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

Bartosz Golaszewski <[email protected]> Thu, 23 Jul 2026 01:44:04 -0700

Newsgroups	org.kernel.vger.linux-crypto,dev.linux.lists.sashiko-reviews,org.infradead.lists.linux-arm-kernel,org.kernel.vger.dmaengine,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel
Message-ID	<CAMRc=McJBVkCT+rFToY-Sn+nrLy-Sb8otz1NYWkQj1J-4-RK-A@mail.gmail.com>

On Wed, 22 Jul 2026 18:24:10 +0200, Stephan Gerhold
<[email protected]> said:
>
> FWIW, I couldn't stop myself trying to finish my "write lock descriptors
> directly into FIFO" idea, once I started I was curious how it would turn
> out. I think it's actually quite elegant, the loop in bam_start_dma() is
> wrapped with LOCK and UNLOCK, later process_channel_irqs() looks at the
> FIFO again and just skips over these descriptors. lock_ce is allocated
> once at channel creation time, no other allocations are needed. (Could
> probably move lock_ce allocation to slave_config() so it's allocated
> only when locking is configured for a channel).
>
> See diff below. It doesn't crash badly in a quick test, but didn't check
> in detail if the locking is actually working correctly. :')
>
> I'm okay with whatever is "free of known races" and works with the use
> cases we have, so use/adapt whatever you like best.
>
> If you want to use this, feel free to add
> Co-developed-by: Stephan Gerhold <[email protected]>
> Signed-off-by: Stephan Gerhold <[email protected]>
>
> Good luck! :D
>

Oh, neat! Thanks, I may use some of that. And that makes you have a stake in
this series now. :)

Bartosz