On 2020-12-21 23:39, Thara Gopinath wrote:
On 12/21/20 2:35 AM, mdalam@xxxxxxxxxxxxxx wrote:
On 2020-12-19 09:05, Thara Gopinath wrote:
On 12/17/20 9:37 AM, Md Sadre Alam wrote:
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.
