mbox series

[v8,00/13] add ecspi ERR009165 for i.mx6/7 soc family

Message ID 1590006865-20900-1-git-send-email-yibin.gong@nxp.com
Headers show
Series add ecspi ERR009165 for i.mx6/7 soc family | expand

Message

Robin Gong May 20, 2020, 8:34 p.m. UTC
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://www.nxp.com/docs/en/errata/IMX6DQCE.pdf. 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.
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma

v2:
  1.Add commit log for reverted patches.
  2.Add comment for 'ecspi_fixed' in sdma driver.
  3.Add 'fsl,imx6sll-ecspi' compatible instead of 'fsl,imx6ul-ecspi'
    rather than remove.
v3:
  1.Confirm with design team make sure ERR009165 fixed on i.mx6ul/i.mx6ull
    /i.mx6sll, not fixed on i.mx8m/8mm and other i.mx6/7 legacy chips.
    Correct dts related dts patch in v2.
  2.Clean eratta information in binding doc and new 'tx_glitch_fixed' flag
    in spi-imx driver to state ERR009165 fixed or not.
  3.Enlarge burst size to fifo size for tx since tx_wml set to 0 in the
    errata workaroud, thus improve performance as possible.
v4:
  1.Add Ack tag from Mark and Vinod
  2.Remove checking 'event_id1' zero as 'event_id0'.
v5:
  1.Add the last patch for compatible with the current uart driver which
    using rom script, so both uart ram script and rom script supported
    in latest firmware, by default uart rom script used. UART driver
    will be broken without this patch.
v6:
  1.Resend after rebase the latest next branch.
  2.Remove below No.13~No.15 patches of v5 because they were mergered.
  	ARM: dts: imx6ul: add dma support on ecspi
  	ARM: dts: imx6sll: correct sdma compatible
  	arm64: defconfig: Enable SDMA on i.mx8mq/8mm
  3.Revert "dmaengine: imx-sdma: fix context cache" since
    'context_loaded' removed.
v7:
  1.Put the last patch 13/13 'Revert "dmaengine: imx-sdma: fix context
    cache"' to the ahead of 03/13 'Revert "dmaengine: imx-sdma: refine
    to load context only once" so that no building waring during comes out
    during bisect.
  2.Address Sascha's comments, including eliminating any i.mx6sx in this
    series, adding new 'is_imx6ul_ecspi()' instead imx in imx51 and taking
    care SMC bit for PIO.
  3.Add back missing 'Reviewed-by' tag on 08/15(v5):09/13(v7)
   'spi: imx: add new i.mx6ul compatible name in binding doc'
v8:
  1.remove 0003-Revert-dmaengine-imx-sdma-fix-context-cache.patch and merge
    it into 04/13 of v7
  2.add 0005-spi-imx-fallback-to-PIO-if-dma-setup-failure.patch for no any
    ecspi function broken even if sdma firmware not updated.
  3.merge 'tx.dst_maxburst' changes in the two continous patches into one
    patch to avoid confusion.
  4.fix typo 'duplicated'.

Robin Gong (13):
  Revert "ARM: dts: imx6q: Use correct SDMA script for SPI5 core"
  Revert "ARM: dts: imx6: Use correct SDMA script for SPI cores"
  Revert "dmaengine: imx-sdma: refine to load context only once"
  dmaengine: imx-sdma: remove duplicated sdma_load_context
  spi: imx: fallback to PIO if dma setup failure
  dmaengine: imx-sdma: add mcu_2_ecspi script
  spi: imx: fix ERR009165
  spi: imx: remove ERR009165 workaround on i.mx6ul
  spi: imx: add new i.mx6ul compatible name in binding doc
  dmaengine: imx-sdma: remove ERR009165 on i.mx6ul
  dma: imx-sdma: add i.mx6ul compatible name
  dmaengine: imx-sdma: fix ecspi1 rx dma not work on i.mx8mm
  dmaengine: imx-sdma: add uart rom script

 .../devicetree/bindings/dma/fsl-imx-sdma.txt       |  1 +
 .../devicetree/bindings/spi/fsl-imx-cspi.txt       |  1 +
 arch/arm/boot/dts/imx6q.dtsi                       |  2 +-
 arch/arm/boot/dts/imx6qdl.dtsi                     |  8 +-
 drivers/dma/imx-sdma.c                             | 67 ++++++++++------
 drivers/spi/spi-imx.c                              | 92 +++++++++++++++++++---
 include/linux/platform_data/dma-imx-sdma.h         |  8 +-
 7 files changed, 135 insertions(+), 44 deletions(-)

