|
On Friday 12 August 2016 12:02 PM,
Ville Syrjälä wrote:
This means bit 12 must be enabled to program hb0 to hb3 from softwareOn Fri, Aug 12, 2016 at 10:48:12AM +0530, vathsala nagaraju wrote:On Thursday 11 August 2016 01:30 PM, Ville Syrjälä wrote:On Thu, Aug 11, 2016 at 01:07:50PM +0530, vathsala nagaraju wrote: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 <rodrigo.vivi@xxxxxxxxx> Signed-off-by: vathsala nagaraju <vathsala.nagaraju@xxxxxxxxx> --- 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);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. hardware folks informed that it's not possible to read the data.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? Only way is through connecting dp analyser. 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. HW will send based on enable and disable setting of this bit.
HW supports SU granularity of 4 lines.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. 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. |
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
