All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Frank Li <frank.li@nxp.com>
Cc: "jdmason@kudzu.us" <jdmason@kudzu.us>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"krzysztof.kozlowski+dt@linaro.org" 
	<krzysztof.kozlowski+dt@linaro.org>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"kw@linux.com" <kw@linux.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"kernel@vger.kernel.org" <kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Peng Fan <peng.fan@nxp.com>, Aisheng Dong <aisheng.dong@nxp.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"festevam@gmail.com" <festevam@gmail.com>,
	dl-linux-imx <linux-imx@nxp.com>, "kishon@ti.com" <kishon@ti.com>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"ntb@lists.linux.dev" <ntb@lists.linux.dev>
Subject: Re: [EXT] Re: [PATCH v3 2/4] irqchip: imx mu worked as msi controller
Date: Thu, 21 Jul 2022 16:28:28 +0100	[thread overview]
Message-ID: <87wnc6xz6r.wl-maz@kernel.org> (raw)
In-Reply-To: <PAXPR04MB9186A1D283ACE8BD6954039288919@PAXPR04MB9186.eurprd04.prod.outlook.com>

On Thu, 21 Jul 2022 16:22:08 +0100,
Frank Li <frank.li@nxp.com> wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Marc Zyngier <maz@kernel.org>
> > Sent: Thursday, July 21, 2022 2:57 AM
> > To: Frank Li <frank.li@nxp.com>
> > Cc: jdmason@kudzu.us; tglx@linutronix.de; robh+dt@kernel.org;
> > krzysztof.kozlowski+dt@linaro.org; shawnguo@kernel.org;
> > s.hauer@pengutronix.de; kw@linux.com; bhelgaas@google.com;
> > kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
> > kernel@lists.infradead.org; linux-pci@vger.kernel.org; Peng Fan
> > <peng.fan@nxp.com>; Aisheng Dong <aisheng.dong@nxp.com>;
> > kernel@pengutronix.de; festevam@gmail.com; dl-linux-imx <linux-
> > imx@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com;
> > ntb@lists.linux.dev
> > Subject: [EXT] Re: [PATCH v3 2/4] irqchip: imx mu worked as msi controller
> > 
> > Caution: EXT Email
> > 
> > On Wed, 20 Jul 2022 22:30:34 +0100,
> > Frank Li <Frank.Li@nxp.com> wrote:
> > >
> > > MU support generate irq by write data to a register.
> > > This patch make mu worked as msi controller.
> > > So MU can do doorbell by using standard msi api.
> > >
> > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > ---
> > >  drivers/irqchip/Kconfig          |   7 +
> > >  drivers/irqchip/Makefile         |   1 +
> > >  drivers/irqchip/irq-imx-mu-msi.c | 462
> > +++++++++++++++++++++++++++++++
> > >  3 files changed, 470 insertions(+)
> > >  create mode 100644 drivers/irqchip/irq-imx-mu-msi.c
> > >
> > > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> > > index 5e4e50122777d..4599471d880c0 100644
> > > --- a/drivers/irqchip/Kconfig
> > > +++ b/drivers/irqchip/Kconfig
> > > @@ -470,6 +470,13 @@ config IMX_INTMUX
> > >       help
> > >         Support for the i.MX INTMUX interrupt multiplexer.
> > >
> > > +config IMX_MU_MSI
> > > +     bool "i.MX MU work as MSI controller"
> > > +     default y if ARCH_MXC
> > > +     select IRQ_DOMAIN
> > > +     help
> > > +       MU work as MSI controller to do general doorbell
> > > +
> > >  config LS1X_IRQ
> > >       bool "Loongson-1 Interrupt Controller"
> > >       depends on MACH_LOONGSON32
> > > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> > > index 5d8e21d3dc6d8..870423746c783 100644
> > > --- a/drivers/irqchip/Makefile
> > > +++ b/drivers/irqchip/Makefile
> > > @@ -98,6 +98,7 @@ obj-$(CONFIG_RISCV_INTC)            += irq-riscv-intc.o
> > >  obj-$(CONFIG_SIFIVE_PLIC)            += irq-sifive-plic.o
> > >  obj-$(CONFIG_IMX_IRQSTEER)           += irq-imx-irqsteer.o
> > >  obj-$(CONFIG_IMX_INTMUX)             += irq-imx-intmux.o
> > > +obj-$(CONFIG_IMX_MU_MSI)             += irq-imx-mu-msi.o
> > >  obj-$(CONFIG_MADERA_IRQ)             += irq-madera.o
> > >  obj-$(CONFIG_LS1X_IRQ)                       += irq-ls1x.o
> > >  obj-$(CONFIG_TI_SCI_INTR_IRQCHIP)    += irq-ti-sci-intr.o
> > > diff --git a/drivers/irqchip/irq-imx-mu-msi.c b/drivers/irqchip/irq-imx-mu-
> > msi.c
> > > new file mode 100644
> > > index 0000000000000..8277dba857759
> > > --- /dev/null
> > > +++ b/drivers/irqchip/irq-imx-mu-msi.c
> > > @@ -0,0 +1,462 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * NXP MU worked as MSI controller
> > > + *
> > > + * Copyright (c) 2018 Pengutronix, Oleksij Rempel
> > <o.rempel@pengutronix.de>
> > > + * Copyright 2022 NXP
> > > + *   Frank Li <Frank.Li@nxp.com>
> > > + *   Peng Fan <peng.fan@nxp.com>
> > > + *
> > > + * Based on drivers/mailbox/imx-mailbox.c
> > > + */
> > > +#include <linux/clk.h>
> > > +#include <linux/kernel.h>
> > > +#include <linux/module.h>
> > > +#include <linux/msi.h>
> > > +#include <linux/interrupt.h>
> > > +#include <linux/irq.h>
> > > +#include <linux/irqchip/chained_irq.h>
> > > +#include <linux/irqchip.h>
> > > +#include <linux/irqdomain.h>
> > > +#include <linux/of_irq.h>
> > > +#include <linux/of_pci.h>
> > > +#include <linux/of_platform.h>
> > > +#include <linux/spinlock.h>
> > > +#include <linux/dma-iommu.h>
> > > +#include <linux/pm_runtime.h>
> > > +#include <linux/pm_domain.h>
> > > +
> > > +
> > > +#define IMX_MU_CHANS            4
> > > +
> > > +enum imx_mu_xcr {
> > > +     IMX_MU_GIER,
> > > +     IMX_MU_GCR,
> > > +     IMX_MU_TCR,
> > > +     IMX_MU_RCR,
> > > +     IMX_MU_xCR_MAX,
> > > +};
> > > +
> > > +enum imx_mu_xsr {
> > > +     IMX_MU_SR,
> > > +     IMX_MU_GSR,
> > > +     IMX_MU_TSR,
> > > +     IMX_MU_RSR,
> > > +};
> > > +
> > > +enum imx_mu_type {
> > > +     IMX_MU_V1 = BIT(0),
> > > +     IMX_MU_V2 = BIT(1),
> > > +     IMX_MU_V2_S4 = BIT(15),
> > > +};
> > > +
> > > +/* Receive Interrupt Enable */
> > > +#define IMX_MU_xCR_RIEn(type, x) (type & IMX_MU_V2 ? BIT(x) : BIT(24
> > + (3 - (x))))
> > > +#define IMX_MU_xSR_RFn(type, x) (type & IMX_MU_V2 ? BIT(x) : BIT(24 +
> > (3 - (x))))
> > > +
> > > +struct imx_mu_dcfg {
> > > +     enum imx_mu_type type;
> > > +     u32     xTR;            /* Transmit Register0 */
> > > +     u32     xRR;            /* Receive Register0 */
> > > +     u32     xSR[4];         /* Status Registers */
> > > +     u32     xCR[4];         /* Control Registers */
> > > +};
> > > +
> > > +struct imx_mu_msi {
> > > +     spinlock_t                      lock;
> > > +     struct platform_device          *pdev;
> > > +     struct irq_domain               *parent;
> > > +     struct irq_domain               *msi_domain;
> > > +     void __iomem                    *regs;
> > > +     phys_addr_t                     msiir_addr;
> > > +     const struct imx_mu_dcfg        *cfg;
> > > +     unsigned long                   used;
> > > +     u32                             gic_irq;
> > > +     struct clk                      *clk;
> > > +     struct device                   *pd_a;
> > > +     struct device                   *pd_b;
> > > +     struct device_link              *pd_link_a;
> > > +     struct device_link              *pd_link_b;
> > > +};
> > > +
> > > +static void imx_mu_write(struct imx_mu_msi *msi_data, u32 val, u32 offs)
> > > +{
> > > +     iowrite32(val, msi_data->regs + offs);
> > > +}
> > > +
> > > +static u32 imx_mu_read(struct imx_mu_msi *msi_data, u32 offs)
> > > +{
> > > +     return ioread32(msi_data->regs + offs);
> > > +}
> > > +
> > > +static u32 imx_mu_xcr_rmw(struct imx_mu_msi *msi_data, enum
> > imx_mu_xcr type, u32 set, u32 clr)
> > > +{
> > > +     unsigned long flags;
> > > +     u32 val;
> > > +
> > > +     spin_lock_irqsave(&msi_data->lock, flags);
> > > +     val = imx_mu_read(msi_data, msi_data->cfg->xCR[type]);
> > > +     val &= ~clr;
> > > +     val |= set;
> > > +     imx_mu_write(msi_data, val, msi_data->cfg->xCR[type]);
> > > +     spin_unlock_irqrestore(&msi_data->lock, flags);
> > > +
> > > +     return val;
> > > +}
> > > +
> > > +static void imx_mu_msi_mask_irq(struct irq_data *data)
> > > +{
> > > +     struct imx_mu_msi *msi_data = irq_data_get_irq_chip_data(data-
> > >parent_data);
> > 
> > Urgh... No. Please don't go poking into the *parent* stuff. Implement
> > the masking at the parent level, and use irq_chip_mask_parent() for
> > this level, unless you can explain why you can't do otherwise.
> > 
> > > +
> > > +     imx_mu_xcr_rmw(msi_data, IMX_MU_RCR, 0,
> > IMX_MU_xCR_RIEn(msi_data->cfg->type, data->hwirq));
> > 
> > How about making this readable and move the dereference inside the macro?
> > 
> > > +}
> > > +
> > > +static void imx_mu_msi_unmask_irq(struct irq_data *data)
> > > +{
> > > +     struct imx_mu_msi *msi_data = irq_data_get_irq_chip_data(data-
> > >parent_data);
> > > +
> > > +     imx_mu_xcr_rmw(msi_data, IMX_MU_RCR,
> > IMX_MU_xCR_RIEn(msi_data->cfg->type, data->hwirq), 0);
> > > +}
> > > +
> > > +static struct irq_chip imx_mu_msi_irq_chip = {
> > > +     .name = "MU-MSI",
> > > +     .irq_mask       = imx_mu_msi_mask_irq,
> > > +     .irq_unmask     = imx_mu_msi_unmask_irq,
> > > +};
> > > +
> > > +static struct msi_domain_ops its_pmsi_ops = {
> > > +};
> > 
> > What does this have to do with the ITS?
> 
> Without this, it will be crashed as access 0 address.

