Re: Setting NAND timings parameters (Re: [RFC/PATCH v2] mtd: nand: pxa3xx: Remove redundant device probing)

[Brian Norris <computersforpeace@gmail.com>]

Hi Ezequiel,

I see that the removal of your driver-specific device table stalled on
this issue. Are you planning on picking it up?

On Tue, Sep 24, 2013 at 06:46:54PM -0300, Ezequiel Garcia wrote:
> On Tue, Sep 10, 2013 at 04:14:25PM +0200, Daniel Mack wrote:
> > > 
> > > Right. However, since we can easily add support to configure every controller
> > > parameter (right?) this shouldn't be a problem.
> > > 
> > > What do you think of this change, Daniel?
> > 
> > I always thought that this detail of the pxa nand driver is ugly :) But
> > I'd say before it can be merged, you need to provide code to set the
> > timing from parameters obtained from generic part. Are you working on
> > this? I'd happily test more patches.
> > 
> 
> Returning to this point: it seems we have two different cases: ONFI-compliant
> devices and non-ONFI.
> 
> For the ONFI, we can have a timings parameter table with some index according
> to the ONFI timing mode available or user-selected. This table could be
> generic (as in Matthieu Castet patch [1]) or driver specific (as in
> denali driver).

It looks like denali just uses a module parameter so the user can select
an ONFI timing mode. This isn't flexible or generically useful and
shouldn't be encouraged on new code.

If more drivers need timing information like this, I would like to see a
generic implementation like Matthieu's (although his can be improved, I
think). It's also worth noting that his code only gets information for
the SDR timing modes, not DDR. I don't know if any hardware is utilizing
DDR modes (I haven't tested it on mine), but it's worth considering
if/how this would fit into the framework.

> For the non-ONFI, we could just add platform data / device-tree bindings
> to allow to user to set the timings.
> 
> [1] http://patchwork.ozlabs.org/patch/197506/
> 
> How does this sound?

Brian