From: mdalam@codeaurora.org
To: Vinod Koul <vkoul@kernel.org>
Cc: corbet@lwn.net, agross@kernel.org, bjorn.andersson@linaro.org,
dan.j.williams@intel.com, dmaengine@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, sricharan@codeaurora.org,
mdalam=codeaurora.org@codeaurora.org
Subject: Re: [PATCH] dmaengine: qcom: bam_dma: Add LOCK and UNLOCK flag bit support
Date: Mon, 01 Feb 2021 21:20:07 +0530 [thread overview]
Message-ID: <73c871d3d674607fafc7b79e602ec587@codeaurora.org> (raw)
In-Reply-To: <20210201064314.GM2771@vkoul-mobl>
On 2021-02-01 12:13, Vinod Koul wrote:
> On 01-02-21, 11:52, mdalam@codeaurora.org wrote:
>> On 2021-02-01 11:35, Vinod Koul wrote:
>> > On 27-01-21, 23:56, mdalam@codeaurora.org wrote:
>
>> > > 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.
>
> Okay so why cant the bam driver check cmd descriptor and do lock/unlock
> as below, why do we need users to do this.
>
> if (flags & DMA_PREP_CMD) {
> do_lock_bam();
User will not decide to do this LOCK/UNLOCK mechanism. It depends on
use case.
This LOCK/UNLOCK mechanism not required always. It needs only when
hardware will be shared
between different core with different driver.
The LOCK/UNLOCK flags provides SW to enter ordering between pipes
execution.
(Generally, the BAM pipes are total independent from each other and
work in parallel manner).
This LOCK/UNLOCK flags are part of actual pipe hardware descriptor.
Pipe descriptor having the following flags:
INT : Interrupt
EOT: End of transfer
EOB: End of block
NWD: Notify when done
CMD: Command
LOCK: Lock
UNLOCK: Unlock
etc.
Here the BAM driver is common driver for (QPIC, Crypto, QUP etc. in
IPQ5018)
So here only Crypto will be shared b/w multiple cores so For crypto
request only the LOCK/UNLOCK
mechanism required.
For other request like for QPIC driver, QUPT driver etc. its not
required. So Crypto driver has to raise the flag for
LOCK/UNLOCK while preparing CMD descriptor. The actual locking will
happen in BAM driver only using condition
if (flags & DMA_PREP_CMD) {
if (flags & DMA_PREP_LOCK)
desc->flags |= cpu_to_le16(DESC_FLAG_LOCK);
}
So Crypto driver should set this flag DMA_PREP_LOCK while preparing CMD
descriptor.
So LOCK should be set on actual hardware pipe descriptor with
descriptor type CMD.
>
> The point here is that this seems to be internal to dma and should be
> handled by dma driver.
>
This LOCK/UNLOK flags are part of actual hardware descriptor so this
should be handled by BAM driver only.
If we set condition like this
if (flags & DMA_PREP_CMD) {
do_lock_bam();
Then LOCK/UNLOCK will be applied for all the CMD descriptor including
(QPIC driver, QUP driver , Crypto driver etc.).
So this is not our intension. So we need to set this LOCK/UNLOCK only
for the drivers it needs. So Crypto driver needs
locking mechanism so we will set LOCK/UNLOCK flag on Crypto driver
request only for other driver request like QPIC driver,
QUP driver will not set this.
> Also if we do this, it needs to be done for specific platforms..
>
> Thanks
next prev parent reply other threads:[~2021-02-01 15:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-17 14:37 [PATCH] dmaengine: qcom: bam_dma: Add LOCK and UNLOCK flag bit support Md Sadre Alam
2020-12-19 3:35 ` Thara Gopinath
2020-12-21 7:35 ` mdalam
2020-12-21 18:09 ` Thara Gopinath
2020-12-22 12:18 ` mdalam
2021-01-12 9:30 ` mdalam
2020-12-21 9:23 ` Vinod Koul
2020-12-21 17:33 ` mdalam
2021-01-12 9:31 ` mdalam
2021-01-12 10:10 ` Vinod Koul
2021-01-13 19:50 ` mdalam
2021-01-15 5:58 ` Vinod Koul
2021-01-18 3:51 ` mdalam
2021-01-19 16:45 ` Vinod Koul
2021-01-27 18:26 ` mdalam
2021-02-01 6:05 ` Vinod Koul
2021-02-01 6:22 ` mdalam
2021-02-01 6:43 ` Vinod Koul
2021-02-01 15:50 ` mdalam [this message]
2021-02-09 16:39 ` mdalam
2021-02-09 17:35 ` Bjorn Andersson
2021-02-11 4:01 ` mdalam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=73c871d3d674607fafc7b79e602ec587@codeaurora.org \
--to=mdalam@codeaurora.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mdalam=codeaurora.org@codeaurora.org \
--cc=sricharan@codeaurora.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).