On 8/11/2025 11:10 PM, Vinod Koul wrote:
On 25-07-25, 16:20, Jyothi Kumar Seerapu wrote:
On 7/23/2025 12:45 PM, Vinod Koul wrote:
On 22-07-25, 15:46, Dmitry Baryshkov wrote:
On Tue, Jul 22, 2025 at 05:50:08PM +0530, Jyothi Kumar Seerapu wrote:
On 7/19/2025 3:27 PM, Dmitry Baryshkov wrote:
On Mon, Jul 07, 2025 at 09:58:30PM +0530, Jyothi Kumar Seerapu wrote:
On 7/4/2025 1:11 AM, Dmitry Baryshkov wrote:
On Thu, 3 Jul 2025 at 15:51, Jyothi Kumar Seerapu
[Folks, would be nice to trim replies]
Could you please confirm if can go with the similar approach of unmap the
processed TREs based on a fixed threshold or constant value, instead of
unmapping them all at once?
I'd still say, that's a bad idea. Please stay within the boundaries of
the DMA API.
I agree with the approach you suggested—it's the GPI's responsibility to
manage the available TREs.
However, I'm curious whether can we set a dynamic watermark value perhaps
half the available TREs) to trigger unmapping of processed TREs ? This would
allow the software to prepare the next set of TREs while the hardware
continues processing the remaining ones, enabling better parallelism and
throughput.
Let's land the simple implementation first, which can then be improved.
However I don't see any way to return 'above the watermark' from the DMA
controller. You might need to enhance the API.
Traditionally, we set the dma transfers for watermark level and we get a
interrupt. So you might want to set the callback for watermark level
and then do mapping/unmapping etc in the callback. This is typical model
for dmaengines, we should follow that well
BR
Thanks Dmitry and Vinod, I will work on V7 patch for submitting the I2C
messages until they fit and and unmap all processed messages together for
now.
Regarding the watermark mechanism, looks GENI SE DMA supports watermark
interrupts but it appears that GPI DMA doesn't have such provision of
watermark.
What is the mechanism to get interrupts from the GPI? If you submit 10
txn, can you ask it to interrupt when half of them are done?
GPI interrupts are triggered upon each transaction completion or when
error conditions occur.
Using the Block Event Interrupt (BEI) mechanism, we can control when
interrupts are generated.
For example, if there are 10 transactions (i.e., 10 I2C messages in a
transfer), it's possible to configure the GSI to generate an interrupt
after the completion of the 5th transaction.
However, with the new design discussed above, I2C messages are submitted
dynamically based on available TREs.
BEI is configured to generate interrupts either:
- After the last I2C message, if sufficient TREs are available, or
- After a specific I2C message, when no further TREs are available.
In this dynamic setup, there is no static way to configure BEI to
trigger interrupts at a fixed transaction count.
The interrupt behavior is instead determined by runtime resource
availability.
