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

[Mukesh Savaliya]

On 7/16/2026 5:39 PM, Bartosz Golaszewski wrote:
> On Wed, 15 Jul 2026 17:33:40 +0200, Vinod Koul <vkoul@xxxxxxxxxx> 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