From: Vinod Koul <vkoul@kernel.org>
To: Md Sadre Alam <quic_mdalam@quicinc.com>
Cc: corbet@lwn.net, thara.gopinath@gmail.com,
herbert@gondor.apana.org.au, davem@davemloft.net,
martin.petersen@oracle.com, enghua.yu@intel.com,
u.kleine-koenig@baylibre.com, dmaengine@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, linux-arm-msm@vger.kernel.org,
quic_utiwari@quicinc.com, quic_srichara@quicinc.com,
quic_varada@quicinc.com
Subject: Re: [PATCH v6 02/12] dmaengine: add DMA_PREP_LOCK and DMA_PREP_UNLOCK flag
Date: Tue, 11 Mar 2025 02:06:00 +0530 [thread overview]
Message-ID: <Z89NMPF9TGmz9Js/@vaman> (raw)
In-Reply-To: <20250115103004.3350561-3-quic_mdalam@quicinc.com>
On 15-01-25, 15:59, Md Sadre Alam wrote:
> Add lock and unlock flag support on command descriptor.
> Once lock set in requester pipe, then the bam controller
> will lock all others pipe and process the request only
> from requester pipe. Unlocking only can be performed from
> the same pipe.
>
> If DMA_PREP_LOCK flag passed in command descriptor then requester
> of this transaction wanted to lock the BAM controller for this
> transaction so BAM driver should set LOCK bit for the HW descriptor.
>
> If DMA_PREP_UNLOCK flag passed in command descriptor then requester
> of this transaction wanted to unlock the BAM controller.so BAM driver
> should set UNLOCK bit for the HW descriptor.
>
> BAM IP version 1.4.0 and above only supports this LOCK/UNLOCK
> feature.
Have you aligned internally b/w team at Qualcomm to have this as single
approach for LOCK implementation. I would like to see ack from
Mukesh/Bjorn before proceeding ahead with this
>
> Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
> ---
>
> Change in [v6]
>
> * Change "BAM" to "DAM"
>
> Change in [v5]
>
> * Added DMA_PREP_LOCK and DMA_PREP_UNLOCK flag support
>
> Change in [v4]
>
> * This patch was not included in v4
>
> Change in [v3]
>
> * This patch was not included in v3
>
> Change in [v2]
>
> * This patch was not included in v2
>
> Change in [v1]
>
> * This patch was not included in v1
>
> Documentation/driver-api/dmaengine/provider.rst | 15 +++++++++++++++
> include/linux/dmaengine.h | 6 ++++++
> 2 files changed, 21 insertions(+)
>
> diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst
> index 3085f8b460fa..a032e55d0a4f 100644
> --- a/Documentation/driver-api/dmaengine/provider.rst
> +++ b/Documentation/driver-api/dmaengine/provider.rst
> @@ -628,6 +628,21 @@ DMA_CTRL_REUSE
> - This flag is only supported if the channel reports the DMA_LOAD_EOT
> capability.
>
> +- DMA_PREP_LOCK
> +
> + - If set, the DMA will lock all other pipes not related to the current
> + pipe group, and keep handling the current pipe only.
> +
> + - All pipes not within this group will be locked by this pipe upon lock
> + event.
> +
> + - only pipes which are in the same group and relate to the same Environment
> + Execution(EE) will not be locked by a certain pipe.
> +
> +- DMA_PREP_UNLOCK
> +
> + - If set, DMA will release all locked pipes
> +
> General Design Notes
> ====================
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 346251bf1026..8ebd43a998a7 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -200,6 +200,10 @@ struct dma_vec {
> * transaction is marked with DMA_PREP_REPEAT will cause the new transaction
> * to never be processed and stay in the issued queue forever. The flag is
> * ignored if the previous transaction is not a repeated transaction.
> + * @DMA_PREP_LOCK: tell the driver that there is a lock bit set on command
> + * descriptor.
> + * @DMA_PREP_UNLOCK: tell the driver that there is a un-lock bit set on command
> + * descriptor.
> */
> enum dma_ctrl_flags {
> DMA_PREP_INTERRUPT = (1 << 0),
> @@ -212,6 +216,8 @@ enum dma_ctrl_flags {
> DMA_PREP_CMD = (1 << 7),
> DMA_PREP_REPEAT = (1 << 8),
> DMA_PREP_LOAD_EOT = (1 << 9),
> + DMA_PREP_LOCK = (1 << 10),
> + DMA_PREP_UNLOCK = (1 << 11),
> };
>
> /**
> --
> 2.34.1
--
~Vinod
next prev parent reply other threads:[~2025-03-10 20:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 10:29 [PATCH v6 00/12] dmaengine: qcom: bam_dma: add cmd descriptor support Md Sadre Alam
2025-01-15 10:29 ` [PATCH v6 01/12] dmaengine: qcom: bam_dma: Add bam_sw_version register read Md Sadre Alam
2025-01-16 17:06 ` Stephan Gerhold
2025-01-17 4:32 ` Md Sadre Alam
2025-01-15 10:29 ` [PATCH v6 02/12] dmaengine: add DMA_PREP_LOCK and DMA_PREP_UNLOCK flag Md Sadre Alam
2025-03-10 20:36 ` Vinod Koul [this message]
2025-03-11 5:11 ` Md Sadre Alam
2025-01-15 10:29 ` [PATCH v6 03/12] dmaengine: qcom: bam_dma: add bam_pipe_lock flag support Md Sadre Alam
2025-03-07 13:37 ` Bartosz Golaszewski
2025-01-15 10:29 ` [PATCH v6 04/12] crypto: qce - Add support for crypto address read Md Sadre Alam
2025-01-15 10:29 ` [PATCH v6 05/12] crypto: qce - Add bam dma support for crypto register r/w Md Sadre Alam
2025-01-15 10:29 ` [PATCH v6 06/12] crypto: qce - Convert register r/w for skcipher via BAM/DMA Md Sadre Alam
2025-01-15 10:29 ` [PATCH v6 07/12] crypto: qce - Convert register r/w for sha " Md Sadre Alam
2025-01-15 10:30 ` [PATCH v6 08/12] crypto: qce - Convert register r/w for aead " Md Sadre Alam
2025-01-15 10:30 ` [PATCH v6 09/12] crypto: qce - Add LOCK and UNLOCK flag support Md Sadre Alam
2025-01-15 10:30 ` [PATCH v6 10/12] crypto: qce - Add support for lock/unlock in skcipher Md Sadre Alam
2025-01-15 10:30 ` [PATCH v6 11/12] crypto: qce - Add support for lock/unlock in sha Md Sadre Alam
2025-01-15 10:30 ` [PATCH v6 12/12] crypto: qce - Add support for lock/unlock in aead Md Sadre Alam
2025-02-20 14:27 ` [PATCH v6 00/12] dmaengine: qcom: bam_dma: add cmd descriptor support brgl
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=Z89NMPF9TGmz9Js/@vaman \
--to=vkoul@kernel.org \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=dmaengine@vger.kernel.org \
--cc=enghua.yu@intel.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=quic_mdalam@quicinc.com \
--cc=quic_srichara@quicinc.com \
--cc=quic_utiwari@quicinc.com \
--cc=quic_varada@quicinc.com \
--cc=thara.gopinath@gmail.com \
--cc=u.kleine-koenig@baylibre.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.