linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Frank Li <Frank.Li@nxp.com>
Cc: gustavo.pimentel@synopsys.com, hongxing.zhu@nxp.com,
	l.stach@pengutronix.de, linux-imx@nxp.com,
	linux-pci@vger.kernel.org, lznuaa@gmail.com, vkoul@kernel.org,
	lorenzo.pieralisi@arm.com, robh@kernel.org, kw@linux.com,
	bhelgaas@google.com, shawnguo@kernel.org,
	Jingoo Han <jingoohan1@gmail.com>
Subject: Re: [PATCH 4/5] PCI: imx6: add PCIe embedded DMA support
Date: Wed, 2 Mar 2022 14:15:20 -0600	[thread overview]
Message-ID: <20220302201520.GA746237@bhelgaas> (raw)
In-Reply-To: <20220302032646.3793-4-Frank.Li@nxp.com>

[+cc Jingoo for DesignWare generic question]

In subject:

  PCI: imx6: Add embedded DMA support

to match existing style.  "PCIe" seems superfluous here since we
already mentioned it earlier in the subject.

On Tue, Mar 01, 2022 at 09:26:45PM -0600, Frank Li wrote:
> Designware PCIe control have embedded DMA controller.
> This enable the DMA controller support.

Maybe:

  Add support for the DMA controller in the DesignWare PCIe core.

If this DMA controller is in the DesignWare core, is everything in
this patch specific to imx6?  Or could some of it be shared with other
dwc-based drivers?

> The DMA can transfer data to any remote address location
> regardless PCI address space size.

What is this sentence telling us?  Is it merely that the DMA "inbound
address space" may be larger than the MMIO "outbound address space"?
I think there's no necessary connection between them, and there's no
need to call it out as though it's something special.

> Prepare struct dw_edma_chip and call dw_edma_probe

"dw_edma_probe()" so it's obvious this is a function.

> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
>  drivers/pci/controller/dwc/pci-imx6.c | 61 +++++++++++++++++++++++++++
>  1 file changed, 61 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index efa8b81711090..a588b848a1650 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -38,6 +38,7 @@
>  #include "../../pci.h"
>  
>  #include "pcie-designware.h"
> +#include "linux/dma/edma.h"
>  
>  #define IMX8MQ_PCIE_LINK_CAP_REG_OFFSET		0x7c
>  #define IMX8MQ_PCIE_LINK_CAP_L1EL_64US		GENMASK(18, 17)
> @@ -164,6 +165,8 @@ struct imx6_pcie {
>  	const struct imx6_pcie_drvdata *drvdata;
>  	struct regulator	*epdev_on;
>  	struct phy		*phy;
> +
> +	struct dw_edma_chip	dma_chip;
>  };
>  
>  /* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */
> @@ -2031,6 +2034,61 @@ static const struct dw_pcie_ep_ops pcie_ep_ops = {
>  	.get_features = imx_pcie_ep_get_features,
>  };
>  
> +static int imx_dma_irq_vector(struct device *dev, unsigned int nr)

Function names should match existing style in this driver, i.e., they
should start with "imx6", not "imx".

> +{
> +	struct platform_device *pdev = to_platform_device(dev);
> +
> +	return platform_get_irq_byname(pdev, "dma");
> +}
> +
> +static struct dw_edma_core_ops dma_ops = {
> +	.irq_vector = imx_dma_irq_vector,
> +};
> +
> +static int imx_add_pcie_dma(struct imx6_pcie *imx6_pcie,
> +			    struct platform_device *pdev,

You don't use "pdev" in this function, so no need to pass it in.

> +			    struct resource *dbi_base)

IIUC this is already in pci->dbi_base, so why not use that instead of
passing it in?  Passing both a struct and the contents of a member of
the struct is an opportunity for a mistake.

