linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
To: maz@kernel.org
Cc: devicetree@vger.kernel.org,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	mbrugger@suse.com, linux-pci@vger.kernel.org,
	phil@raspberrypi.org, linux-kernel@vger.kernel.org,
	Florian Fainelli <f.fainelli@gmail.com>,
	bcm-kernel-feedback-list@broadcom.com,
	linux-rpi-kernel@lists.infradead.org, james.quinlan@broadcom.com,
	Bjorn Helgaas <bhelgaas@google.com>,
	Andrew Murray <andrew.murray@arm.com>,
	linux-arm-kernel@lists.infradead.org, wahrenst@gmx.net
Subject: Re: [PATCH 4/4] PCI: brcmstb: add MSI capability
Date: Mon, 11 Nov 2019 12:21:41 +0100	[thread overview]
Message-ID: <86aeec16bc04d17372db5e33ffec0d5621973116.camel@suse.de> (raw)
In-Reply-To: <f1154b65d422e2e37e3b320e662d4268@www.loen.fr>


[-- Attachment #1.1: Type: text/plain, Size: 15129 bytes --]

Hi Marc,
thanks for the review!

On Thu, 2019-11-07 at 16:49 +0109, Marc Zyngier wrote:
> On 2019-11-06 22:54, Nicolas Saenz Julienne wrote:
> > From: Jim Quinlan <james.quinlan@broadcom.com>
> > 
> > This commit adds MSI to the Broadcom STB PCIe host controller. It 
> > does
> > not add MSIX since that functionality is not in the HW.  The MSI
> > controller is physically located within the PCIe block, however, 
> > there
> > is no reason why the MSI controller could not be moved elsewhere in
> > the future.
> > 
> > Since the internal Brcmstb MSI controller is intertwined with the 
> > PCIe
> > controller, it is not its own platform device but rather part of the
> > PCIe platform device.
> > 
> > This is based on Jim's original submission[1] with some slight 
> > changes
> > regarding how pcie->msi_target_addr is decided.
> > 
> > [1] https://patchwork.kernel.org/patch/10605955/
> > 
> > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > Co-developed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > ---
> >  drivers/pci/controller/Kconfig        |   2 +-
> >  drivers/pci/controller/pcie-brcmstb.c | 333 
> > +++++++++++++++++++++++++-
> >  2 files changed, 332 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/Kconfig 
> > b/drivers/pci/controller/Kconfig
> > index 8b3aae91d8af..99b972ad3f2f 100644
> > --- a/drivers/pci/controller/Kconfig
> > +++ b/drivers/pci/controller/Kconfig
> > @@ -284,7 +284,7 @@ config VMD
> >  config PCIE_BRCMSTB
> >  	bool "Broadcom Brcmstb PCIe host controller"
> >  	depends on ARCH_BRCMSTB || BMIPS_GENERIC
> > -	depends on OF
> > +	depends on OF && PCI_MSI
> >  	depends on SOC_BRCMSTB
> >  	default ARCH_BRCMSTB || BMIPS_GENERIC
> >  	help
> > diff --git a/drivers/pci/controller/pcie-brcmstb.c
> > b/drivers/pci/controller/pcie-brcmstb.c
> > index 880ec11d06a1..26053e69b95f 100644
> > --- a/drivers/pci/controller/pcie-brcmstb.c
> > +++ b/drivers/pci/controller/pcie-brcmstb.c
> > @@ -1,6 +1,7 @@
> >  // SPDX-License-Identifier: GPL-2.0
> >  /* Copyright (C) 2009 - 2019 Broadcom */
> > 
> > +#include <linux/bitops.h>
> >  #include <linux/clk.h>
> >  #include <linux/compiler.h>
> >  #include <linux/delay.h>
> > @@ -8,11 +9,13 @@
> >  #include <linux/interrupt.h>
> >  #include <linux/io.h>
> >  #include <linux/ioport.h>
> > +#include <linux/irqchip/chained_irq.h>
> >  #include <linux/irqdomain.h>
> >  #include <linux/kernel.h>
> >  #include <linux/list.h>
> >  #include <linux/log2.h>
> >  #include <linux/module.h>
> > +#include <linux/msi.h>
> >  #include <linux/of_address.h>
> >  #include <linux/of_irq.h>
> >  #include <linux/of_pci.h>
> > @@ -46,6 +49,9 @@
> >  #define PCIE_MISC_RC_BAR2_CONFIG_LO			0x4034
> >  #define PCIE_MISC_RC_BAR2_CONFIG_HI			0x4038
> >  #define PCIE_MISC_RC_BAR3_CONFIG_LO			0x403c
> > +#define PCIE_MISC_MSI_BAR_CONFIG_LO			0x4044
> > +#define PCIE_MISC_MSI_BAR_CONFIG_HI			0x4048
> > +#define PCIE_MISC_MSI_DATA_CONFIG			0x404c
> >  #define PCIE_MISC_PCIE_CTRL				0x4064
> >  #define PCIE_MISC_PCIE_STATUS				0x4068
> >  #define PCIE_MISC_REVISION				0x406c
> > @@ -54,6 +60,7 @@
> >  #define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI		0x4084
> >  #define PCIE_MISC_HARD_PCIE_HARD_DEBUG			0x4204
> >  #define PCIE_INTR2_CPU_BASE				0x4300
> > +#define PCIE_MSI_INTR2_BASE				0x4500
> > 
> >  /*
> >   * Broadcom Settop Box PCIe Register Field shift and mask info. The
> > @@ -114,6 +121,8 @@
> > 
> >  #define BRCM_NUM_PCIE_OUT_WINS		0x4
> >  #define BRCM_MAX_SCB			0x4
> > +#define BRCM_INT_PCI_MSI_NR		32
> > +#define BRCM_PCIE_HW_REV_33		0x0303
> > 
> >  #define BRCM_MSI_TARGET_ADDR_LT_4GB	0x0fffffffcULL
> >  #define BRCM_MSI_TARGET_ADDR_GT_4GB	0xffffffffcULL
> > @@ -199,6 +208,33 @@ struct brcm_window {
> >  	dma_addr_t size;
> >  };
> > 
> > +struct brcm_msi {
> > +	struct device		*dev;
> > +	void __iomem		*base;
> > +	struct device_node	*dn;
> > +	struct irq_domain	*msi_domain;
> > +	struct irq_domain	*inner_domain;
> > +	struct mutex		lock; /* guards the alloc/free operations */
> > +	u64			target_addr;
> > +	int			irq;
> > +
> > +	/* intr_base is the base pointer for interrupt status/set/clr regs 
> > */
> > +	void __iomem		*intr_base;
> > +
> > +	/* intr_legacy_mask indicates how many bits are MSI interrupts */
> > +	u32			intr_legacy_mask;
> > +
> > +	/*
> > +	 * intr_legacy_offset indicates bit position of MSI_01. It is
> > +	 * to map the register bit position to a hwirq that starts at 0.
> > +	 */
> > +	u32			intr_legacy_offset;
> > +
> > +	/* used indicates which MSI interrupts have been alloc'd */
> > +	unsigned long		used;
> > +	unsigned int		rev;
> > +};
> > +
> >  /* Internal PCIe Host Controller Information.*/
> >  struct brcm_pcie {
> >  	struct device		*dev;
> > @@ -211,7 +247,10 @@ struct brcm_pcie {
> >  	bool			suspended;
> >  	bool			ssc;
> >  	int			gen;
> > +	u64			msi_target_addr;
> >  	struct brcm_window	out_wins[BRCM_NUM_PCIE_OUT_WINS];
> > +	struct brcm_msi		*msi;
> > +	bool			msi_internal;
> 
> Do you need both of these fields? Is there any case where msi is valid
> and msi_internal is false?

You're right, got rid of msi_internal.

> 
> >  	unsigned int		rev;
> >  	const int		*reg_offsets;
> >  	const int		*reg_field_info;
> > @@ -477,6 +516,267 @@ static void brcm_pcie_set_outbound_win(struct
> > brcm_pcie *pcie,
> >  			   LIMIT, tmp);
> >  }
> > 
> > +static struct irq_chip brcm_msi_irq_chip = {
> > +	.name = "Brcm_MSI",
> > +	.irq_mask = pci_msi_mask_irq,
> > +	.irq_unmask = pci_msi_unmask_irq,
> > +};
> > +
> > +static struct msi_domain_info brcm_msi_domain_info = {
> > +	.flags	= (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> > +		   MSI_FLAG_PCI_MSIX),
> 
> Is there a particular reason for not supporting MultiMSI? I won't miss
> it, but it might be worth documenting the restriction if the HW cannot
> support it (though I can't immediately see why).

There is no actual restriction. As Jim tells me, there never was the need for
it. If it's fine with you, we'll leave that as an enhancement for the future,
specially since the RPi's XHCI device only uses one MSI interrupt.

> > +	.chip	= &brcm_msi_irq_chip,
> > +};
> > +
> > +static void brcm_pcie_msi_isr(struct irq_desc *desc)
> > +{
> > +	struct irq_chip *chip = irq_desc_get_chip(desc);
> > +	struct brcm_msi *msi;
> > +	unsigned long status, virq;
> > +	u32 mask, bit, hwirq;
> > +	struct device *dev;
> > +
> > +	chained_irq_enter(chip, desc);
> > +	msi = irq_desc_get_handler_data(desc);
> > +	mask = msi->intr_legacy_mask;
> > +	dev = msi->dev;
> > +
> > +	while ((status = bcm_readl(msi->intr_base + STATUS) & mask)) {
> 
> Is this loop really worth it? If, as I imagine, this register is at the
> end of a wet piece of string, this additional read (likely to return 
> zero)
> will have a measurable latency impact...

I think this one was cargo-culted, TBH this pattern is all over the place.
Though, now that you point it out, I can't really provide a justification for
it. Maybe Jim can contradict me here, but It's working fine without it.

> > +		for_each_set_bit(bit, &status, BRCM_INT_PCI_MSI_NR) {
> > +			/* clear the interrupt */
> > +			bcm_writel(1 << bit, msi->intr_base + CLR);
> > +
> > +			/* Account for legacy interrupt offset */
> > +			hwirq = bit - msi->intr_legacy_offset;
> > +
> > +			virq = irq_find_mapping(msi->inner_domain, hwirq);
> > +			if (virq) {
> > +				if (msi->used & (1 << hwirq))
> > +					generic_handle_irq(virq);
> > +				else
> > +					dev_info(dev, "unhandled MSI %d\n",
> > +						 hwirq);
> 
> Can this ever happen? If you've found the mapping in the irqdomain,
> the MSI obviously has been allocated. Or am I missing something?

Agree, I'll get rid of it.

> > +			} else {
> > +				/* Unknown MSI, just clear it */
> > +				dev_dbg(dev, "unexpected MSI\n");
> > +			}
> > +		}
> > +	}
> > +	chained_irq_exit(chip, desc);
> > +}
> > +
> > +static void brcm_compose_msi_msg(struct irq_data *data, struct 
> > msi_msg *msg)
> > +{
> > +	struct brcm_msi *msi = irq_data_get_irq_chip_data(data);
> > +	u32 temp;
> > +
> > +	msg->address_lo = lower_32_bits(msi->target_addr);
> > +	msg->address_hi = upper_32_bits(msi->target_addr);
> > +	temp = bcm_readl(msi->base + PCIE_MISC_MSI_DATA_CONFIG);

Well as far as the RPi is concerned I can do without it. I don't know if there
is an odd case on STB devices where we need it, maybe Jim can shine some light
into it. Regardless I think I'll remove it for now, we can then fix it once we
enable other users for the controller.

> > +	msg->data = ((temp >> 16) & (temp & 0xffff)) | data->hwirq;
> > +}
> > +
> > +static int brcm_msi_set_affinity(struct irq_data *irq_data,
> > +				 const struct cpumask *mask, bool force)
> > +{
> > +	return -EINVAL;
> > +}
> > +
> > +static struct irq_chip brcm_msi_bottom_irq_chip = {
> > +	.name			= "Brcm_MSI",
> > +	.irq_compose_msi_msg	= brcm_compose_msi_msg,
> > +	.irq_set_affinity	= brcm_msi_set_affinity,
> > +};
> > +
> > +static int brcm_msi_alloc(struct brcm_msi *msi)
> > +{
> > +	int bit, hwirq;
> > +
> > +	mutex_lock(&msi->lock);
> > +	bit = ~msi->used ? ffz(msi->used) : -1;
> > +
> > +	if (bit >= 0 && bit < BRCM_INT_PCI_MSI_NR) {
> > +		msi->used |= (1 << bit);
> > +		hwirq = bit - msi->intr_legacy_offset;
> > +	} else {
> > +		hwirq = -ENOSPC;
> > +	}
> 
> Please consider using bitmap_find_free_region() and co, instead of
> open coding your allocator.

Noted.

> > +
> > +	mutex_unlock(&msi->lock);
> > +	return hwirq;
> > +}
> > +
> > +static void brcm_msi_free(struct brcm_msi *msi, unsigned long hwirq)
> > +{
> > +	mutex_lock(&msi->lock);
> > +	msi->used &= ~(1 << (hwirq + msi->intr_legacy_offset));
> > +	mutex_unlock(&msi->lock);
> > +}
> > +
> > +static int brcm_irq_domain_alloc(struct irq_domain *domain, unsigned
> > int virq,
> > +				 unsigned int nr_irqs, void *args)
> > +{
> > +	struct brcm_msi *msi = domain->host_data;
> > +	int hwirq;
> > +
> > +	hwirq = brcm_msi_alloc(msi);
> > +
> > +	if (hwirq < 0)
> > +		return hwirq;
> > +
> > +	irq_domain_set_info(domain, virq, (irq_hw_number_t)hwirq,
> > +			    &brcm_msi_bottom_irq_chip, domain->host_data,
> > +			    handle_simple_irq, NULL, NULL);
> 
> simple_irq doesn't quite match what this does. This really should
> use an edge flow.

Ok, I'll look into it.

> > +	return 0;
> > +}
> > +
> > +static void brcm_irq_domain_free(struct irq_domain *domain,
> > +				 unsigned int virq, unsigned int nr_irqs)
> > +{
> > +	struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> > +	struct brcm_msi *msi = irq_data_get_irq_chip_data(d);
> > +
> > +	brcm_msi_free(msi, d->hwirq);
> > +}
> > +
> > +static void brcm_msi_set_regs(struct brcm_msi *msi)
> > +{
> > +	u32 data_val, msi_lo, msi_hi;
> > +
> > +	if (msi->rev >= BRCM_PCIE_HW_REV_33) {
> > +		/*
> > +		 * ffe0 -- least sig 5 bits are 0 indicating 32 msgs
> > +		 * 6540 -- this is our arbitrary unique data value
> > +		 */
> > +		data_val = 0xffe06540;
> > +	} else {
> > +		/*
> > +		 * fff8 -- least sig 3 bits are 0 indicating 8 msgs
> > +		 * 6540 -- this is our arbitrary unique data value
> > +		 */
> > +		data_val = 0xfff86540;
> > +	}
> > +
> > +	/*
> > +	 * Make sure we are not masking MSIs.  Note that MSIs can be 
> > masked,
> > +	 * but that occurs on the PCIe EP device
> 
> That's not a guarantee, specially with plain MultiMSI. I'm actually
> minded to move the masking to be purely local on the MSI controllers
> I maintain.

Sorry, I'm a little lost here. The way I understand it after reset, even with
multiMSI, on the EP side all vectors are umasked. So it would make sense to do
the same on the controller.

The way I see it, we want to avoid using this register anyway, as with multiMSI
we'd only get function wide masking, which I guess is not all that useful.

> > +	 */
> > +	bcm_writel(0xffffffff & msi->intr_legacy_mask,
> > +		   msi->intr_base + MASK_CLR);
> > +
> > +	msi_lo = lower_32_bits(msi->target_addr);
> > +	msi_hi = upper_32_bits(msi->target_addr);
> > +	/*
> > +	 * The 0 bit of PCIE_MISC_MSI_BAR_CONFIG_LO is repurposed to MSI
> > +	 * enable, which we set to 1.
> > +	 */
> > +	bcm_writel(msi_lo | 1, msi->base + PCIE_MISC_MSI_BAR_CONFIG_LO);
> > +	bcm_writel(msi_hi, msi->base + PCIE_MISC_MSI_BAR_CONFIG_HI);
> > +	bcm_writel(data_val, msi->base + PCIE_MISC_MSI_DATA_CONFIG);
> > +}
> > +
> > +static const struct irq_domain_ops msi_domain_ops = {
> > +	.alloc	= brcm_irq_domain_alloc,
> > +	.free	= brcm_irq_domain_free,
> > +};
> > +
> > +static int brcm_allocate_domains(struct brcm_msi *msi)
> > +{
> > +	struct fwnode_handle *fwnode = of_node_to_fwnode(msi->dn);
> > +	struct device *dev = msi->dev;
> > +
> > +	msi->inner_domain = irq_domain_add_linear(NULL, 
> > BRCM_INT_PCI_MSI_NR,
> > +						  &msi_domain_ops, msi);
> > +	if (!msi->inner_domain) {
> > +		dev_err(dev, "failed to create IRQ domain\n");
> > +		return -ENOMEM;
> > +	}
> > +
> > +	msi->msi_domain = pci_msi_create_irq_domain(fwnode,
> > +						    &brcm_msi_domain_info,
> > +						    msi->inner_domain);
> > +	if (!msi->msi_domain) {
> > +		dev_err(dev, "failed to create MSI domain\n");
> > +		irq_domain_remove(msi->inner_domain);
> > +		return -ENOMEM;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static void brcm_free_domains(struct brcm_msi *msi)
> > +{
> > +	irq_domain_remove(msi->msi_domain);
> > +	irq_domain_remove(msi->inner_domain);
> > +}
> > +
> > +static void brcm_msi_remove(struct brcm_pcie *pcie)
> > +{
> > +	struct brcm_msi *msi = pcie->msi;
> > +
> > +	if (!msi)
> > +		return;
> > +	irq_set_chained_handler(msi->irq, NULL);
> > +	irq_set_handler_data(msi->irq, NULL);
> > +	brcm_free_domains(msi);
> > +}
> > +
> > +static int brcm_pcie_enable_msi(struct brcm_pcie *pcie)
> > +{
> > +	struct brcm_msi *msi;
> > +	int irq, ret;
> > +	struct device *dev = pcie->dev;
> > +
> > +	irq = irq_of_parse_and_map(dev->of_node, 1);
> > +	if (irq <= 0) {
> > +		dev_err(dev, "cannot map msi intr\n");
> > +		return -ENODEV;
> > +	}
> > +
> > +	msi = devm_kzalloc(dev, sizeof(struct brcm_msi), GFP_KERNEL);
> > +	if (!msi)
> > +		return -ENOMEM;
> > +
> > +	msi->dev = dev;
> > +	msi->base = pcie->base;
> > +	msi->rev =  pcie->rev;
> > +	msi->dn = pcie->dn;
> > +	msi->target_addr = pcie->msi_target_addr;
> > +	msi->irq = irq;
> > +
> > +	ret = brcm_allocate_domains(msi);
> > +	if (ret)
> > +		return ret;
> 
> You seem to rely on the devm_* allocators to cleanup on failure. But as 
> far
> as I can see, failing to initialize the MSI subsystem doesn't translate 
> in
> a PCIe init failure, hence keeping the memory around.

Indeed, I see what you mean. I say let's fail.

Regards,
Nicolas


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-11-11 11:22 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06 21:45 [PATCH 0/4] Raspberry Pi 4 PCIe support Nicolas Saenz Julienne
2019-11-06 21:45 ` [PATCH 1/4] dt-bindings: pci: add bindings for brcmstb's PCIe device Nicolas Saenz Julienne
2019-11-07 10:32   ` Andrew Murray
2019-11-07 10:53     ` Nicolas Saenz Julienne
2019-11-13  4:15   ` Rob Herring
2019-11-14 13:15     ` Nicolas Saenz Julienne
2019-11-06 21:45 ` [PATCH 2/4] ARM: dts: bcm2711: Enable PCIe controller Nicolas Saenz Julienne
2019-11-07 10:37   ` Andrew Murray
2019-11-12  9:18     ` Nicolas Saenz Julienne
2019-11-07 17:44   ` Stefan Wahren
2019-11-07 18:24     ` Nicolas Saenz Julienne
2019-11-06 21:45 ` [PATCH 3/4] PCI: brcmstb: add Broadcom STB PCIe host controller driver Nicolas Saenz Julienne
2019-11-07 15:00   ` Andrew Murray
2019-11-07 16:12     ` Jim Quinlan
2019-11-08 10:52       ` Andrew Murray
2019-11-08 16:33         ` Jim Quinlan
2019-11-07 17:30     ` Nicolas Saenz Julienne
2019-11-08 10:51       ` Andrew Murray
2019-11-07 17:50   ` Stefan Wahren
2019-11-08 11:13     ` Nicolas Saenz Julienne
2019-11-11  7:10   ` Jeremy Linton
2019-11-11 15:29     ` Nicolas Saenz Julienne
2019-11-11 16:40       ` Florian Fainelli
2019-11-11 20:00       ` Jeremy Linton
2019-11-11 21:27         ` Florian Fainelli
2019-11-06 21:45 ` [PATCH 4/4] PCI: brcmstb: add MSI capability Nicolas Saenz Julienne
2019-11-07 15:40   ` Marc Zyngier
2019-11-11 11:21     ` Nicolas Saenz Julienne [this message]
2019-11-11 13:29       ` Marc Zyngier
2019-11-06 21:51 ` [PATCH 0/4] Raspberry Pi 4 PCIe support Florian Fainelli
2019-11-07  9:58   ` Nicolas Saenz Julienne

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=86aeec16bc04d17372db5e33ffec0d5621973116.camel@suse.de \
    --to=nsaenzjulienne@suse.de \
    --cc=andrew.murray@arm.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=james.quinlan@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=maz@kernel.org \
    --cc=mbrugger@suse.com \
    --cc=phil@raspberrypi.org \
    --cc=wahrenst@gmx.net \
    /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).