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

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
>

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).

Bart