[Intel-gfx] [PATCH 11/12] drm/i915/debugfs: Print information about what caused a PSR exit

Pandiyan, Dhinakaran dhinakaran.pandiyan at intel.com
Fri Mar 23 00:22:30 UTC 2018




On Fri, 2018-03-23 at 00:16 +0000, Souza, Jose wrote:
> On Thu, 2018-03-22 at 16:43 -0700, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > On Thu, 2018-03-22 at 16:27 -0700, Rodrigo Vivi wrote:
> > > On Thu, Mar 22, 2018 at 02:48:47PM -0700, José Roberto de Souza
> > > wrote:
> > > > This will be helpful to debug what hardware is actually tracking.
> > > > 
> > > > Signed-off-by: José Roberto de Souza <jose.souza at intel.com>
> > > > Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan at intel.com>
> > > > Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_debugfs.c | 47
> > > > +++++++++++++++++++++++++++++++++++++
> > > >  drivers/gpu/drm/i915/i915_reg.h     | 18 ++++++++++++++
> > > >  2 files changed, 65 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > index 0a0642c61cd0..3182e9a7cc5d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > @@ -2641,6 +2641,43 @@ static void
> > > > psr_sink_last_received_psr_sdp_sprintf(struct seq_file *m, u32
> > > > val)
> > > >  		seq_puts(m, "\tY-Coordinate valid\n");
> > > >  }
> > > >  
> > > > +static void psr_event_exit_sprintf(struct seq_file *m, u32 val,
> > > > +				   bool psr2_enabled)
> > > > +{
> > > > +	if (val & EDP_PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
> > > > +		seq_puts(m, "\tPSR2 watchdog timer expired\n");
> > > > +	if ((val & EDP_PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
> > > > +		seq_puts(m, "\tPSR2 disabled\n");
> > > > +	if (val & EDP_PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
> > > > +		seq_puts(m, "\tSU dirty FIFO underrun\n");
> > > > +	if (val & EDP_PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
> > > > +		seq_puts(m, "\tSU CRC FIFO underrun\n");
> > > > +	if (val & EDP_PSR_EVENT_GRAPHICS_RESET)
> > > > +		seq_puts(m, "\tGraphics reset\n");
> > > > +	if (val & EDP_PSR_EVENT_PCH_INTERRUPT)
> > > > +		seq_puts(m, "\tPCH interrupt\n");
> > > > +	if (val & EDP_PSR_EVENT_MEMORY_UP)
> > > > +		seq_puts(m, "\tMemory up\n");
> > > > +	if (val & EDP_PSR_EVENT_FRONT_BUFFER_MODIFY)
> > > > +		seq_puts(m, "\tFront buffer modification\n");
> > > > +	if (val & EDP_PSR_EVENT_WD_TIMER_EXPIRE)
> > > > +		seq_puts(m, "\tPSR watchdog timer expired\n");
> > > > +	if (val & EDP_PSR_EVENT_PIPE_REGISTERS_UPDATE)
> > > > +		seq_puts(m, "\tPIPE registers updated\n");
> > > > +	if (val & EDP_PSR_EVENT_REGISTER_UPDATE)
> > > > +		seq_puts(m, "\tRegister update\n");
> > > > +	if (val & EDP_PSR_EVENT_HDCP_ENABLE)
> > > > +		seq_puts(m, "\tHDCP enabled\n");
> > > > +	if (val & EDP_PSR_EVENT_KVMR_SESSION_ENABLE)
> > > > +		seq_puts(m, "\tKVMR session enabled\n");
> > > > +	if (val & EDP_PSR_EVENT_VBI_ENABLE)
> > > > +		seq_puts(m, "\tVBI enabled\n");
> > > > +	if (val & EDP_PSR_EVENT_LPSP_MODE_EXIT)
> > > > +		seq_puts(m, "\tLPSP mode exited\n");
> > > > +	if ((val & EDP_PSR_EVENT_PSR_DISABLE) && !psr2_enabled)
> > > > +		seq_puts(m, "\tPSR disabled\n");
> > > > +}
> > > > +
> > > >  static int i915_edp_psr_status(struct seq_file *m, void *data)
> > > >  {
> > > >  	struct drm_i915_private *dev_priv = node_to_i915(m-
> > > > >private);
> > > > @@ -2716,6 +2753,16 @@ static int i915_edp_psr_status(struct
> > > > seq_file *m, void *data)
> > > >  
> > > >  		seq_printf(m, "Performance_Counter: %u\n",
> > > > psrperf);
> > > >  	}
> > > > +
> > > > +	if (INTEL_GEN(dev_priv) >= 9) {
> > > > +		u32 val = I915_READ(EDP_PSR_EVENT);
> > > 
> > > What I'm afraid here is that this really shows the last event or
> > > the first one after we cleared.
> > > 
> > 
> > Both, the bits remain set unless cleared. I have plans of printing
> > the
> > events out of the PSR exit irq handler. This really was one of the
> > main
> > reasons to implement PSR interrupts. Since we get interrupt for each
> > PSR
> > exit, we'll also print out the correct event that caused exit.
> > 
> 
> Exactly that, so should I drop this one?
> Are you planning send a patch later showing the reasons in the debugfs?

Yeah, I was planning to do it after the interrupt series is merged.
Since you've already done all the work for this patch, I think it makes
sense for you to one this one on top of PSR interrupts.

> This way we could improve and write new IGT tests.
> 


More information about the Intel-gfx mailing list