> -----Original Message----- > From: Aisheng Dong > Sent: 2019年3月28日 19:21 > To: Marc Zyngier <[email protected]>; Leonard Crestez > <[email protected]>; [email protected]; Richard Zhu > <[email protected]>; Jacky Bai <[email protected]> > Cc: Fabio Estevam <[email protected]>; Cosmin Samoila > <[email protected]>; Robin Gong <[email protected]>; Mircea Pop > <[email protected]>; Daniel Baluta <[email protected]>; > [email protected]; [email protected]; Robert Chiras > <[email protected]>; Anson Huang <[email protected]>; Jun Li > <[email protected]>; Abel Vesa <[email protected]>; [email protected]; > Zening Wang <[email protected]>; dl-linux-imx <[email protected]>; > BOUGH CHEN <[email protected]>; Horia Geanta > <[email protected]>; Peter Chen <[email protected]>; Joakim Zhang > <[email protected]>; [email protected]; Leo Zhang > <[email protected]>; Shenwei Wang <[email protected]>; > [email protected]; [email protected]; Ranjani > Vaidyanathan <[email protected]>; Han Xu <[email protected]>; > [email protected]; Iuliana Prodan <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected]; Peng Fan > <[email protected]>; [email protected]; Viorel Suman > <[email protected]> > Subject: RE: [RFC 0/7] cpuidle: Add poking mechanism to support non-IPI > wakeup > > > From: Marc Zyngier [mailto:[email protected]] > > 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...
