All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <bhelgaas@google.com>
To: Tanmay Inamdar <tinamdar@apm.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Rob Landley <rob@landley.net>, Liviu Dudau <liviu.dudau@arm.com>,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, patches@apm.com, jcm@redhat.com
Subject: Re: [PATCH v9 1/4] pci:host: APM X-Gene PCIe host controller driver
Date: Fri, 19 Sep 2014 16:32:58 -0600	[thread overview]
Message-ID: <20140919223258.GA32208@google.com> (raw)
In-Reply-To: <1410906824-9321-2-git-send-email-tinamdar@apm.com>

On Tue, Sep 16, 2014 at 03:33:41PM -0700, Tanmay Inamdar wrote:
> This patch adds the AppliedMicro X-Gene SOC PCIe host controller driver.
> X-Gene PCIe controller supports maximum up to 8 lanes and GEN3 speed.
> X-Gene SOC supports maximum 5 PCIe ports.
> 
> Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com>
> Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
> ---
>  drivers/pci/host/Kconfig     |  10 +
>  drivers/pci/host/Makefile    |   1 +
>  drivers/pci/host/pci-xgene.c | 646 +++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 657 insertions(+)
>  create mode 100644 drivers/pci/host/pci-xgene.c
> ...

> +static inline void
> +xgene_pcie_cfg_in16(void __iomem *addr, int offset, u32 *val)

Whitespace - can fit on one line.  Also others below.

> +{
> +	*val = readl(addr + (offset & ~0x3));
> +
> +	switch (offset & 0x3) {
> +	case 2:
> +		*val >>= 16;
> +		break;
> +	}
> +
> +	*val &= 0xFFFF;
> +}
> +
> +static inline void
> +xgene_pcie_cfg_in8(void __iomem *addr, int offset, u32 *val)
> +{
> +	*val = readl(addr + (offset & ~0x3));
> +
> +	switch (offset & 0x3) {
> +	case 3:
> +		*val = *val >> 24;
> +		break;
> +	case 2:
> +		*val = *val >> 16;
> +		break;
> +	case 1:
> +		*val = *val >> 8;
> +		break;
> +	}
> +	*val &= 0xFF;
> +}
> +
> +/* When the address bit [17:16] is 2'b01, the Configuration access will be
> + * treated as Type 1 and it will be forwarded to external PCIe device.
> + */

Follow usual block comment style:

    /*
     * text
     */

> ...
> +static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
> +{
> +	int i;
> +
> +	/* Hide the PCI host BARs from the kernel as their content doesn't
> +	 * fit well in the resource management
> +	 */

This needs a better explanation than "doesn't fit well."

I *think* you're probably talking about something similar to the MVEBU
devices mentioned here:
http://lkml.kernel.org/r/CAErSpo56jB1Bf2JtYCGKXZBZqRF1jXFxGmeewPX_e6vSXueGyA@mail.gmail.com

where the device can be configured as either an endpoint or a root port,
and the endpoint BARs are still visible when configured as a root port.

In any event, I'd like a description of exactly what these BARs are and wha
the problem is.  Presumably the BARs exist and were sized by the PCI core
in __pci_read_base().  That will generate some log messages and possibly
some warnings, depending on how the host bridge windows are set up.

We might eventually need a way to skip BARs like that altogether so we
don't even try to size them.

> +	for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> +		dev->resource[i].start = dev->resource[i].end = 0;
> +		dev->resource[i].flags = 0;
> +	}
> +	dev_info(&dev->dev, "Hiding X-Gene pci host bridge resources %s\n",
> +		 pci_name(dev));
> +}
> +DECLARE_PCI_FIXUP_HEADER(XGENE_PCIE_VENDORID, XGENE_PCIE_DEVICEID,
> +			 xgene_pcie_fixup_bridge);
> +
> ...

