Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp336446ybb; Thu, 28 Mar 2019 03:38:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqyUdNynYOnj8W73hOjviXgxtphW6157ByZ+1H9x9CJ9tcRniTzbKbsfXKdgGvtsnqseE8Rl X-Received: by 2002:a65:4342:: with SMTP id k2mr39970011pgq.445.1553769482241; Thu, 28 Mar 2019 03:38:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553769482; cv=none; d=google.com; s=arc-20160816; b=mi6iMzBGADilAX0XikMohd0MqAS/vIVMq3YCA1yfGZUt4JMZWfYCbE50CJclU6exN0 zxQ0aF0WgycYmeIRdCwSeFWcnktsEtOHcJIWKKOBlitekR46dpwv9LK6QwGX2ldJpsag 6QcFsF618ZWm9CienJ8piApGiZs30NhXfM2auR4Qh2FYz1ikyNMVxM1KSqL5LLDKBX7O mx2whNGwbHdQOIt3ZzVmNWiC7qJK2LGBfkifd4wX5QhvsXBYPt6g13MpdZDYwBhwljEC EhOfjW/EGDEgRzoURNek6TCjcpZnOGQbj+s3EPqXZzPnch4IG6pOI1VC5FzFF+aTH4Ur Cbvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:autocrypt:openpgp:from:references:cc:to :subject; bh=2MnX5ebb1a9foXxd0OhWLNIswtF1DYiGtH0qM+F28FQ=; b=qECXyW7God63VRY2F9L2FIYUOjNPhAUvibuy4bda0mJEh0vh9Gw4BXvflhiraVR6kD FUC2Axz+X/Z7XAFFpVAtO0xy4dPsnOThN4po854fRtdFnwPTNlrZ0vXvC4Ql/w1QX5C5 uctvUOIzDvkrBvwJuQf3ddAuaB4NUi0bNUJI1k/K9AYvp4vUv6+JoTBrlcQekdhQSnq6 0E7ZAdRbB107uxlmsC3TQXxmXAyAYqTT3PD3KMnNKeOAaUverDm36FmGy+CGsQRdfgh7 uu4Gqa/77YB+M97cIxsGThmvhPQ92+LnpdW34zxaaI/S/e+Aeu2sRE3iegNLYUYv+IJ5 0ZUg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 128si653770pgc.469.2019.03.28.03.37.46; Thu, 28 Mar 2019 03:38:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726508AbfC1Kfc (ORCPT + 99 others); Thu, 28 Mar 2019 06:35:32 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:42176 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725815AbfC1Kfb (ORCPT ); Thu, 28 Mar 2019 06:35:31 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3F29015AB; Thu, 28 Mar 2019 03:35:31 -0700 (PDT) Received: from [10.1.196.92] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3B8F73F59C; Thu, 28 Mar 2019 03:35:26 -0700 (PDT) Subject: Re: [RFC 0/7] cpuidle: Add poking mechanism to support non-IPI wakeup To: Leonard Crestez , "l.stach@pengutronix.de" , Abel Vesa , Jacky Bai Cc: dl-linux-imx , "linux-kernel@vger.kernel.org" , Aisheng Dong , "linux-pm@vger.kernel.org" , "lorenzo.pieralisi@arm.com" , Fabio Estevam , "mark.rutland@arm.com" , "rjw@rjwysocki.net" , "catalin.marinas@arm.com" , "will.deacon@arm.com" , "robh@kernel.org" , "shawnguo@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "sudeep.holla@arm.com" , Anson Huang , "kernel@pengutronix.de" References: <1553692845-20983-1-git-send-email-abel.vesa@nxp.com> <1553701479.2561.38.camel@pengutronix.de> <564216aa-1144-71de-e887-00c58f466bf5@arm.com> <1553702767.2561.40.camel@pengutronix.de> <85c91392-9cbf-a5fc-b037-3d58f2b0ac9c@arm.com> From: Marc Zyngier Openpgp: preference=signencrypt Autocrypt: addr=marc.zyngier@arm.com; prefer-encrypt=mutual; keydata= mQINBE6Jf0UBEADLCxpix34Ch3kQKA9SNlVQroj9aHAEzzl0+V8jrvT9a9GkK+FjBOIQz4KE g+3p+lqgJH4NfwPm9H5I5e3wa+Scz9wAqWLTT772Rqb6hf6kx0kKd0P2jGv79qXSmwru28vJ t9NNsmIhEYwS5eTfCbsZZDCnR31J6qxozsDHpCGLHlYym/VbC199Uq/pN5gH+5JHZyhyZiNW ozUCjMqC4eNW42nYVKZQfbj/k4W9xFfudFaFEhAf/Vb1r6F05eBP1uopuzNkAN7vqS8XcgQH qXI357YC4ToCbmqLue4HK9+2mtf7MTdHZYGZ939OfTlOGuxFW+bhtPQzsHiW7eNe0ew0+LaL 3wdNzT5abPBscqXWVGsZWCAzBmrZato+Pd2bSCDPLInZV0j+rjt7MWiSxEAEowue3IcZA++7 ifTDIscQdpeKT8hcL+9eHLgoSDH62SlubO/y8bB1hV8JjLW/jQpLnae0oz25h39ij4ijcp8N t5slf5DNRi1NLz5+iaaLg4gaM3ywVK2VEKdBTg+JTg3dfrb3DH7ctTQquyKun9IVY8AsxMc6 lxl4HxrpLX7HgF10685GG5fFla7R1RUnW5svgQhz6YVU33yJjk5lIIrrxKI/wLlhn066mtu1 DoD9TEAjwOmpa6ofV6rHeBPehUwMZEsLqlKfLsl0PpsJwov8TQARAQABtCNNYXJjIFp5bmdp ZXIgPG1hcmMuenluZ2llckBhcm0uY29tPokCOwQTAQIAJQIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AFAk6NvYYCGQEACgkQI9DQutE9ekObww/+NcUATWXOcnoPflpYG43GZ0XjQLng LQFjBZL+CJV5+1XMDfz4ATH37cR+8gMO1UwmWPv5tOMKLHhw6uLxGG4upPAm0qxjRA/SE3LC 22kBjWiSMrkQgv5FDcwdhAcj8A+gKgcXBeyXsGBXLjo5UQOGvPTQXcqNXB9A3ZZN9vS6QUYN TXFjnUnzCJd+PVI/4jORz9EUVw1q/+kZgmA8/GhfPH3xNetTGLyJCJcQ86acom2liLZZX4+1 6Hda2x3hxpoQo7pTu+XA2YC4XyUstNDYIsE4F4NVHGi88a3N8yWE+Z7cBI2HjGvpfNxZnmKX 6bws6RQ4LHDPhy0yzWFowJXGTqM/e79c1UeqOVxKGFF3VhJJu1nMlh+5hnW4glXOoy/WmDEM UMbl9KbJUfo+GgIQGMp8mwgW0vK4HrSmevlDeMcrLdfbbFbcZLNeFFBn6KqxFZaTd+LpylIH bOPN6fy1Dxf7UZscogYw5Pt0JscgpciuO3DAZo3eXz6ffj2NrWchnbj+SpPBiH4srfFmHY+Y LBemIIOmSqIsjoSRjNEZeEObkshDVG5NncJzbAQY+V3Q3yo9og/8ZiaulVWDbcpKyUpzt7pv cdnY3baDE8ate/cymFP5jGJK++QCeA6u6JzBp7HnKbngqWa6g8qDSjPXBPCLmmRWbc5j0lvA 6ilrF8m5Ag0ETol/RQEQAM/2pdLYCWmf3rtIiP8Wj5NwyjSL6/UrChXtoX9wlY8a4h3EX6E3 64snIJVMLbyr4bwdmPKULlny7T/R8dx/mCOWu/DztrVNQiXWOTKJnd/2iQblBT+W5W8ep/nS w3qUIckKwKdplQtzSKeE+PJ+GMS+DoNDDkcrVjUnsoCEr0aK3cO6g5hLGu8IBbC1CJYSpple VVb/sADnWF3SfUvJ/l4K8Uk4B4+X90KpA7U9MhvDTCy5mJGaTsFqDLpnqp/yqaT2P7kyMG2E w+eqtVIqwwweZA0S+tuqput5xdNAcsj2PugVx9tlw/LJo39nh8NrMxAhv5aQ+JJ2I8UTiHLX QvoC0Yc/jZX/JRB5r4x4IhK34Mv5TiH/gFfZbwxd287Y1jOaD9lhnke1SX5MXF7eCT3cgyB+ hgSu42w+2xYl3+rzIhQqxXhaP232t/b3ilJO00ZZ19d4KICGcakeiL6ZBtD8TrtkRiewI3v0 o8rUBWtjcDRgg3tWx/PcJvZnw1twbmRdaNvsvnlapD2Y9Js3woRLIjSAGOijwzFXSJyC2HU1 AAuR9uo4/QkeIrQVHIxP7TJZdJ9sGEWdeGPzzPlKLHwIX2HzfbdtPejPSXm5LJ026qdtJHgz BAb3NygZG6BH6EC1NPDQ6O53EXorXS1tsSAgp5ZDSFEBklpRVT3E0NrDABEBAAGJAh8EGAEC AAkFAk6Jf0UCGwwACgkQI9DQutE9ekMLBQ//U+Mt9DtFpzMCIHFPE9nNlsCm75j22lNiw6mX mx3cUA3pl+uRGQr/zQC5inQNtjFUmwGkHqrAw+SmG5gsgnM4pSdYvraWaCWOZCQCx1lpaCOl MotrNcwMJTJLQGc4BjJyOeSH59HQDitKfKMu/yjRhzT8CXhys6R0kYMrEN0tbe1cFOJkxSbV 0GgRTDF4PKyLT+RncoKxQe8lGxuk5614aRpBQa0LPafkirwqkUtxsPnarkPUEfkBlnIhAR8L kmneYLu0AvbWjfJCUH7qfpyS/FRrQCoBq9QIEcf2v1f0AIpA27f9KCEv5MZSHXGCdNcbjKw1 39YxYZhmXaHFKDSZIC29YhQJeXWlfDEDq6nIhvurZy3mSh2OMQgaIoFexPCsBBOclH8QUtMk a3jW/qYyrV+qUq9Wf3SKPrXf7B3xB332jFCETbyZQXqmowV+2b3rJFRWn5hK5B+xwvuxKyGq qDOGjof2dKl2zBIxbFgOclV7wqCVkhxSJi/QaOj2zBqSNPXga5DWtX3ekRnJLa1+ijXxmdjz hApihi08gwvP5G9fNGKQyRETePEtEAWt0b7dOqMzYBYGRVr7uS4uT6WP7fzOwAJC4lU7ZYWZ yVshCa0IvTtp1085RtT3qhh9mobkcZ+7cQOY+Tx2RGXS9WeOh2jZjdoWUv6CevXNQyOUXMM= Organization: ARM Ltd Message-ID: Date: Thu, 28 Mar 2019 10:35:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27/03/2019 18:40, Leonard Crestez wrote: > On Wed, 2019-03-27 at 17:45 +0000, Marc Zyngier wrote: >> On 27/03/2019 16:06, 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). >>> >>> Anything that isn't visible to the GPC and requires the GIC >>> wake_request signal to behave as specified is broken by this erratum. >> >> I really wonder how a timer interrupt (a PPI, hence not routed through >> the GPC) can wake up the CPU in this case. It really feels like >> something like "program CNTV_CVAL_EL0 to expire at some later point; >> WFI" could result in the CPU going to a deep sleep state, and not >> wake-up at all. > > This is already a common issue for cpuidle implementions handled by the > "local-timer-stop" property. imx has other timer blocks in the SOC, > they generate SPIs which are connected to GPC. > >> This would indicate that not only cpuidle is broken with this, but >> absolutely every interrupt that is not routed through the GPC. > > Yes, cpuidle is broken for irqs not routed through GPC. However: > > * All SPIs are connected to GPC in a 1:1 mapping > * This series deals with SGIs > * The timer PPIs are not required; covered by local-timer-stop > * LPIs are currently unused (I understand imx-pci uses SPI by default > from Lucas) > > Anything missing? > > My understanding is that this wake request feature via GIC is new in v3 > and this is maybe why HW team missed it during integration. Older > imx6/7 has GICv2 and has deep idle states which always rely on GPC to > wakeup so the approach can work. Certainly the approach can work. The question is whether we want to support this in a mainline kernel, spreading random hooks in the generic code and adding a firmware interface on top of that. By all accounts, this HW is broken. You can indeed impose limitations (dumb down PCI, mandate the use of a broadcast timer), or you can just flag cpuidle as unsupported on this HW. My vote is on the latter. Thanks, M. -- Jazz is not dead. It just smells funny...