All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: "Frank Li" <Frank.Li@nxp.com>, "Vinod Koul" <vkoul@kernel.org>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Sagi Grimberg" <sagi@grimberg.me>,
	"Chaitanya Kulkarni" <kch@nvidia.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	"Nicolas Ferre" <nicolas.ferre@microchip.com>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	"Claudiu Beznea" <claudiu.beznea@tuxon.dev>,
	"Koichiro Den" <den@valinux.co.jp>,
	"Niklas Cassel" <cassel@kernel.org>
Cc: dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-nvme@lists.infradead.org,
	mhi@lists.linux.dev, linux-arm-msm@vger.kernel.org,
	linux-crypto@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
Subject: Re: [PATCH v2 6/8] nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API
Date: Fri, 19 Dec 2025 19:42:57 +0900	[thread overview]
Message-ID: <0fa95ea2-4539-472b-adae-300e46a78f20@kernel.org> (raw)
In-Reply-To: <20251218-dma_prep_config-v2-6-c07079836128@nxp.com>

On 12/19/25 00:56, Frank Li wrote:
> Use the new dmaengine_prep_config_single_safe() API to combine the
> configuration and descriptor preparation into a single call.
> 
> Since dmaengine_prep_config_single_safe() performs the configuration and
> preparation atomically and dw edma driver implement prep_config_sg() call
> back, so dmaengine_prep_config_single() is reentriable, the mutex can be
> removed.

What about for platforms other than DesignWare EDMA ?
This is a generic endpoint driver that can work on any platform that is endpoint
capable and that has a DMA channel for the PCI endpoint.

The dmaengine_prep_config_single_safe() API should be handling everything
transparently for any platform, regardless of the DMA channel driver
implementing or not the prep_config_sg() callback.

For platforms that do not implement it, I suspect that the mutex will still be
needed here. So how to we resolve this ? Ideally, all of that should be hidden
by the DMA API. The endpoint driver should not need to deal with these differences.

> 
> Tested-by: Niklas Cassel <cassel@kernel.org>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
>  drivers/nvme/target/pci-epf.c | 18 ++++--------------
>  1 file changed, 4 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
> index 56b1c6a7706a9e2dd9d8aaf17b440129b948486c..8b5ea5d4c79dfd461b767cfd4033a9e4604c94b1 100644
> --- a/drivers/nvme/target/pci-epf.c
> +++ b/drivers/nvme/target/pci-epf.c
> @@ -388,22 +388,15 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
>  		return -EINVAL;
>  	}
>  
> -	mutex_lock(lock);
> -
>  	dma_dev = dmaengine_get_dma_device(chan);
>  	dma_addr = dma_map_single(dma_dev, seg->buf, seg->length, dir);
>  	ret = dma_mapping_error(dma_dev, dma_addr);
>  	if (ret)
> -		goto unlock;
> -
> -	ret = dmaengine_slave_config(chan, &sconf);
> -	if (ret) {
> -		dev_err(dev, "Failed to configure DMA channel\n");
> -		goto unmap;
> -	}
> +		return ret;
>  
> -	desc = dmaengine_prep_slave_single(chan, dma_addr, seg->length,
> -					   sconf.direction, DMA_CTRL_ACK);
> +	desc = dmaengine_prep_config_single_safe(chan, dma_addr, seg->length,
> +						 sconf.direction,
> +						 DMA_CTRL_ACK, &sconf);
>  	if (!desc) {
>  		dev_err(dev, "Failed to prepare DMA\n");
>  		ret = -EIO;
> @@ -426,9 +419,6 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
>  unmap:
>  	dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
>  
> -unlock:
> -	mutex_unlock(lock);
> -
>  	return ret;
>  }
>  
> 


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2025-12-19 10:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-18 15:56 [PATCH v2 0/8] dmaengine: Add new API to combine onfiguration and descriptor preparation Frank Li
2025-12-18 15:56 ` [PATCH v2 1/8] dmaengine: Add API to combine configuration and preparation (sg and single) Frank Li
2025-12-19 10:33   ` Damien Le Moal
2025-12-23 10:41   ` Vinod Koul
2026-03-09 11:04   ` Vinod Koul
2026-03-09 14:42     ` Frank Li
2026-03-17 10:37       ` Vinod Koul
2026-03-17 14:04         ` Frank Li
2025-12-18 15:56 ` [PATCH v2 2/8] PCI: endpoint: pci-epf-test: Use dmaenigne_prep_config_single() to simplify code Frank Li
2025-12-19 10:34   ` Damien Le Moal
2025-12-18 15:56 ` [PATCH v2 3/8] dmaengine: dw-edma: Use new .device_prep_config_sg() callback Frank Li
2025-12-19 10:35   ` Damien Le Moal
2025-12-18 15:56 ` [PATCH v2 4/8] dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer() Frank Li
2025-12-19 10:38   ` Damien Le Moal
2025-12-18 15:56 ` [PATCH v2 5/8] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer Frank Li
2025-12-19 10:38   ` Damien Le Moal
2025-12-18 15:56 ` [PATCH v2 6/8] nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API Frank Li
2025-12-19 10:42   ` Damien Le Moal [this message]
2025-12-18 15:56 ` [PATCH v2 7/8] PCI: epf-mhi: Use dmaengine_prep_config_single() to simplify code Frank Li
2025-12-18 15:56 ` [PATCH v2 8/8] crypto: atmel: Use dmaengine_prep_config_single() API Frank Li

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=0fa95ea2-4539-472b-adae-300e46a78f20@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=Frank.Li@nxp.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=bhelgaas@google.com \
    --cc=cassel@kernel.org \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=davem@davemloft.net \
    --cc=den@valinux.co.jp \
    --cc=dmaengine@vger.kernel.org \
    --cc=hch@lst.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=imx@lists.linux.dev \
    --cc=kch@nvidia.com \
    --cc=kishon@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=mhi@lists.linux.dev \
    --cc=nicolas.ferre@microchip.com \
    --cc=sagi@grimberg.me \
    --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 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.