RE: [PATCH v10 2/2] PCI: keembay: Add support for Intel Keem Bay

["Thokala, Srikanth" <srikanth.thokala@intel.com>]

Hi Marc,

> -----Original Message-----
> From: Marc Zyngier <maz@kernel.org>
> Sent: Monday, July 26, 2021 1:30 PM
> To: Thokala, Srikanth <srikanth.thokala@intel.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>; robh+dt@kernel.org;
> linux-pci@vger.kernel.org; devicetree@vger.kernel.org;
> andriy.shevchenko@linux.intel.com; mgross@linux.intel.com; Raja
> Subramanian, Lakshmi Bai <lakshmi.bai.raja.subramanian@intel.com>;
> Sangannavar, Mallikarjunappa <mallikarjunappa.sangannavar@intel.com>;
> kw@linux.com
> Subject: Re: [PATCH v10 2/2] PCI: keembay: Add support for Intel Keem
> Bay
> 
> On 2021-06-25 04:23, Thokala, Srikanth wrote:
> > Hi Lorenzo,
> >
> >> -----Original Message-----
> >> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >> Sent: Monday, June 21, 2021 10:23 PM
> >> To: Thokala, Srikanth <srikanth.thokala@intel.com>; maz@kernel.org
> >> Cc: robh+dt@kernel.org; linux-pci@vger.kernel.org;
> >> devicetree@vger.kernel.org; andriy.shevchenko@linux.intel.com;
> >> mgross@linux.intel.com; Raja Subramanian, Lakshmi Bai
> >> <lakshmi.bai.raja.subramanian@intel.com>; Sangannavar,
> Mallikarjunappa
> >> <mallikarjunappa.sangannavar@intel.com>; kw@linux.com
> >> Subject: Re: [PATCH v10 2/2] PCI: keembay: Add support for Intel
> Keem
> >> Bay
> >>
> >> [+Marc]
> >>
> >> On Mon, Jun 07, 2021 at 09:10:44PM +0530, srikanth.thokala@intel.com
> >> wrote:
> >> [...]
> >>
> >> > +static void keembay_pcie_msi_irq_handler(struct irq_desc *desc)
> >> > +{
> >> > +	struct keembay_pcie *pcie =
> irq_desc_get_handler_data(desc);
> >> > +	struct irq_chip *chip = irq_desc_get_chip(desc);
> >> > +	u32 val, mask, status;
> >> > +	struct pcie_port *pp;
> >> > +
> >> > +	chained_irq_enter(chip, desc);
> >> > +
> >> > +	pp = &pcie->pci.pp;
> >> > +	val = readl(pcie->apb_base + PCIE_REGS_INTERRUPT_STATUS);
> >> > +	mask = readl(pcie->apb_base + PCIE_REGS_INTERRUPT_ENABLE);
> >> > +
> >> > +	status = val & mask;
> >> > +
> >> > +	if (status & MSI_CTRL_INT) {
> >> > +		dw_handle_msi_irq(pp);
> >> > +		writel(status, pcie->apb_base +
> PCIE_REGS_INTERRUPT_STATUS);
> >> > +	}
> >> > +
> >> > +	chained_irq_exit(chip, desc);
> >> > +}
> >> > +
> >> > +static int keembay_pcie_setup_msi_irq(struct keembay_pcie *pcie)
> >> > +{
> >> > +	struct dw_pcie *pci = &pcie->pci;
> >> > +	struct device *dev = pci->dev;
> >> > +	struct platform_device *pdev = to_platform_device(dev);
> >> > +	int irq;
> >> > +
> >> > +	irq = platform_get_irq_byname(pdev, "pcie");
> >> > +	if (irq < 0)
> >> > +		return irq;
> >> > +
> >> > +	irq_set_chained_handler_and_data(irq,
> keembay_pcie_msi_irq_handler,
> >> > +					 pcie);
> >> > +
> >>
> >> Ok this is yet another DWC MSI incantation and given that Marc
> worked
> >> hard consolidating them let's have a look before we merge it.
> >>
> >> IIUC - this IP relies on the DWC logic to handle MSIs + custom
> >> registers to detect a pending MSI IRQ because the logic in
> >> dw_chained_msi_irq() is *not* enough so you have to register
> >> a driver specific chained handler. This looks similar to the dra7xx
> >> driver MSI handling but I am not entirely convinced it is needed.
> >>
> >> I assume this code in keembay_pcie_msi_irq_handler() is required
> >> owing to additional IP logic on top of the standard DWC IP, in
> >> particular the PCIE_REGS_INTERRUPT_STATUS write to "clear" the
> >> IRQ.
> >>
> >> We need more insights before merging it so please provide them.
> >>
> >> pp = &pcie->pci.pp;
> >> val = readl(pcie->apb_base + PCIE_REGS_INTERRUPT_STATUS);
> >> mask = readl(pcie->apb_base + PCIE_REGS_INTERRUPT_ENABLE);
> >>
> >> status = val & mask;
> >>
> >> if (status & MSI_CTRL_INT) {
> >> 	dw_handle_msi_irq(pp);
> >> 	writel(status, pcie->apb_base + PCIE_REGS_INTERRUPT_STATUS);
> >> }
> >
> > Yes, your understanding is correct.
> >
> > Additional registers PCIE_REGS_INTERRUPT_ENABLE/_STATUS are provided
> > by IP to control the interrupts.
> >
> > To receive MSI interrupts, SW must enable bit '8' of _ENABLE
> register.
> > And once a MSI is raised by the End point, bit '8' of _STATUS
> register
> > will be set and it needs to be cleared after servicing the interrupt.
> 
> What isn't clear here is whether the other bits that are written back
> are significant and have a side effect. If only bit 8 is required,
> shouldn't you *only* write this bit back?
> 
> Only you can know the answer to this, but it would be good if you
> could actually document this deviation from the already wonky
> DWC infrastructure.

SW will only unmask MSI Interrupt i.e. bit '8' in the 'INTERRUPT_ENABLE'
register during the Root Port initialization, other bits of this register
are not significant in this mode.

Thanks!
Srikanth

> 
> Thanks,
> 
>          M.
> --
> Jazz is not dead. It just smells funny...