Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	intel-gfx@lists.freedesktop.org,
	"Len Brown" <len.brown@intel.com>
Subject: Re: [PATCH] drm/i915: Extend residency counter ranges on chv and byt
Date: Fri, 03 Mar 2017 10:11:34 +0200	[thread overview]
Message-ID: <8760jqbwzt.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20170302191543.GJ31595@intel.com>

Ville Syrjälä <ville.syrjala@linux.intel.com> writes:

> On Thu, Mar 02, 2017 at 06:21:37PM +0000, Chris Wilson wrote:
>> On Thu, Mar 02, 2017 at 08:13:31PM +0200, Ville Syrjälä wrote:
>> > On Thu, Mar 02, 2017 at 08:01:40PM +0200, Mika Kuoppala wrote:
>> > > We were passively acting on the high counter value bit
>> > > and as it was never set, we were only utilizing the
>> > > the 32bits of resolution. As the divisor with these platforms
>> > > is quite high, the wrap around happened in the less than 13 seconds.
>> > > 
>> > > If we toggle the resolution bit in the control register and
>> > 
>> > Can't be done on all machines. IIRC both Chris and me tried this at
>> > some point and on some machines the register was locked. Also I'm
>> > not sure if some piece of firmware depends on the original setting.
>> 
>> > Ville Syrjälä wrote:
>> > On Thu, Apr 07, 2016 at 02:58:01PM +0100, Chris Wilson wrote:
>> > > On Thu, Apr 07, 2016 at 04:18:16PM +0300, Ville Syrjälä wrote:
>> > > > On Thu, Apr 07, 2016 at 01:59:44PM +0100, Chris Wilson wrote:
>> > > > > Can we set that bit ourselves? That puts the overflow into the 1 hour
>> > > > > mark. Thanks,
>> > > > 
>> > > > I don't know if it's safe to frob the bit. I worry that something
>> > > > outside our control might depend on it staying put.
>> > > 
>> > > A quick frob of the bit says that it is RO. When I try to set it, it
>> > > doesn't stick. :(
>> > 
>> > Same here on my VLV. I was able to toggle it on my BSW. Perhaps
>> > something can lock it down, and my BSW BIOS just doesn't do that.
>> 
>> Bah. Humbug.
>
> Hmm. Actually now that I tried it again it seems to stick at least on
> one BSW and two VLV machines. I'm not 100% those VLV machines are what I
> tried before, but the third one I have has died so I can't re-test it.
>
> The other explanation for the failure I saw earlier could be that I
> forgot to set the mask bit. Interestingly the mask bit reads as 0 on
> VLV and as 1 on CHV, but when writing both need it to be set (as is
> expected for a mask bit).

I falled for this trap atleast on the first try. The bspec nomenclature
on the page was somewhat nonstandard, mask bits misleadingly 'RO'
so my brain skipped those at first read...

-Mika
>
> BTW I found this note in the Gunit docs:
> "Each of these counters will start counting on reset and continue
>  counting when that particular event happens. There will be a 40-bit
>  counter. 0x13_8104[15] selects if the lower 32 bits or the upper
>  32 bits of the 40-bit counter are read out. 0x13_8104[7:0] will
>  have individual enables for each of the above counters"
>
> Hmm. It also looks like we're explicitly enabling the high range mode on
> CHV in rps init. But on VLV we don't touch that bit. I can't see this
> register being mentioned in the BIOS spec, so I'm not sure who came up
> with this code. Oh, actually it seems we were enabling the high range
> bit on VLV too until commit 31685c258e0b ("drm/i915/vlv: WA for Turbo
> and RC6 to work together.")
>
> So all this leads to me to think that maybe it's safe to frob this
> register after all. If it were super important for turbo/rc6 I would
> have expected to see it in the BIOS spec.
>
> -- 
> Ville Syrjälä
> Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-03-03  8:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-02 18:01 [PATCH] drm/i915: Extend residency counter ranges on chv and byt Mika Kuoppala
2017-03-02 18:13 ` Chris Wilson
2017-03-02 18:19   ` Chris Wilson
2017-03-02 18:20   ` Mika Kuoppala
2017-03-02 18:34     ` Chris Wilson
2017-03-02 18:13 ` Ville Syrjälä
2017-03-02 18:18   ` Mika Kuoppala
2017-03-02 18:21   ` Chris Wilson
2017-03-02 19:15     ` Ville Syrjälä
2017-03-03  8:11       ` Mika Kuoppala [this message]
2017-03-02 19:47 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-03-03 14:16 ` [PATCH] " Chris Wilson

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=8760jqbwzt.fsf@gaia.fi.intel.com \
    --to=mika.kuoppala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=len.brown@intel.com \
    --cc=ville.syrjala@linux.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