Received: by 10.223.185.116 with SMTP id b49csp7383706wrg; Thu, 1 Mar 2018 04:48:43 -0800 (PST) X-Google-Smtp-Source: AG47ELsFvPlsuUuX3MN6A+L7tbvMqtuhjismRr04t+HRG/YebIT2lNhts62WTkOQpAMdOxf6NSSN X-Received: by 10.98.245.18 with SMTP id n18mr1802996pfh.25.1519908523034; Thu, 01 Mar 2018 04:48:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519908522; cv=none; d=google.com; s=arc-20160816; b=imuNszFsoPmfu83jSlYNvyJgI3Y2VD+Ws4mLSzA5+wPqbDOF4XQLn0SQszmvWIy7LV WM6bHpmnd1oeeii7TNaW9VJR1ZCPtRrXKCFT9KHIod6m/9XZNRCdyDEnh5uOLGzyROuy +J3AED8MrJLx4iUw1IGODm8AntARh+0UyBXymuV4EhpubwOZaIlvOH6vdcXCWhvdtaC6 LoNtNDa2unKAqzrIPPLxZuzabPBSN4o9sUr/oakiROi/mg4f7ZDRDOF7cbugxDkQtOGu iL093OZWe6B4WnEyddUpnfDPy3z87K/qazqX8sOquPK3WVs+RAO5FCioF9eSwTT6qoRg BeXQ== 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:from:references:cc:to:subject :arc-authentication-results; bh=OVTkhAHHAP4xRcE1v2i93z3cyri7FzWkuYCZrzsvKxw=; b=okV13HA1Sdcet0jJQM3Xyy7yulUEny7BJ2Ez25d3zR5WSBh0GiNis/HdNrc3QrfOmU mLs+xCwhsiKoBhMuMwwEhH/q82bMNHPXljQmMXhG1Pl8xDTdnFzPXIurJSvSEK95wC9v K5y2xTFNx3lXRSVsvZcplN7+yPNkz/L+TiiiqHSIIbQj9NZ0HLIJMqyhJV/dEbfWGiPx Z6Frl7AaFGIK3hMYzuDZJVk0LspymyDZZuuQuRiiBHctq1gW30uCgYS9HPl5DcPOXqOk q/y4cyvA3v0E4KhiqSWipHwj/Noj0cGIGkNRGFBYd9UECNuX3eCGYgAUCXIPJGRSi8lm Tu7w== 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 v65si2907358pfk.338.2018.03.01.04.48.27; Thu, 01 Mar 2018 04:48:42 -0800 (PST) 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 S1030407AbeCAMaD (ORCPT + 99 others); Thu, 1 Mar 2018 07:30:03 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:37386 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030328AbeCAMaB (ORCPT ); Thu, 1 Mar 2018 07:30:01 -0500 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 4E0AB80D; Thu, 1 Mar 2018 04:30:01 -0800 (PST) Received: from [10.1.207.62] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 712EB3F246; Thu, 1 Mar 2018 04:29:59 -0800 (PST) Subject: Re: [PATCH v7 1/3] irqchip/gic-v3-its: add ability to save/restore ITS state To: Mark Rutland , Derek Basehore Cc: linux-kernel@vger.kernel.org, Soby.Mathew@arm.com, sudeep.holla@arm.com, devicetree@vger.kernel.org, robh+dt@kernel.org, linux-pm@vger.kernel.org, rafael.j.wysocki@intel.com, tglx@linutronix.de, briannorris@chromium.org References: <20180301054820.42847-1-dbasehore@chromium.org> <20180301054820.42847-2-dbasehore@chromium.org> <20180301114144.nmwu4qtslvj7ogj5@lakrids.cambridge.arm.com> From: Marc Zyngier Organization: ARM Ltd Message-ID: <0a74f87a-027a-df7d-ca2d-fc164ec9cdf7@arm.com> Date: Thu, 1 Mar 2018 12:29:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180301114144.nmwu4qtslvj7ogj5@lakrids.cambridge.arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark, On 01/03/18 11:41, Mark Rutland wrote: > On Wed, Feb 28, 2018 at 09:48:18PM -0800, Derek Basehore wrote: >> Some platforms power off GIC logic in suspend, so we need to >> save/restore state. The distributor and redistributor registers need >> to be handled in platform code due to access permissions on those >> registers, but the ITS registers can be restored in the kernel. >> >> Signed-off-by: Derek Basehore > > How much state do we have to save/restore? > > Given we can apparently read all this state, couldn't we *always* save > the state, then upon resume detect if the state has been lost, restoring > it if so? > > That way, we don't need a property in FW tables for DT or ACPI. That's a good point. I guess that we could just compare the saved GITS_CTLR register and restore the full state only if the ITS comes back as disabled. I'm just a bit worried that it makes it an implicit convention between kernel an FW, which could change in funny ways. Importantly, the PSCI spec says states FW should restore *the whole state*. Obviously, it cannot to that on HW that doesn't allow you to read out the state, hence the DT flag that outlines the departure from the expected behaviour. I'm happy to go either way, but then I have the feeling that we should go back to quirking it on the actual implementation (GIC500 in this case) if we're to from the property. > > [...] > >> @@ -3261,6 +3363,9 @@ static int __init its_probe_one(struct resource *res, >> ctlr |= GITS_CTLR_ImDe; >> writel_relaxed(ctlr, its->base + GITS_CTLR); >> >> + if (fwnode_property_present(handle, "reset-on-suspend")) >> + its->flags |= ITS_FLAGS_SAVE_SUSPEND_STATE; > > Does this allow this property on an ACPI system? > > If we need this on ACPI, we need a spec update to handle this properly, > and shouldn't use device properties like this. Well spotted. I guess that dropping the property would fix that altogether, assuming we feel that the above is safe enough. Thoughts? M. -- Jazz is not dead. It just smells funny...