Hi Frieder, Please find some more comments regarding the new spi-fsl-qspi.c driver. > Hi Lukasz, > > On 20.09.2018 17:00, Lukasz Majewski wrote: > > Hi Frieder, > > > >> Hi Frieder, > >> > >>> Hi Lukasz, > >>> > >>> On 19.09.2018 00:42, Lukasz Majewski wrote: > >>>> 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. > >>> > >>> The only setup with two chips that is known to be problematic with > >>> the new driver, is when both chips are connected to the same bus > >>> (e.g. QSPIA) using separate chip selects. > >> > >> I'm using QSPI0 controller, with two memories connected to QSPI0_A > >> and QSPI0_B lines. > >> > >>> > >>> Does your board use this kind of setup, or are the two chips > >>> connected two different buses (QSPIA and QSPIB)? > >>> > >>> Have you tested the new driver? It would be great to receive some > >>> more feedback. > >> > >> I will check (test) this new driver. No problem. > > > > I've ported your patch on v4.19-rc3. > > > > I had to fix the "div0 issue" by adding: > > if (op->dummy.buswidth && > > (op->dummy.nbytes * 8 / op->dummy.buswidth > 64)) > > > > In fsl_qspi_supports_op() function. > > > > > > Unfortunately, on Vybrid vf610 when testing I do see corruption of > > read data from the mtd device: > > > > ~# hexdump aaa.img > > 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e > > 0000010 e98e 5265 683c a635 c069 e402 303f d936 > > 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc > > 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff > > 0000040 ffff ffff ffff ffff ffff ffff ffff ffff > > * > > 0000100 > > > > ~# hexdump data_test.img > > 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e > > 0000010 e98e 5265 683c a635 c069 e402 303f d936 > > 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc > > 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff > > 0000040 01c9 462d 0a43 f893 0e42 67f1 57f0 787c > > 0000050 49c0 fb2a e514 e954 1d21 affa bac4 38f1 > > 0000060 1ca5 ec46 77eb a854 285b 8e21 12d7 f377 > > 0000070 b441 2baf ee33 596c 98b6 e71a c1cb 876c > > > > > > Test case: > > flash_erase /dev/mtd3 0 1 > > dd if=data_test.img of=/dev/mtd3 > > dd if=/dev/mtd3 of=aaa.img bs=1 count=256 > > > > > > From the code I see that the AHB buffer has 1024B. It is accessed > > in 8 bytes packs. > > > > This seems like some cache or HW issue.... > > > > In the old driver, to fix this problem one needed to > > 1. Reduce the RX fifo size from 128B to 64B > > > > 2. Disable (set to 0) the AHB transfer's BUF3CR ADATSZ field - the > > transfer size is the same as in LUT. > > > > (Original patch: https://patchwork.ozlabs.org/patch/675401/) > > Thanks a lot for doing the test. It seems like Vybrid needs some > special handling to work around this problem. > So this means the current driver has never worked for Vybrid, as the > mentioned patch was never merged!? > > As these issues seem to be specific to Vybrid and as they seem to > exist in the current driver too, I would like to fix them after we > have a first version of the new driver that works for the other > platforms. > > I hope we can figure out the other issues soon. > > Thanks, > Frieder > > > > > > >> > >>> > >>>> 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: > > ^^^^^^^^^^^^^^^^^^^^^^^^ - It would be handy to have the > > exact explanation of this issue. > > > >>>> https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671 ^^^^^^^^^^^^ - [1] I've looked a bit closer to the new spi-fsl-qspi.c driver and it looks like it uses fsl_qspi_exec_op() and then calls fsl_qspi_do_op(). In the last function we setup the QUADSPI_IPCR register to initiate the transfer between SPI-NOR and the internal RX buffer. Please correct me if I'm wrong but it seems to me like we are using "IP Command Read" approach here. If this is true - what was the rationale to use it in the new driver, as in the old one the "AHB Command Read" approach was recommended (i.e. faster) [1]? To be even more problematic the info in link [1] states that on vybrid there is a bug on the "IP Command Read" HW block and it should be avoided. > >>>> > >>>> I've googled for some errata or known issues for vybryd's QSPI IP > >>>> block (vf610) but without luck so far ... > >>> > >>> Unfortunately I don't know the background for this comment. > >> > >> The comment was added by some Freescale employee when the driver > >> was added to Linux (by Huang - CC'ed). > >> > >>> Is your > >>> board using VF610? > >> > >> Yes, it uses vf610 (A5 + M4 cores). > >> > >>> Do you experience problems? > >> > >> I've already observed following issue: > >> > >> For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only half > >> of the AHB buffer is valid. When I do read the whole one - I do see > >> read data corruption (on UBI or raw memory). > >> > >> This was pointed out in the patch: > >> https://patchwork.ozlabs.org/patch/675401/ > >> > >> Unfortunately, I did not found any info regarding this problem (in > >> NXP's errata or other doc). > >> > >> I will check if this issue shows up on new patches. > >> > >> Thanks in advance for your help. > >> > >>> > >>> Regards, > >>> Frieder > >>> > >>> ______________________________________________________ > >>> 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 > > > > > > > > > > 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 > > ______________________________________________________ > 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:
pgpXZgfz7yOYO.pgp
Description: OpenPGP digital signature
