From: Leonard Crestez <leonard.crestez@nxp.com> To: Marc Zyngier <marc.zyngier@arm.com>, Abel Vesa <abel.vesa@nxp.com>, Lucas Stach <l.stach@pengutronix.de> Cc: Mark Rutland <mark.rutland@arm.com>, Abel Vesa <abelvesa@gmail.com>, Rob Herring <robh+dt@kernel.org>, Shawn Guo <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <festevam@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Jacky Bai <ping.bai@nxp.com>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, dl-linux-imx <linux-imx@nxp.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Carlo Caione <ccaione@baylibre.com> Subject: Re: [RFC 0/2] Add workaround for core wake-up on IPI for i.MX8MQ Date: Mon, 10 Jun 2019 14:32:37 +0000 [thread overview] Message-ID: <VI1PR04MB5055A808A08A1C47784E4332EE130@VI1PR04MB5055.eurprd04.prod.outlook.com> (raw) In-Reply-To: 7b86aa90-6d64-589c-f11e-d2ee6ab3fd54@arm.com 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
WARNING: multiple messages have this Message-ID (diff)
From: Leonard Crestez <leonard.crestez@nxp.com> To: Marc Zyngier <marc.zyngier@arm.com>, Abel Vesa <abel.vesa@nxp.com>, Lucas Stach <l.stach@pengutronix.de> Cc: Mark Rutland <mark.rutland@arm.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Jacky Bai <ping.bai@nxp.com>, Carlo Caione <ccaione@baylibre.com>, Fabio Estevam <festevam@gmail.com>, Sascha Hauer <s.hauer@pengutronix.de>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>, dl-linux-imx <linux-imx@nxp.com>, Pengutronix Kernel Team <kernel@pengutronix.de>, Abel Vesa <abelvesa@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Shawn Guo <shawnguo@kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [RFC 0/2] Add workaround for core wake-up on IPI for i.MX8MQ Date: Mon, 10 Jun 2019 14:32:37 +0000 [thread overview] Message-ID: <VI1PR04MB5055A808A08A1C47784E4332EE130@VI1PR04MB5055.eurprd04.prod.outlook.com> (raw) In-Reply-To: 7b86aa90-6d64-589c-f11e-d2ee6ab3fd54@arm.com 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-06-10 14:32 UTC|newest] Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-10 12:13 [RFC 0/2] Add workaround for core wake-up on IPI for i.MX8MQ Abel Vesa 2019-06-10 12:13 ` Abel Vesa 2019-06-10 12:13 ` Abel Vesa 2019-06-10 12:13 ` [RFC 1/2] irqchip: irq-imx-gpcv2: Add workaround for i.MX8MQ ERR11171 Abel Vesa 2019-06-10 12:13 ` Abel Vesa 2019-06-10 12:38 ` Leonard Crestez 2019-06-10 12:38 ` Leonard Crestez 2019-06-10 12:38 ` Leonard Crestez 2019-06-10 13:24 ` Marc Zyngier 2019-06-10 13:24 ` Marc Zyngier 2019-06-10 13:38 ` Abel Vesa 2019-06-10 13:38 ` Abel Vesa 2019-06-10 13:38 ` Abel Vesa 2019-06-10 13:51 ` Marc Zyngier 2019-06-10 13:51 ` Marc Zyngier 2019-06-10 13:51 ` Marc Zyngier 2019-06-10 14:12 ` Abel Vesa 2019-06-10 14:12 ` Abel Vesa 2019-06-10 14:12 ` Abel Vesa 2019-06-10 14:28 ` Marc Zyngier 2019-06-10 14:28 ` Marc Zyngier 2019-06-10 14:28 ` Marc Zyngier 2019-06-10 12:13 ` [RFC 2/2] arm64: dts: imx8mq: Add idle states and gpcv2 wake_request broken property Abel Vesa 2019-06-10 12:13 ` Abel Vesa 2019-06-10 13:19 ` [RFC 0/2] Add workaround for core wake-up on IPI for i.MX8MQ Mark Rutland 2019-06-10 13:19 ` Mark Rutland 2019-06-10 13:29 ` Abel Vesa 2019-06-10 13:29 ` Abel Vesa 2019-06-10 13:29 ` Abel Vesa 2019-06-10 13:39 ` Marc Zyngier 2019-06-10 13:39 ` Marc Zyngier 2019-06-10 13:39 ` Marc Zyngier 2019-06-10 13:55 ` Abel Vesa 2019-06-10 13:55 ` Abel Vesa 2019-06-10 13:55 ` Abel Vesa 2019-06-10 14:07 ` Marc Zyngier 2019-06-10 14:07 ` Marc Zyngier 2019-06-10 14:07 ` Marc Zyngier 2019-06-10 14:32 ` Leonard Crestez [this message] 2019-06-10 14:32 ` Leonard Crestez 2019-06-10 14:32 ` Leonard Crestez 2019-06-10 14:52 ` Marc Zyngier 2019-06-10 14:52 ` Marc Zyngier 2019-06-10 14:52 ` Marc Zyngier 2019-06-12 7:14 ` Thomas Gleixner 2019-06-12 7:14 ` Thomas Gleixner 2019-06-12 7:14 ` Thomas Gleixner 2019-06-12 7:35 ` Marc Zyngier 2019-06-12 7:35 ` Marc Zyngier 2019-06-12 7:35 ` Marc Zyngier 2019-06-12 7:37 ` Thomas Gleixner 2019-06-12 7:37 ` Thomas Gleixner 2019-06-12 7:37 ` Thomas Gleixner 2019-06-23 11:47 ` Martin Kepplinger 2019-06-23 11:47 ` Martin Kepplinger 2019-06-28 8:54 ` Abel Vesa 2019-06-28 8:54 ` Abel Vesa 2019-06-28 8:54 ` Abel Vesa 2019-07-02 6:47 ` Martin Kepplinger 2019-07-02 6:47 ` Martin Kepplinger 2019-07-02 6:47 ` Martin Kepplinger 2019-07-02 11:33 ` Abel Vesa 2019-07-02 11:33 ` Abel Vesa 2019-07-02 11:33 ` Abel Vesa 2019-07-08 7:54 ` Martin Kepplinger 2019-07-08 7:54 ` Martin Kepplinger 2019-07-08 7:54 ` Martin Kepplinger 2019-07-08 12:20 ` Martin Kepplinger 2019-07-08 12:20 ` Martin Kepplinger 2019-07-08 12:20 ` Martin Kepplinger 2019-10-30 6:11 ` Martin Kepplinger 2019-10-30 6:11 ` Martin Kepplinger 2019-10-30 7:33 ` Martin Kepplinger 2019-10-30 7:33 ` Martin Kepplinger 2019-10-30 8:08 ` Abel Vesa 2019-10-30 8:08 ` Abel Vesa 2019-10-30 8:14 ` Martin Kepplinger 2019-10-30 8:14 ` Martin Kepplinger 2019-11-04 8:49 ` Martin Kepplinger 2019-11-04 8:49 ` Martin Kepplinger 2019-11-04 10:35 ` Abel Vesa 2019-11-04 10:35 ` Abel Vesa 2019-11-06 11:59 ` Martin Kepplinger 2019-11-06 11:59 ` Martin Kepplinger 2019-11-06 22:36 ` Leonard Crestez 2019-11-06 22:36 ` Leonard Crestez 2019-11-08 11:21 ` Martin Kepplinger 2019-11-08 11:21 ` Martin Kepplinger 2019-11-08 11:50 ` Abel Vesa 2019-11-08 11:50 ` Abel Vesa 2019-11-08 14:17 ` Martin Kepplinger 2019-11-08 14:17 ` Martin Kepplinger 2019-11-11 7:54 ` Abel Vesa 2019-11-11 7:54 ` Abel Vesa 2019-11-25 17:23 ` Martin Kepplinger 2019-11-25 17:23 ` Martin Kepplinger
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=VI1PR04MB5055A808A08A1C47784E4332EE130@VI1PR04MB5055.eurprd04.prod.outlook.com \ --to=leonard.crestez@nxp.com \ --cc=abel.vesa@nxp.com \ --cc=abelvesa@gmail.com \ --cc=ccaione@baylibre.com \ --cc=devicetree@vger.kernel.org \ --cc=festevam@gmail.com \ --cc=kernel@pengutronix.de \ --cc=l.stach@pengutronix.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lorenzo.pieralisi@arm.com \ --cc=marc.zyngier@arm.com \ --cc=mark.rutland@arm.com \ --cc=ping.bai@nxp.com \ --cc=robh+dt@kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=shawnguo@kernel.org \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.