Comments

Sascha Hauer May 27, 2020, 5:03 a.m. UTC | #1
On Thu, May 21, 2020 at 04:34:12AM +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://www.nxp.com/docs/en/errata/IMX6DQCE.pdf. 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.

For the series:

Acked-by: Sascha Hauer <s.hauer@pengutronix.de>

Sascha
Mark Brown May 28, 2020, 1:07 p.m. UTC | #2
On Thu, 21 May 2020 04:34:12 +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://www.nxp.com/docs/en/errata/IMX6DQCE.pdf. 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.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: imx: fallback to PIO if dma setup failure
      commit: bcd8e7761ec9c128b9102b0833d9c7052ae2dbcf

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark
Matthias Schiffer June 3, 2020, 8:31 a.m. UTC | #3
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://www.nxp.com/docs/en/errata/IMX6DQCE.pdf. 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.

Kind regards,
Matthias



> 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/imx/sdma
> 
> v2:
>   1.Add commit log for reverted patches.
>   2.Add comment for 'ecspi_fixed' in sdma driver.
>   3.Add 'fsl,imx6sll-ecspi' compatible instead of 'fsl,imx6ul-ecspi'
>     rather than remove.
> v3:
>   1.Confirm with design team make sure ERR009165 fixed on
> i.mx6ul/i.mx6ull
>     /i.mx6sll, not fixed on i.mx8m/8mm and other i.mx6/7 legacy
> chips.
>     Correct dts related dts patch in v2.
>   2.Clean eratta information in binding doc and new 'tx_glitch_fixed'
> flag
>     in spi-imx driver to state ERR009165 fixed or not.
>   3.Enlarge burst size to fifo size for tx since tx_wml set to 0 in
> the
>     errata workaroud, thus improve performance as possible.
> v4:
>   1.Add Ack tag from Mark and Vinod
>   2.Remove checking 'event_id1' zero as 'event_id0'.
> v5:
>   1.Add the last patch for compatible with the current uart driver
> which
>     using rom script, so both uart ram script and rom script
> supported
>     in latest firmware, by default uart rom script used. UART driver
>     will be broken without this patch.
> v6:
>   1.Resend after rebase the latest next branch.
>   2.Remove below No.13~No.15 patches of v5 because they were
> mergered.
>   	ARM: dts: imx6ul: add dma support on ecspi
>   	ARM: dts: imx6sll: correct sdma compatible
>   	arm64: defconfig: Enable SDMA on i.mx8mq/8mm
>   3.Revert "dmaengine: imx-sdma: fix context cache" since
>     'context_loaded' removed.
> v7:
>   1.Put the last patch 13/13 'Revert "dmaengine: imx-sdma: fix
> context
>     cache"' to the ahead of 03/13 'Revert "dmaengine: imx-sdma:
> refine
>     to load context only once" so that no building waring during
> comes out
>     during bisect.
>   2.Address Sascha's comments, including eliminating any i.mx6sx in
> this
>     series, adding new 'is_imx6ul_ecspi()' instead imx in imx51 and
> taking
>     care SMC bit for PIO.
>   3.Add back missing 'Reviewed-by' tag on 08/15(v5):09/13(v7)
>    'spi: imx: add new i.mx6ul compatible name in binding doc'
> v8:
>   1.remove 0003-Revert-dmaengine-imx-sdma-fix-context-cache.patch and
> merge
>     it into 04/13 of v7
>   2.add 0005-spi-imx-fallback-to-PIO-if-dma-setup-failure.patch for
> no any
>     ecspi function broken even if sdma firmware not updated.
>   3.merge 'tx.dst_maxburst' changes in the two continous patches into
> one
>     patch to avoid confusion.
>   4.fix typo 'duplicated'.
> 
> Robin Gong (13):
>   Revert "ARM: dts: imx6q: Use correct SDMA script for SPI5 core"
>   Revert "ARM: dts: imx6: Use correct SDMA script for SPI cores"
>   Revert "dmaengine: imx-sdma: refine to load context only once"
>   dmaengine: imx-sdma: remove duplicated sdma_load_context
>   spi: imx: fallback to PIO if dma setup failure
>   dmaengine: imx-sdma: add mcu_2_ecspi script
>   spi: imx: fix ERR009165
>   spi: imx: remove ERR009165 workaround on i.mx6ul
>   spi: imx: add new i.mx6ul compatible name in binding doc
>   dmaengine: imx-sdma: remove ERR009165 on i.mx6ul
>   dma: imx-sdma: add i.mx6ul compatible name
>   dmaengine: imx-sdma: fix ecspi1 rx dma not work on i.mx8mm
>   dmaengine: imx-sdma: add uart rom script
> 
>  .../devicetree/bindings/dma/fsl-imx-sdma.txt       |  1 +
>  .../devicetree/bindings/spi/fsl-imx-cspi.txt       |  1 +
>  arch/arm/boot/dts/imx6q.dtsi                       |  2 +-
>  arch/arm/boot/dts/imx6qdl.dtsi                     |  8 +-
>  drivers/dma/imx-sdma.c                             | 67 ++++++++++
> ------
>  drivers/spi/spi-imx.c                              | 92
> +++++++++++++++++++---
>  include/linux/platform_data/dma-imx-sdma.h         |  8 +-
>  7 files changed, 135 insertions(+), 44 deletions(-)
>
Robin Gong June 3, 2020, 9:50 a.m. UTC | #4
On 2020/06/03 Matthias Schiffer <matthias.schiffer@ew.tq-group.com> 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?
Robin Gong June 5, 2020, 2:45 a.m. UTC | #5
On 2020/06/03 Matthias Schiffer <matthias.schiffer@ew.tq-group.com> wrote:
> On Wed, 2020-06-03 at 09:50 +0000, Robin Gong wrote:
> > On 2020/06/03 Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> > 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?
> >
> 
> I have attached the following log files:
> - pio.log: DMA disabled via module parameter
> - dma.log: "lucky" timing, SDMA firmware loaded before SPI-NOR probe
> - fallback.log: DMA->PIO fallback
> 
> The logs include some additional log messages:
> - Return value of spi_imx_dma_transfer() before PIO fallback
> - SPI-NOR SFPT dump
> 
> It can be seen that the BFPT data is identical in pio.log and dma.log,
> and differs almost completely in fallback.log. The corrupted data seems
> to be random, or uninitialized memory; it differs with every boot.
Would you please have a try with the attached patch? Thanks.
Matthias Schiffer June 5, 2020, 7:57 a.m. UTC | #6
On Fri, 2020-06-05 at 02:45 +0000, Robin Gong wrote:
> On 2020/06/03 Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> wrote:
> > On Wed, 2020-06-03 at 09:50 +0000, Robin Gong wrote:
> > > On 2020/06/03 Matthias Schiffer <
> > > matthias.schiffer@ew.tq-group.com>
> > > 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?
> > > 
> > 
> > I have attached the following log files:
> > - pio.log: DMA disabled via module parameter
> > - dma.log: "lucky" timing, SDMA firmware loaded before SPI-NOR
> > probe
> > - fallback.log: DMA->PIO fallback
> > 
> > The logs include some additional log messages:
> > - Return value of spi_imx_dma_transfer() before PIO fallback
> > - SPI-NOR SFPT dump
> > 
> > It can be seen that the BFPT data is identical in pio.log and
> > dma.log,
> > and differs almost completely in fallback.log. The corrupted data
> > seems
> > to be random, or uninitialized memory; it differs with every boot.
> 
> Would you please have a try with the attached patch? Thanks.


Thank you, this fixes the issue we're seeing.

Kind regards,
Matthias