[PATCH RESEND] dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree

[PATCH RESEND] dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree

[Vishnu Santhosh]

The driver hardcodes IRQF_TRIGGER_HIGH when registering the BAM
interrupt, which overrides the trigger type specified in the device
tree. On Qualcomm Shikra SoC, the A2 BAM signals an edge interrupt
to the apps processor; registering it as level-high causes the
interrupt to not fire, resulting in missed DMA completions.

Use IRQF_TRIGGER_NONE instead, which causes the kernel to use the
trigger type already configured by platform_get_irq() when it parsed
the device tree interrupts property. This makes the driver
platform-agnostic.

Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
---
 drivers/dma/qcom/bam_dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index 19116295f8325767a0d97a7848077885b118241c..6c3e2ca8a572fd04c925de0adbd5cc0616b361ef 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -1303,7 +1303,7 @@ static int bam_dma_probe(struct platform_device *pdev)
 		bam_channel_init(bdev, &bdev->channels[i], i);
 
 	ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
-			IRQF_TRIGGER_HIGH, "bam_dma", bdev);
+			IRQF_TRIGGER_NONE, "bam_dma", bdev);
 	if (ret)
 		goto err_bam_channel_exit;
 

---
base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
change-id: 20260601-qcom-bam-dma-irq-trigger-0366e7e86f17

Best regards,
-- 
Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>

Re: [PATCH RESEND] dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

Pre-existing issues:
- [High] Unclocked MMIO accesses cause system crash (synchronous external abort).
- [High] Error path devres race conditions cause Use-After-Free and system crashes.
- [High] Missing `pm_runtime_put_noidle()` leaks device usage counter on error paths.
- [High] Requesting IRQ before enabling PM runtime can cause an interrupt storm and CPU hang.
--

--- Patch [1]: [PATCH RESEND] dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree ---
commit ddb45d4f1215300c79f379d22aecb598266fe011
Author: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>

dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree

The driver hardcodes IRQF_TRIGGER_HIGH when registering the BAM
interrupt, which overrides the trigger type specified in the device
tree. This patch uses IRQF_TRIGGER_NONE instead, which allows the kernel
to use the trigger type already configured by platform_get_irq().

> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 19116295f8325..6c3e2ca8a572f 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -1303,7 +1303,7 @@ static int bam_dma_probe(struct platform_device *pdev)
>  		bam_channel_init(bdev, &bdev->channels[i], i);
>  
>  	ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
> -			IRQF_TRIGGER_HIGH, "bam_dma", bdev);
> +			IRQF_TRIGGER_NONE, "bam_dma", bdev);

[Severity: High]
This is a pre-existing issue, but does requesting the IRQ here before enabling
PM runtime risk an interrupt storm and CPU hang?

Since devm_request_irq() is called before pm_runtime_enable(), if an
interrupt fires immediately, bam_dma_irq() handles it. However, because PM
runtime is disabled, pm_runtime_get_sync() returns -EACCES.

The handler then returns IRQ_NONE without clearing the BAM interrupt status:

drivers/dma/qcom/bam_dma.c:bam_dma_irq() {
...
	ret = pm_runtime_get_sync(bdev->dev);
	if (ret < 0)
		return IRQ_NONE;
...
}

For level-triggered interrupts, wouldn't this leave the line asserted and
cause an interrupt storm?

[Severity: High]
This isn't a bug introduced by this patch, but does relying on devres to free
the IRQ create a race condition on error paths?

If a failure occurs after this devm_request_irq() call, the error path
manual teardown leaves a window where the IRQ is still active:

drivers/dma/qcom/bam_dma.c:bam_dma_probe() {
...
err_tasklet_kill:
	tasklet_kill(&bdev->task);
err_disable_clk:
	clk_disable_unprepare(bdev->bamclk);

	return ret;
}

If an interrupt fires during this window before devres frees the IRQ,
bam_dma_irq() runs. It could either access unclocked MMIO or call
tasklet_schedule().

Does this mean the scheduled tasklet remains pending while devres frees bdev,
leading to a use-after-free when the tasklet executes?

[Severity: High]
This is a pre-existing issue, but do unclocked MMIO accesses cause system
crashes (synchronous external aborts)?

