linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Dilip Kota <eswara.kota@linux.intel.com>
Cc: gustavo.pimentel@synopsys.com, lorenzo.pieralisi@arm.com,
	andrew.murray@arm.com, helgaas@kernel.org, jingoohan1@gmail.com,
	robh@kernel.org, martin.blumenstingl@googlemail.com,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, cheol.yong.kim@intel.com,
	chuanhua.lei@linux.intel.com, qi-ming.wu@intel.com
Subject: Re: [PATCH v5 2/3] dwc: PCI: intel: PCIe RC controller driver
Date: Wed, 6 Nov 2019 14:24:52 +0200	[thread overview]
Message-ID: <20191106122452.GA32742@smile.fi.intel.com> (raw)
In-Reply-To: <ac63d9856323555736c5b361612df3ee49b0f998.1572950559.git.eswara.kota@linux.intel.com>

On Wed, Nov 06, 2019 at 11:44:02AM +0800, Dilip Kota wrote:
> Add support to PCIe RC controller on Intel Gateway SoCs.
> PCIe controller is based of Synopsys DesignWare PCIe core.
> 
> Intel PCIe driver requires Upconfigure support, fast training
> sequence and link speed configuration. So adding the respective
> helper functions in the PCIe DesignWare framework.
> It also programs hardware autonomous speed during speed
> configuration so defining it in pci_regs.h.

My comments below, though I may miss the discussion and comment on the settled
things.

> +config PCIE_INTEL_GW
> +        bool "Intel Gateway PCIe host controller support"
> +	depends on OF && (X86 || COMPILE_TEST)
> +	select PCIE_DW_HOST
> +	help
> +          Say 'Y' here to enable PCIe Host controller support on Intel
> +	  Gateway SoCs.
> +	  The PCIe controller uses the DesignWare core plus Intel-specific
> +	  hardware wrappers.

Above has indentation issues.

> +void dw_pcie_upconfig_setup(struct dw_pcie *pci)
> +{
> +	u32 val;
> +
> +	val = dw_pcie_readl_dbi(pci, PCIE_PORT_MULTI_LANE_CTRL);
> +	dw_pcie_writel_dbi(pci, PCIE_PORT_MULTI_LANE_CTRL,
> +			   val | PORT_MLTI_UPCFG_SUPPORT);

Why not to use similar pattern as below?

	val = dw_pcie_readl_dbi(pci, PCIE_PORT_MULTI_LANE_CTRL);
	val |= PORT_MLTI_UPCFG_SUPPORT;
	dw_pcie_writel_dbi(pci, PCIE_PORT_MULTI_LANE_CTRL, val);

> +}

> +void dw_pcie_link_set_max_speed(struct dw_pcie *pci, u32 link_gen)
> +{
> +	u32 reg, val;
> +	u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> +
> +	reg = dw_pcie_readl_dbi(pci, offset + PCI_EXP_LNKCTL2);
> +	reg &= ~PCI_EXP_LNKCTL2_TLS;
> +
> +	switch (pcie_link_speed[link_gen]) {
> +	case PCIE_SPEED_2_5GT:
> +		reg |= PCI_EXP_LNKCTL2_TLS_2_5GT;

> +	break;

Is this a style or indentation issue?

> +	case PCIE_SPEED_5_0GT:
> +		reg |= PCI_EXP_LNKCTL2_TLS_5_0GT;
> +	break;

Ditto.

> +	case PCIE_SPEED_8_0GT:
> +		reg |= PCI_EXP_LNKCTL2_TLS_8_0GT;

> +	break;

Ditto.

> +	case PCIE_SPEED_16_0GT:
> +		reg |= PCI_EXP_LNKCTL2_TLS_16_0GT;

> +	break;

Ditto.

> +	default:

> +	/* Use hardware capability */

Ditto.

> +		val = dw_pcie_readl_dbi(pci, offset + PCI_EXP_LNKCAP);
> +		val = FIELD_GET(PCI_EXP_LNKCAP_SLS, val);
> +		reg &= ~PCI_EXP_LNKCTL2_HASD;
> +		reg |= FIELD_PREP(PCI_EXP_LNKCTL2_TLS, val);

> +	break;

Ditto.

> +	}
> +
> +	dw_pcie_writel_dbi(pci, offset + PCI_EXP_LNKCTL2, reg);
> +}

> +void dw_pcie_link_set_n_fts(struct dw_pcie *pci, u32 n_fts)
> +{
> +	u32 val;
> +
> +	val = dw_pcie_readl_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL);

