* Mohammed, Afzal <afzal@xxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
