Message-ID: <0ac4b527-2f79-4d21-7408-18c87cadb512@arm.com>
Date:   Wed, 27 Mar 2019 18:13:20 +0000
From:   Marc Zyngier <marc.zyngier@....com>
To:     Leonard Crestez <leonard.crestez@....com>,
        "l.stach@...gutronix.de" <l.stach@...gutronix.de>,
        Richard Zhu <hongxing.zhu@....com>
Cc:     Fabio Estevam <fabio.estevam@....com>,
        Cosmin Samoila <cosmin.samoila@....com>,
        Robin Gong <yibin.gong@....com>,
        Mircea Pop <mircea.pop@....com>,
        Daniel Baluta <daniel.baluta@....com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        Aisheng Dong <aisheng.dong@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        Robert Chiras <robert.chiras@....com>,
        Anson Huang <anson.huang@....com>, Jun Li <jun.li@....com>,
        Abel Vesa <abel.vesa@....com>,
        "robh@...nel.org" <robh@...nel.org>,
        Zening Wang <zening.wang@....com>,
        dl-linux-imx <linux-imx@....com>,
        BOUGH CHEN <haibo.chen@....com>,
        Horia Geanta <horia.geanta@....com>,
        Peter Chen <peter.chen@....com>,
        Joakim Zhang <qiangqing.zhang@....com>,
        "rjw@...ysocki.net" <rjw@...ysocki.net>,
        Leo Zhang <leo.zhang@....com>,
        Shenwei Wang <shenwei.wang@....com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Ranjani Vaidyanathan <ranjani.vaidyanathan@....com>,
        Han Xu <han.xu@....com>,
        "will.deacon@....com" <will.deacon@....com>,
        Iuliana Prodan <iuliana.prodan@....com>,
        "sudeep.holla@....com" <sudeep.holla@....com>,
        "lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
        Jacky Bai <ping.bai@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        Peng Fan <peng.fan@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        Viorel Suman <viorel.suman@....com>
Subject: Re: [RFC 0/7] cpuidle: Add poking mechanism to support non-IPI wakeup

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.

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

Powered by blists - more mailing lists