On 2021-02-01 11:35, Vinod Koul wrote:

On 27-01-21, 23:56, mdalam@codeaurora.org wrote:

quoted

On 2021-01-19 22:15, Vinod Koul wrote:

quoted

On 18-01-21, 09:21, mdalam@codeaurora.org wrote:

quoted

On 2021-01-15 11:28, Vinod Koul wrote:

quoted

On 14-01-21, 01:20, mdalam@codeaurora.org wrote:

quoted

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

quoted

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.

What and when is the CMD descriptor used for..?

  CMD descriptor is mainly used for configuring controller register.
  We can read/write controller register via BAM using CMD descriptor
only.
  CMD descriptor use command pipe for the transaction.

In which use cases would you need to issue cmd descriptors..?

  In IPQ5018 there is only one Crypto engine and it will get shared
  between UBI32 core & A53 core. So here we need to use command
  descriptor in-order to perform LOCKING/UNLOCKING mechanism. Since
  LOCK/ULOCK flag we can set only on CMD descriptor.

So when will lock/unlock be performed? Can you please explain that..

   LOCK/UNLOCK will be performed when two different driver wanted to use 
the
   same HW. eg. In IPQ5018 there is only one Crypto engine and it will be 
shared b/w
   UBI32 core driver and A53 core driver.

   When A53 core wanted to submit request to crypto engine via BAM then 
first it has to
   LOCK all other pipes (pipe dedicated to UBI32 core) and then trigger 
the transaction start.
   Once all the transaction will be completed the A53 core crypto driver 
will release the LOCK
   from all the pipes. Same sequence will be applicable for UBI32 core 
crypto driver as well.
   It depends whose request will come first to the crypto HW.

quoted

quoted

quoted

quoted

quoted

quoted

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.

So no need for this patch then, right?

  This patch is needed , because if some hardware will shared between
  multiple core like A53 and ubi32 for example. In IPQ5018 there is
  only one crypto engine and this will be shared between A53 core and
  ubi32 core and in A53 core & ubi32 core there are different drivers
  is getting used. So if encryption/decryption request come at same
  time from both the driver then things will get messed up. So here we
  need LOCKING mechanism.  If first request is from A53 core driver
  then this driver should lock all the pipes other than pipe dedicated
  to A53 core. So while preparing CMD descriptor driver should used
  this flag "DMA_PREP_LOCK", Since LOCK and UNLOCK flag bit we can set
  only on CMD descriptor. Once request processed then driver will set
  UNLOCK flag on CMD descriptor. Driver should use this flag
  "DMA_PREP_UNLOCK" while preparing CMD descriptor. Same logic will be
  apply for ubi32 core driver as well.

Why cant this be applied at driver level, based on txn being issued it
can lock issue the txn and then unlock when done. I am not convinced yet
that this needs to be exported to users and can be managed by dmaengine
driver.

  The actual LOCK/UNLOCK flag should be set on hardware command 
descriptor.
  so this flag setting should be done in DMA engine driver. The user 
of the
DMA
  driver like (in case of IPQ5018) Crypto can use flag "DMA_PREP_LOCK" 
&
"DMA_PREP_UNLOCK"
  while preparing CMD descriptor before submitting to the DMA engine. 
In DMA
engine driver
  we are checking these flasgs on CMD descriptor and setting actual
LOCK/UNLOCK flag on hardware
  descriptor.

I am not sure I comprehend this yet.. when is that we would need to do
this... is this for each txn submitted to dmaengine.. or something
else..

  Its not for each transaction submitted to dmaengine. We have to set 
this only
  once on CMD descriptor. So when A53 crypto driver need to change the 
crypto configuration
  then first it will lock the all other pipes using setting the LOCK flag 
bit on CMD
  descriptor and then it can start the transaction , on data descriptor 
this flag will
  not get set once all transaction will be completed the A53 crypto 
driver release the lock on
  all other pipes using UNLOCK flag on CMD descriptor. So LOCK/UNLOCK 
will be only once and not for
  the each transaction.

quoted

   if (flags & DMA_PREP_CMD) { <== check for descriptor type
		if (flags & DMA_PREP_LOCK)
			desc->flags |= cpu_to_le16(DESC_FLAG_LOCK); <== Actual LOCK flag 
setting
on HW descriptor.
		if (flags & DMA_PREP_UNLOCK)
			desc->flags |= cpu_to_le16(DESC_FLAG_UNLOCK); <== Actual UNLOCK 
flag
setting on HW descriptor.
	}

quoted

Thanks