Re: Questions about the Freescale/NXP QuadSPI controller

Frieder Schrempf <frieder.schrempf@xxxxxxxxx> · Thu, 13 Sep 2018 09:00:47 +0200

Hi Han,

On 12.09.2018 23:04, Han Xu wrote:

-----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://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2femea01.safelinks.protection.outlook.com%2f%3furl%3dhttps%253A%252F%252Fsm&umid=aac77072-ee97-4b8a-b8b9-55765e276aec&auth=78a0452d0eda3018cc3487ba1bec995089e109a2-cefb4275e4aea35bf0c475f6bd6da9e9a8c877a0
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 ;)

Ok, on a closer look it is obvious that the reason is this commit [1]. 
My last test was before this change, when dummy.buswidth was still set 
to 1 even if dummy.n_bytes is 0.
Now both are 0 and I need to handle this in the FSL QSPI driver.

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.

Ok, great. Thanks for your test.

As Yogesh reported problems with his LS1088ARDB board, where both chips 
are connected to QSPIA, I was hoping someone could confirm this by 
testing on a similar setup.

So if you have a board around, that uses this setup, it would be great 
if you can try on that. If not we have to find other ways to investigate 
this.

Thanks,
Frieder

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=9882b5375df532acb2c2399a90d882461112e612

Thanks,
Frieder

[1]
https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2femea01.safelinks.protection.outlook.com%2f%3furl%3dhttp%253A%252F%252Fgit.f&umid=aac77072-ee97-4b8a-b8b9-55765e276aec&auth=78a0452d0eda3018cc3487ba1bec995089e109a2-54ce7888db3c2cb56ff686a840c4d0fa657a3cdb
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