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

[Tony Lindgren <tony@atomide.com>]

* Mohammed, Afzal <afzal@ti.com> [121107 01:00]:
> + 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 ?

Up to you to figure out the ordering.
 
> 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.

Maybe send pull requests for the ones that are ready to go?

They should be done against what we have in clean-up probably, so
omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3 or against
omap-for-v3.8/cleanup-headers-gpmc it that merges easily with
the cleanup branch.
 
> 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 ?)

Right, once we enable CONFIG_ARCH_MULTIPLATFORM, drivers trying
to include <mach/*.h> or <plat/*.h> files will fail to build.

Regards,

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