> +	val &= ~PORT_LOGIC_N_FTS;
> +	val |= n_fts;

What if somebody supplies bits outside of the mask? I guess you need to apply
proper masks to both values.

> +	dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
> +}

> +#define PORT_LOGIC_N_FTS		GENMASK(7, 0)

Shouldn't you use _MASK suffix here?

> +#define BUS_IATU_OFFS			SZ_256M

Perhaps less cryptic name?

> +#define RST_INTRVL_DFT_MS		100

Less cryptic name would be

	RESET_INTERVAL_MS


> +static void pcie_update_bits(void __iomem *base, u32 mask, u32 val, u32 ofs)
> +{
> +	u32 old, new;
> +
> +	old = readl(base + ofs);

> +	new = old & ~mask;
> +	new |= val & mask;

Standard pattern

	new = (old & ~mask) | (val & mask);

And actually you may re-use 'val' variable and get rid of 'new' one.

> +
> +	if (new != old)
> +		writel(new, base + ofs);
> +}

> +static int intel_pcie_get_resources(struct platform_device *pdev)
> +{

> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");

> +

No need to have this blank line.

> +	pci->dbi_base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(pci->dbi_base))
> +		return PTR_ERR(pci->dbi_base);

> +	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "app");

> +

Ditto.

> +	lpp->app_base = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(lpp->app_base))
> +		return PTR_ERR(lpp->app_base);

> +	return 0;
> +}

> +	/* Read PMC status and wait for falling into L2 link state */
> +	ret = readl_poll_timeout(lpp->app_base + PCIE_APP_PMC, value,

> +				 (value & PCIE_APP_PMC_IN_L2), 20,

Too many parentheses.

> +				 jiffies_to_usecs(5 * HZ));

> +	if (!lpp->pcie_cap_ofst) {
> +		lpp->pcie_cap_ofst = dw_pcie_find_capability(&lpp->pci,
> +							     PCI_CAP_ID_EXP);
> +	}

Wouldn't be slightly better to have something like

	ret = dw_pcie_find_capability(&lpp->pci, PCI_CAP_ID_EXP);
	if (ret >= 0 && !lpp->pcie_cap_ofst)
		lpp->pcie_cap_ofst = ret;

?

(It can be expanded to print error / warning messages if needed)

> +	return ret;
> +}

> +	platform_set_drvdata(pdev, lpp);

I think it makes sense to setup at the end of the function (before dev_info()
call).

> +	data = device_get_match_data(dev);

Perhaps
	if (!data)
		return -ENODEV; // -EINVAL?

> +	/*
> +	 * Intel PCIe doesn't configure IO region, so set viewport
> +	 * to not to perform IO region access.
> +	 */
> +	pci->num_viewport = data->num_viewport;

Missed blank line?

> +	dev_info(dev, "Intel PCIe Root Complex Port init done\n");

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2019-11-06 12:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06  3:44 [PATCH v5 0/3] PCI: Add Intel PCIe Driver and respective dt-binding yaml file Dilip Kota
2019-11-06  3:44 ` [PATCH v5 1/3] dt-bindings: PCI: intel: Add YAML schemas for the PCIe RC controller Dilip Kota
2019-11-12 19:17   ` Rob Herring
2019-11-13  2:39     ` Dilip Kota
2019-11-06  3:44 ` [PATCH v5 2/3] dwc: PCI: intel: PCIe RC controller driver Dilip Kota
2019-11-06 12:24   ` Andy Shevchenko [this message]
2019-11-11  8:08     ` Dilip Kota
2019-11-12  7:18       ` Dilip Kota
2019-11-08 10:42   ` Andrew Murray
2019-11-11  8:09     ` Dilip Kota
2019-11-06  3:44 ` [PATCH v5 3/3] PCI: artpec6: Configure FTS with dwc helper function Dilip Kota
2019-11-06  9:43   ` Gustavo Pimentel
2019-11-11  6:24     ` Dilip Kota
2019-11-07 21:03   ` Jingoo Han
2019-11-08 10:43     ` Andrew Murray
2019-11-11  8:10       ` Dilip Kota
2019-11-11  8:09     ` Dilip Kota

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=20191106122452.GA32742@smile.fi.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=andrew.murray@arm.com \
    --cc=cheol.yong.kim@intel.com \
    --cc=chuanhua.lei@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=eswara.kota@linux.intel.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=helgaas@kernel.org \
    --cc=jingoohan1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=qi-ming.wu@intel.com \
    --cc=robh@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).