Received: by 10.223.176.5 with SMTP id f5csp1189424wra; Tue, 6 Feb 2018 14:27:51 -0800 (PST) X-Google-Smtp-Source: AH8x224ck0fyTmX3gj/SCldQxEzldOA+U1x7WiiZeRz0HXh3Be+wx+pUBN3vh61nD0gKtiBJ3R+x X-Received: by 2002:a17:902:481:: with SMTP id e1-v6mr3801803ple.228.1517956071258; Tue, 06 Feb 2018 14:27:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517956071; cv=none; d=google.com; s=arc-20160816; b=PCRVQ7hb06ZuN6IvKQceuAdiUYTQgcimo1Ndd1vzZ1lUuU4/2n0qZuGymmV1K5tRMy eojyRt+sTWnI7b1n+o3yQPgokfgkrMUcTIeWLn+hBzOax6Dma6OHeTdzHcdRlAsb/xIO SFGoHaQmuVZrly6a6Bc+8QkCDxNZr+xw2EXucRf1p8vZvkw+Xq3zYfq7Zckdy/qILybF NDitAX2YrYCaKNX4C430Fm5iqD5Wu2FxetRShZaqDM7JXfmazmAOJiKXOKt7j0BbNuM7 8gu/dauNA0cCloyO2poVoDN5PWViECeRGyXjaIWpr+sNqlqx0Gj9HFiwyWqVZgblLSlU nsUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=JyEJdYxw+4IQtickYlDyTs3skPwQX1vlxIuWEpSD1HY=; b=dNG5N+485/CTp4BXEena7USyEXic3B9EYywEsCUxFqrQWzwpkdRbLqOc5zicxLgYoG /fAvWvd4zwAb0ygLsaoGSW3ftPdNA5PbG+mQwBR0u4OoK4nDKl4Kv+DkESRaY0OvpYmh uGR78Ic+qLbs+zRlNyxSfmnLz2yywa/rTjZw5vtwIK2+VRck5JULvYTNCbp8qG/p5Dni JFHeVEVlkOqCA8QmOUWKGjp9O75uXnswNGr1eQynhvRQzTaF4Nf6LopzA6u9Pv4XYog0 Y+lPyS5HKrkS+rFEPkmBxiAAPARl0wBKxPAqj9MPslB9tlanoZ19UtfL63EUZHbelR6C WtuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=mcR1MwaH; dkim=fail header.i=@chromium.org header.s=google header.b=HF8i1oP2; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z62si28262pff.332.2018.02.06.14.27.36; Tue, 06 Feb 2018 14:27:51 -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; dkim=fail header.i=@google.com header.s=20161025 header.b=mcR1MwaH; dkim=fail header.i=@chromium.org header.s=google header.b=HF8i1oP2; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753637AbeBFWZb (ORCPT + 99 others); Tue, 6 Feb 2018 17:25:31 -0500 Received: from mail-wr0-f194.google.com ([209.85.128.194]:34287 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753428AbeBFWZ3 (ORCPT ); Tue, 6 Feb 2018 17:25:29 -0500 Received: by mail-wr0-f194.google.com with SMTP id z6so3630258wrb.1 for ; Tue, 06 Feb 2018 14:25:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JyEJdYxw+4IQtickYlDyTs3skPwQX1vlxIuWEpSD1HY=; b=mcR1MwaH8Q6Lms4qV6fVVRHvtZpJZZ6YEQL9jUpO454P+uYkYuZ9hHLe32ezFiwcuI 7LbBPxG7CH/JMCWMKpbzrMOGnmVLjaeFbv+xwBZU1q+gKmNDNK69Wh1i9tfvObXG2Qqm rLpL8J/Ujs2mLvibichM1St2U0QSHlS+XRbZCbSnC7J67yI494w95Aj1hY1Bbq/rugLC f7UMQRLj1MiTT1tYGODup0rXml4DTpu8t9yMkH4iB06+rbH7v4jAMvXavcyvbJKyFRHS SDIumMOmomPMWDKevGpF7iI0s8up1FedEyuxLLVqDoy5aZszx6BZp0DFwTm6m/20TnT2 cuuQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JyEJdYxw+4IQtickYlDyTs3skPwQX1vlxIuWEpSD1HY=; b=HF8i1oP2eJwt0Ghn0fw6Os2VGTl9406bbGe4batAOoVylttQLB4btUoMeoTnyXeQLH 0jW4M7L/ZiHUD+SKH94NqxCbx9DbBa118UR7B2YvFUsbSIL1OKrFuPZW6u2B5zwEiN3U mpekdRqLLbXNM30iEWfgX3XIhcsX7hRzgoaHE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=JyEJdYxw+4IQtickYlDyTs3skPwQX1vlxIuWEpSD1HY=; b=auCNzsXoZ6ik54W1fzCFx1zMiCpd0hDCsgcdcxcWDnCZlnB9rSDPmQOsFgiTevIAcx Z3LaQ8bFXttW4UfJjaqG7KKHjdZhwAGyw7PafIkI/TKManLQlYn7QCSaf5RI8NzQkQ1t n/MwT5SuwZtpScAIXniptTM1l38e+UgURaRQQ/JK5iEpBZUsago6P45EA732dVAxAU/m 77WE0R22eF9Ttu18vgWNnUCsGYfNQR1vqEMGA3DSC65JsXMtCjBv7rEAT9UmsCI7OByn vyGJw8OtACno2r4YIFZInqYSctd64X9jsQ/gm1+N1P8RnOZC8E3OzX4knePeOLLQCAL4 2buQ== X-Gm-Message-State: APf1xPByVe+YphS61L6atezOEyCXZEl7PN08x/uESaUPWOmZsUTcIY+p TER0C09TV9SbUknIppiK+xr1UVLQtV5El93uf7YT2Q== X-Received: by 10.223.176.172 with SMTP id i41mr3572009wra.47.1517955927501; Tue, 06 Feb 2018 14:25:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.124.6 with HTTP; Tue, 6 Feb 2018 14:25:26 -0800 (PST) In-Reply-To: References: <20180203012450.18378-1-dbasehore@chromium.org> <20180203012450.18378-3-dbasehore@chromium.org> From: "dbasehore ." Date: Tue, 6 Feb 2018 14:25:26 -0800 X-Google-Sender-Auth: TZS7QWR6qdkze1TliT7ZSovAtqs Message-ID: Subject: Re: [PATCH v4 2/5] irqchip/gic-v3-its: add ability to save/restore ITS state To: Marc Zyngier 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 6, 2018 at 8:23 AM, Marc Zyngier wrote: > 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. Huh, I missed that. It at least makes this a lot simpler. That also means that the current code has a potential bug if suspend is preempted. > >> >>> >>>> + /* 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. Fair enough. I'll disable the ITS at the start of restore_enable. > > Thanks, > > M. > -- > Jazz is not dead. It just smells funny...