Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information

Hi Tomi,

On Monday 09 December 2013 14:45:25 Tomi Valkeinen wrote:

On 2013-12-05 19:05, Tony Lindgren wrote:

quoted

* Tomi Valkeinen [off-list ref] [131204 04:31]:

Description missing.. But other than that can you please check that
the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
the hwmod data from device" works with this?

The test to do is to remove the related reg, interrupt and dma entries
from omap_hwmod_*_data.c, and make sure the related hwmod data is
initialized from DT properly.

I made a quick test with panda, by applying your patch and reverting
b38911f3472be89551bfca740adf0009562b9873. That only effectively tests
the DISPC IRQ, but that worked fine.

quoted

I don't know if it makes sense to have them as children of dss_core, they
really all seem to be completely independent devices?

The DSS subdevices depend on the dss_core. dss_core has to be powered up
for any of the subdevices to work. This is done automatically by the
runtime PM when the subdevices are children of the dss_core.

I'd like to get a clearer picture of the hardware here. The OMAP3 ISP is 
organized in a seemingly similar way, with the hardware subdivided in high-
level more-or-less independent modules. However, from a system point of view, 
the ISP submodules are not standalone: they're part of the same power domain 
as the ISP core, with subclocks management and interrupts being handled by the 
ISP core. For those reasons we've modeled the ISP as a single platform device.

Are the DSS submodules really independent, or are they organized similarly ? 
For instance do they each have a clock handled by the OMAP core clock IP, or 
are the clocks gated by the DSS core ? Do they have interrupts routed to the 
GIC, or does the DSS core driver demux the interrupts ?

If the submodules are not independent, would it make sense to have a single DT 
node that would be matched with the DSS core driver ? You could list 
information about the submodules in subnodes, and possibly create platform 
devices internally in the DSS core, but a single platform device would be 
instantiated from DT, and the DSS core wouldn't need a "simple-bus" compatible 
string. My gut feeling is that this would be a better representation of the 
hardware, but I might not known enough about the DSS and be completely wrong.

quoted

BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
property and do the lookup based on the compatible property instead ;)
So from that point of view we need to get the device mapping right in
the .dtsi files, and don't want to start mixing up separate devices into
single .dtsi entry.

Hmm, was that just a general comment, or something that affects the DSS
DT data I have in my patch? As far as I understand, the DSS nodes
reflect the current hwmods correctly.

With the exception that DPI and SDI do not have a matching hwmod, as
they are really part of dss_core/dispc. They are separate nodes as they
are "video outputs" the same way as the other subnodes.

I could perhaps remove the DPI and SDI nodes, and have them as direct
video ports from DISPC, but... That's easier said than done.

DPI and SDI indeed seem like ports to me, node devices. Have you given the 
implementation a thought ? How difficult would it be ?

-- 
Regards,

Laurent Pinchart