[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o8f4fkkh.wl-maz@kernel.org>
Date: Sat, 27 Mar 2021 19:44:30 +0000
From: Marc Zyngier <maz@...nel.org>
To: Pali Rohár <pali@...nel.org>
Cc: Jianjun Wang <jianjun.wang@...iatek.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Rob Herring <robh+dt@...nel.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Ryder Lee <ryder.lee@...iatek.com>,
Philipp Zabel <p.zabel@...gutronix.de>,
Matthias Brugger <matthias.bgg@...il.com>,
linux-pci@...r.kernel.org, linux-mediatek@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, youlin.pei@...iatek.com,
chuanjia.liu@...iatek.com, qizhong.cheng@...iatek.com,
sin_jieyang@...iatek.com, drinkcat@...omium.org,
Rex-BC.Chen@...iatek.com, anson.chuang@...iatek.com,
Krzysztof Wilczyski <kw@...ux.com>
Subject: Re: [v9,5/7] PCI: mediatek-gen3: Add MSI support
On Sat, 27 Mar 2021 19:28:37 +0000,
Pali Rohár <pali@...nel.org> wrote:
>
> On Wednesday 24 March 2021 11:05:08 Jianjun Wang wrote:
> > +static void mtk_pcie_msi_handler(struct mtk_pcie_port *port, int set_idx)
> > +{
> > + struct mtk_msi_set *msi_set = &port->msi_sets[set_idx];
> > + unsigned long msi_enable, msi_status;
> > + unsigned int virq;
> > + irq_hw_number_t bit, hwirq;
> > +
> > + msi_enable = readl_relaxed(msi_set->base + PCIE_MSI_SET_ENABLE_OFFSET);
> > +
> > + do {
> > + msi_status = readl_relaxed(msi_set->base +
> > + PCIE_MSI_SET_STATUS_OFFSET);
> > + msi_status &= msi_enable;
> > + if (!msi_status)
> > + break;
> > +
> > + for_each_set_bit(bit, &msi_status, PCIE_MSI_IRQS_PER_SET) {
> > + hwirq = bit + set_idx * PCIE_MSI_IRQS_PER_SET;
> > + virq = irq_find_mapping(port->msi_bottom_domain, hwirq);
> > + generic_handle_irq(virq);
> > + }
> > + } while (true);
>
> Hello!
>
> Just a question, cannot this while-loop cause block of processing other
> interrupts?
This is a level interrupt. You don't have much choice but to handle it
immediately, although an alternative would be to mask it and deal with
it in a thread. And since Linux doesn't deal with interrupt priority,
a screaming interrupt is never a good thing.
> I have done tests with different HW (aardvark) but with same while(true)
> loop logic. One XHCI PCIe controller was sending MSI interrupts too fast
> and interrupt handler with this while(true) logic was in infinite loop.
> During one IRQ it was calling infinite many times generic_handle_irq()
> as HW was feeding new and new MSI hwirq into status register.
Define "too fast". If something in the system is able to program the
XHCI device in such a way that it causes a screaming interrupt, that's
the place to look for problems, and probably not in the interrupt
handling itself, which does what it is supposed to do.
> But this is different HW, so it can have different behavior and does not
> have to cause above issue.
>
> I have just spotted same code pattern for processing MSI interrupts...
This is a common pattern that you will find in pretty much any
interrupt handling/demuxing, and is done this way when the cost of
taking the exception is high compared to that of handling it.
Which is pretty much any of the badly designed, level-driving,
DW-inspired, sorry excuse for MSI implementations that are popular on
low-end ARM SoCs.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists