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:

quoted

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