[Intel-gfx] [PATCH] drm/i915: Add Baytrail PSR Support.

Ville Syrjälä ville.syrjala at linux.intel.com
Fri Jan 24 18:41:04 CET 2014


On Fri, Jan 24, 2014 at 02:05:57PM -0200, Rodrigo Vivi wrote:
> On Fri, Jan 24, 2014 at 12:53 PM, Ville Syrjälä
> <ville.syrjala at linux.intel.com> wrote:
> > On Thu, Jan 23, 2014 at 05:19:53PM -0200, Rodrigo Vivi wrote:
> > <snip>
> >> index 76126e0..f5501ab 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -1969,6 +1969,40 @@
> >>  #define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B)
> >>  #define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B)
> >>
> >> +/* VLV eDP PSR registers */
> >> +#define VLV_EDP_PSR_CTL                              (VLV_DISPLAY_BASE + 0x60090)
> >
> > VLV has per-pipe PSR registers. The ones you have here are just for
> > pipe A. Seems like some rework is needed to make it work on either
> > pipe.
> 
> Yes, but since I don't have any hw with two eDPs here I decided to let
> the limitation we had for HSW, PSR only on pipe A.
> In my point of view we could go ahead with this one eDP scenario and
> implement psr on pipe b support later.

I don't see any pipe checks in the code, so you will happily enable PSR
on pipe A even if eDP is being fed by pipe B at the time.

Also even if you enable PSR on pipe A, you set the trunk clock gate
disable for pipe B, which seems weird. Setting that bit might actually
be the reason the pipe, port and PLL remain enabled during PSR.

-- 
Ville Syrjälä
Intel OTC



More information about the Intel-gfx mailing list