linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Serge Semin <fancer.lancer@gmail.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: "Siddharth Vadapalli" <s-vadapalli@ti.com>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Gustavo Pimentel" <gustavo.pimentel@synopsys.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Marek Vasut" <marek.vasut+renesas@gmail.com>,
	"Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-renesas-soc@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	mhi@lists.linux.dev
Subject: Re: [PATCH v3 1/5] PCI: dwc: Refactor dw_pcie_edma_find_chip() API
Date: Mon, 26 Feb 2024 15:45:16 +0300	[thread overview]
Message-ID: <fielxplkgrvz5qmqrrq5ahmah5yqx7anjylrlcqyev2z2cl2wo@3ltyl242vkba> (raw)
In-Reply-To: <20240226-dw-hdma-v3-1-cfcb8171fc24@linaro.org>

Hi Manivannan

On Mon, Feb 26, 2024 at 05:07:26PM +0530, Manivannan Sadhasivam wrote:
> In order to add support for Hyper DMA (HDMA), let's refactor the existing
> dw_pcie_edma_find_chip() API by moving the common code to separate
> functions.
> 
> No functional change.
> 
> Suggested-by: Serge Semin <fancer.lancer@gmail.com>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
>  drivers/pci/controller/dwc/pcie-designware.c | 52 +++++++++++++++++++++-------
>  1 file changed, 39 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
> index 250cf7f40b85..193fcd86cf93 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -880,7 +880,17 @@ static struct dw_edma_plat_ops dw_pcie_edma_ops = {
>  	.irq_vector = dw_pcie_edma_irq_vector,
>  };
>  
> -static int dw_pcie_edma_find_chip(struct dw_pcie *pci)
> +static void dw_pcie_edma_init_data(struct dw_pcie *pci)
> +{
> +	pci->edma.dev = pci->dev;
> +
> +	if (!pci->edma.ops)
> +		pci->edma.ops = &dw_pcie_edma_ops;
> +
> +	pci->edma.flags |= DW_EDMA_CHIP_LOCAL;
> +}
> +
> +static int dw_pcie_edma_find_mf(struct dw_pcie *pci)
>  {
>  	u32 val;
>  
> @@ -900,24 +910,27 @@ static int dw_pcie_edma_find_chip(struct dw_pcie *pci)
>  	else
>  		val = dw_pcie_readl_dbi(pci, PCIE_DMA_VIEWPORT_BASE + PCIE_DMA_CTRL);
> 

> -	if (val == 0xFFFFFFFF && pci->edma.reg_base) {
> -		pci->edma.mf = EDMA_MF_EDMA_UNROLL;
> -
> -		val = dw_pcie_readl_dma(pci, PCIE_DMA_CTRL);
> -	} else if (val != 0xFFFFFFFF) {
> -		pci->edma.mf = EDMA_MF_EDMA_LEGACY;
> +	/* Set default mapping format here and update it below if needed */
> +	pci->edma.mf = EDMA_MF_EDMA_LEGACY;
>  
> +	if (val == 0xFFFFFFFF && pci->edma.reg_base)
> +		pci->edma.mf = EDMA_MF_EDMA_UNROLL;
> +	else if (val != 0xFFFFFFFF)
>  		pci->edma.reg_base = pci->dbi_base + PCIE_DMA_VIEWPORT_BASE;
> -	} else {
> +	else
>  		return -ENODEV;
> -	}

Sorry for not posting my opinion about this earlier, but IMO v2 code
was more correct than this one. This version makes the code being not
linear as it was in v2, thus harder to comprehend:

1. Setting up a default value and then overriding it or not makes the
reader to keep in mind the initialized value which is harder than to
just read what is done in the respective branch.

2. Splitting up the case clause with respective inits and the mapping
format setting up also makes it harder to comprehend what's going on.
In the legacy case the reg-base address and the mapping format init are
split up while they should have been done simultaneously only if (val
!= 0xFFFFFFFF).

3. The most of the current devices has the unrolled mapping (available
since v4.9 IP-core), thus having the mf field pre-initialized produces
a redundant store operation for the most of the modern devices.

4. Getting rid from the curly braces isn't something what should be
avoided at any cost and doesn't give any optimization really. It
doesn't cause having less C-lines of the source code and doesn't
improve the code readability.

So to speak, I'd suggest to get back the v2 implementation here.

>  
> -	pci->edma.dev = pci->dev;
> +	return 0;
> +}
>  
> -	if (!pci->edma.ops)
> -		pci->edma.ops = &dw_pcie_edma_ops;
> +static int dw_pcie_edma_find_channels(struct dw_pcie *pci)
> +{
> +	u32 val;
>  
> -	pci->edma.flags |= DW_EDMA_CHIP_LOCAL;

> +	if (pci->edma.mf == EDMA_MF_EDMA_LEGACY)
> +		val = dw_pcie_readl_dbi(pci, PCIE_DMA_VIEWPORT_BASE + PCIE_DMA_CTRL);
> +	else
> +		val = dw_pcie_readl_dma(pci, PCIE_DMA_CTRL);

Just dw_pcie_readl_dma(pci, PCIE_DMA_CTRL)

-Serge(y)

>  
>  	pci->edma.ll_wr_cnt = FIELD_GET(PCIE_DMA_NUM_WR_CHAN, val);
>  	pci->edma.ll_rd_cnt = FIELD_GET(PCIE_DMA_NUM_RD_CHAN, val);
> @@ -930,6 +943,19 @@ static int dw_pcie_edma_find_chip(struct dw_pcie *pci)
>  	return 0;
>  }
>  
> +static int dw_pcie_edma_find_chip(struct dw_pcie *pci)
> +{
> +	int ret;
> +
> +	dw_pcie_edma_init_data(pci);
> +
> +	ret = dw_pcie_edma_find_mf(pci);
> +	if (ret)
> +		return ret;
> +
> +	return dw_pcie_edma_find_channels(pci);
> +}
> +
>  static int dw_pcie_edma_irq_verify(struct dw_pcie *pci)
>  {
>  	struct platform_device *pdev = to_platform_device(pci->dev);
> 
> -- 
> 2.25.1
> 

  parent reply	other threads:[~2024-02-26 12:45 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-26 11:37 [PATCH v3 0/5] PCI: dwc: Add support for integrating HDMA with DWC EP driver Manivannan Sadhasivam
2024-02-26 11:37 ` [PATCH v3 1/5] PCI: dwc: Refactor dw_pcie_edma_find_chip() API Manivannan Sadhasivam
2024-02-26 12:02   ` Siddharth Vadapalli
2024-02-26 12:45   ` Serge Semin [this message]
2024-02-26 15:27     ` Manivannan Sadhasivam
2024-02-26 21:00       ` Serge Semin
2024-02-27  7:34         ` Manivannan Sadhasivam
2024-02-26 16:24   ` Frank Li
2024-02-26 11:37 ` [PATCH v3 2/5] PCI: dwc: Skip finding eDMA channels count if glue drivers have passed them Manivannan Sadhasivam
2024-02-26 12:53   ` Serge Semin
2024-02-26 15:30     ` Manivannan Sadhasivam
2024-02-26 21:32       ` Serge Semin
2024-02-27  8:42         ` Manivannan Sadhasivam
2024-02-27 12:21           ` Serge Semin
2024-03-04  6:17             ` Manivannan Sadhasivam
2024-02-26 16:26   ` Frank Li
2024-02-26 11:37 ` [PATCH v3 3/5] PCI: dwc: Pass the eDMA mapping format flag directly from glue drivers Manivannan Sadhasivam
2024-02-26 12:57   ` Serge Semin
2024-02-26 16:30   ` Frank Li
2024-02-27  7:45     ` Manivannan Sadhasivam
2024-02-27 17:38       ` Frank Li
2024-03-04  6:19         ` Manivannan Sadhasivam
2024-02-26 11:37 ` [PATCH v3 4/5] PCI: qcom-ep: Add HDMA support for SA8775P SoC Manivannan Sadhasivam
2024-02-26 16:32   ` Frank Li
2024-02-26 11:37 ` [PATCH v3 5/5] PCI: epf-mhi: Enable HDMA " Manivannan Sadhasivam
2024-02-26 16:34   ` 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=fielxplkgrvz5qmqrrq5ahmah5yqx7anjylrlcqyev2z2cl2wo@3ltyl242vkba \
    --to=fancer.lancer@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=jingoohan1@gmail.com \
    --cc=kishon@kernel.org \
    --cc=kw@linux.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=marek.vasut+renesas@gmail.com \
    --cc=mhi@lists.linux.dev \
    --cc=robh@kernel.org \
    --cc=s-vadapalli@ti.com \
    --cc=yoshihiro.shimoda.uh@renesas.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 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).