Because the *name* of the structure has an influence on the behaviour
of the kernel?????

> 
> > 
> > > +
> > > +static struct msi_domain_info imx_mu_msi_domain_info = {
> > > +     .flags  = (MSI_FLAG_USE_DEF_DOM_OPS |
> > > +                MSI_FLAG_USE_DEF_CHIP_OPS |
> > > +                MSI_FLAG_PCI_MSIX),
> > 
> > What does PCI_MSIX mean in this context? I really wish you used
> > copy/paste a bit more carefully.
> > 
> > > +     .ops    = &its_pmsi_ops,
> > > +     .chip   = &imx_mu_msi_irq_chip,
> > > +};
> > > +
> > > +static void imx_mu_msi_compose_msg(struct irq_data *data, struct
> > msi_msg *msg)
> > > +{
> > > +     struct imx_mu_msi *msi_data = irq_data_get_irq_chip_data(data);
> > > +
> > > +     msg->address_hi = upper_32_bits(msi_data->msiir_addr);
> > > +     msg->address_lo = lower_32_bits(msi_data->msiir_addr + 4 * data-
> > >hwirq);
> > 
> > This is a horrible way of writing this. you should compute the address
> > first, and then apply the address split.
> > 
> > > +     msg->data = data->hwirq;
> > > +
> > > +     iommu_dma_compose_msi_msg(irq_data_get_msi_desc(data), msg);
> > > +}
> > > +
> > > +static int imx_mu_msi_set_affinity(struct irq_data *irq_data,
> > > +                                const struct cpumask *mask, bool force)
> > > +
> > > +{
> > > +     return IRQ_SET_MASK_OK;
> > > +}
> > 
> > Err... What effect does this have if you don't do anything?
> 
> [Frank Li] Without this, it will be crashed as access 0 address.

