Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Hogander, Jouni" <jouni.hogander@intel.com>
To: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915/display: Prevent DC6 while vblank is enabled for Panel Replay
Date: Thu, 12 Sep 2024 07:05:14 +0000	[thread overview]
Message-ID: <add0beda290e1324c1c40687ef18ed7f77927934.camel@intel.com> (raw)
In-Reply-To: <ZuGn5l9oLy_gk_Il@intel.com>

On Wed, 2024-09-11 at 17:23 +0300, Ville Syrjälä wrote:
> On Wed, Sep 11, 2024 at 01:14:33PM +0000, Hogander, Jouni wrote:
> > On Wed, 2024-09-11 at 16:00 +0300, Ville Syrjälä wrote:
> > > On Wed, Sep 11, 2024 at 03:40:15PM +0300, Jouni Högander wrote:
> > > > We need to block DC6 entry in case of Panel Replay as enabling
> > > > VBI
> > > > doesn't
> > > > prevent DC6 in case of Panel Replay.
> > > 
> > > This doesn't make sense to me. I *think* we are currently
> > > supposed to always operate in the "main link on" mode for panel
> > > replay.
> > 
> > This is not true. Check bspec 68920:
> > 
> > "When performing PR on an eDP port the Source will allow advanced
> > link
> > power management (ALPM) to turn the Main Link OFF when not sending
> > an
> > SDP or update region."
> 
> Right, it seems to be a thing for eDP only.
> 
> > 
> > And if you check block_dc6_needed in my patch that is checking eDP.
> > 
> > I was originally planning to handle this by preventing PR entry
> > when
> > VBLANK is enabled, but that would be more expensive from power
> > managements point of view -> decided to go with blocking DC6.
> 
> None of this explains how DC6 vs. DC5 is somehow different.
> DC5 should already turn of all the clocks/etc so nothing real
> can actually happen anymore. The only thing DC6 adds on top
> of DC5 is turning off some extra power wells.

Ok, based on your description I should use DC_STATE_DISABLE.

> 
> Hmm. So get_allowed_dc_mask() seems to be telling me that new
> platforms only have DC6 but no DC5. Is that correct or not?
> No idea. But that means we are in fact disabling all DC states
> and that at least explains how something might happen due to
> this patch.

Probably this is what happens. I will use DC_STATE_DISABLE instead.

> 
> The one thing that still doesn't quite make sense is that I would
> assume that the main link would get turned off regardless of DC6
> or not, which I would think causes the timing generator to stop
> anyway and should still give us no vblanks...

Comment from HW team was:

"Unlike PSR1/PSR2, the Transcoder’s timing generator never stops when
PR is Active (assuming DC6 is disabled), so the Transcoder will always
send V. Blank events to the interrupt structure."

BR,

Jouni Högander


> 


  reply	other threads:[~2024-09-12  7:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-11 12:40 [PATCH] drm/i915/display: Prevent DC6 while vblank is enabled for Panel Replay Jouni Högander
2024-09-11 13:00 ` Ville Syrjälä
2024-09-11 13:14   ` Hogander, Jouni
2024-09-11 14:23     ` Ville Syrjälä
2024-09-12  7:05       ` Hogander, Jouni [this message]
2024-09-11 15:14 ` Ville Syrjälä
2024-09-11 18:48 ` ✗ Fi.CI.SPARSE: warning for " Patchwork
2024-09-11 19:04 ` ✗ Fi.CI.BAT: 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=add0beda290e1324c1c40687ef18ed7f77927934.camel@intel.com \
    --to=jouni.hogander@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --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