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

[jgunthorpe@obsidianresearch.com (Jason Gunthorpe)]

On Mon, Mar 18, 2013 at 05:27:18PM +0100, Thomas Petazzoni wrote:
> Dear Jason Gunthorpe,
> 
> On Fri, 8 Mar 2013 10:29:50 -0700, Jason Gunthorpe wrote:
> 
> > > Sorry, but we _do_ want the kernel to be able to set those timings
> > > parameters, and therefore, a Device Bus driver will be needed,
> > > regardless of whether it creates the address window or not.
> > 
> > See the very good idea from Maxime Bizon about autoprobing the ONFI
> > timings directly from the NAND chip.
> 
> ONFI (Open NAND Firmware Interface) is about NAND, while the Device Bus
> driver submitted by Ezequiel is about NOR. I don't think NORs have a
> standard way of exposing their memory timings requirements. And the
> Device Bus driver is not only for NORs, but also for example for FPGAs
> connected on the memory bus.

Right, AFAIK there is no CFI property for device timings, and there is
a lot of variation of optimal timings between pin-compatible
parts.

Some kind of out-of-band indication of the flash chip and speed grade
is necessary to get optimal timings, unfortunately - no idea how you'd
fit that sensibly into a DT framework.

> Ezequiel followed the work done by Jon Hunter on the GPMC driver for
> the memory bus of OMAP SoCs, which includes the definition of timings
> in the Device Tree. To me, it seems like defining the timings in the
> Device Tree do make sense, and "ONFI" is not a good enough answer to
> get rid of the Device Bus driver submitted by Ezequiel.

As I said, I think that is fine - there is nothing wrong with a driver
to set the bus timings. But, if there are no bus timings in the DT
then the driver should not be involved at all..

Similarly the driver should require all the timings, re-using timings
left in the register with timings from the DT seems very strange..

Regards,
Jason