On Tue, 2012-08-07 at 12:32 +0300, Felipe Balbi wrote:

Hi,

On Tue, Aug 07, 2012 at 12:27:52PM +0300, Tomi Valkeinen wrote:

quoted

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 ?

Yes, they can be overridden, but I think it's still quite difficult to
manage. DSS is modeled with multiple blocks, also in DT data. So you'd
need to override multiple entries.

And it'd also require a new dts file for each version of your board with
different ES version.

Also, I don't really see why this information would need to be present
in the DT data (especially as it's not simple). It's all trivially found
out in the code, by using cpu_is & soc_is.

 Tomi