In bam_dma_irq(), process_channel_irqs() is called unconditionally before
pm_runtime_get_sync():

drivers/dma/qcom/bam_dma.c:bam_dma_irq() {
...
	srcs |= process_channel_irqs(bdev);

	ret = pm_runtime_get_sync(bdev->dev);
...
}

If a spurious interrupt fires while the device is runtime-suspended, it reads
registers without a clock.

Similarly, in bam_dma_remove():

drivers/dma/qcom/bam_dma.c:bam_dma_remove() {
...
	pm_runtime_force_suspend(&pdev->dev);
...
	writel_relaxed(0, bam_addr(bdev, 0,  BAM_IRQ_SRCS_MSK_EE));
...
}

Does writing to BAM_IRQ_SRCS_MSK_EE immediately after forcing the device
into suspend (which disables its clock) deterministically crash the system?

[Severity: High]
This isn't a bug introduced by this patch, but does the error path in PM
runtime handling leak the device usage counter?

If pm_runtime_get_sync() fails, it increments the usage counter but the
driver returns directly without dropping the reference:

drivers/dma/qcom/bam_dma.c:bam_pause() {
...
	ret = pm_runtime_get_sync(bdev->dev);
	if (ret < 0)
		return ret;
...
}

This missing pm_runtime_put_noidle() on failure appears across multiple
functions, including bam_start_dma(), bam_free_chan(), bam_pause(),
bam_resume(), and bam_dma_irq().

Can this cause the device to permanently fail to enter runtime suspend?

>  	if (ret)
>  		goto err_bam_channel_exit;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-qcom-bam-dma-irq-trigger-v1-1-6405eac86f00@oss.qualcomm.com?part=1

Re: [PATCH RESEND] dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree

[Vishnu Santhosh]

On 17-07-2026 10:30 am, Vishnu Santhosh wrote:
> The driver hardcodes IRQF_TRIGGER_HIGH when registering the BAM
> interrupt, which overrides the trigger type specified in the device
> tree. On Qualcomm Shikra SoC, the A2 BAM signals an edge interrupt
> to the apps processor; registering it as level-high causes the
> interrupt to not fire, resulting in missed DMA completions.
>
> Use IRQF_TRIGGER_NONE instead, which causes the kernel to use the
> trigger type already configured by platform_get_irq() when it parsed
> the device tree interrupts property. This makes the driver
> platform-agnostic.
>
> Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
> Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
> ---
>   drivers/dma/qcom/bam_dma.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 19116295f8325767a0d97a7848077885b118241c..6c3e2ca8a572fd04c925de0adbd5cc0616b361ef 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -1303,7 +1303,7 @@ static int bam_dma_probe(struct platform_device *pdev)
>   		bam_channel_init(bdev, &bdev->channels[i], i);
>   
>   	ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
> -			IRQF_TRIGGER_HIGH, "bam_dma", bdev);
> +			IRQF_TRIGGER_NONE, "bam_dma", bdev);
>   	if (ret)
>   		goto err_bam_channel_exit;
>   
>
> ---
> base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
> change-id: 20260601-qcom-bam-dma-irq-trigger-0366e7e86f17
>
> Best regards,

Gentle ping on this patch. Could you please review it and let me know if
there are any concerns with the approach?


Thanks,
Vishnu

Re: [PATCH RESEND] dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree

[Frank Li]

On Fri, Jul 17, 2026 at 10:30:28AM +0530, Vishnu Santhosh wrote:
> The driver hardcodes IRQF_TRIGGER_HIGH when registering the BAM
> interrupt, which overrides the trigger type specified in the device
> tree. On Qualcomm Shikra SoC, the A2 BAM signals an edge interrupt
> to the apps processor; registering it as level-high causes the
> interrupt to not fire, resulting in missed DMA completions.
>
> Use IRQF_TRIGGER_NONE instead, which causes the kernel to use the
> trigger type already configured by platform_get_irq() when it parsed
> the device tree interrupts property. This makes the driver
> platform-agnostic.

where show this? can you point me doc or code?

Frank

