[PATCH 1/3] omap gpmc : add support of setting CYCLE2CYCLEDELAY and BUSTURNAROUND

[Mohammed, Afzal]

+ Tony, Daniel

Hi,

On Wed, Nov 07, 2012 at 02:04:03, Hunter, Jon wrote:
> On 11/06/2012 12:00 PM, Matthieu CASTET wrote:

> > I will post another patch, unless this is already done in  Afzal patch (Is there
> > a tree where I can get Afzal pending patches ?)

> Afzal keeps his kernel tree on gitorious [1]. However, I am not sure
> what Afzal's plans are for the remaining patches not yet merged and
> which branch you should look at (I have a lot of problems viewing
> anything on gitorious these days).
> 
> Afzal, let us know how you prefer to handle this.

My initial plan was to do timing related changes first and then dt
conversion. But at the present moment, it seems higher priority has
to be given for dt conversion over timing changes (it involves
using generic timing routine for all required gpmc peripherals,
handling additional timings inclusive of $subject) and hence timing
related changes were put in suspended animation for now.

And Daniel has started working on gpmc dt. Let us take Tony's
opinion on how to deal with this, Tony ?

Following are the pending changes w.r.t timing available @[1]
(please note that these would have to be rebased over branch/tag
specified by Tony in reply to Matthieu's patch 3/3)
a. d42eafa ARM: OMAP2+: nand: remove redundant rounding
b. f229aba ARM: OMAP2+: gpmc: handle additional timings
c. 14cbb87 ARM: OMAP2+: gpmc: generic timing calculation
d. 9830264 ARM: OMAP2+: onenand: generic timing calculation
e. 5f33ea5 ARM: OMAP2+: smc91x: generic timing calculation
f. 9876020 ARM: OMAP2+: tusb6010: generic timing calculation (HEAD)

'b' is a superset of $subject

Originally 'a' and 'b' was part of gpmc cleanup series for common
zImage, then Tony requested for minimal changes for it, hence
'a' & 'b' was left out in the pull request (picked up by Tony),
so that gpmc common zImage cleanup series would not create any
timing related issues.

One thing to note is that cycle2cycledelay and busturnaround field's
would get zeroed out with $subject patch for those peripheral's that
call gpmc_cs_set_timings(). If there are any boards silently
depending on bootloader setting these values, it may be affected, so
this change would need to be verified for existing boards in mainline.

Perhaps 'b' (for $subject patch) can be taken ahead if Tony is
happy with it.

And regarding patches 2 & 3 of Matthieu's series that calculate
timings, I was wondering whether generic timing routine (c) can
learn from it as well as vice-versa. Also with gpmc common zImage
series, omap-nand driver does not have access to timing related
gpmc functions, a new gpmc function would have to be exported
that translates onfi timings to gpmc (or educate generic timing
routine with onfi translation too ?)

Regards
Afzal

[a] git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing