Current state of AM33xx patches

[zonque@gmail.com (Daniel Mack)]

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