Current state of AM33xx patches

[Paul Walmsley]

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.

> shouldn't things be done right in the first place?

Well, all this is distinct from what the 'right' thing is or was.

It should be noted that from the power management and multiple bus 
initiator perspectives, the process of migrating from hwmod data to DT 
will be lossy.  For example, DT uses a single-root perspective of the 
device hierarchy, and does not explicitly encode the interconnections 
between IP blocks.


- Paul