> 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? 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...