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.
Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
