Received: by 10.223.176.5 with SMTP id f5csp852948wra; Tue, 6 Feb 2018 08:26:02 -0800 (PST) X-Google-Smtp-Source: AH8x2266RLwR9J3Lf2PDkhB5n3Jp7eweHoPvt8QmVweO5U9l2xGMndwUIcV6bJ2g8SqNVaEbmNmC X-Received: by 2002:a17:902:aa8e:: with SMTP id d14-v6mr2862139plr.94.1517934362330; Tue, 06 Feb 2018 08:26:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517934362; cv=none; d=google.com; s=arc-20160816; b=VkvcWXz94UdzhyPFmtMrU51uMrUrLuUGiFW7pSzoztMTBc3qirHzsMsKM1Uk1AlcAj jUedHExsi/V4eiJMWzto0HQbS8DAM6vFxZIq9MAK6LZEcRElI5Je8Lt1l21lVwwgaj0g UjaNUm5vQxvBO8TggqAe2uXl3Ttx2lGkFw1kMNRKZlnhJKTmuM2ZzD9Vqg2s9faU+Q5a fzhcJmG35MYcrfPpp/qNbr6QKxQUI/x+c6g4wcqYFB7V9nVInW64zMa9TmOyjUxhTml9 UDaNiI04VunV7LWW+7bzUAbE+RpxQM3UkwwtnjSqYc7NQnL3QTyjZcCnbK4ENal1T/3f UY/w== 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=PSZHpXtcp3ladRxOz03p/76ZrwyLgE1A3XS++5XhZ7A=; b=cvBy8g1WPTTAhIdCC059Da4b1fdpDxow5v/wi4KtQplewJY3q8IpLUqy9cmkxx6rkd xQflf533Mua3gS34cL+e1Yqt9PnVaoOp+d0rOJPZcpW8/8SfJiZt5VdkURlK5P+WROpN 5dP9PYT9grIiHIoF7Fi0H6qSLdtDSv1ERnk5fDKE84V/O1toNZVjTCWSyvTr82sTkVDV ROZVTe8SNvWTMozf+f+XehW8BzxkPnVds/+zP5I2r5gJ+0Vh/1O8I0DpzRPKuZgqWKn4 vGIfXMC8birQuJQqAe+13qM0rfhHatnskbnb8beu7CZRPHBXiWYXiYQ5OJvvEdvoz0tG 4BSQ== 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 89-v6si1831557plc.397.2018.02.06.08.25.47; Tue, 06 Feb 2018 08:26:02 -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 S1752541AbeBFQXO (ORCPT + 99 others); Tue, 6 Feb 2018 11:23:14 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:39470 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752236AbeBFQXH (ORCPT ); Tue, 6 Feb 2018 11:23:07 -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 272261435; Tue, 6 Feb 2018 08:23:07 -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 4EDF13F53D; Tue, 6 Feb 2018 08:23:05 -0800 (PST) Subject: Re: [PATCH v4 2/5] irqchip/gic-v3-its: add ability to save/restore ITS state To: "dbasehore ." Cc: linux-kernel , Soby Mathew , Sudeep Holla , devicetree@vger.kernel.org, robh+dt@kernel.org, Mark Rutland , Linux-pm mailing list , "Wysocki, Rafael J" , Thomas Gleixner , Brian Norris References: <20180203012450.18378-1-dbasehore@chromium.org> <20180203012450.18378-3-dbasehore@chromium.org> From: Marc Zyngier Organization: ARM Ltd Message-ID: Date: Tue, 6 Feb 2018 16:23:03 +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: 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 On 05/02/18 21:33, dbasehore . wrote: > On Mon, Feb 5, 2018 at 7:56 AM, Marc Zyngier wrote: >> On 03/02/18 01:24, 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 >>> --- >>> drivers/irqchip/irq-gic-v3-its.c | 101 +++++++++++++++++++++++++++++++++++++++ >>> 1 file changed, 101 insertions(+) >>> >>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c >>> index 06f025fd5726..e13515cdb68f 100644 >>> --- a/drivers/irqchip/irq-gic-v3-its.c >>> +++ b/drivers/irqchip/irq-gic-v3-its.c >>> @@ -33,6 +33,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> >>> #include >>> #include >>> @@ -46,6 +47,7 @@ >>> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0) >>> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1) >>> #define ITS_FLAGS_WORKAROUND_CAVIUM_23144 (1ULL << 2) >>> +#define ITS_FLAGS_SAVE_SUSPEND_STATE (1ULL << 3) >>> >>> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0) >>> >>> @@ -83,6 +85,15 @@ struct its_baser { >>> u32 psz; >>> }; >>> >>> +/* >>> + * Saved ITS state - this is where saved state for the ITS is stored >>> + * when it's disabled during system suspend. >>> + */ >>> +struct its_ctx { >>> + u64 cbaser; >>> + u32 ctlr; >>> +}; >> >> Nit: This is pretty small for the ITS context. Given that its_node is >> the context, you can safely expand this in the its_node structure. > > Sounds reasonable. I think I just have it this way because I used to > have more in here. > >> >>> + >>> struct its_device; >>> >>> /* >>> @@ -101,6 +112,7 @@ struct its_node { >>> struct its_collection *collections; >>> struct fwnode_handle *fwnode_handle; >>> u64 (*get_msi_base)(struct its_device *its_dev); >>> + struct its_ctx its_ctx; >>> struct list_head its_device_list; >>> u64 flags; >>> unsigned long list_nr; >>> @@ -3042,6 +3054,90 @@ static void its_enable_quirks(struct its_node *its) >>> gic_enable_quirks(iidr, its_quirks, its); >>> } >>> >>> +static int its_save_disable(void) >>> +{ >>> + struct its_node *its; >>> + int err = 0; >>> + >>> + spin_lock(&its_lock); >>> + list_for_each_entry(its, &its_nodes, entry) { >>> + struct its_ctx *ctx; >>> + void __iomem *base; >>> + >>> + if (!(its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE)) >>> + continue; >>> + >>> + ctx = &its->its_ctx; >>> + base = its->base; >>> + ctx->ctlr = readl_relaxed(base + GITS_CTLR); >>> + err = its_force_quiescent(base); >>> + if (err) { >>> + pr_err("ITS failed to quiesce\n"); >>> + writel_relaxed(ctx->ctlr, base + GITS_CTLR); >>> + goto err; >>> + } >>> + >>> + ctx->cbaser = gits_read_cbaser(base + GITS_CBASER); >>> + } >>> + >>> +err: >>> + if (err) { >>> + list_for_each_entry_continue_reverse(its, &its_nodes, entry) { >>> + if (its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE) { >>> + struct its_ctx *ctx = &its->its_ctx; >>> + void __iomem *base = its->base; >>> + >>> + writel_relaxed(ctx->ctlr, base + GITS_CTLR); >>> + } >>> + } >>> + } >>> + >>> + spin_unlock(&its_lock); >>> + >>> + return err; >>> +} >>> + >>> +static void its_restore_enable(void) >>> +{ >>> + struct its_node *its; >>> + >>> + spin_lock(&its_lock); >>> + list_for_each_entry(its, &its_nodes, entry) { >>> + if (its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE) { >>> + struct its_ctx *ctx = &its->its_ctx; >>> + void __iomem *base = its->base; >>> + /* >>> + * Only the lower 32 bits matter here since the upper 32 >>> + * don't include any of the offset. >>> + */ >>> + u32 creader = readl_relaxed(base + GITS_CREADR); >> >> Accessor matching gits_write_cwriter and co? >> >>> + int i; >>> + >>> + /* >>> + * Reset the write location to where the ITS is >>> + * currently at. >>> + */ >>> + gits_write_cbaser(ctx->cbaser, base + GITS_CBASER); >>> + gits_write_cwriter(creader, base + GITS_CWRITER); >>> + its->cmd_write = &its->cmd_base[ >>> + creader / sizeof(struct its_cmd_block)]; >> >> Nit: please do not split lines like this, this is unreadable. We both >> have screens that are wide enough for this to fit on a single line. >> >> More importantly: Why isn't it sufficient to reset both CREADR and >> CWRITER to zero? Is there any case where you can suspend whilst having >> anything in flight? > > CREADR is RO and we need to handle the non-zero case. I was planning > on getting rid of the write to CWRITER since it shouldn't be needed. > Either CREADR and CWRITER have the prior values, or both are reset to > 0. You're writing GITS_CBASER, which has for consequence: "When this register is successfully written, the value of GITS_CREADR is set to zero.". Ergo, none of that is necessary and you *must* set CWRITER to 0. > >> >>> + /* Restore GITS_BASER from the value cache. */ >>> + for (i = 0; i < GITS_BASER_NR_REGS; i++) { >>> + struct its_baser *baser = &its->tables[i]; >>> + >>> + its_write_baser(its, baser, baser->val); >> >> You may want to first test that this BASER register is actually >> requiring something before writing to it. Yes, this is normally safe. >> But HW is also normally broken. >> >>> + } >>> + writel_relaxed(ctx->ctlr, base + GITS_CTLR); >> >> Before restoring all of this, shouldn't you first test that the ITS is >> actually in a disabled state? > > The save_disable code put it in a disabled state. The reset state is> also disabled. I don't expect PSCI to change the GITS_CTLR register at > all. Are you expecting something on the other side of the PSCI layer > to poke this register? We'd probably want to force disable at the > start of restore_enable if so. I expect firmware to do its worse, because even if mainline ATF is close to perfection, it will be hacked to death by platform people who usually do not have a clue (that's definitely my experience). So I expect this code to be written defensively. Thanks, M. -- Jazz is not dead. It just smells funny...