[RFC V2 PATCH 0/8] ARM: kirkwood: cleanup DT conversion

[Jason Gunthorpe]

On Mon, Jan 28, 2013 at 08:03:32PM +0100, Thomas Petazzoni wrote:

> devices described in the DT, nothing different. In their ->probe()
> function, those driver call some mvebu_setup_addr_decoding_window()
> function, which is part of an API provided by the address mapping
> driver.

I think that would be a layering mess to update these possibly shared
drivers to conditionally call some mvebu specific function in some
case, with some SOC specific set of parameters.. The MBUS driver
should take care of that, just like the PCI framework takes care of
address allocation.
 
> The address at which we configure the various address decoding windows
> is an operating system specific decision, it is not a description of
> the hardware. Therefore, it shouldn't be encoded in the DT, because the
> DT describes the hardware, not the Linux-specific decisions on how the
> hardware should be used.

DT models PCI BARs/Bridge windows as well, which are functionally
identical to the MBUS decode windows. There *is* a piece of address
decoder hardware, and the DT binding for that kind of hardware is a
bus with ranges. So it is completely appropriate to model that in DT.

The OF convention for bridge buses is to put the boot loader assigned
address in the DT (under the assumption that the boot loader sets
things up properly) so it is reasonable to include those addresses in
DT as well..

If, someday, the MBUS driver wants to dynamically allocate every MBUS
region, then that is fine, it can ignore/override the addresses from
the DT, just like the PCI stuff does for BARs/etc, but for today
without dynamic assignment it makes alot of sense to just use the DT
values directly.

Jason