> +{
> +	unsigned int pcie_dma_offset;
> +	struct dw_pcie *pci = imx6_pcie->pci;
> +	struct device *dev = pci->dev;
> +	struct dw_edma_chip *dma = &imx6_pcie->dma_chip;
> +	int i = 0;
> +	u64 pbase;
> +	void *vbase;
> +	int sz = PAGE_SIZE;
> +
> +	pcie_dma_offset = 0x970;
> +
> +	pbase = dbi_base->start + pcie_dma_offset;
> +	vbase = pci->dbi_base + pcie_dma_offset;
> +
> +	dma->dev = dev;
> +
> +	dma->rg_region.paddr = pbase;
> +	dma->rg_region.vaddr = vbase;
> +	dma->rg_region.sz = 0x424;
> +
> +	dma->wr_ch_cnt = dma->rd_ch_cnt = 1;
> +
> +	dma->ops = &dma_ops;
> +	dma->nr_irqs = 1;
> +
> +	dma->flags = DW_EDMA_CHIP_NO_MSI | DW_EDMA_CHIP_REG32BIT | DW_EDMA_CHIP_LOCAL_EP;
> +
> +	dma->ll_region_wr[0].sz = sz;
> +	dma->ll_region_wr[0].vaddr = dmam_alloc_coherent(dev, sz,
> +							 &dma->ll_region_wr[i].paddr,
> +							 GFP_KERNEL);
> +
> +	dma->ll_region_rd[0].sz = sz;
> +	dma->ll_region_rd[0].vaddr = dmam_alloc_coherent(dev, sz,
> +							 &dma->ll_region_rd[i].paddr,
> +							 GFP_KERNEL);
> +
> +	return dw_edma_probe(dma);
> +}
> +
>  static int imx_add_pcie_ep(struct imx6_pcie *imx6_pcie,
>  					struct platform_device *pdev)
>  {
> @@ -2694,6 +2752,9 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  		goto err_ret;
>  	}
>  
> +	if (imx_add_pcie_dma(imx6_pcie, pdev, dbi_base))
> +		dev_info(dev, "pci edma probe failure\n");
> +
>  	return 0;
>  
>  err_ret:
> -- 
> 2.24.0.rc1
> 

  reply	other threads:[~2022-03-02 20:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-02  3:26 [PATCH 1/5] dmaengine: dw-edma: fix dw_edma_probe() can't be call globally Frank Li
2022-03-02  3:26 ` [PATCH 2/5] dmaengine: dw-edma-pcie: don't touch internal struct dw_edma Frank Li
2022-03-03  9:56   ` Manivannan Sadhasivam
2022-03-02  3:26 ` [PATCH 3/5] dmaengine: dw-edma: add flags at struct dw_edma_chip Frank Li
2022-03-02  3:26 ` [PATCH 4/5] PCI: imx6: add PCIe embedded DMA support Frank Li
2022-03-02 20:15   ` Bjorn Helgaas [this message]
2022-03-02 20:49     ` Zhi Li
2022-03-02 21:21       ` Bjorn Helgaas
2022-03-02 21:28         ` Zhi Li
2022-03-03 17:48           ` Bjorn Helgaas
2022-03-03 18:00             ` Zhi Li
2022-03-02  3:26 ` [PATCH 5/5] PCI: endpoint: functions/pci-epf-test: Support PCI controller DMA Frank Li
2022-03-03  9:42 ` [PATCH 1/5] dmaengine: dw-edma: fix dw_edma_probe() can't be call globally Manivannan Sadhasivam
2022-03-03 10:05 ` 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=20220302201520.GA746237@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=Frank.Li@nxp.com \
    --cc=bhelgaas@google.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=hongxing.zhu@nxp.com \
    --cc=jingoohan1@gmail.com \
    --cc=kw@linux.com \
    --cc=l.stach@pengutronix.de \
    --cc=linux-imx@nxp.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=lznuaa@gmail.com \
    --cc=robh@kernel.org \
    --cc=shawnguo@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).