From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Daniel Vetter <daniel@ffwll.ch>, Imre Deak <imre.deak@intel.com>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/3] tests/pm_rps: vlv: load gpu for idle min/max tests
Date: Fri, 5 Dec 2014 22:06:45 +0100 [thread overview]
Message-ID: <20141205210644.GF20350@phenom.ffwll.local> (raw)
In-Reply-To: <20141205205942.GN13586@nuc-i3427.alporthouse.com>
On Fri, Dec 05, 2014 at 08:59:42PM +0000, Chris Wilson wrote:
> On Fri, Dec 05, 2014 at 09:56:18PM +0100, Daniel Vetter wrote:
> > On Thu, Dec 04, 2014 at 06:09:39PM +0200, Imre Deak wrote:
> > > When changing the sysfs GT min/max frequencies, the kernel won't
> > > explicitly change the current frequency, unless it becomes out of bound
> > > based on the new min/max values. The test happens to work on non-VLV
> > > platforms because on those the kernel resets the current frequency
> > > unconditionally (to adjust the RPS interrupt mask as a side-effect) and
> > > that will lead to an RPS interrupt setting the minimum frequency.
> > >
> > > To fix this load the GPU after decreasing the min frequency and before
> > > checking the current frequency. This should set the current frequency to
> > > the minimum.
> > >
> > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> >
> > Isn't this a kernel bug which should be fixed in the kernel? If userspace
> > changes the requested freq, the kernel should obey right away. Not
> > somewhen later when something happens ...
>
> Only if busy. If the GPU is idle, we should ignore the softlimits and
> program the most efficient idle frequency - as part of i915.powersave.
Hm yeah that slight reinterpretation of the limits makes them actually
more useful. So ack from me on all 3 patches.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2014-12-05 21:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-04 16:09 [PATCH 0/3] igt/pm_rps: fix some subcases for vlv Imre Deak
2014-12-04 16:09 ` [PATCH 1/3] tests/pm_rps: vlv: wait for freq to settle Imre Deak
2014-12-04 16:09 ` [PATCH 2/3] tests/pm_rps: vlv: load gpu for idle min/max tests Imre Deak
2014-12-05 20:56 ` Daniel Vetter
2014-12-05 20:59 ` Chris Wilson
2014-12-05 21:06 ` Daniel Vetter [this message]
2014-12-05 21:01 ` Imre Deak
2014-12-04 16:09 ` [PATCH 3/3] tests/pm_rps: vlv: round middle point to freq supported by HW Imre Deak
2014-12-04 16:31 ` Ville Syrjälä
2014-12-05 14:27 ` [PATCH v2 " Imre Deak
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=20141205210644.GF20350@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.