On Thu, 2012-02-23 at 12:43 +0100, Cousson, Benoit wrote:
> Hi Tomi,
>
> On 2/22/2012 1:07 PM, Tomi Valkeinen wrote:
> > dsi1: dsi@1 {
> > compatible = "ti,omap4-dsi";
> > ti,hwmods = "dss_dsi1";
> > id =<0>;
>
> Fixed id should be avoided. In theory you should not need that, and if
> it is needed like for the UART because Linux is expecting a tty<id>, you
> should create an alias to map the node to the numbered alias. Just check
> what was done for UART.
We need to know the ID of the DSI block in the driver for pinmuxing,
clock configuration, and possibly some dsi configurations (i.e. max
buffer on DSI1 could be higher than on DSI2). Isn't the alias just,
well, textual alias to be shown to the user?
For cases like buffer size it's easy to add a property, and define the
buffer size in the DT data.
Pinmuxing is handled with control module's register, we need to set
certain bits for DSI1 and some other for DSI2.
Clock config depends also on DSI ID, as the DSS internal clocks differ
for the DSI modules, and the clock muxing is done in DSS core. So, for
example, when DSI2 wants to use the clock from DSI2 PLL, it needs to
call DSS core and tell it to switch DSI2's source clock from PRCM to
DSI2 PLL.
Do you have any suggestions how pinmuxing or clock config could be
handled without explicit id?
> > dispc is not an output interface (so it won't have any children), it
> > doesn't have anything to customize in the dt data, and it's present on
> > all OMAPs. Should it still be present in the DT data, or should the
> > device be created dynamically in platform code?
>
> For consistency, it is still better to have it. You will then be able to
> use the DT compatible mechanism to identify properly the various DISPC
> version if needed.
>
> Don't you have a functional dependency between the DISPC and some other
> nodes like DSI, SDI, DPI?
Yes, all output devices, DSI, DPI, etc, depend on DISPC (well, in theory
not always). Should that be somehow visible in DT data?
> > dpi and sdi are not hwmods as the rest of the nodes. They are, from HW
> > point of view, more or less parts of DSS or perhaps DISPC.
>
> This is fine, hwmod is really needed only for the IP under PRCM control
> mostly. Other device can then be regular platform_device.
>
> I even think that I will get rid of the other hwmod as soon as the clock
> binding will be there in DT. Because for the PRCM point of view, there
> is only one DSS node. The other ones were created artificially to expose
> the clocks to the proper device. They should not be there.
But each DSS submodule has their own sysconfig & related stuff. Isn't
that handled by hwmod code?
> > How about the actual panel devices. Above there's the "ti,tfp410"
> > device. The panel devices are not plain platform devices, so I need to
> > handle those myself. Can I somehow handle that in the platform code,
> > creating omap_dss_devices at boot time, or do I need to create those
> > devices in, for example in this case, dpi-driver's probe?
>
> That does not look right to me. Why cannot they be platform_device?
Legacy reasons. I don't think there are other reasons.
I fear that changing the panel devices to platform devices will be a
huge change. I think the easiest way would be to change the current
omap_dss_device to contain a platform_device instead of a device. But
I'm not sure if that works, I didn't find any other driver using
platform_device in that way.
Well, I need to look at this more.
Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
