<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On Friday 12 August 2016 12:02 PM, Ville Syrjälä wrote: </div> <blockquote cite="mid:20160812063212.GU4329@intel.com" type="cite"> <pre wrap="">On Fri, Aug 12, 2016 at 10:48:12AM +0530, vathsala nagaraju wrote: </pre> <blockquote type="cite"> <pre wrap="">On Thursday 11 August 2016 01:30 PM, Ville Syrjälä wrote: </pre> <blockquote type="cite"> <pre wrap="">On Thu, Aug 11, 2016 at 01:07:50PM +0530, vathsala nagaraju wrote: </pre> <blockquote type="cite"> <pre wrap="">Adds Y-co-ordinate support to skl_psr_setup_vsc as per edp 1.4 spec,table 6-11:VSC SDP HEADER Extension for psr2 support. Cc: Rodrigo Vivi <a class="moz-txt-link-rfc2396E" href="mailto:rodrigo.vivi@intel.com"><rodrigo.vivi@intel.com></a> Signed-off-by: vathsala nagaraju <a class="moz-txt-link-rfc2396E" href="mailto:vathsala.nagaraju@intel.com"><vathsala.nagaraju@intel.com></a> --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_dp.c | 22 ++++++++++++++++++++++ drivers/gpu/drm/i915/intel_psr.c | 13 ++++++++++++- include/drm/drm_dp_helper.h | 5 ++++- 4 files changed, 40 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 7f2754a..79ce64f 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1022,6 +1022,8 @@ struct i915_psr { bool psr2_support; bool aux_frame_sync; bool link_standby; + bool y_cord_support; + bool colorimetry_support; }; enum intel_pch { diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 364db90..19e9ecf 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3439,6 +3439,28 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp) dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync; DRM_DEBUG_KMS("PSR2 %s on sink", dev_priv->psr.psr2_support ? "supported" : "not supported"); + + if (dev_priv->psr.psr2_support) { + uint8_t psr_caps, dprx; + + /*check if panel supports Y-Cordinate*/ + drm_dp_dpcd_readb(&intel_dp->aux, + DP_PSR_CAPS, + &psr_caps); </pre> </blockquote> <pre wrap="">intel_dp->edp_dpcd[1] We should probably add something resembling dp_link_status() for each DPCD chunk we cache, to make it less confusing to use them. </pre> <blockquote type="cite"> <pre wrap="">+ if (psr_caps & DP_PSR_Y_COORDINATE) + dev_priv->psr.y_cord_support = true; + else + dev_priv->psr.y_cord_support = false; + /* check for COLORIMETRY SUPPORT */ + drm_dp_dpcd_readb(&intel_dp->aux, + DPRX_FEATURE_ENUMERATION_LIST, + &dprx); + if (dprx & VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED) + dev_priv->psr.colorimetry_support = true; + else + dev_priv->psr.colorimetry_support = false; + } + } /* Read the eDP Display control capabilities registers */ diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 59a21c9..76a630b 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -122,13 +122,24 @@ static void vlv_psr_setup_vsc(struct intel_dp *intel_dp) static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp) { struct edp_vsc_psr psr_vsc; + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); + struct drm_device *dev = intel_dig_port->base.base.dev; + struct drm_i915_private *dev_priv = to_i915(dev); /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */ memset(&psr_vsc, 0, sizeof(psr_vsc)); psr_vsc.sdp_header.HB0 = 0; psr_vsc.sdp_header.HB1 = 0x7; psr_vsc.sdp_header.HB2 = 0x3; - psr_vsc.sdp_header.HB3 = 0xb; + psr_vsc.sdp_header.HB3 = 0xc; + if (dev_priv->psr.y_cord_support && + dev_priv->psr.colorimetry_support) { + psr_vsc.sdp_header.HB2 = 0x5; + psr_vsc.sdp_header.HB3 = 0x13; + } else { + psr_vsc.sdp_header.HB2 = 0x4; + psr_vsc.sdp_header.HB3 = 0xe; + } </pre> </blockquote> <pre wrap="">That looks bogus. Why do we claim to have colorimetry data but then don't fill it out? </pre> </blockquote> <pre wrap="">HB2 to be set 04 or 05 04h = 3D stereo + PSR/PSR2 + Y-coordinate. 05h = 3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry Format As of now it's defaulting to 0x4, will correct it. </pre> <blockquote type="cite"> <pre wrap=""> Also you're not setting the actual y coordinate stuff anywhere, so why would we want to indicate that we support it? </pre> </blockquote> <pre wrap="">Bspec says to set CHICKEN_TRANS_EDP(0x420cc) bit 15 if Y coordinate is supported. it set in patch 2. </pre> </blockquote> <pre wrap=""> This whole part of the spec looks a wee bit inadequate. Hmm. So bit 25 of CHICKEN_TRANS_EDP seems to control whether the hardware will generate part of the VSC SDP or not. But nowhere does it explain which part that is. The sequence doesn't even mention that bit, but it does mention bit 12 which means "This field enables the programmable header for the PSR2 VSC packet.". Not sure what that means.</pre> </blockquote> This means bit 12 must be enabled to program hb0 to hb3 from software <blockquote cite="mid:20160812063212.GU4329@intel.com" type="cite"> <pre wrap=""> If that means the hardware can generate the HB0-3 bytes, it would be nice to know what exactly it will put there. And because of this I can't be sure why we have to switch to the manual header mode in PSR2. Maybe it means the hardware generates a header that doesn't allow the Y coordinate stuff. Hmm. Can we maybe read out the hardware generated data via the VSC DIP?</pre> </blockquote> hardware folks informed that it's not possible to read the data. Only way is through connecting dp analyser. <blockquote cite="mid:20160812063212.GU4329@intel.com" type="cite"> <pre wrap=""> And then there are these bits 11 and 15 which controls *something* about the Y coordindate stuff. But it doesn't actually explain if the hardware will fill those out or just send/not send based on these bits. If we assume it will fill them out, then yes, I suppose we should make sure the VSC SDP version and size are high enough to include them.</pre> </blockquote> HW will send based on enable and disable setting of this bit.<o:p></o:p> <table class="MsoNormalTable" style="width:375.0pt;background:white" width="500" border="1" cellpadding="0" cellspacing="1"> <tbody> <tr> <td style="padding:.75pt .75pt .75pt .75pt"> bit 15<o:p></o:p> </td> <td style="padding:.75pt .75pt .75pt .75pt"> bit 11<o:p></o:p> </td> <td style="padding:.75pt .75pt .75pt .75pt"> Description<o:p></o:p> </td> </tr> <tr> <td style="padding:.75pt .75pt .75pt .75pt"> 0<o:p></o:p> </td> <td style="padding:.75pt .75pt .75pt .75pt"> 0<o:p></o:p> </td> <td style="padding:.75pt .75pt .75pt .75pt"> Y-coordinate (DB12-DB13) and Y-valid (DB1 bit6) are disabled.<o:p></o:p> </td> </tr> <tr> <td style="padding:.75pt .75pt .75pt .75pt"> 0<o:p></o:p> </td> <td style="padding:.75pt .75pt .75pt .75pt"> 1<o:p></o:p> </td> <td style="padding:.75pt .75pt .75pt .75pt"> Not a valid setting.<o:p></o:p> </td> </tr> <tr> <td style="padding:.75pt .75pt .75pt .75pt"> 1<o:p></o:p> </td> <td style="padding:.75pt .75pt .75pt .75pt"> 0<o:p></o:p> </td> <td style="padding:.75pt .75pt .75pt .75pt"> Y-coordinate (VSC bytes DB12-DB13) is sent and Y-valid (DB1 bit6) is included.<o:p></o:p> </td> </tr> <tr> <td style="padding:.75pt .75pt .75pt .75pt"> 1<o:p></o:p> </td> <td style="padding:.75pt .75pt .75pt .75pt"> 1<o:p></o:p> </td> <td style="padding:.75pt .75pt .75pt .75pt"> Y-coordinate (VSC bytes DB12-DB13) is sent and Y-valid (DB1 bit6) is not included. </td> </tr> </tbody> </table> <blockquote cite="mid:20160812063212.GU4329@intel.com" type="cite"> <pre wrap=""> Also how does the hardware handle the SU granularity? I see no bits to control that, so I can't see how the hardware could know what it has to do here. Hmm. PSR2_MAN_TRK_CTL seems to say that when using manual tracking, it's going to send chunks of 4 scanlines always, which I suppose will satisfy the worst case for both the X and Y granularity. So I guess the hardware tracking mode would just do the same. </pre> </blockquote> HW supports SU granularity of 4 lines. <blockquote cite="mid:20160812063212.GU4329@intel.com" type="cite"> <pre wrap=""> Oh, and while reading the eDP spec, I noticed that the AUX frame sync requires GTC, which we totally don't seem to even configure/enable. We do however tell the sink to enable AUX frame sync whenever it supports it. AUX frame sync is mandatory for PSR2 SU AFAICS, and without SU it doesn't seem to be needed. I haven't spotted any patches for GTC, so I'm asuming it's all still a bit broken. </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap=""> intel_psr_write_vsc(intel_dp, &psr_vsc); } diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 63b8bd5..3d875c0 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -194,7 +194,7 @@ # define DP_PSR_SETUP_TIME_0 (6 << 1) # define DP_PSR_SETUP_TIME_MASK (7 << 1) # define DP_PSR_SETUP_TIME_SHIFT 1 - +# define DP_PSR_Y_COORDINATE (1 << 4) /* * 0x80-0x8f describe downstream port capabilities, but there are two layouts * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not, @@ -640,6 +640,9 @@ struct edp_sdp_header { #define EDP_SDP_HEADER_REVISION_MASK 0x1F #define EDP_SDP_HEADER_VALID_PAYLOAD_BYTES 0x1F +#define DPRX_FEATURE_ENUMERATION_LIST 0x02210 +#define VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED (1 << 3) + struct edp_vsc_psr { struct edp_sdp_header sdp_header; u8 DB0; /* Stereo Interface */ -- 2.7.4 _______________________________________________ Intel-gfx mailing list <a class="moz-txt-link-abbreviated" href="mailto:Intel-gfx@lists.freedesktop.org">Intel-gfx@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/intel-gfx">https://lists.freedesktop.org/mailman/listinfo/intel-gfx</a> </pre> </blockquote> </blockquote> </blockquote> <pre wrap=""> </pre> </blockquote> </body> </html>