Re: Questions about the Freescale/NXP QuadSPI controller

[Boris Brezillon <boris.brezillon@xxxxxxxxxxx>]

On Thu, 6 Sep 2018 11:11:57 +0000
Yogesh Narayan Gaur <yogeshnarayan.gaur@xxxxxxx> wrote:

> Hi Boris,
> 
> > -----Original Message-----
> > From: Boris Brezillon [mailto:boris.brezillon@xxxxxxxxxxx]
> > Sent: Saturday, August 4, 2018 7:07 PM
> > To: Han Xu <han.xu@xxxxxxx>
> > Cc: Frieder Schrempf <frieder.schrempf@xxxxxxxxx>; David Wolfe
> > <david.wolfe@xxxxxxx>; Fabio Estevam <fabio.estevam@xxxxxxx>;
> > Prabhakar Kushwaha <prabhakar.kushwaha@xxxxxxx>; Yogesh Narayan Gaur
> > <yogeshnarayan.gaur@xxxxxxx>; shawnguo@xxxxxxxxxx; linux-
> > mtd@xxxxxxxxxxxxxxxxxxx; linux-spi@xxxxxxxxxxxxxxx;
> > dwmw2@xxxxxxxxxxxxx; computersforpeace@xxxxxxxxx;
> > marek.vasut@xxxxxxxxx; richard@xxxxxx; miquel.raynal@xxxxxxxxxxx;
> > broonie@xxxxxxxxxx Subject: Re: Questions about the Freescale/NXP
> > QuadSPI controller
> > 
> > Hi Han,
> > 
> > On Thu, 2 Aug 2018 21:58:48 +0000
> > Han Xu <han.xu@xxxxxxx> wrote:
> >   
> > > > -----Original Message-----
> > > > From: Frieder Schrempf [mailto:frieder.schrempf@xxxxxxxxx]
> > > > Sent: Thursday, August 2, 2018 8:09 AM
> > > > To: David Wolfe <david.wolfe@xxxxxxx>; Fabio Estevam
> > > > <fabio.estevam@xxxxxxx>; Prabhakar Kushwaha
> > > > <prabhakar.kushwaha@xxxxxxx>; Yogesh Narayan Gaur
> > > > <yogeshnarayan.gaur@xxxxxxx>; Han Xu <han.xu@xxxxxxx>;
> > > > shawnguo@xxxxxxxxxx
> > > > Cc: linux-mtd@xxxxxxxxxxxxxxxxxxx; boris.brezillon@xxxxxxxxxxx;
> > > > linux- spi@xxxxxxxxxxxxxxx; dwmw2@xxxxxxxxxxxxx;
> > > > computersforpeace@xxxxxxxxx; marek.vasut@xxxxxxxxx;
> > > > richard@xxxxxx; miquel.raynal@xxxxxxxxxxx; broonie@xxxxxxxxxx
> > > > Subject: Re: Questions about the Freescale/NXP QuadSPI
> > > > controller
> > > >
> > > > Ping.
> > > >
> > > > I'm not sure if my message below went out to you at all. At
> > > > least I can't find it in the ML archive.
> > > >
> > > > I still hope someone can help with the questions below.
> > > >
> > > > Meanwhile for the second point I did some tests myself with one
> > > > chip on each of the two buses and it worked fine with my latest
> > > > v2 patches. So I'm not sure at all why Yogesh has problems with
> > > > his setup (two chips on the first bus).  
> > >
> > > Tried to test the v2 patch set on i.MX6SX SDB board but get the
> > > memory map  
> > failure.  
> > >
> > > [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for
> > > resource [mem  
> > 0x70000000-0x7fffffff]  
> > > [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe
> > > failed [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed
> > > with error -12
> > >
> > > This is the reason why dynamic ioremap added in previous driver,
> > > please refer to
> > >
> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> > >  
> > chwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Cyogeshnar
> > ayan  
> > > .gaur%40nxp.com%7Caed89ff1b0ac4936acd408d5fa0f7303%7C686ea1d3bc2  
> > b4c6fa  
> > >  
> > 92cd99c5c301635%7C0%7C0%7C636689866643724038&amp;sdata=lZnBc0m%
> > 2BOp8yY  
> > > JBFcNBEa2HSoNMhmJjeM9cIoGeVs0E%3D&amp;reserved=0  
> > 
> > We can reduce the size of the iomap to 2k * 4, since this is all we
> > use currently. Can you try to change the size of the ioremap call
> > to 16k and tell us if it works.
> > 
> > Unrelated to this issue, we still have 2 questions left unanswered:
> > 
> > 1/ is there an easy way to invalidate AHB buffers? I mean, not
> >    something that implies a full reset + several milliseconds of
> > delay after the reset. Right now we trick the caching logic by
> > mapping a portion that is twice the size of the buffer and
> > switching from one sub-portion to this other to trigger a real read
> > on each read access, but that's hack-ish, and I'd be surprised if HW
> >    engineers hadn't planned for this "manual AHB buffer flush" case.
> >   
> 
> I had a discussion with the HW IP owner, they said that IP command
> and AHB command are two separate sets of accessing method to flash.
> Memory coherency between IP and AHB command can't be maintained by
> the hardware. So after every IP data write command (write, erase,
> write reg) AHB RX buffer needs to be flushed.
> 
> Software Reset is the safest way to achieve this. 
> Adding of the delay in several millisecond after setting of the Reset
> Bits is too conservative, can be tried with the reduced value.

Do you know exactly how many cycles/nanoseconds we should wait? Is
there a status reg that says when the block is ready to be used again?

> 
> > 2/ if we use DMA, do you know what happens when the TX FIFO runs out
> >    of data while the TX request is not finished yet. In PIO mode, it
> >    seems the engine sends garbage on the bus when that happens, and
> > we definitely don't want that.  
> 
> For this query, they have said TX FIFO is the max limit, if data send
> more than TX FIFO size then it would results in un-defined behavior
> and there would be data corruption.

Okay.
Marek, I guess we have a good reason to accept patch [1] now.

[1]http://patchwork.ozlabs.org/patch/928677/