[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <de00809a-2775-4417-b987-5f557962ec31@quicinc.com>
Date: Fri, 30 May 2025 19:35:10 +0530
From: Jyothi Kumar Seerapu <quic_jseerapu@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
CC: Vinod Koul <vkoul@...nel.org>,
Mukesh Kumar Savaliya
<quic_msavaliy@...cinc.com>,
Viken Dadhaniya <quic_vdadhani@...cinc.com>,
Andi Shyti <andi.shyti@...nel.org>,
Sumit Semwal <sumit.semwal@...aro.org>,
Christian König <christian.koenig@....com>,
<linux-arm-msm@...r.kernel.org>, <dmaengine@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <linux-i2c@...r.kernel.org>,
<linux-media@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
<linaro-mm-sig@...ts.linaro.org>, <quic_vtanuku@...cinc.com>
Subject: Re: [PATCH v6 1/2] dmaengine: qcom: gpi: Add GPI Block event
interrupt support
On 5/9/2025 11:48 AM, Jyothi Kumar Seerapu wrote:
>
>
> On 5/6/2025 5:02 PM, Dmitry Baryshkov wrote:
>> On Tue, May 06, 2025 at 04:48:43PM +0530, 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.
>>>
>>> Signed-off-by: Jyothi Kumar Seerapu <quic_jseerapu@...cinc.com>
>>> ---
>>> v5 ->v6:
>>> - For updating the block event interrupt bit, instead of relying on
>>> bei_flag, decision check is moved with DMA_PREP_INTERRUPT flag.
>>> v4 -> v5:
>>> - BEI flag naming changed from flags to bei_flag.
>>> - QCOM_GPI_BLOCK_EVENT_IRQ macro is removed from qcom-gpi-dma.h
>>> file, and Block event interrupt support is checked with bei_flag.
>>>
>>> v3 -> v4:
>>> - API's added for Block event interrupt with multi descriptor
>>> support for
>>> I2C is moved from qcom-gpi-dma.h file to I2C geni qcom driver file.
>>> - gpi_multi_xfer_timeout_handler function is moved from GPI driver to
>>> I2C driver.
>>>
>>> v2-> v3:
>>> - Renamed gpi_multi_desc_process to gpi_multi_xfer_timeout_handler
>>> - MIN_NUM_OF_MSGS_MULTI_DESC changed from 4 to 2
>>> - Added documentation for newly added changes in "qcom-gpi-dma.h"
>>> file
>>> - Updated commit description.
>>>
>>> v1 -> v2:
>>> - Changed dma_addr type from array of pointers to array.
>>> - To support BEI functionality with the TRE size of 64 defined in
>>> GPI driver,
>>> updated QCOM_GPI_MAX_NUM_MSGS to 16 and NUM_MSGS_PER_IRQ to 4.
>>>
>>> drivers/dma/qcom/gpi.c | 3 +++
>>> include/linux/dma/qcom-gpi-dma.h | 2 ++
>>> 2 files changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/dma/qcom/gpi.c b/drivers/dma/qcom/gpi.c
>>> index b1f0001cc99c..7e511f54166a 100644
>>> --- a/drivers/dma/qcom/gpi.c
>>> +++ b/drivers/dma/qcom/gpi.c
>>> @@ -1695,6 +1695,9 @@ static int gpi_create_i2c_tre(struct gchan
>>> *chan, struct gpi_desc *desc,
>>> tre->dword[3] = u32_encode_bits(TRE_TYPE_DMA, TRE_FLAGS_TYPE);
>>> tre->dword[3] |= u32_encode_bits(1, TRE_FLAGS_IEOT);
>>> +
>>> + if (!(i2c->dma_flags & DMA_PREP_INTERRUPT))
>>> + tre->dword[3] |= u32_encode_bits(1, TRE_FLAGS_BEI);
>>> }
>>> for (i = 0; i < tre_idx; i++)
>>> diff --git a/include/linux/dma/qcom-gpi-dma.h b/include/linux/dma/
>>> qcom-gpi-dma.h
>>> index 6680dd1a43c6..ebac0d3edff2 100644
>>> --- a/include/linux/dma/qcom-gpi-dma.h
>>> +++ b/include/linux/dma/qcom-gpi-dma.h
>>> @@ -65,6 +65,7 @@ enum i2c_op {
>>> * @rx_len: receive length for buffer
>>> * @op: i2c cmd
>>> * @muli-msg: is part of multi i2c r-w msgs
>>> + * @dma_flags: Flags indicating DMA capabilities
>>> */
>>> struct gpi_i2c_config {
>>> u8 set_config;
>>> @@ -78,6 +79,7 @@ struct gpi_i2c_config {
>>> u32 rx_len;
>>> enum i2c_op op;
>>> bool multi_msg;
>>> + unsigned int dma_flags;
>>
>> Why do you need extra field instead of using
>> dma_async_tx_descriptor.flags?
>
> In the original I2C QCOM GENI driver, using the local variable (unsigned
> in flags) and updating the "DMA_PREP_INTERRUPT" flag.
>
> Sure, i will review if "dma_async_tx_descriptor.flags" can be retrieved
> in GPI driver for DMA_PREP_INTERRUPT flag status.
Hi Dmitry,
In the I2C Geni driver, the dma flags are primarily used in the
dmaengine_prep_slave_single() function, which expects the argument type
to be unsigned int. Therefore, the flags should be defined either as
enum dma_ctrl_flags, or unsigned int.
In the GPI driver, specifically within the gpi_prep_slave_sg() function,
the flags are correctly received from the I2C driver. However, these
flags are not currently passed to the gpi_create_i2c_tre() function.
If we pass the existing flags variable to the gpi_create_i2c_tre()
function, we can retrieve the DMA flags information without introducing
any additional or external variables.
Please confirm if this approach—reusing the existing flags argument in
the GPI driver—is acceptable and good to proceed with.
>>
>>> };
>>> #endif /* QCOM_GPI_DMA_H */
>>> --
>>> 2.17.1
>>>
>>
>
>
Powered by blists - more mailing lists