[PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding

Arnd Bergmann arnd at arndb.de
Tue Jun 11 19:10:36 EDT 2013

On Tuesday 11 June 2013 16:58:41 Jason Gunthorpe wrote:
> On Wed, Jun 12, 2013 at 12:34:14AM +0200, Arnd Bergmann wrote:
> > a significant waste of physical address space, because the (per-soc)
> > ranges property has to be set up for the largest possible external
> > device connected to the bus, but the mbus window only needs to cover the
> > device that is actually connected.
> Yes, but perhaps that is a good argument to not put the ranges in the
> dtsi?

Fair enough. In that case not using ranges at all is probably easier
so the board file only needs to update one place.

> > I think we have to walk the entire tree of devices underneath mbus,
> > at least any device node that has a 'reg' property, following children
> > of any device node with a 'ranges' property. We might need to
> > add a variant of of_get_address() that does a partial translation
> > up to a given node (the mbus) instead of all the way to the root.
> Hum, how complex do you think this is? Run down the entire tree,
> translate every regs and maintain a max offset for every target id.

It's the same thing we do for PCI.

> > > then dynamic assignment of that window
> > > makes sense to me. (however, this also looks a bit tricky, how do you
> > > avoid hitting the PCI-E window reservations, for instance?)
> > 
> > The PCI-E window would have 'ranges' but no 'regs', so we automatically
> > skip it.
> The trouble is not skipping PCI-E when parsing the dt. When the
> kernel goes to make a dynamic window allocation it needs to exclude
> the address space reserved for the PCI-E aperture.
> The mbus driver starts before the PCI-E driver, so how can this be
> resolved? Hardwire specialness about PCI-E into mbus?
> Make the PCI-E aperture fully dynamic?
> Starting to be pretty complex - for what gain?

I think this can be simplified a lot by making PCI a known special case:

We assign all regular (non-PCI) windows from the top, and whatever is
left by the time PCI comes up can be used for that, starting at the
bottom of the avaliable space.
> > > I'm not sure there is a good reason to reject the address map in the
> > > DT?
> > 
> > You mean keep all windows that are listed by the boot loader but
> > reassign the others? I guess it would be simpler but may result in
> > a less optimal address map.
> Sure, but what does a more optimal address map get you?
>  1) More space to map SDRAM - however - the SDRAM map is controlled
>     exclusively by the bootloader and the kernel doesn't have the
>     information or the code to mess with it - so this isn't possible
>  2) More space for the PCI-E aperture - this is entirely controlled by
>     the kernel, but today we are using the pre-set allocation from the
>     DT, so it doesn't matter how tightly the rest of the stuff is packed.
> To me, it feels like alot of complex trouble to do actual dynamic
> allocation, and I don't really see any gain.

We could of course decide to skip the dynamic part in the Linux
implementation for the moment, but I would definitely want to
see the binding written in a way that going fully dynamic can be
done later without changing the binding if we decide we need to
squeeze out more RAM or PCI space.


More information about the linux-arm-kernel mailing list