Messages in this thread | | | Subject | Re: [PATCH v10 05/12] dmaengine: dma: imx-sdma: add fw_loaded and is_ram_script | From | Frieder Schrempf <> | Date | Thu, 23 Jul 2020 13:51:44 +0200 |
| |
On 23.07.20 13:12, Robin Gong wrote: >> On 2020/07/23 17:04 Frieder Schrempf <frieder.schrempf@kontron.de> >> wrote: >>> Hi Robin, >>> >>> On 30.06.20 15:31, Robin Gong wrote: >>>> 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 <yibin.gong@nxp.com> >>>> 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 >>>> 5411e01e..ce1c83e 100644 >>>> --- a/drivers/dma/imx-sdma.c >>>> +++ b/drivers/dma/imx-sdma.c >>>> @@ -379,6 +379,7 @@ struct sdma_channel { >>>> enum dma_status status; >>>> struct imx_dma_data data; >>>> struct work_struct terminate_worker; >>>> + bool is_ram_script; >>>> }; >>>> >>>> #define IMX_DMA_SG_LOOP BIT(0) >>>> @@ -443,6 +444,7 @@ struct sdma_engine { >>>> struct sdma_buffer_descriptor *bd0; >>>> /* clock ratio for AHB:SDMA core. 1:1 is 1, 2:1 is 0*/ >>>> bool clk_ratio; >>>> + bool fw_loaded; >>>> }; >>>> >>>> static int sdma_config_write(struct dma_chan *chan, @@ -929,6 >>>> +931,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac, >>>> case IMX_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; >>>> case IMX_DMATYPE_SSI_SP: >>>> case IMX_DMATYPE_MMC: >>>> @@ -943,6 +946,7 @@ static void sdma_get_pc(struct sdma_channel >>> *sdmac, >>>> per_2_emi = sdma->script_addrs->asrc_2_mcu_addr; >>>> emi_2_per = sdma->script_addrs->asrc_2_mcu_addr; >>>> per_2_per = sdma->script_addrs->per_2_per_addr; >>>> + sdmac->is_ram_script = true; >>>> break; >>>> case IMX_DMATYPE_ASRC_SP: >>>> per_2_emi = sdma->script_addrs->shp_2_mcu_addr; >>>> @@ -1339,6 +1343,11 @@ static struct sdma_desc >>> *sdma_transfer_init(struct sdma_channel *sdmac, >>>> { >>>> 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://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ffirmware%2Flinux-firmware.git%2Ft&data=02%7C01%7Cfrieder.schrempf%40kontron.de%7C08276b76f9a14dae1f8408d82ef94da1%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637310995564511410&sdata=YA1455ILoNgRDHAOy1H2051J9cu5VsHk39xtQive8mo%3D&reserved=0 >> 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. >> >>> >>> 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.
| |