[PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings

Tony Lindgren tony at atomide.com
Thu Jun 14 06:19:02 EDT 2012


* Mohammed, Afzal <afzal at ti.com> [120614 03:15]:
> Hi Tony,
> 
> On Wed, Jun 13, 2012 at 17:28:33, Mohammed, Afzal wrote:
> > On Wed, Jun 13, 2012 at 17:24:45, Tony Lindgren wrote:
> > 
> > > > If there's a chance it causing file system corruption, we should
> > > > test it carefully on the boards before applying. If that's done,
> > > > then there's probably no need for warnings. It's safer to disable
> > > > NAND for untested boards if there's a chance of breaking the timings.
> > > 
> > > Actually this patch breaks at least DMA on tusb6010 on n8x0. That's
> > > a MUSB hardware in a wrapper connected to GPMC that's very picky with
> > > the timings.
> > > 
> > > Got any hints what should be done with the cycle2cycle stuff for
> > > tusb6010?
> > 
> > Not as of now, let me try to find out.
> 
> Probably with the below patch [1], we can get values set by bootloader &
> calculate back value to entered in Kernel, of course that may not work
> if tusb6010 works with different gpmc i/p frequency.

Well I took a look at the values, and it seems the only difference is the
static GPMC_CONFIG1_CLKACTIVATIONTIME(1) that your patch now overwrites 0.

Tony



More information about the linux-arm-kernel mailing list