>
> Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
> Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
> ---
>  drivers/dma/qcom/bam_dma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 19116295f8325767a0d97a7848077885b118241c..6c3e2ca8a572fd04c925de0adbd5cc0616b361ef 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -1303,7 +1303,7 @@ static int bam_dma_probe(struct platform_device *pdev)
>  		bam_channel_init(bdev, &bdev->channels[i], i);
>
>  	ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
> -			IRQF_TRIGGER_HIGH, "bam_dma", bdev);
> +			IRQF_TRIGGER_NONE, "bam_dma", bdev);
>  	if (ret)
>  		goto err_bam_channel_exit;
>
>
> ---
> base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
> change-id: 20260601-qcom-bam-dma-irq-trigger-0366e7e86f17
>
> Best regards,
> --
> Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
>

Re: [PATCH RESEND] dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree

[Vishnu Santhosh]

On 15-09-2026 07:36 pm, Frank Li wrote:
> On Fri, Jul 17, 2026 at 10:30:28AM +0530, Vishnu Santhosh wrote:
>> The driver hardcodes IRQF_TRIGGER_HIGH when registering the BAM
>> interrupt, which overrides the trigger type specified in the device
>> tree. On Qualcomm Shikra SoC, the A2 BAM signals an edge interrupt
>> to the apps processor; registering it as level-high causes the
>> interrupt to not fire, resulting in missed DMA completions.
>>
>> Use IRQF_TRIGGER_NONE instead, which causes the kernel to use the
>> trigger type already configured by platform_get_irq() when it parsed
>> the device tree interrupts property. This makes the driver
>> platform-agnostic.
> where show this? can you point me doc or code?
>
> Frank

Hi Frank,

The BAM driver obtains the IRQ through platform_get_irq():

bdev->irq = platform_get_irq(pdev, 0);

in https://elixir.bootlin.com/linux/v7.3-rc3/source/drivers/dma/qcom/bam_dma.c#L1270

It then registers the same IRQ with:

ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
                          IRQF_TRIGGER_HIGH, "bam_dma", bdev);

in https://elixir.bootlin.com/linux/v7.3-rc3/source/drivers/dma/qcom/bam_dma.c#L1335

The comment above IRQF_TRIGGER_NONE in include/linux/interrupt.h
states that when no trigger flag is specified, the interrupt uses the trigger type already
configured by the machine or firmware.

https://elixir.bootlin.com/linux/v7.3-rc3/source/include/linux/interrupt.h#L25

Therefore, IRQF_TRIGGER_HIGH overrides the trigger type associated with the IRQ during
DT/IRQ-domain mapping, while IRQF_TRIGGER_NONE preserves it.

The Shikra DTS which is still under review describes the BAM interrupt as edge-triggered:

interrupts = <GIC_SPI 74 IRQ_TYPE_EDGE_RISING 0>;

This driver change is needed so that the DT-specified trigger type remains effective once
the Shikra DTS change is accepted.


Thanks,
Vishnu


>
>> Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
>> Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
>> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
>> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
>> ---
>>   drivers/dma/qcom/bam_dma.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
>> index 19116295f8325767a0d97a7848077885b118241c..6c3e2ca8a572fd04c925de0adbd5cc0616b361ef 100644
>> --- a/drivers/dma/qcom/bam_dma.c
>> +++ b/drivers/dma/qcom/bam_dma.c
>> @@ -1303,7 +1303,7 @@ static int bam_dma_probe(struct platform_device *pdev)
>>   		bam_channel_init(bdev, &bdev->channels[i], i);
>>
>>   	ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
>> -			IRQF_TRIGGER_HIGH, "bam_dma", bdev);
>> +			IRQF_TRIGGER_NONE, "bam_dma", bdev);
>>   	if (ret)
>>   		goto err_bam_channel_exit;
>>
>>
>> ---
>> base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
>> change-id: 20260601-qcom-bam-dma-irq-trigger-0366e7e86f17
>>
>> Best regards,
>> --
>> Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
>>

Re: [PATCH RESEND] dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree

[Vishnu Santhosh]

Hi Frank,