> +static void xgene_pcie_setup_ob_reg(struct xgene_pcie_port *port,
> +				    struct resource *res, u32 offset,
> +				    u64 cpu_addr, u64 pci_addr)
> +{
> +	void __iomem *base = port->csr_base + offset;
> +	resource_size_t size = resource_size(res);
> +	u64 restype = resource_type(res);
> +	u64 mask = 0;
> +	u32 min_size;
> +	u32 flag = EN_REG;
> +
> +	if (restype == IORESOURCE_MEM) {
> +		min_size = SZ_128M;
> +	} else {
> +		min_size = 128;
> +		flag |= OB_LO_IO;
> +	}
> +
> +	if (size >= min_size)
> +		mask = ~(size - 1) | flag;
> +	else
> +		dev_warn(port->dev, "res size 0x%llx less than minimum 0x%x\n",
> +			 (u64)size, min_size);

I'd include a %pR here to help identify the offending resource.

> +static int xgene_pcie_map_ranges(struct xgene_pcie_port *port,
> +				 struct list_head *res,
> +				 resource_size_t io_base)
> +{
> +	struct pci_host_bridge_window *window;
> +	struct device *dev = port->dev;
> +	int ret;
> +
> +	list_for_each_entry(window, res, list) {
> +		struct resource *res = window->res;
> +		u64 restype = resource_type(res);
> +
> +		dev_dbg(port->dev, "0x%08lx 0x%016llx...0x%016llx\n",
> +			res->flags, res->start, res->end);

Use %pR here.

> +
> +		switch (restype) {
> +		case IORESOURCE_IO:
> +			xgene_pcie_setup_ob_reg(port, res, OMR3BARL, io_base,
> +						res->start - window->offset);
> +			ret = pci_remap_iospace(res, io_base);
> +			if (ret < 0)
> +				return ret;
> +			break;
> +		case IORESOURCE_MEM:
> +			xgene_pcie_setup_ob_reg(port, res, OMR1BARL, res->start,
> +						res->start - window->offset);
> +			break;
> +		case IORESOURCE_BUS:
> +			break;
> +		default:
> +			dev_err(dev, "invalid io resource!");

If you're going to print something here, you might as well include the type
that seems invalid.  If you use %pR, I think it will do that automatically.

> +			return -EINVAL;
> +		}
> +	}
> +	xgene_pcie_setup_cfg_reg(port->csr_base, port->cfg_addr);
> +
> +	return 0;
> +}

Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: bhelgaas@google.com (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 1/4] pci:host: APM X-Gene PCIe host controller driver
Date: Fri, 19 Sep 2014 16:32:58 -0600	[thread overview]
Message-ID: <20140919223258.GA32208@google.com> (raw)
In-Reply-To: <1410906824-9321-2-git-send-email-tinamdar@apm.com>

On Tue, Sep 16, 2014 at 03:33:41PM -0700, Tanmay Inamdar wrote:
> This patch adds the AppliedMicro X-Gene SOC PCIe host controller driver.
> X-Gene PCIe controller supports maximum up to 8 lanes and GEN3 speed.
> X-Gene SOC supports maximum 5 PCIe ports.
> 
> Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com>
> Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
> ---
>  drivers/pci/host/Kconfig     |  10 +
>  drivers/pci/host/Makefile    |   1 +
>  drivers/pci/host/pci-xgene.c | 646 +++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 657 insertions(+)
>  create mode 100644 drivers/pci/host/pci-xgene.c
> ...

> +static inline void
> +xgene_pcie_cfg_in16(void __iomem *addr, int offset, u32 *val)

Whitespace - can fit on one line.  Also others below.

> +{
> +	*val = readl(addr + (offset & ~0x3));
> +
> +	switch (offset & 0x3) {
> +	case 2:
> +		*val >>= 16;
> +		break;
> +	}
> +
> +	*val &= 0xFFFF;
> +}
> +
> +static inline void
> +xgene_pcie_cfg_in8(void __iomem *addr, int offset, u32 *val)
> +{
> +	*val = readl(addr + (offset & ~0x3));
> +
> +	switch (offset & 0x3) {
> +	case 3:
> +		*val = *val >> 24;
> +		break;
> +	case 2:
> +		*val = *val >> 16;
> +		break;
> +	case 1:
> +		*val = *val >> 8;
> +		break;
> +	}
> +	*val &= 0xFF;
> +}
> +
> +/* When the address bit [17:16] is 2'b01, the Configuration access will be
> + * treated as Type 1 and it will be forwarded to external PCIe device.
> + */

Follow usual block comment style:

    /*
     * text
     */

> ...
> +static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
> +{
> +	int i;
> +
> +	/* Hide the PCI host BARs from the kernel as their content doesn't
> +	 * fit well in the resource management
> +	 */

This needs a better explanation than "doesn't fit well."

I *think* you're probably talking about something similar to the MVEBU
devices mentioned here:
http://lkml.kernel.org/r/CAErSpo56jB1Bf2JtYCGKXZBZqRF1jXFxGmeewPX_e6vSXueGyA at mail.gmail.com

where the device can be configured as either an endpoint or a root port,
and the endpoint BARs are still visible when configured as a root port.

In any event, I'd like a description of exactly what these BARs are and wha
the problem is.  Presumably the BARs exist and were sized by the PCI core
in __pci_read_base().  That will generate some log messages and possibly
some warnings, depending on how the host bridge windows are set up.

We might eventually need a way to skip BARs like that altogether so we
don't even try to size them.

> +	for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> +		dev->resource[i].start = dev->resource[i].end = 0;
> +		dev->resource[i].flags = 0;
> +	}
> +	dev_info(&dev->dev, "Hiding X-Gene pci host bridge resources %s\n",
> +		 pci_name(dev));
> +}
> +DECLARE_PCI_FIXUP_HEADER(XGENE_PCIE_VENDORID, XGENE_PCIE_DEVICEID,
> +			 xgene_pcie_fixup_bridge);
> +
> ...

