From: Robin Gong <hidden> Date: 2020-06-30 05:24:37
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'.
v9:
1. add "spi: imx: add dma_sync_sg_for_device after fallback from dma"
to fix the potential issue brought by commit bcd8e7761ec9("spi: imx:
fallback to PIO if dma setup failure") which is the only one patch
of v8 merged. Thanks Matthias for reporting:
https://lore.kernel.org/linux-arm-kernel/5d246dd81607bb6e5cb9af86ad4e53f7a7a99c50.camel@ew.tq-group.com/
2. remove 05/13 of v8 "spi: imx:fallback to PIO if dma setup failure"
since it's been merged.
v10:
1. remove 01/13 "spi: imx: add dma_sync_sg_for_device after fallback from dma"
since there is another independent patch merged:
-- commit 809b1b04df898 ("spi: introduce fallback to pio")
2. add "dmaengine: dma: imx-sdma: add fw_loaded and is_ram_script" which
is used to fix the potential dma_alloc_coherent() failure while this
patchset applied but sdma firmware may not be ready for long time.
3. burst size change back from fifo size to normal wml to align with nxp
internal tree which has been test for years. Overnight with loopback
test with spidev failed with fifo size, but pass with wml(half of fifo
size).Seems the whole fifo size fed may cause rxfifo overflow during
tx shift out while rx shift in.
"spi: imx: remove ERR009165 workaround on i.mx6ul"
4. remove 12/13 'dmaengine: imx-sdma: fix ecspi1 rx dma not work on i.mx8mm'
since below two similar patches merged:
-- commit 25962e1a7f1d ("dmaengine: imx-sdma: Fix the event id check to
include RX event for UART6")
-- commit 2f57b8d57673 ("dmaengine: imx-sdma: Fix: Remove 'always true'
comparison")
Robin Gong (12):
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
dmaengine: dma: imx-sdma: add fw_loaded and is_ram_script
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: 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 | 63 ++++++++++++++++------
drivers/spi/spi-imx.c | 52 +++++++++++++++---
include/linux/platform_data/dma-imx-sdma.h | 8 ++-
7 files changed, 106 insertions(+), 29 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Robin Gong <hidden> Date: 2020-06-30 05:24:43
There are two ways for SDMA accessing SPBA devices: one is SDMA->AIPS
->SPBA(masterA port), another is SDMA->SPBA(masterC port). Please refer
to the 'Figure 58-1. i.MX 6Dual/6Quad SPBA connectivity' of i.mx6DQ
Reference Manual. SDMA provide the corresponding app_2_mcu/mcu_2_app and
shp_2_mcu/mcu_2_shp script for such two options. So both AIPS and SPBA
scripts should keep the same behaviour, the issue only caught in AIPS
script sounds not solide.
The issue is more likely as the ecspi errata
ERR009165(http://www.nxp.com/docs/en/errata/IMX6DQCE.pdf):
eCSPI: TXFIFO empty flag glitch can cause the current FIFO transfer to
be sent twice
So revert commit 'df07101e1c4a' firstly.
Signed-off-by: Robin Gong <redacted>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx6q.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Robin Gong <hidden> Date: 2020-06-30 05:24:48
There are two ways for SDMA accessing SPBA devices: one is SDMA->AIPS
->SPBA(masterA port), another is SDMA->SPBA(masterC port). Please refer
to the 'Figure 58-1. i.MX 6Dual/6Quad SPBA connectivity' of i.mx6DQ
Reference Manual. SDMA provide the corresponding app_2_mcu/mcu_2_app and
shp_2_mcu/mcu_2_shp script for such two options. So both AIPS and SPBA
scripts should keep the same behaviour, the issue only caught in AIPS
script sounds not solide.
The issue is more likely as the ecspi errata
ERR009165(http://www.nxp.com/docs/en/errata/IMX6DQCE.pdf):
eCSPI: TXFIFO empty flag glitch can cause the current FIFO transfer to
be sent twice
So revert commit 'dd4b487b32a3' firstly.
Signed-off-by: Robin Gong <redacted>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/boot/dts/imx6qdl.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
From: Robin Gong <hidden> Date: 2020-06-30 05:24:52
This reverts commit ad0d92d7ba6aecbe2705907c38ff8d8be4da1e9c, because
in spi-imx case, burst length may be changed dynamically.
Signed-off-by: Robin Gong <redacted>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/dma/imx-sdma.c | 8 --------
1 file changed, 8 deletions(-)
From: Robin Gong <hidden> Date: 2020-06-30 05:24:56
Since sdma_transfer_init() will do sdma_load_context before any
sdma transfer, no need once more in sdma_config_channel().
Signed-off-by: Robin Gong <redacted>
Acked-by: Vinod Koul <vkoul@kernel.org>
---
drivers/dma/imx-sdma.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
From: Robin Gong <hidden> Date: 2020-06-30 05:25:03
Add 'fw_loaded' and 'is_ram_script' to check if the script used by channel
is ram script and it's loaded or not, so that could prevent meaningless
following malloc dma descriptor and bd allocate in sdma_transfer_init(),
otherwise memory may be consumed out potentially without free in case
that spi fallback into pio while dma transfer failed by sdma firmware not
ready(next ERR009165 patch depends on sdma RAM scripts/firmware).
Signed-off-by: Robin Gong <redacted>
---
drivers/dma/imx-sdma.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
@@ -443,6 +444,7 @@ struct sdma_engine {structsdma_buffer_descriptor*bd0;/* clock ratio for AHB:SDMA core. 1:1 is 1, 2:1 is 0*/boolclk_ratio;+boolfw_loaded;};staticintsdma_config_write(structdma_chan*chan,
From: Robin Gong <hidden> Date: 2020-06-30 05:25:16
Change to XCH mode even in dma mode, please refer to the below
errata:
https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
Signed-off-by: Robin Gong <redacted>
Acked-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-imx.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
@@ -591,8 +591,8 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,ctrl|=mx51_ecspi_clkdiv(spi_imx,t->speed_hz,&clk);spi_imx->spi_bus_clk=clk;-if(spi_imx->usedma)-ctrl|=MX51_ECSPI_CTRL_SMC;+/* ERR009165: work in XHC mode as PIO */+ctrl&=~MX51_ECSPI_CTRL_SMC;writel(ctrl,spi_imx->base+MX51_ECSPI_CTRL);
@@ -1273,10 +1273,6 @@ static int spi_imx_sdma_init(struct device *dev, struct spi_imx_data *spi_imx,{intret;-/* use pio mode for i.mx6dl chip TKT238285 */-if(of_machine_is_compatible("fsl,imx6dl"))-return0;-spi_imx->wml=spi_imx->devtype_data->fifo_size/2;/* Prepare for TX DMA: */
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Robin Gong <hidden> Date: 2020-06-30 05:25:23
ERR009165 fixed on i.mx6ul/6ull/6sll. All other i.mx6/7 and
i.mx8m/8mm still need this errata. Please refer to nxp official
errata document from https://www.nxp.com/ .
For removing workaround on those chips. Add new i.mx6ul type.
Signed-off-by: Robin Gong <redacted>
Acked-by: Mark Brown <broonie@kernel.org>
---
drivers/spi/spi-imx.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 46 insertions(+), 4 deletions(-)
@@ -57,6 +57,7 @@ enum spi_imx_devtype {IMX35_CSPI,/* CSPI on all i.mx except above */IMX51_ECSPI,/* ECSPI on i.mx51 */IMX53_ECSPI,/* ECSPI on i.mx53 and later */+IMX6UL_ECSPI,/* ERR009165 fix from i.mx6ul */};structspi_imx_data;
@@ -132,6 +138,11 @@ static inline int is_imx51_ecspi(struct spi_imx_data *d)returnd->devtype_data->devtype==IMX51_ECSPI;}+staticinlineintis_imx6ul_ecspi(structspi_imx_data*d)+{+returnd->devtype_data->devtype==IMX6UL_ECSPI;+}+staticinlineintis_imx53_ecspi(structspi_imx_data*d){returnd->devtype_data->devtype==IMX53_ECSPI;
@@ -591,8 +602,14 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,ctrl|=mx51_ecspi_clkdiv(spi_imx,t->speed_hz,&clk);spi_imx->spi_bus_clk=clk;-/* ERR009165: work in XHC mode as PIO */-ctrl&=~MX51_ECSPI_CTRL_SMC;+/*+*ERR009165:workinXHCmodeinsteadofSMCasPIOonthechips+*beforei.mx6ul.+*/+if(spi_imx->usedma&&spi_imx->devtype_data->tx_glitch_fixed)+ctrl|=MX51_ECSPI_CTRL_SMC;+else+ctrl&=~MX51_ECSPI_CTRL_SMC;writel(ctrl,spi_imx->base+MX51_ECSPI_CTRL);
@@ -618,12 +635,16 @@ static int mx51_ecspi_prepare_transfer(struct spi_imx_data *spi_imx,staticvoidmx51_setup_wml(structspi_imx_data*spi_imx){+u32tx_wml=0;++if(spi_imx->devtype_data->tx_glitch_fixed)+tx_wml=spi_imx->wml;/**ConfiguretheDMAregister:setupthewatermark*andenableDMArequest.*/writel(MX51_ECSPI_DMA_RX_WML(spi_imx->wml-1)|-MX51_ECSPI_DMA_TX_WML(0)|+MX51_ECSPI_DMA_TX_WML(tx_wml)|MX51_ECSPI_DMA_RXT_WML(spi_imx->wml)|MX51_ECSPI_DMA_TEDEN|MX51_ECSPI_DMA_RXDEN|MX51_ECSPI_DMA_RXTDEN,spi_imx->base+MX51_ECSPI_DMA);
From: Robin Gong <hidden> Date: 2020-06-30 05:25:30
ERR009165 fixed from i.mx6ul, add its compatible name in binding doc.
Signed-off-by: Robin Gong <redacted>
Acked-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt | 1 +
1 file changed, 1 insertion(+)
@@ -10,6 +10,7 @@ Required properties: - "fsl,imx35-cspi" for SPI compatible with the one integrated on i.MX35 - "fsl,imx51-ecspi" for SPI compatible with the one integrated on i.MX51 - "fsl,imx53-ecspi" for SPI compatible with the one integrated on i.MX53 and later Soc+ - "fsl,imx6ul-ecspi" for SPI compatible with the one integrated on i.MX6UL and later Soc - "fsl,imx8mq-ecspi" for SPI compatible with the one integrated on i.MX8MQ - "fsl,imx8mm-ecspi" for SPI compatible with the one integrated on i.MX8MM - "fsl,imx8mn-ecspi" for SPI compatible with the one integrated on i.MX8MN
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Robin Gong <hidden> Date: 2020-06-30 05:25:35
ECSPI issue fixed from i.mx6ul at hardware level, no need
ERR009165 anymore on those chips such as i.mx8mq.
Signed-off-by: Robin Gong <redacted>
Acked-by: Vinod Koul <vkoul@kernel.org>
---
drivers/dma/imx-sdma.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
From: Robin Gong <hidden> Date: 2020-06-30 05:25:38
Add i.mx6ul compatible name in binding doc.
Signed-off-by: Robin Gong <redacted>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 1 +
1 file changed, 1 insertion(+)
From: Robin Gong <hidden> Date: 2020-06-30 05:25:45
For the compatibility of NXP internal legacy kernel before 4.19 which
is based on uart ram script and upstreaming kernel based on uart rom
script, add both uart ram/rom script in latest sdma firmware. By default
uart rom script used.
Besides, add two multi-fifo scripts for SAI/PDM on i.mx8m/8mm and add
back qspi script miss for v4(i.mx7d/8m/8mm family, but v3 is for i.mx6).
rom script:
uart_2_mcu_addr
uartsh_2_mcu_addr /* through spba bus */
am script:
uart_2_mcu_ram_addr
uartsh_2_mcu_ram_addr /* through spba bus */
Please get latest sdma firmware from the below and put them into the path
(/lib/firmware/imx/sdma/):
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
/tree/imx/sdma
Signed-off-by: Robin Gong <redacted>
Acked-by: Vinod Koul <vkoul@kernel.org>
---
drivers/dma/imx-sdma.c | 4 ++--
include/linux/platform_data/dma-imx-sdma.h | 8 ++++++--
2 files changed, 8 insertions(+), 4 deletions(-)
@@ -52,6 +52,10 @@ struct sdma_script_start_addrs {s32zcanfd_2_mcu_addr;s32zqspi_2_mcu_addr;s32mcu_2_ecspi_addr;+s32mcu_2_sai_addr;+s32sai_2_mcu_addr;+s32uart_2_mcu_addr;+s32uartsh_2_mcu_addr;/* End of v3 array */s32mcu_2_zqspi_addr;/* End of v4 array */
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Add 'fw_loaded' and 'is_ram_script' to check if the script used by channel
is ram script and it's loaded or not, so that could prevent meaningless
following malloc dma descriptor and bd allocate in sdma_transfer_init(),
otherwise memory may be consumed out potentially without free in case
that spi fallback into pio while dma transfer failed by sdma firmware not
ready(next ERR009165 patch depends on sdma RAM scripts/firmware).
Add 'fw_loaded' and 'is_ram_script' to check if the script used by channel
is ram script and it's loaded or not, so that could prevent meaningless
following malloc dma descriptor and bd allocate in sdma_transfer_init(),
otherwise memory may be consumed out potentially without free in case
that spi fallback into pio while dma transfer failed by sdma firmware not
ready(next ERR009165 patch depends on sdma RAM scripts/firmware).
Signed-off-by: Robin Gong <redacted>
Acked-By: Vinod Koul <vkoul@kernel.org>
---
drivers/dma/imx-sdma.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
@@ -443,6 +444,7 @@ struct sdma_engine {structsdma_buffer_descriptor*bd0;/* clock ratio for AHB:SDMA core. 1:1 is 1, 2:1 is 0*/boolclk_ratio;+boolfw_loaded;};staticintsdma_config_write(structdma_chan*chan,
I tried your v10 patches on next-20200722 with i.MX8MM and it mostly seems to work fine.
When I tried first, I had the imx-sdma driver compiled into the kernel, so it didn't load the firmware and fell back to the ROM scripts.
With this, SPI transactions work just fine, but I got the above error message printed continuously when sending data in SPI3 via spidev.
When I build imx-sdma as a module, the firmware is loaded correctly and everything works as expected.
Can you have a look at this and provide a fix?
Thanks,
Frieder
quoted hunk
+ desc = kzalloc((sizeof(*desc)), GFP_NOWAIT); if (!desc) goto err_out;
From: Robin Gong <hidden> Date: 2020-07-23 10:24:33
On 2020/07/23 17:04 Frieder Schrempf [off-list ref] wrote:
Hi Robin,
On 30.06.20 15:31, Robin Gong wrote:
quoted
Add 'fw_loaded' and 'is_ram_script' to check if the script used by
channel is ram script and it's loaded or not, so that could prevent
meaningless following malloc dma descriptor and bd allocate in
sdma_transfer_init(), otherwise memory may be consumed out potentially
without free in case that spi fallback into pio while dma transfer
failed by sdma firmware not ready(next ERR009165 patch depends on sdma
RAM scripts/firmware).
quoted
Signed-off-by: Robin Gong <redacted>
Acked-By: Vinod Koul <vkoul@kernel.org>
---
drivers/dma/imx-sdma.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index
@@ -443,6 +444,7 @@ struct sdma_engine {structsdma_buffer_descriptor*bd0;/* clock ratio for AHB:SDMA core. 1:1 is 1, 2:1 is 0*/boolclk_ratio;+boolfw_loaded;};staticintsdma_config_write(structdma_chan*chan,@@-929,6+931,7
{ struct sdma_desc *desc;+ if (!sdmac->sdma->fw_loaded && sdmac->is_ram_script) {+ dev_err(sdmac->sdma->dev, "sdma firmware not ready!\n");+ goto err_out;+ }
I tried your v10 patches on next-20200722 with i.MX8MM and it mostly
seems to work fine.
When I tried first, I had the imx-sdma driver compiled into the kernel, so it
didn't load the firmware and fell back to the ROM scripts.
With this, SPI transactions work just fine, but I got the above error message
printed continuously when sending data in SPI3 via spidev.
That's caused by you didn't load ram firmware as this patch set described.
Please follow below steps to load firmware manually if you don't want to
use NXP official Yocto release package:
1. 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
2. Load firmware manually:
echo 1 > /sys/$DEVPATH/loading
cat $MY_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data
echo 0 > /sys/$DEVPATH/loading
Please refer to Documentation/driver-api/firmware/fallback-mechanisms.rst
and load the firmware in 60s (firmware fallback loading timeout) from kernel
boot up.
When I build imx-sdma as a module, the firmware is loaded correctly and
everything works as expected.
I guess that's not related with sdma building as module. If sdma build as
module, spi will fall to pio mode at spi-imx driver probe phase so that the above
warning log never to be walked. Would you please add some debug info to double
confirm?
Can you have a look at this and provide a fix?
Thanks,
Frieder
From: Robin Gong <hidden> Date: 2020-07-23 11:12:40
On 2020/07/23 17:04 Frieder Schrempf [off-list ref]
wrote:
quoted
Hi Robin,
On 30.06.20 15:31, Robin Gong wrote:
quoted
Add 'fw_loaded' and 'is_ram_script' to check if the script used by
channel is ram script and it's loaded or not, so that could prevent
meaningless following malloc dma descriptor and bd allocate in
sdma_transfer_init(), otherwise memory may be consumed out
potentially without free in case that spi fallback into pio while
dma transfer failed by sdma firmware not ready(next ERR009165 patch
depends on sdma
RAM scripts/firmware).
quoted
Signed-off-by: Robin Gong <redacted>
Acked-By: Vinod Koul <vkoul@kernel.org>
---
drivers/dma/imx-sdma.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index
@@ -443,6 +444,7 @@ struct sdma_engine {structsdma_buffer_descriptor*bd0;/* clock ratio for AHB:SDMA core. 1:1 is 1, 2:1 is 0*/boolclk_ratio;+boolfw_loaded;};staticintsdma_config_write(structdma_chan*chan,@@-929,6+931,7@@staticvoidsdma_get_pc(structsdma_channel*sdmac,caseIMX_DMATYPE_SSI_DUAL:per_2_emi=sdma->script_addrs->ssish_2_mcu_addr;emi_2_per=sdma->script_addrs->mcu_2_ssish_addr;+sdmac->is_ram_script=true;break;caseIMX_DMATYPE_SSI_SP:caseIMX_DMATYPE_MMC:
{ struct sdma_desc *desc;+ if (!sdmac->sdma->fw_loaded && sdmac->is_ram_script) {+ dev_err(sdmac->sdma->dev, "sdma firmware not ready!\n");+ goto err_out;+ }
I tried your v10 patches on next-20200722 with i.MX8MM and it mostly
seems to work fine.
When I tried first, I had the imx-sdma driver compiled into the
kernel, so it didn't load the firmware and fell back to the ROM scripts.
With this, SPI transactions work just fine, but I got the above error
message printed continuously when sending data in SPI3 via spidev.
That's caused by you didn't load ram firmware as this patch set described.
Please follow below steps to load firmware manually if you don't want to use
NXP official Yocto release package:
1. 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/t
ree/imx/sdma
2. Load firmware manually:
echo 1 > /sys/$DEVPATH/loading
cat $MY_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data
echo 0 > /sys/$DEVPATH/loading
Please refer to Documentation/driver-api/firmware/fallback-mechanisms.rst
and load the firmware in 60s (firmware fallback loading timeout) from kernel
boot up.
quoted
When I build imx-sdma as a module, the firmware is loaded correctly
and everything works as expected.
I guess that's not related with sdma building as module. If sdma build as
module, spi will fall to pio mode at spi-imx driver probe phase so that the
above warning log never to be walked. Would you please add some debug
info to double confirm?
Hi Frider,
Please ignore this comment, since there is -EPROBE_DEFER checking
, so you load sdma firmware by building sdma driver as module instead of
the above comment I mentioned? The warning log comes out during spi
transfer start and sdma firmware loading done, but if sdma driver building as
module could ensure firmware loading done in sdma_driver_probe_phase->
spi_imx_probe_phase, which means sdma firmware loading has been ready
before spi transfer start, hence no such warning message.
But I am not sure if all client drivers except spi are in good shape to support
' CONFIG_IMX_SDMA=m '. Besides, do you think 'dev_err_once ' instead of 'dev_err' is okay for you?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 2020/07/23 17:04 Frieder Schrempf [off-list ref]
wrote:
quoted
Hi Robin,
On 30.06.20 15:31, Robin Gong wrote:
quoted
Add 'fw_loaded' and 'is_ram_script' to check if the script used by
channel is ram script and it's loaded or not, so that could prevent
meaningless following malloc dma descriptor and bd allocate in
sdma_transfer_init(), otherwise memory may be consumed out
potentially without free in case that spi fallback into pio while
dma transfer failed by sdma firmware not ready(next ERR009165 patch
depends on sdma
RAM scripts/firmware).
quoted
Signed-off-by: Robin Gong <redacted>
Acked-By: Vinod Koul <vkoul@kernel.org>
---
drivers/dma/imx-sdma.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index
@@ -443,6 +444,7 @@ struct sdma_engine {structsdma_buffer_descriptor*bd0;/* clock ratio for AHB:SDMA core. 1:1 is 1, 2:1 is 0*/boolclk_ratio;+boolfw_loaded;};staticintsdma_config_write(structdma_chan*chan,@@-929,6+931,7@@staticvoidsdma_get_pc(structsdma_channel*sdmac,caseIMX_DMATYPE_SSI_DUAL:per_2_emi=sdma->script_addrs->ssish_2_mcu_addr;emi_2_per=sdma->script_addrs->mcu_2_ssish_addr;+sdmac->is_ram_script=true;break;caseIMX_DMATYPE_SSI_SP:caseIMX_DMATYPE_MMC:
{ struct sdma_desc *desc;+ if (!sdmac->sdma->fw_loaded && sdmac->is_ram_script) {+ dev_err(sdmac->sdma->dev, "sdma firmware not ready!\n");+ goto err_out;+ }
I tried your v10 patches on next-20200722 with i.MX8MM and it mostly
seems to work fine.
When I tried first, I had the imx-sdma driver compiled into the
kernel, so it didn't load the firmware and fell back to the ROM scripts.
With this, SPI transactions work just fine, but I got the above error
message printed continuously when sending data in SPI3 via spidev.
When I build imx-sdma as a module, the firmware is loaded correctly
and everything works as expected.
I guess that's not related with sdma building as module. If sdma build as
module, spi will fall to pio mode at spi-imx driver probe phase so that the
above warning log never to be walked. Would you please add some debug
info to double confirm?
Hi Frider,
Please ignore this comment, since there is -EPROBE_DEFER checking
, so you load sdma firmware by building sdma driver as module instead of
the above comment I mentioned?
Yes, correct.
The warning log comes out during spi
transfer start and sdma firmware loading done, but if sdma driver building as
module could ensure firmware loading done in sdma_driver_probe_phase->
spi_imx_probe_phase, which means sdma firmware loading has been ready
before spi transfer start, hence no such warning message.
But I am not sure if all client drivers except spi are in good shape to support
' CONFIG_IMX_SDMA=m '.
I'm pretty sure that CONFIG_IMX_SDMA=m is supported and common. Otherwise it wouldn't be an option in Kconfig.
Besides, do you think 'dev_err_once ' instead of 'dev_err' is okay for you?
I can't really judge if this is a proper fix as I haven't looked at the code in detail, but if you want to use dev_err_once(), that would be ok for me, maybe even better dev_warn_once().
As chances are that even without firmware transfers will work a warning instead of an error makes more sense to me.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Robin Gong <hidden> Date: 2020-07-23 14:11:29
On 2020/07/23 19:52 Frieder Schrempf [off-list ref] wrote:
quoted
The warning log comes out during spi
transfer start and sdma firmware loading done, but if sdma driver
building as module could ensure firmware loading done in
sdma_driver_probe_phase-> spi_imx_probe_phase, which means sdma
firmware loading has been ready before spi transfer start, hence no such
warning message.
quoted
But I am not sure if all client drivers except spi are in good shape
to support ' CONFIG_IMX_SDMA=m '.
I'm pretty sure that CONFIG_IMX_SDMA=m is supported and common.
Otherwise it wouldn't be an option in Kconfig.
Sorry, I mean other drivers using sdma such as audio/uart..etc, I know
sdma driver support to build as module. But I'm not sure if there are some
potential issues here with changing to sdma module. For now, could we
just leave it for another patch whatever it's better solution or not?
quoted
Besides, do you think 'dev_err_once ' instead of 'dev_err' is okay for you?
I can't really judge if this is a proper fix as I haven't looked at the code in detail,
but if you want to use dev_err_once(), that would be ok for me, maybe even
better dev_warn_once().
As chances are that even without firmware transfers will work a warning
instead of an error makes more sense to me.
Okay, I'll change it in later version. Anyway, thanks for your test.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel