[PATCH v5 RESEND 1/2] dmaengine: qcom: gpi: Add GPI Block event interrupt support

Jyothi Kumar Seerapu quic_jseerapu at quicinc.com
Thu Mar 13 12:20:15 UTC 2025


Hi Vinod, Thanks for the review comments.

On 3/11/2025 2:30 AM, Vinod Koul wrote:
> On 12-02-25, 17:35, Jyothi Kumar Seerapu wrote:
>> GSI hardware generates an interrupt for each transfer completion.
>> For multiple messages within a single transfer, this results in
>> N interrupts for N messages, leading to significant software
>> interrupt latency.
>>
>> To mitigate this latency, utilize Block Event Interrupt (BEI) mechanism.
>> Enabling BEI instructs the GSI hardware to prevent interrupt generation
>> and BEI is disabled when an interrupt is necessary.
>>
>> When using BEI, consider splitting a single multi-message transfer into
>> chunks of 8 messages internally and so interrupts are not expected for
>> the first 7 message completions, only the last message triggers
>> an interrupt, indicating the completion of 8 messages.
>>
>> This BEI mechanism enhances overall transfer efficiency.
> 
> That sounds good but I dont like the idea that we add a custom interface
> for this. Please use DMA_PREP_INTERRUPT instead. Adding this flag should
> trigger N interrupts, absence of this should lead to Block events only
> 
The DMA_PREP_INTERRUPT flag in DMA operations is used to indicate that 
an interrupt should be generated once the DMA transfer is completed.
However, this flag itself does not block interrupt generation at the GPI 
DMA hardware level. The GPI DMA hardware can still raise interrupts even 
in the absence of the DMA_PREP_INTERRUPT flag.

To block interrupts at the GPI DMA hardware level, we need to use the 
Block Event Interrupt (BEI) bit (as explained in the commit log).
As an example : for 100 transfers, we only want to receive one interrupt 
at the 100th transfer. This helps us significantly reduce latencies, as 
handling back-to-back 100 interrupts can take a few milliseconds.

Hope this explains it well. Please let me know if there are any other 
concerns or feedback.



More information about the dri-devel mailing list