RE: Questions about the Freescale/NXP QuadSPI controller

[Han Xu <han.xu@xxxxxxx>]

> -----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%2Fpa
> >>
> 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.

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>;
        };
};

> 
> >
> > 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
> >
> >
> [1]https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fp
> >
> atchwork.ozlabs.org%2Fpatch%2F928677%2F&amp;data=02%7C01%7Chan.x
> u%40nx
> >
> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
> 9c5c3
> >
> 01635%7C0%7C0%7C636715621426190473&amp;sdata=p%2FJBfxNd2Swlmrrr
> H9Xk2R2
> > DDl%2BshfXdUoyXAy4bXBc%3D&amp;reserved=0
> >
> [2]https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fp
> >
> atchwork.ozlabs.org%2Fpatch%2F928678%2F&amp;data=02%7C01%7Chan.x
> u%40nx
> >
> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
> 9c5c3
> >
> 01635%7C0%7C0%7C636715621426190473&amp;sdata=xo2l3Ld3n9mkO5PTW
> 5DOqP7u0
> > %2Bgch0cXs7jEjHVokqQ%3D&amp;reserved=0
> >