Then you should fix that bug, because what you have here makes
absolutely no sense.

> 
> > 
> > > +
> > > +static struct irq_chip imx_mu_msi_parent_chip = {
> > > +     .name                   = "MU",
> > > +     .irq_compose_msi_msg    = imx_mu_msi_compose_msg,
> > > +     .irq_set_affinity = imx_mu_msi_set_affinity,
> > > +};
> > > +
> > > +static int imx_mu_msi_domain_irq_alloc(struct irq_domain *domain,
> > > +                                     unsigned int virq,
> > > +                                     unsigned int nr_irqs,
> > > +                                     void *args)
> > > +{
> > > +     struct imx_mu_msi *msi_data = domain->host_data;
> > > +     msi_alloc_info_t *info = args;
> > > +     int pos, err = 0;
> > > +
> > > +     WARN_ON(nr_irqs != 1);
> > > +
> > > +     spin_lock(&msi_data->lock);
> > 
> > Interrupt fires after lock acquisition, handler masks the interrupt.
> > Deadlock.
> 
> [Frank Li] you are right, it should be spin_lock_irqsave.
> 
> > 
> > > +     pos = find_first_zero_bit(&msi_data->used, IMX_MU_CHANS);
> > > +     if (pos < IMX_MU_CHANS)
> > > +             __set_bit(pos, &msi_data->used);
> > > +     else
> > > +             err = -ENOSPC;
> > > +     spin_unlock(&msi_data->lock);
> > > +
> > > +     if (err)
> > > +             return err;
> > > +
> > > +     err = iommu_dma_prepare_msi(info->desc, msi_data->msiir_addr +
> > pos * 4);
> > 
> > Does this HW even have an IOMMU?
> 
> [Frank Li] we have a platform with iommu.    
> 
> > 
> > > +     if (err)
> > > +             return err;
> > > +
> > > +     irq_domain_set_info(domain, virq, pos,
> > > +                         &imx_mu_msi_parent_chip, msi_data,
> > > +                         handle_simple_irq, NULL, NULL);
> > 
> > This is an edge interrupt. Please handle it like one.
> 
> [Frank Li]  Not sure what your means?

A MSI is an edge interrupt. Use handle_edge_irq.

> 
> > 
> > > +     return 0;
> > > +}
> > > +
> > > +static void imx_mu_msi_domain_irq_free(struct irq_domain *domain,
> > > +                                    unsigned int virq, unsigned int nr_irqs)
> > > +{
> > > +     struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> > > +     struct imx_mu_msi *msi_data = irq_data_get_irq_chip_data(d);
> > > +
> > > +     spin_lock(&msi_data->lock);
> > 
> > Same problem.
> > 
> > > +     __clear_bit(d->hwirq, &msi_data->used);
> > > +     spin_unlock(&msi_data->lock);
> > > +}
> > > +
> > > +static const struct irq_domain_ops imx_mu_msi_domain_ops = {
> > > +     .alloc  = imx_mu_msi_domain_irq_alloc,
> > > +     .free   = imx_mu_msi_domain_irq_free,
> > > +};
> > > +
> > > +static void imx_mu_msi_irq_handler(struct irq_desc *desc)
> > > +{
> > > +     struct imx_mu_msi *msi_data = irq_desc_get_handler_data(desc);
> > > +     u32 status;
> > > +     int i;
> > > +
> > > +     status = imx_mu_read(msi_data, msi_data->cfg->xSR[IMX_MU_RSR]);
> > > +
> > > +     chained_irq_enter(irq_desc_get_chip(desc), desc);
> > > +     for (i = 0; i < IMX_MU_CHANS; i++) {
> > > +             if (status & IMX_MU_xSR_RFn(msi_data->cfg->type, i)) {
> > > +                     imx_mu_read(msi_data, msi_data->cfg->xRR + i * 4);
> > > +                     generic_handle_domain_irq(msi_data->parent, i);
> > 
> > Why the parent? You must start at the top of the hierarchy.
> > 
> > > +             }
> > > +     }
> > > +     chained_irq_exit(irq_desc_get_chip(desc), desc);
> > 
> > If your MSIs are a chained interrupt, why do you even provide an
> > affinity setting callback?
> 
> [Frank Li]  it will be crash if no affinity setting callback.

Then you have to fix your driver.

	M.

-- 
Without deviation from the norm, progress is not possible.

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Frank Li <frank.li@nxp.com>
Cc: "jdmason@kudzu.us" <jdmason@kudzu.us>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"krzysztof.kozlowski+dt@linaro.org"
	<krzysztof.kozlowski+dt@linaro.org>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"kw@linux.com" <kw@linux.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"kernel@vger.kernel.org" <kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Peng Fan <peng.fan@nxp.com>, Aisheng Dong <aisheng.dong@nxp.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"festevam@gmail.com" <festevam@gmail.com>,
	dl-linux-imx <linux-imx@nxp.com>, "kishon@ti.com" <kishon@ti.com>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"ntb@lists.linux.dev" <ntb@lists.linux.dev>
Subject: Re: [EXT] Re: [PATCH v3 2/4] irqchip: imx mu worked as msi controller
Date: Thu, 21 Jul 2022 16:28:28 +0100	[thread overview]
Message-ID: <87wnc6xz6r.wl-maz@kernel.org> (raw)
In-Reply-To: <PAXPR04MB9186A1D283ACE8BD6954039288919@PAXPR04MB9186.eurprd04.prod.outlook.com>

On Thu, 21 Jul 2022 16:22:08 +0100,
Frank Li <frank.li@nxp.com> wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Marc Zyngier <maz@kernel.org>
> > Sent: Thursday, July 21, 2022 2:57 AM
> > To: Frank Li <frank.li@nxp.com>
> > Cc: jdmason@kudzu.us; tglx@linutronix.de; robh+dt@kernel.org;
> > krzysztof.kozlowski+dt@linaro.org; shawnguo@kernel.org;
> > s.hauer@pengutronix.de; kw@linux.com; bhelgaas@google.com;
> > kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
> > kernel@lists.infradead.org; linux-pci@vger.kernel.org; Peng Fan
> > <peng.fan@nxp.com>; Aisheng Dong <aisheng.dong@nxp.com>;
> > kernel@pengutronix.de; festevam@gmail.com; dl-linux-imx <linux-
> > imx@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com;
> > ntb@lists.linux.dev
> > Subject: [EXT] Re: [PATCH v3 2/4] irqchip: imx mu worked as msi controller
> > 
> > Caution: EXT Email
> > 
> > On Wed, 20 Jul 2022 22:30:34 +0100,
> > Frank Li <Frank.Li@nxp.com> wrote:
> > >
> > > MU support generate irq by write data to a register.
> > > This patch make mu worked as msi controller.
> > > So MU can do doorbell by using standard msi api.
> > >
> > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > ---
> > >  drivers/irqchip/Kconfig          |   7 +
> > >  drivers/irqchip/Makefile         |   1 +
> > >  drivers/irqchip/irq-imx-mu-msi.c | 462
> > +++++++++++++++++++++++++++++++
> > >  3 files changed, 470 insertions(+)
> > >  create mode 100644 drivers/irqchip/irq-imx-mu-msi.c
> > >
> > > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> > > index 5e4e50122777d..4599471d880c0 100644
> > > --- a/drivers/irqchip/Kconfig
> > > +++ b/drivers/irqchip/Kconfig
> > > @@ -470,6 +470,13 @@ config IMX_INTMUX
> > >       help
> > >         Support for the i.MX INTMUX interrupt multiplexer.
> > >
> > > +config IMX_MU_MSI
> > > +     bool "i.MX MU work as MSI controller"
> > > +     default y if ARCH_MXC
> > > +     select IRQ_DOMAIN
> > > +     help
> > > +       MU work as MSI controller to do general doorbell
> > > +
> > >  config LS1X_IRQ
> > >       bool "Loongson-1 Interrupt Controller"
> > >       depends on MACH_LOONGSON32
> > > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> > > index 5d8e21d3dc6d8..870423746c783 100644
> > > --- a/drivers/irqchip/Makefile
> > > +++ b/drivers/irqchip/Makefile
> > > @@ -98,6 +98,7 @@ obj-$(CONFIG_RISCV_INTC)            += irq-riscv-intc.o
> > >  obj-$(CONFIG_SIFIVE_PLIC)            += irq-sifive-plic.o
> > >  obj-$(CONFIG_IMX_IRQSTEER)           += irq-imx-irqsteer.o
> > >  obj-$(CONFIG_IMX_INTMUX)             += irq-imx-intmux.o
> > > +obj-$(CONFIG_IMX_MU_MSI)             += irq-imx-mu-msi.o
> > >  obj-$(CONFIG_MADERA_IRQ)             += irq-madera.o
> > >  obj-$(CONFIG_LS1X_IRQ)                       += irq-ls1x.o
> > >  obj-$(CONFIG_TI_SCI_INTR_IRQCHIP)    += irq-ti-sci-intr.o
> > > diff --git a/drivers/irqchip/irq-imx-mu-msi.c b/drivers/irqchip/irq-imx-mu-
> > msi.c
> > > new file mode 100644
> > > index 0000000000000..8277dba857759
> > > --- /dev/null
> > > +++ b/drivers/irqchip/irq-imx-mu-msi.c
> > > @@ -0,0 +1,462 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * NXP MU worked as MSI controller
> > > + *
> > > + * Copyright (c) 2018 Pengutronix, Oleksij Rempel
> > <o.rempel@pengutronix.de>
> > > + * Copyright 2022 NXP
> > > + *   Frank Li <Frank.Li@nxp.com>
> > > + *   Peng Fan <peng.fan@nxp.com>
> > > + *
> > > + * Based on drivers/mailbox/imx-mailbox.c
> > > + */
> > > +#include <linux/clk.h>
> > > +#include <linux/kernel.h>
> > > +#include <linux/module.h>
> > > +#include <linux/msi.h>
> > > +#include <linux/interrupt.h>
> > > +#include <linux/irq.h>
> > > +#include <linux/irqchip/chained_irq.h>
> > > +#include <linux/irqchip.h>
> > > +#include <linux/irqdomain.h>
> > > +#include <linux/of_irq.h>
> > > +#include <linux/of_pci.h>
> > > +#include <linux/of_platform.h>
> > > +#include <linux/spinlock.h>
> > > +#include <linux/dma-iommu.h>
> > > +#include <linux/pm_runtime.h>
> > > +#include <linux/pm_domain.h>
> > > +
> > > +
> > > +#define IMX_MU_CHANS            4
> > > +
> > > +enum imx_mu_xcr {
> > > +     IMX_MU_GIER,
> > > +     IMX_MU_GCR,
> > > +     IMX_MU_TCR,
> > > +     IMX_MU_RCR,
> > > +     IMX_MU_xCR_MAX,
> > > +};
> > > +
> > > +enum imx_mu_xsr {
> > > +     IMX_MU_SR,
> > > +     IMX_MU_GSR,
> > > +     IMX_MU_TSR,
> > > +     IMX_MU_RSR,
> > > +};
> > > +
> > > +enum imx_mu_type {
> > > +     IMX_MU_V1 = BIT(0),
> > > +     IMX_MU_V2 = BIT(1),
> > > +     IMX_MU_V2_S4 = BIT(15),
> > > +};
> > > +
> > > +/* Receive Interrupt Enable */
> > > +#define IMX_MU_xCR_RIEn(type, x) (type & IMX_MU_V2 ? BIT(x) : BIT(24
> > + (3 - (x))))
> > > +#define IMX_MU_xSR_RFn(type, x) (type & IMX_MU_V2 ? BIT(x) : BIT(24 +
> > (3 - (x))))
> > > +
> > > +struct imx_mu_dcfg {
> > > +     enum imx_mu_type type;
> > > +     u32     xTR;            /* Transmit Register0 */
> > > +     u32     xRR;            /* Receive Register0 */
> > > +     u32     xSR[4];         /* Status Registers */
> > > +     u32     xCR[4];         /* Control Registers */
> > > +};
> > > +
> > > +struct imx_mu_msi {
> > > +     spinlock_t                      lock;
> > > +     struct platform_device          *pdev;
> > > +     struct irq_domain               *parent;
> > > +     struct irq_domain               *msi_domain;
> > > +     void __iomem                    *regs;
> > > +     phys_addr_t                     msiir_addr;
> > > +     const struct imx_mu_dcfg        *cfg;
> > > +     unsigned long                   used;
> > > +     u32                             gic_irq;
> > > +     struct clk                      *clk;
> > > +     struct device                   *pd_a;
> > > +     struct device                   *pd_b;
> > > +     struct device_link              *pd_link_a;
> > > +     struct device_link              *pd_link_b;
> > > +};
> > > +
> > > +static void imx_mu_write(struct imx_mu_msi *msi_data, u32 val, u32 offs)
> > > +{
> > > +     iowrite32(val, msi_data->regs + offs);
> > > +}
> > > +
> > > +static u32 imx_mu_read(struct imx_mu_msi *msi_data, u32 offs)
> > > +{
> > > +     return ioread32(msi_data->regs + offs);
> > > +}
> > > +
> > > +static u32 imx_mu_xcr_rmw(struct imx_mu_msi *msi_data, enum
> > imx_mu_xcr type, u32 set, u32 clr)
> > > +{
> > > +     unsigned long flags;
> > > +     u32 val;
> > > +
> > > +     spin_lock_irqsave(&msi_data->lock, flags);
> > > +     val = imx_mu_read(msi_data, msi_data->cfg->xCR[type]);
> > > +     val &= ~clr;
> > > +     val |= set;
> > > +     imx_mu_write(msi_data, val, msi_data->cfg->xCR[type]);
> > > +     spin_unlock_irqrestore(&msi_data->lock, flags);
> > > +
> > > +     return val;
> > > +}
> > > +
> > > +static void imx_mu_msi_mask_irq(struct irq_data *data)
> > > +{
> > > +     struct imx_mu_msi *msi_data = irq_data_get_irq_chip_data(data-
> > >parent_data);
> > 
> > Urgh... No. Please don't go poking into the *parent* stuff. Implement
> > the masking at the parent level, and use irq_chip_mask_parent() for
> > this level, unless you can explain why you can't do otherwise.
> > 
> > > +
> > > +     imx_mu_xcr_rmw(msi_data, IMX_MU_RCR, 0,
> > IMX_MU_xCR_RIEn(msi_data->cfg->type, data->hwirq));
> > 
> > How about making this readable and move the dereference inside the macro?
> > 
> > > +}
> > > +
> > > +static void imx_mu_msi_unmask_irq(struct irq_data *data)
> > > +{
> > > +     struct imx_mu_msi *msi_data = irq_data_get_irq_chip_data(data-
> > >parent_data);
> > > +
> > > +     imx_mu_xcr_rmw(msi_data, IMX_MU_RCR,
> > IMX_MU_xCR_RIEn(msi_data->cfg->type, data->hwirq), 0);
> > > +}
> > > +
> > > +static struct irq_chip imx_mu_msi_irq_chip = {
> > > +     .name = "MU-MSI",
> > > +     .irq_mask       = imx_mu_msi_mask_irq,
> > > +     .irq_unmask     = imx_mu_msi_unmask_irq,
> > > +};
> > > +
> > > +static struct msi_domain_ops its_pmsi_ops = {
> > > +};
> > 
> > What does this have to do with the ITS?
> 
> Without this, it will be crashed as access 0 address.

