Re: [Intel-gfx] [PATCH -next] drm/i915: Fix non static symbol warning
On Sat, 17 Sep 2016, Wei Yongjun wrote: > From: Wei Yongjun > > Fixes the following sparse warning: > > drivers/gpu/drm/i915/intel_dp.c:1527:5: warning: > symbol 'intel_dp_compute_bpp' was not declared. Should it be static? > > Signed-off-by: Wei Yongjun > --- > drivers/gpu/drm/i915/intel_dp.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 69cee9b..acd0c51 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1524,8 +1524,8 @@ void intel_dp_compute_rate(struct intel_dp *intel_dp, > int port_clock, > } > } > > -int intel_dp_compute_bpp(struct intel_dp *intel_dp, > - struct intel_crtc_state *pipe_config) > +static int intel_dp_compute_bpp(struct intel_dp *intel_dp, > + struct intel_crtc_state *pipe_config) Already fixed upstream. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/psr:Adds Y-cordinate to skl_psr_setup_vsc
On Friday 12 August 2016 12:02 PM, Ville Syrjälä wrote:
On 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
Signed-off-by: vathsala nagaraju
---
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.
+ 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;
+ }
That looks bogus. Why do we claim to have colorimetry data but
then don't fill it out?
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.
Also you're not setting the actual y coordinate stuff anywhere, so why
would we want to indicate that we support it?
Bspec says to set CHICKEN_TRANS_EDP(0x420cc) bit 15 if Y coordinate is
supported.
it set in patch 2.
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.
This means bit 12 must be enabl
[Intel-gfx] [Regression report] Weekly regression report WW38
This week's new regressions: +---+---+++ | BugId | Summary | Created on | Bisect | +---+---+++ | 97824 | [BDW BYT] [Regression] pm_rps / reset fails | 2016-09-15 | No | | 97820 | [BDW BYT] [Regression] [GPU Hang] with gem_re | 2016-09-15 | No | +---+---+++ Previous Regressions: +---+---+++ | BugId | Summary | Created on | Bisect | +---+---+++ | 90112 | [BSW bisected] OglGSCloth/Lightsmark/CS/ Port | 2015-04-20 | Yes| | 94590 | [KBL/BXT] igt/kms_fbcon_fbt/psr-suspend regre | 2016-03-17 | No | | 97215 | [KBL] [Regression] pm_rps / reset fails | 2016-08-05 | No | | 93263 | 945GM regression since 4.3| 2015-12-05 | No | | 72782 | [945GM bisected] screen blank on S3 resume on | 2013-12-17 | Yes| | 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will | 2015-10-10 | Yes| | 92050 | [regression]/bug introduced by commit [0e572f | 2015-09-19 | No | | 93393 | Regression for Skylake modesetting in kernel | 2015-12-16 | No | | 93802 | [IVB bisected] switching to tty1 causes fifo | 2016-01-20 | Yes| | 95197 | [i915] regression in 4.6-rc5: GPU HANG: ecode | 2016-04-28 | No | | 94587 | [KBL] igt/kms_plane/plane-panning-bottom-righ | 2016-03-17 | No | | 96800 | [regression] The drm-intel-nightly branch no | 2016-07-04 | No | | 95736 | [IVB bisected] *ERROR* uncleared fifo underru | 2016-05-24 | Yes| | 89728 | [HSW/BDW/BYT bisected] igt / pm_rps / reset f | 2015-03-23 | Yes| | 89629 | [i965 regression]igt/kms_rotation_crc/sprite- | 2015-03-18 | No | | 92502 | [SKL] [Regression] igt/kms_flip/2x-flip-vs-ex | 2015-10-16 | No | | 96938 | [HSW modeset regression] i915/drm locks up wh | 2016-07-15 | No | | 87131 | [PNV regression] igt/gem_exec_lut_handle take | 2014-12-09 | No | | 87726 | [BDW Bisected] OglDrvCtx performance reduced | 2014-12-26 | Yes| | 91974 | [bisected] unrecoverable black screen after k | 2015-09-11 | Yes| | 96645 | [regression 4.7] [BISECT]Low package c-states | 2016-06-22 | Yes| | 94430 | [HSW+nvidia] regression: display becomes "dis | 2016-03-07 | No | | 97295 | Regression backlight control broken on Dell X | 2016-08-11 | No | | 97573 | [IVB/SNB/BYT/HSW/BDW] GuC boot kernel command | 2016-09-02 | No | | 97596 | [SKL] [regression] Flickering artefact window | 2016-09-05 | No | | 93971 | video framerate performance regression with U | 2016-02-02 | No | | 89872 | [ HSW Bisected ] VGA was white screen when re | 2015-04-02 | Yes| | 96428 | [IVB bisected] [drm:intel_dp_aux_ch] *ERROR* | 2016-06-07 | Yes| | 91959 | [865g Linux regression] GPU hang and disabled | 2015-09-10 | No | | 95097 | [hdmi regression ilk] no signal to TV | 2016-04-24 | No | | 94748 | Black screen on Skylake (mouse position relat | 2016-03-29 | No | | 97216 | [KBL] [Regression] pm_rps / min-max-config-lo | 2016-08-05 | No | | 97450 | [SKL] [regression] Random display flickering | 2016-08-23 | No | | 92972 | Black screen on Intel NUC hardware (i915) pos | 2015-11-16 | No | | 87725 | [BDW Bisected] OglBatch7 performance reduced | 2014-12-26 | Yes| | 94676 | Possible kernel regression for gen3 and earli | 2016-03-23 | No | | 94337 | Linux 4.5 regression: FIFO underruns on Skyla | 2016-02-29 | No | | 97017 | [SKL GT3e guc bisected] ~10% performance drop | 2016-07-21 | Yes| | 96916 | Regression: screen flashes with PSR enabled | 2016-07-13 | No | | 90368 | [SNB BSW SKL BXT KBL] bisected igt/kms_3d has | 2015-05-08 | Yes| | 94588 | [IVB/KBL/BSW/BXT/BDW] igt/gem_reloc_overflow | 2016-03-17 | No | | 96736 | kernel 4.6 regression: PSR causes screen to f | 2016-06-29 | No | | 90134 | [BSW Bisected]GFXBench3_gl_driver/GFXBench3_g | 2015-04-22 | Yes| | 96704 | kernel 4.6 regression: PSR on Haswell causes | 2016-06-28 | No | | 93782 | [i9xx TV][BISECT] vblank wait timeout on crtc | 2016-01-19 | Yes| | 89632 | [i965 regression]igt/kms_universal_plane/univ | 2015-03-18 | No | | 92237 | [SNB]Horrible noise (audio) via DisplayPort [ | 2015-10-02 | No | +---+---+++ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3
Hi! James & Paulo: What's the current status of this? Was this issue discussed elsewhere or even fixed in between? Just asking, because this issue is on the list of regressions for 4.8. Ciao, Thorsten On 01.09.2016 00:25, James Bottomley wrote: > On Wed, 2016-08-31 at 21:51 +, Zanoni, Paulo R wrote: >> Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu: >>> On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote: On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote: > We seem to have an xrandr regression with skylake now. What's > happening is that I can get output on to a projector, but the > system is losing video when I change the xrandr sessions (like > going from a --above b to a --same-as b). The main screen goes > blank, which is basically a reboot situation. Unfortunately, I > can't seem to get the logs out of systemd to see if there was a > dump to dmesg (the system was definitely responding). > > I fell back to 4.6.2 which worked perfectly, so this is > definitely > some sort of regression. I'll be able to debug more fully when > I > get back home from the Linux Security Summit. I'm home now. Unfortunately, my monitor isn't as problematic as the projector, but by flipping between various modes and separating and overlaying the panels with --above and --same-as (xrandr), I can eventually get it to the point where the main LCD panel goes black and can only be restarted by specifying a different mode. This seems to be associated with these lines in the X [ 14714.389] (EE) intel(0): failed to set mode: Invalid argument [22] But the curious thing is that even if this fails with the error message once, it may succeed a second time, so it looks to be a transient error translation problem from the kernel driver. I've attached the full log below. This is only with a VGA output. I currently don't have a HDMI dongle, but I'm in the process of acquiring one. >>> >>> After more playing around, I'm getting thousands of these in the >>> kernel >>> log (possibly millions: the log wraps very fast): >>> >>> [23504.873606] [drm:intel_dp_start_link_train [i915]] *ERROR* >>> failed >>> to train DP, aborting >>> >>> And then finally it gives up with >>> >>> [25023.770951] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] >>> *ERROR* CPU pipe B FIFO underrun >>> [25561.926075] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] >>> *ERROR* CPU pipe A FIFO underrun >>> >>> And the crtc for the VGA output becomes non-responsive to any >>> configuration command. This requires a reboot and sometimes a UEFI >>> variable reset before it comes back. >> >> Please see this discussion: >> https://patchwork.freedesktop.org/patch/103237/ >> >> Do you have this patch on your tree? Does the problem go away if you >> revert it? > > Yes, I've got it, it went in in 4.8-rc3 according to git: > > commit 58e311b09c319183254d9220c50a533e7157c9ab > Author: Matt Roper > Date: Thu Aug 4 14:08:00 2016 -0700 > > drm/i915/gen9: Give one extra block per line for SKL plane WM > calculations > > Reverting it causes the secondary display not to sync pretty much at > all. However, in the flickers I can see, it does work OK and doesn't > now crash switching from --same-as to --above and back > > I also still get the logs filling up with the link training errors. > > On balance, although the behaviour is different, it's not an > improvement because if I can't sync with the projector, I can't really > use this as a fix. > > James ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
