Re: [PATCH v20 06/14] dmaengine: qcom: bam_dma: add support for BAM locking

[Bartosz Golaszewski]

On Wed, 8 Jul 2026 14:17:51 +0200, Stephan Gerhold
<stephan.gerhold@xxxxxxxxxx> said:
> On Mon, Jun 29, 2026 at 12:01:08PM +0200, Bartosz Golaszewski wrote:
>>
>> @@ -1064,9 +1220,23 @@ static void bam_start_dma(struct bam_chan *bchan)
>>
>>  	lockdep_assert_held(&bchan->vc.lock);
>>
>> +	vd = vchan_next_desc(&bchan->vc);
>>  	if (!vd)
>>  		return;
>>
>> +	/*
>> +	 * Wrap the issued work with a LOCK/UNLOCK pair exactly once, at the
>> +	 * start of a fresh sequence and only when there is real work to lock
>> +	 * around. On a re-entry after a full FIFO, we see the BAM is locked
>> +	 * and must not add another pair we simply continue loading the
>> +	 * remainder of the same locked sequence.
>> +	 */
>> +	if (!bchan->bam_locked) {
>> +		ret = bam_setup_pipe_lock(bchan);
>> +		if (ret == 0 && bchan->bam_locked)
>> +			vd = vchan_next_desc(&bchan->vc);
>> +	}
>
> I *suspect* though that Sashiko is right about the new race condition
> here if new descriptors are queued while the hardware is busy processing
> a locked sequence.
>
> https://sashiko.dev/#/patchset/20260629-qcom-qce-cmd-descr-v20-0-56f67da84c05%40oss.qualcomm.com?part=6
>
> Any idea how to fix this?
>

We could move the bam_clocked clearing from the IRQ handler into
bam_start_dma(), right after the UNLOCK descriptor is committed to the FIFO.
Basically track the state at queue-time, not at interrupt time. Once we commit
the UNLOCK, the locked range of descriptors is "sealed". If there's more work,
we'd call bam_setup_pipe_lock() again with a new "sealed" range surrounded
by LOCK/UNLOCK.

Bart