From: Evan Green <evgreen@chromium.org>
To: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Cc: Rajat Jain <rajatja@google.com>,
Furquan Shaikh <furquan@chromium.org>,
Ravi Chandra Sadineni <ravisadineni@chromium.org>,
Vishwanath Somayaji <vishwanath.somayaji@intel.com>,
Andy Shevchenko <andy@infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
platform-driver-x86@vger.kernel.org,
Darren Hart <dvhart@infradead.org>
Subject: Re: [PATCH] platform/x86: intel_pmc_core: Report slp_s0 residency range
Date: Fri, 5 Apr 2019 10:52:04 -0700 [thread overview]
Message-ID: <CAE=gft7r+0s6M2KZLdcp33xvnxjX2Kqyg-vVk5dVVoC5PUOGqw@mail.gmail.com> (raw)
In-Reply-To: <20190405071455.GA30194@raj-desk2.iind.intel.com>
On Fri, Apr 5, 2019 at 12:28 AM Rajneesh Bhardwaj
<rajneesh.bhardwaj@intel.com> wrote:
>
> On Mon, Apr 01, 2019 at 11:05:04AM -0700, Evan Green wrote:
> > The PMC driver performs a 32-bit read on the sleep s0 residency counter,
> > followed by a hard-coded multiplication to convert into microseconds.
> > The maximum value this counter could have would be 0xffffffff*0x64
> > microseconds, which by my calculations is about 4.9 days. This is well
> > within a reasonable time period to observe an overflow.
> >
> > Usermode consumers watching slp_s0_residency_usec need to be aware of
> > overflows, but have no idea what the maximum value of this counter is,
> > given the hardcoded multiply of a 32-bit value by
> > SPT_PMC_SLP_S0_RES_COUNTER_STEP.
>
> This register is a 32 bit register untill ICL generation and a recent patch
> from Rajat fixed the overflow https://patchwork.kernel.org/patch/10816103/
> already so i am not sure how this will help userspace. I think the userspace
> can still take care of any overflow concerns based on the information
> available about this register in EDS so i feel exposing a new debugfs entry
> just for the sake of knowing range is probably not needed.
So you don't anticipate reusing this driver for other models where the
factor of 100 might change, or the counter might be a different width?
We can hardcode the multiply in usermode in order to detect when we've
exceeded the 4.9 day rollover range, but it seemed brittle, and would
break if this hardware implementation detail ever changed.
-Evan
next prev parent reply other threads:[~2019-04-05 17:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-01 18:05 [PATCH] platform/x86: intel_pmc_core: Report slp_s0 residency range Evan Green
2019-04-05 7:14 ` Rajneesh Bhardwaj
2019-04-05 17:52 ` Evan Green [this message]
2019-04-06 19:11 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAE=gft7r+0s6M2KZLdcp33xvnxjX2Kqyg-vVk5dVVoC5PUOGqw@mail.gmail.com' \
--to=evgreen@chromium.org \
--cc=andy@infradead.org \
--cc=dvhart@infradead.org \
--cc=furquan@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rajatja@google.com \
--cc=rajneesh.bhardwaj@intel.com \
--cc=ravisadineni@chromium.org \
--cc=vishwanath.somayaji@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).