RE: Questions about the Freescale/NXP QuadSPI controller

[Han Xu <han.xu@xxxxxxx>]

> -----Original Message-----
> From: Frieder Schrempf [mailto:frieder.schrempf@xxxxxxxxx]
> Sent: Wednesday, September 12, 2018 1:41 PM
> To: Han Xu <han.xu@xxxxxxx>
> Cc: Boris Brezillon <boris.brezillon@xxxxxxxxxxx>; 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 12.09.2018 19:04, Han Xu wrote:
> >
> >
> >> -----Original Message-----
> >> From: Frieder Schrempf [mailto:frieder.schrempf@xxxxxxxxx]
> >> Sent: Monday, September 3, 2018 4:02 AM
> >> To: Han Xu <han.xu@xxxxxxx>
> >> Cc: Boris Brezillon <boris.brezillon@xxxxxxxxxxx>; 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 04.08.2018 15:37, Boris Brezillon wrote:
> >>> 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%2Fsm
> >> ex12-5-en-
> ctp.trendmicro.com%3A443%2Fwis%2Fclicktime%2Fv1%2Fquery%3Fu
> >>
> rl%3Dhttps%253a%252f%252femea01.safelinks.protection.outlook.com%252
> f
> >> %253furl%253dhttps%25253A%25252F%25252Fpa%26umid%3Dd6cc1014-
> 1848-42fb
> >> -92fd-
> 9626d45c8050%26auth%3D541e45255b6517100d80c2b1b80b6933b203c492-
> >>
> 5aa8e1977a9db94300a9f61f5446e7a21b175f56&amp;data=02%7C01%7Chan.x
> u%40
> >>
> nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d3bc2b4c6fa92c
> d99c
> >>
> 5c301635%7C0%7C0%7C636723744426896223&amp;sdata=Y32I9H9adPn%2Bn
> lcICuV
> >> M8Uoozsig%2BM3F0rNAhkIF5ZE%3D&amp;reserved=0
> >>>>
> >>
> tchwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Chan.xu
> >> %40nx
> >>>>
> >>
> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
> >> 9c5c
> >>>>
> >>
> 301635%7C0%7C0%7C636715621426190473&amp;sdata=XWPfWe%2Fu2ePW
> >> mNPe179D0
> >>>> vjTp6eLp0%2FJRF2vRayDwug%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.
> >>
> >> Were you able to test with the reduced iomap size?
> >> It would be great to know if it works on your board.
> >>
> >> Thanks,
> >> Frieder
> >
> > Test the code on i.MX6SX sabreauto board with two micron n25q256a chips
> on two CS.
> > First issue found is __div0 kernel dump with these code
> > /* Max 64 dummy clock cycles supported */ if (op->dummy.nbytes * 8 /
> > op->dummy.buswidth > 64) dummy.buswidth was not set during read id.
> 
> First, thank you for coming back to this and doing the test.
> I'm currently not sure about the reason for this, but I guess Boris will figure it
> out easily ;)
> 
> >
> > Second issue is the second part failed to be probed, tried both buswidth 4
> and buswidth 1.
> >
> > [    1.364979] m25p80 spi5.0: found n25q256a, expected m25p80
> > [    1.370986] m25p80 spi5.0: n25q256a (32768 Kbytes)
> > [    1.381020] m25p80 spi5.1: unrecognized JEDEC id bytes: ff, ff, ff
> >
> > These are the DT settings:
> > &qspi1 {
> >          pinctrl-names = "default";
> >          pinctrl-0 = <&pinctrl_qspi1_1>;
> >          status = "okay";
> >
> >          flash0: n25q256a@0 {
> >          ¦       #address-cells = <1>;
> >          ¦       #size-cells = <1>;
> >          ¦       compatible = "micron,m25p80";
> >          ¦       spi-max-frequency = <29000000>;
> >                  spi-rx-bus-width = <4>;
> >                  spi-tx-bus-width = <4>;
> >          ¦       reg = <0>;
> >          };
> >
> >          flash1: n25q256a@1 {
> >          ¦       #address-cells = <1>;
> >          ¦       #size-cells = <1>;
> >          ¦       compatible = "micron,m25p80";
> >          ¦       spi-max-frequency = <29000000>;
> >                  spi-rx-bus-width = <4>;
> >                  spi-tx-bus-width = <4>;
> >          ¦       reg = <1>;
> >          };
> > };
> 
> First, I think you should add "jedec,spi-nor" to your compatible properties.
> 
> Second, are you sure, that the two chips are both on QSPIA using the two
> chip selects?
> I have no schematics of the board, but if I look at the devicetree in the linux-
> imx kernel [1] it seems to me that one chip is on QSPIA CS0 and the other on
> QSPIB CS0.
> If this is the case, then you have to set reg = <2> for the second chip.

Yes, you are right, the second chip connects to QSPIB CS0, with the DT change, both of them work fine with __div0 issue workaround.

> 
> Thanks,
> Frieder
> 
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.f
> reescale.com%2Fgit%2Fcgit.cgi%2Fimx%2Flinux-
> imx.git%2Ftree%2Farch%2Farm%2Fboot%2Fdts%2Fimx6sx-
> sabreauto.dts%3Fh%3Dimx_4.9.11_1.0.0_ga%23n771&amp;data=02%7C01%
> 7Chan.xu%40nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d
> 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636723744426896223&amp;sdata
> =038DdgMLjO23Io3CTHoSVrJL2Ho%2BgxyHlx9%2BLMrLWkQ%3D&amp;reser
> ved=0
> 
> >>>
> >>> 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.
> >>>
> >>> 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.
> >>>
> >>> While #1 is not blocking us, #2 is if we don't have those patches
> >>> [1][2] applied, and Marek wanted to be sure there was no other ways
> >>> to solve the "TX FIFO starvation" issue before considering these changes.
> >>> So that'd be great if someone from NXP could have a look/ask around
> >>> and give us answers to those 2 questions.
> >>>
> >>> Thanks,
> >>>
> >>> Boris