Because the *name* of the structure has an influence on the behaviour
of the kernel?????

> 
> > 
> > > +
> > > +static struct msi_domain_info imx_mu_msi_domain_info = {
> > > +     .flags  = (MSI_FLAG_USE_DEF_DOM_OPS |
> > > +                MSI_FLAG_USE_DEF_CHIP_OPS |
> > > +                MSI_FLAG_PCI_MSIX),
> > 
> > What does PCI_MSIX mean in this context? I really wish you used
> > copy/paste a bit more carefully.
> > 
> > > +     .ops    = &its_pmsi_ops,
> > > +     .chip   = &imx_mu_msi_irq_chip,
> > > +};
> > > +
> > > +static void imx_mu_msi_compose_msg(struct irq_data *data, struct
> > msi_msg *msg)
> > > +{
> > > +     struct imx_mu_msi *msi_data = irq_data_get_irq_chip_data(data);
> > > +
> > > +     msg->address_hi = upper_32_bits(msi_data->msiir_addr);
> > > +     msg->address_lo = lower_32_bits(msi_data->msiir_addr + 4 * data-
> > >hwirq);
> > 
> > This is a horrible way of writing this. you should compute the address
> > first, and then apply the address split.
> > 
> > > +     msg->data = data->hwirq;
> > > +
> > > +     iommu_dma_compose_msi_msg(irq_data_get_msi_desc(data), msg);
> > > +}
> > > +
> > > +static int imx_mu_msi_set_affinity(struct irq_data *irq_data,
> > > +                                const struct cpumask *mask, bool force)
> > > +
> > > +{
> > > +     return IRQ_SET_MASK_OK;
> > > +}
> > 
> > Err... What effect does this have if you don't do anything?
> 
> [Frank Li] Without this, it will be crashed as access 0 address.

