# Re: \[PATCH 1/6\] OMAPDSS: DISPC: Remove cpu\_is\_xxxx checks

- From: Felipe Balbi \<hidden\>
- Date: 2012-08-07 09:32:09 
- List: linux-fbdev
- Page: https://ratatoskr.run/linux-fbdev/2012/08/13463590
- Thread: https://ratatoskr.run/linux-omap/2012/08/13463753/t.md

```text
Hi,

On Tue, Aug 07, 2012 at 12:27:52PM +0300, Tomi Valkeinen wrote:
> On Tue, 2012-08-07 at 12:14 +0300, Felipe Balbi wrote:
> 
> > Or you could use the driver_data field on the platform_device_id and
> > of_device_id structures for that. Something like:
> > 
> > static const struct platform_device_id dss_id_table[] __initconst = {
> > {
> > 	{ "omap2-dss", omap2_dss_features },
> > 	{ "omap3-dss", omap3_dss_features },
> > 	{ "omap4-dss", omap4_dss_features },
> > 	{ "omap5-dss", omap5_dss_features },
> > 	{} /* Terminating entry */
> > };
> > 
> > then, on your probe, you just need to copy id->driver_data to your own
> > structures so you can reference them later. No need for cpu_is_* or
> > soc_is_* or machine_is_* anywhere.
> > 
> > On your platform_code, wherever you create the dss device, you need to
> > fix up the name though. The platform_device name should match
> > platform_device_id name, not platform_driver name.
> 
> I've thought about that, but we need versions even for different OMAP ES
> versions.
> 
> So in the device tree data we couldn't have the DSS nodes in a, say,
> common omap4 file. We'd need separate DT files for each OMAP ES version.

you can overwrite attributes on your board dts file, right ? Meaning
that e.g. omap4.dtsi would have:

dss1: dss@xxxx {
	compatible = "ti, omap4-dss";
};


then on omap4-based-board.dts:

&dss1 {
	compatible = "ti,omap4-based-board-dss";
};

or something similar. Isn't that doable ? Benoit, would this work on
DTS ?

-- 
balbi
```

## Attachments

- [signature.asc](https://ratatoskr.run/linux-fbdev/2012/08/13463590/attachment/0) (application/pgp-signature, 836 bytes)
