Hi Paul, On 30.06.2012 04:11, Paul Walmsley wrote: > On Fri, 29 Jun 2012, Daniel Mack wrote: > >> Correct me if I'm mistaken, but this isn't really what DT was designed >> for. In this context, it is used as a simple list of devices to probe, >> not as a abstracted description of the hardware resources and their >> interconnects. >> >> The question is: is that the way things should be kept for OMAP/AM33xx? >> Or should work be done to move all that hwmod stuff to proper >> clk/irq/res definitions that can be used from DT generically? > > Eventually the MPU address space, MPU interrupt controller IRQ line data, > system DMA controller data, and some of the other common resource > information are probably going to migrate from the hwmod data into the DT > blob. > > And probably some of the power management-related data will migrate to the > IP block driver code used for a particular SoC. > > Probably the best time for this to happen is after the PRM/CM/SCM drivers > are written, and an omap_bus layer is created from the existing hwmod > code. The planning that we've done in conjunction with the ARM DT people > involves getting DT board file handling done first, which is really what > DT makes the most sense for. Then looking at the on-chip SoC stuff > afterwards. > >> As there's actually no need to care for legacy users at all (as no board >> support for AM33xx is mainline), > > The hwmod data is unrelated to the board files. > > The "legacy" user here is the hwmod code. It uses the data to create > devices for the IP blocks on the SoC, to reset those IP blocks at kernel > init, and to implement IP block power management via the runtime PM layer.
Ok, thanks for the explaining this. For now, I'll add hwmod stubs for the components I need. Btw, has anyone yet worked on getting the MDIO/EMAC driver merged? Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
