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

[Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>]

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>
>>>>>