All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vkoul@kernel.org>
To: Bartosz Golaszewski <brgl@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Thara Gopinath <thara.gopinath@gmail.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Udit Tiwari <quic_utiwari@quicinc.com>,
	Daniel Perez-Zoghbi <dperezzo@quicinc.com>,
	Md Sadre Alam <mdalam@qti.qualcomm.com>,
	Dmitry Baryshkov <lumag@kernel.org>,
	dmaengine@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-crypto@vger.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH v9 03/11] dmaengine: qcom: bam_dma: implement support for BAM locking
Date: Tue, 16 Dec 2025 20:40:58 +0530	[thread overview]
Message-ID: <aUF2gj_0svpygHmD@vaman> (raw)
In-Reply-To: <CAMRc=MetbSuaU9VpK7CTio4kt-1pkwEFecARv7ROWDH_yq63OQ@mail.gmail.com>

On 16-12-25, 16:00, Bartosz Golaszewski wrote:
> On Tue, Dec 16, 2025 at 2:00 PM Vinod Koul <vkoul@kernel.org> wrote:
> >
> > On 28-11-25, 12:44, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > >
> > > Use metadata operations in DMA descriptors to allow BAM users to pass
> > > additional information to the engine. To that end: define a new
> > > structure - struct bam_desc_metadata - as a medium and define two new
> > > commands: for locking and unlocking the BAM respectively. Handle the
> > > locking in the .attach() callback.
> > >
> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > ---
> > >  drivers/dma/qcom/bam_dma.c       | 59 +++++++++++++++++++++++++++++++++++++++-
> > >  include/linux/dma/qcom_bam_dma.h | 12 ++++++++
> > >  2 files changed, 70 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
> > > index c9ae1fffe44d79c5eb59b8bbf7f147a8fa3aa0bd..d1dc80b29818897b333cd223ec7306a169cc51fd 100644
> > > --- a/drivers/dma/qcom/bam_dma.c
> > > +++ b/drivers/dma/qcom/bam_dma.c
> > > @@ -30,6 +30,7 @@
> > >  #include <linux/module.h>
> > >  #include <linux/interrupt.h>
> > >  #include <linux/dma-mapping.h>
> > > +#include <linux/dma/qcom_bam_dma.h>
> > >  #include <linux/scatterlist.h>
> > >  #include <linux/device.h>
> > >  #include <linux/platform_device.h>
> > > @@ -391,6 +392,8 @@ struct bam_chan {
> > >       struct list_head desc_list;
> > >
> > >       struct list_head node;
> > > +
> > > +     bool bam_locked;
> > >  };
> > >
> > >  static inline struct bam_chan *to_bam_chan(struct dma_chan *common)
> > > @@ -655,6 +658,53 @@ static int bam_slave_config(struct dma_chan *chan,
> > >       return 0;
> > >  }
> > >
> > > +static int bam_metadata_attach(struct dma_async_tx_descriptor *desc, void *data, size_t len)
> > > +{
> > > +     struct virt_dma_desc *vd = container_of(desc, struct virt_dma_desc, tx);
> > > +     struct bam_async_desc *async_desc = container_of(vd, struct bam_async_desc,  vd);
> > > +     struct bam_desc_hw *hw_desc = async_desc->desc;
> > > +     struct bam_desc_metadata *metadata = data;
> > > +     struct bam_chan *bchan = to_bam_chan(metadata->chan);
> > > +     struct bam_device *bdev = bchan->bdev;
> > > +
> > > +     if (!data)
> > > +             return -EINVAL;
> > > +
> > > +     if (metadata->op == BAM_META_CMD_LOCK || metadata->op == BAM_META_CMD_UNLOCK) {
> > > +             if (!bdev->dev_data->bam_pipe_lock)
> > > +                     return -EOPNOTSUPP;
> > > +
> > > +             /* Expecting a dummy write when locking, only one descriptor allowed. */
> > > +             if (async_desc->num_desc != 1)
> > > +                     return -EINVAL;
> > > +     }
> > > +
> > > +     switch (metadata->op) {
> > > +     case BAM_META_CMD_LOCK:
> > > +             if (bchan->bam_locked)
> > > +                     return -EBUSY;
> > > +
> > > +             hw_desc->flags |= DESC_FLAG_LOCK;
> >
> > Why does this flag imply for the hardware.

s/Why/What !
> 
> Please rephrase, I don't get what you mean.

I am trying to understand what the flag refers to and why do you need
this.. What is the problem that lock tries to solve

> >
> > I do not like the interface designed here. This is overloading. Can we
> > look at doing something better here.
> >
> 
> It used to be a generic flag in dmaengine visible for all users.
> Dmitry argued that it's too Qualcomm-specific for a generic flag and
> suggested using the metadata to hide the communication between the QCE
> and BAM drivers. I'm open to other suggestions but it has to be a bit
> more specific than "do something better". :)
> 
> Bartosz

-- 
~Vinod

  reply	other threads:[~2025-12-16 15:11 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-28 11:43 [PATCH v9 00/11] crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O Bartosz Golaszewski
2025-11-28 11:43 ` [PATCH v9 01/11] dmaengine: qcom: bam_dma: Extend the driver's device match data Bartosz Golaszewski
2025-11-28 11:44 ` [PATCH v9 02/11] dmaengine: qcom: bam_dma: Add bam_pipe_lock flag support Bartosz Golaszewski
2025-12-06 11:42   ` Dmitry Baryshkov
2025-11-28 11:44 ` [PATCH v9 03/11] dmaengine: qcom: bam_dma: implement support for BAM locking Bartosz Golaszewski
2025-12-06 11:44   ` Dmitry Baryshkov
2025-12-16 13:00   ` Vinod Koul
2025-12-16 15:00     ` Bartosz Golaszewski
2025-12-16 15:10       ` Vinod Koul [this message]
2025-12-17 14:31         ` Bartosz Golaszewski
2025-12-23 10:45           ` Vinod Koul
2025-12-23 12:35             ` Bartosz Golaszewski
2025-12-23 20:19               ` Dmitry Baryshkov
2025-12-24  8:58                 ` Bartosz Golaszewski
2025-12-24  9:33                   ` Dmitry Baryshkov
2026-01-01 12:00               ` Vinod Koul
2026-01-02  9:26                 ` Bartosz Golaszewski
2026-01-02 16:59                   ` Vinod Koul
2026-01-02 17:14                     ` Bartosz Golaszewski
2026-01-06 12:20                       ` Bartosz Golaszewski
2026-01-09  2:27                       ` Vinod Koul
2026-01-09 14:15                         ` Bartosz Golaszewski
2026-01-14 15:37                           ` Bartosz Golaszewski
2026-01-22  9:33                             ` Bartosz Golaszewski
2026-02-03 13:39                               ` Bartosz Golaszewski
2026-02-19 12:12                           ` Manivannan Sadhasivam
2026-02-19 12:49                             ` Dmitry Baryshkov
2026-02-19 13:26                             ` Bjorn Andersson
2026-02-19 13:30                             ` Bartosz Golaszewski
2026-02-19 14:40                               ` Manivannan Sadhasivam
2026-02-25  9:52                                 ` Vinod Koul
2026-02-27 21:32                                   ` Bartosz Golaszewski
2026-01-14 16:04                         ` Dmitry Baryshkov
2025-11-28 11:44 ` [PATCH v9 04/11] crypto: qce - Include algapi.h in the core.h header Bartosz Golaszewski
2025-11-28 11:44 ` [PATCH v9 05/11] crypto: qce - Remove unused ignore_buf Bartosz Golaszewski
2025-11-28 12:01   ` Konrad Dybcio
2025-11-28 12:05     ` Bartosz Golaszewski
2025-11-28 12:09       ` Konrad Dybcio
2025-11-28 11:44 ` [PATCH v9 06/11] crypto: qce - Simplify arguments of devm_qce_dma_request() Bartosz Golaszewski
2025-11-28 11:44 ` [PATCH v9 07/11] crypto: qce - Use existing devres APIs in devm_qce_dma_request() Bartosz Golaszewski
2025-11-28 12:03   ` Konrad Dybcio
2025-11-28 11:44 ` [PATCH v9 08/11] crypto: qce - Map crypto memory for DMA Bartosz Golaszewski
2025-11-28 11:44 ` [PATCH v9 09/11] crypto: qce - Add BAM DMA support for crypto register I/O Bartosz Golaszewski
2025-11-28 11:44 ` [PATCH v9 10/11] crypto: qce - Add support for BAM locking Bartosz Golaszewski
2025-12-01 13:03   ` Konrad Dybcio
2025-12-18 15:32     ` Bartosz Golaszewski
2025-11-28 11:44 ` [PATCH v9 11/11] crypto: qce - Switch to using BAM DMA for crypto I/O Bartosz Golaszewski
2025-11-28 12:08   ` Konrad Dybcio
2025-11-28 12:11     ` Bartosz Golaszewski
2025-11-28 12:57       ` Konrad Dybcio
2025-12-06 11:45   ` Dmitry Baryshkov

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=aUF2gj_0svpygHmD@vaman \
    --to=vkoul@kernel.org \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=brgl@kernel.org \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=dmaengine@vger.kernel.org \
    --cc=dperezzo@quicinc.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=lumag@kernel.org \
    --cc=mdalam@qti.qualcomm.com \
    --cc=quic_utiwari@quicinc.com \
    --cc=thara.gopinath@gmail.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.