On 16-09-2026 08:30 pm, Vishnu Santhosh wrote:
>
> On 15-09-2026 07:36 pm, Frank Li wrote:
>> On Fri, Jul 17, 2026 at 10:30:28AM +0530, Vishnu Santhosh wrote:
>>> The driver hardcodes IRQF_TRIGGER_HIGH when registering the BAM
>>> interrupt, which overrides the trigger type specified in the device
>>> tree. On Qualcomm Shikra SoC, the A2 BAM signals an edge interrupt
>>> to the apps processor; registering it as level-high causes the
>>> interrupt to not fire, resulting in missed DMA completions.
>>>
>>> Use IRQF_TRIGGER_NONE instead, which causes the kernel to use the
>>> trigger type already configured by platform_get_irq() when it parsed
>>> the device tree interrupts property. This makes the driver
>>> platform-agnostic.
>> where show this? can you point me doc or code?
>>
>> Frank
>
> Hi Frank,
>
> The BAM driver obtains the IRQ through platform_get_irq():
>
> bdev->irq = platform_get_irq(pdev, 0);
>
> in 
> https://elixir.bootlin.com/linux/v7.3-rc3/source/drivers/dma/qcom/bam_dma.c#L1270
>
> It then registers the same IRQ with:
>
> ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
>                          IRQF_TRIGGER_HIGH, "bam_dma", bdev);
>
> in 
> https://elixir.bootlin.com/linux/v7.3-rc3/source/drivers/dma/qcom/bam_dma.c#L1335
>
> The comment above IRQF_TRIGGER_NONE in include/linux/interrupt.h
> states that when no trigger flag is specified, the interrupt uses the 
> trigger type already
> configured by the machine or firmware.
>
> https://elixir.bootlin.com/linux/v7.3-rc3/source/include/linux/interrupt.h#L25 
>
>
> Therefore, IRQF_TRIGGER_HIGH overrides the trigger type associated 
> with the IRQ during
> DT/IRQ-domain mapping, while IRQF_TRIGGER_NONE preserves it.
>
> The Shikra DTS which is still under review describes the BAM interrupt 
> as edge-triggered:
>
> interrupts = <GIC_SPI 74 IRQ_TYPE_EDGE_RISING 0>;
>
> This driver change is needed so that the DT-specified trigger type 
> remains effective once
> the Shikra DTS change is accepted.
>
>
> Thanks,
> Vishnu
>
Gentle ping on this patch. Please let me know if any other information to be shared
from my side.


Thanks,
Vishnu

>
>>
>>> Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
>>> Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
>>> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
>>> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
>>> ---
>>>   drivers/dma/qcom/bam_dma.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
>>> index 
>>> 19116295f8325767a0d97a7848077885b118241c..6c3e2ca8a572fd04c925de0adbd5cc0616b361ef 
>>> 100644
>>> --- a/drivers/dma/qcom/bam_dma.c
>>> +++ b/drivers/dma/qcom/bam_dma.c
>>> @@ -1303,7 +1303,7 @@ static int bam_dma_probe(struct 
>>> platform_device *pdev)
>>>           bam_channel_init(bdev, &bdev->channels[i], i);
>>>
>>>       ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
>>> -            IRQF_TRIGGER_HIGH, "bam_dma", bdev);
>>> +            IRQF_TRIGGER_NONE, "bam_dma", bdev);
>>>       if (ret)
>>>           goto err_bam_channel_exit;
>>>
>>>
>>> ---
>>> base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
>>> change-id: 20260601-qcom-bam-dma-irq-trigger-0366e7e86f17
>>>
>>> Best regards,
>>> -- 
>>> Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
>>>

Re: [PATCH RESEND] dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree

[Frank Li]

