Messages in this thread |  | | From | Bartosz Golaszewski <> | | Date | Wed, 11 Mar 2026 03:32:38 -0700 | | Subject | Re: [PATCH v12 05/12] dmaengine: qcom: bam_dma: add support for BAM locking |
| |
On Wed, Mar 11, 2026 at 11:00 AM Stephan Gerhold <stephan.gerhold@linaro.org> wrote: > > I'm not entirely sure if this actually guarantees waiting with the > unlock until the transaction is "done", for two reasons: > > 1. &bchan->vc.desc_issued looks like a "TODO" list for descriptors we > haven't fully managed to squeeze into the BAM FIFO yet. It doesn't > tell you which descriptors have been consumed and finished > processing inside the FIFO. > > Consider e.g. the following case: The client has issued a number of > descriptors, they all fit into the FIFO. The first descriptor has a > callback assigned, so we ask the BAM to send us an interrupt when it > has been consumed. We get the interrupt for the first descriptor and > process_channel_irqs() marks it as completed, the rest of the > descriptors are still pending. &bchan->vc.desc_issued is empty, so > you queue the unlock command before the rest of the descriptors have > finished. >
Thanks for looking into it. Good catch, I think you're right.
> 2. From reading the BAM chapter in the APQ8016E TRM I get the > impression that by default an interrupt for a descriptor just tells > you that the descriptor was consumed by the BAM (and forwarded to > the peripheral). If you want to guarantee that the transaction is > actually done on the peripheral side before allowing writes into > config registers, you would need to set the NWD (Notify When Done) > bit (aka DMA_PREP_FENCE) on the last descriptor before the unlock > command. > > NWD seems to stall descriptor processing until the peripheral > signals completion, so this might allow you to immediately queue the > unlock command like in v11. The downside is that you would need to > make assumptions about the set of commands submitted by the client > again... The downstream driver seems to set NWD on the data > descriptor immediately before the UNLOCK command [1]. >
If what we have in the queue is:
[DATA] [DATA] [DATA] [CMD]
And we want to extend it with LOCK/UNLOCK like so:
[LOCK] [DATA] [DATA] [DATA] [CMD] [UNLOCK]
Should the NWD go with the last DATA descriptor or the last descriptor period whether data or command?
It's, again, not very clear from reading tha part.
Bart
> The chapter in the APQ8016E TRM kind of contradicts itself > sometimes, but there is this sentence for example: "On the data > descriptor preceding command descriptor, NWD bit must be asserted in > order to assure that all the data has been transferred and the > peripheral is ready to be re-configured." > > Thanks, > Stephan > > [1]: https://git.codelinaro.org/clo/la/platform/vendor/qcom/opensource/securemsm-kernel/-/blob/fa55a96773d3fbfcd96beb2965efcaaae5697816/crypto-qti/qce50.c#L5361-5362
|  |