Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp914781imm; Thu, 31 May 2018 11:39:05 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJ3Bm1jonrwq/azuJjAOhvCDHjRrTzozgUwryLjSDY4sYbnRTW6/dfroPW+HBNOPv6gNdc6 X-Received: by 2002:a17:902:8308:: with SMTP id bd8-v6mr8087179plb.195.1527791945319; Thu, 31 May 2018 11:39:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527791945; cv=none; d=google.com; s=arc-20160816; b=OHTBg2GZSq29YPoG9+f3OvAVOQ7sA/BVPq0NethotQccNZ7LE2onftHKaP3oOFqdBP xBFQ6xWPv0WVveOVtk7SJqMm3FFZQS92QMyrAozWr1ScqkJVYmDEwMqOKApGb/NAbNdt fWBipX5RDvb/kdm6uteD1lpjpy+kubj1vw7vuod/hVeT7pHiMda9iitXst0T80kzBQiz /qGDKJIhC1cc+DXLn4Q7BcMTfPdtuEhOpK1bW7yTa58QRA7y4yNxj46ncZzmRnzol9oV ZH8YgHPP9RtlLYKPtq7KLMMUkL1/0oCbXzcGhx6Fx+s6bwr6uCzkZYi9Rw7PqzqGR7yV vemw== 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 :arc-authentication-results; bh=qghEdPGwSYrXmYJEgMrEVGLJUfs6jFg9AOqIo0+2jk0=; b=vPIJB/pO8JGoVAswNuvQT6QX8sn2fE7HNi6OfgkNdJPWos6sOMPUh+wHhoxyz3vqOe wgmNg/aJgux3H2tSm2MFFKkq9+Q4kPT+EA5Z+XbfijnB384c18re/XRQC35lzE1ho1lN HrfmJoIC+fJCy+s2qgev54oJeMsPmkFl9T/UGboQM66kc8jBOI1XtoU76K3tS3P46dI4 IDwm25Ibqp/AI1yCJLWnDO0NPfT5Z9ly7maRy+rUGDc9jDG+rIh7v+hzVNRI4FUPW4Wl y7vOQmO1QpnpmZqMUuM5aM+4IfBRR+ugLhR2IXT3EChaAqt8ntPSPIpb+KH/Dd0A5E+S zodQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lvtzQpEG; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r11-v6si15748903pfd.193.2018.05.31.11.38.50; Thu, 31 May 2018 11:39:05 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=lvtzQpEG; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755958AbeEaSiY (ORCPT + 99 others); Thu, 31 May 2018 14:38:24 -0400 Received: from mail-qk0-f193.google.com ([209.85.220.193]:35129 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755879AbeEaSiV (ORCPT ); Thu, 31 May 2018 14:38:21 -0400 Received: by mail-qk0-f193.google.com with SMTP id d130-v6so12563810qkc.2; Thu, 31 May 2018 11:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qghEdPGwSYrXmYJEgMrEVGLJUfs6jFg9AOqIo0+2jk0=; b=lvtzQpEG7EWQXHSIvtuBXiBJcLrgrxxWpxrYvVPOvOnHcqK834cVjNhjeJkuALiljU Hlj2QncUwutbre2uzDB9KFxh+zoCm/unR45Y+DIoJxXyDkr/mZ2G+7rT4No4l+WLlGt9 XgM1IsDj4Hpvsm5gYfhxmWZOtyCAp2DQFEvIuPc/FV/MOg1dKSEcR2NICkxqelr/ues4 KvPE6vwbEoth80z2/BZU8sO7XcLZebGLyj/cpBKHgnxxmASAwP/qdjarnMX8ygDZ34c9 7O3/X4XlEhP60EHga9DumoAfJR9gyEbSAGzrkMH55Cadr4t+C7JfjGMwmd1PTxqy+zlU KL4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qghEdPGwSYrXmYJEgMrEVGLJUfs6jFg9AOqIo0+2jk0=; b=MS9YXw/wlQeyk8upynp0fDcMwxNcENjHQgGDS0c9jrNU/9RR58Vq0bVoU36OCLELCe tJK+AOogSd+Zx1Le+TT1PcdcevwiMVUJe56iSutGXvnqdx63fhuXpjiaben86xQnTYFs hNjhRSrDSo9yM55D8hXjX5EYjW1QMEWBNpZlS/MVbmfHGB6F4mtJ7pSDn0R3Kb9LCeaQ lAIuG9gPqsJ0fUoC6R4NOUWlI/W8SFIO90tKrE04nUf2RWY18YJRweZOyzbgTEdZf/Qk BXFkdKLTmUlVlvYP7bs0d5euETmqW+FE5RinElE9Cy8P+39VRsu2lZSAa8WjqNTl5VJP i+XA== X-Gm-Message-State: APt69E2N0tRPeatXvon5IXccsGuL3ewtN5fsiu5Y/EAUXl79zK92uMT0 nSDIS55YUmQc0ss4B7rIjUDknYDRiQrQsCEK+l0= X-Received: by 2002:a37:1457:: with SMTP id e84-v6mr7363358qkh.3.1527791900266; Thu, 31 May 2018 11:38:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:9896:0:0:0:0:0 with HTTP; Thu, 31 May 2018 11:38:19 -0700 (PDT) In-Reply-To: <20180525011056.25132-1-david.e.box@linux.intel.com> References: <20180525011056.25132-1-david.e.box@linux.intel.com> From: Andy Shevchenko Date: Thu, 31 May 2018 21:38:19 +0300 Message-ID: Subject: Re: [PATCH V2] platform/x86: intel_pmc_core: Add CNP SLPS0 debug registers To: "David E. Box" Cc: Andy Shevchenko , Rajneesh Bhardwaj , Vishwanath Somayaji , Darren Hart , kyle.d.pelton@linux.intel.com, Platform Driver , Linux Kernel Mailing List 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 Fri, May 25, 2018 at 4:10 AM, David E. Box wrote: > Adds debugfs access to registers in the Cannon Point PCH PMC that are > useful for debugging #SLP_S0 signal assertion and other low power related > activities. Device pm states are latched in these registers whenever the > package enters C10 and can be read from slp_s0_debug_status. The pm > states may also be latched by writing 1 to slp_s0_dbg_latch which will > immediately capture the current state on the next read of > slp_s0_debug_status. Also while in intel_pmc_core.h clean up spacing. > Thanks for an update. My comments below. As far as I understand there is still ongoing discussion about the approach when and how to show data. So I'll wait a bit for a settlement between you, guys. > +static void pmc_core_slps0_dbg_latch(struct pmc_dev *pmcdev, bool reset) > +{ > + const struct pmc_reg_map *map = pmcdev->map; > + u32 fd; > + > + mutex_lock(&pmcdev->lock); > + > + if (!reset && !slps0_dbg_latch) > + goto out_unlock; > + > + fd = pmc_core_reg_read(pmcdev, map->slps0_dbg_offset); > + reset ? (fd &= ~CNP_PMC_LATCH_SLPS0_EVENTS) : > + (fd |= CNP_PMC_LATCH_SLPS0_EVENTS); I would rather use classical pattern here, i.e. if (reset) fd ... else fd ... > + pmc_core_reg_write(pmcdev, map->slps0_dbg_offset, fd); > + > + slps0_dbg_latch = 0; > + > +out_unlock: > + mutex_unlock(&pmcdev->lock); > +} > + struct pmc_dev *pmcdev = s ? s->private : &pmc; I'm not sure why do we need such condition. Simple ... pmcdev = s->private; is enough. > /* Cannonlake Power Management Controller register offsets */ > -#define CNP_PMC_SLP_S0_RES_COUNTER_OFFSET 0x193C > -#define CNP_PMC_LTR_IGNORE_OFFSET 0x1B0C > -#define CNP_PMC_PM_CFG_OFFSET 0x1818 > +#define CNP_PMC_SLP_S0_RES_COUNTER_OFFSET 0x193C > +#define CNP_PMC_LTR_IGNORE_OFFSET 0x1B0C > +#define CNP_PMC_PM_CFG_OFFSET 0x1818 I have hard time to understand what is the difference here. Either do another clean up patch (white spaces vs. tabs?) or leave it untouched. > /* Cannonlake: PGD PFET Enable Ack Status Register(s) start */ > -#define CNP_PMC_HOST_PPFEAR0A 0x1D90 > +#define CNP_PMC_HOST_PPFEAR0A 0x1D90 > > -#define CNP_PMC_MMIO_REG_LEN 0x2000 > -#define CNP_PPFEAR_NUM_ENTRIES 8 > -#define CNP_PMC_READ_DISABLE_BIT 22 > +#define CNP_PMC_MMIO_REG_LEN 0x2000 > +#define CNP_PPFEAR_NUM_ENTRIES 8 > +#define CNP_PMC_READ_DISABLE_BIT 22 Ditto. > +struct slps0_dbg_map { > + const struct pmc_bit_map *slps0_dbg_sts; > + int size; > +}; Didn't pay attention to this earlier. Why do we have a separate size member? What does it define? -- With Best Regards, Andy Shevchenko