On 2020-12-22 17:48, mdalam@codeaurora.org wrote:

On 2020-12-21 23:39, Thara Gopinath wrote:

quoted

On 12/21/20 2:35 AM, mdalam@codeaurora.org wrote:

quoted

On 2020-12-19 09:05, Thara Gopinath wrote:

quoted

On 12/17/20 9:37 AM, 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.

Hi,

This is a generic question. What is the point of LOCK/UNLOCK with
allocating LOCK groups to the individual dma channels? By default
doesn't all channels fall in the same group. This would mean that
a lock does not prevent the dma controller from not executing a
transaction on the other channels.

The Pipe Locking/Unlocking will be only on command-descriptor.
Upon encountering a command descriptor 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.

So unless you assign pipe groups, this will not work as intended
right? So this patch is only half of the solution. There should also
be a patch allowing pipe groups to be assigned. Without that extra bit
this patch does nothing , right ?

Yes you are right.
We are having some register which will configure the pipe lock group.
But these registers are not exposed to non-secure world. These 
registers
only accessible through secure world. Currently in IPQ5018 SoC we are
configuring
these register in secure world to configure pipe lock group.

ping! Is there any update on this ? Do you need any further info ?