Re: [PATCH v8 2/4] dmaengine: qcom: gpi: Add lock/unlock TREs for multi-owner I2C transfers

On 7/16/2026 5:39 PM, Bartosz Golaszewski wrote:
> On Wed, 15 Jul 2026 17:33:40 +0200, Vinod Koul <[email protected]> said:
>> On 08-07-26, 10:40, Mukesh Kumar Savaliya wrote:
>>
>>> +/**
>>> + * enum gpi_lock_action - request lock/unlock TRE sequencing
>>> + * @GPI_LOCK_NONE: No lock/unlock TRE requested for this transfer
>>> + * @GPI_LOCK_ACQUIRE: Emit a lock TRE before the transfer
>>> + * @GPI_LOCK_RELEASE: Emit an unlock TRE after the transfer
>>> + *
>>> + * Used by protocol drivers for multi-owner controller setups (e.g. when
>>> + * DeviceTree indicates the controller is shared via qcom,qup-multi-owner).
>>> + */
>>> +enum gpi_lock_action {
>>> +	GPI_LOCK_NONE = 0,
>>> +	GPI_LOCK_ACQUIRE,
>>> +	GPI_LOCK_RELEASE,
>>
>> Can qualcomm people please align on LOCK/UNLOCK interface? This is
>> second interface I am seeing now. Can you folks align internally on how
>> clients should communicating lock/unlock across different qualcomm
>> dmaengine drivers
>>
> 

Sure Vinod,Thanks for your review and updating on direction.
I thought reverse to not pass transfer index to GSI driver.


> As discussed internally - this driver should follow the pattern we established
> for BAM DMA where we don't require consumers to be aware of the locking
> happening to any larger degree than is absolutely required (for instance:
> passing the address of the appropriate scratchpad register as is the case for
> BAM DMA).
> 
Yes, Bartosz, i understand. let me align on this and follow BAM DMA 
design, will review with you OR get BAM DMA changes.

If Consumers do not posses knowledge of locking/unlocking, DMA engine 
(here GSI) need to have some decision making knowledge. e.g. First 
transfer and last transfer.

let me share with you and then will upload.


> Bart