Re: [PATCH 1/6] OMAPDSS: DISPC: Remove cpu_is_xxxx checks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Tue, Aug 07, 2012 at 12:57:16PM +0300, Tomi Valkeinen wrote:
> 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:
> > > 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 ?
> > 
> 
> 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.

Fair enough. I just think we should remove all cpu_is_* and soc_is_*
from drivers.

-- 
balbi

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux