Re: [PATCH v9 03/11] dmaengine: qcom: bam_dma: implement support for BAM locking

[Bartosz Golaszewski]

On Fri, Jan 9, 2026 at 3:15 PM Bartosz Golaszewski <brgl@xxxxxxxxxx> wrote:
>
> On Fri, Jan 9, 2026 at 3:27 AM Vinod Koul <vkoul@xxxxxxxxxx> wrote:
> >
> > >
> > > We need an API because we send a locking descriptor, then a regular
> > > descriptor (or descriptors) for the actual transaction(s) and then an
> > > unlocking descriptor. It's a thing the user of the DMA engine needs to
> > > decide on, not the DMA engine itself.
> >
> > I think downstream sends lock descriptor always. What is the harm in
> > doing that every time if we go down that path?
>
> No, in downstream it too depends on the user setting the right bits.
> Currently the only user of the BAM locking downstream is the NAND
> driver. I don't think the code where the crypto driver uses it is
> public yet.
>
> And yes, there is harm - it slightly impacts performance. For QCE it
> doesn't really matter as any users wanting to offload skcipher or SHA
> are better off using the Arm Crypto Extensions anyway as they are
> faster by an order of magnitude (!). It's also the default upstream,
> where the priorities are set such that the ARM CEs are preferred over
> the QCE. QCE however, is able to coordinate with the TrustZone and
> will be used to support the DRM use-cases.
>
> I prefer to avoid impacting any other users of BAM DMA.
>
> > Reg Dmitry question above, this is dma hw capability, how will client
> > know if it has to lock on older rev of hardware or not...?
> >
> > > Also: only the crypto engine needs it for now, not all the other users
> > > of the BAM engine.
> >
>
> Trying to set the lock/unlock bits will make
> dmaengine_desc_attach_metadata() fail if HW does not support it.
>
> > But they might eventually right?
> >
>
> Yes, and they will already have the interface to do it - in the form
> of descriptor metadata.
>

Hi! Have I answered all your questions? Can we proceed with this?

Bartosz