Hi Tomi, On Monday 09 December 2013 14:45:25 Tomi Valkeinen wrote: > On 2013-12-05 19:05, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkeinen@xxxxxx> [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. > > > 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. > > 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
Attachment:
signature.asc
Description: This is a digitally signed message part.