Then you should fix that bug, because what you have here makes
absolutely no sense.

> 
> > 
> > > +
> > > +static struct irq_chip imx_mu_msi_parent_chip = {
> > > +     .name                   = "MU",
> > > +     .irq_compose_msi_msg    = imx_mu_msi_compose_msg,
> > > +     .irq_set_affinity = imx_mu_msi_set_affinity,
> > > +};
> > > +
> > > +static int imx_mu_msi_domain_irq_alloc(struct irq_domain *domain,
> > > +                                     unsigned int virq,
> > > +                                     unsigned int nr_irqs,
> > > +                                     void *args)
> > > +{
> > > +     struct imx_mu_msi *msi_data = domain->host_data;
> > > +     msi_alloc_info_t *info = args;
> > > +     int pos, err = 0;
> > > +
> > > +     WARN_ON(nr_irqs != 1);
> > > +
> > > +     spin_lock(&msi_data->lock);
> > 
> > Interrupt fires after lock acquisition, handler masks the interrupt.
> > Deadlock.
> 
> [Frank Li] you are right, it should be spin_lock_irqsave.
> 
> > 
> > > +     pos = find_first_zero_bit(&msi_data->used, IMX_MU_CHANS);
> > > +     if (pos < IMX_MU_CHANS)
> > > +             __set_bit(pos, &msi_data->used);
> > > +     else
> > > +             err = -ENOSPC;
> > > +     spin_unlock(&msi_data->lock);
> > > +
> > > +     if (err)
> > > +             return err;
> > > +
> > > +     err = iommu_dma_prepare_msi(info->desc, msi_data->msiir_addr +
> > pos * 4);
> > 
> > Does this HW even have an IOMMU?
> 
> [Frank Li] we have a platform with iommu.    
> 
> > 
> > > +     if (err)
> > > +             return err;
> > > +
> > > +     irq_domain_set_info(domain, virq, pos,
> > > +                         &imx_mu_msi_parent_chip, msi_data,
> > > +                         handle_simple_irq, NULL, NULL);
> > 
> > This is an edge interrupt. Please handle it like one.
> 
> [Frank Li]  Not sure what your means?

A MSI is an edge interrupt. Use handle_edge_irq.

> 
> > 
> > > +     return 0;
> > > +}
> > > +
> > > +static void imx_mu_msi_domain_irq_free(struct irq_domain *domain,
> > > +                                    unsigned int virq, unsigned int nr_irqs)
> > > +{
> > > +     struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> > > +     struct imx_mu_msi *msi_data = irq_data_get_irq_chip_data(d);
> > > +
> > > +     spin_lock(&msi_data->lock);
> > 
> > Same problem.
> > 
> > > +     __clear_bit(d->hwirq, &msi_data->used);
> > > +     spin_unlock(&msi_data->lock);
> > > +}
> > > +
> > > +static const struct irq_domain_ops imx_mu_msi_domain_ops = {
> > > +     .alloc  = imx_mu_msi_domain_irq_alloc,
> > > +     .free   = imx_mu_msi_domain_irq_free,
> > > +};
> > > +
> > > +static void imx_mu_msi_irq_handler(struct irq_desc *desc)
> > > +{
> > > +     struct imx_mu_msi *msi_data = irq_desc_get_handler_data(desc);
> > > +     u32 status;
> > > +     int i;
> > > +
> > > +     status = imx_mu_read(msi_data, msi_data->cfg->xSR[IMX_MU_RSR]);
> > > +
> > > +     chained_irq_enter(irq_desc_get_chip(desc), desc);
> > > +     for (i = 0; i < IMX_MU_CHANS; i++) {
> > > +             if (status & IMX_MU_xSR_RFn(msi_data->cfg->type, i)) {
> > > +                     imx_mu_read(msi_data, msi_data->cfg->xRR + i * 4);
> > > +                     generic_handle_domain_irq(msi_data->parent, i);
> > 
> > Why the parent? You must start at the top of the hierarchy.
> > 
> > > +             }
> > > +     }
> > > +     chained_irq_exit(irq_desc_get_chip(desc), desc);
> > 
> > If your MSIs are a chained interrupt, why do you even provide an
> > affinity setting callback?
> 
> [Frank Li]  it will be crash if no affinity setting callback.

Then you have to fix your driver.

	M.

-- 
Without deviation from the norm, progress is not possible.

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

  reply	other threads:[~2022-07-21 15:28 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20 21:30 [PATCH v3 0/4] PCI EP driver support MSI doorbell from host Frank Li
2022-07-20 21:30 ` Frank Li
2022-07-20 21:30 ` [PATCH v3 1/4] irqchip: allow pass down .pm field at IRQCHIP_PLATFORM_DRIVER_END Frank Li
2022-07-20 21:30   ` Frank Li
2022-07-20 21:30 ` [PATCH v3 2/4] irqchip: imx mu worked as msi controller Frank Li
2022-07-20 21:30   ` Frank Li
2022-07-21  7:57   ` Marc Zyngier
2022-07-21  7:57     ` Marc Zyngier
2022-07-21 15:22     ` [EXT] " Frank Li
2022-07-21 15:22       ` Frank Li
2022-07-21 15:28       ` Marc Zyngier [this message]
2022-07-21 15:28         ` Marc Zyngier
2022-07-21 15:35         ` Frank Li
2022-07-21 15:35           ` Frank Li
2022-07-26 21:48         ` Frank Li
2022-07-26 21:48           ` Frank Li
2022-07-27  8:02           ` Marc Zyngier
2022-07-27  8:02             ` Marc Zyngier
2022-07-27 15:23             ` Frank Li
2022-07-27 15:23               ` Frank Li
2022-07-27 15:34               ` Marc Zyngier
2022-07-27 15:34                 ` Marc Zyngier
2022-07-27 18:29                 ` Frank Li
2022-07-27 18:29                   ` Frank Li
2022-07-27 18:58                   ` Frank Li
2022-07-27 18:58                     ` Frank Li
2022-07-22  7:33       ` Marc Zyngier
2022-07-22  7:33         ` Marc Zyngier
2022-07-22 16:12         ` Frank Li
2022-07-22 16:12           ` Frank Li
2022-07-20 21:30 ` [PATCH v3 3/4] dt-bindings: irqchip: imx mu work " Frank Li
2022-07-20 21:30   ` Frank Li
2022-07-23 18:50   ` Krzysztof Kozlowski
2022-07-23 18:50     ` Krzysztof Kozlowski
2022-07-25 16:29     ` [EXT] " Frank Li
2022-07-25 16:29       ` Frank Li
2022-07-25 16:44       ` Krzysztof Kozlowski
2022-07-25 16:44         ` Krzysztof Kozlowski
2022-07-25 16:55         ` Frank Li
2022-07-25 16:55           ` Frank Li
2022-07-25 20:28           ` Krzysztof Kozlowski
2022-07-25 20:28             ` Krzysztof Kozlowski
2022-08-10 14:01   ` Rob Herring
2022-08-10 14:01     ` Rob Herring
2022-08-10 14:20     ` Marc Zyngier
2022-08-10 14:20       ` Marc Zyngier
2022-08-10 14:32     ` Jon Mason
2022-08-10 14:32       ` Jon Mason
2022-07-20 21:30 ` [PATCH v3 4/4] pcie: endpoint: pci-epf-vntb: add endpoint MSI support Frank Li
2022-07-20 21:30   ` 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=87wnc6xz6r.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=aisheng.dong@nxp.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=frank.li@nxp.com \
    --cc=jdmason@kudzu.us \
    --cc=kernel@pengutronix.de \
    --cc=kernel@vger.kernel.org \
    --cc=kishon@ti.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=ntb@lists.linux.dev \
    --cc=peng.fan@nxp.com \
    --cc=robh+dt@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=tglx@linutronix.de \
    /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.