On 21-11-03 13:09:15, Martin Kepplinger wrote:
Am Dienstag, dem 02.11.2021 um 11:55 +0100 schrieb Alexander Stein:
quoted
Hello,
I was hit by the errata e11171 on imx8mq on our custom board. I found
[1] from over 2 years ago, and the even older patchset [2].
Is there some final conclusion or fix regarding this errata? From
what
I understand the proposed change is apparently not acceptable in
mainline for several reasons. I'm wondering what's the current
status.
Unfortunately, there is not gonna be an upstream solution for this
errata. Long story short, the SOC is missing wakeup lines from gic
to gpc. This means the IPIs are affected. So, knowing all that,
in order to wake up a core, you need to write a bit in some register
in gpc. The SW workaround (non upstreamable) I provided does exactly
that by hijacking the gic_raise_softirq __smp_cross_call handler and
registers a wrapper over it which also calls into ATF (using SIP)
and wakes up that specific core by writing into the gpc register.
There is no other possible way to wake up a core on 8MQ.
quoted
As suggested at that time, the only solution (right now) is to
disable
cpuidle on imx8mq?
Yes, the vendor actually suggests that, but you can use the mentioned
hack.
quoted
Best regards,
Alexander
[1] https://lkml.org/lkml/2019/6/10/350
[2] https://lkml.org/lkml/2019/3/27/542
Hi Alexander, hi Abel,
At this point my understanding is basically the same. We carry (a
slight variation of) the above in our tree ever since in oder to have
the cpu-sleep sleep state. Not using it is not acceptable to us :)
Until now there's one internal API change we need to revert (bring
back) in order for this to work. For reference, this is our current
implementation:
https://source.puri.sm/martin.kepplinger/linux-next/-/compare/0b90c3622755e0155632d8cc25edd4eb7f875968...ce4803745a180adc8d87891d4ff8dff1c7bd5464
Abel, can you still say that, in case this solution won't apply anymore
in the future, that you would be available to create an update?
I'll try to find a workaround soon, based on the same general idea
behind the current one you guys are using. I'll do this in my own time
since the company does not allocate resources for 8MQ cpuidle support anymore.
Can you even imagine a possibly acceptable solution for mainline to
this? Nothing is completely set in stone with Linux :)
I believe Marc was pretty clear about not accepting such a workaround
(and, TBH, it makes perfect sense not to).
Since I don't think there is any other way that would go around the
gic driver, I believe this has hit an end when it comes to upstream support.
Sorry about that.
I'm open to any suggestions though.
thank you very much,
martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel