On 2021-01-12 15:40, Vinod Koul wrote:

On 12-01-21, 15:01, mdalam@codeaurora.org wrote:

quoted

On 2020-12-21 23:03, mdalam@codeaurora.org wrote:

quoted

On 2020-12-21 14:53, Vinod Koul wrote:

quoted

Hello,

On 17-12-20, 20:07, Md Sadre Alam wrote:

quoted

This change will add support for LOCK & UNLOCK flag bit support
on CMD descriptor.

If DMA_PREP_LOCK flag passed in prep_slave_sg then requester of this
transaction wanted to lock the DMA controller for this transaction so
BAM driver should set LOCK bit for the HW descriptor.

If DMA_PREP_UNLOCK flag passed in prep_slave_sg then requester
of this
transaction wanted to unlock the DMA controller.so BAM driver
should set
UNLOCK bit for the HW descriptor.

Can you explain why would we need to first lock and then unlock..? How
would this be used in real world.

I have read a bit of documentation but is unclear to me. Also should
this be exposed as an API to users, sounds like internal to driver..?

IPQ5018 SoC having only one Crypto Hardware Engine. This Crypto Hardware
Engine
will be shared between A53 core & ubi32 core. There is two separate
driver dedicated
to A53 core and ubi32 core. So to use Crypto Hardware Engine
parallelly for encryption/description
we need bam locking mechanism. if one driver will submit the request
for encryption/description
to Crypto then first it has to set LOCK flag bit on command descriptor
so that other pipes will
get locked.

The Pipe Locking/Unlocking will be only on command-descriptor. Upon
encountering a command descriptor

Can you explain what is a cmd descriptor?

   In BAM pipe descriptor structure there is a field called CMD (Command 
descriptor).
   CMD allows the SW to create descriptors of type Command which does not 
generate any data transmissions
   but configures registers in the Peripheral (write operations, and read 
registers operations ).
   Using command descriptor enables the SW to queue new configurations 
between data transfers in advance.

quoted

quoted

with LOCK bit set, The BAM will lock all other pipes not related to
the current pipe group, and keep
handling the current pipe only until it sees the UNLOCK set then it
will release all locked pipes.
locked pipe will not fetch new descriptors even if it got event/events
adding more descriptors for
this pipe (locked pipe).

No need to expose as an API to user because its internal to driver, so
while preparing command descriptor
just we have to update the LOCK/UNLOCK flag.

So IIUC, no api right? it would be internal to driver..?

   Yes its totally internal to deriver.