Dear All, Maybe I do jump a bit off topic here, but... I've read through the following thread: https://patchwork.ozlabs.org/patch/939885/ And it mentions some issues with reading AHB content (buffers) in fsl-quadspi.c driver discovered when new QuadSPI driver was developed. I do have a setup with qspi0 having two SPI memories connected (2x16 MiB), and I'm wondering if anybody has some more info regarding: (What's more is that there is a bug in * the "IP Command Read" in the Vybrid.) found here: https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671 I've googled for some errata or known issues for vybryd's QSPI IP block (vf610) but without luck so far ... Thanks in advance, > 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&data=02%7C01%7Chan.x > >> u%40 > >>>> > >> nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d3bc2b4c6fa92c > >> d99c > >>>> > >> 5c301635%7C0%7C0%7C636723744426896223&sdata=Y32I9H9adPn%2Bn > >> lcICuV > >>>> M8Uoozsig%2BM3F0rNAhkIF5ZE%3D&reserved=0 > >>>>>> > >>>> > >> tchwork.ozlabs.org%2Fpatch%2F503655%2F&data=02%7C01%7Chan.xu > >>>> %40nx > >>>>>> > >>>> > >> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9 > >>>> 9c5c > >>>>>> > >>>> > >> 301635%7C0%7C0%7C636715621426190473&sdata=XWPfWe%2Fu2ePW > >>>> mNPe179D0 > >>>>>> vjTp6eLp0%2FJRF2vRayDwug%3D&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&data=02%7C01% > >> 7Chan.xu%40nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d > >> 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636723744426896223&sdata > >> =038DdgMLjO23Io3CTHoSVrJL2Ho%2BgxyHlx9%2BLMrLWkQ%3D&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 > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@xxxxxxx
Attachment:
pgpqClqCQ8be5.pgp
Description: OpenPGP digital signature
