> -----Original Message----- > From: Aisheng Dong > Sent: 2019年3月28日 19:21 > To: Marc Zyngier <marc.zyng...@arm.com>; Leonard Crestez > <leonard.cres...@nxp.com>; l.st...@pengutronix.de; Richard Zhu > <hongxing....@nxp.com>; Jacky Bai <ping....@nxp.com> > Cc: Fabio Estevam <fabio.este...@nxp.com>; Cosmin Samoila > <cosmin.samo...@nxp.com>; Robin Gong <yibin.g...@nxp.com>; Mircea Pop > <mircea....@nxp.com>; Daniel Baluta <daniel.bal...@nxp.com>; > catalin.mari...@arm.com; shawn...@kernel.org; Robert Chiras > <robert.chi...@nxp.com>; Anson Huang <anson.hu...@nxp.com>; Jun Li > <jun...@nxp.com>; Abel Vesa <abel.v...@nxp.com>; r...@kernel.org; > Zening Wang <zening.w...@nxp.com>; dl-linux-imx <linux-...@nxp.com>; > BOUGH CHEN <haibo.c...@nxp.com>; Horia Geanta > <horia.gea...@nxp.com>; Peter Chen <peter.c...@nxp.com>; Joakim Zhang > <qiangqing.zh...@nxp.com>; r...@rjwysocki.net; Leo Zhang > <leo.zh...@nxp.com>; Shenwei Wang <shenwei.w...@nxp.com>; > linux...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Ranjani > Vaidyanathan <ranjani.vaidyanat...@nxp.com>; Han Xu <han...@nxp.com>; > will.dea...@arm.com; Iuliana Prodan <iuliana.pro...@nxp.com>; > sudeep.ho...@arm.com; lorenzo.pieral...@arm.com; > linux-kernel@vger.kernel.org; mark.rutl...@arm.com; Peng Fan > <peng....@nxp.com>; ker...@pengutronix.de; Viorel Suman > <viorel.su...@nxp.com> > Subject: RE: [RFC 0/7] cpuidle: Add poking mechanism to support non-IPI > wakeup > > > From: Marc Zyngier [mailto:marc.zyng...@arm.com] > > Sent: Thursday, March 28, 2019 2:13 AM On 27/03/2019 17:00, Leonard > > Crestez wrote: > > > On Wed, 2019-03-27 at 17:06 +0100, Lucas Stach wrote: > > >> Am Mittwoch, den 27.03.2019, 15:57 +0000 schrieb Marc Zyngier: > > >>> On 27/03/2019 15:44, Lucas Stach wrote: > > >>>> Am Mittwoch, den 27.03.2019, 13:21 +0000 schrieb Abel Vesa: > > >>>>> This work is a workaround I'm looking into (more as a background > > >>>>> task) in order to add support for cpuidle on i.MX8MQ based > platforms. > > >>>>> > > >>>>> The main idea here is getting around the missing GIC > > >>>>> wake_request signal (due to integration design issue) by waking > > >>>>> up a each individual core through some dedicated SW power-up > > >>>>> bits inside the power controller (GPC) right before every IPI is > > >>>>> requested for that each > > individual core. > > >>>> > > >>>> Just a general comment, without going into the details of this series: > > >>>> this issue is not only affecting IPIs, but also MSIs terminated > > >>>> at the GIC. Currently MSIs are terminated at the PCIe core, but > > >>>> terminating them at the GIC is clearly preferable, as this allows > > >>>> assigning CPU affinity to individual MSIs and lowers IRQ service > overhead. > > >>>> > > >>>> I'm not sure what the consequences are for upstream Linux support > > >>>> yet, but we should keep in mind that having a workaround for IPIs > > >>>> is only solving part of the issue. > > >>> > > >>> If this erratum is affecting more than just IPIs, then indeed I > > >>> don't see how this patch series solves anything. > > >>> > > >>> But the erratum documentation seems to imply that only SGIs are > > >>> affected, and goes as far as suggesting to use an external > > >>> interrupt would solve it. How comes this is not the case? Or is it > > >>> that anything directly routed to a redistributor is also affected? > > >>> This would break LPIs (and thus MSIs) and PPIs (the CPU timer, among > others). > > >>> > > >>> What is the *exact* status of this thing? I have the ugly feeling > > >>> that the true workaround is just to disable cpuidle. > > >> > > >> As far as I understand the erratum, the basic issue is that the GIC > > >> wake_request signals are not connected to the GPC (the > > >> CPU/peripheral power sequencer). The SPIs are routed through the > > >> GPC and thus are visible as wakeup sources, which is why the > > >> workaround of using an external SPI as wakeup trigger for the IPI works. > > > > > > We had a kernel workaround for IPIs in our internal tree for a long > > > time and I don't think we do anything special for PCI. Does PCI MSI > > > really bypass the GPC on 8mq? > > > > If you have an ITS, certainly. If you don't, it depends. MSIs can hit > > the distributor's MBI registers and generate non-wired SPIs, which I > > assume will bypass the GPC altogether. > > > > Richard & Jacky, > > Can you double check if this issue affect PCI MSI function? > [Richard Zhu] GIC V3 has the ITS/LPIs features. That can be used by PCIe MSI functions. BTW, the PCIe MSI ITS mode is not enabled in vendor tree.
Best Regards Richard Zhu > Regards > Dong Aisheng > > > > Adding Richard/Jacky, they might know about this. > > > > > > This seems like something of a corner case to me, don't many imx > > > boards ship without PCI; especially for low-power scenarios? If > > > required it might be reasonable to add an additional workaround to > > > disable all cpuidle if pci msis are used. > > > > Establishing a link between cpuidle and PCI in the kernel would be > > pretty invasive, and that would come on top of what this series also > mandates. > > > > At that level of apparent brokenness, it is far safer to get cpuidle > > out of the picture altogether, and I'd rather see these patches in a vendor > tree (for once). > > > > Thanks, > > > > M. > > -- > > Jazz is not dead. It just smells funny...