On Mon, Sep 28, 2026 at 02:38:14PM +0530, Vishnu Santhosh wrote:
> Hi Frank,
>
> On 16-09-2026 08:30 pm, Vishnu Santhosh wrote:
> >
> > On 15-09-2026 07:36 pm, Frank Li wrote:
> > > On Fri, Jul 17, 2026 at 10:30:28AM +0530, Vishnu Santhosh wrote:
> > > > The driver hardcodes IRQF_TRIGGER_HIGH when registering the BAM
> > > > interrupt, which overrides the trigger type specified in the device
> > > > tree. On Qualcomm Shikra SoC, the A2 BAM signals an edge interrupt
> > > > to the apps processor; registering it as level-high causes the
> > > > interrupt to not fire, resulting in missed DMA completions.
> > > >
> > > > Use IRQF_TRIGGER_NONE instead, which causes the kernel to use the
> > > > trigger type already configured by platform_get_irq() when it parsed
> > > > the device tree interrupts property. This makes the driver
> > > > platform-agnostic.
> > > where show this? can you point me doc or code?
> > >
> > > Frank
> >
> > Hi Frank,
> >
> > The BAM driver obtains the IRQ through platform_get_irq():
> >
> > bdev->irq = platform_get_irq(pdev, 0);
> >
> > in https://elixir.bootlin.com/linux/v7.3-rc3/source/drivers/dma/qcom/bam_dma.c#L1270
> >
> > It then registers the same IRQ with:
> >
> > ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
> >                          IRQF_TRIGGER_HIGH, "bam_dma", bdev);
> >
> > in https://elixir.bootlin.com/linux/v7.3-rc3/source/drivers/dma/qcom/bam_dma.c#L1335
> >
> > The comment above IRQF_TRIGGER_NONE in include/linux/interrupt.h
> > states that when no trigger flag is specified, the interrupt uses the
> > trigger type already
> > configured by the machine or firmware.
> >
> > https://elixir.bootlin.com/linux/v7.3-rc3/source/include/linux/interrupt.h#L25

Thank you provide it. Kernel doc or comments may miss match actually code
Do you know where exactly handle IRQF_TRIGGER_NONE as what doc said?

Frank

> >
> >
> > Therefore, IRQF_TRIGGER_HIGH overrides the trigger type associated with
> > the IRQ during
> > DT/IRQ-domain mapping, while IRQF_TRIGGER_NONE preserves it.
> >
> > The Shikra DTS which is still under review describes the BAM interrupt
> > as edge-triggered:
> >
> > interrupts = <GIC_SPI 74 IRQ_TYPE_EDGE_RISING 0>;
> >
> > This driver change is needed so that the DT-specified trigger type
> > remains effective once
> > the Shikra DTS change is accepted.
> >
> >
> > Thanks,
> > Vishnu
> >
> Gentle ping on this patch. Please let me know if any other information to be shared
> from my side.
>
>
> Thanks,
> Vishnu
>
> >
> > >
> > > > Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
> > > > Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
> > > > Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
> > > > Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
> > > > ---
> > > >   drivers/dma/qcom/bam_dma.c | 2 +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> > > > index 19116295f8325767a0d97a7848077885b118241c..6c3e2ca8a572fd04c925de0adbd5cc0616b361ef
> > > > 100644
> > > > --- a/drivers/dma/qcom/bam_dma.c
> > > > +++ b/drivers/dma/qcom/bam_dma.c
> > > > @@ -1303,7 +1303,7 @@ static int bam_dma_probe(struct
> > > > platform_device *pdev)
> > > >           bam_channel_init(bdev, &bdev->channels[i], i);
> > > >
> > > >       ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
> > > > -            IRQF_TRIGGER_HIGH, "bam_dma", bdev);
> > > > +            IRQF_TRIGGER_NONE, "bam_dma", bdev);
> > > >       if (ret)
> > > >           goto err_bam_channel_exit;
> > > >
> > > >
> > > > ---
> > > > base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
> > > > change-id: 20260601-qcom-bam-dma-irq-trigger-0366e7e86f17
> > > >
> > > > Best regards,
> > > > --
> > > > Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
> > > >

Re: [PATCH RESEND] dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree

[Vishnu Santhosh]

On 28-09-2026 09:57 pm, Frank Li wrote:
> On Mon, Sep 28, 2026 at 02:38:14PM +0530, Vishnu Santhosh wrote:
>> Hi Frank,
>>
>> On 16-09-2026 08:30 pm, Vishnu Santhosh wrote:
>>> On 15-09-2026 07:36 pm, Frank Li wrote:
>>>> On Fri, Jul 17, 2026 at 10:30:28AM +0530, Vishnu Santhosh wrote:
>>>>> The driver hardcodes IRQF_TRIGGER_HIGH when registering the BAM
>>>>> interrupt, which overrides the trigger type specified in the device
>>>>> tree. On Qualcomm Shikra SoC, the A2 BAM signals an edge interrupt
>>>>> to the apps processor; registering it as level-high causes the
>>>>> interrupt to not fire, resulting in missed DMA completions.
>>>>>
>>>>> Use IRQF_TRIGGER_NONE instead, which causes the kernel to use the
>>>>> trigger type already configured by platform_get_irq() when it parsed
>>>>> the device tree interrupts property. This makes the driver
>>>>> platform-agnostic.
>>>> where show this? can you point me doc or code?
>>>>
>>>> Frank
>>> Hi Frank,
>>>
>>> The BAM driver obtains the IRQ through platform_get_irq():
>>>
>>> bdev->irq = platform_get_irq(pdev, 0);
>>>
>>> in https://elixir.bootlin.com/linux/v7.3-rc3/source/drivers/dma/qcom/bam_dma.c#L1270
>>>
>>> It then registers the same IRQ with:
>>>
>>> ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
>>>                           IRQF_TRIGGER_HIGH, "bam_dma", bdev);
>>>
>>> in https://elixir.bootlin.com/linux/v7.3-rc3/source/drivers/dma/qcom/bam_dma.c#L1335
>>>
>>> The comment above IRQF_TRIGGER_NONE in include/linux/interrupt.h
>>> states that when no trigger flag is specified, the interrupt uses the
>>> trigger type already
>>> configured by the machine or firmware.
>>>
>>> https://elixir.bootlin.com/linux/v7.3-rc3/source/include/linux/interrupt.h#L25
> Thank you provide it. Kernel doc or comments may miss match actually code
> Do you know where exactly handle IRQF_TRIGGER_NONE as what doc said?
>
> Frank

Please find the detailed flow below.

The trigger type is handled in two steps:

1. platform_get_irq() looks up the DT trigger type and stores it in irq_data:

bam_dma_probe()
  platform_get_irq()
   platform_get_irq_optional()
    platform_get_irq_affinity()
     of_irq_get()
      irq_create_of_mapping()
       irq_create_fwspec_mapping() {
           ...
           irq_domain_translate(domain, fwspec, &hwirq, &type); /* L928 */
           ...
           /* Store trigger type */
           irqd_set_trigger_type(irq_data, type);                 /* L1001 */
       }

https://elixir.bootlin.com/linux/v7.3-rc4/source/kernel/irq/irqdomain.c#L1001

Type as IRQ_TYPE_EDGE_RISING, taken from the interrupts property in DT.

2. request_irq() uses the stored type only when the caller gives no trigger flag:

bam_dma_probe()
  devm_request_irq()
   devm_request_threaded_irq()
    __devm_request_threaded_irq()
     request_threaded_irq()
      __setup_irq() {
          ...
          /*
           * If the trigger type is not specified by the caller,
           * then use the default for this interrupt.
           * /
           if (!(new->flags & IRQF_TRIGGER_MASK))
              new->flags |= irqd_get_trigger_type(&desc->irq_data);  /* L1495 */
          ...
          if (!shared) {
              /* Setup the type (level, edge polarity) if configured: */
              if (new->flags & IRQF_TRIGGER_MASK) {
                 ret = __irq_set_trigger(desc,
                       new->flags & IRQF_TRIGGER_MASK);   /* L1719 */
              }
          }
      }

https://elixir.bootlin.com/linux/v7.3-rc4/source/kernel/irq/manage.c#L1495

So with IRQF_TRIGGER_HIGH, the check at manage.c#L1495 is false, the DT
type is ignored, and __irq_set_trigger() programs the GIC as level-high.
With IRQF_TRIGGER_NONE (0), __setup_irq() takes the type stored from DT
in step 1 and programs that instead.


Thanks,
Vishnu

