From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [PATCH 6/7] drm/i915: Restart RPS using the same RP_CONTROL as from initialisation
Date: Mon, 20 Feb 2017 16:59:05 +0200 [thread overview]
Message-ID: <87lgt0di2u.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20170220144744.GL11809@nuc-i3427.alporthouse.com>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> On Mon, Feb 20, 2017 at 04:40:47PM +0200, Mika Kuoppala wrote:
>> Chris Wilson <chris@chris-wilson.co.uk> writes:
>>
>> > During initialisation, we set different flags for different
>> > architectures - these should be preserved when we reload the RPS
>> > thresholds. If we use a mmio read, it will first ensure that the
>> > threshold registers are written before we apply the latch in RP_CONTROL.
>> >
>> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> > Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>> > Cc: stable@vger.kernel.org
>>
>> This will change how the valleyview will do the DOWN_IDLE,
>> due to readback you will get a GEN6_RP_DOWN_IDLE_CONT.
>
> No change, since we don't use it on byt - we only use the EI intervals
> as we manually calculate the up/down signals based on the C0 counters.
>
>> I can't think of why we would like to keep that behaviour
>> as the IDLE_CONT setup is a twart in my opinion.
>>
>> If you agree with the above, substitute the IDLE_CONT in
>> valleview setup and you can add,
>
> It is a mistake in the setup, but that change has to be seperate to
> exclude it as being part of the magic that avoids the hang.
Ok, so let me rephrase. As the skipping of the IDLE_CONT had
an effect to the way byt behaves, we intentionally want to keep that
with byt.
So this is no accident, and yes it makes sense
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2017-02-20 15:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170220094713.22874-1-chris@chris-wilson.co.uk>
2017-02-20 9:47 ` [PATCH 4/7] drm/i915: Use set_rps to enable RPS Chris Wilson
2017-02-20 14:29 ` Mika Kuoppala
2017-02-20 14:38 ` Chris Wilson
2017-02-20 9:47 ` [PATCH 5/7] drm/i915: Take forcewake for setting the RPS thresholds Chris Wilson
2017-02-20 14:34 ` Mika Kuoppala
2017-02-20 14:45 ` Chris Wilson
2017-02-20 9:47 ` [PATCH 6/7] drm/i915: Restart RPS using the same RP_CONTROL as from initialisation Chris Wilson
2017-02-20 13:33 ` [Intel-gfx] " Szwichtenberg, Radoslaw
2017-02-20 14:40 ` Mika Kuoppala
2017-02-20 14:47 ` Chris Wilson
2017-02-20 14:59 ` Mika Kuoppala [this message]
2017-02-20 9:47 ` [PATCH 7/7] drm/i915: Stop RPS as we adjust thresholds Chris Wilson
2017-02-20 12:35 ` [Intel-gfx] " Szwichtenberg, Radoslaw
2017-02-20 14:41 ` Mika Kuoppala
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=87lgt0di2u.fsf@gaia.fi.intel.com \
--to=mika.kuoppala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@vger.kernel.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 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).