diff mbox series

[v10,05/12] dmaengine: dma: imx-sdma: add fw_loaded and is_ram_script

Message ID 1593523876-22387-6-git-send-email-yibin.gong@nxp.com (mailing list archive)
State New, archived
Headers show
Series add ecspi ERR009165 for i.mx6/7 soc family | expand

Commit Message

Robin Gong June 30, 2020, 1:31 p.m. UTC
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>
---
 drivers/dma/imx-sdma.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

Comments

Vinod Koul July 15, 2020, 5:57 a.m. UTC | #1
On 30-06-20, 21: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).

Acked-By: Vinod Koul <vkoul@kernel.org>
Frieder Schrempf July 23, 2020, 9:03 a.m. UTC | #2
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.

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

> +
>   	desc = kzalloc((sizeof(*desc)), GFP_NOWAIT);
>   	if (!desc)
>   		goto err_out;
> @@ -1589,6 +1598,8 @@ static int sdma_config_write(struct dma_chan *chan,
>   {
>   	struct sdma_channel *sdmac = to_sdma_chan(chan);
>   
> +	sdmac->is_ram_script = false;
> +
>   	if (direction == DMA_DEV_TO_MEM) {
>   		sdmac->per_address = dmaengine_cfg->src_addr;
>   		sdmac->watermark_level = dmaengine_cfg->src_maxburst *
> @@ -1768,6 +1779,8 @@ static void sdma_load_firmware(const struct firmware *fw, void *context)
>   
>   	sdma_add_scripts(sdma, addr);
>   
> +	sdma->fw_loaded = true;
> +
>   	dev_info(sdma->dev, "loaded firmware %d.%d\n",
>   			header->version_major,
>   			header->version_minor);
>
Robin Gong July 23, 2020, 10:24 a.m. UTC | #3
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://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
Robin Gong July 23, 2020, 11:12 a.m. UTC | #4
> 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://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.
> 
> >
> > 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?
Frieder Schrempf July 23, 2020, 11:51 a.m. UTC | #5
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&amp;data=02%7C01%7Cfrieder.schrempf%40kontron.de%7C08276b76f9a14dae1f8408d82ef94da1%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637310995564511410&amp;sdata=YA1455ILoNgRDHAOy1H2051J9cu5VsHk39xtQive8mo%3D&amp;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.
Robin Gong July 23, 2020, 2:11 p.m. UTC | #6
On 2020/07/23 19:52 Frieder Schrempf <frieder.schrempf@kontron.de> wrote:
> 
> > 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.
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?
> 
> > 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.
diff mbox series

Patch

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;
+	}
+
 	desc = kzalloc((sizeof(*desc)), GFP_NOWAIT);
 	if (!desc)
 		goto err_out;
@@ -1589,6 +1598,8 @@  static int sdma_config_write(struct dma_chan *chan,
 {
 	struct sdma_channel *sdmac = to_sdma_chan(chan);
 
+	sdmac->is_ram_script = false;
+
 	if (direction == DMA_DEV_TO_MEM) {
 		sdmac->per_address = dmaengine_cfg->src_addr;
 		sdmac->watermark_level = dmaengine_cfg->src_maxburst *
@@ -1768,6 +1779,8 @@  static void sdma_load_firmware(const struct firmware *fw, void *context)
 
 	sdma_add_scripts(sdma, addr);
 
+	sdma->fw_loaded = true;
+
 	dev_info(sdma->dev, "loaded firmware %d.%d\n",
 			header->version_major,
 			header->version_minor);