On 6/10/2019 5:08 PM, Marc Zyngier wrote: > On 10/06/2019 14:55, Abel Vesa wrote: >> On 19-06-10 14:39:02, Marc Zyngier wrote: >>> On 10/06/2019 14:29, Abel Vesa wrote: >>>> On 19-06-10 14:19:21, Mark Rutland wrote: >>>>> On Mon, Jun 10, 2019 at 03:13:44PM +0300, Abel Vesa wrote: >>>>>> Basically, it 'hijacks' the registered gic_raise_softirq __smp_cross_call >>>>>> handler and registers instead a wrapper which calls in the 'hijacked' >>>>>> handler, after that calling into EL3 which will take care of the actual >>>>>> wake up. This time, instead of expanding the PSCI ABI, we use a new vendor SIP. >>>>> >>>>> IIUC from last time [1,2], this erratum affects all interrupts >>>>> targetting teh idle CPU, not just IPIs, so even if the bodge is more >>>>> self-contained, it doesn't really solve the issue, and there are still >>>>> cases where a CPU will not be woken from idle when it should be (e.g. >>>>> upon receipt of an LPI). >>>> >>>> Wrong, this erratum does not affect any other type of interrupts, other >>>> than IPIs. That is because all the other interrupts go through GPC, >>>> which means the cores will wake up on any other type (again, other than IPI). >>> >>> Huh... Are you saying that LPIs and PPIs are going through the GPC, and >>> will trigger the wake-up of the core? That's not the conclusion we >>> reached last time. >> >> Hmm, I don't think that was the conclusion. Yes, Lucas was saying (IIRC) >> that if you terminate the IRQs at GIC then all the other interrupts will be >> in the same situation. But the performance improvement given by terminating >> them at GIC might not be worth it when compared to the cpuidle support. > > PPIs are broken, > relying on some other terrible hack for the timer (and only the timer, > leaving other PPIs dead as a nail). It also implies that LPIs have never > been looked into, and given that they aren't routed through the GPC, the > conclusion is pretty easy to draw. > > Nobody is talking about performance here. It is strictly about > correctness, and what I read about this system is that it cannot > reliably use cpuidle. My argument was that it's fine if PPIs and LPIs are broken as long as they're not used: * PPIs are only used for local timer which is not used for wakeup. * LPIs on imx are not currently implemented. This workaround is only targeted at a very specific SOC with specific usecases and in that context it behaves correctly, as far as I can tell. As mentioned in another thread the HW issue was already solved in newer chips of the same family (like imx8mm). If there is a need for PPIs and LPIs on imx8mq in the future then maybe we can detect that scenario and disable cpuidle? -- Regards, Leonard
