[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AM0PR0402MB35709190DBBF8498237105838CBF0@AM0PR0402MB3570.eurprd04.prod.outlook.com>
Date: Thu, 20 Dec 2018 05:52:07 +0000
From: Richard Zhu <hongxing.zhu@....com>
To: Lucas Stach <l.stach@...gutronix.de>,
Bjorn Helgaas <helgaas@...nel.org>
CC: Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Andrew Smirnov <andrew.smirnov@...il.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Sven Van Asbroeck <thesven73@...il.com>,
Kishon Vijay Abraham I <kishon@...com>,
Gustavo Pimentel <gustavo.pimentel@...opsys.com>,
Shawn Lin <shawn.lin@...k-chips.com>,
Trent Piepho <tpiepho@...inj.com>
Subject: RE: [v4] PCI: imx: make msi work without CONFIG_PCIEPORTBUS=y
Hi Bjorn:
> -----Original Message-----
> From: Lucas Stach [mailto:l.stach@...gutronix.de]
> Sent: 2018年12月19日 23:52
> To: Bjorn Helgaas <helgaas@...nel.org>; Richard Zhu
> <hongxing.zhu@....com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@....com>; Andrew Smirnov
> <andrew.smirnov@...il.com>; linux-pci@...r.kernel.org;
> linux-kernel@...r.kernel.org; linux-arm-kernel@...ts.infradead.org; Sven Van
> Asbroeck <thesven73@...il.com>; Niklas Cassel <niklas.cassel@...s.com>;
> Kishon Vijay Abraham I <kishon@...com>; Gustavo Pimentel
> <gustavo.pimentel@...opsys.com>; Shawn Lin <shawn.lin@...k-chips.com>;
> Trent Piepho <tpiepho@...inj.com>
> Subject: Re: [v4] PCI: imx: make msi work without CONFIG_PCIEPORTBUS=y
>
> Am Mittwoch, den 19.12.2018, 08:12 -0600 schrieb Bjorn Helgaas:
> > [+cc Sven, Trent, et al from related report:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flor
> >
> e.kernel.org%2Flinux-pci%2F20181218210444.5950-1-TheSven73%40google
> mai
> >
> l.com&data=02%7C01%7Chongxing.zhu%40nxp.com%7C05ba3b5bb42c
> 4db9bf3b
> >
> 08d665c9f17b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
> 808315347
> >
> 780466&sdata=ta7ffj9EPGoqAjDiS1ORvR65A2IhMUpb2Endz9%2B6zM4
> %3D&
> > reserved=0]
> >
> > On Fri, Dec 14, 2018 at 06:44:15AM +0000, Richard Zhu wrote:
> > > Assertion of the MSI Enable bit of RC's MSI CAP is mandatory
> > > required to trigger MSI on i.MX6 PCIe.
> > > This bit would be asserted when CONFIG_PCIEPORTBUS=y.
> > > Thus, the MSI works fine on i.MX6 PCIe before the commit "f3fdfc4".
> > >
> > > Assert it unconditionally when MSI is enabled.
> > > Otherwise, the MSI wouldn't be triggered although the EP is present
> > > and the MSIs are assigned.
> >
> > OK, I think I finally understand most of what's going on. Please
> > check the following possible changelog text:
> >
> > The MSI Enable bit in the MSI Capability (PCIe r4.0, sec 7.7.1.2)
> > controls whether a Function can request service using MSI.
> >
> > i.MX6 Root Ports implement the MSI Capability and may use MSI to
> > request service for events like PME, hotplug, AER, etc. In
> > addition, on i.MX6, the MSI Enable bit controls delivery of MSI
> > interrupts from components below the Root Port.
> >
> > Prior to f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
> > CONFIG_PCIEPORTBUS"), enabling CONFIG_PCI_IMX6 automatically
> also
> > enabled CONFIG_PCIEPORTBUS, and when portdrv claimed the Root
> Ports,
> > it set the MSI Enable bit so it could use PME, hotplug, AER, etc.
> > As a side effect, that also enabled delivery of MSI interrupts from
> > downstream components.
> >
> > After f3fdfc4ac3a2, the imx6q-pcie driver can operate without
> > portdrv, but that means imx6q-pcie must set the MSI Enable bit
> > itself if downstream components use MSI.
> >
> > Fixes: f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
> > CONFIG_PCIEPORTBUS")
> >
> > I still don't understand exactly *how* MSI Enable affects MSI from
> > downstream components, since the downstream component just does a
> DMA
> > write, and the Root Port can't tell whether the write is to memory or
> > interrupt controller unless the Root Port knows where the MSI targets
> > are, e.g., if the interrupt controller is actually part of the RC.
>
[Richard Zhu] Thanks a lot for your kindly help to craft the commit log.
I'm totally fine with it.
Just like Lucas said below, the MSI trigger conditions are part of the glue logic
When integrate this IP into iMX6 SOC.
The MSI Enable bit set of RC is one of the mandatory required condition to
trigger MSI from EP.
Best Regards
Richard Zhu
> The controller terminating the MSI write is part of the DWC PCIe host
> controller on i.MX6, which is questionable at least when you think about how
> a MSI should be self-synchronizing to memory writes, but that's reality...
>
> As to why the controller needs the MSI Enable bit set, I have no idea.
> But then the DWC controller is known to have some funky design limitations
> regarding MSI, like not forwarding legacy PCI interrupts anymore when MSI is
> enabled, so it's not totally surprising that we need some quirky setup here.
>
> Regards,
> Lucas
Powered by blists - more mailing lists