linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: "Gustavo Pimentel" <gustavo.pimentel@synopsys.com>,
	"Vinod Koul" <vkoul@kernel.org>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Frank Li" <Frank.Li@nxp.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Serge Semin" <fancer.lancer@gmail.com>,
	"Alexey Malahov" <Alexey.Malahov@baikalelectronics.ru>,
	"Pavel Parkhomenko" <Pavel.Parkhomenko@baikalelectronics.ru>,
	linux-pci@vger.kernel.org, dmaengine@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 25/25] PCI: dwc: Add DW eDMA engine support
Date: Mon, 28 Mar 2022 19:45:21 +0530	[thread overview]
Message-ID: <20220328141521.GA17663@thinkpad> (raw)
In-Reply-To: <20220324014836.19149-26-Sergey.Semin@baikalelectronics.ru>

On Thu, Mar 24, 2022 at 04:48:36AM +0300, Serge Semin wrote:
> Since the DW eDMA driver now supports eDMA controllers embedded into the
> locally accessible DW PCIe Root Ports and End-points, we can use the
> updated interface to register DW eDMA as DMA engine device if it's
> available. In order to successfully do that the DW PCIe core driver need
> to perform some preparations first. First of all it needs to find out the
> eDMA controller CSRs base address, whether they are accessible over the
> Port Logic or iATU unrolled space. Afterwards it can try to auto-detect
> the eDMA controller availability and number of it's read/write channels.
> If none was found the procedure will just silently halt with no error
> returned. Secondly the platform is supposed to provide either combined or
> per-channel IRQ signals. If no valid IRQs set is found the procedure will
> also halt with no error returned so to be backward compatible with
> platforms where DW PCIe controllers have eDMA embedded but lack of the
> IRQs defined for them. Finally before actually probing the eDMA device we
> need to allocate LLP items buffers. After that the DW eDMA can be
> registered. If registration is successful the info-message regarding the
> number of detected Read/Write eDMA channels will be printed to the system
> log in the same way as it's done for iATU settings.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>  .../pci/controller/dwc/pcie-designware-ep.c   |   4 +
>  .../pci/controller/dwc/pcie-designware-host.c |  13 +-
>  drivers/pci/controller/dwc/pcie-designware.c  | 188 ++++++++++++++++++
>  drivers/pci/controller/dwc/pcie-designware.h  |  23 ++-
>  4 files changed, 225 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index 23401f17e8f0..b2840d1a5b9a 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -712,6 +712,10 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
>  
>  	dw_pcie_iatu_detect(pci);
>  
> +	ret = dw_pcie_edma_detect(pci);
> +	if (ret)
> +		return ret;
> +
>  	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
>  	if (!res)
>  		return -EINVAL;

eDMA needs to be removed on error path

> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 715a13b90e43..048b452ee4f3 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -405,14 +405,18 @@ int dw_pcie_host_init(struct pcie_port *pp)
>  
>  	dw_pcie_iatu_detect(pci);
>  
> -	ret = dw_pcie_setup_rc(pp);
> +	ret = dw_pcie_edma_detect(pci);
>  	if (ret)
>  		goto err_free_msi;
>  
> +	ret = dw_pcie_setup_rc(pp);
> +	if (ret)
> +		goto err_edma_remove;
> +
>  	if (!dw_pcie_link_up(pci) && pci->ops && pci->ops->start_link) {
>  		ret = pci->ops->start_link(pci);
>  		if (ret)
> -			goto err_free_msi;
> +			goto err_edma_remove;
>  	}
>  
>  	/* Ignore errors, the link may come up later */
> @@ -430,6 +434,9 @@ int dw_pcie_host_init(struct pcie_port *pp)
>  	if (pci->ops && pci->ops->stop_link)
>  		pci->ops->stop_link(pci);
>  
> +err_edma_remove:
> +	dw_pcie_edma_remove(pci);
> +
>  err_free_msi:
>  	if (pp->has_msi_ctrl)
>  		dw_pcie_free_msi(pp);
> @@ -452,6 +459,8 @@ void dw_pcie_host_deinit(struct pcie_port *pp)
>  	if (pci->ops && pci->ops->stop_link)
>  		pci->ops->stop_link(pci);
>  
> +	dw_pcie_edma_remove(pci);
> +
>  	if (pp->has_msi_ctrl)
>  		dw_pcie_free_msi(pp);
>  
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
> index 4a95a7b112e9..dbe39a7ecb71 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c

[...]

> +int dw_pcie_edma_detect(struct dw_pcie *pci)
> +{
> +	int ret;
> +
> +	pci->edma.dev = pci->dev;
> +	if (!pci->edma.ops)
> +		pci->edma.ops = &dw_pcie_edma_ops;
> +	pci->edma.flags |= DW_EDMA_CHIP_LOCAL;
> +
> +	pci->edma_unroll_enabled = dw_pcie_edma_unroll_enabled(pci);

Is is possible to continue the unroll path for eDMA if iATU unroll is enabled?

> +	if (pci->edma_unroll_enabled && pci->iatu_unroll_enabled) {
> +		pci->edma.mf = EDMA_MF_EDMA_UNROLL;
> +		if (pci->atu_base != pci->dbi_base + DEFAULT_DBI_ATU_OFFSET)
> +			pci->edma.reg_base = pci->atu_base + PCIE_DMA_UNROLL_BASE;
> +		else
> +			pci->edma.reg_base = pci->dbi_base + DEFAULT_DBI_DMA_OFFSET;

This assumption won't work on all platforms. Atleast on our platform, the
offsets vary. So I'd suggest to try getting the reg_base from DT first and use
these offsets as a fallback as we do for iATU.

> +	} else {
> +		pci->edma.mf = EDMA_MF_EDMA_LEGACY;
> +		pci->edma.reg_base = pci->dbi_base + PCIE_DMA_VIEWPORT_BASE;
> +	}
> +
> +	ret = dw_pcie_edma_detect_channels(pci);
> +	if (ret) {
> +		dev_err(pci->dev, "Unexpected NoF eDMA channels found\n");
> +		return ret;
> +	}
> +
> +	/* Skip any further initialization if no eDMA found */

Should we introduce a new Kconfig option for enabling eDMA? My concern here is,
if eDMA is really needed for an usecase and if the platform support is broken
somehow (DT issues?), then we'll just simply go ahead without probe failure and
it may break somewhere else.

And we are returning errors if something wrong happens during eDMA probe. This
might annoy the existing users who don't care about eDMA but turning those
errors to debug will affect the real users of eDMA.

For these reasons, I think it'd be better to probe eDMA only if the Kconfig
option is enabled (which would be disabled by default). And properly return the
failure.

Thanks,
Mani

  reply	other threads:[~2022-03-28 14:15 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-24  1:48 [PATCH 00/25] dmaengine: dw-edma: Add RP/EP local DMA controllers support Serge Semin
2022-03-24  1:48 ` [PATCH 01/25] dmaengine: dw-edma: Drop dma_slave_config.direction field usage Serge Semin
2022-03-24 13:30   ` Manivannan Sadhasivam
2022-04-05 11:15     ` Serge Semin
2022-03-24  1:48 ` [PATCH 02/25] dmaengine: dw-edma: Fix eDMA Rd/Wr-channels and DMA-direction semantics Serge Semin
2022-03-24  1:48 ` [PATCH 03/25] dma-direct: take dma-ranges/offsets into account in resource mapping Serge Semin
2022-03-24 11:30   ` Robin Murphy
2022-04-17 22:44     ` Serge Semin
2022-04-20  7:12       ` Christoph Hellwig
2022-04-20  8:32         ` Serge Semin
2022-04-20  8:47           ` Christoph Hellwig
2022-04-20  8:55             ` Serge Semin
2022-04-21 14:45               ` Christoph Hellwig
2022-04-21 17:35                 ` Serge Semin
2022-04-21 20:51                   ` Robin Murphy
2022-04-24 21:46                     ` Serge Semin
2022-03-24  1:48 ` [PATCH 04/25] dmaengine: Fix dma_slave_config.dst_addr description Serge Semin
2022-03-24 14:08   ` Manivannan Sadhasivam
2022-03-31  5:38     ` Vinod Koul
2022-03-31  7:13       ` Serge Semin
2022-03-31 10:50         ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 05/25] dmaengine: dw-edma: Convert ll/dt phys-address to PCIe bus/DMA address Serge Semin
2022-03-24 16:23   ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 06/25] dmaengine: dw-edma: Fix missing src/dst address of the interleaved xfers Serge Semin
2022-03-24 16:26   ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 07/25] dmaengine: dw-edma: Don't permit non-inc " Serge Semin
2022-03-24 17:15   ` Manivannan Sadhasivam
2022-04-17 22:59     ` Serge Semin
2022-03-24  1:48 ` [PATCH 08/25] dmaengine: dw-edma: Fix invalid interleaved xfers semantics Serge Semin
2022-03-24  1:48 ` [PATCH 09/25] dmaengine: dw-edma: Add CPU to PCIe bus address translation Serge Semin
2022-03-24 17:25   ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 10/25] dmaengine: dw-edma: Add PCIe bus address getter to the remote EP glue-driver Serge Semin
2022-03-24 17:41   ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 11/25] dmaengine: dw-edma: Drop chancnt initialization Serge Semin
2022-03-24 17:42   ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 12/25] dmaengine: dw-edma: Fix DebugFS reg entry type Serge Semin
2022-03-24 17:48   ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 13/25] dmaengine: dw-edma: Stop checking debugfs_create_*() return value Serge Semin
2022-03-24 18:12   ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 14/25] dmaengine: dw-edma: Add dw_edma prefix to the DebugFS nodes descriptor Serge Semin
2022-03-24 18:14   ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 15/25] dmaengine: dw-edma: Convert DebugFS descs to being kz-allocated Serge Semin
2022-03-25  6:03   ` Manivannan Sadhasivam
2022-03-25  6:42     ` Manivannan Sadhasivam
2022-04-18  7:17     ` Serge Semin
2022-03-24  1:48 ` [PATCH 16/25] dmaengine: dw-edma: Simplify the DebugFS context CSRs init procedure Serge Semin
2022-03-25  6:27   ` Manivannan Sadhasivam
2022-03-25  6:31     ` Manivannan Sadhasivam
2022-04-18  8:23     ` Serge Semin
2022-03-24  1:48 ` [PATCH 17/25] dmaengine: dw-edma: Move eDMA data pointer to DebugFS node descriptor Serge Semin
2022-03-25  6:35   ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 18/25] dmaengine: dw-edma: Join Write/Read channels into a single device Serge Semin
2022-03-25  7:34   ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 19/25] dmaengine: dw-edma: Use DMA-engine device DebugFS subdirectory Serge Semin
2022-03-25  7:41   ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 20/25] dmaengine: dw-edma: Use non-atomic io-64 methods Serge Semin
2022-03-25  8:28   ` Manivannan Sadhasivam
2022-04-18 11:37     ` Serge Semin
2022-03-24  1:48 ` [PATCH 21/25] dmaengine: dw-edma: Drop DT-region allocation Serge Semin
2022-03-25  8:33   ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 22/25] dmaengine: dw-edma: Replace chip ID number with device name Serge Semin
2022-03-25 10:02   ` Manivannan Sadhasivam
2022-04-18 12:17     ` Serge Semin
2022-03-24  1:48 ` [PATCH 23/25] dmaengine: dw-edma: Bypass dma-ranges mapping for the local setup Serge Semin
2022-03-25 18:10   ` Manivannan Sadhasivam
2022-04-18 13:36     ` Serge Semin
2022-03-24  1:48 ` [PATCH 24/25] dmaengine: dw-edma: Skip cleanup procedure if no private data found Serge Semin
2022-03-25 18:15   ` Manivannan Sadhasivam
2022-04-18 13:48     ` Serge Semin
2022-04-23 14:45       ` Manivannan Sadhasivam
2022-03-24  1:48 ` [PATCH 25/25] PCI: dwc: Add DW eDMA engine support Serge Semin
2022-03-28 14:15   ` Manivannan Sadhasivam [this message]
2022-04-19 20:54     ` Serge Semin
2022-04-23 14:40       ` Manivannan Sadhasivam
2022-04-25  5:22         ` Manivannan Sadhasivam
2022-04-28 14:05         ` Serge Semin
2022-04-28 17:09           ` Manivannan Sadhasivam
2022-04-29 16:13             ` Serge Semin
2022-04-29 17:20               ` Manivannan Sadhasivam

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=20220328141521.GA17663@thinkpad \
    --to=manivannan.sadhasivam@linaro.org \
    --cc=Alexey.Malahov@baikalelectronics.ru \
    --cc=Frank.Li@nxp.com \
    --cc=Pavel.Parkhomenko@baikalelectronics.ru \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=bhelgaas@google.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=fancer.lancer@gmail.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=jingoohan1@gmail.com \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=robh@kernel.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).