[PATCH 04/10] bus: introduce an Marvell EBU MBus driver

[ezequiel.garcia@free-electrons.com (Ezequiel Garcia)]

Hi Jason,

On Wed, Mar 06, 2013 at 04:04:12PM -0700, Jason Gunthorpe wrote:
> 
>        nor at 0 {
>           compatible = 'linux mtd nor driver';
>           regs = <MAPDEF(1, 0xab, MAPDEF_NOMASK) 0x10000>;
>       }
> 
> We can now tell directly that 'linux mtd nor driver' is behind MBUS
> target 0xab, and the OF code already knows the base for this MBUS
> target from the ranges property, as modified by the MBUS driver. The
> MBUS driver also knows which targets to configure windows for
> immediately at boot without having to consult internal tables. Plus we
> don't need to modify the NOR driver to call out to MBUS window
> functions to fetch an address.
> 
> There are a few other variants on how to do this in DT, but they all
> come down to modeling the MBUS target using a ranges property and
> having the mbus driver adjust the range mapping at runtime.
> 

At least in the flash (NOR and friends) case, this is not necessarily true.

Now that the Device Bus driver is posted I think we have a nice example
on how address decoding windows would be allocated through the mbus
driver, *without* touching the child driver (i.e. NOR driver).

The windows are allocated as part of the "preparing" tasks the Device
Bus does as the parent device and it seems like a very clean solution.
The windows are specifically related to him, so I think this driver is
the most appropriate to perform the window management.

In a certain way, this is similar to other memory-controller devices
(e.g. OMAP's GPMC) that need to request a chip select before the child
device can be accessed.

Moreover -as I already stated in the patchset- I believe we can make the
Device Bus implement dynamic window allocation, if he can't find a 'ranges'
property for a given child.

In conclusion: there is absolutely no need to change the NOR driver,
and there is no need to explictly add an explicit description of the
NOR window in the device tree.

Thanks,
-- 
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com