[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191030080727.7pcvhd4466dproy4@fsr-ub1664-175>
Date: Wed, 30 Oct 2019 08:08:25 +0000
From: Abel Vesa <abel.vesa@....com>
To: Martin Kepplinger <martink@...teo.de>
CC: Abel Vesa <abelvesa@...il.com>, Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Marc Zyngier <marc.zyngier@....com>,
Lucas Stach <l.stach@...gutronix.de>,
Jacky Bai <ping.bai@....com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Leonard Crestez <leonard.crestez@....com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Carlo Caione <ccaione@...libre.com>,
dl-linux-imx <linux-imx@....com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 0/2] Add workaround for core wake-up on IPI for i.MX8MQ
On 19-10-30 07:11:37, Martin Kepplinger wrote:
> On 23.06.19 13:47, Martin Kepplinger wrote:
> > On 10.06.19 14:13, Abel Vesa wrote:
> >> This is another alternative for the RFC:
> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2019%2F3%2F27%2F545&data=02%7C01%7Cabel.vesa%40nxp.com%7Cf5f8d8dd37974234fcb108d75d000944%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637080127051582184&sdata=qZEo1fY1lkTjqZWuuQftYJ5euEsSxjEAqGILCY8ChnU%3D&reserved=0
> >>
> >> This new workaround proposal is a little bit more hacky but more contained
> >> since everything is done within the irq-imx-gpcv2 driver.
> >>
> >> 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.
> >>
> >> I also have the patches ready for TF-A but I'll hold on to them until I see if
> >> this has a chance of getting in.
> >
>
> Hi Abel,
>
> Running this workaround doesn't seem to work anymore on 5.4-rcX. Linux
> doesn't boot, with ATF unchanged (includes your workaround changes). I
> can try to add more details to this...
>
This is happening because the system counter is now enabled on 8mq.
And since the irq-imx-gpcv2 is using as irq_set_affinity the
irq_chip_set_affinity_parent. This is because the actual implementation
of the driver relies on GIC to set the right affinity. On a SoC
that has the wake_request signales linked to the power controller this
works fine. Since the system counter is actually the tick broadcast
device and the set affinity relies only on GIC, the cores can't be
woken up by the broadcast interrupt.
> Have you tested this for 5.4? Could you update this workaround? Please
> let me know if I missed any earlier update on this (having a cpu-sleep
> idle state).
>
The solution is to implement the set affinity in the irq-imx-gpcv2 driver
which would allow the gpc to wake up the target core when the broadcast
irq arrives.
I have a patch for this. I just need to clean it up a little bit.
Unfortunately, it won't go upstream since everuone thinks the gic
should be the one to control the affinity. This obviously doesn't work
on 8mq.
Currently, I'm at ELCE in Lyon. Will get back at the office tomorrow
and sned you what I have.
> thanks!
>
> martin
Powered by blists - more mailing lists