Received: by 10.223.176.5 with SMTP id f5csp77416wra; Mon, 5 Feb 2018 17:03:40 -0800 (PST) X-Google-Smtp-Source: AH8x226clxeWWzFI1euZX+nbr8aINhoENI9FAv60vteut09vUA+spE3jgW4/nJZfKmrGp4FiQFft X-Received: by 10.98.110.202 with SMTP id j193mr632145pfc.19.1517879020275; Mon, 05 Feb 2018 17:03:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517879020; cv=none; d=google.com; s=arc-20160816; b=sMnYf45pTbHX4y5IpnmHKF1KDfccyRwbtoBhmHoTKkCiFdlUdSFEKvtcvaypKZrIWU HJAD5q9s5j+H78TS4LS5SRQprdMICS0usfnFLhFAvRRMwztI4eG0jKs/PM9CYbPbfJOh OxWlxlU+0aIhdp3J6/RmTpimj6GzltU2i8P2j7TYsRpN5RJ1kYCZoor2KwNniNpdQIsn S3JXVZ9+9tnU8er0e9Hrr+zs5q1dPH7R5lJivKPSG0tL0w3UxzbSafvH6fYfYLUuaC3z ROSL4qTlutNr1Gx2I8hkFoi3e3ISKRYJXkR9/A4ks5T6KhEpAlRQjycEM4BbX21LpdYp 8QWA== 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:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:dkim-signature:arc-authentication-results; bh=N8AioY2MCFrTDEG8s4Ky3PVor4V/DGhWbpK6HY9mTTk=; b=IdygvWTFcZadqqKAs4DVi34YZANf+HGTMAwX/P+2G7JqmLAq7FqXhw23uaIvmEJQLM kE4UyDCi57bHGGA5L6I0xPvsa3FfvpbojYCHqVpb5PuhML7fwjZ6PxGoSOoH5z3mtU8i eeJr5qqeNAYdngv3XYE6sWZ9/InLJMwLs1Gm1BojpuVRCOOwg1sRiGDvu3isYLkfZTlQ zpCMDdgSs5zjzkai876IjldQhwC9ZTrN8JPkVZTGcfse7QX33nG2b0mvFMLkiJPgTYVK yI13BITA18znTBDesjrzEL1xwsWwuCrBYCO8/C7P74qSduDR759YByor45oT+xH3ofwU WGLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=IXUHIE/O; dkim=fail header.i=@chromium.org header.s=google header.b=MPeZI1Dp; 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 u87si7221079pfj.41.2018.02.05.17.03.25; Mon, 05 Feb 2018 17:03:40 -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=IXUHIE/O; dkim=fail header.i=@chromium.org header.s=google header.b=MPeZI1Dp; 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 S1751834AbeBFBBZ (ORCPT + 99 others); Mon, 5 Feb 2018 20:01:25 -0500 Received: from mail-wr0-f196.google.com ([209.85.128.196]:37542 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751914AbeBFBBS (ORCPT ); Mon, 5 Feb 2018 20:01:18 -0500 Received: by mail-wr0-f196.google.com with SMTP id a43so206722wrc.4 for ; Mon, 05 Feb 2018 17:01:17 -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:content-transfer-encoding; bh=N8AioY2MCFrTDEG8s4Ky3PVor4V/DGhWbpK6HY9mTTk=; b=IXUHIE/O+TmSSEo7RwLkr8eZemvCcMCnX0fe7RP92xPBTI94IusXtz2keXdulG3h5d HIxfCnQJAQtl+sYDZiyHjtG7VC9kWRP01ANmMtfKKRuHs63r48CK/xoEd2NOFrdiobWY kWzD3Q/So8gMe6m0AniOG4fBsMlsuwCjuQLzGvugGzvVZlbGKUtqJGOfAAs4Re/raEfN RxlTZbKLS0eKmsrWcOTK3KmvUtrm6ZiOiu92Ox21U0H7vWhDBYW8S6DF5fhwR1z0jz8G reETuOLTLWNA13NL5ZcPj5cKDoyim2ZNtqYcnvSfjeRvMdYIDU8/8aV36xTdLCUhmqAa 2WHQ== 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:content-transfer-encoding; bh=N8AioY2MCFrTDEG8s4Ky3PVor4V/DGhWbpK6HY9mTTk=; b=MPeZI1DpUB2whE+VjzuArBYtaaX3/eadB0Al7c2FNBGgdu/aDQTTLkWZmzSPD4TAO4 y3sspn9/WjCmV8mPYbKJZu0yjlhPSEVxZaHMjF64FrQjFzb91tX2+HmgP7qP5y3N4jL/ 6P7BpiDyF/9fo8sd579EbMF6wIkGxC0elzcJQ= 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:content-transfer-encoding; bh=N8AioY2MCFrTDEG8s4Ky3PVor4V/DGhWbpK6HY9mTTk=; b=G5pEtUhn4OCVXVMPEPMAt5lwP9gesQRpAEQVbFzcJgOrWvsPv0CR+vuSfy64NsRUP7 ovFD9QB3tcp0kEuanOaUGGnQcwE1rR79lOJgID7S3UI1Ktvns1PTta+w3/CiIMLMmLWM +Pwndng8Dvmcpbo1Ntwn/d17FBzDz0QngK7lhzK0jcenXOMfHtZ9oXwNvWrJD3jukEUo 7OdGbwcYXVwkUWBhsq5kDFMu/p/kKF1zSWEnMDoBDcEXXp5uJBrImjdbSAIuw0kJU9ft 3gbWSsBJ5DOjn0pT2vTcf4y5uuaQD3BX7J+gH22HLJXGtBtjDwbGi65bMIdcV8ndymq9 piow== X-Gm-Message-State: APf1xPADdhErJrPvTZ9oVNSrw7BU4YCaOvv++4bWCSFHq8j19Poa1fuD Ec3ugLFRvdLTJT+04XYpHUUWU3GD0Yjjpo2dGoT9VDvWeHo= X-Received: by 10.223.157.135 with SMTP id p7mr567496wre.34.1517878876681; Mon, 05 Feb 2018 17:01:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.124.6 with HTTP; Mon, 5 Feb 2018 17:01:15 -0800 (PST) In-Reply-To: References: <20180203012450.18378-1-dbasehore@chromium.org> <20180203012450.18378-3-dbasehore@chromium.org> From: "dbasehore ." Date: Mon, 5 Feb 2018 17:01:15 -0800 X-Google-Sender-Auth: jvcM4eZ4-BSG0ruYLSdsB2gAp8M 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" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 5, 2018 at 4:33 PM, 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. >> >>> + >>> 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_de= v); >>> + 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 *i= ts) >>> gic_enable_quirks(iidr, its_quirks, its); >>> } >>> >>> +static int its_save_disable(void) >>> +{ >>> + struct its_node *its; >>> + int err =3D 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 =3D &its->its_ctx; >>> + base =3D its->base; >>> + ctx->ctlr =3D readl_relaxed(base + GITS_CTLR); >>> + err =3D its_force_quiescent(base); >>> + if (err) { >>> + pr_err("ITS failed to quiesce\n"); >>> + writel_relaxed(ctx->ctlr, base + GITS_CTLR); >>> + goto err; >>> + } >>> + >>> + ctx->cbaser =3D gits_read_cbaser(base + GITS_CBASER); >>> + } >>> + >>> +err: >>> + if (err) { >>> + list_for_each_entry_continue_reverse(its, &its_nodes, ent= ry) { >>> + if (its->flags & ITS_FLAGS_SAVE_SUSPEND_STATE) { >>> + struct its_ctx *ctx =3D &its->its_ctx; >>> + void __iomem *base =3D its->base; >>> + >>> + writel_relaxed(ctx->ctlr, base + GITS_CTL= R); >>> + } >>> + } >>> + } >>> + >>> + 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 =3D &its->its_ctx; >>> + void __iomem *base =3D its->base; >>> + /* >>> + * Only the lower 32 bits matter here since the u= pper 32 >>> + * don't include any of the offset. >>> + */ >>> + u32 creader =3D 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 =3D &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? >> >>> + /* Restore GITS_BASER from the value cache. */ >>> + for (i =3D 0; i < GITS_BASER_NR_REGS; i++) { >>> + struct its_baser *baser =3D &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. >> > > Anything specific to test? I see that I can check if the BASER > register has the valid bit set and also that the type is not none. > Okay, I found this snippet in the GICv3 Specification: No memory is allocated for the translation table. The ITS discards any writes to the interrupt translation page when either: =E2=80=A2 GITS_BASER.Type specifies any valid table entry type other tha= n interrupt collections, that is, any value other than 100. =E2=80=A2 GITS_BASER.Type specifies an interrupt collection and GITS_TYPER.HCC =3D=3D 0. I'll turn this into a test in code and only write the BASER if that passes. >>> + } >>> + 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? >> >>> + } >>> + } >>> + spin_unlock(&its_lock); >>> +} >>> + >>> +static struct syscore_ops its_syscore_ops =3D { >>> + .suspend =3D its_save_disable, >>> + .resume =3D its_restore_enable, >>> +}; >>> + >>> static int its_init_domain(struct fwnode_handle *handle, struct its_no= de *its) >>> { >>> struct irq_domain *inner_domain; >>> @@ -3261,6 +3357,9 @@ static int __init its_probe_one(struct resource *= res, >>> ctlr |=3D GITS_CTLR_ImDe; >>> writel_relaxed(ctlr, its->base + GITS_CTLR); >>> >>> + if (fwnode_property_present(handle, "reset-on-suspend")) >>> + its->flags |=3D ITS_FLAGS_SAVE_SUSPEND_STATE; >>> + >>> err =3D its_init_domain(handle, its); >>> if (err) >>> goto out_free_tables; >>> @@ -3515,5 +3614,7 @@ int __init its_init(struct fwnode_handle *handle,= struct rdists *rdists, >>> } >>> } >>> >>> + register_syscore_ops(&its_syscore_ops); >>> + >>> return 0; >>> } >>> >> >> Thanks, >> >> M. >> -- >> Jazz is not dead. It just smells funny...