> +static void xgene_pcie_setup_ob_reg(struct xgene_pcie_port *port,
> +				    struct resource *res, u32 offset,
> +				    u64 cpu_addr, u64 pci_addr)
> +{
> +	void __iomem *base = port->csr_base + offset;
> +	resource_size_t size = resource_size(res);
> +	u64 restype = resource_type(res);
> +	u64 mask = 0;
> +	u32 min_size;
> +	u32 flag = EN_REG;
> +
> +	if (restype == IORESOURCE_MEM) {
> +		min_size = SZ_128M;
> +	} else {
> +		min_size = 128;
> +		flag |= OB_LO_IO;
> +	}
> +
> +	if (size >= min_size)
> +		mask = ~(size - 1) | flag;
> +	else
> +		dev_warn(port->dev, "res size 0x%llx less than minimum 0x%x\n",
> +			 (u64)size, min_size);

I'd include a %pR here to help identify the offending resource.

> +static int xgene_pcie_map_ranges(struct xgene_pcie_port *port,
> +				 struct list_head *res,
> +				 resource_size_t io_base)
> +{
> +	struct pci_host_bridge_window *window;
> +	struct device *dev = port->dev;
> +	int ret;
> +
> +	list_for_each_entry(window, res, list) {
> +		struct resource *res = window->res;
> +		u64 restype = resource_type(res);
> +
> +		dev_dbg(port->dev, "0x%08lx 0x%016llx...0x%016llx\n",
> +			res->flags, res->start, res->end);

Use %pR here.

> +
> +		switch (restype) {
> +		case IORESOURCE_IO:
> +			xgene_pcie_setup_ob_reg(port, res, OMR3BARL, io_base,
> +						res->start - window->offset);
> +			ret = pci_remap_iospace(res, io_base);
> +			if (ret < 0)
> +				return ret;
> +			break;
> +		case IORESOURCE_MEM:
> +			xgene_pcie_setup_ob_reg(port, res, OMR1BARL, res->start,
> +						res->start - window->offset);
> +			break;
> +		case IORESOURCE_BUS:
> +			break;
> +		default:
> +			dev_err(dev, "invalid io resource!");

If you're going to print something here, you might as well include the type
that seems invalid.  If you use %pR, I think it will do that automatically.

> +			return -EINVAL;
> +		}
> +	}
> +	xgene_pcie_setup_cfg_reg(port->csr_base, port->cfg_addr);
> +
> +	return 0;
> +}

Bjorn

  reply	other threads:[~2014-09-19 22:33 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-16 22:33 [PATCH v9 0/4] APM X-Gene PCIe host controller Tanmay Inamdar
2014-09-16 22:33 ` Tanmay Inamdar
2014-09-16 22:33 ` [PATCH v9 1/4] pci:host: APM X-Gene PCIe host controller driver Tanmay Inamdar
2014-09-16 22:33   ` Tanmay Inamdar
2014-09-19 22:32   ` Bjorn Helgaas [this message]
2014-09-19 22:32     ` Bjorn Helgaas
2014-09-22 21:33     ` Tanmay Inamdar
2014-09-22 21:33       ` Tanmay Inamdar
2014-09-22 22:09       ` Bjorn Helgaas
2014-09-22 22:09         ` Bjorn Helgaas
2014-09-22 22:27         ` Jason Gunthorpe
2014-09-22 22:27           ` Jason Gunthorpe
2014-09-22 22:59           ` Tanmay Inamdar
2014-09-22 22:59             ` Tanmay Inamdar
2014-09-22 22:40         ` Tanmay Inamdar
2014-09-22 22:40           ` Tanmay Inamdar
2014-09-16 22:33 ` [PATCH v9 2/4] arm64: dts: APM X-Gene PCIe device tree nodes Tanmay Inamdar
2014-09-16 22:33   ` Tanmay Inamdar
2014-09-16 22:33 ` [PATCH v9 3/4] dt-bindings: pci: xgene pcie device tree bindings Tanmay Inamdar
2014-09-16 22:33   ` Tanmay Inamdar
2014-09-16 22:33 ` [PATCH v9 4/4] MAINTAINERS: entry for APM X-Gene PCIe host driver Tanmay Inamdar
2014-09-16 22:33   ` Tanmay Inamdar
2014-09-19  3:08 ` [PATCH v9 0/4] APM X-Gene PCIe host controller Ming Lei
2014-09-19  3:08   ` Ming Lei
2014-09-19 17:15   ` Tanmay Inamdar
2014-09-19 17:15     ` Tanmay Inamdar
2014-09-22  1:23     ` Ming Lei
2014-09-22  1:23       ` Ming Lei
2014-09-30 16:53       ` Bjorn Helgaas
2014-09-30 16:53         ` Bjorn Helgaas
2014-09-30 16:53         ` Bjorn Helgaas
2014-09-30 17:01         ` Liviu Dudau
2014-09-30 17:01           ` Liviu Dudau

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=20140919223258.GA32208@google.com \
    --to=bhelgaas@google.com \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=jcm@redhat.com \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=patches@apm.com \
    --cc=rob@landley.net \
    --cc=robh+dt@kernel.org \
    --cc=tinamdar@apm.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 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.