[PATCH 0/4] OMAP-GPMC generic timing migration

[tony@atomide.com (Tony Lindgren)]

* Daniel Mack <zonque@gmail.com> [121017 08:15]:
> Hi Afzal,
> 
> On 17.10.2012 07:42, Afzal Mohammed wrote:
> > On Tuesday 16 October 2012 12:26 PM, Afzal Mohammed wrote:
> >> I certainly don't think it is easier, rather tougher, cleaner
> >> as well. One thing that worried me was, if we pursue the
> >> auxdata path (a last resort option) and later if it is
> >> objected, we would be back to square one.
> > 
> > I commented on auxdata usage without visualising in more
> > detail how it can be implemented, it was bad of me.
> > 
> > I doubt whether auxdata would help here, it seems using
> > compatible field alone would help in deciding relevant
> > custom timing routine. Whether we want this kind of
> > peripheral knowledge in gpmc driver instead of using
> > generic timing routine has to be decided though.
> 
> Maybe slightly off-topic, but still:
> 
> When GPMC is used for driving NAND chips that comply to CFI, the timings
> could actually be derived from the connected peripheral as well. I
> believe a slowest-possible-mode will have to be selected first for the
> identication phase.

I wish.. Just getting things working to the identification phase
requires quite a bit of configuration for the timings.
 
> Another thing that might be worth thinking about is that apart from the
> GPMC host controller and the peripherals, there could be other
> components like level shifters or series resistors on the board that
> limit the maximum speed of transactions. So in fact we might be better
> off storing all that timing details in the DT, as they are in fact
> highly application specific.

Yes and the level shifters affect timings too.

Regards,

Tony