RE: (EXT) [PATCH v8 00/13] add ecspi ERR009165 for i.mx6/7 soc family

[Robin Gong <yibin.gong@xxxxxxx>]

On 2020/06/03 Matthias Schiffer <matthias.schiffer@xxxxxxxxxxxxxxx> wrote:
 > On Thu, 2020-05-21 at 04:34 +0800, Robin Gong wrote:
> > There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO
> > transfer to be send twice in DMA mode. Please get more information
> > from:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> nxp.com%2Fdocs%2Fen%2Ferrata%2FIMX6DQCE.pdf&amp;data=02%7C01%7C
> yibin.g
> >
> ong%40nxp.com%7C4621358b9be04a79d2d508d80798835b%7C686ea1d3bc2b
> 4c6fa92
> >
> cd99c5c301635%7C0%7C1%7C637267698912634476&amp;sdata=hR66H1hP%
> 2Fqb6OXe
> > w9wpXizY8DiNfZZ1KLwu3Kty87jc%3D&amp;reserved=0. The workaround is
> > adding new sdma ram script which works in XCH  mode as PIO inside sdma
> > instead of SMC mode, meanwhile, 'TX_THRESHOLD' should be 0. The issue
> should be exist on all legacy i.mx6/7 soc family before i.mx6ul.
> > NXP fix this design issue from i.mx6ul, so newer chips including
> > i.mx6ul/ 6ull/6sll do not need this workaroud anymore. All other
> > i.mx6/7/8 chips still need this workaroud. This patch set add new
> > 'fsl,imx6ul-ecspi'
> > for ecspi driver and 'ecspi_fixed' in sdma driver to choose if need
> > errata or not.
> > The first two reverted patches should be the same issue, though, it
> > seems 'fixed' by changing to other shp script. Hope Sean or Sascha
> > could have the chance to test this patch set if could fix their
> > issues.
> > Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1 not work
> > on i.mx8mm because the event id is zero.
> >
> > PS:
> >    Please get sdma firmware from below linux-firmware and copy it to
> > your local rootfs /lib/firmware/imx/sdma.
> 
> 
> Hello Robin,
> 
> we have tried out this series, and there seems to be an issue with the
> PIO fallback. We are testing on an i.MX6Q board, and our kernel is a
> mostly-unmodified 5.4, on which we backported all SDMA patches from
> next-20200602 (imx-sdma.c is identical to next-20200602 version), and
> then applied this whole series.
> 
> We build the SDMA driver as a kernel module, which is loaded by udev,
> so the root filesystem is ready and the SDMA firmware can be loaded.
> The behaviour we're seeing is the following:
> 
> 1. As long as the SDMA driver is not loaded, initializing spi_imx will
> be deferred
> 2. imx_sdma is loaded. The SDMA firmware is not yet loaded at this
> point
> 3. spi_imx is initialized and an SPI-NOR flash is probed. To load the
> BFPT, the driver will attempt to use DMA; this will fail with EINVAL as
> long as the SDMA firmware is not ready, so the fallback to PIO happens
> (4. SDMA firmware is ready, subsequent SPI transfers use DMA)
> 
> The problem happens in step 3: Whenever the driver falls back to PIO,
> the received data is corrupt. The behaviour is specific to the
> fallback: When I disable DMA completely via spi_imx.use_dma, or when
> the timing is lucky and the SDMA firmware gets loaded before the flash
> is probed, no corruption can be observed.
Thanks Matthias, would you like post log?