[PATCH 04/14] bus: mvebu-mbus: Add static window allocation to the DT binding
Jason Gunthorpe
jgunthorpe at obsidianresearch.com
Wed Jun 12 09:08:45 EST 2013
On Wed, Jun 12, 2013 at 12:22:29AM +0200, Sebastian Hesselbarth wrote:
> sorry to kick into this thread that late but Ezequiel made me think of
> address windows when asking on IRC. From what I can see from your and
> Arnd's proposal the only real difference is that having it Arnd's way
> allows you to have two or more windows mapped to e.g. devbus with
> totally independent address ranges - while yours requires one large
> window for all child devices?
Sorry, I'm having problems following the possessives in your paragraph
- which things are you comparing?
> Although, not thought to the bare end this could also work and maybe
> reflects the actual hardware more accuate:
I actually posted something like this a time ago, but Arnd's
suggestion to encode the target id in the address seems much clearer,
and more accurate, though a bit more work to parse.
It is 'better' in that the base addresses are in exactly one place -
the ranges of the mbus node. With marvell,mbus-target the base
addreses are strewn everywhere and now are difficult to change.
A main consideration here is that the bootloader needs to update the
base addresses - to support the 0xd0 vs 0xf1 internal-regs base
address issue. So I think that requirement alone is enough to make
marvell,mbus-target undesirable.
> When removing size from marvell,mbus-target above, mbus driver could
> also probe for required max size from the reg properties of the child
> nodes. Arnd already said that mbus isn't "simple-bus" anymore, why
> can't it just walk through the nodes and collect required windows?
With enough restrictions, I think it is pretty easy to parse
marvell,mbus-target, but you can employ the same restrictions to
simplify parsing the 2 cell address format too.
Jason
More information about the devicetree-discuss
mailing list