linux-kernel - Re: [PATCH v6 2/2] i2c: i2c-qcom-geni: Add Block event interrupt support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8a149580-5044-4744-b432-9f0eef0a0d31@quicinc.com>
Date: Fri, 25 Jul 2025 16:20:23 +0530
From: Jyothi Kumar Seerapu <quic_jseerapu@...cinc.com>
To: Vinod Koul <vkoul@...nel.org>,
        Dmitry Baryshkov
	<dmitry.baryshkov@....qualcomm.com>
CC: 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 2/2] i2c: i2c-qcom-geni: Add Block event interrupt
 support



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.