All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Summers, Stuart" <stuart.summers@intel.com>
To: "Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/i915: Re-add enable_rc6 modparam
Date: Tue, 21 May 2019 19:17:57 +0000	[thread overview]
Message-ID: <89c68007f7cc7568a98e73d090f1e35b908bee35.camel@intel.com> (raw)
In-Reply-To: <20190517161739.GC6984@intel.com>


[-- Attachment #1.1: Type: text/plain, Size: 4433 bytes --]

On Fri, 2019-05-17 at 09:17 -0700, Rodrigo Vivi wrote:
> On Thu, May 16, 2019 at 03:49:19PM +0000, Summers, Stuart wrote:
> > On Thu, 2019-05-16 at 18:42 +0300, Jani Nikula wrote:
> > > On Thu, 16 May 2019, "Summers, Stuart" <stuart.summers@intel.com>
> > > wrote:
> > > > On Thu, 2019-05-16 at 12:59 +0300, Jani Nikula wrote:
> > > > > On Tue, 14 May 2019, Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > > wrote:
> > > > > > One possibility that just came to my mind now is, what if
> > > > > > we
> > > > > > make
> > > > > > this only for platforms that are still protected by
> > > > > > is_alpha_support=1
> > > > > > (soon becoming require_force_probe=1)
> > > > > 
> > > > > Please don't conflate alpha_support or force_probe with
> > > > > *anything*
> > > > > else.
> > > > > 
> > > > > > But this is just one side of the coin... when product is
> > > > > > out
> > > > > > there
> > > > > > and we want the user to debug the issue to see if it is a
> > > > > > RC6
> > > > > > bug
> > > > > > we have no way to verify that. :/
> > > > > 
> > > > > The problem is, if it works with rc6 disabled, it doesn't
> > > > > prove
> > > > > it's
> > > > > an
> > > > > rc6 bug either.
> 
> Well, RC6 is the main GT power gating. The issue could be on may
> other
> individual power gating, but if by disabling RC6 the issue is gone
> it is a very good indication that it is a GT-PM bug somewhere.
> 
> > > > 
> > > > Good point. I'm not saying we should enforce a process of
> > > > disabling
> > > > RC6
> > > > for the platform if enable_rc6=0 results in success. I'm just
> > > > saying
> > > > having the option is useful from a debug perspective. We will
> > > > still
> > > > need to do the appropriate full analysis, including the normal
> > > > code
> > > > review process on a pre-case basis when debug involves this
> > > > parameter.
> > > > But the parameter itself is still useful.
> > > 
> > > The trouble starts when users figure out that enable_rc6=0 works
> > > around
> > > a particular problem they have (likely by way of disabling
> > > runtime
> > > pm,
> > > not directly related to rc6). You could argue this is a good
> > > thing,
> > > but
> > > unfortunately we generally never hear from them again, and the
> > > root
> > > cause remains unsolved, with degraded user experience wrt power
> > > management.
> 
> This is indeed bad. We should probably be clear that by disabling
> that
> they are draining their power and probably killing battery life.

I could add a DRM_ERROR or even a GEM_WARN_ON if this is set with a
description similar to what you have if that's interesting.

> 
> > 
> > So I understand the reasoning here, and agree that isn't an ideal
> > situation. I'd also like a way to debug more efficiently. What did
> > you
> > think about the suggestion from Tvrtko to only apply on
> > CONFIG_DRM_I915_DEBUG?
> 
> if debug is on and parameter is set, right? Might be a good thing to
> avoid the abuse on the parameter.
> 
> > 
> > Or we could even wrap this entirely with a CONFIG_I915_DEBUG_PM -
> > although I'd like to suggest we still use the module parameter, we
> > could just use the config option to hide the modparam under normal
> > operation.
> 
> I think this looks more like you are enabling more logs and
> not that you are disabling... unless the plan is to go with
> this flag plus logs and traces around PM. Than I think it is
> a good idea.

I'm not precluding people from adding more logs here - and there will
at least be some additional logs indicating we are bypassing the PM
flows. But at least for this patch, the intention would be to add new
"debug capability", which in this case, means the addition of the new
module parameter, enable_rc6.

Really this is just an extra deterent for users, since they'll need to
custom build the kernel to get this - not something enabled by default
in one of the distros, for instance.

Thanks,
Stuart

> 
> Same rules needs to apply to  RC6, RPM, DC states,
> display power well management, psr, etc.
> 
> Thanks,
> Rodrigo.
> 
> > 
> > Thanks,
> > Stuart
> > 
> > > 
> > > BR,
> > > Jani.
> > > 
> > > 
> 
> 
> 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3270 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-05-21 19:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14 16:46 [PATCH 1/2] drm/i915: Re-add enable_rc6 modparam Stuart Summers
2019-05-14 16:46 ` [PATCH 2/2] drm/i915: Extend reset modparam to domain resets Stuart Summers
2019-05-14 16:54   ` Chris Wilson
2019-05-14 17:03     ` Summers, Stuart
2019-05-14 16:53 ` [PATCH 1/2] drm/i915: Re-add enable_rc6 modparam Chris Wilson
2019-05-14 18:32   ` Summers, Stuart
2019-05-15  0:06     ` Rodrigo Vivi
2019-05-15  5:43       ` Tvrtko Ursulin
2019-05-15 14:16         ` Summers, Stuart
2019-05-16  9:59       ` Jani Nikula
2019-05-16 14:10         ` Summers, Stuart
2019-05-16 15:42           ` Jani Nikula
2019-05-16 15:49             ` Summers, Stuart
2019-05-17 16:17               ` Rodrigo Vivi
2019-05-17 16:34                 ` Ville Syrjälä
2019-05-17 16:44                   ` Rodrigo Vivi
2019-05-17 17:02                     ` Ville Syrjälä
2019-05-21 19:17                 ` Summers, Stuart [this message]
2019-05-14 17:07 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] " Patchwork
2019-05-14 17:29 ` ✓ Fi.CI.BAT: success " Patchwork
2019-05-15  0:23 ` ✗ Fi.CI.IGT: failure " Patchwork

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=89c68007f7cc7568a98e73d090f1e35b908bee35.camel@intel.com \
    --to=stuart.summers@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rodrigo.vivi@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 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.