>
>>>
>>> Therefore, IRQF_TRIGGER_HIGH overrides the trigger type associated with
>>> the IRQ during
>>> DT/IRQ-domain mapping, while IRQF_TRIGGER_NONE preserves it.
>>>
>>> The Shikra DTS which is still under review describes the BAM interrupt
>>> as edge-triggered:
>>>
>>> interrupts = <GIC_SPI 74 IRQ_TYPE_EDGE_RISING 0>;
>>>
>>> This driver change is needed so that the DT-specified trigger type
>>> remains effective once
>>> the Shikra DTS change is accepted.
>>>
>>>
>>> Thanks,
>>> Vishnu
>>>
>> Gentle ping on this patch. Please let me know if any other information to be shared
>> from my side.
>>
>>
>> Thanks,
>> Vishnu
>>
>>>>> Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
>>>>> Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
>>>>> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
>>>>> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
>>>>> ---
>>>>>    drivers/dma/qcom/bam_dma.c | 2 +-
>>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
>>>>> index 19116295f8325767a0d97a7848077885b118241c..6c3e2ca8a572fd04c925de0adbd5cc0616b361ef
>>>>> 100644
>>>>> --- a/drivers/dma/qcom/bam_dma.c
>>>>> +++ b/drivers/dma/qcom/bam_dma.c
>>>>> @@ -1303,7 +1303,7 @@ static int bam_dma_probe(struct
>>>>> platform_device *pdev)
>>>>>            bam_channel_init(bdev, &bdev->channels[i], i);
>>>>>
>>>>>        ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
>>>>> -            IRQF_TRIGGER_HIGH, "bam_dma", bdev);
>>>>> +            IRQF_TRIGGER_NONE, "bam_dma", bdev);
>>>>>        if (ret)
>>>>>            goto err_bam_channel_exit;
>>>>>
>>>>>
>>>>> ---
>>>>> base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
>>>>> change-id: 20260601-qcom-bam-dma-irq-trigger-0366e7e86f17
>>>>>
>>>>> Best regards,
>>>>> --
>>>>> Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
>>>>>

Re: [PATCH RESEND] dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree

[Frank Li]

On Fri, Jul 17, 2026 at 10:30:28AM +0530, Vishnu Santhosh wrote:
> The driver hardcodes IRQF_TRIGGER_HIGH when registering the BAM
> interrupt, which overrides the trigger type specified in the device
> tree. On Qualcomm Shikra SoC, the A2 BAM signals an edge interrupt
> to the apps processor; registering it as level-high causes the
> interrupt to not fire, resulting in missed DMA completions.
>
> Use IRQF_TRIGGER_NONE instead, which causes the kernel to use the
> trigger type already configured by platform_get_irq() when it parsed
> the device tree interrupts property. This makes the driver
> platform-agnostic.
>
> Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
> Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
> ---

Reviewed-by: Frank Li <Frank.Li@nxp.com>

>  drivers/dma/qcom/bam_dma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> index 19116295f8325767a0d97a7848077885b118241c..6c3e2ca8a572fd04c925de0adbd5cc0616b361ef 100644
> --- a/drivers/dma/qcom/bam_dma.c
> +++ b/drivers/dma/qcom/bam_dma.c
> @@ -1303,7 +1303,7 @@ static int bam_dma_probe(struct platform_device *pdev)
>  		bam_channel_init(bdev, &bdev->channels[i], i);
>
>  	ret = devm_request_irq(bdev->dev, bdev->irq, bam_dma_irq,
> -			IRQF_TRIGGER_HIGH, "bam_dma", bdev);
> +			IRQF_TRIGGER_NONE, "bam_dma", bdev);
>  	if (ret)
>  		goto err_bam_channel_exit;
>
>
> ---
> base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
> change-id: 20260601-qcom-bam-dma-irq-trigger-0366e7e86f17
>
> Best regards,
> --
> Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
>

Re: [PATCH RESEND] dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree

[Vinod Koul]

On Fri, 17 Jul 2026 10:30:28 +0530, Vishnu Santhosh wrote:
> The driver hardcodes IRQF_TRIGGER_HIGH when registering the BAM
> interrupt, which overrides the trigger type specified in the device
> tree. On Qualcomm Shikra SoC, the A2 BAM signals an edge interrupt
> to the apps processor; registering it as level-high causes the
> interrupt to not fire, resulting in missed DMA completions.
> 
> Use IRQF_TRIGGER_NONE instead, which causes the kernel to use the
> trigger type already configured by platform_get_irq() when it parsed
> the device tree interrupts property. This makes the driver
> platform-agnostic.
> 
> [...]

Applied, thanks!

[1/1] dmaengine: qcom: bam_dma: Defer IRQ trigger type to device tree
      commit: 3cee6f79553202d7d3954555560ac38d719344b8

Best regards,
-- 
~Vinod