Re: [Intel-gfx] [PATCH v2 00/14] YCBCR 4:2:0 handling in DRM layer
Regards Shashank On 7/15/2017 12:32 AM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 09:03:06PM +0530, Shashank Sharma wrote: Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format, which is currently supported on HDMI 2.0 sources/sinks. Due to lower chroma sub-sampling rate, YCBCR 4:2:0 can drive the video modes at half the pixel clock than YCBCR 4:4:4 or RGB 8:8:8 outputs. For example, a CEA 4K@60, RGB 8:8:8 mode needs a clock of appx 594Mhz, but it can be driven at 297Mhz using YCBCR 4:2:0 output. Of course, the lower rate of chroma subsampling, causes the quality of YCBCR 4:2:0 to be lower than YCBCR 4:4:4 or RGB 8:8:8. This patch series adds support for YCBCR 4:2:0 output in DRM layer. - First 2 patches, complete the CEA mode-db in drm driver, by adding new 4k modes. Current CEA mode-db contains 64 modes only (VIC 1-64), whereas CEA-861-F defined VICs up to 107, including 4k modes, from VIC range 93-107. First patch makes sure that inclusion of these modes doesn't break existing HDMI 1.4 monitors, across various drivers. - Next 5 patches focus on parsing new YCBCR 4:2:0 EDID blocks, and adding YCBCR 4:2:0 modes in connector. They also contain a prune function, which will cleanup the YCBCR 4:2:0 modes from list, if the connector doesn't declare them supported. - Next 2 patches add helper functions for identifing YCBCR 4:2:0 modes and setup the color space in AVI infoframes. - Next 6 patches add code for I915 layer handling of YCBCR 4:2:0 output. This patch series was initially published as a complete framework to handle all YCBCR outputs (4:4:4, 4:2:2, 4:2:0), but based on the code reviews, now its been published as YCBCR 4:2:0 handling series only. The previous discussion and reviews can be found here: V5: https://patchwork.freedesktop.org/series/26815/ V1-V4: https://patchwork.freedesktop.org/series/22683/ Now re-publishing this patch series as YCBCR 4:2:0 handling series here. V2: Addressed review comments from Ville This series dropped one patch in V2(patch 8 from V1), so 14 patches in V2 This series has been tested with drm-tip code with following setup: Source: Intel Geminilake device. Sink: ACER S277HK HDMI 2.0 monitor. Protocol testing: Astro VA-1844A HDMI analyzer. Shashank Sharma (14): drm: handle HDMI 2.0 VICs in AVI info-frames drm/edid: complete CEA modedb(VIC 1-107) drm/edid: parse sink information before CEA blocks drm/edid: cleanup patch for CEA extended-tag macro drm: add helper to validate YCBCR420 modes drm/edid: parse YCBCR420 videomodes from EDID drm/edid: parse ycbcr 420 deep color information drm: add helper functions for YCBCR420 handling I just finished pushing the core bits into drm-misc-next. But I'm not super happy how that went because there were still quite a few trivial checkpatch warnings and indentation issues I had to fix up. All of that should have been dealt with before even submitting the patches to the list. Review bandwidth is a scarce resource so we don't want to squander it on this sort of stuff. The whole patch series was checked with checkpatch every time it was sent for review. It had only 1 checkpatch warning, for which I had added an explanation in patch's header like: For patch 1: PS: This patch touches a few lines in few files, which were already above 80 char, so checkpatch gives 80 char warning again. - gpu/drm/omapdrm/omap_encoder.c - gpu/drm/i915/intel_sdvo.c Apart from this, here is the checkpatch output: ../scripts/checkpatch.pl *.patch - v8-0001-drm-handle-HDMI-2.0-VICs-in-AVI-info-frames.patch - WARNING: line over 80 characters #278: FILE: drivers/gpu/drm/i915/intel_sdvo.c:999: + &pipe_config->base.adjusted_mode, WARNING: line over 80 characters #332: FILE: drivers/gpu/drm/omapdrm/omap_encoder.c:88: + r = drm_hdmi_avi_infoframe_from_display_mode(&avi, adjusted_mode, total: 0 errors, 2 warnings, 247 lines checked v8-0001-drm-handle-HDMI-2.0-VICs-in-AVI-info-frames.patch has style problems, please review. v8-0002-drm-edid-complete-CEA-modedb-VIC-1-107.patch total: 0 errors, 0 warnings, 245 lines checked v8-0002-drm-edid-complete-CEA-modedb-VIC-1-107.patch has no obvious style problems and is ready for submission. --- v8-0003-drm-edid-parse-sink-information-before-CEA-blocks.patch --- total: 0 errors, 0 warnings, 21 lines checked v8-0003-drm-edid-parse-sink-information-before-CEA-blocks.patch has no obvious style problems and is ready for submission. --- v8-0004-drm-edid-cleanup-patch-for-CEA-extended-tag-macro.patch ---
Re: [Intel-gfx] [PATCH v2 12/14] drm/i915: prepare csc unit for YCBCR420 output
Regards
Shashank
On 7/15/2017 12:06 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:18PM +0530, Shashank Sharma wrote:
To support ycbcr output, we need a pipe CSC block to do
RGB->YCBCR conversion.
Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.
This function adds a csc handler, which uses recommended bspec
values to perform RGB->YCBCR conversion (target color space BT709)
V2: Rebase
V3: Rebase
V4: Rebase
V5: Addressed review comments from Ander
- Remove extra line added in the patch
- Add the spec details in the commit message
- Combine two if(cond) while calling intel_crtc_compute_config
V6: Handle YCBCR420 outputs only (Ville)
V7: Addressed review comments from Ville:
- Add description about target colorspace
- Remove the comments from CSC function
- DRM_DEBUG->DEBUG_KMS for atomic failure due to CSC unit busy
- Remove unnecessary debug message about YCBCR420 possibe
Cc: Ville Syrjala
Cc: Daniel Vetter
Cc: Ander Conselvan de Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_color.c | 46 +++-
drivers/gpu/drm/i915/intel_display.c | 15
2 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index f85d575..8698691 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,22 @@
#define LEGACY_LUT_LENGTH (sizeof(struct drm_color_lut) * 256)
+/* Post offset values for RGB->YCBCR conversion */
+#define POSTOFF_RGB_TO_YUV_HI 0x800
+#define POSTOFF_RGB_TO_YUV_ME 0x100
+#define POSTOFF_RGB_TO_YUV_LO 0x800
+
+/*
+ * These values are direct register values specified in the Bspec,
+ * for RGB->YUV conversion matrix (colorspace BT709)
+ */
+#define CSC_RGB_TO_YUV_RU_GU 0x2ba809d8
+#define CSC_RGB_TO_YUV_BU 0x37e8
+#define CSC_RGB_TO_YUV_RY_GY 0x1e089cc0
+#define CSC_RGB_TO_YUV_BY 0xb528
+#define CSC_RGB_TO_YUV_RV_GV 0xbce89ad8
+#define CSC_RGB_TO_YUV_BV 0x1e08
+
/*
* Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
* format). This macro takes the coefficient we want transformed and the
@@ -91,6 +107,31 @@ static void ctm_mult_by_limited(uint64_t *result, int64_t
*input)
}
}
+void i9xx_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
+{
+ int pipe = intel_crtc->pipe;
+ struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+
+
+ I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+ I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+ I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+ I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), CSC_RGB_TO_YUV_RU_GU);
+ I915_WRITE(PIPE_CSC_COEFF_BU(pipe), CSC_RGB_TO_YUV_BU);
+
+ I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), CSC_RGB_TO_YUV_RY_GY);
+ I915_WRITE(PIPE_CSC_COEFF_BY(pipe), CSC_RGB_TO_YUV_BY);
+
+ I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), CSC_RGB_TO_YUV_RV_GV);
+ I915_WRITE(PIPE_CSC_COEFF_BV(pipe), CSC_RGB_TO_YUV_BV);
+
+ I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
+ I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
+ I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
+ I915_WRITE(PIPE_CSC_MODE(pipe), 0);
+}
+
/* Set up the pipe CSC unit. */
static void i9xx_load_csc_matrix(struct drm_crtc_state *crtc_state)
{
@@ -101,7 +142,10 @@ static void i9xx_load_csc_matrix(struct drm_crtc_state
*crtc_state)
uint16_t coeffs[9] = { 0, };
struct intel_crtc_state *intel_crtc_state =
to_intel_crtc_state(crtc_state);
- if (crtc_state->ctm) {
+ if (intel_crtc_state->ycbcr420) {
+ i9xx_load_ycbcr_conversion_matrix(intel_crtc);
+ return;
+ } else if (crtc_state->ctm) {
struct drm_color_ctm *ctm =
(struct drm_color_ctm *)crtc_state->ctm->data;
uint64_t input[9] = { 0, };
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1a23ec0..9c6a1ed 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6283,6 +6283,21 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
return -EINVAL;
}
+ /* YCBCR420 feasibility check */
Not a useful comment.
Got it.
+ if (pipe_config->ycbcr420) {
+ struct drm_crtc_state *drm_state = &pipe_config->base;
Having aliasing pointer for the same thing is just annoying.
We do have quite a lot of that going around, but IMO we need
to clean that all up at some point.
So pls just do this instead:
if (pipe_config->ycbcr420 && pipe_config->base.ctm) {
...
}
Most of the time its done to cover for 80 char limit, and to make code
look good.
but let me see if I can accommodate this one.
Re: [Intel-gfx] [PATCH v2 11/14] drm/i915: prepare pipe for YCBCR420 output
Regards
Shashank
On 7/15/2017 12:03 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:17PM +0530, Shashank Sharma wrote:
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC for YCBCR420 outputs.
V2: rebase
V3: rebase
V4: rebase
V5: added r-b from Ander
V6: Handle only YCBCR420 outputs (ville)
V7: rebase
Cc: Ville Syrjala
Cc: Ander Conselvan de Oliveira
Cc: Daniel Vetter
Reviewed-by: Ander Conselvan de Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_display.c | 7 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c712d01..e5020d6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5227,6 +5227,9 @@ enum {
#define _PIPE_MISC_A 0x70030
#define _PIPE_MISC_B 0x71030
+#define PIPEMISC_YCBCR420_ENABLE (1<<27)
+#define PIPEMISC_YCBCR420_MODE_BLEND (1<<26)
+#define PIPEMISC_OUTPUT_YCBCR(1<<11)
Please rename to match spec. So something like:
PIPEMISC_YUV420_ENABLE (1<<27)
PIPEMISC_YUV420_MODE_FULL_BLEND (1<<26)
PIPEMISC_OUTPUT_COLORSPACE_YUV (1<<11)
got it.
#define PIPEMISC_DITHER_BPC_MASK(7<<5)
#define PIPEMISC_DITHER_8_BPC (0<<5)
#define PIPEMISC_DITHER_10_BPC (1<<5)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d78f1c2..1a23ec0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8076,6 +8076,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc_state *config = intel_crtc->config;
if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
u32 val = 0;
@@ -8101,6 +8102,12 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
if (intel_crtc->config->dither)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
+ if (config->ycbcr420) {
+ val |= PIPEMISC_OUTPUT_YCBCR |
+ PIPEMISC_YCBCR420_ENABLE |
+ PIPEMISC_YCBCR420_MODE_BLEND;
+ }
I think we'll want two flags. One to specify whether we're outputting
YCbCr and the other to indicate whether we need the 4:2:0 subsamling.
So maybe something like
bool ycbcr;
bool ycbcr420;
This would have been true if we were support YCBCR444/422/420 all, but
the recent patch series only
supports 420, so if its ycbcr its ycbcr420. We might be able to add
preference of a 420_also mode in case
of RGB Vs YCBCR420, by adding another property.
We also need state readout for this stuff. With those two flags I think
we can do something like:
if (IS_BDW || GEN >= 9) {
tmp = READ(PIPEMISC);
crtc_state->ycbcr = tmp & OUTPUT_YUV;
We dont support YCBCR (apart from 420) anymore, as there is no HDMI
output property.
So this doesn't look required.
if (IS_GLK || GEN >= 10)
crtc_state->ycbcr420 = tmp & YUV420_ENABLE;
Yes, this is a great suggestion, and I believe I was missing this. Thanks !
}
The other missing readout thing is adjustment of the clock.
ddi_dotclock_get() will need to double the dotclock when we're
outputting ycbcr420.
Pls also add something along the lines of
DRM_DEBUG_KMS("ycbcr: %i, ycbcr420: %i\n", ...);
to intel_dump_pipe_config() so that we can actually tell when we're
outputting YCbCr and 4:2:0.
Thanks, this is also what I was looking for.
- Shashank
+
I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
}
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 10/14] drm/i915: prepare scaler for YCBCR420 modeset
Regards
Shahank
On 7/15/2017 12:00 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:16PM +0530, Shashank Sharma wrote:
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
scaler framework. This output type is identified using bit
30 of the scaler users bitmap.
V2: rebase
V3: rebase
V4: rebase
V5: addressed review comments from Ander:
- No need to check both scaler_user && hdmi_output.
Check for scaler_user is enough.
V6: rebase
V7: Do not create a new scaler user, use existing pipe scaler user.
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
drivers/gpu/drm/i915/intel_drv.h | 4 +++-
drivers/gpu/drm/i915/intel_hdmi.c| 12
drivers/gpu/drm/i915/intel_panel.c | 3 ++-
4 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a5140e4..d78f1c2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4624,6 +4624,9 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
*/
need_scaling = src_w != dst_w || src_h != dst_h;
+ if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
+ need_scaling = true;
+
/*
* Scaling/fitting not supported in IF-ID mode in GEN9+
* TODO: Interlace fetch mode doesn't support YUV420 planar formats.
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 592243b..94ea6ed 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -471,7 +471,8 @@ struct intel_crtc_scaler_state {
*
* If a bit is set, a user is using a scaler.
* Here user can be a plane or crtc as defined below:
-* bits 0-30 - plane (bit position is index from drm_plane_index)
+* bits 0-29 - plane (bit position is index from drm_plane_index)
+* bit 30- hdmi output
That's no longer true.
Agree !
* bit 31- crtc
*
* Instead of creating a new index to cover planes and crtc, using
@@ -484,6 +485,7 @@ struct intel_crtc_scaler_state {
* avilability.
*/
#define SKL_CRTC_INDEX 31
+
Bogus whitespace change.
Got it.
unsigned scaler_users;
/* scaler used by crtc for panel fitting purpose */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index eb6243c..49f4fb8 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1356,6 +1356,7 @@ intel_hdmi_ycbcr420_config(struct drm_connector
*connector,
struct intel_crtc_state *config,
int *clock_12bpc, int *clock_8bpc)
{
+ struct intel_crtc *intel_crtc = to_intel_crtc(config->base.crtc);
if (!connector->ycbcr_420_allowed) {
DRM_ERROR("Platform doesn't support YCBCR420 output\n");
@@ -1367,6 +1368,17 @@ intel_hdmi_ycbcr420_config(struct drm_connector
*connector,
*clock_12bpc /= 2;
*clock_8bpc /= 2;
config->ycbcr420 = true;
+
+ /* YCBCR 420 output conversion needs a scaler */
+ if (skl_update_scaler_crtc(config)) {
+ DRM_ERROR("Scaler allocation for output failed\n");
DRM_DEBUG_KMS
Ok,
+ return false;
+ }
+
+ /* Bind this scaler to pipe */
Unnecesary comment.
Ok,
Shashank
+ intel_pch_panel_fitting(intel_crtc, config,
+ DRM_MODE_SCALE_FULLSCREEN);
+
return true;
}
diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c
index 96c2cbd..fd2e081 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -110,7 +110,8 @@ intel_pch_panel_fitting(struct intel_crtc *intel_crtc,
/* Native modes don't need fitting */
if (adjusted_mode->crtc_hdisplay == pipe_config->pipe_src_w &&
- adjusted_mode->crtc_vdisplay == pipe_config->pipe_src_h)
+ adjusted_mode->crtc_vdisplay == pipe_config->pipe_src_h &&
+ !pipe_config->ycbcr420)
goto done;
switch (fitting_mode) {
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 09/14] drm/i915: add config function for YCBCR420 outputs
Regards
Shashank
On 7/15/2017 12:00 AM, Ville Syrjälä wrote:
On Thu, Jul 13, 2017 at 09:03:15PM +0530, Shashank Sharma wrote:
This patch checks encoder level support for YCBCR420 outputs.
The logic goes as simple as this:
If the input mode is YCBCR420-only mode: prepare HDMI for
YCBCR420 output, else continue with RGB output mode.
It checks if the mode is YCBCR420 and source can support this
output then it marks the ycbcr_420 output indicator into crtc
state, for further staging in driver.
V2: Split the patch into two, kept helper functions in DRM layer.
V3: Changed the compute_config function based on new DRM API.
V4: Rebase
V5: Rebase
V6: Check and handle YCBCR420-only modes, discard the property
based approach (Ville)
V7: Addressed review comments from Ville
- add else case in 12BPC check.
- extract ycbcr420 state inside hdmi_12bpc_possible function.
Cc: Ville Syrjala
Cc: Daniel Vetter
Cc: Ander Conselvan de Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 3 +++
drivers/gpu/drm/i915/intel_hdmi.c| 43 +---
3 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2144adc..a5140e4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11945,6 +11945,7 @@ intel_pipe_config_compare(struct drm_i915_private
*dev_priv,
PIPE_CONF_CHECK_I(hdmi_scrambling);
PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
PIPE_CONF_CHECK_I(has_infoframe);
+ PIPE_CONF_CHECK_I(ycbcr420);
PIPE_CONF_CHECK_I(has_audio);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d17a324..592243b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -780,6 +780,9 @@ struct intel_crtc_state {
/* HDMI High TMDS char rate ratio */
bool hdmi_high_tmds_clock_ratio;
+
+ /* HDMI output type */
We'll want DP too at some point. So that's going to get stale pretty
soon.
Agree, will make it output format ycbcr420
+ bool ycbcr420;
};
struct intel_crtc {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index cc0d100..eb6243c 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1312,6 +1312,7 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state
*crtc_state)
struct drm_atomic_state *state = crtc_state->base.state;
struct drm_connector_state *connector_state;
struct drm_connector *connector;
+ bool output_ycbcr420 = crtc_state->ycbcr420;
Pointless variable. Just use 'crtc_state->ycbcr420' in the code
directly.
Ah, yes it was used at more places before we removed some of the code,
during review.
Sure, will use that directly.
int i;
if (HAS_GMCH_DISPLAY(dev_priv))
@@ -1330,8 +1331,16 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state
*crtc_state)
if (connector_state->crtc != crtc_state->base.crtc)
continue;
- if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 0)
- return false;
+ if (output_ycbcr420) {
+ const struct drm_hdmi_info *hdmi = &info->hdmi;
+
+ if (!(hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36))
+ return false;
+ } else {
+
Bogus whitespace.
Got it.
+ if (!(info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36))
+ return false;
+ }
}
/* Display Wa #1139 */
@@ -1342,6 +1351,25 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state
*crtc_state)
return true;
}
+static bool
+intel_hdmi_ycbcr420_config(struct drm_connector *connector,
+ struct intel_crtc_state *config,
+ int *clock_12bpc, int *clock_8bpc)
+{
+
Bogus whitespace.
Got it.
- Shashank
+ if (!connector->ycbcr_420_allowed) {
+ DRM_ERROR("Platform doesn't support YCBCR420 output\n");
+ return false;
+ }
+
+ /* YCBCR420 TMDS rate requirement is half the pixel clock */
+ config->port_clock /= 2;
+ *clock_12bpc /= 2;
+ *clock_8bpc /= 2;
+ config->ycbcr420 = true;
+ return true;
+}
+
bool intel_hdmi_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
@@ -1349,7 +1377,8 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_display_mode
[Intel-gfx] [PATCH] drm/i915: Consistently use enum pipe for PCH transcoders
The current code uses two different enum types for PCH transcoders and
performs implicit conversions between the two types. This is error prone
and causes clang to raise warnings like this:
drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion
from enumeration type 'enum pipe' to different enumeration type
'enum transcoder' [-Wenum-conversion]
intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
Consistently use the type enum pipe for PCH transcoders.
Signed-off-by: Matthias Kaehlcke
---
drivers/gpu/drm/i915/i915_irq.c| 10 +-
drivers/gpu/drm/i915/intel_display.c | 24 ++--
drivers/gpu/drm/i915/intel_drv.h | 6 +++---
drivers/gpu/drm/i915/intel_fifo_underrun.c | 6 +++---
4 files changed, 21 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 190f6aa5d15e..7960d2170750 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2132,10 +2132,10 @@ static void ibx_irq_handler(struct drm_i915_private
*dev_priv, u32 pch_iir)
DRM_DEBUG_DRIVER("PCH transcoder CRC error interrupt\n");
if (pch_iir & SDE_TRANSA_FIFO_UNDER)
- intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
+ intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
if (pch_iir & SDE_TRANSB_FIFO_UNDER)
- intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
+ intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
}
static void ivb_err_int_handler(struct drm_i915_private *dev_priv)
@@ -2169,13 +2169,13 @@ static void cpt_serr_int_handler(struct
drm_i915_private *dev_priv)
DRM_ERROR("PCH poison interrupt\n");
if (serr_int & SERR_INT_TRANS_A_FIFO_UNDERRUN)
- intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_A);
+ intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_A);
if (serr_int & SERR_INT_TRANS_B_FIFO_UNDERRUN)
- intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_B);
+ intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_B);
if (serr_int & SERR_INT_TRANS_C_FIFO_UNDERRUN)
- intel_pch_fifo_underrun_irq_handler(dev_priv, TRANSCODER_C);
+ intel_pch_fifo_underrun_irq_handler(dev_priv, PIPE_C);
I915_WRITE(SERR_INT, serr_int);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9106ea32b048..21a8fea46ad9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1782,7 +1782,7 @@ static void lpt_enable_pch_transcoder(struct
drm_i915_private *dev_priv,
/* FDI must be feeding us bits for PCH ports */
assert_fdi_tx_enabled(dev_priv, (enum pipe) cpu_transcoder);
- assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
+ assert_fdi_rx_enabled(dev_priv, PIPE_A);
/* Workaround: set timing override bit. */
val = I915_READ(TRANS_CHICKEN2(PIPE_A));
@@ -1858,16 +1858,16 @@ void lpt_disable_pch_transcoder(struct drm_i915_private
*dev_priv)
I915_WRITE(TRANS_CHICKEN2(PIPE_A), val);
}
-enum transcoder intel_crtc_pch_transcoder(struct intel_crtc *crtc)
+enum pipe intel_crtc_pch_transcoder(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
WARN_ON(!crtc->config->has_pch_encoder);
if (HAS_PCH_LPT(dev_priv))
- return TRANSCODER_A;
+ return PIPE_A;
else
- return (enum transcoder) crtc->pipe;
+ return crtc->pipe;
}
/**
@@ -1906,7 +1906,7 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
if (crtc->config->has_pch_encoder) {
/* if driving the PCH, we need FDI enabled */
assert_fdi_rx_pll_enabled(dev_priv,
- (enum pipe)
intel_crtc_pch_transcoder(crtc));
+
intel_crtc_pch_transcoder(crtc));
assert_fdi_tx_pll_enabled(dev_priv,
(enum pipe) cpu_transcoder);
}
@@ -4573,7 +4573,7 @@ static void lpt_pch_enable(const struct intel_crtc_state
*crtc_state)
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
- assert_pch_transcoder_disabled(dev_priv, TRANSCODER_A);
+ assert_pch_transcoder_disabled(dev_priv, PIPE_A);
lpt_program_iclkip(crtc);
@@ -5329,8 +5329,7 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
return;
if (intel_crtc->config->has_pch_encoder)
- intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
-
Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches
El Fri, Jul 14, 2017 at 03:43:35PM -0700 Grant Grundler ha dit: > On Fri, Jul 14, 2017 at 2:35 PM, Daniel Vetter wrote: > > On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler > > wrote: > >> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula > >> wrote: > >>> On Thu, 13 Jul 2017, Stéphane Marchesin > >>> wrote: > So, if you think this is wrong, can you fix this warning in a way that > you'd like? > >>> > >>> As I replied previously [1], with more background, fixing the warnings > >>> properly, in a way that actually improves the code instead of making it > >>> worse, would mean a bunch of churn that's not just purely mechanical > >>> conversion. > >> > >> That's fair. > >> > >>> Unless you can point out a bug which is actually caused by mixing the > >>> types (which is mostly intentional, see the background) I have a hard > >>> time telling people this should be a priority. > >> > >> This feels like "can't see the forest because of the trees". > >> > >> The original patch was submitted in order to compile cleanly using > >> clang and the above suggests using clang is not important. Using > >> clang is important to Matthias and the Chrome OS organization for many > >> good reasons - including better warnings. > >> > >> The original patch message was clear that clang was generating the > >> warning. This isn't the only patch mka has sent to kernel devs. What > >> one can infer is Chrome OS is trying to move to clang (like other > >> Google products _already_ have.) My impression is all these products > >> are a priority to Intel - but it would be good to know otherwise. > >> > >>> Definitely something we'd > >>> like to do in the long run and pedantically correct (and I tend to > >>> prefer code that way) but we certainly have more important things to do. > >> > >> The long run is now. Everyone agrees the code should change and you > >> don't have to do it. Matthias submitted an unacceptable patch and > >> giving him some concrete guidance on what would be acceptable would > >> enable him to implement/test it (or anyone else could for that > >> matter). Can you do that? > >> > >> Just give an example of what the "right" API looks like and see where it > >> goes. > > > > We've replied and discussed on May 5th what that roughly should be, > > right when Matthias pinged us. The original submission unfortunately > > fell through the cracks (it happens, not much we can do with this > > flood). Matthias didn't seem to have any questions about the proposed > > solutions (we laid out both the minimal short-term fix to unconfuse > > things, and what might be done on top), I think a reasonable > > assumption was that it's all clear. Otherwise he should have asked. > > Indeed! > > After briefly chatting with Stephane and mka, it seems the difference > between short-term fix and "done on top" were not clear. > > > Now, over 2 months later (and complete silence from your side) there's > > suddenly mass panic and multiple escalations on all available > > channels, which feels like a rather decent overreaction and not a > > terrible constructive way to collaborate on the upstream codebase. > > I'm sorry - I'm not on the other channels and I didn't see any mass > panic. I agree that's not a collaborative. The previous answer in this > thread didn't seem particularly collaborative either though. > > The silence was partly due to mka working on other "clang enablement" patches: Yes, sorry for the silence :( With my lack of expertise with this driver and graphics in general I wasn't sure if I'd take up the "done on top" solution and shifted my attention to other clang related issues. > $ pwclient list -w m...@chromium.org > Patches submitted by Matthias Kaehlcke : > ID StateName > -- - > 9668095 Superseded mac80211: Fix clang warning about constant > operand in logical operation > 9668479 Accepted ath9k: Add cast to u8 to FREQ2FBIN macro > 9668643 Accepted [v2] mac80211: Fix clang warning about constant > operand in logical operation > 9679753 Accepted [v2] cfg80211: Fix array-bounds warning in fragment copy > 9684547 Accepted mac80211: ibss: Fix channel type enum in > ieee80211_sta_join_ibss() > 9684629 Accepted nl80211: Fix enum type of variable in > nl80211_put_sta_rate() > > > Anyway, I've done the quick draft for the function declaration changes > > that would clear up the confusion, just needs a clang run to update > > all the parameters to match, and passed that on to Stéphane Marchesin. Thanks, that is helpful! > Awesome - thanks! :) > > > I expect you to follow up with the corresponding patch right away. > > mka said "he would take a look at it". But knowing how he understates > things in a typical "German Engineer" way, I'm optimistic it will be > more than that. Thanks! > > cheers, > grant > > > > > Thanks a lot. > > > > Yours, Daniel > > > > For reference the diff, but probably whitespace mangled because the > > real machine is down
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Implement .get_format_info() hook for CCS
FYI: The latest version of the CCS modifier patches for mesa are now
reviewed:
https://patchwork.freedesktop.org/series/27213/
I'll be landing the prep-work patches soon. The final couple of patches
are just waiting on the I915_FORMAT_MOD_Y_TILED_CCS in drm_fourcc.h to land
in the kernel.
On Sun, Jul 9, 2017 at 11:53 PM, Vidya Srinivas
wrote:
> From: Ville Syrjälä
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display engine
> the location of the color control surfae (CCS) which describes which
> parts of the main surface are compressed and which are not. The location
> of CCS is provided by userspace as just another plane with its own offset.
>
> By providing our own format information for the CCS formats, we should
> be able to make framebuffer_check() do the right thing for the CCS
> surface as well.
>
> Note that we'll return the same format info for both Y and Yf tiled
> format as that's what happens with the non-CCS Y vs. Yf as well. If
> desired, we could potentially return a unique pointer for each
> pixel_format+tiling+ccs combination, in which case we immediately be
> able to tell if any of that stuff changed by just comparing the
> pointers. But that does sound a bit wasteful space wise.
>
> v2: Drop the 'dev' argument from the hook
> v3: Include the description of the CCS surface layout
> v4: Pretend CCS tiles are regular 128 byte wide Y tiles (Jason)
>
> Cc: Daniel Vetter
> Cc: Ben Widawsky
> Cc: Jason Ekstrand
> Reviewed-by: Ben Widawsky (v3)
> Signed-off-by: Ville Syrjä
> ---
> drivers/gpu/drm/drm_fourcc.c | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 37 ++
> ++
> include/drm/drm_mode_config.h| 3 ++-
> include/uapi/drm/drm_fourcc.h| 3 +++
> 4 files changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 9c0152d..50da618 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -222,7 +222,7 @@ const struct drm_format_info *drm_format_info(u32
> format)
> const struct drm_format_info *info = NULL;
>
> if (dev->mode_config.funcs->get_format_info)
> - info = dev->mode_config.funcs->get_format_info(mode_cmd);
> + info = dev->mode_config.funcs->get_format_info(dev,
> mode_cmd);
>
> if (!info)
> info = drm_format_info(mode_cmd->pixel_format);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2144adc..9fb2f37 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2433,6 +2433,42 @@ static unsigned int
> intel_fb_modifier_to_tiling(uint64_t
> fb_modifier)
> }
> }
>
> +static const struct drm_format_info ccs_formats[] = {
> + { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
> .cpp = { 4, 1, }, .hsub = 16, .vsub = 8, },
> + { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
> .cpp = { 4, 1, }, .hsub = 16, .vsub = 8, },
> + { .format = DRM_FORMAT_ARGB, .depth = 32, .num_planes = 2,
> .cpp = { 4, 1, }, .hsub = 16, .vsub = 8, },
> + { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2,
> .cpp = { 4, 1, }, .hsub = 16, .vsub = 8, },
> +};
> +
> +static const struct drm_format_info *
> +lookup_format_info(const struct drm_format_info formats[],
> + int num_formats, u32 format)
> +{
> + int i;
> +
> + for (i = 0; i < num_formats; i++) {
> + if (formats[i].format == format)
> + return &formats[i];
> + }
> +
> + return NULL;
> +}
> +
> +static const struct drm_format_info *
> +intel_get_format_info(struct drm_device *dev,
> + const struct drm_mode_fb_cmd2 *cmd)
> +{
> + switch (cmd->modifier[0]) {
> + case I915_FORMAT_MOD_Y_TILED_CCS:
> + case I915_FORMAT_MOD_Yf_TILED_CCS:
> + return lookup_format_info(ccs_formats,
> + ARRAY_SIZE(ccs_formats),
> + cmd->pixel_format);
> + default:
> + return NULL;
> + }
> +}
> +
> static int
> intel_fill_fb_info(struct drm_i915_private *dev_priv,
>struct drm_framebuffer *fb)
> @@ -14622,6 +14658,7 @@ static void intel_atomic_state_free(struct
> drm_atomic_state *state)
>
> static const struct drm_mode_config_funcs intel_mode_funcs = {
> .fb_create = intel_user_framebuffer_create,
> + .get_format_info = intel_get_format_info,
> .output_poll_changed = intel_fbdev_output_poll_changed,
> .atomic_check = intel_atomic_check,
> .atomic_commit = intel_atomic_commit,
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 4298171..f0d3d38 100644
> --- a/include/drm/
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/atomic-helper: Fix leak in disable_all
== Series Details == Series: series starting with [1/3] drm/atomic-helper: Fix leak in disable_all URL : https://patchwork.freedesktop.org/series/27337/ State : success == Summary == Series 27337v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/27337/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-r) fdo#100125 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:441s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:433s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:358s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:526s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:503s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:490s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:483s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:597s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:431s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:413s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:422s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:488s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:467s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:461s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:574s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:584s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:563s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:452s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:583s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:466s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:484s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:440s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:484s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:553s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:408s bd5641a8649223257233c4e1c45fc94abec1cdbe drm-tip: 2017y-07m-14d-19h-18m-56s UTC integration manifest 1c86ce5 drm/i915: unregister interfaces first in unload f27dd6e drm/i915: Fix fbdev unload sequence 89c3f3f drm/atomic-helper: Fix leak in disable_all == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5198/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: unregister interfaces first in unload
We first need to make sure no one else can get at us anymore,
before we can proceed to tear down all the datastructures.
Just a small step towards eventually the perfect unload code ...
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2c2afb19975d..38990b264b97 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1372,6 +1372,8 @@ void i915_driver_unload(struct drm_device *dev)
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
+ i915_driver_unregister(dev_priv);
+
if (i915_gem_suspend(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
@@ -1381,8 +1383,6 @@ void i915_driver_unload(struct drm_device *dev)
intel_gvt_cleanup(dev_priv);
- i915_driver_unregister(dev_priv);
-
intel_modeset_cleanup(dev);
/*
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Fix fbdev unload sequence
First thing we need to do is unregister the fbdev instance, but we
can't just go ahead and kfree it. That must wait until the hotplug and
polling work are stopped, since they can race with the with the
teardown. That means we need to split up the fbdev teardown into the
unregister part and the cleanup part.
I originally suspected that this was broken in one of the unload
shuffles, but on closer inspection the oldest sequence I've dug out
also gets this wrong. Just not quite so badly.
I've run drv_module_reload a few hundred times and it's rock solid
compared to insta-death beforehand. This bug seems to have been
uncovered by
commit 88be58be886f1215cc73dc8c273c985eecd7385c
Author: Daniel Vetter
Date: Thu Jul 6 15:00:19 2017 +0200
drm/i915/fbdev: Always forward hotplug events
But the effect of that seems to only be to increase the race window
enough to make it blow up easier. I'm not exactly clear on what's
going on there ...
v2: Fix whitespace and use fetch_and_zero (Chris).
Testcase: igt/drv_module_reload
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101791
Cc: martin.pe...@free.fr
Cc: ch...@chris-wilson.co.uk
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 3 +--
drivers/gpu/drm/i915/intel_display.c | 3 +++
drivers/gpu/drm/i915/intel_drv.h | 9 +++--
drivers/gpu/drm/i915/intel_fbdev.c | 22 +++---
4 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..2c2afb19975d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1240,6 +1240,7 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
*/
static void i915_driver_unregister(struct drm_i915_private *dev_priv)
{
+ intel_fbdev_unregister(dev_priv);
intel_audio_deinit(dev_priv);
intel_gpu_ips_teardown();
@@ -1371,8 +1372,6 @@ void i915_driver_unload(struct drm_device *dev)
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
- intel_fbdev_fini(dev);
-
if (i915_gem_suspend(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ecb4e30673fc..e10fae2faa88 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15111,6 +15111,9 @@ void intel_modeset_cleanup(struct drm_device *dev)
*/
drm_kms_helper_poll_fini(dev);
+ /* poll work can call into fbdev, hence clean that up afterwards */
+ intel_fbdev_fini(dev_priv);
+
intel_unregister_dsm_handler();
intel_fbc_global_disable(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3132260f18ce..7361e983d953 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1597,7 +1597,8 @@ void intel_hpd_poll_init(struct drm_i915_private
*dev_priv);
#ifdef CONFIG_DRM_FBDEV_EMULATION
extern int intel_fbdev_init(struct drm_device *dev);
extern void intel_fbdev_initial_config_async(struct drm_device *dev);
-extern void intel_fbdev_fini(struct drm_device *dev);
+extern void intel_fbdev_unregister(struct drm_i915_private *dev_priv);
+extern void intel_fbdev_fini(struct drm_i915_private *dev_priv);
extern void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool
synchronous);
extern void intel_fbdev_output_poll_changed(struct drm_device *dev);
extern void intel_fbdev_restore_mode(struct drm_device *dev);
@@ -1611,7 +1612,11 @@ static inline void
intel_fbdev_initial_config_async(struct drm_device *dev)
{
}
-static inline void intel_fbdev_fini(struct drm_device *dev)
+static inline void intel_fbdev_unregister(struct drm_i915_private *dev_priv)
+{
+}
+
+static inline void intel_fbdev_fini(struct drm_i915_private *dev_priv)
{
}
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index b953365a3eec..391992373d27 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -538,8 +538,6 @@ static void intel_fbdev_destroy(struct intel_fbdev *ifbdev)
* trying to rectify all the possible error paths leading here.
*/
- drm_fb_helper_unregister_fbi(&ifbdev->helper);
-
drm_fb_helper_fini(&ifbdev->helper);
if (ifbdev->vma) {
@@ -727,8 +725,10 @@ static void intel_fbdev_initial_config(void *data,
async_cookie_t cookie)
/* Due to peculiar init order wrt to hpd handling this is separate. */
if (drm_fb_helper_initial_config(&ifbdev->helper,
-ifbdev->preferred_bpp))
- intel_fbdev_fini(ifbdev->helper.dev);
+ifbdev->preferred_bpp)) {
+ intel_fbdev_unregister(
[Intel-gfx] [PATCH 1/3] drm/atomic-helper: Fix leak in disable_all
The legacy plane->fb pointer is refcounted by calling drm_atomic_clean_old_fb(). In practice this isn't a real problem because: - The caller in the i915 gpu reset code restores the original state again, which means the plane->fb pointer won't change, hence can't leak. - Drivers using drm_atomic_helper_shutdown call the fbdev cleanup first, and that usually cleans up the fb through drm_remove_framebuffer, which does this correctly. - Without fbdev the only framebuffers are from userspace, and those get cleaned up (again using drm_remove_framebuffer) befor the driver can even be unloaded. But in i915 I've switched the cleanup sequence around so that the _shutdown() calls happens after the drm_remove_framebuffer(), which is how I discovered this issue. v2: My analysis why the current code was ok for gpu reset and suspend/resume was correct, but then I totally failed to realize that we better keep this symmetric. Thanksfully CI noticed that for balance, a refcounting bug must exist at 2 places if previously there was no issue ... Cc: martin.pe...@free.fr Cc: ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic_helper.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index b07fc30372d3..3a04619d3bec 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -2726,6 +2726,7 @@ int drm_atomic_helper_disable_all(struct drm_device *dev, struct drm_plane *plane; struct drm_crtc_state *crtc_state; struct drm_crtc *crtc; + unsigned plane_mask = 0; int ret, i; state = drm_atomic_state_alloc(dev); @@ -2768,10 +2769,14 @@ int drm_atomic_helper_disable_all(struct drm_device *dev, goto free; drm_atomic_set_fb_for_plane(plane_state, NULL); + plane_mask |= BIT(drm_plane_index(plane)); + plane->old_fb = plane->fb; } ret = drm_atomic_commit(state); free: + if (plane_mask) + drm_atomic_clean_old_fb(dev, plane_mask, ret); drm_atomic_state_put(state); return ret; } @@ -2902,6 +2907,8 @@ int drm_atomic_helper_commit_duplicated_state(struct drm_atomic_state *state, struct drm_connector_state *new_conn_state; struct drm_crtc *crtc; struct drm_crtc_state *new_crtc_state; + struct drm_device *dev = state->dev; + int ret; state->acquire_ctx = ctx; @@ -2914,7 +2921,10 @@ int drm_atomic_helper_commit_duplicated_state(struct drm_atomic_state *state, for_each_new_connector_in_state(state, connector, new_conn_state, i) state->connectors[i].old_state = connector->state; - return drm_atomic_commit(state); + ret = drm_atomic_commit(state); + drm_atomic_clean_old_fb(dev, ~0U, ret); + + return ret; } EXPORT_SYMBOL(drm_atomic_helper_commit_duplicated_state); -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches
On Fri, Jul 14, 2017 at 2:35 PM, Daniel Vetter wrote: > On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler wrote: >> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula >> wrote: >>> On Thu, 13 Jul 2017, Stéphane Marchesin >>> wrote: So, if you think this is wrong, can you fix this warning in a way that you'd like? >>> >>> As I replied previously [1], with more background, fixing the warnings >>> properly, in a way that actually improves the code instead of making it >>> worse, would mean a bunch of churn that's not just purely mechanical >>> conversion. >> >> That's fair. >> >>> Unless you can point out a bug which is actually caused by mixing the >>> types (which is mostly intentional, see the background) I have a hard >>> time telling people this should be a priority. >> >> This feels like "can't see the forest because of the trees". >> >> The original patch was submitted in order to compile cleanly using >> clang and the above suggests using clang is not important. Using >> clang is important to Matthias and the Chrome OS organization for many >> good reasons - including better warnings. >> >> The original patch message was clear that clang was generating the >> warning. This isn't the only patch mka has sent to kernel devs. What >> one can infer is Chrome OS is trying to move to clang (like other >> Google products _already_ have.) My impression is all these products >> are a priority to Intel - but it would be good to know otherwise. >> >>> Definitely something we'd >>> like to do in the long run and pedantically correct (and I tend to >>> prefer code that way) but we certainly have more important things to do. >> >> The long run is now. Everyone agrees the code should change and you >> don't have to do it. Matthias submitted an unacceptable patch and >> giving him some concrete guidance on what would be acceptable would >> enable him to implement/test it (or anyone else could for that >> matter). Can you do that? >> >> Just give an example of what the "right" API looks like and see where it >> goes. > > We've replied and discussed on May 5th what that roughly should be, > right when Matthias pinged us. The original submission unfortunately > fell through the cracks (it happens, not much we can do with this > flood). Matthias didn't seem to have any questions about the proposed > solutions (we laid out both the minimal short-term fix to unconfuse > things, and what might be done on top), I think a reasonable > assumption was that it's all clear. Otherwise he should have asked. Indeed! After briefly chatting with Stephane and mka, it seems the difference between short-term fix and "done on top" were not clear. > Now, over 2 months later (and complete silence from your side) there's > suddenly mass panic and multiple escalations on all available > channels, which feels like a rather decent overreaction and not a > terrible constructive way to collaborate on the upstream codebase. I'm sorry - I'm not on the other channels and I didn't see any mass panic. I agree that's not a collaborative. The previous answer in this thread didn't seem particularly collaborative either though. The silence was partly due to mka working on other "clang enablement" patches: $ pwclient list -w m...@chromium.org Patches submitted by Matthias Kaehlcke : ID StateName -- - 9668095 Superseded mac80211: Fix clang warning about constant operand in logical operation 9668479 Accepted ath9k: Add cast to u8 to FREQ2FBIN macro 9668643 Accepted [v2] mac80211: Fix clang warning about constant operand in logical operation 9679753 Accepted [v2] cfg80211: Fix array-bounds warning in fragment copy 9684547 Accepted mac80211: ibss: Fix channel type enum in ieee80211_sta_join_ibss() 9684629 Accepted nl80211: Fix enum type of variable in nl80211_put_sta_rate() > Anyway, I've done the quick draft for the function declaration changes > that would clear up the confusion, just needs a clang run to update > all the parameters to match, and passed that on to Stéphane Marchesin. Awesome - thanks! :) > I expect you to follow up with the corresponding patch right away. mka said "he would take a look at it". But knowing how he understates things in a typical "German Engineer" way, I'm optimistic it will be more than that. Thanks! cheers, grant > > Thanks a lot. > > Yours, Daniel > > For reference the diff, but probably whitespace mangled because the > real machine is down already: > > diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c > b/drivers/gpu/drm/i915/intel_fifo_underrun.c > index d484862cc7df..21c221b4ae57 100644 > --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c > +++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c > @@ -313,7 +313,7 @@ bool intel_set_cpu_fifo_underrun_reporting(struct > drm_i915_private *dev_priv, > * Returns the previous state of underrun reporting. > */ > bool intel_set_pch_fifo_underrun_reporting(struct drm_i915_private *dev_priv, > - enum
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/atomic-helper: Fix leak in disable_all
On Fri, Jul 14, 2017 at 10:17:52PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-07-14 22:03:05) > > On Fri, Jul 14, 2017 at 09:32:13PM +0100, Chris Wilson wrote: > > > Quoting Patchwork (2017-07-14 21:18:04) > > > > == Series Details == > > > > > > > > Series: series starting with [1/3] drm/atomic-helper: Fix leak in > > > > disable_all > > > > URL : https://patchwork.freedesktop.org/series/27327/ > > > > State : failure > > > > > > > > == Summary == > > > > > > > > Series 27327v1 Series without cover letter > > > > https://patchwork.freedesktop.org/api/1.0/series/27327/revisions/1/mbox/ > > > > > > > > Test gem_exec_fence: > > > > Subgroup await-hang-default: > > > > pass -> INCOMPLETE (fi-blb-e6850) > > > > pass -> INCOMPLETE (fi-pnv-d510) > > > > Test gem_exec_flush: > > > > Subgroup basic-batch-kernel-default-uc: > > > > fail -> PASS (fi-snb-2600) fdo#17 > > > > Test kms_busy: > > > > Subgroup basic-flip-default-a: > > > > pass -> INCOMPLETE (fi-ilk-650) > > > > pass -> INCOMPLETE (fi-snb-2520m) > > > > pass -> INCOMPLETE (fi-snb-2600) > > > > pass -> INCOMPLETE (fi-ivb-3520m) > > > > pass -> INCOMPLETE (fi-ivb-3770) > > > > pass -> INCOMPLETE (fi-byt-j1900) > > > > pass -> INCOMPLETE (fi-byt-n2820) > > > > pass -> INCOMPLETE (fi-hsw-4770) > > > > pass -> INCOMPLETE (fi-hsw-4770r) > > > > pass -> INCOMPLETE (fi-bdw-5557u) > > > > pass -> INCOMPLETE (fi-bdw-gvtdvm) > > > > pass -> INCOMPLETE (fi-skl-6260u) > > > > pass -> INCOMPLETE (fi-skl-6700hq) fdo#101144 > > > > pass -> INCOMPLETE (fi-skl-6700k) > > > > pass -> INCOMPLETE (fi-skl-6770hq) > > > > pass -> INCOMPLETE (fi-skl-gvtdvm) > > > > none -> INCOMPLETE (fi-skl-x1585l) > > > > pass -> INCOMPLETE (fi-bxt-j4205) > > > > pass -> INCOMPLETE (fi-kbl-7500u) > > > > pass -> INCOMPLETE (fi-kbl-7560u) > > > > pass -> INCOMPLETE (fi-kbl-r) > > > > pass -> INCOMPLETE (fi-glk-2a) > > > > Subgroup basic-flip-default-c: > > > > pass -> INCOMPLETE (fi-bsw-n3050) > > > > > > Looks like we decremented a refcount once too often (after it was freed, > > > poison 0x6b--). That clean up plane->old_fb? > > > > I can't even run that testcase without my gpu reset fixes, epic win :( > > It's hard to tell, but considering that the error it is detecting is slab > corruption, it is more likely an earlier test that is doing the dirty > deed. This is kasan territory. Tomi! I did fire up my full pile of stuff, and it indeed goes somehow horribly wrong in the modeset path for the reset code. Looks like my innocently-looking change to disable_all (we call that somewhere in there) to properly refcount ->fb wasn't all that innocent :( It's getting late, I'll try to figure out what's going tomorrow or on Mon. Promises to be another intriguing wild goose chase at least. kasan didn't say anything special, but somehow the atomic commit machinery died completely. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches
On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler wrote:
> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula
> wrote:
>> On Thu, 13 Jul 2017, Stéphane Marchesin wrote:
>>> So, if you think this is wrong, can you fix this warning in a way that
>>> you'd like?
>>
>> As I replied previously [1], with more background, fixing the warnings
>> properly, in a way that actually improves the code instead of making it
>> worse, would mean a bunch of churn that's not just purely mechanical
>> conversion.
>
> That's fair.
>
>> Unless you can point out a bug which is actually caused by mixing the
>> types (which is mostly intentional, see the background) I have a hard
>> time telling people this should be a priority.
>
> This feels like "can't see the forest because of the trees".
>
> The original patch was submitted in order to compile cleanly using
> clang and the above suggests using clang is not important. Using
> clang is important to Matthias and the Chrome OS organization for many
> good reasons - including better warnings.
>
> The original patch message was clear that clang was generating the
> warning. This isn't the only patch mka has sent to kernel devs. What
> one can infer is Chrome OS is trying to move to clang (like other
> Google products _already_ have.) My impression is all these products
> are a priority to Intel - but it would be good to know otherwise.
>
>> Definitely something we'd
>> like to do in the long run and pedantically correct (and I tend to
>> prefer code that way) but we certainly have more important things to do.
>
> The long run is now. Everyone agrees the code should change and you
> don't have to do it. Matthias submitted an unacceptable patch and
> giving him some concrete guidance on what would be acceptable would
> enable him to implement/test it (or anyone else could for that
> matter). Can you do that?
>
> Just give an example of what the "right" API looks like and see where it goes.
We've replied and discussed on May 5th what that roughly should be,
right when Matthias pinged us. The original submission unfortunately
fell through the cracks (it happens, not much we can do with this
flood). Matthias didn't seem to have any questions about the proposed
solutions (we laid out both the minimal short-term fix to unconfuse
things, and what might be done on top), I think a reasonable
assumption was that it's all clear. Otherwise he should have asked.
Now, over 2 months later (and complete silence from your side) there's
suddenly mass panic and multiple escalations on all available
channels, which feels like a rather decent overreaction and not a
terrible constructive way to collaborate on the upstream codebase.
Anyway, I've done the quick draft for the function declaration changes
that would clear up the confusion, just needs a clang run to update
all the parameters to match, and passed that on to Stéphane Marchesin.
I expect you to follow up with the corresponding patch right away.
Thanks a lot.
Yours, Daniel
For reference the diff, but probably whitespace mangled because the
real machine is down already:
diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c
b/drivers/gpu/drm/i915/intel_fifo_underrun.c
index d484862cc7df..21c221b4ae57 100644
--- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
+++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
@@ -313,7 +313,7 @@ bool intel_set_cpu_fifo_underrun_reporting(struct
drm_i915_private *dev_priv,
* Returns the previous state of underrun reporting.
*/
bool intel_set_pch_fifo_underrun_reporting(struct drm_i915_private *dev_priv,
- enum transcoder pch_transcoder,
+ enum pipe pch_transcoder,
bool enable)
{
struct intel_crtc *crtc =
@@ -390,7 +390,7 @@ void intel_cpu_fifo_underrun_irq_handler(struct
drm_i915_private *dev_priv,
* interrupt to avoid an irq storm.
*/
void intel_pch_fifo_underrun_irq_handler(struct drm_i915_private *dev_priv,
- enum transcoder pch_transcoder)
+ enum pipe pch_transcoder)
{
if (intel_set_pch_fifo_underrun_reporting(dev_priv, pch_transcoder,
false)) {
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/drm_module_reload: Don't require hda dynamic debug
On Fri, Jul 14, 2017 at 11:03 PM, Pandiyan, Dhinakaran wrote: > On Fri, 2017-07-14 at 19:14 +0200, Daniel Vetter wrote: >> I can live without those logs, and it avoids a kernel >> recompile&reboot. >> > > Sounds reasonable, having hda dynamic debug does not feel like a > necessity for module_reload testing. > Reviewed-by: Dhinakaran Pandiyan Thanks for your review, pushed. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/atomic-helper: Fix leak in disable_all
Quoting Daniel Vetter (2017-07-14 22:03:05) > On Fri, Jul 14, 2017 at 09:32:13PM +0100, Chris Wilson wrote: > > Quoting Patchwork (2017-07-14 21:18:04) > > > == Series Details == > > > > > > Series: series starting with [1/3] drm/atomic-helper: Fix leak in > > > disable_all > > > URL : https://patchwork.freedesktop.org/series/27327/ > > > State : failure > > > > > > == Summary == > > > > > > Series 27327v1 Series without cover letter > > > https://patchwork.freedesktop.org/api/1.0/series/27327/revisions/1/mbox/ > > > > > > Test gem_exec_fence: > > > Subgroup await-hang-default: > > > pass -> INCOMPLETE (fi-blb-e6850) > > > pass -> INCOMPLETE (fi-pnv-d510) > > > Test gem_exec_flush: > > > Subgroup basic-batch-kernel-default-uc: > > > fail -> PASS (fi-snb-2600) fdo#17 > > > Test kms_busy: > > > Subgroup basic-flip-default-a: > > > pass -> INCOMPLETE (fi-ilk-650) > > > pass -> INCOMPLETE (fi-snb-2520m) > > > pass -> INCOMPLETE (fi-snb-2600) > > > pass -> INCOMPLETE (fi-ivb-3520m) > > > pass -> INCOMPLETE (fi-ivb-3770) > > > pass -> INCOMPLETE (fi-byt-j1900) > > > pass -> INCOMPLETE (fi-byt-n2820) > > > pass -> INCOMPLETE (fi-hsw-4770) > > > pass -> INCOMPLETE (fi-hsw-4770r) > > > pass -> INCOMPLETE (fi-bdw-5557u) > > > pass -> INCOMPLETE (fi-bdw-gvtdvm) > > > pass -> INCOMPLETE (fi-skl-6260u) > > > pass -> INCOMPLETE (fi-skl-6700hq) fdo#101144 > > > pass -> INCOMPLETE (fi-skl-6700k) > > > pass -> INCOMPLETE (fi-skl-6770hq) > > > pass -> INCOMPLETE (fi-skl-gvtdvm) > > > none -> INCOMPLETE (fi-skl-x1585l) > > > pass -> INCOMPLETE (fi-bxt-j4205) > > > pass -> INCOMPLETE (fi-kbl-7500u) > > > pass -> INCOMPLETE (fi-kbl-7560u) > > > pass -> INCOMPLETE (fi-kbl-r) > > > pass -> INCOMPLETE (fi-glk-2a) > > > Subgroup basic-flip-default-c: > > > pass -> INCOMPLETE (fi-bsw-n3050) > > > > Looks like we decremented a refcount once too often (after it was freed, > > poison 0x6b--). That clean up plane->old_fb? > > I can't even run that testcase without my gpu reset fixes, epic win :( It's hard to tell, but considering that the error it is detecting is slab corruption, it is more likely an earlier test that is doing the dirty deed. This is kasan territory. Tomi! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/drm_module_reload: Don't require hda dynamic debug
On Fri, 2017-07-14 at 19:14 +0200, Daniel Vetter wrote:
> I can live without those logs, and it avoids a kernel
> recompile&reboot.
>
Sounds reasonable, having hda dynamic debug does not feel like a
necessity for module_reload testing.
Reviewed-by: Dhinakaran Pandiyan
> Signed-off-by: Daniel Vetter
> ---
> tests/drv_module_reload.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tests/drv_module_reload.c b/tests/drv_module_reload.c
> index db2ad2cf0f43..be831851dec2 100644
> --- a/tests/drv_module_reload.c
> +++ b/tests/drv_module_reload.c
> @@ -285,7 +285,10 @@ hda_dynamic_debug(bool enable)
> const char snd_hda_core_off[] = "module snd_hda_intel =_";
>
> fp = fopen("/sys/kernel/debug/dynamic_debug/control", "w");
> - igt_assert(fp != NULL);
> + if (!fp) {
> + igt_debug("hda dynamic debug not available\n");
> + return;
> + }
>
> if (enable) {
> fwrite(snd_hda_intel_on, 1, sizeof(snd_hda_intel_on), fp);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/atomic-helper: Fix leak in disable_all
On Fri, Jul 14, 2017 at 09:32:13PM +0100, Chris Wilson wrote: > Quoting Patchwork (2017-07-14 21:18:04) > > == Series Details == > > > > Series: series starting with [1/3] drm/atomic-helper: Fix leak in > > disable_all > > URL : https://patchwork.freedesktop.org/series/27327/ > > State : failure > > > > == Summary == > > > > Series 27327v1 Series without cover letter > > https://patchwork.freedesktop.org/api/1.0/series/27327/revisions/1/mbox/ > > > > Test gem_exec_fence: > > Subgroup await-hang-default: > > pass -> INCOMPLETE (fi-blb-e6850) > > pass -> INCOMPLETE (fi-pnv-d510) > > Test gem_exec_flush: > > Subgroup basic-batch-kernel-default-uc: > > fail -> PASS (fi-snb-2600) fdo#17 > > Test kms_busy: > > Subgroup basic-flip-default-a: > > pass -> INCOMPLETE (fi-ilk-650) > > pass -> INCOMPLETE (fi-snb-2520m) > > pass -> INCOMPLETE (fi-snb-2600) > > pass -> INCOMPLETE (fi-ivb-3520m) > > pass -> INCOMPLETE (fi-ivb-3770) > > pass -> INCOMPLETE (fi-byt-j1900) > > pass -> INCOMPLETE (fi-byt-n2820) > > pass -> INCOMPLETE (fi-hsw-4770) > > pass -> INCOMPLETE (fi-hsw-4770r) > > pass -> INCOMPLETE (fi-bdw-5557u) > > pass -> INCOMPLETE (fi-bdw-gvtdvm) > > pass -> INCOMPLETE (fi-skl-6260u) > > pass -> INCOMPLETE (fi-skl-6700hq) fdo#101144 > > pass -> INCOMPLETE (fi-skl-6700k) > > pass -> INCOMPLETE (fi-skl-6770hq) > > pass -> INCOMPLETE (fi-skl-gvtdvm) > > none -> INCOMPLETE (fi-skl-x1585l) > > pass -> INCOMPLETE (fi-bxt-j4205) > > pass -> INCOMPLETE (fi-kbl-7500u) > > pass -> INCOMPLETE (fi-kbl-7560u) > > pass -> INCOMPLETE (fi-kbl-r) > > pass -> INCOMPLETE (fi-glk-2a) > > Subgroup basic-flip-default-c: > > pass -> INCOMPLETE (fi-bsw-n3050) > > Looks like we decremented a refcount once too often (after it was freed, > poison 0x6b--). That clean up plane->old_fb? I can't even run that testcase without my gpu reset fixes, epic win :( I'll assemble an even bigger pile and see what happens. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/fbc: add comments to the FBC auxiliary structs
On Fri, Jul 14, 2017 at 04:38:22PM -0300, Paulo Zanoni wrote:
> I wrote this code an year and a half ago and I couldn't exactly
> remember the main differences of these two structures when reviewing a
> new FBC patch. Add some comments to help explain what's the purpose of
> each struct.
>
> For the record, the original commits are:
> b183b3f14395 ("drm/i915/fbc: introduce struct intel_fbc_reg_params")
> aaf78d276ba0 ("drm/i915/fbc: introduce struct intel_fbc_state_cache")
>
> Cc: Praveen Paneri
> Signed-off-by: Paulo Zanoni
Make them kerneldoc? It allows in-line comment, and maybe we'll have
proper kerneldoc for all our structs eventually. Either way
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.h | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a1eeb489..271402c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1063,6 +1063,11 @@ struct intel_fbc {
> bool underrun_detected;
> struct work_struct underrun_work;
>
> + /*
> + * Due to the atomic rules we can't access some structures without the
> + * appropriate locking, so we cache information here in order to avoid
> + * these problems.
> + */
> struct intel_fbc_state_cache {
> struct i915_vma *vma;
>
> @@ -1084,6 +1089,13 @@ struct intel_fbc {
> } fb;
> } state_cache;
>
> + /*
> + * This structure contains everything that's relevant to program the
> + * hardware registers. When we want to figure out if we need to disable
> + * and re-enable FBC for a new configuration we just check if there's
> + * something different in the struct. The genx_fbc_activate functions
> + * are supposed to read from it in order to program the registers.
> + */
> struct intel_fbc_reg_params {
> struct i915_vma *vma;
>
> --
> 2.9.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915: Add GuC timeout config options to Kconfig.debug
On 28/06/17 01:54, Tvrtko Ursulin wrote:
On 14/06/2017 00:19, Kelvin Gardiner wrote:
It is sometimes useful for debug purposes to be able to set GuC timeout
lengths.
This patch adds GuC load and request timeouts values to Kconfig.debug,
which can then be optionally set as required for debug cases. A default
value equal to the current hard-coded values are provided.
In the case when a Kconfig option has not been set, a default value is
provide using a define.
Signed-off-by: Kelvin Gardiner
---
drivers/gpu/drm/i915/Kconfig.debug | 40
+
drivers/gpu/drm/i915/i915_drv.h | 13 +++
drivers/gpu/drm/i915/intel_guc_loader.c | 3 ++-
drivers/gpu/drm/i915/intel_uc.c | 5 -
4 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 78c5c04..6a0767d 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -112,3 +112,43 @@ config DRM_I915_DEBUG_VBLANK_EVADE
the vblank.
If in doubt, say "N".
+
+config DRM_I915_OVERRIDE_TIMEOUTS
+bool "Enable timeout overrides"
+depends on DRM_I915
+default n
+help
+ Enable this option to allow overriding of selected timeouts
in the
+ driver i915.
+
+ Timeouts should only be overridden for debug and not in normal
use.
+
+ If in doubt, say "N".
If you drop this config...
+
+config DRM_I915_TIMEOUT_GUC_LOAD
+int "Set the value of the GuC load timeout"
+depends on DRM_I915_OVERRIDE_TIMEOUTS
... and this depends line...
+default 100
+range 0 1
+help
+ Set this option to select the value of the timeout in ms for
how long
+ the GuC FW load should take.
+
+ The valid range is 0 to 1
+
+ The default timeout will work in normal use. This option is
provided
+ for debug.
+
+config DRM_I915_TIMEOUT_GUC_REQUEST
+int "Set the value of the GuC request timeout"
+depends on DRM_I915_OVERRIDE_TIMEOUTS
... and this one...
+default 10
+range 0 1000
+help
+ Set this option to select the value of the timeout in ms
for how long
+ a request to the GuC should take.
+
+ The valid range is 0 to 1000
+
+ The default timeout will work in normal use. This option is
provided
+ for debug.
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 38ef734..efc56d2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1488,6 +1488,19 @@ struct drm_i915_error_state_buf {
#define I915_ENGINE_DEAD_TIMEOUT (4 * HZ) /* Seqno, head and
subunits dead */
#define I915_SEQNO_DEAD_TIMEOUT (12 * HZ) /* Seqno dead with
active head */
+#ifndef CONFIG_DRM_I915_TIMEOUT_GUC_LOAD
+#define DRM_I915_TIMEOUT_GUC_LOAD 100
+#else
+#define DRM_I915_TIMEOUT_GUC_LOAD CONFIG_DRM_I915_TIMEOUT_GUC_LOAD
+#endif
+
+#ifndef CONFIG_DRM_I915_TIMEOUT_GUC_REQUEST
+#define DRM_I915_TIMEOUT_GUC_REQUEST 10
+#else
+#define DRM_I915_TIMEOUT_GUC_REQUEST CONFIG_DRM_I915_TIMEOUT_GUC_REQUEST
+#endif
+
+
... and this whole block ...
struct i915_gpu_error {
/* For hangcheck timer */
#define DRM_I915_HANGCHECK_PERIOD 1500 /* in ms */
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 8b0ae7f..0d7abad 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -235,7 +235,8 @@ static int guc_ucode_xfer_dma(struct
drm_i915_private *dev_priv,
* (Higher levels of the driver will attempt to fall back to
* execlist mode if this happens.)
*/
-ret = wait_for(guc_ucode_response(dev_priv, &status), 100);
+ret = wait_for(guc_ucode_response(dev_priv, &status),
+DRM_I915_TIMEOUT_GUC_LOAD);
... and use CONFIG_DRM_I915_TIMEOUT_GUC_LOAD directly here ...
DRM_DEBUG_DRIVER("DMA status 0x%x, GuC status 0x%x\n",
I915_READ(DMA_CTRL), status);
diff --git a/drivers/gpu/drm/i915/intel_uc.c
b/drivers/gpu/drm/i915/intel_uc.c
index 27e072c..de34119 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -501,7 +501,10 @@ int intel_guc_send_mmio(struct intel_guc *guc,
const u32 *action, u32 len)
guc_send_reg(guc, 0),
INTEL_GUC_RECV_MASK,
INTEL_GUC_RECV_MASK,
- 10, 10, &status);
+ 10,
+ DRM_I915_TIMEOUT_GUC_REQUEST,
... and the same here respectively, then the patch becomes somewhat
shorter.
Agreed. I went with this implementation after some discussion with others.
I'll send a version with the changes you suggest, and we can see which
seems cleaner.
Question is whether that would be worth it, or having an explicit master
toggle is more desirable?
Since both timeout options provide defa
Re: [Intel-gfx] Skylake / (EE) modeset(0): present flip failed loop
I hate to spam, but I'm still getting half a gig of errors in my logs per day, to the point that I need to prune them aggressively, and obviously Xorg with the new kernel and new intel driver, is not working right. If this is not the right place to get support, where is it? If it's the place baring other options I haven't found, please help: As per my last post: I'll try a more basic question: am I supposed not to use the modesetting driver if I want a working setup? While debian seems to default to or kind of force the use of the modesetting driver, if you confirm I shouldn't be using it, I can look at how to switch away from it. Thanks, Marc > On Mon, Jul 10, 2017 at 09:21:46AM -0700, Marc MERLIN wrote: > > On Fri, Jul 07, 2017 at 10:26:30AM -0700, Marc MERLIN wrote: > > > On Fri, Jul 07, 2017 at 11:47:25AM +0100, Chris Wilson wrote: > > > > Quoting Marc MERLIN (2017-07-07 06:40:51) > > > > > Is this the right place to send this? > > > > > Can anyone help? > > > > > > > > > > On Wed, Jul 05, 2017 at 11:33:01PM -0700, Marc MERLIN wrote: > > > > > > Howdy, > > > > > > > > > > > > I have a thinkpad P70 with debian testing and 4.11.6 kernel. > > > > > > A recent-ish upgrade broke something and now I'm getting loads of > > > > > > spam > > > > > > in my Xorg.log > > > > > > > > > > > > [ 5031.435] (WW) modeset(0): flip queue failed: Invalid argument > > > > > > [ 5031.435] (WW) modeset(0): Page flip failed: Invalid argument > > > > > > [ 5031.435] (EE) modeset(0): present flip failed > > > > > > [ 5031.519] (WW) modeset(0): flip queue failed: Invalid argument > > > > > > [ 5031.519] (WW) modeset(0): Page flip failed: Invalid argument > > > > > > [ 5031.519] (EE) modeset(0): present flip failed > > > > > > (...) > > > > > > > > > > > > system info: > > > > > > ii libdrm-intel1:amd642.4.74-1 > > > > > > ii xserver-xorg-core 2:1.19.2-1 > > > > > > ii xserver-xorg-video-intel 2:2.99.917+git20161206-1 > > > > > > > > If you were indeed using -intel then I would be more concerned. > > > > > > Thanks for the reply. > > > Sorry, I'm not quite parsing what you wrote here. Are you saying that I > > > should be disable the modesetting driver? > > > To be honest, I didn't actually choose it, it seems that Debian forced > > > the switch to it. > > > > > > xserver-xorg-video-intel (2:2.13.0-2) unstable; urgency=low > > > > > > * Starting from 2.10, the Intel X driver depends on a kernel driver for > > > mode setting (that's called KMS). The corresponding kernel option is > > > CONFIG_DRM_I915, and is enabled in Debian kernels. > > > * To enable KMS, either of those should be sufficient: > > > + /etc/modprobe.d/i915-kms.conf should contain: > > > options i915 modeset=1 > > > > > > If so, how do you recommend I switch back if that's what you meant I > > > should do? > > > > > > > But at the very least you need to dig into dmesg (with drm.debug=fe) to > > > > find out why it failed. (One way is to run -intel with debugging enabled > > > > so that it includes the kernel error messages along with the failure > > > > message.) > > > > > > Sounds like I need to switch drivers? > > > Right now I have no xorg.conf and it just autodetects/sets the KMS driver. > > > Sorry if I'm kind of a NOOB here, but if you give me a short pointer to > > > how you'd like me to switch, I'll happily do so. > > > > Can someone give me a hint what I should do next? > > Things are starting to become a problem, not counting performance which is > > far from good: > > saruman:/tmp$ du -sh /var/log/Xorg.0.log > > 1.1G/var/log/Xorg.0.log > > > > Marc > > -- > > "A mouse is a device used to point at the xterm you want to type in" - > > A.S.R. > > Microsoft is to operating systems > > what McDonalds is to gourmet > > cooking > > Home page: http://marc.merlins.org/ > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > "A mouse is a device used to point at the xterm you want to type in" - A.S.R. > Microsoft is to operating systems > what McDonalds is to gourmet > cooking > Home page: http://marc.merlins.org/ > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix cursor updates on some platforms
On Fri, Jul 14, 2017 at 07:34:15PM +0300, Ville Syrjälä wrote: > On Fri, Jul 14, 2017 at 05:24:03PM +0100, Chris Wilson wrote: > > Quoting ville.syrj...@linux.intel.com (2017-07-14 16:52:27) > > > From: Ville Syrjälä > > > > > > Turns out that just writing CURPOS isn't sufficient to move the cursor > > > on some platforms. My 830 works just fine, but eg. 945 and PNV don't. > > > On those platforms we need to arm even the CURPOS update with a > > > CURBASE write. > > > > > > Even worse, a write to any of the cursor register apart from CURBASE > > > will cancel an already pending cursor update. So if we have armed a > > > CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank > > > would cancel that armed update. Thus we're left with a cursor that > > > doesn't appear to move, or even change shape. > > > > > > Fix the problem by always performing the CURBASE write after a > > > CURPOS write. Bspec is somewhat unclear which platforms actually > > > require this CURBASE write and which don't. So to keep it simple > > > and to make sure we really fix the problem across all supported > > > devices, let's just perform the CURBASE write unconditionally. > > > > Hmm, it seems that kms_cursor_crc should catch this? I guess we are > > missing a move N times quickly test? > > Yeah. I guess what we have is basically this: > 1. enable cursor at some location > 2. wait for vblank and grab the crc > 3. disable cursor and render the cursor image to the primary plane fb > 4. wait for vblank and grab the crc Actually kms_cursor_crc does catch this. At least the "sliding" test seems to fail on pnv without the patch, and pass with the patch. The problem is we don't run any of that in BAT. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbc: add comments to the FBC auxiliary structs
== Series Details == Series: drm/i915/fbc: add comments to the FBC auxiliary structs URL : https://patchwork.freedesktop.org/series/27330/ State : success == Summary == Series 27330v1 drm/i915/fbc: add comments to the FBC auxiliary structs https://patchwork.freedesktop.org/api/1.0/series/27330/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-r) fdo#100125 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:449s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:426s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:355s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:527s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:511s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:489s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:485s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:596s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:433s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:502s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:463s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:577s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:585s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:564s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:453s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:582s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:470s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:481s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:437s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:496s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:544s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:407s bd5641a8649223257233c4e1c45fc94abec1cdbe drm-tip: 2017y-07m-14d-19h-18m-56s UTC integration manifest 53780e8 drm/i915/fbc: add comments to the FBC auxiliary structs == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5197/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/atomic-helper: Fix leak in disable_all
Quoting Patchwork (2017-07-14 21:18:04) > == Series Details == > > Series: series starting with [1/3] drm/atomic-helper: Fix leak in disable_all > URL : https://patchwork.freedesktop.org/series/27327/ > State : failure > > == Summary == > > Series 27327v1 Series without cover letter > https://patchwork.freedesktop.org/api/1.0/series/27327/revisions/1/mbox/ > > Test gem_exec_fence: > Subgroup await-hang-default: > pass -> INCOMPLETE (fi-blb-e6850) > pass -> INCOMPLETE (fi-pnv-d510) > Test gem_exec_flush: > Subgroup basic-batch-kernel-default-uc: > fail -> PASS (fi-snb-2600) fdo#17 > Test kms_busy: > Subgroup basic-flip-default-a: > pass -> INCOMPLETE (fi-ilk-650) > pass -> INCOMPLETE (fi-snb-2520m) > pass -> INCOMPLETE (fi-snb-2600) > pass -> INCOMPLETE (fi-ivb-3520m) > pass -> INCOMPLETE (fi-ivb-3770) > pass -> INCOMPLETE (fi-byt-j1900) > pass -> INCOMPLETE (fi-byt-n2820) > pass -> INCOMPLETE (fi-hsw-4770) > pass -> INCOMPLETE (fi-hsw-4770r) > pass -> INCOMPLETE (fi-bdw-5557u) > pass -> INCOMPLETE (fi-bdw-gvtdvm) > pass -> INCOMPLETE (fi-skl-6260u) > pass -> INCOMPLETE (fi-skl-6700hq) fdo#101144 > pass -> INCOMPLETE (fi-skl-6700k) > pass -> INCOMPLETE (fi-skl-6770hq) > pass -> INCOMPLETE (fi-skl-gvtdvm) > none -> INCOMPLETE (fi-skl-x1585l) > pass -> INCOMPLETE (fi-bxt-j4205) > pass -> INCOMPLETE (fi-kbl-7500u) > pass -> INCOMPLETE (fi-kbl-7560u) > pass -> INCOMPLETE (fi-kbl-r) > pass -> INCOMPLETE (fi-glk-2a) > Subgroup basic-flip-default-c: > pass -> INCOMPLETE (fi-bsw-n3050) Looks like we decremented a refcount once too often (after it was freed, poison 0x6b--). That clean up plane->old_fb? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/atomic-helper: Fix leak in disable_all
== Series Details == Series: series starting with [1/3] drm/atomic-helper: Fix leak in disable_all URL : https://patchwork.freedesktop.org/series/27327/ State : failure == Summary == Series 27327v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/27327/revisions/1/mbox/ Test gem_exec_fence: Subgroup await-hang-default: pass -> INCOMPLETE (fi-blb-e6850) pass -> INCOMPLETE (fi-pnv-d510) Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test kms_busy: Subgroup basic-flip-default-a: pass -> INCOMPLETE (fi-ilk-650) pass -> INCOMPLETE (fi-snb-2520m) pass -> INCOMPLETE (fi-snb-2600) pass -> INCOMPLETE (fi-ivb-3520m) pass -> INCOMPLETE (fi-ivb-3770) pass -> INCOMPLETE (fi-byt-j1900) pass -> INCOMPLETE (fi-byt-n2820) pass -> INCOMPLETE (fi-hsw-4770) pass -> INCOMPLETE (fi-hsw-4770r) pass -> INCOMPLETE (fi-bdw-5557u) pass -> INCOMPLETE (fi-bdw-gvtdvm) pass -> INCOMPLETE (fi-skl-6260u) pass -> INCOMPLETE (fi-skl-6700hq) fdo#101144 pass -> INCOMPLETE (fi-skl-6700k) pass -> INCOMPLETE (fi-skl-6770hq) pass -> INCOMPLETE (fi-skl-gvtdvm) none -> INCOMPLETE (fi-skl-x1585l) pass -> INCOMPLETE (fi-bxt-j4205) pass -> INCOMPLETE (fi-kbl-7500u) pass -> INCOMPLETE (fi-kbl-7560u) pass -> INCOMPLETE (fi-kbl-r) pass -> INCOMPLETE (fi-glk-2a) Subgroup basic-flip-default-c: pass -> INCOMPLETE (fi-bsw-n3050) fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144 fi-bdw-5557u total:196 pass:191 dwarn:0 dfail:0 fail:0 skip:4 fi-bdw-gvtdvmtotal:196 pass:190 dwarn:0 dfail:0 fail:0 skip:5 fi-blb-e6850 total:48 pass:24 dwarn:0 dfail:0 fail:0 skip:23 fi-bsw-n3050 total:198 pass:181 dwarn:0 dfail:0 fail:0 skip:16 fi-bxt-j4205 total:196 pass:183 dwarn:0 dfail:0 fail:0 skip:12 fi-byt-j1900 total:196 pass:181 dwarn:0 dfail:0 fail:0 skip:14 fi-byt-n2820 total:196 pass:181 dwarn:0 dfail:0 fail:0 skip:14 fi-glk-2atotal:196 pass:182 dwarn:0 dfail:0 fail:0 skip:13 fi-hsw-4770 total:196 pass:186 dwarn:0 dfail:0 fail:0 skip:9 fi-hsw-4770r total:196 pass:186 dwarn:0 dfail:0 fail:0 skip:9 fi-ilk-650 total:196 pass:163 dwarn:0 dfail:0 fail:0 skip:32 fi-ivb-3520m total:196 pass:182 dwarn:0 dfail:0 fail:0 skip:13 fi-ivb-3770 total:196 pass:182 dwarn:0 dfail:0 fail:0 skip:13 fi-kbl-7500u total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:11 fi-kbl-7560u total:196 pass:192 dwarn:0 dfail:0 fail:0 skip:3 fi-kbl-r total:196 pass:183 dwarn:1 dfail:0 fail:0 skip:11 fi-pnv-d510 total:48 pass:24 dwarn:0 dfail:0 fail:0 skip:23 fi-skl-6260u total:196 pass:192 dwarn:0 dfail:0 fail:0 skip:3 fi-skl-6700hqtotal:196 pass:184 dwarn:0 dfail:0 fail:0 skip:11 fi-skl-6700k total:196 pass:184 dwarn:0 dfail:0 fail:0 skip:11 fi-skl-6770hqtotal:196 pass:192 dwarn:0 dfail:0 fail:0 skip:3 fi-skl-gvtdvmtotal:196 pass:191 dwarn:0 dfail:0 fail:0 skip:4 fi-skl-x1585ltotal:196 pass:192 dwarn:0 dfail:0 fail:0 skip:3 fi-snb-2520m total:196 pass:178 dwarn:0 dfail:0 fail:0 skip:17 fi-snb-2600 total:196 pass:178 dwarn:0 dfail:0 fail:0 skip:17 bd5641a8649223257233c4e1c45fc94abec1cdbe drm-tip: 2017y-07m-14d-19h-18m-56s UTC integration manifest 38c0fe8 drm/i915: unregister interfaces first in unload 8c358e2 drm/i915: Fix fbdev unload sequence 2020d3d drm/atomic-helper: Fix leak in disable_all == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5196/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/fbc: add comments to the FBC auxiliary structs
I wrote this code an year and a half ago and I couldn't exactly
remember the main differences of these two structures when reviewing a
new FBC patch. Add some comments to help explain what's the purpose of
each struct.
For the record, the original commits are:
b183b3f14395 ("drm/i915/fbc: introduce struct intel_fbc_reg_params")
aaf78d276ba0 ("drm/i915/fbc: introduce struct intel_fbc_state_cache")
Cc: Praveen Paneri
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a1eeb489..271402c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1063,6 +1063,11 @@ struct intel_fbc {
bool underrun_detected;
struct work_struct underrun_work;
+ /*
+* Due to the atomic rules we can't access some structures without the
+* appropriate locking, so we cache information here in order to avoid
+* these problems.
+*/
struct intel_fbc_state_cache {
struct i915_vma *vma;
@@ -1084,6 +1089,13 @@ struct intel_fbc {
} fb;
} state_cache;
+ /*
+* This structure contains everything that's relevant to program the
+* hardware registers. When we want to figure out if we need to disable
+* and re-enable FBC for a new configuration we just check if there's
+* something different in the struct. The genx_fbc_activate functions
+* are supposed to read from it in order to program the registers.
+*/
struct intel_fbc_reg_params {
struct i915_vma *vma;
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: unregister interfaces first in unload
Quoting Daniel Vetter (2017-07-14 20:14:39) > We first need to make sure no one else can get at us anymore, > before we can proceed to tear down all the datastructures. > > Just a small step towards eventually the perfect unload code ... > > Signed-off-by: Daniel Vetter Just some concern from the inertia of having the old order for years, but this looks completely correct to me. That the driver may still be active as we disable the userspace interfaces should not affect those. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Fix FBC cfb stride programming for non X-tiled FB
Em Sex, 2017-03-24 às 17:12 +0530, Praveen Paneri escreveu:
> When FBC is enabled for linear, legacy Y-tiled and Yf-tiled
> surfaces on gen9, the cfb stride must be programmed by SW as
>
> cfb_stride = ceiling[(at least plane width in pixels)/
> (32 * compression limit factor)] * 8
>
> v2: Minor fix for a build error
>
> v3: Fixed subject, register name and platform check (Ville)
>
> v4: Added WA details in comment (Paulo)
>
> Cc: Paulo Zanoni
> Cc: Ville Syrjälä
> Signed-off-by: Praveen Paneri
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_fbc.c | 9 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 04c8f69..4adf2e6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6504,6 +6504,9 @@ enum {
> #define GLK_CL1_PWR_DOWN(1 << 11)
> #define GLK_CL2_PWR_DOWN(1 << 12)
>
> +#define CHICKEN_MISC_4 _MMIO(0x4208c)
> +#define FBC_STRIDE_OVERRIDE(1<<13)
> +
> #define _CHICKEN_PIPESL_1_A 0x420b0
> #define _CHICKEN_PIPESL_1_B 0x420b4
> #define HSW_FBCQ_DIS(1 << 22)
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index ded2add..1183633 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -298,9 +298,18 @@ static bool ilk_fbc_is_active(struct
> drm_i915_private *dev_priv)
> static void gen7_fbc_activate(struct drm_i915_private *dev_priv)
> {
> struct intel_fbc_reg_params *params = &dev_priv->fbc.params;
> + struct intel_fbc_state_cache *cache = &dev_priv-
> >fbc.state_cache;
Please take a look at b183b3f14395. We need to store the calculated
stride value in reg_params so the stride value can actually be taken
into consideration when comparing different FBC configurations.
> u32 dpfc_ctl;
> int threshold = dev_priv->fbc.threshold;
>
> + /* Display WA #0529: skl, kbl, bxt, glk */
> + if (IS_GEN9(dev_priv) &&
AFAIU, this WA shouldn't be applied for GLK.
> + i915_gem_object_get_tiling(cache->vma->obj) !=
> I915_TILING_X) {
> + int cfb_stride = DIV_ROUND_UP(cache->plane.src_w,
> + (32 * threshold)) * 8;
> + I915_WRITE(CHICKEN_MISC_4, FBC_STRIDE_OVERRIDE |
> cfb_stride);
We need to zero those bits when we're not using Y tiling. I mean, at
least bit 13.
Also, CHICKEN_MISC_4 contains other fields not touched here, so we
should probably do a read-modify-write on it, preserving everything
we're not touching.
Thanks,
Paulo
> + }
> +
> dpfc_ctl = 0;
> if (IS_IVYBRIDGE(dev_priv))
> dpfc_ctl |= IVB_DPFC_CTL_PLANE(params->crtc.plane);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Fix fbdev unload sequence
Quoting Daniel Vetter (2017-07-14 20:14:38)
Second nit:
> +void intel_fbdev_fini(struct drm_i915_private *dev_priv)
> +{
> + struct intel_fbdev *ifbdev = dev_priv->fbdev;
> +
> + if (!ifbdev)
> + return;
> +
> intel_fbdev_destroy(ifbdev);
> dev_priv->fbdev = NULL;
Maybe
struct intel_fbdev *ifbdev;
ifbdev = fetch_and_zero(&dev_priv->fbdev);
if (!fbdev)
return;
intel_fbdev_destroy(ifbdev);
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Fix fbdev unload sequence
Quoting Daniel Vetter (2017-07-14 20:14:38) > First thing we need to do is unregister the fbdev instance, but we > can't just go ahead and kfree it. That must wait until the hotplug and > polling work are stopped, since they can race with the with the > teardown. That means we need to split up the fbdev teardown into the > unregister part and the cleanup part. > > I originally suspected that this was broken in one of the unload > shuffles, but on closer inspection the oldest sequence I've dug out > also gets this wrong. Just not quite so badly. > > I've run drv_module_reload a few hundred times and it's rock solid > compared to insta-death beforehand. This bug seems to have been > uncovered by > > commit 88be58be886f1215cc73dc8c273c985eecd7385c > Author: Daniel Vetter > Date: Thu Jul 6 15:00:19 2017 +0200 > > drm/i915/fbdev: Always forward hotplug events > > But the effect of that seems to only be to increase the race window > enough to make it blow up easier. I'm not exactly clear on what's > going on there ... > > Testcase: igt/drv_module_reload > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101791 > Cc: martin.pe...@free.fr > Cc: ch...@chris-wilson.co.uk > Signed-off-by: Daniel Vetter Splitting out the unregister and running it early makes sense and is how we expect to unload to proceed. Reviewed-by: Chris Wilson Nit: > @@ -1383,7 +1383,6 @@ void i915_driver_unload(struct drm_device *dev) > intel_gvt_cleanup(dev_priv); > > i915_driver_unregister(dev_priv); > - > intel_modeset_cleanup(dev); I think it will useful to maintain the visual break here. (I know next patch moves it again...) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/atomic-helper: Fix leak in disable_all
Quoting Daniel Vetter (2017-07-14 20:14:37) > The legacy plane->fb pointer is refcounted by calling > drm_atomic_clean_old_fb(). > > In practice this isn't a real problem because: > - The caller in the i915 gpu reset code restores the original state > again, which means the plane->fb pointer won't change, hence can't > leak. > - Drivers using drm_atomic_helper_shutdown call the fbdev cleanup > first, and that usually cleans up the fb through > drm_remove_framebuffer, which does this correctly. > - Without fbdev the only framebuffers are from userspace, and those > get cleaned up (again using drm_remove_framebuffer) befor the driver > can even be unloaded. > > But in i915 I've switched the cleanup sequence around so that the > _shutdown() calls happens after the drm_remove_framebuffer(), which is > how I discovered this issue. If only we have refcounted fb now and didn't need every caller manually tracking the old pointers. Given the requirement for the caller to cleanup old_fb around drm_atomic_commit(), this looks correct to me. > Cc: martin.pe...@free.fr > Cc: ch...@chris-wilson.co.uk > Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf/fence: Avoid use of uninitialised timestamp
2017-07-11 Chris Wilson : > Quoting Chris Wilson (2017-02-14 12:40:01) > > [ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized > > memory (8802538683d0) > > [ 236.828642] > > 42001e7f0008 > > [ 236.839543] i i i i u u u u i i i i i i i i u u u u u u u u u u u u u u > > u u > > [ 236.850420] ^ > > [ 236.854123] RIP: 0010:[] [] > > fence_signal+0x17/0xd0 > > [ 236.861313] RSP: 0018:88024acd7ba0 EFLAGS: 00010282 > > [ 236.865027] RAX: 812f6a90 RBX: 8802527ca800 RCX: > > 880252cb30e0 > > [ 236.868801] RDX: 88024ac5d918 RSI: 880252f780e0 RDI: > > 880253868380 > > [ 236.872579] RBP: 88024acd7bc0 R08: 88024acd7be0 R09: > > > > [ 236.876407] R10: R11: R12: > > 880253868380 > > [ 236.880185] R13: 8802538684d0 R14: 880253868380 R15: > > 88024cd48e00 > > [ 236.883983] FS: 7f1646d1a740() GS:88025d00() > > knlGS: > > [ 236.890959] CS: 0010 DS: ES: CR0: 80050033 > > [ 236.894702] CR2: 880251360318 CR3: 00024ad21000 CR4: > > 001406f0 > > [ 236.898481] [] i915_gem_request_retire+0x1cd/0x230 > > [ 236.902439] [] i915_gem_request_alloc+0xa3/0x2f0 > > [ 236.906435] [] > > i915_gem_do_execbuffer.isra.41+0xb6d/0x18b0 > > [ 236.910434] [] i915_gem_execbuffer2+0x95/0x1e0 > > [ 236.914390] [] drm_ioctl+0x1e5/0x460 > > [ 236.918275] [] do_vfs_ioctl+0x8f/0x5c0 > > [ 236.922168] [] SyS_ioctl+0x3c/0x70 > > [ 236.926090] [] entry_SYSCALL_64_fastpath+0x17/0x93 > > [ 236.930045] [] 0x > > Ah something that I didn't take into account, and indeed gives this a bit > more urgency than I realised, is that the timestamp is exposed to > userspace. As such we are feeding it garbage, at best. > > The trivial option is just to clear it in dma_fence_init(). I still have > the slight preference for the extra complication here (for the reader) as > it should be quicker for the more common path of signaling the fence. > > > We only set the timestamp before we mark the fence as signaled. It is > > done before to avoid observers having a window in which they may see the > > fence as complete but no timestamp. Having it does incur a potential for > > the timestamp to be written twice, and even for it to be corrupted if > > the u64 write is not atomic. Instead use a new bit to record the > > presence of the timestamp, and teach the readers to wait until it is set > > if the fence is complete. There still remains a race where the timestamp > > for the signaled fence may be shown before the fence is reported as > > signaled, but that's a pre-existing error. > > Now deserves a > Reported-by: Rafael Antognolli > > > Signed-off-by: Chris Wilson > > Cc: Sumit Semwal > > Cc: Gustavo Padovan > > Cc: Daniel Vetter > Cc: Rafael Antognolli > > > --- > > drivers/dma-buf/dma-fence.c | 17 ++--- > > drivers/dma-buf/sync_debug.c | 2 +- > > drivers/dma-buf/sync_file.c | 8 +++- > > include/linux/dma-fence.h| 2 ++ > > 4 files changed, 16 insertions(+), 13 deletions(-) Finally pushed this one to drm-misc-fixes. Thanks. Gustavo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: unregister interfaces first in unload
We first need to make sure no one else can get at us anymore,
before we can proceed to tear down all the datastructures.
Just a small step towards eventually the perfect unload code ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3a6dc04bd51e..38990b264b97 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1372,6 +1372,7 @@ void i915_driver_unload(struct drm_device *dev)
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
+ i915_driver_unregister(dev_priv);
if (i915_gem_suspend(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
@@ -1382,7 +1383,6 @@ void i915_driver_unload(struct drm_device *dev)
intel_gvt_cleanup(dev_priv);
- i915_driver_unregister(dev_priv);
intel_modeset_cleanup(dev);
/*
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/atomic-helper: Fix leak in disable_all
The legacy plane->fb pointer is refcounted by calling drm_atomic_clean_old_fb(). In practice this isn't a real problem because: - The caller in the i915 gpu reset code restores the original state again, which means the plane->fb pointer won't change, hence can't leak. - Drivers using drm_atomic_helper_shutdown call the fbdev cleanup first, and that usually cleans up the fb through drm_remove_framebuffer, which does this correctly. - Without fbdev the only framebuffers are from userspace, and those get cleaned up (again using drm_remove_framebuffer) befor the driver can even be unloaded. But in i915 I've switched the cleanup sequence around so that the _shutdown() calls happens after the drm_remove_framebuffer(), which is how I discovered this issue. Cc: martin.pe...@free.fr Cc: ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic_helper.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index b07fc30372d3..71b5f71e61e0 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -2726,6 +2726,7 @@ int drm_atomic_helper_disable_all(struct drm_device *dev, struct drm_plane *plane; struct drm_crtc_state *crtc_state; struct drm_crtc *crtc; + unsigned plane_mask = 0; int ret, i; state = drm_atomic_state_alloc(dev); @@ -2768,10 +2769,14 @@ int drm_atomic_helper_disable_all(struct drm_device *dev, goto free; drm_atomic_set_fb_for_plane(plane_state, NULL); + plane_mask |= BIT(drm_plane_index(plane)); + plane->old_fb = plane->fb; } ret = drm_atomic_commit(state); free: + if (plane_mask) + drm_atomic_clean_old_fb(dev, plane_mask, ret); drm_atomic_state_put(state); return ret; } -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Fix fbdev unload sequence
First thing we need to do is unregister the fbdev instance, but we
can't just go ahead and kfree it. That must wait until the hotplug and
polling work are stopped, since they can race with the with the
teardown. That means we need to split up the fbdev teardown into the
unregister part and the cleanup part.
I originally suspected that this was broken in one of the unload
shuffles, but on closer inspection the oldest sequence I've dug out
also gets this wrong. Just not quite so badly.
I've run drv_module_reload a few hundred times and it's rock solid
compared to insta-death beforehand. This bug seems to have been
uncovered by
commit 88be58be886f1215cc73dc8c273c985eecd7385c
Author: Daniel Vetter
Date: Thu Jul 6 15:00:19 2017 +0200
drm/i915/fbdev: Always forward hotplug events
But the effect of that seems to only be to increase the race window
enough to make it blow up easier. I'm not exactly clear on what's
going on there ...
Testcase: igt/drv_module_reload
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101791
Cc: martin.pe...@free.fr
Cc: ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 3 +--
drivers/gpu/drm/i915/intel_display.c | 3 +++
drivers/gpu/drm/i915/intel_drv.h | 9 +++--
drivers/gpu/drm/i915/intel_fbdev.c | 21 +++--
4 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..3a6dc04bd51e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1240,6 +1240,7 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
*/
static void i915_driver_unregister(struct drm_i915_private *dev_priv)
{
+ intel_fbdev_unregister(dev_priv);
intel_audio_deinit(dev_priv);
intel_gpu_ips_teardown();
@@ -1371,7 +1372,6 @@ void i915_driver_unload(struct drm_device *dev)
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
- intel_fbdev_fini(dev);
if (i915_gem_suspend(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
@@ -1383,7 +1383,6 @@ void i915_driver_unload(struct drm_device *dev)
intel_gvt_cleanup(dev_priv);
i915_driver_unregister(dev_priv);
-
intel_modeset_cleanup(dev);
/*
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ecb4e30673fc..e10fae2faa88 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15111,6 +15111,9 @@ void intel_modeset_cleanup(struct drm_device *dev)
*/
drm_kms_helper_poll_fini(dev);
+ /* poll work can call into fbdev, hence clean that up afterwards */
+ intel_fbdev_fini(dev_priv);
+
intel_unregister_dsm_handler();
intel_fbc_global_disable(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3132260f18ce..7361e983d953 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1597,7 +1597,8 @@ void intel_hpd_poll_init(struct drm_i915_private
*dev_priv);
#ifdef CONFIG_DRM_FBDEV_EMULATION
extern int intel_fbdev_init(struct drm_device *dev);
extern void intel_fbdev_initial_config_async(struct drm_device *dev);
-extern void intel_fbdev_fini(struct drm_device *dev);
+extern void intel_fbdev_unregister(struct drm_i915_private *dev_priv);
+extern void intel_fbdev_fini(struct drm_i915_private *dev_priv);
extern void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool
synchronous);
extern void intel_fbdev_output_poll_changed(struct drm_device *dev);
extern void intel_fbdev_restore_mode(struct drm_device *dev);
@@ -1611,7 +1612,11 @@ static inline void
intel_fbdev_initial_config_async(struct drm_device *dev)
{
}
-static inline void intel_fbdev_fini(struct drm_device *dev)
+static inline void intel_fbdev_unregister(struct drm_i915_private *dev_priv)
+{
+}
+
+static inline void intel_fbdev_fini(struct drm_i915_private *dev_priv)
{
}
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index b953365a3eec..82280e104692 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -538,8 +538,6 @@ static void intel_fbdev_destroy(struct intel_fbdev *ifbdev)
* trying to rectify all the possible error paths leading here.
*/
- drm_fb_helper_unregister_fbi(&ifbdev->helper);
-
drm_fb_helper_fini(&ifbdev->helper);
if (ifbdev->vma) {
@@ -727,8 +725,10 @@ static void intel_fbdev_initial_config(void *data,
async_cookie_t cookie)
/* Due to peculiar init order wrt to hpd handling this is separate. */
if (drm_fb_helper_initial_config(&ifbdev->helper,
-ifbdev->preferred_bpp))
- intel_fbdev_fini(ifbdev-
Re: [Intel-gfx] [PATCH 2/4] drm: Create a format/modifier blob
On Fri, Jul 14, 2017 at 11:41:49AM -0700, Ben Widawsky wrote: > On 17-06-29 22:49:44, Ville Syrjälä wrote: > > [snip] > > > > >... but here it's ALIGN(formats_offset+formats_size). I think we should > >be aligning the same thing in both cases, or we add a BUILD_BUG_ON to > >make sure the header size always stays a multiple of 8 bytes. > > > >That's mainly because the design of the structure seems geared towards > >expanding the header in the future (as in why else would you have the > >offsets?). > > > > I guess I don't quite understand what you're asking for. The first thing is > determining a size, the second is finding an offset into the blob. If I remember my thinking correctly, then what I was trying to say was ALIGN(multiple_of_4, 8) + ALIGN(multiple_of_4, 8) != ALIGN(multiple_of_4 + multiple_of_4, 8) but the code was assuming that it's true, or that at least one of those things is a multiple of 8 already. > I don't mind changing this, but tell me what you want. > > BUILD_BUG_ON sounds good to me regardless. > > [snip] > > -- > Ben Widawsky, Intel Open Source Technology Center -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/14] YCBCR 4:2:0 handling in DRM layer
On Thu, Jul 13, 2017 at 09:03:06PM +0530, Shashank Sharma wrote: > Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format, > which is currently supported on HDMI 2.0 sources/sinks. Due to lower > chroma sub-sampling rate, YCBCR 4:2:0 can drive the video modes at half > the pixel clock than YCBCR 4:4:4 or RGB 8:8:8 outputs. For example, a CEA > 4K@60, RGB 8:8:8 mode needs a clock of appx 594Mhz, but it can be driven at > 297Mhz using YCBCR 4:2:0 output. > > Of course, the lower rate of chroma subsampling, causes the quality of YCBCR > 4:2:0 to be lower than YCBCR 4:4:4 or RGB 8:8:8. > > This patch series adds support for YCBCR 4:2:0 output in DRM layer. > > - First 2 patches, complete the CEA mode-db in drm driver, by adding > new 4k modes. Current CEA mode-db contains 64 modes only (VIC 1-64), > whereas CEA-861-F defined VICs up to 107, including 4k modes, from VIC > range 93-107. First patch makes sure that inclusion of these modes doesn't > break existing HDMI 1.4 monitors, across various drivers. > > - Next 5 patches focus on parsing new YCBCR 4:2:0 EDID blocks, and adding > YCBCR 4:2:0 modes in connector. They also contain a prune function, which > will cleanup the YCBCR 4:2:0 modes from list, if the connector doesn't > declare them supported. > > - Next 2 patches add helper functions for identifing YCBCR 4:2:0 modes and > setup the color space in AVI infoframes. > > - Next 6 patches add code for I915 layer handling of YCBCR 4:2:0 output. > > This patch series was initially published as a complete framework to handle > all YCBCR outputs (4:4:4, 4:2:2, 4:2:0), but based on the code reviews, now > its been published as YCBCR 4:2:0 handling series only. > > The previous discussion and reviews can be found here: > V5: https://patchwork.freedesktop.org/series/26815/ > V1-V4: https://patchwork.freedesktop.org/series/22683/ > > Now re-publishing this patch series as YCBCR 4:2:0 handling series here. > V2: Addressed review comments from Ville > This series dropped one patch in V2(patch 8 from V1), so 14 patches in V2 > > This series has been tested with drm-tip code with following setup: > Source: Intel Geminilake device. > Sink: ACER S277HK HDMI 2.0 monitor. > Protocol testing: Astro VA-1844A HDMI analyzer. > > Shashank Sharma (14): > drm: handle HDMI 2.0 VICs in AVI info-frames > drm/edid: complete CEA modedb(VIC 1-107) > drm/edid: parse sink information before CEA blocks > drm/edid: cleanup patch for CEA extended-tag macro > drm: add helper to validate YCBCR420 modes > drm/edid: parse YCBCR420 videomodes from EDID > drm/edid: parse ycbcr 420 deep color information > drm: add helper functions for YCBCR420 handling I just finished pushing the core bits into drm-misc-next. But I'm not super happy how that went because there were still quite a few trivial checkpatch warnings and indentation issues I had to fix up. All of that should have been dealt with before even submitting the patches to the list. Review bandwidth is a scarce resource so we don't want to squander it on this sort of stuff. Another issue I ran into when I tried to actually run the code. As soon as I loaded the driver a warning and the accompanying backtrace from the state checker flew past my terminal. That too should have been caught before even sending the patches to the list. So I think the next time someone asks me to review something I will start by asking these basic questions: - Did you configure your editor so that it automagically formats code correctly? - Did you check for new compiler/sparse/checkpatch warnings? - Did you check for new runtime errors/warnings from the driver? If the answer to any of those is "no", then I won't even bother reviewing anything. OK, that's enough ranting. Now for the more positive feedback. The code does work for me, for the mose part. There is some kind of initial problem though. When I first load the driver I get some kind of weird shifted grey screen. So I guess either we're misconfiguring something in the source, or we're not properly telling the sink what we're sending it. After another modeset the problem goes away and everything appears to work correctly. So congrats on making that happen \o/ > drm/i915: add config function for YCBCR420 outputs > drm/i915: prepare scaler for YCBCR420 modeset > drm/i915: prepare pipe for YCBCR420 output > drm/i915: prepare csc unit for YCBCR420 output > drm/i915: set colorspace for YCBCR420 outputs > drm/i915/glk: set HDMI 2.0 identifier These remaining i915 patches still have a few issues, the lack of state readout and the grey screen issue are the major ones. I've left more detailed feedback on the individual patches, but right now I don't have a clear idea what's causing the grey screen. Assuming the remaining issues I've highlighted get fixed, and the remaining patches won't get massively altered in the process, you can slap Reviewed-by: Ville Syrjälä onto the patches. > >
Re: [Intel-gfx] [PATCH 2/4] drm: Create a format/modifier blob
On 17-06-29 22:49:44, Ville Syrjälä wrote: [snip] ... but here it's ALIGN(formats_offset+formats_size). I think we should be aligning the same thing in both cases, or we add a BUILD_BUG_ON to make sure the header size always stays a multiple of 8 bytes. That's mainly because the design of the structure seems geared towards expanding the header in the future (as in why else would you have the offsets?). I guess I don't quite understand what you're asking for. The first thing is determining a size, the second is finding an offset into the blob. I don't mind changing this, but tell me what you want. BUILD_BUG_ON sounds good to me regardless. [snip] -- Ben Widawsky, 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 v2 12/14] drm/i915: prepare csc unit for YCBCR420 output
On Thu, Jul 13, 2017 at 09:03:18PM +0530, Shashank Sharma wrote:
> To support ycbcr output, we need a pipe CSC block to do
> RGB->YCBCR conversion.
>
> Current Intel platforms have only one pipe CSC unit, so
> we can either do color correction using it, or we can perform
> RGB->YCBCR conversion.
>
> This function adds a csc handler, which uses recommended bspec
> values to perform RGB->YCBCR conversion (target color space BT709)
>
> V2: Rebase
> V3: Rebase
> V4: Rebase
> V5: Addressed review comments from Ander
> - Remove extra line added in the patch
> - Add the spec details in the commit message
> - Combine two if(cond) while calling intel_crtc_compute_config
> V6: Handle YCBCR420 outputs only (Ville)
> V7: Addressed review comments from Ville:
> - Add description about target colorspace
> - Remove the comments from CSC function
> - DRM_DEBUG->DEBUG_KMS for atomic failure due to CSC unit busy
> - Remove unnecessary debug message about YCBCR420 possibe
>
> Cc: Ville Syrjala
> Cc: Daniel Vetter
> Cc: Ander Conselvan de Oliveira
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_color.c | 46
> +++-
> drivers/gpu/drm/i915/intel_display.c | 15
> 2 files changed, 60 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index f85d575..8698691 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -41,6 +41,22 @@
>
> #define LEGACY_LUT_LENGTH(sizeof(struct drm_color_lut) * 256)
>
> +/* Post offset values for RGB->YCBCR conversion */
> +#define POSTOFF_RGB_TO_YUV_HI 0x800
> +#define POSTOFF_RGB_TO_YUV_ME 0x100
> +#define POSTOFF_RGB_TO_YUV_LO 0x800
> +
> +/*
> + * These values are direct register values specified in the Bspec,
> + * for RGB->YUV conversion matrix (colorspace BT709)
> + */
> +#define CSC_RGB_TO_YUV_RU_GU 0x2ba809d8
> +#define CSC_RGB_TO_YUV_BU 0x37e8
> +#define CSC_RGB_TO_YUV_RY_GY 0x1e089cc0
> +#define CSC_RGB_TO_YUV_BY 0xb528
> +#define CSC_RGB_TO_YUV_RV_GV 0xbce89ad8
> +#define CSC_RGB_TO_YUV_BV 0x1e08
> +
> /*
> * Extract the CSC coefficient from a CTM coefficient (in U32.32 fixed point
> * format). This macro takes the coefficient we want transformed and the
> @@ -91,6 +107,31 @@ static void ctm_mult_by_limited(uint64_t *result, int64_t
> *input)
> }
> }
>
> +void i9xx_load_ycbcr_conversion_matrix(struct intel_crtc *intel_crtc)
> +{
> + int pipe = intel_crtc->pipe;
> + struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> +
> +
> + I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
> + I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
> + I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
> +
> + I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), CSC_RGB_TO_YUV_RU_GU);
> + I915_WRITE(PIPE_CSC_COEFF_BU(pipe), CSC_RGB_TO_YUV_BU);
> +
> + I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), CSC_RGB_TO_YUV_RY_GY);
> + I915_WRITE(PIPE_CSC_COEFF_BY(pipe), CSC_RGB_TO_YUV_BY);
> +
> + I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), CSC_RGB_TO_YUV_RV_GV);
> + I915_WRITE(PIPE_CSC_COEFF_BV(pipe), CSC_RGB_TO_YUV_BV);
> +
> + I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
> + I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
> + I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
> + I915_WRITE(PIPE_CSC_MODE(pipe), 0);
> +}
> +
> /* Set up the pipe CSC unit. */
> static void i9xx_load_csc_matrix(struct drm_crtc_state *crtc_state)
> {
> @@ -101,7 +142,10 @@ static void i9xx_load_csc_matrix(struct drm_crtc_state
> *crtc_state)
> uint16_t coeffs[9] = { 0, };
> struct intel_crtc_state *intel_crtc_state =
> to_intel_crtc_state(crtc_state);
>
> - if (crtc_state->ctm) {
> + if (intel_crtc_state->ycbcr420) {
> + i9xx_load_ycbcr_conversion_matrix(intel_crtc);
> + return;
> + } else if (crtc_state->ctm) {
> struct drm_color_ctm *ctm =
> (struct drm_color_ctm *)crtc_state->ctm->data;
> uint64_t input[9] = { 0, };
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 1a23ec0..9c6a1ed 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6283,6 +6283,21 @@ static int intel_crtc_compute_config(struct intel_crtc
> *crtc,
> return -EINVAL;
> }
>
> + /* YCBCR420 feasibility check */
Not a useful comment.
> + if (pipe_config->ycbcr420) {
> + struct drm_crtc_state *drm_state = &pipe_config->base;
Having aliasing pointer for the same thing is just annoying.
We do have quite a lot of that going around, but IMO we need
to clean that all up at some point.
So pls just do this instead:
if (pipe_config->ycbcr420 && pipe_config->base.ctm) {
...
}
> +
> + /*
>
Re: [Intel-gfx] [PATCH v2 11/14] drm/i915: prepare pipe for YCBCR420 output
On Thu, Jul 13, 2017 at 09:03:17PM +0530, Shashank Sharma wrote:
> To get HDMI YCBCR420 output, the PIPEMISC register should be
> programmed to:
> - Generate YCBCR output (bit 11)
> - In case of YCBCR420 outputs, it should be programmed in full
> blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
>
> This patch:
> - Adds definition of these bits.
> - Programs PIPEMISC for YCBCR420 outputs.
>
> V2: rebase
> V3: rebase
> V4: rebase
> V5: added r-b from Ander
> V6: Handle only YCBCR420 outputs (ville)
> V7: rebase
>
> Cc: Ville Syrjala
> Cc: Ander Conselvan de Oliveira
> Cc: Daniel Vetter
>
> Reviewed-by: Ander Conselvan de Oliveira
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i915/intel_display.c | 7 +++
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c712d01..e5020d6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5227,6 +5227,9 @@ enum {
>
> #define _PIPE_MISC_A 0x70030
> #define _PIPE_MISC_B 0x71030
> +#define PIPEMISC_YCBCR420_ENABLE (1<<27)
> +#define PIPEMISC_YCBCR420_MODE_BLEND (1<<26)
> +#define PIPEMISC_OUTPUT_YCBCR (1<<11)
Please rename to match spec. So something like:
PIPEMISC_YUV420_ENABLE (1<<27)
PIPEMISC_YUV420_MODE_FULL_BLEND (1<<26)
PIPEMISC_OUTPUT_COLORSPACE_YUV (1<<11)
> #define PIPEMISC_DITHER_BPC_MASK (7<<5)
> #define PIPEMISC_DITHER_8_BPC (0<<5)
> #define PIPEMISC_DITHER_10_BPC (1<<5)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index d78f1c2..1a23ec0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8076,6 +8076,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct intel_crtc_state *config = intel_crtc->config;
>
> if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
> u32 val = 0;
> @@ -8101,6 +8102,12 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
> if (intel_crtc->config->dither)
> val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
>
> + if (config->ycbcr420) {
> + val |= PIPEMISC_OUTPUT_YCBCR |
> + PIPEMISC_YCBCR420_ENABLE |
> + PIPEMISC_YCBCR420_MODE_BLEND;
> + }
I think we'll want two flags. One to specify whether we're outputting
YCbCr and the other to indicate whether we need the 4:2:0 subsamling.
So maybe something like
bool ycbcr;
bool ycbcr420;
We also need state readout for this stuff. With those two flags I think
we can do something like:
if (IS_BDW || GEN >= 9) {
tmp = READ(PIPEMISC);
crtc_state->ycbcr = tmp & OUTPUT_YUV;
if (IS_GLK || GEN >= 10)
crtc_state->ycbcr420 = tmp & YUV420_ENABLE;
}
The other missing readout thing is adjustment of the clock.
ddi_dotclock_get() will need to double the dotclock when we're
outputting ycbcr420.
Pls also add something along the lines of
DRM_DEBUG_KMS("ycbcr: %i, ycbcr420: %i\n", ...);
to intel_dump_pipe_config() so that we can actually tell when we're
outputting YCbCr and 4:2:0.
> +
> I915_WRITE(PIPEMISC(intel_crtc->pipe), val);
> }
> }
> --
> 2.7.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 10/14] drm/i915: prepare scaler for YCBCR420 modeset
On Thu, Jul 13, 2017 at 09:03:16PM +0530, Shashank Sharma wrote:
> To get a YCBCR420 output from intel platforms, we need one
> scaler to scale down YCBCR444 samples to YCBCR420 samples.
>
> This patch:
> - Does scaler allocation for HDMI ycbcr420 outputs.
> - Programs PIPE_MISC register for ycbcr420 output.
> - Adds a new scaler user "HDMI output" to plug-into existing
> scaler framework. This output type is identified using bit
> 30 of the scaler users bitmap.
>
> V2: rebase
> V3: rebase
> V4: rebase
> V5: addressed review comments from Ander:
> - No need to check both scaler_user && hdmi_output.
> Check for scaler_user is enough.
> V6: rebase
> V7: Do not create a new scaler user, use existing pipe scaler user.
>
> Cc: Ville Syrjala
> Cc: Ander Conselvan De Oliveira
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 +++
> drivers/gpu/drm/i915/intel_drv.h | 4 +++-
> drivers/gpu/drm/i915/intel_hdmi.c| 12
> drivers/gpu/drm/i915/intel_panel.c | 3 ++-
> 4 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a5140e4..d78f1c2 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4624,6 +4624,9 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
> bool force_detach,
>*/
> need_scaling = src_w != dst_w || src_h != dst_h;
>
> + if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
> + need_scaling = true;
> +
> /*
>* Scaling/fitting not supported in IF-ID mode in GEN9+
>* TODO: Interlace fetch mode doesn't support YUV420 planar formats.
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 592243b..94ea6ed 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -471,7 +471,8 @@ struct intel_crtc_scaler_state {
>*
>* If a bit is set, a user is using a scaler.
>* Here user can be a plane or crtc as defined below:
> - * bits 0-30 - plane (bit position is index from drm_plane_index)
> + * bits 0-29 - plane (bit position is index from drm_plane_index)
> + * bit 30- hdmi output
That's no longer true.
>* bit 31- crtc
>*
>* Instead of creating a new index to cover planes and crtc, using
> @@ -484,6 +485,7 @@ struct intel_crtc_scaler_state {
>* avilability.
>*/
> #define SKL_CRTC_INDEX 31
> +
Bogus whitespace change.
> unsigned scaler_users;
>
> /* scaler used by crtc for panel fitting purpose */
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index eb6243c..49f4fb8 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1356,6 +1356,7 @@ intel_hdmi_ycbcr420_config(struct drm_connector
> *connector,
> struct intel_crtc_state *config,
> int *clock_12bpc, int *clock_8bpc)
> {
> + struct intel_crtc *intel_crtc = to_intel_crtc(config->base.crtc);
>
> if (!connector->ycbcr_420_allowed) {
> DRM_ERROR("Platform doesn't support YCBCR420 output\n");
> @@ -1367,6 +1368,17 @@ intel_hdmi_ycbcr420_config(struct drm_connector
> *connector,
> *clock_12bpc /= 2;
> *clock_8bpc /= 2;
> config->ycbcr420 = true;
> +
> + /* YCBCR 420 output conversion needs a scaler */
> + if (skl_update_scaler_crtc(config)) {
> + DRM_ERROR("Scaler allocation for output failed\n");
DRM_DEBUG_KMS
> + return false;
> + }
> +
> + /* Bind this scaler to pipe */
Unnecesary comment.
> + intel_pch_panel_fitting(intel_crtc, config,
> + DRM_MODE_SCALE_FULLSCREEN);
> +
> return true;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index 96c2cbd..fd2e081 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -110,7 +110,8 @@ intel_pch_panel_fitting(struct intel_crtc *intel_crtc,
>
> /* Native modes don't need fitting */
> if (adjusted_mode->crtc_hdisplay == pipe_config->pipe_src_w &&
> - adjusted_mode->crtc_vdisplay == pipe_config->pipe_src_h)
> + adjusted_mode->crtc_vdisplay == pipe_config->pipe_src_h &&
> + !pipe_config->ycbcr420)
> goto done;
>
> switch (fitting_mode) {
> --
> 2.7.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 09/14] drm/i915: add config function for YCBCR420 outputs
On Thu, Jul 13, 2017 at 09:03:15PM +0530, Shashank Sharma wrote:
> This patch checks encoder level support for YCBCR420 outputs.
> The logic goes as simple as this:
> If the input mode is YCBCR420-only mode: prepare HDMI for
> YCBCR420 output, else continue with RGB output mode.
>
> It checks if the mode is YCBCR420 and source can support this
> output then it marks the ycbcr_420 output indicator into crtc
> state, for further staging in driver.
>
> V2: Split the patch into two, kept helper functions in DRM layer.
> V3: Changed the compute_config function based on new DRM API.
> V4: Rebase
> V5: Rebase
> V6: Check and handle YCBCR420-only modes, discard the property
> based approach (Ville)
> V7: Addressed review comments from Ville
> - add else case in 12BPC check.
> - extract ycbcr420 state inside hdmi_12bpc_possible function.
>
> Cc: Ville Syrjala
> Cc: Daniel Vetter
> Cc: Ander Conselvan de Oliveira
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_display.c | 1 +
> drivers/gpu/drm/i915/intel_drv.h | 3 +++
> drivers/gpu/drm/i915/intel_hdmi.c| 43
> +---
> 3 files changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 2144adc..a5140e4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11945,6 +11945,7 @@ intel_pipe_config_compare(struct drm_i915_private
> *dev_priv,
> PIPE_CONF_CHECK_I(hdmi_scrambling);
> PIPE_CONF_CHECK_I(hdmi_high_tmds_clock_ratio);
> PIPE_CONF_CHECK_I(has_infoframe);
> + PIPE_CONF_CHECK_I(ycbcr420);
>
> PIPE_CONF_CHECK_I(has_audio);
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d17a324..592243b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -780,6 +780,9 @@ struct intel_crtc_state {
>
> /* HDMI High TMDS char rate ratio */
> bool hdmi_high_tmds_clock_ratio;
> +
> + /* HDMI output type */
We'll want DP too at some point. So that's going to get stale pretty
soon.
> + bool ycbcr420;
> };
>
> struct intel_crtc {
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index cc0d100..eb6243c 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1312,6 +1312,7 @@ static bool hdmi_12bpc_possible(struct intel_crtc_state
> *crtc_state)
> struct drm_atomic_state *state = crtc_state->base.state;
> struct drm_connector_state *connector_state;
> struct drm_connector *connector;
> + bool output_ycbcr420 = crtc_state->ycbcr420;
Pointless variable. Just use 'crtc_state->ycbcr420' in the code
directly.
> int i;
>
> if (HAS_GMCH_DISPLAY(dev_priv))
> @@ -1330,8 +1331,16 @@ static bool hdmi_12bpc_possible(struct
> intel_crtc_state *crtc_state)
> if (connector_state->crtc != crtc_state->base.crtc)
> continue;
>
> - if ((info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36) == 0)
> - return false;
> + if (output_ycbcr420) {
> + const struct drm_hdmi_info *hdmi = &info->hdmi;
> +
> + if (!(hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36))
> + return false;
> + } else {
> +
Bogus whitespace.
> + if (!(info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36))
> + return false;
> + }
> }
>
> /* Display Wa #1139 */
> @@ -1342,6 +1351,25 @@ static bool hdmi_12bpc_possible(struct
> intel_crtc_state *crtc_state)
> return true;
> }
>
> +static bool
> +intel_hdmi_ycbcr420_config(struct drm_connector *connector,
> +struct intel_crtc_state *config,
> +int *clock_12bpc, int *clock_8bpc)
> +{
> +
Bogus whitespace.
> + if (!connector->ycbcr_420_allowed) {
> + DRM_ERROR("Platform doesn't support YCBCR420 output\n");
> + return false;
> + }
> +
> + /* YCBCR420 TMDS rate requirement is half the pixel clock */
> + config->port_clock /= 2;
> + *clock_12bpc /= 2;
> + *clock_8bpc /= 2;
> + config->ycbcr420 = true;
> + return true;
> +}
> +
> bool intel_hdmi_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config,
> struct drm_connector_state *conn_state)
> @@ -1349,7 +1377,8 @@ bool intel_hdmi_compute_config(struct intel_encoder
> *encoder,
> struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
> - struct drm_scdc *scdc = &conn_
Re: [Intel-gfx] [PATCH v2 i-g-t] igt/perf: add tests to verify create/destroy userspace configs
On 14 July 2017 at 18:57, Lionel Landwerlin
wrote:
> On 14/07/17 18:09, Matthew Auld wrote:
>>
>> On 13 July 2017 at 12:16, Lionel Landwerlin
>> wrote:
>>>
>>> v2: Add tests regarding removing configs (Matthew)
>>> Add tests regarding adding/removing configs without permissions
>>> (Matthew)
>>>
>>> Signed-off-by: Lionel Landwerlin
>>> ---
>>> tests/perf.c | 201
>>> +++
>>> 1 file changed, 201 insertions(+)
>>
>> I still think it would be nice to have at least have some flex tests,
>> especially if we consider the issue with not reserving enough dwords,
>> even if it's a pita...
>
>
> Well the current test were testing exactly that, and we didn't see any
> errors.
> Because in most cases, the back of the batchbuffer will just get rewritten
> by the next batch.
Assuming we don't reserve enough dwords then intel_ring_advance()
should catch this, it checks the advanced cs against the number of
reserved dwords from intel_ring_begin(), so we should be hitting the
GEM_BUG_ON(), unless I'm glossing over something. Do you have
DEBUG_GEM enabled?
>
> Apart from testing the if (reg >= xxx && reg =< yyy), I don't know that we
> can test anything interesting here :(
I was thinking flex configs with n_regs < max_flex, and also n_regs > max_flex.
>
>
>
>>
>>> diff --git a/tests/perf.c b/tests/perf.c
>>> index db28ba1f..47caf1c6 100644
>>> --- a/tests/perf.c
>>> +++ b/tests/perf.c
>>> @@ -146,6 +146,36 @@ enum drm_i915_perf_record_type {
>>> };
>>> #endif /* !DRM_I915_PERF_OPEN */
>>>
>>> +#ifndef DRM_IOCTL_I915_PERF_ADD_CONFIG
>>> +
>>> +#define DRM_I915_PERF_ADD_CONFIG 0x37
>>> +#define DRM_I915_PERF_REMOVE_CONFIG0x38
>>> +
>>> +#define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOWR(DRM_COMMAND_BASE +
>>> DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
>>> +#define DRM_IOCTL_I915_PERF_REMOVE_CONFIG DRM_IOWR(DRM_COMMAND_BASE
>>> + DRM_I915_PERF_REMOVE_CONFIG, __u64)
>>> +
>>> +/**
>>> + * Structure to upload perf dynamic configuration into the kernel.
>>> + */
>>> +struct drm_i915_perf_oa_config {
>>> + /** String formatted like "%08x-%04x-%04x-%04x-%012x" */
>>> + __u64 uuid;
>>> +
>>> + __u32 n_mux_regs;
>>> + __u32 pad0;
>>> + __u64 mux_regs;
>>> +
>>> + __u32 n_boolean_regs;
>>> + __u32 pad1;
>>> + __u64 boolean_regs;
>>> +
>>> + __u32 n_flex_regs;
>>> + __u32 pad2;
>>> + __u64 flex_regs;
>>> +};
>>> +
>>> +#endif /* !DRM_IOCTL_I915_PERF_ADD_CONFIG */
>>> +
>>> struct accumulator {
>>> #define MAX_RAW_OA_COUNTERS 62
>>> enum drm_i915_oa_format format;
>>> @@ -4001,6 +4031,168 @@ test_rc6_disable(void)
>>> igt_assert_neq(n_events_end - n_events_start, 0);
>>> }
>>>
>>> +static void
>>> +test_invalid_userspace_config_create(void)
>>> +{
>>> + struct drm_i915_perf_oa_config config;
>>> + const char *uuid = "01234567-0123-0123-0123-0123456789ab";
>>> + const char *invalid_uuid = "blablabla-wrong";
>>> + uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
>>> + uint32_t invalid_mux_regs[] = { 0x12345678 /* invalid register
>>> */, 0x0 };
>>> +
>>> + memset(&config, 0, sizeof(config));
>>> +
>>> + /* invalid uuid */
>>> + config.uuid = to_user_pointer(invalid_uuid);
>>> + config.n_mux_regs = 1;
>>> + config.mux_regs = to_user_pointer(mux_regs);
>>> + config.n_boolean_regs = 0;
>>> + config.n_flex_regs = 0;
>>> +
>>> + do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config,
>>> EINVAL);
>>> +
>>> + /* invalid mux_regs */
>>> + config.uuid = to_user_pointer(uuid);
>>> + config.n_mux_regs = 1;
>>> + config.mux_regs = to_user_pointer(invalid_mux_regs);
>>> + config.n_boolean_regs = 0;
>>> + config.n_flex_regs = 0;
>>> +
>>> + do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config,
>>> EINVAL);
>>> +
>>> + /* empty config */
>>> + config.uuid = to_user_pointer(uuid);
>>> + config.n_mux_regs = 0;
>>> + config.mux_regs = to_user_pointer(mux_regs);
>>> + config.n_boolean_regs = 0;
>>> + config.n_flex_regs = 0;
>>> +
>>> + do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config,
>>> EINVAL);
>>> +
>>> + /* empty config with null pointers */
>>> + config.uuid = to_user_pointer(uuid);
>>> + config.n_mux_regs = 1;
>>> + config.mux_regs = to_user_pointer(NULL);
>>> + config.n_boolean_regs = 2;
>>> + config.boolean_regs = to_user_pointer(NULL);
>>> + config.n_flex_regs = 3;
>>> + config.flex_regs = to_user_pointer(NULL);
>>> +
>>> + do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config,
>>> EINVAL);
>>> +}
>>> +
>>> +static void
>>> +test_invalid_userspace_config_remove(void)
>>> +{
>>> + struct drm_i915_perf_oa_config config;
>>> + const char *uuid = "01234567-0123-0123-0123-0123456789ab";
>>> +
Re: [Intel-gfx] [PATCH] drm/i915: cleanup the CHICKEN_MISC_2 (re)definitions
oh! I believe you had warned me about this beforehand but I forgot... sorry
Reviewed-by: Rodrigo Vivi
On Fri, Jul 14, 2017 at 10:52 AM, Paulo Zanoni wrote:
> * Don't define it twice.
> * Define MSBs first, like the rest of i915_reg.h.
> * Add CNL_ prefix to the bit that arrived in CNL.
>
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 8 +++-
> drivers/gpu/drm/i915/intel_runtime_pm.c | 4 ++--
> 2 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c712d01..a16bf67 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6703,12 +6703,10 @@ enum {
> #define KVM_CONFIG_CHANGE_NOTIFICATION_SELECT (1 << 14)
>
> #define CHICKEN_MISC_2 _MMIO(0x42084)
> -#define GLK_CL0_PWR_DOWN (1 << 10)
> -#define GLK_CL1_PWR_DOWN (1 << 11)
> +#define CNL_COMP_PWR_DOWN (1 << 23)
> #define GLK_CL2_PWR_DOWN (1 << 12)
> -
> -#define CHICKEN_MISC_2 _MMIO(0x42084)
> -#define COMP_PWR_DOWN (1 << 23)
> +#define GLK_CL1_PWR_DOWN (1 << 11)
> +#define GLK_CL0_PWR_DOWN (1 << 10)
>
> #define _CHICKEN_PIPESL_1_A0x420b0
> #define _CHICKEN_PIPESL_1_B0x420b4
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index f630d63..45bdcd0 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -2820,7 +2820,7 @@ static void cnl_display_core_init(struct
> drm_i915_private *dev_priv, bool resume
>
> /* 2. Enable Comp */
> val = I915_READ(CHICKEN_MISC_2);
> - val &= ~COMP_PWR_DOWN;
> + val &= ~CNL_COMP_PWR_DOWN;
> I915_WRITE(CHICKEN_MISC_2, val);
>
> val = I915_READ(CNL_PORT_COMP_DW3);
> @@ -2894,7 +2894,7 @@ static void cnl_display_core_uninit(struct
> drm_i915_private *dev_priv)
>
> /* 5. Disable Comp */
> val = I915_READ(CHICKEN_MISC_2);
> - val |= COMP_PWR_DOWN;
> + val |= CNL_COMP_PWR_DOWN;
> I915_WRITE(CHICKEN_MISC_2, val);
> }
>
> --
> 2.9.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: cleanup the CHICKEN_MISC_2 (re)definitions
== Series Details == Series: drm/i915: cleanup the CHICKEN_MISC_2 (re)definitions URL : https://patchwork.freedesktop.org/series/27321/ State : success == Summary == Series 27321v1 drm/i915: cleanup the CHICKEN_MISC_2 (re)definitions https://patchwork.freedesktop.org/api/1.0/series/27321/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-r) fdo#100125 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:440s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:429s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:354s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:532s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:503s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:493s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:491s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:600s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:439s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:416s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:415s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:493s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:466s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:578s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:583s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:568s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:466s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:583s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:470s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:475s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:441s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:468s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:546s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:407s e1306e0d65a3a850838534019a9a61e73bf1efcc drm-tip: 2017y-07m-14d-13h-56m-32s UTC integration manifest 8cd1822 drm/i915: cleanup the CHICKEN_MISC_2 (re)definitions == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5195/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 i-g-t] igt/perf: add tests to verify create/destroy userspace configs
On 14/07/17 18:09, Matthew Auld wrote:
On 13 July 2017 at 12:16, Lionel Landwerlin
wrote:
v2: Add tests regarding removing configs (Matthew)
Add tests regarding adding/removing configs without permissions
(Matthew)
Signed-off-by: Lionel Landwerlin
---
tests/perf.c | 201 +++
1 file changed, 201 insertions(+)
I still think it would be nice to have at least have some flex tests,
especially if we consider the issue with not reserving enough dwords,
even if it's a pita...
Well the current test were testing exactly that, and we didn't see any
errors.
Because in most cases, the back of the batchbuffer will just get
rewritten by the next batch.
Apart from testing the if (reg >= xxx && reg =< yyy), I don't know that
we can test anything interesting here :(
diff --git a/tests/perf.c b/tests/perf.c
index db28ba1f..47caf1c6 100644
--- a/tests/perf.c
+++ b/tests/perf.c
@@ -146,6 +146,36 @@ enum drm_i915_perf_record_type {
};
#endif /* !DRM_I915_PERF_OPEN */
+#ifndef DRM_IOCTL_I915_PERF_ADD_CONFIG
+
+#define DRM_I915_PERF_ADD_CONFIG 0x37
+#define DRM_I915_PERF_REMOVE_CONFIG0x38
+
+#define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
+#define DRM_IOCTL_I915_PERF_REMOVE_CONFIG DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_PERF_REMOVE_CONFIG, __u64)
+
+/**
+ * Structure to upload perf dynamic configuration into the kernel.
+ */
+struct drm_i915_perf_oa_config {
+ /** String formatted like "%08x-%04x-%04x-%04x-%012x" */
+ __u64 uuid;
+
+ __u32 n_mux_regs;
+ __u32 pad0;
+ __u64 mux_regs;
+
+ __u32 n_boolean_regs;
+ __u32 pad1;
+ __u64 boolean_regs;
+
+ __u32 n_flex_regs;
+ __u32 pad2;
+ __u64 flex_regs;
+};
+
+#endif /* !DRM_IOCTL_I915_PERF_ADD_CONFIG */
+
struct accumulator {
#define MAX_RAW_OA_COUNTERS 62
enum drm_i915_oa_format format;
@@ -4001,6 +4031,168 @@ test_rc6_disable(void)
igt_assert_neq(n_events_end - n_events_start, 0);
}
+static void
+test_invalid_userspace_config_create(void)
+{
+ struct drm_i915_perf_oa_config config;
+ const char *uuid = "01234567-0123-0123-0123-0123456789ab";
+ const char *invalid_uuid = "blablabla-wrong";
+ uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
+ uint32_t invalid_mux_regs[] = { 0x12345678 /* invalid register */, 0x0
};
+
+ memset(&config, 0, sizeof(config));
+
+ /* invalid uuid */
+ config.uuid = to_user_pointer(invalid_uuid);
+ config.n_mux_regs = 1;
+ config.mux_regs = to_user_pointer(mux_regs);
+ config.n_boolean_regs = 0;
+ config.n_flex_regs = 0;
+
+ do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
+
+ /* invalid mux_regs */
+ config.uuid = to_user_pointer(uuid);
+ config.n_mux_regs = 1;
+ config.mux_regs = to_user_pointer(invalid_mux_regs);
+ config.n_boolean_regs = 0;
+ config.n_flex_regs = 0;
+
+ do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
+
+ /* empty config */
+ config.uuid = to_user_pointer(uuid);
+ config.n_mux_regs = 0;
+ config.mux_regs = to_user_pointer(mux_regs);
+ config.n_boolean_regs = 0;
+ config.n_flex_regs = 0;
+
+ do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
+
+ /* empty config with null pointers */
+ config.uuid = to_user_pointer(uuid);
+ config.n_mux_regs = 1;
+ config.mux_regs = to_user_pointer(NULL);
+ config.n_boolean_regs = 2;
+ config.boolean_regs = to_user_pointer(NULL);
+ config.n_flex_regs = 3;
+ config.flex_regs = to_user_pointer(NULL);
+
+ do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
+}
+
+static void
+test_invalid_userspace_config_remove(void)
+{
+ struct drm_i915_perf_oa_config config;
+ const char *uuid = "01234567-0123-0123-0123-0123456789ab";
+ uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
+ uint64_t config_id, wrong_config_id = 9;
+ char path[512];
+ int ret;
+
+ snprintf(path, sizeof(path), "/sys/class/drm/card%d/metrics/%s/id",
card, uuid);
+
+ /* Destroy previous configuration if present */
+ if (try_read_u64_file(path, &config_id))
+ igt_assert(igt_ioctl(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG,
&config_id) == 0);
+
+ memset(&config, 0, sizeof(config));
+
+ config.uuid = to_user_pointer(uuid);
+
+ config.n_mux_regs = 1;
+ config.mux_regs = to_user_pointer(mux_regs);
+ config.n_boolean_regs = 0;
+ config.n_flex_regs = 0;
+
+ ret = igt_ioctl(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config);
+ igt_assert(ret > 0);
+ config_id = ret;
+
+ /* Removing configs without permissions should fail. */
+ igt_fork(child, 1)
Re: [Intel-gfx] [PATCH] drm/i915/cnl: New DMC release: 1.05.
On 07/12/2017 04:47 PM, Rodrigo Vivi wrote: Version 1.05 is now available for CNL. According to its release notes the only difference is: - Change from aux A pwrreq always turn on during restore, to saving and restoring aux A pwrreq. Reviewed-by: Clinton Taylor -Clint Anusha Srivatsa Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_csr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c index 965988f79a55..2dc46651f27a 100644 --- a/drivers/gpu/drm/i915/intel_csr.c +++ b/drivers/gpu/drm/i915/intel_csr.c @@ -37,8 +37,8 @@ #define I915_CSR_GLK "i915/glk_dmc_ver1_04.bin" #define GLK_CSR_VERSION_REQUIRED CSR_VERSION(1, 4) -#define I915_CSR_CNL "i915/cnl_dmc_ver1_04.bin" -#define CNL_CSR_VERSION_REQUIRED CSR_VERSION(1, 4) +#define I915_CSR_CNL "i915/cnl_dmc_ver1_05.bin" +#define CNL_CSR_VERSION_REQUIRED CSR_VERSION(1, 5) #define I915_CSR_KBL "i915/kbl_dmc_ver1_01.bin" MODULE_FIRMWARE(I915_CSR_KBL); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: cleanup the CHICKEN_MISC_2 (re)definitions
* Don't define it twice.
* Define MSBs first, like the rest of i915_reg.h.
* Add CNL_ prefix to the bit that arrived in CNL.
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h | 8 +++-
drivers/gpu/drm/i915/intel_runtime_pm.c | 4 ++--
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c712d01..a16bf67 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6703,12 +6703,10 @@ enum {
#define KVM_CONFIG_CHANGE_NOTIFICATION_SELECT (1 << 14)
#define CHICKEN_MISC_2 _MMIO(0x42084)
-#define GLK_CL0_PWR_DOWN (1 << 10)
-#define GLK_CL1_PWR_DOWN (1 << 11)
+#define CNL_COMP_PWR_DOWN (1 << 23)
#define GLK_CL2_PWR_DOWN (1 << 12)
-
-#define CHICKEN_MISC_2 _MMIO(0x42084)
-#define COMP_PWR_DOWN (1 << 23)
+#define GLK_CL1_PWR_DOWN (1 << 11)
+#define GLK_CL0_PWR_DOWN (1 << 10)
#define _CHICKEN_PIPESL_1_A0x420b0
#define _CHICKEN_PIPESL_1_B0x420b4
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index f630d63..45bdcd0 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2820,7 +2820,7 @@ static void cnl_display_core_init(struct drm_i915_private
*dev_priv, bool resume
/* 2. Enable Comp */
val = I915_READ(CHICKEN_MISC_2);
- val &= ~COMP_PWR_DOWN;
+ val &= ~CNL_COMP_PWR_DOWN;
I915_WRITE(CHICKEN_MISC_2, val);
val = I915_READ(CNL_PORT_COMP_DW3);
@@ -2894,7 +2894,7 @@ static void cnl_display_core_uninit(struct
drm_i915_private *dev_priv)
/* 5. Disable Comp */
val = I915_READ(CHICKEN_MISC_2);
- val |= COMP_PWR_DOWN;
+ val |= CNL_COMP_PWR_DOWN;
I915_WRITE(CHICKEN_MISC_2, val);
}
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Gen10 render context size.
Hi, I'm a bit late to the party, but as I already mentioned at [1] the CNL render ctx size is smaller than the gen9 one according to the specs. The ctx format in the specs contains 16752 dwords, i.e. 17 pages, to which we need to add 1 page for the PPHWSP, so 18 pages total. If we re-use the gen9 size we end up wasting 4 pages per lrc. I don't have access to a CNL to test this but I've been told that a setup using 19 pages (1 more for safety) has been tested successfully on CNL. -Daniele [1] https://lists.freedesktop.org/archives/intel-gfx/2017-April/125321.html On 07/07/17 09:38, Rodrigo Vivi wrote: patch merged to dinq. thanks for reviewing. On Thu, Jul 6, 2017 at 7:51 PM, Ben Widawsky wrote: On 17-07-06 14:06:24, Vivi, Rodrigo wrote: No change on render context size is required for Gen10. So this patch doesn't change the default behaviour, but only avoid the missing_case message. Cc: Ben Widawsky Signed-off-by: Rodrigo Vivi Reviewed-by: Ben Widawsky [snip] -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches
On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula wrote: > On Thu, 13 Jul 2017, Stéphane Marchesin wrote: >> So, if you think this is wrong, can you fix this warning in a way that >> you'd like? > > As I replied previously [1], with more background, fixing the warnings > properly, in a way that actually improves the code instead of making it > worse, would mean a bunch of churn that's not just purely mechanical > conversion. That's fair. > Unless you can point out a bug which is actually caused by mixing the > types (which is mostly intentional, see the background) I have a hard > time telling people this should be a priority. This feels like "can't see the forest because of the trees". The original patch was submitted in order to compile cleanly using clang and the above suggests using clang is not important. Using clang is important to Matthias and the Chrome OS organization for many good reasons - including better warnings. The original patch message was clear that clang was generating the warning. This isn't the only patch mka has sent to kernel devs. What one can infer is Chrome OS is trying to move to clang (like other Google products _already_ have.) My impression is all these products are a priority to Intel - but it would be good to know otherwise. > Definitely something we'd > like to do in the long run and pedantically correct (and I tend to > prefer code that way) but we certainly have more important things to do. The long run is now. Everyone agrees the code should change and you don't have to do it. Matthias submitted an unacceptable patch and giving him some concrete guidance on what would be acceptable would enable him to implement/test it (or anyone else could for that matter). Can you do that? Just give an example of what the "right" API looks like and see where it goes. cheers, grant > > BR, > Jani. > > [1] http://mid.mail-archive.com/87wp9rahjy.fsf@intel.com > > > -- > Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/drm_module_reload: Don't require hda dynamic debug
I can live without those logs, and it avoids a kernel
recompile&reboot.
Signed-off-by: Daniel Vetter
---
tests/drv_module_reload.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/drv_module_reload.c b/tests/drv_module_reload.c
index db2ad2cf0f43..be831851dec2 100644
--- a/tests/drv_module_reload.c
+++ b/tests/drv_module_reload.c
@@ -285,7 +285,10 @@ hda_dynamic_debug(bool enable)
const char snd_hda_core_off[] = "module snd_hda_intel =_";
fp = fopen("/sys/kernel/debug/dynamic_debug/control", "w");
- igt_assert(fp != NULL);
+ if (!fp) {
+ igt_debug("hda dynamic debug not available\n");
+ return;
+ }
if (enable) {
fwrite(snd_hda_intel_on, 1, sizeof(snd_hda_intel_on), fp);
--
2.5.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 i-g-t] igt/perf: add tests to verify create/destroy userspace configs
On 13 July 2017 at 12:16, Lionel Landwerlin
wrote:
> v2: Add tests regarding removing configs (Matthew)
> Add tests regarding adding/removing configs without permissions
> (Matthew)
>
> Signed-off-by: Lionel Landwerlin
> ---
> tests/perf.c | 201
> +++
> 1 file changed, 201 insertions(+)
I still think it would be nice to have at least have some flex tests,
especially if we consider the issue with not reserving enough dwords,
even if it's a pita...
>
> diff --git a/tests/perf.c b/tests/perf.c
> index db28ba1f..47caf1c6 100644
> --- a/tests/perf.c
> +++ b/tests/perf.c
> @@ -146,6 +146,36 @@ enum drm_i915_perf_record_type {
> };
> #endif /* !DRM_I915_PERF_OPEN */
>
> +#ifndef DRM_IOCTL_I915_PERF_ADD_CONFIG
> +
> +#define DRM_I915_PERF_ADD_CONFIG 0x37
> +#define DRM_I915_PERF_REMOVE_CONFIG0x38
> +
> +#define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
> +#define DRM_IOCTL_I915_PERF_REMOVE_CONFIG DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_PERF_REMOVE_CONFIG, __u64)
> +
> +/**
> + * Structure to upload perf dynamic configuration into the kernel.
> + */
> +struct drm_i915_perf_oa_config {
> + /** String formatted like "%08x-%04x-%04x-%04x-%012x" */
> + __u64 uuid;
> +
> + __u32 n_mux_regs;
> + __u32 pad0;
> + __u64 mux_regs;
> +
> + __u32 n_boolean_regs;
> + __u32 pad1;
> + __u64 boolean_regs;
> +
> + __u32 n_flex_regs;
> + __u32 pad2;
> + __u64 flex_regs;
> +};
> +
> +#endif /* !DRM_IOCTL_I915_PERF_ADD_CONFIG */
> +
> struct accumulator {
> #define MAX_RAW_OA_COUNTERS 62
> enum drm_i915_oa_format format;
> @@ -4001,6 +4031,168 @@ test_rc6_disable(void)
> igt_assert_neq(n_events_end - n_events_start, 0);
> }
>
> +static void
> +test_invalid_userspace_config_create(void)
> +{
> + struct drm_i915_perf_oa_config config;
> + const char *uuid = "01234567-0123-0123-0123-0123456789ab";
> + const char *invalid_uuid = "blablabla-wrong";
> + uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
> + uint32_t invalid_mux_regs[] = { 0x12345678 /* invalid register */,
> 0x0 };
> +
> + memset(&config, 0, sizeof(config));
> +
> + /* invalid uuid */
> + config.uuid = to_user_pointer(invalid_uuid);
> + config.n_mux_regs = 1;
> + config.mux_regs = to_user_pointer(mux_regs);
> + config.n_boolean_regs = 0;
> + config.n_flex_regs = 0;
> +
> + do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
> +
> + /* invalid mux_regs */
> + config.uuid = to_user_pointer(uuid);
> + config.n_mux_regs = 1;
> + config.mux_regs = to_user_pointer(invalid_mux_regs);
> + config.n_boolean_regs = 0;
> + config.n_flex_regs = 0;
> +
> + do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
> +
> + /* empty config */
> + config.uuid = to_user_pointer(uuid);
> + config.n_mux_regs = 0;
> + config.mux_regs = to_user_pointer(mux_regs);
> + config.n_boolean_regs = 0;
> + config.n_flex_regs = 0;
> +
> + do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
> +
> + /* empty config with null pointers */
> + config.uuid = to_user_pointer(uuid);
> + config.n_mux_regs = 1;
> + config.mux_regs = to_user_pointer(NULL);
> + config.n_boolean_regs = 2;
> + config.boolean_regs = to_user_pointer(NULL);
> + config.n_flex_regs = 3;
> + config.flex_regs = to_user_pointer(NULL);
> +
> + do_ioctl_err(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config, EINVAL);
> +}
> +
> +static void
> +test_invalid_userspace_config_remove(void)
> +{
> + struct drm_i915_perf_oa_config config;
> + const char *uuid = "01234567-0123-0123-0123-0123456789ab";
> + uint32_t mux_regs[] = { 0x9888 /* NOA_WRITE */, 0x0 };
> + uint64_t config_id, wrong_config_id = 9;
> + char path[512];
> + int ret;
> +
> + snprintf(path, sizeof(path), "/sys/class/drm/card%d/metrics/%s/id",
> card, uuid);
> +
> + /* Destroy previous configuration if present */
> + if (try_read_u64_file(path, &config_id))
> + igt_assert(igt_ioctl(drm_fd, DRM_IOCTL_I915_PERF_REMOVE_CONFIG,
> &config_id) == 0);
> +
> + memset(&config, 0, sizeof(config));
> +
> + config.uuid = to_user_pointer(uuid);
> +
> + config.n_mux_regs = 1;
> + config.mux_regs = to_user_pointer(mux_regs);
> + config.n_boolean_regs = 0;
> + config.n_flex_regs = 0;
> +
> + ret = igt_ioctl(drm_fd, DRM_IOCTL_I915_PERF_ADD_CONFIG, &config);
> + igt_assert(ret > 0);
> + config_id = ret;
> +
> + /* Removing configs without permissions should fail. */
> + igt_fork(child, 1) {
> + igt_drop_root();
> +
> + do_ioctl_err
[Intel-gfx] ✓ Fi.CI.BAT: success for PSR clean-up, new vfuncs and more use of HW tracking. (rev4)
== Series Details == Series: PSR clean-up, new vfuncs and more use of HW tracking. (rev4) URL : https://patchwork.freedesktop.org/series/27194/ State : success == Summary == Series 27194v4 PSR clean-up, new vfuncs and more use of HW tracking. https://patchwork.freedesktop.org/api/1.0/series/27194/revisions/4/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: pass -> FAIL (fi-snb-2600) fdo#100215 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-x1585l) fdo#101781 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:444s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:431s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:355s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:527s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:511s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:491s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:486s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:595s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:443s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:411s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:423s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:502s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:472s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:468s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:572s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:576s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:567s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:454s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:589s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:466s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:482s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:441s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:500s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:546s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:408s e1306e0d65a3a850838534019a9a61e73bf1efcc drm-tip: 2017y-07m-14d-13h-56m-32s UTC integration manifest ee28d85 drm/i915/psr: Re-create a hsw_psr_enable_source. 8d81dca drm/i915/psr: Unify VSC setup functions. fc23fed drm/i915/psr: Add activate vfunc. bcf4fb1 drm/i915/psr: hsw_psr_activate. 621fdb1 drm/i915/psr: vfunc for disabling source. bf733f4 drm/i915/psr: Avoid any PSR stuff on platforms without support. 61776f5 drm/i915/psr: Remove vlv_is_active function. == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5194/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND v2 2/2] drm/i915/dp: Validate the compliance test link parameters
Tested by: Elio Martinez
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Manasi Navare
Sent: Friday, July 7, 2017 6:13 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [RESEND v2 2/2] drm/i915/dp: Validate the compliance test
link parameters
Validate the compliance test link parameters when the compliance test dpcd
registers are read. Also validate them in compute_config before using them
since the max values might have been reduced due to link training fallback.
If either the link rate or lane count is invalid, we still bail from using the
test parameters since the combination would not work and instead use the
fallback values.
v2:
* Added commit message to explain why we still bail when either of of the
params is invalid (Ville Syrjala)
* Add reason for validating in the comment (Jani Nikula)
* Also check if index >= 0 after validating (Jani Nikula)
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Ville Syrjala
---
drivers/gpu/drm/i915/intel_dp.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d94a47c..4fc23bc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1678,12 +1678,18 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
int index;
- index = intel_dp_rate_index(intel_dp->common_rates,
- intel_dp->num_common_rates,
-
intel_dp->compliance.test_link_rate);
- if (index >= 0)
- min_clock = max_clock = index;
- min_lane_count = max_lane_count =
intel_dp->compliance.test_lane_count;
+ /* Validate the compliance test data since max values
+* might have changed due to link train fallback.
+*/
+ if (intel_dp_link_params_valid(intel_dp,
intel_dp->compliance.test_link_rate,
+
intel_dp->compliance.test_lane_count)) {
+ index = intel_dp_rate_index(intel_dp->common_rates,
+ intel_dp->num_common_rates,
+
intel_dp->compliance.test_link_rate);
+ if (index >= 0)
+ min_clock = max_clock = index;
+ min_lane_count = max_lane_count =
intel_dp->compliance.test_lane_count;
+ }
}
DRM_DEBUG_KMS("DP link computation with max lane count %i "
"max bw %d pixel clock %iKHz\n", @@ -3964,8 +3970,7 @@
intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8 *sink_irq_vector)
static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp) {
int status = 0;
- int min_lane_count = 1;
- int link_rate_index, test_link_rate;
+ int test_link_rate;
uint8_t test_lane_count, test_link_bw;
/* (DP CTS 1.2)
* 4.3.1.11
@@ -3979,10 +3984,6 @@ static uint8_t intel_dp_autotest_link_training(struct
intel_dp *intel_dp)
return DP_TEST_NAK;
}
test_lane_count &= DP_MAX_LANE_COUNT_MASK;
- /* Validate the requested lane count */
- if (test_lane_count < min_lane_count ||
- test_lane_count > intel_dp->max_link_lane_count)
- return DP_TEST_NAK;
status = drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_LINK_RATE,
&test_link_bw);
@@ -3990,12 +3991,11 @@ static uint8_t intel_dp_autotest_link_training(struct
intel_dp *intel_dp)
DRM_DEBUG_KMS("Link Rate read failed\n");
return DP_TEST_NAK;
}
- /* Validate the requested link rate */
test_link_rate = drm_dp_bw_code_to_link_rate(test_link_bw);
- link_rate_index = intel_dp_rate_index(intel_dp->common_rates,
- intel_dp->num_common_rates,
- test_link_rate);
- if (link_rate_index < 0)
+
+ /* Validate the requested link rate and lane count */
+ if (!intel_dp_link_params_valid(intel_dp, test_link_rate,
+ test_lane_count))
return DP_TEST_NAK;
intel_dp->compliance.test_lane_count = test_lane_count;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RESEND,v2,1/2] drm/i915/dp: Generalize intel_dp_link_params function to accept arguments to be validated
Tested by: Elio Martinez -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Patchwork Sent: Friday, July 7, 2017 6:25 PM To: nav...@emeril.freedesktop.org; Navare, Manasi D Cc: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RESEND,v2,1/2] drm/i915/dp: Generalize intel_dp_link_params function to accept arguments to be validated == Series Details == Series: series starting with [RESEND,v2,1/2] drm/i915/dp: Generalize intel_dp_link_params function to accept arguments to be validated URL : https://patchwork.freedesktop.org/series/27028/ State : success == Summary == Series 27028v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/27028/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-x1585l) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101705 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:438s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:430s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:354s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:538s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:509s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:489s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:488s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:594s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:433s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:412s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:427s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:499s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:457s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:576s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:581s fi-pnv-d510 total:279 pass:221 dwarn:3 dfail:0 fail:0 skip:55 time:566s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:467s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:587s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:475s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:485s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:433s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:510s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:553s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:402s edc3bde190ad0559ad1c7c63e0efd8d5b4b24b2c drm-tip: 2017y-07m-07d-17h-12m-03s UTC integration manifest edb2eb9 drm/i915/dp: Validate the compliance test link parameters 1d7b5b6 drm/i915/dp: Generalize intel_dp_link_params function to accept arguments to be validated == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5146/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/psr: Re-org Activate after enable
Let's move the activation calls together after enable is done.
No real functional change should be expected here. Just an attempt
to get it clear when we are really activating PSR after enabling it.
v2: Add braces on if/else because commit message there is too long
as suggested by Jani.
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Dhinakaran Pandiyan
Cc: Jim Bride
Cc: Vathsala NAgaraju
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_psr.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c2c7afe6a902..09e16768dacc 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -554,9 +554,6 @@ void intel_psr_enable(struct intel_dp *intel_dp)
hsw_psr_enable_sink(intel_dp);
hsw_psr_enable_source(intel_dp);
-
- if (INTEL_GEN(dev_priv) >= 9)
- intel_psr_activate(intel_dp);
} else {
vlv_psr_setup_vsc(intel_dp);
@@ -566,20 +563,25 @@ void intel_psr_enable(struct intel_dp *intel_dp)
vlv_psr_enable_source(intel_dp);
}
- /*
-* FIXME: Activation should happen immediately since this function
-* is just called after pipe is fully trained and enabled.
-* However on every platform we face issues when first activation
-* follows a modeset so quickly.
-* - On VLV/CHV we get bank screen on first activation
-* - On HSW/BDW we get a recoverable frozen screen until next
-* exit-activate sequence.
-*/
- if (INTEL_GEN(dev_priv) < 9)
+ dev_priv->psr.enabled = intel_dp;
+
+ if (INTEL_GEN(dev_priv) >= 9) {
+ intel_psr_activate(intel_dp);
+ } else {
+ /*
+* FIXME: Activation should happen immediately since this
+* function is just called after pipe is fully trained and
+* enabled.
+* However on some platforms we face issues when first
+* activation follows a modeset so quickly.
+* - On VLV/CHV we get bank screen on first activation
+* - On HSW/BDW we get a recoverable frozen screen until
+* next exit-activate sequence.
+*/
schedule_delayed_work(&dev_priv->psr.work,
msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
+ }
- dev_priv->psr.enabled = intel_dp;
unlock:
mutex_unlock(&dev_priv->psr.lock);
}
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for PSR clean-up, new vfuncs and more use of HW tracking. (rev3)
== Series Details == Series: PSR clean-up, new vfuncs and more use of HW tracking. (rev3) URL : https://patchwork.freedesktop.org/series/27194/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh CHK scripts/mod/devicetable-offsets.h CHK include/generated/compile.h CHK kernel/config_data.h CC [M] drivers/gpu/drm/i915/intel_psr.o drivers/gpu/drm/i915/intel_psr.c: In function ‘intel_psr_enable’: drivers/gpu/drm/i915/intel_psr.c:547:1: error: expected expression before ‘<<’ token <<< 9e8f83846114215a62362801b9fb8a7908c35b6d ^ drivers/gpu/drm/i915/intel_psr.c:547:9: error: invalid suffix "f83846114215a62362801b9fb8a7908c35b6d" on floating constant <<< 9e8f83846114215a62362801b9fb8a7908c35b6d ^ drivers/gpu/drm/i915/intel_psr.c:550:1: error: expected expression before ‘==’ token === ^ drivers/gpu/drm/i915/intel_psr.c:552:1: error: expected expression before ‘>>’ token >>> drm/i915/psr: Re-org Activate after enable ^ scripts/Makefile.build:302: recipe for target 'drivers/gpu/drm/i915/intel_psr.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_psr.o] Error 1 scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:561: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1016: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/psr: Re-create a hsw_psr_enable_source.
This sequence is part of enable source anyways, but they
only need to be executed once and not on every activation,
So let's re-create hsw_enable_source.
v2: Avoid changing order here to avoid changing behaviour
as suggested by Jani.
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Dhinakaran Pandiyan
Cc: Jim Bride
Cc: Vathsala NAgaraju
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_psr.c | 75 ++--
1 file changed, 42 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index febaca1dec4b..3caf330017da 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -230,6 +230,47 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
I915_WRITE(aux_ctl_reg, aux_ctl);
}
+static void hsw_psr_enable_source(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
+ enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+
+ u32 chicken;
+
+ if (dev_priv->psr.psr2_support) {
+ chicken = PSR2_VSC_ENABLE_PROG_HEADER;
+ if (dev_priv->psr.y_cord_support)
+ chicken |= PSR2_ADD_VERTICAL_LINE_COUNT;
+ I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
+ I915_WRITE(EDP_PSR_DEBUG_CTL,
+ EDP_PSR_DEBUG_MASK_MEMUP |
+ EDP_PSR_DEBUG_MASK_HPD |
+ EDP_PSR_DEBUG_MASK_LPSP |
+ EDP_PSR_DEBUG_MASK_MAX_SLEEP |
+ EDP_PSR_DEBUG_MASK_DISP_REG_WRITE);
+ } else {
+ /*
+* Per Spec: Avoid continuous PSR exit by masking MEMUP
+* and HPD. also mask LPSP to avoid dependency on other
+* drivers that might block runtime_pm besides
+* preventing other hw tracking issues now we can rely
+* on frontbuffer tracking.
+*/
+ I915_WRITE(EDP_PSR_DEBUG_CTL,
+ EDP_PSR_DEBUG_MASK_MEMUP |
+ EDP_PSR_DEBUG_MASK_HPD |
+ EDP_PSR_DEBUG_MASK_LPSP);
+ }
+
+ /*
+* The rest of enable source sequence that should be here is actually
+* executed during activation time. So check hsw_psr_activate().
+*/
+}
+
static void vlv_psr_enable_source(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -485,9 +526,6 @@ void intel_psr_enable(struct intel_dp *intel_dp)
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);
- struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
- enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
- u32 chicken;
if (!HAS_PSR(dev_priv))
return;
@@ -512,30 +550,7 @@ void intel_psr_enable(struct intel_dp *intel_dp)
hsw_psr_setup_vsc(intel_dp);
- if (dev_priv->psr.psr2_support) {
- chicken = PSR2_VSC_ENABLE_PROG_HEADER;
- if (dev_priv->psr.y_cord_support)
- chicken |= PSR2_ADD_VERTICAL_LINE_COUNT;
- I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
- I915_WRITE(EDP_PSR_DEBUG_CTL,
- EDP_PSR_DEBUG_MASK_MEMUP |
- EDP_PSR_DEBUG_MASK_HPD |
- EDP_PSR_DEBUG_MASK_LPSP |
- EDP_PSR_DEBUG_MASK_MAX_SLEEP |
- EDP_PSR_DEBUG_MASK_DISP_REG_WRITE);
- } else {
- /*
-* Per Spec: Avoid continuous PSR exit by masking MEMUP
-* and HPD. also mask LPSP to avoid dependency on other
-* drivers that might block runtime_pm besides
-* preventing other hw tracking issues now we can rely
-* on frontbuffer tracking.
-*/
- I915_WRITE(EDP_PSR_DEBUG_CTL,
- EDP_PSR_DEBUG_MASK_MEMUP |
- EDP_PSR_DEBUG_MASK_HPD |
- EDP_PSR_DEBUG_MASK_LPSP);
- }
+ hsw_psr_enable_source(intel_dp);
/* Enable PSR on the panel */
hsw_psr_enable_sink(intel_dp);
@@ -548,12 +563,6 @@ void intel_psr_enable(struct intel_dp *intel_dp)
[Intel-gfx] [PATCH 2/2] drm/i915/psr: Move hsw_enable_source after enabling sink.
No functional change is expected here since at this point
PSR is not allowed to go to any active state. In other
words, not really enabled.
However let's do in a separated patch so it gets clear
on what is change and specially it can helps on bisect
case if we figure something has caused changes in behaviour.
But this needs to be done before we make the vfunc to
enable source to be in parity with VLV implementation.
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Dhinakaran Pandiyan
Cc: Jim Bride
Cc: Vathsala NAgaraju
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_psr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 3caf330017da..c2c7afe6a902 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -550,11 +550,11 @@ void intel_psr_enable(struct intel_dp *intel_dp)
hsw_psr_setup_vsc(intel_dp);
- hsw_psr_enable_source(intel_dp);
-
/* Enable PSR on the panel */
hsw_psr_enable_sink(intel_dp);
+ hsw_psr_enable_source(intel_dp);
+
if (INTEL_GEN(dev_priv) >= 9)
intel_psr_activate(intel_dp);
} else {
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix cursor updates on some platforms
On Fri, Jul 14, 2017 at 05:24:03PM +0100, Chris Wilson wrote: > Quoting ville.syrj...@linux.intel.com (2017-07-14 16:52:27) > > From: Ville Syrjälä > > > > Turns out that just writing CURPOS isn't sufficient to move the cursor > > on some platforms. My 830 works just fine, but eg. 945 and PNV don't. > > On those platforms we need to arm even the CURPOS update with a > > CURBASE write. > > > > Even worse, a write to any of the cursor register apart from CURBASE > > will cancel an already pending cursor update. So if we have armed a > > CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank > > would cancel that armed update. Thus we're left with a cursor that > > doesn't appear to move, or even change shape. > > > > Fix the problem by always performing the CURBASE write after a > > CURPOS write. Bspec is somewhat unclear which platforms actually > > require this CURBASE write and which don't. So to keep it simple > > and to make sure we really fix the problem across all supported > > devices, let's just perform the CURBASE write unconditionally. > > Hmm, it seems that kms_cursor_crc should catch this? I guess we are > missing a move N times quickly test? Yeah. I guess what we have is basically this: 1. enable cursor at some location 2. wait for vblank and grab the crc 3. disable cursor and render the cursor image to the primary plane fb 4. wait for vblank and grab the crc I guess what we could do is make step 1 enable the cursor at an incorrect location, and then perform a few extra cursor movements, ending in the correct location, before we grab the crc. > We have CRC support on pnv right? We should have it across the board. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix cursor updates on some platforms
Quoting ville.syrj...@linux.intel.com (2017-07-14 16:52:27) > From: Ville Syrjälä > > Turns out that just writing CURPOS isn't sufficient to move the cursor > on some platforms. My 830 works just fine, but eg. 945 and PNV don't. > On those platforms we need to arm even the CURPOS update with a > CURBASE write. > > Even worse, a write to any of the cursor register apart from CURBASE > will cancel an already pending cursor update. So if we have armed a > CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank > would cancel that armed update. Thus we're left with a cursor that > doesn't appear to move, or even change shape. > > Fix the problem by always performing the CURBASE write after a > CURPOS write. Bspec is somewhat unclear which platforms actually > require this CURBASE write and which don't. So to keep it simple > and to make sure we really fix the problem across all supported > devices, let's just perform the CURBASE write unconditionally. Hmm, it seems that kms_cursor_crc should catch this? I guess we are missing a move N times quickly test? We have CRC support on pnv right? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/3] drm/i915/perf: fix flex eu registers programming
On 14 July 2017 at 16:15, Lionel Landwerlin
wrote:
> We were reserving fewer dwords in the ring than necessary. Indeed
> we're always writing all registers once, so discard the actual number
> of registers given by the user and just program the whitelisted ones
> once.
>
> Reported-by: Matthew Auld
Fixes: 19f81df2859e ("drm/i915/perf: Add OA unit support for Gen 8+")
> Signed-off-by: Lionel Landwerlin
> Cc: # v4.12+
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix cursor updates on some platforms
== Series Details == Series: drm/i915: Fix cursor updates on some platforms URL : https://patchwork.freedesktop.org/series/27314/ State : success == Summary == Series 27314v1 drm/i915: Fix cursor updates on some platforms https://patchwork.freedesktop.org/api/1.0/series/27314/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 +1 Subgroup suspend-read-crc-pipe-a: pass -> FAIL (fi-skl-6700k) fdo#100367 Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:448s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:429s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:359s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:533s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:505s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:491s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:487s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:597s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:432s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:412s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:494s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:466s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:571s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:583s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:562s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:456s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:594s fi-skl-6700k total:279 pass:256 dwarn:4 dfail:0 fail:1 skip:18 time:465s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:477s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:434s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:479s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:541s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:419s e1306e0d65a3a850838534019a9a61e73bf1efcc drm-tip: 2017y-07m-14d-13h-56m-32s UTC integration manifest 3c5f5b7 drm/i915: Fix cursor updates on some platforms == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5192/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/4] drm/i915/psr: Account for sink CRC raciness on some panels
On Fri, Jul 14, 2017 at 12:46:08PM +0300, Jani Nikula wrote:
> On Tue, 11 Jul 2017, Jim Bride wrote:
> > According to the eDP spec, when the count field in TEST_SINK_MISC
> > increments then the six bytes of sink CRC information in the DPCD
> > should be valid. Unfortunately, this doesn't seem to be the case
> > on some panels, and as a result we get some incorrect and inconsistent
> > values from the sink CRC DPCD locations at times. This problem exhibits
> > itself more on faster processors (relative failure rates HSW < SKL < KBL.)
> > In order to try and account for this, we try a lot harder to read the sink
> > CRC until we get consistent values twice in a row before returning what we
> > read and delay for a time before trying to read. We still see some
> > occasional failures, but reading the sink CRC is much more reliable,
> > particularly on SKL and KBL, with these changes than without.
> >
> > v2: * Reduce number of retries when reading the sink CRC (Jani)
> > * Refactor to minimize changes to the code (Jani)
> > * Rebase
> >
> > Cc: Rodrigo Vivi
> > Cc: Paulo Zanoni
> > Cc: Jani Nikula
> > Reviewed-by: Rodrigo Vivi
> > Signed-off-by: Jim Bride
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 40
> >
> > 1 file changed, 36 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 2d42d09..69c8130c 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3906,6 +3906,14 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> > *crc)
> > u8 buf;
> > int count, ret;
> > int attempts = 6;
> > + u8 old_crc[6];
> > +
> > + if (crc != NULL) {
>
> As DK said, please drop the check.
>
> > + memset(crc, 0, 6);
> > + memset(old_crc, 0xff, 6);
>
> Both unnecessary, see below.
>
> > + } else {
> > + return -ENOMEM;
> > + }
> >
> > ret = intel_dp_sink_crc_start(intel_dp);
> > if (ret)
> > @@ -3929,11 +3937,35 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> > *crc)
> > goto stop;
> > }
> >
> > - if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0) {
> > - ret = -EIO;
> > - goto stop;
> > - }
> > + attempts = 6;
> > +
> > + /*
> > +* Sometimes it takes a while for the "real" CRC values to land in
> > +* the DPCD, so try several times until we get two reads in a row
> > +* that are the same. If we're an eDP panel, delay between reads
> > +* for a while since the values take a bit longer to propagate.
> > +*/
> > + do {
>
> Never use a do-while when a for loop will do. for (i = 0; i < 6; i++)
> gets interpreted in the spine, no need for further processing.
I had used do-while because it was used earlier to read the test
count (code I didn't touch.) In any event, I can convert to a
for loop easy enough.
> > + intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
> > + if (is_edp(intel_dp))
> > + usleep_range(2, 25000);
>
> Is the intention to do these *between* reads? If yes, then move this
> *after* the memcmp to only do this between reads.
Moved.
> > +
> > + if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR,
> > +crc, 6) < 0) {
> > + ret = -EIO;
> > + goto stop;
>
> break;
Changed.
> > + }
> > +
> > + if (memcmp(old_crc, crc, 6) == 0) {
> > + ret = 0;
> > + goto stop;
> > + } else {
> > + memcpy(old_crc, crc, 6);
> > + }
>
> After you've switched this to the for loop, you can do:
>
> if (i && memcmp(old_crc, crc, sizeof(old_crc)) == 0)
> break;
> memcpy(old_crc, crc, sizeof(old_crc));
Changed. I'll submit a new version of the patch after I retest.
Jim
> > + } while (--attempts);
> >
>
> if (i == 6) {
>
> > + DRM_DEBUG_KMS("Failed to get CRC after 6 attempts.\n");
> > + ret = -ETIMEDOUT;
>
> }
>
> > stop:
> > intel_dp_sink_crc_stop(intel_dp);
> > return ret;
>
> --
> 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/2] drm/i915: Fix error checking/locking in perf/lookup_context()
Reviewed-by: Lionel Landwerlin
On 14/07/17 16:12, Imre Deak wrote:
1acfc104cdf8 missed to convert this one caller to be lockless. The side
effect of that was that the error check in lookup_context() became
incorrect. Convert now this caller too.
Fixes: 1acfc104cdf ("drm/i915: Enable rcu-only context lookups")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_perf.c | 32 +---
1 file changed, 5 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index d9f77a4d85db..96682fd86f82 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2483,27 +2483,6 @@ static const struct file_operations fops = {
};
-static struct i915_gem_context *
-lookup_context(struct drm_i915_private *dev_priv,
- struct drm_i915_file_private *file_priv,
- u32 ctx_user_handle)
-{
- struct i915_gem_context *ctx;
- int ret;
-
- ret = i915_mutex_lock_interruptible(&dev_priv->drm);
- if (ret)
- return ERR_PTR(ret);
-
- ctx = i915_gem_context_lookup(file_priv, ctx_user_handle);
- if (!IS_ERR(ctx))
- i915_gem_context_get(ctx);
-
- mutex_unlock(&dev_priv->drm.struct_mutex);
-
- return ctx;
-}
-
/**
* i915_perf_open_ioctl_locked - DRM ioctl() for userspace to open a stream FD
* @dev_priv: i915 device instance
@@ -2545,12 +2524,11 @@ i915_perf_open_ioctl_locked(struct drm_i915_private
*dev_priv,
u32 ctx_handle = props->ctx_handle;
struct drm_i915_file_private *file_priv = file->driver_priv;
- specific_ctx = lookup_context(dev_priv, file_priv, ctx_handle);
- if (IS_ERR(specific_ctx)) {
- ret = PTR_ERR(specific_ctx);
- if (ret != -EINTR)
- DRM_DEBUG("Failed to look up context with ID %u for
opening perf stream\n",
- ctx_handle);
+ specific_ctx = i915_gem_context_lookup(file_priv, ctx_handle);
+ if (!specific_ctx) {
+ DRM_DEBUG("Failed to look up context with ID %u for opening
perf stream\n",
+ ctx_handle);
+ ret = -ENOENT;
goto err;
}
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix cursor updates on some platforms
From: Ville Syrjälä
Turns out that just writing CURPOS isn't sufficient to move the cursor
on some platforms. My 830 works just fine, but eg. 945 and PNV don't.
On those platforms we need to arm even the CURPOS update with a
CURBASE write.
Even worse, a write to any of the cursor register apart from CURBASE
will cancel an already pending cursor update. So if we have armed a
CURCNTR/CURBASE update, a subsequent CURPOS write prior to vblank
would cancel that armed update. Thus we're left with a cursor that
doesn't appear to move, or even change shape.
Fix the problem by always performing the CURBASE write after a
CURPOS write. Bspec is somewhat unclear which platforms actually
require this CURBASE write and which don't. So to keep it simple
and to make sure we really fix the problem across all supported
devices, let's just perform the CURBASE write unconditionally.
Cc: Paul Menzel
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101790
Fixes: 75343a44c901 ("drm/i915: Drop useless posting reads from cursor commit")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2144adc5b1d5..460bd942fcb7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9555,7 +9555,16 @@ static void i9xx_update_cursor(struct intel_plane *plane,
* On some platforms writing CURCNTR first will also
* cause CURPOS to be armed by the CURBASE write.
* Without the CURCNTR write the CURPOS write would
-* arm itself.
+* arm itself. Thus we always start the full update
+* with a CURCNTR write.
+*
+* On other platforms CURPOS always requires the
+* CURBASE write to arm the update. Additonally
+* a write to any of the cursor register will cancel
+* an already armed cursor update. Thus leaving out
+* the CURBASE write after CURPOS could lead to a
+* cursor that doesn't appear to move, or even change
+* shape. Thus we always write CURBASE.
*
* CURCNTR and CUR_FBC_CTL are always
* armed by the CURBASE write only.
@@ -9574,6 +9583,7 @@ static void i9xx_update_cursor(struct intel_plane *plane,
plane->cursor.cntl = cntl;
} else {
I915_WRITE_FW(CURPOS(pipe), pos);
+ I915_WRITE_FW(CURBASE(pipe), base);
}
POSTING_READ_FW(CURBASE(pipe));
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for loadable OA configs
== Series Details == Series: Add support for loadable OA configs URL : https://patchwork.freedesktop.org/series/27310/ State : success == Summary == Series 27310v1 Add support for loadable OA configs https://patchwork.freedesktop.org/api/1.0/series/27310/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 +1 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:429s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:416s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:357s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:483s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:479s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:496s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:483s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:580s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:430s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:403s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:421s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:499s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:460s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:560s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:567s fi-pnv-d510 total:279 pass:221 dwarn:3 dfail:0 fail:0 skip:55 time:560s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:443s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:571s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:632s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:458s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:430s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:467s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:408s e1306e0d65a3a850838534019a9a61e73bf1efcc drm-tip: 2017y-07m-14d-13h-56m-32s UTC integration manifest 97998d26 drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface cf72de7 drm/i915/perf: prune OA configs 9135d3f drm/i915/perf: fix flex eu registers programming == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5191/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix error checking/locking in perf/lookup_context()
Quoting Patchwork (2017-07-14 16:28:47) > e1306e0d65a3a850838534019a9a61e73bf1efcc drm-tip: 2017y-07m-14d-13h-56m-32s > UTC integration manifest > 090da8a drm/i915: Fix user ptr check size in eb_relocate_vma() > 84be7c7 drm/i915: Fix error checking/locking in perf/lookup_context() And because pw saw it first, Reviewed-by: Chris Wilson for the lookup_context fix. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix error checking/locking in perf/lookup_context()
== Series Details == Series: series starting with [1/2] drm/i915: Fix error checking/locking in perf/lookup_context() URL : https://patchwork.freedesktop.org/series/27309/ State : success == Summary == Series 27309v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/27309/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: pass -> FAIL (fi-snb-2600) fdo#100215 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-x1585l) fdo#101781 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:443s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:431s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:356s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:526s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:507s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:494s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:487s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:594s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:436s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:417s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:418s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:492s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:467s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:460s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:571s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:581s fi-pnv-d510 total:279 pass:221 dwarn:3 dfail:0 fail:0 skip:55 time:560s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:476s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:592s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:467s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:473s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:442s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:491s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:541s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:412s e1306e0d65a3a850838534019a9a61e73bf1efcc drm-tip: 2017y-07m-14d-13h-56m-32s UTC integration manifest 090da8a drm/i915: Fix user ptr check size in eb_relocate_vma() 84be7c7 drm/i915: Fix error checking/locking in perf/lookup_context() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5190/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2 1/7] igt: lib/igt_crc: Split out CRC functionality
From: Brian Starkey
Separate out the CRC code for better compartmentalisation. Should ease
the addition of more/different CRC sources in the future.
Signed-off-by: Brian Starkey
---
lib/Makefile.sources | 2 +
lib/igt_chamelium.h | 1 +
lib/igt_crc.c | 563 ++
lib/igt_crc.h | 125 +
lib/igt_debugfs.c | 547
lib/igt_debugfs.h | 81 --
tests/chamelium.c | 1 +
tests/kms_atomic_transition.c | 1 +
tests/kms_ccs.c | 1 +
tests/kms_chv_cursor_fail.c | 1 +
tests/kms_crtc_background_color.c | 1 +
tests/kms_cursor_crc.c| 1 +
tests/kms_cursor_legacy.c | 1 +
tests/kms_draw_crc.c | 1 +
tests/kms_fbc_crc.c | 1 +
tests/kms_flip_tiling.c | 1 +
tests/kms_frontbuffer_tracking.c | 1 +
tests/kms_mmap_write_crc.c| 1 +
tests/kms_mmio_vs_cs_flip.c | 1 +
tests/kms_pipe_color.c| 1 +
tests/kms_pipe_crc_basic.c| 1 +
tests/kms_plane.c | 1 +
tests/kms_plane_lowres.c | 1 +
tests/kms_plane_multiple.c| 1 +
tests/kms_plane_scaling.c | 1 +
tests/kms_pwrite_crc.c| 1 +
tests/kms_rotation_crc.c | 1 +
tests/kms_universal_plane.c | 1 +
tools/intel_display_crc.c | 1 +
29 files changed, 714 insertions(+), 628 deletions(-)
create mode 100644 lib/igt_crc.c
create mode 100644 lib/igt_crc.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 53fdb54c..cfba15c9 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -11,6 +11,8 @@ lib_source_list = \
igt_debugfs.h \
igt_aux.c \
igt_aux.h \
+ igt_crc.c \
+ igt_crc.h \
igt_edid_template.h \
igt_gt.c\
igt_gt.h\
diff --git a/lib/igt_chamelium.h b/lib/igt_chamelium.h
index 81322ad2..ea5abc2e 100644
--- a/lib/igt_chamelium.h
+++ b/lib/igt_chamelium.h
@@ -31,6 +31,7 @@
#endif
#include "igt.h"
+#include "igt_crc.h"
#include
struct chamelium;
diff --git a/lib/igt_crc.c b/lib/igt_crc.c
new file mode 100644
index ..91a0b5a8
--- /dev/null
+++ b/lib/igt_crc.c
@@ -0,0 +1,563 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "igt_aux.h"
+#include "igt_crc.h"
+#include "igt_core.h"
+#include "igt_debugfs.h"
+#include "igt_kms.h"
+
+/**
+ * igt_assert_crc_equal:
+ * @a: first pipe CRC value
+ * @b: second pipe CRC value
+ *
+ * Compares two CRC values and fails the testcase if they don't match with
+ * igt_fail(). Note that due to CRC collisions CRC based testcase can only
+ * assert that CRCs match, never that they are different. Otherwise there might
+ * be random testcase failures when different screen contents end up with the
+ * same CRC by chance.
+ */
+void igt_assert_crc_equal(const igt_crc_t *a, const igt_crc_t *b)
+{
+ int i;
+
+ for (i = 0; i < a->n_words; i++)
+ igt_assert_eq_u32(a->crc[i], b->crc[i]);
+}
+
+/**
+ * igt_crc_to_string:
+ * @crc: pipe CRC value to print
+ *
+ * This formats @crc into a string buffer which is owned by
igt_crc_to_string().
+ * The next call will override the buffer again, which makes this
multithreading
+ * unsafe.
+ *
+ * This should only ever be used for diagnostic debug output.
+ */
+char *igt_crc_to_string(igt_crc_t *crc)
+{
+ int i;
+ char buf[128] = { 0 };
+
+ for (i = 0; i < crc->n_words; i++)
+ sprintf(buf + strlen(buf), "%08x
[Intel-gfx] [PATCH i-g-t v2 0/7] igt: Add support for testing writeback connectors
We're trying to introduce support for writeback connectors, a way to expose in DRM the hardware functionality from display engines that allows to write back into memory the result of the DE's composition of supported planes. Generic DRM support is available here [1] and will be merged once this patchset gets approved for inclusion into igt. VC4 support for writeback is added here [2] and for mali-dp is added here [3]. Changelog: - v2: Rebased on top of a844ccbdbab9fd16c37de81281c6281bc800e97a - v1: Original (re)submission [4] Many thanks, Liviu [1] https://lists.freedesktop.org/archives/dri-devel/2017-May/141796.html [2] https://lists.freedesktop.org/archives/dri-devel/2017-June/143337.html [3] https://lists.freedesktop.org/archives/dri-devel/2017-May/141799.html [4] https://lists.freedesktop.org/archives/intel-gfx/2017-July/132344.html Brian Starkey (7): igt: lib/igt_crc: Split out CRC functionality lib/igt_kms: Add writeback support in lib/ kms_writeback: Add initial writeback tests lib: Add function to hash a framebuffer kms_writeback: Add writeback-check-output lib/igt_kms: Add igt_output_clone_pipe for cloning kms_writeback: Add tests using a cloned output lib/Makefile.sources | 2 + lib/igt_aux.c | 1 + lib/igt_chamelium.h | 1 + lib/igt_crc.c | 563 ++ lib/igt_crc.h | 125 + lib/igt_debugfs.c | 547 lib/igt_debugfs.h | 81 -- lib/igt_fb.c | 65 + lib/igt_fb.h | 5 + lib/igt_kms.c | 172 +--- lib/igt_kms.h | 26 ++ tests/Makefile.sources| 1 + tests/chamelium.c | 1 + tests/kms_atomic_transition.c | 1 + tests/kms_ccs.c | 1 + tests/kms_chv_cursor_fail.c | 1 + tests/kms_crtc_background_color.c | 1 + tests/kms_cursor_crc.c| 1 + tests/kms_cursor_legacy.c | 1 + tests/kms_draw_crc.c | 1 + tests/kms_fbc_crc.c | 1 + tests/kms_flip_tiling.c | 1 + tests/kms_frontbuffer_tracking.c | 1 + tests/kms_mmap_write_crc.c| 1 + tests/kms_mmio_vs_cs_flip.c | 1 + tests/kms_pipe_color.c| 1 + tests/kms_pipe_crc_basic.c| 1 + tests/kms_plane.c | 1 + tests/kms_plane_lowres.c | 1 + tests/kms_plane_multiple.c| 1 + tests/kms_plane_scaling.c | 1 + tests/kms_pwrite_crc.c| 1 + tests/kms_rotation_crc.c | 1 + tests/kms_universal_plane.c | 1 + tests/kms_writeback.c | 541 tools/intel_display_crc.c | 1 + 36 files changed, 1487 insertions(+), 666 deletions(-) create mode 100644 lib/igt_crc.c create mode 100644 lib/igt_crc.h create mode 100644 tests/kms_writeback.c -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2 3/7] kms_writeback: Add initial writeback tests
From: Brian Starkey
Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and
WRITEBACK_FB_ID properties on writeback connectors, ensuring their
behaviour is correct.
Signed-off-by: Brian Starkey
---
lib/igt_kms.c | 6 +-
lib/igt_kms.h | 7 +
tests/Makefile.sources | 1 +
tests/kms_writeback.c | 371 +
4 files changed, 382 insertions(+), 3 deletions(-)
create mode 100644 tests/kms_writeback.c
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 02e2b274..aae32202 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -2137,7 +2137,7 @@ static uint32_t igt_plane_get_fb_gem_handle(igt_plane_t
*plane)
/*
* Add position and fb changes of a plane to the atomic property set
*/
-static void
+void
igt_atomic_prepare_plane_commit(igt_plane_t *plane, igt_pipe_t *pipe,
drmModeAtomicReq *req)
{
@@ -2515,7 +2515,7 @@ igt_pipe_replace_blob(igt_pipe_t *pipe, uint64_t *blob,
void *ptr, size_t length
/*
* Add crtc property changes to the atomic property set
*/
-static void igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj,
drmModeAtomicReq *req)
+void igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicReq
*req)
{
if (pipe_obj->background_changed)
igt_atomic_populate_crtc_req(req, pipe_obj,
IGT_CRTC_BACKGROUND, pipe_obj->background);
@@ -2567,7 +2567,7 @@ static void igt_atomic_prepare_crtc_commit(igt_pipe_t
*pipe_obj, drmModeAtomicRe
/*
* Add connector property changes to the atomic property set
*/
-static void igt_atomic_prepare_connector_commit(igt_output_t *output,
drmModeAtomicReq *req)
+void igt_atomic_prepare_connector_commit(igt_output_t *output,
drmModeAtomicReq *req)
{
struct kmstest_connector_config *config = &output->config;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index ce9a35ef..ab8ec764 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -533,6 +533,8 @@ static inline bool igt_output_is_connected(igt_output_t
*output)
#define igt_atomic_populate_plane_req(req, plane, prop, value) \
igt_assert_lt(0, drmModeAtomicAddProperty(req,
plane->drm_plane->plane_id,\
plane->atomic_props_plane[prop], value))
+void igt_atomic_prepare_plane_commit(igt_plane_t *plane, igt_pipe_t *pipe,
+ drmModeAtomicReq *req);
/**
* igt_atomic_populate_crtc_req:
@@ -544,6 +546,9 @@ static inline bool igt_output_is_connected(igt_output_t
*output)
#define igt_atomic_populate_crtc_req(req, pipe, prop, value) \
igt_assert_lt(0, drmModeAtomicAddProperty(req, pipe->crtc_id,\
pipe->atomic_props_crtc[prop], value))
+
+void igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicReq
*req);
+
/**
* igt_atomic_populate_connector_req:
* @req: A pointer to drmModeAtomicReq
@@ -555,6 +560,8 @@ static inline bool igt_output_is_connected(igt_output_t
*output)
igt_assert_lt(0, drmModeAtomicAddProperty(req,
output->config.connector->connector_id,\
output->config.atomic_props_connector[prop], value))
+void igt_atomic_prepare_connector_commit(igt_output_t *output,
drmModeAtomicReq *req);
+
void igt_enable_connectors(void);
void igt_reset_connectors(void);
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 5b98a5a3..7318855d 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -213,6 +213,7 @@ TESTS_progs = \
kms_tv_load_detect \
kms_universal_plane \
kms_vblank \
+ kms_writeback \
meta_test \
perf \
pm_backlight \
diff --git a/tests/kms_writeback.c b/tests/kms_writeback.c
new file mode 100644
index ..d2066482
--- /dev/null
+++ b/tests/kms_writeback.c
@@ -0,0 +1,371 @@
+/*
+ * (C) COPYRIGHT 2017 ARM Limited. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE O
[Intel-gfx] [PATCH i-g-t v2 6/7] lib/igt_kms: Add igt_output_clone_pipe for cloning
From: Brian Starkey
An output can be added as a clone of any other output(s) attached to a
pipe using igt_output_clone_pipe()
Signed-off-by: Brian Starkey
---
lib/igt_kms.c | 90 +--
lib/igt_kms.h | 3 ++
2 files changed, 59 insertions(+), 34 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index aae32202..85dc0aa8 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1560,6 +1560,17 @@ static void igt_display_log_shift(igt_display_t
*display, int shift)
igt_assert(display->log_shift >= 0);
}
+static int igt_output_idx(igt_output_t *output)
+{
+ int i;
+
+ for (i = 0; i < output->display->n_outputs; i++)
+ if (&output->display->outputs[i] == output)
+ return i;
+
+ return -1;
+}
+
static void igt_output_refresh(igt_output_t *output)
{
igt_display_t *display = output->display;
@@ -1990,40 +2001,6 @@ void igt_display_fini(igt_display_t *display)
display->pipes = NULL;
}
-static void igt_display_refresh(igt_display_t *display)
-{
- igt_output_t *output;
- int i;
-
- unsigned long pipes_in_use = 0;
-
- /* Check that two outputs aren't trying to use the same pipe */
- for (i = 0; i < display->n_outputs; i++) {
- output = &display->outputs[i];
-
- if (pipes_in_use & output->pending_crtc_idx_mask)
- goto report_dup;
-
- pipes_in_use |= output->pending_crtc_idx_mask;
-
- if (output->force_reprobe)
- igt_output_refresh(output);
- }
-
- return;
-
-report_dup:
- for (; i > 0; i--) {
- igt_output_t *b = &display->outputs[i - 1];
-
- igt_assert_f(output->pending_crtc_idx_mask !=
-b->pending_crtc_idx_mask,
-"%s and %s are both trying to use pipe %s\n",
-igt_output_name(output), igt_output_name(b),
-kmstest_pipe_name(ffs(b->pending_crtc_idx_mask) -
1));
- }
-}
-
static igt_pipe_t *igt_output_get_driving_pipe(igt_output_t *output)
{
igt_display_t *display = output->display;
@@ -2047,6 +2024,38 @@ static igt_pipe_t
*igt_output_get_driving_pipe(igt_output_t *output)
return &display->pipes[pipe];
}
+static void igt_display_refresh(igt_display_t *display)
+{
+ igt_output_t *output;
+ igt_pipe_t *pipe;
+ int i;
+
+ unsigned long pipes_in_use = 0;
+
+ /* Check that outputs and pipes agree wrt. cloning */
+ for (i = 0; i < display->n_outputs; i++) {
+ output = &display->outputs[i];
+
+ pipe = igt_output_get_driving_pipe(output);
+ if (pipe) {
+ igt_assert_f(pipe->outputs & (1 <<
igt_output_idx(output)),
+"Output %s not expected to be using pipe
%s\n",
+igt_output_name(output),
+kmstest_pipe_name(pipe->pipe));
+
+ if (pipes_in_use & output->pending_crtc_idx_mask)
+ LOG(display, "Output %s clones pipe %s\n",
+ igt_output_name(output),
+ kmstest_pipe_name(pipe->pipe));
+ }
+
+ pipes_in_use |= output->pending_crtc_idx_mask;
+
+ if (output->force_reprobe)
+ igt_output_refresh(output);
+ }
+}
+
static igt_plane_t *igt_pipe_get_plane(igt_pipe_t *pipe, int plane_idx)
{
igt_assert_f(plane_idx >= 0 && plane_idx < pipe->n_planes,
@@ -2941,6 +2950,16 @@ void igt_output_override_mode(igt_output_t *output,
drmModeModeInfo *mode)
pipe->mode_changed = true;
}
+void igt_output_clone_pipe(igt_output_t *output, enum pipe pipe)
+{
+ igt_display_t *display = output->display;
+ uint32_t current_clones = display->pipes[pipe].outputs;
+
+ igt_output_set_pipe(output, pipe);
+
+ display->pipes[pipe].outputs |= current_clones;
+}
+
void igt_output_set_pipe(igt_output_t *output, enum pipe pipe)
{
igt_display_t *display = output->display;
@@ -2952,6 +2971,7 @@ void igt_output_set_pipe(igt_output_t *output, enum pipe
pipe)
old_pipe = igt_output_get_driving_pipe(output);
old_pipe->mode_changed = true;
+ old_pipe->outputs &= ~(1 << igt_output_idx(output));
}
if (pipe == PIPE_NONE) {
@@ -2963,6 +2983,8 @@ void igt_output_set_pipe(igt_output_t *output, enum pipe
pipe)
output->pending_crtc_idx_mask = 1 << pipe;
display->pipes[pipe].mode_changed = true;
+
+ display->pipes[pipe].outputs = (1 << igt_output_idx(output));
}
output->config.pipe_changed = true;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index ab8ec764..9d
[Intel-gfx] [PATCH i-g-t v2 2/7] lib/igt_kms: Add writeback support in lib/
From: Brian Starkey
Add support in igt_kms for Writeback connectors, with the ability to
attach framebuffers and retrieve fences.
Signed-off-by: Brian Starkey
---
lib/igt_aux.c | 1 +
lib/igt_kms.c | 76 ++-
lib/igt_kms.h | 16 +
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 86a213c2..ad80452a 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -1106,6 +1106,7 @@ static const struct type_name connector_type_names[] = {
{ DRM_MODE_CONNECTOR_eDP, "eDP" },
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
{ DRM_MODE_CONNECTOR_DSI, "DSI" },
+ { DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
{}
};
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 6390229f..02e2b274 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -186,7 +186,10 @@ const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
"scaling mode",
- "CRTC_ID"
+ "CRTC_ID",
+ "WRITEBACK_PIXEL_FORMATS",
+ "WRITEBACK_FB_ID",
+ "WRITEBACK_OUT_FENCE_PTR"
};
/*
@@ -1832,6 +1835,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
output->pending_crtc_idx_mask = 0;
output->id = resources->connectors[i];
output->display = display;
+ output->writeback_out_fence_fd = -1;
igt_output_refresh(output);
@@ -1899,6 +1903,42 @@ igt_output_t *igt_output_from_connector(igt_display_t
*display,
return found;
}
+void igt_output_set_writeback_fb(igt_output_t *output, struct igt_fb *fb)
+{
+ igt_display_t *display = output->display;
+ struct kmstest_connector_config *config = &output->config;
+
+ if (config->connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK)
+ return;
+
+ LOG(display, "%s: output_set_writeback_fb(%d)\n", output->name,
+ fb ? fb->fb_id : 0);
+
+ output->writeback_fb = fb;
+}
+
+static void igt_output_reset_writeback_out_fence(igt_output_t *output)
+{
+ if (output->writeback_out_fence_fd >= 0) {
+ close(output->writeback_out_fence_fd);
+ output->writeback_out_fence_fd = -1;
+ }
+}
+
+void igt_output_request_writeback_out_fence(igt_output_t *output)
+{
+ igt_output_reset_writeback_out_fence(output);
+ output->writeback_out_fence_requested = true;
+}
+
+int igt_output_get_last_writeback_out_fence(igt_output_t *output)
+{
+ int fd = output->writeback_out_fence_fd;
+ output->writeback_out_fence_fd = -1;
+
+ return fd;
+}
+
static void igt_pipe_fini(igt_pipe_t *pipe)
{
int i;
@@ -1922,6 +1962,8 @@ static void igt_pipe_fini(igt_pipe_t *pipe)
static void igt_output_fini(igt_output_t *output)
{
kmstest_free_connector_config(&output->config);
+ if (output->writeback_out_fence_fd >= 0)
+ close(output->writeback_out_fence_fd);
free(output->name);
output->name = NULL;
}
@@ -2541,10 +2583,41 @@ static void
igt_atomic_prepare_connector_commit(igt_output_t *output, drmModeAto
igt_atomic_populate_connector_req(req, output,
IGT_CONNECTOR_CRTC_ID, crtc_id);
}
+
+ if (output->writeback_fb) {
+ igt_atomic_populate_connector_req(req, output,
IGT_CONNECTOR_WRITEBACK_FB_ID, output->writeback_fb->fb_id);
+ output->writeback_fb = NULL;
+ }
+
+ igt_output_reset_writeback_out_fence(output);
+ if (output->writeback_out_fence_requested) {
+ igt_atomic_populate_connector_req(req, output,
IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR,
+
(uint64_t)(uintptr_t)&output->writeback_out_fence_fd);
+ }
+
/*
* TODO: Add all other connector level properties here
*/
+}
+
+static void handle_writeback_out_fences(igt_display_t *display, uint32_t
flags, int ret)
+{
+ int i;
+ for (i = 0; i < display->n_outputs; i++) {
+ igt_output_t *output = &display->outputs[i];
+
+ if (!output->config.connector)
+ continue;
+
+ if (!output->writeback_out_fence_requested)
+ continue;
+
+ output->writeback_out_fence_requested = false;
+
+ if (ret || (flags & DRM_MODE_ATOMIC_TEST_ONLY))
+ igt_assert(output->writeback_out_fence_fd == -1);
+ }
}
/*
@@ -2593,6 +2666,7 @@ static int igt_atomic_commit(igt_display_t *display,
uint32_t flags, void *user_
}
ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data);
+ handle_writeback_out_fences(display, flags, ret);
drmModeAtomicFree(req);
return ret;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 35428f3e..ce9a35ef 100644
--- a/lib/igt_kms.h
+++ b/lib/ig
[Intel-gfx] [PATCH i-g-t v2 5/7] kms_writeback: Add writeback-check-output
From: Brian Starkey
Add a test which makes commits using the writeback connector, and
checks the output buffer hash to make sure it is/isn't written as
appropriate.
Signed-off-by: Brian Starkey
---
tests/kms_writeback.c | 123 ++
1 file changed, 123 insertions(+)
diff --git a/tests/kms_writeback.c b/tests/kms_writeback.c
index d2066482..8201a81c 100644
--- a/tests/kms_writeback.c
+++ b/tests/kms_writeback.c
@@ -29,6 +29,7 @@
#include "igt.h"
#include "igt_fb.h"
+#include "sw_sync.h"
/* We need to define these ourselves until we get an updated libdrm */
#ifndef DRM_MODE_CONNECTOR_WRITEBACK
@@ -278,6 +279,115 @@ static void writeback_fb_id(igt_output_t *output,
igt_fb_t *valid_fb, igt_fb_t *
igt_assert(ret == 0);
}
+static void fill_fb(igt_fb_t *fb, double color[3])
+{
+ cairo_t *cr = igt_get_cairo_ctx(fb->fd, fb);
+ igt_assert(cr);
+
+ igt_paint_color(cr, 0, 0, fb->width, fb->height,
+ color[0], color[1], color[2]);
+}
+
+static void get_and_wait_out_fence(igt_output_t *output)
+{
+ int ret, out_fence = out_fence =
igt_output_get_last_writeback_out_fence(output);
+ igt_assert(out_fence >= 0);
+
+ ret = sync_fence_wait(out_fence, 1000);
+ igt_assert(ret == 0);
+ close(out_fence);
+}
+
+static void writeback_seqence(igt_output_t *output, igt_plane_t *plane,
+ igt_fb_t *in_fb, igt_fb_t *out_fbs[], int
n_commits)
+{
+ int i, color_idx = 0;
+ double in_fb_colors[2][3] = {
+ { 1.0, 0.0, 0.0 },
+ { 0.0, 1.0, 0.0 },
+ };
+ double clear_color[3] = { 1.0, 1.0, 1.0 };
+ igt_crc_t cleared_crc, out_expected;
+
+ for (i = 0; i < n_commits; i++, color_idx++) {
+ /* Change the input color each time */
+ fill_fb(in_fb, in_fb_colors[color_idx % 2]);
+
+ if (out_fbs[i]) {
+ igt_crc_t out_before;
+
+ /* Get the expected CRC */
+ fill_fb(out_fbs[i], in_fb_colors[color_idx % 2]);
+ igt_fb_get_crc(out_fbs[i], &out_expected);
+
+ fill_fb(out_fbs[i], clear_color);
+ if (i == 0)
+ igt_fb_get_crc(out_fbs[i], &cleared_crc);
+ igt_fb_get_crc(out_fbs[i], &out_before);
+ igt_assert_crc_equal(&cleared_crc, &out_before);
+ }
+
+ /* Commit */
+ igt_plane_set_fb(plane, in_fb);
+ igt_output_set_writeback_fb(output, out_fbs[i]);
+ if (out_fbs[i])
+ igt_output_request_writeback_out_fence(output);
+ igt_display_commit_atomic(output->display,
+ DRM_MODE_ATOMIC_ALLOW_MODESET,
+ NULL);
+ if (out_fbs[i])
+ get_and_wait_out_fence(output);
+
+ /* Make sure the old output buffer is untouched */
+ if (i > 0 && out_fbs[i - 1] && (out_fbs[i] != out_fbs[i - 1])) {
+ igt_crc_t out_prev;
+ igt_fb_get_crc(out_fbs[i - 1], &out_prev);
+ igt_assert_crc_equal(&cleared_crc, &out_prev);
+ }
+
+ /* Make sure this output buffer is written */
+ if (out_fbs[i]) {
+ igt_crc_t out_after;
+ igt_fb_get_crc(out_fbs[i], &out_after);
+ igt_assert_crc_equal(&out_expected, &out_after);
+
+ /* And clear it, for the next time */
+ fill_fb(out_fbs[i], clear_color);
+ }
+ }
+}
+
+static void writeback_check_output(igt_output_t *output, igt_plane_t *plane,
+ igt_fb_t *input_fb, igt_fb_t *output_fb)
+{
+ igt_fb_t *out_fbs[2] = { 0 };
+ igt_fb_t second_out_fb;
+ int ret;
+
+ /* One commit, with a writeback. */
+ writeback_seqence(output, plane, input_fb, &output_fb, 1);
+
+ /* Two commits, the second with no writeback */
+ out_fbs[0] = output_fb;
+ writeback_seqence(output, plane, input_fb, out_fbs, 2);
+
+ /* Two commits, both with writeback */
+ out_fbs[1] = output_fb;
+ writeback_seqence(output, plane, input_fb, out_fbs, 2);
+
+ ret = igt_create_fb(output_fb->fd, output_fb->width, output_fb->height,
+ DRM_FORMAT_XRGB,
+ igt_fb_mod_to_tiling(0),
+ &second_out_fb);
+ igt_require(ret > 0);
+
+ /* Two commits, with different writeback buffers */
+ out_fbs[1] = &second_out_fb;
+ writeback_seqence(output, plane, input_fb, out_fbs, 2);
+
+ igt_remove_fb(output_fb->fd, &second_out_fb);
+}
+
igt_main
{
igt_displa
[Intel-gfx] [PATCH i-g-t v2 7/7] kms_writeback: Add tests using a cloned output
From: Brian Starkey
Update the connector search to also optionally attempt to find a
non-writeback connector to clone to.
Add a subtest which is the same as writeback-check-output, but also
clones to the second connector.
Signed-off-by: Brian Starkey
---
tests/kms_writeback.c | 63 ---
1 file changed, 55 insertions(+), 8 deletions(-)
diff --git a/tests/kms_writeback.c b/tests/kms_writeback.c
index 8201a81c..9a34bca0 100644
--- a/tests/kms_writeback.c
+++ b/tests/kms_writeback.c
@@ -81,7 +81,8 @@ static uint32_t pick_writeback_format(igt_output_t *output)
return format;
}
-static bool check_writeback_config(igt_display_t *display, igt_output_t
*output)
+static bool check_writeback_config(igt_display_t *display, igt_output_t
*output,
+ int pipe, igt_output_t **clone)
{
igt_fb_t input_fb, output_fb;
igt_plane_t *plane;
@@ -123,6 +124,27 @@ static bool check_writeback_config(igt_display_t *display,
igt_output_t *output)
ret = igt_display_try_commit_atomic(display, DRM_MODE_ATOMIC_TEST_ONLY |
DRM_MODE_ATOMIC_ALLOW_MODESET,
NULL);
+ if (!ret && clone) {
+ /* Try and find a clone */
+ int i, newret;
+ *clone = NULL;
+
+ for (i = 0; i < display->n_outputs; i++) {
+ igt_output_t *second_output = &display->outputs[i];
+ if (output != second_output &&
+ igt_pipe_connector_valid(pipe, second_output)) {
+
+ igt_output_clone_pipe(second_output, pipe);
+ newret = igt_display_try_commit_atomic(display,
DRM_MODE_ATOMIC_TEST_ONLY |
+
DRM_MODE_ATOMIC_ALLOW_MODESET, NULL);
+ igt_output_set_pipe(second_output, PIPE_NONE);
+ if (!newret) {
+ *clone = second_output;
+ break;
+ }
+ }
+ }
+ }
igt_plane_set_fb(plane, NULL);
igt_remove_fb(display->drm_fd, &input_fb);
igt_remove_fb(display->drm_fd, &output_fb);
@@ -130,7 +152,8 @@ static bool check_writeback_config(igt_display_t *display,
igt_output_t *output)
return !ret;
}
-static igt_output_t *kms_writeback_get_output(igt_display_t *display)
+static igt_output_t *kms_writeback_get_output(igt_display_t *display, enum
pipe *pipe,
+ igt_output_t **clone)
{
int i;
@@ -146,10 +169,16 @@ static igt_output_t
*kms_writeback_get_output(igt_display_t *display)
for (j = 0; j < igt_display_get_n_pipes(display); j++) {
igt_output_set_pipe(output, j);
- if (check_writeback_config(display, output)) {
+ if (check_writeback_config(display, output, j, clone)) {
igt_debug("Using connector %u:%s on pipe %d\n",
output->config.connector->connector_id,
output->name, j);
+ if (clone && *clone)
+ igt_debug("Cloning to connector
%u:%s\n",
+
(*clone)->config.connector->connector_id,
+ (*clone)->name);
+ if (pipe)
+ *pipe = j;
return output;
}
}
@@ -190,9 +219,6 @@ static int do_writeback_test(igt_output_t *output, uint32_t
flags,
igt_pipe_t *pipe_obj = &display->pipes[pipe];
igt_plane_t *plane;
- /*
-* Add CRTC Properties to the property set
-*/
igt_atomic_prepare_crtc_commit(pipe_obj, req);
for_each_plane_on_pipe(display, pipe, plane) {
@@ -391,10 +417,11 @@ static void writeback_check_output(igt_output_t *output,
igt_plane_t *plane,
igt_main
{
igt_display_t display;
- igt_output_t *output;
+ igt_output_t *output, *clone;
igt_plane_t *plane;
igt_fb_t input_fb;
drmModeModeInfo mode;
+ enum pipe pipe;
int ret;
memset(&display, 0, sizeof(display));
@@ -409,7 +436,7 @@ igt_main
igt_require(display.is_atomic);
- output = kms_writeback_get_output(&display);
+ output = kms_writeback_get_output(&display, &pipe, &clone);
igt_require(output);
if (output->use_override_mode)
@@ -487,6 +514,26 @@ igt_main
igt_remove_fb(d
[Intel-gfx] [PATCH i-g-t v2 4/7] lib: Add function to hash a framebuffer
From: Brian Starkey
To use writeback buffers as a CRC source, we need to be able to hash
them. Implement a simple FVA-1a hashing routine for this purpose.
Doing a bytewise hash on the framebuffer directly can be very slow if
the memory is noncached. By making a copy of each line in the FB first
(which can take advantage of word-access speedup), we can do the hash
on a cached copy, which is much faster (10x speedup on my platform).
Signed-off-by: Brian Starkey
---
lib/igt_fb.c | 65
lib/igt_fb.h | 5 +
2 files changed, 70 insertions(+)
diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index d2b7e9e3..f613bb2e 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -1302,3 +1302,68 @@ void igt_get_all_cairo_formats(const uint32_t **formats,
int *format_count)
*formats = drm_formats;
*format_count = n_formats;
}
+
+/*
+ * This implements the FNV-1a hashing algorithm instead of CRC, for
+ * simplicity
+ * http://www.isthe.com/chongo/tech/comp/fnv/index.html
+ *
+ * hash = offset_basis
+ * for each octet_of_data to be hashed
+ * hash = hash xor octet_of_data
+ * hash = hash * FNV_prime
+ * return hash
+ *
+ * 32 bit offset_basis = 2166136261
+ * 32 bit FNV_prime = 224 + 28 + 0x93 = 16777619
+ */
+int igt_fb_get_crc(struct igt_fb *fb, igt_crc_t *crc)
+{
+#define FNV1a_OFFSET_BIAS 2166136261
+#define FNV1a_PRIME 16777619
+ uint32_t hash;
+ void *map;
+ char *ptr, *line = NULL;
+ int x, y, cpp = igt_drm_format_to_bpp(fb->drm_format) / 8;
+
+ if (fb->is_dumb)
+ map = kmstest_dumb_map_buffer(fb->fd, fb->gem_handle, fb->size,
+ PROT_READ);
+ else
+ map = gem_mmap__gtt(fb->fd, fb->gem_handle, fb->size,
+ PROT_READ);
+ ptr = map;
+
+ /*
+* Framebuffers are often uncached, which can make byte-wise accesses
+* very slow. We copy each line of the FB into a local buffer to speed
+* up the hashing.
+*/
+ line = malloc(fb->stride);
+ if (!line) {
+ munmap(map, fb->size);
+ return -ENOMEM;
+ }
+
+ hash = FNV1a_OFFSET_BIAS;
+
+ for (y = 0; y < fb->height; y++, ptr += fb->stride) {
+
+ memcpy(line, ptr, fb->stride);
+
+ for (x = 0; x < fb->width * cpp; x++) {
+ hash ^= line[x];
+ hash *= FNV1a_PRIME;
+ }
+ }
+
+ crc->n_words = 1;
+ crc->crc[0] = hash;
+
+ free(line);
+ munmap(map, fb->size);
+
+ return 0;
+#undef FNV1a_OFFSET_BIAS
+#undef FNV1a_PRIME
+}
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 4a680cef..04430e9d 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -43,6 +43,8 @@ typedef struct _cairo cairo_t;
#include
+#include "igt_crc.h"
+
/**
* igt_fb_t:
* @fb_id: KMS ID of the framebuffer
@@ -156,5 +158,8 @@ uint32_t igt_drm_format_to_bpp(uint32_t drm_format);
const char *igt_format_str(uint32_t drm_format);
void igt_get_all_cairo_formats(const uint32_t **formats, int *format_count);
+/* Get a hash for a framebuffer */
+int igt_fb_get_crc(struct igt_fb *fb, igt_crc_t *crc);
+
#endif /* __IGT_FB_H__ */
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface
From: Matthew Auld
The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
available through the i915 perf interface.
This will relieve the kernel from holding all the possible configs, so
we can leave only the test configs here.
v2: Drop DRM_ERROR for userspace errors (Matthew)
Add padding to userspace structure (Matthew)
s/guid/uuid/ (Matthew)
v3: Use u32 instead of int to iterate through registers (Matthew)
Signed-off-by: Matthew Auld
Signed-off-by: Lionel Landwerlin
Signed-off-by: Andrzej Datczuk
---
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 25 +++
drivers/gpu/drm/i915/i915_perf.c | 352 ++-
drivers/gpu/drm/i915/i915_reg.h | 2 +
include/uapi/drm/i915_drm.h | 24 +++
5 files changed, 404 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..a3d339670ec1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2730,6 +2730,8 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM,
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM,
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl,
DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_PERF_ADD_CONFIG, i915_perf_add_config_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(I915_PERF_REMOVE_CONFIG,
i915_perf_remove_config_ioctl, DRM_UNLOCKED|DRM_RENDER_ALLOW),
};
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e2853b31d0e6..dd72e32581db 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2043,6 +2043,25 @@ struct i915_perf_stream {
*/
struct i915_oa_ops {
/**
+* @is_valid_b_counter_reg: Validates register's address for
+* programming boolean counters for a particular platform.
+*/
+ bool (*is_valid_b_counter_reg)(struct drm_i915_private *dev_priv,
+ u32 addr);
+
+ /**
+* @is_valid_mux_reg: Validates register's address for programming mux
+* for a particular platform.
+*/
+ bool (*is_valid_mux_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+ /**
+* @is_valid_flex_reg: Validates register's address for programming
+* flex EU filtering for a particular platform.
+*/
+ bool (*is_valid_flex_reg)(struct drm_i915_private *dev_priv, u32 addr);
+
+ /**
* @init_oa_buffer: Resets the head and tail pointers of the
* circular buffer for periodic OA reports.
*
@@ -2433,6 +2452,8 @@ struct drm_i915_private {
struct mutex lock;
struct list_head streams;
+ struct idr metrics_idr;
+
struct {
struct i915_perf_stream *exclusive_stream;
@@ -3599,6 +3620,10 @@ i915_gem_context_lookup_timeline(struct i915_gem_context
*ctx,
int i915_perf_open_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+int i915_perf_add_config_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
+int i915_perf_remove_config_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
void i915_oa_init_reg_state(struct intel_engine_cs *engine,
struct i915_gem_context *ctx,
uint32_t *reg_state);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index b658635b9b89..bd698893511e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2652,7 +2652,7 @@ static struct i915_oa_config *get_oa_config(struct
drm_i915_private *dev_priv,
if (metrics_set == 1)
return &dev_priv->perf.oa.test_config;
- return NULL;
+ return idr_find(&dev_priv->perf.metrics_idr, metrics_set);
}
/**
@@ -2913,6 +2913,7 @@ void i915_perf_register(struct drm_i915_private *dev_priv)
&dev_priv->perf.oa.test_config.sysfs_metric);
if (ret)
goto sysfs_error;
+
goto exit;
sysfs_error:
@@ -2944,6 +2945,334 @@ void i915_perf_unregister(struct drm_i915_private
*dev_priv)
dev_priv->perf.metrics_kobj = NULL;
}
+static bool gen8_is_valid_flex_addr(struct drm_i915_private *dev_priv, u32
addr)
+{
+ static const i915_reg_t flex_eu_regs[] = {
+ EU_PERF_CNTL0,
+ EU_PERF_CNTL1,
+
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix user ptr check size in eb_relocate_vma()
Quoting Imre Deak (2017-07-14 16:12:42)
> Fix the sizeof(ptr) vs. sizeof(*ptr) typo.
>
> Fixes: 2889caa92321 - ("drm/i915: Eliminate lots of iterations over the
> execobjects array")
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Signed-off-by: Imre Deak
/o\ Oops.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/3] Add support for loadable OA configs
Hi again, Here is a v4 that uncovered an issue in the existing code. Thanks to Matthew for his in-depth review! Cheers, Lionel Landwerlin (2): drm/i915/perf: fix flex eu registers programming drm/i915/perf: prune OA configs Matthew Auld (1): drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface drivers/gpu/drm/i915/i915_drv.c |2 + drivers/gpu/drm/i915/i915_drv.h | 69 +- drivers/gpu/drm/i915/i915_oa_bdw.c| 5360 + drivers/gpu/drm/i915/i915_oa_bdw.h|8 +- drivers/gpu/drm/i915/i915_oa_bxt.c| 2623 +--- drivers/gpu/drm/i915/i915_oa_bxt.h|8 +- drivers/gpu/drm/i915/i915_oa_chv.c| 2806 + drivers/gpu/drm/i915/i915_oa_chv.h|8 +- drivers/gpu/drm/i915/i915_oa_glk.c| 2535 +--- drivers/gpu/drm/i915/i915_oa_glk.h|8 +- drivers/gpu/drm/i915/i915_oa_hsw.c| 764 + drivers/gpu/drm/i915/i915_oa_hsw.h|8 +- drivers/gpu/drm/i915/i915_oa_kblgt2.c | 2971 +- drivers/gpu/drm/i915/i915_oa_kblgt2.h |8 +- drivers/gpu/drm/i915/i915_oa_kblgt3.c | 3020 +-- drivers/gpu/drm/i915/i915_oa_kblgt3.h |8 +- drivers/gpu/drm/i915/i915_oa_sklgt2.c | 3458 + drivers/gpu/drm/i915/i915_oa_sklgt2.h |8 +- drivers/gpu/drm/i915/i915_oa_sklgt3.c | 3019 +-- drivers/gpu/drm/i915/i915_oa_sklgt3.h |8 +- drivers/gpu/drm/i915/i915_oa_sklgt4.c | 3073 +-- drivers/gpu/drm/i915/i915_oa_sklgt4.h |8 +- drivers/gpu/drm/i915/i915_perf.c | 656 ++-- drivers/gpu/drm/i915/i915_reg.h |2 + include/uapi/drm/i915_drm.h | 24 + 25 files changed, 904 insertions(+), 29558 deletions(-) -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/3] drm/i915/perf: fix flex eu registers programming
We were reserving fewer dwords in the ring than necessary. Indeed we're always writing all registers once, so discard the actual number of registers given by the user and just program the whitelisted ones once. Reported-by: Matthew Auld Signed-off-by: Lionel Landwerlin Cc: # v4.12+ --- drivers/gpu/drm/i915/i915_perf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index d9f77a4d85db..ed396f7b7dca 100644 --- a/drivers/gpu/drm/i915/i915_perf.c +++ b/drivers/gpu/drm/i915/i915_perf.c @@ -1601,11 +1601,11 @@ static int gen8_emit_oa_config(struct drm_i915_gem_request *req) u32 *cs; int i; - cs = intel_ring_begin(req, n_flex_regs * 2 + 4); + cs = intel_ring_begin(req, ARRAY_SIZE(flex_mmio) * 2 + 4); if (IS_ERR(cs)) return PTR_ERR(cs); - *cs++ = MI_LOAD_REGISTER_IMM(n_flex_regs + 1); + *cs++ = MI_LOAD_REGISTER_IMM(ARRAY_SIZE(flex_mmio) + 1); *cs++ = i915_mmio_reg_offset(GEN8_OACTXCONTROL); *cs++ = (dev_priv->perf.oa.period_exponent << GEN8_OA_TIMER_PERIOD_SHIFT) | -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Fix error checking/locking in perf/lookup_context()
1acfc104cdf8 missed to convert this one caller to be lockless. The side
effect of that was that the error check in lookup_context() became
incorrect. Convert now this caller too.
Fixes: 1acfc104cdf ("drm/i915: Enable rcu-only context lookups")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_perf.c | 32 +---
1 file changed, 5 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index d9f77a4d85db..96682fd86f82 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2483,27 +2483,6 @@ static const struct file_operations fops = {
};
-static struct i915_gem_context *
-lookup_context(struct drm_i915_private *dev_priv,
- struct drm_i915_file_private *file_priv,
- u32 ctx_user_handle)
-{
- struct i915_gem_context *ctx;
- int ret;
-
- ret = i915_mutex_lock_interruptible(&dev_priv->drm);
- if (ret)
- return ERR_PTR(ret);
-
- ctx = i915_gem_context_lookup(file_priv, ctx_user_handle);
- if (!IS_ERR(ctx))
- i915_gem_context_get(ctx);
-
- mutex_unlock(&dev_priv->drm.struct_mutex);
-
- return ctx;
-}
-
/**
* i915_perf_open_ioctl_locked - DRM ioctl() for userspace to open a stream FD
* @dev_priv: i915 device instance
@@ -2545,12 +2524,11 @@ i915_perf_open_ioctl_locked(struct drm_i915_private
*dev_priv,
u32 ctx_handle = props->ctx_handle;
struct drm_i915_file_private *file_priv = file->driver_priv;
- specific_ctx = lookup_context(dev_priv, file_priv, ctx_handle);
- if (IS_ERR(specific_ctx)) {
- ret = PTR_ERR(specific_ctx);
- if (ret != -EINTR)
- DRM_DEBUG("Failed to look up context with ID %u
for opening perf stream\n",
- ctx_handle);
+ specific_ctx = i915_gem_context_lookup(file_priv, ctx_handle);
+ if (!specific_ctx) {
+ DRM_DEBUG("Failed to look up context with ID %u for
opening perf stream\n",
+ ctx_handle);
+ ret = -ENOENT;
goto err;
}
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Fix user ptr check size in eb_relocate_vma()
Fix the sizeof(ptr) vs. sizeof(*ptr) typo.
Fixes: 2889caa92321 - ("drm/i915: Eliminate lots of iterations over the
execobjects array")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 929f275e67aa..fe3e0d40034c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1459,7 +1459,7 @@ static int eb_relocate_vma(struct i915_execbuffer *eb,
struct i915_vma *vma)
* to read. However, if the array is not writable the user loses
* the updated relocation values.
*/
- if (unlikely(!access_ok(VERIFY_READ, urelocs, remain*sizeof(urelocs
+ if (unlikely(!access_ok(VERIFY_READ, urelocs, remain*sizeof(*urelocs
return -EFAULT;
do {
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page
Quoting Oscar Mateo (2017-07-14 15:52:59) > > > > On 07/13/2017 03:28 PM, Rodrigo Vivi wrote: > > On Wed, May 3, 2017 at 9:31 AM, Chris Wilson > > wrote: > >> On Wed, May 03, 2017 at 09:12:18AM +, Oscar Mateo wrote: > >>> On 05/03/2017 08:52 AM, Mika Kuoppala wrote: > >>> > >>> Oscar Mateo [1] writes: > >>> > >>> > >>> On 05/02/2017 09:17 AM, Mika Kuoppala wrote: > >>> > >>> Chris Wilson [2] writes: > >>> > >>> > >>> On Fri, Apr 28, 2017 at 09:11:06AM +, Oscar Mateo wrote: > >>> > >>> The new batchbuffer for CNL surpasses the 4096 byte mark. > >>> > >>> Cc: Mika Kuoppala [3] > >>> Cc: Ben Widawsky [4] > >>> Signed-off-by: Oscar Mateo [5] > >>> > >>> Evil, 4k+ of nothing-ness that userspace then has to configure for > >>> itself > >>> for correctness anyway. > >>> > >>> Patch looks ok, but still question the sanity. > >>> > >>> Is there a requirement for CNL to init the renderstate? > >>> > >>> I would like to drop the render state init from CNL if > >>> we can't find evidence that it needs it. Bspec indicates > >>> that it doesnt. > > I'd like to drop as well, and I was hearing people around telling we > > didn't need anymore, > > however without this during power on I had bad failures... > > > > The best I could get from architecture (+Raf) is that setting valid and > coherent values for the whole render state is required as soon as the > context is created, no matter who does it. If you see failures when the > KMD does not do it, that means the UMD must be missing something, right? That is my initial response as well. The kernel does load one context, just so that the hardware always has space to write to on power saving. The only batch executed for it is the golden render state. Easy enough to only initialise that kernel context to isolate whether it is self-inflicted or that userspace overlooked something in its state management. (I have the view that even if userspace doesn't think it needs to use a particular bit of state today, tomorrow it will so will need it anyway!) -Chris > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 12/12] drm/atomic: Allow drm_atomic_helper_swap_state to fail
On Tue, Jul 11, 2017 at 04:33:14PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index bfb98fbd0e0e..05a22aeffbb0 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2261,13 +2261,13 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
> *
> * Returns:
> *
> - * Always returns 0, cannot fail yet.
> + * Returns 0 on success. Can return -ERESTARTSYS when @stall is true and the
> + * waiting for the previous commits has been interrupted.
> */
Reviewed-by: Daniel Vetter
> int drm_atomic_helper_swap_state(struct drm_atomic_state *state,
> bool stall)
> {
> - int i;
> - long ret;
> + int i, ret;
> struct drm_connector *connector;
> struct drm_connector_state *old_conn_state, *new_conn_state;
> struct drm_crtc *crtc;
> @@ -2290,12 +2290,11 @@ int drm_atomic_helper_swap_state(struct
> drm_atomic_state *state,
> if (!commit)
> continue;
>
> - ret = wait_for_completion_timeout(&commit->hw_done,
> - 10*HZ);
> - if (ret == 0)
> - DRM_ERROR("[CRTC:%d:%s] hw_done timed out\n",
> - crtc->base.id, crtc->name);
> + ret =
> wait_for_completion_interruptible(&commit->hw_done);
> drm_crtc_commit_put(commit);
> +
> + if (ret)
> + return ret;
> }
> }
>
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 11/12] drm/atomic: Add __must_check to drm_atomic_helper_swap_state.
On Tue, Jul 11, 2017 at 04:33:13PM +0200, Maarten Lankhorst wrote: > Now that all drivers check the return value, convert swap_state to > __must_check. This is done separately to force build warnings if we > missed a driver. > > Signed-off-by: Maarten Lankhorst Maybe squash in with the next commit, seems a bit silly to split this out. Either way: Reviewed-by: Daniel Vetter > --- > include/drm/drm_atomic_helper.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h > index 37c9534ff691..8871741fa723 100644 > --- a/include/drm/drm_atomic_helper.h > +++ b/include/drm/drm_atomic_helper.h > @@ -84,7 +84,8 @@ void > drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc_state > *old_crtc_state, >bool atomic); > > -int drm_atomic_helper_swap_state(struct drm_atomic_state *state, bool stall); > +int __must_check drm_atomic_helper_swap_state(struct drm_atomic_state *state, > + bool stall); > > /* nonblocking commit helpers */ > int drm_atomic_helper_setup_commit(struct drm_atomic_state *state, > -- > 2.11.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 10/12] drm/vc4: Handle drm_atomic_helper_swap_state failure
On Tue, Jul 11, 2017 at 04:33:12PM +0200, Maarten Lankhorst wrote: > drm_atomic_helper_swap_state() will be changed to interruptible waiting > in the next few commits, so all drivers have to be changed to handling > failure. > > VC4 has its own nonblocking modeset tracking through the vc4->async_modeset > semaphore, so it doesn't need to stall in swap_state. Pass stall = false > and BUG_ON when it returns an error. This should never happen for !stall. > > Signed-off-by: Maarten Lankhorst > Cc: Eric Anholt Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/vc4/vc4_kms.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c > index 27edae427025..aeec6e8703d2 100644 > --- a/drivers/gpu/drm/vc4/vc4_kms.c > +++ b/drivers/gpu/drm/vc4/vc4_kms.c > @@ -126,7 +126,7 @@ static int vc4_atomic_commit(struct drm_device *dev, >* the software side now. >*/ > > - drm_atomic_helper_swap_state(state, true); > + BUG_ON(drm_atomic_helper_swap_state(state, false) < 0); > > /* >* Everything below can be run asynchronously without the need to grab > -- > 2.11.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 08/12] drm/tegra: Handle drm_atomic_helper_swap_state failure
On Tue, Jul 11, 2017 at 04:33:10PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: linux-te...@vger.kernel.org
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/tegra/drm.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index ad3d124a972d..3ba659a5940d 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -100,7 +100,12 @@ static int tegra_atomic_commit(struct drm_device *drm,
>* the software side now.
>*/
>
> - drm_atomic_helper_swap_state(state, true);
> + err = drm_atomic_helper_swap_state(state, true);
> + if (err) {
> + mutex_unlock(&tegra->commit.lock);
> + drm_atomic_helper_cleanup_planes(drm, state);
> + return err;
> + }
>
> drm_atomic_state_get(state);
> if (nonblock)
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 07/12] drm/msm: Handle drm_atomic_helper_swap_state failure
On Tue, Jul 11, 2017 at 04:33:09PM +0200, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
>
> MSM has its own busy tracking, which means the swap_state call can be
> done with stall = false, in which case it should never return an error.
> Handle failure with BUG_ON for this reason.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Rob Clark
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> ---
> drivers/gpu/drm/msm/msm_atomic.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_atomic.c
> b/drivers/gpu/drm/msm/msm_atomic.c
> index 9633a68b14d7..badfa8717317 100644
> --- a/drivers/gpu/drm/msm/msm_atomic.c
> +++ b/drivers/gpu/drm/msm/msm_atomic.c
> @@ -232,20 +232,18 @@ int msm_atomic_commit(struct drm_device *dev,
>* mark our set of crtc's as busy:
>*/
> ret = start_atomic(dev->dev_private, c->crtc_mask);
> - if (ret) {
> - kfree(c);
> - goto error;
> - }
> + if (ret)
> + goto err_free;
> +
> + BUG_ON(drm_atomic_helper_swap_state(state, false) < 0);
Hm, not sure we want to do this, makes switching msm to the nonblocking
helpers a bit more tricky. And the got err_free thing looks like leftovers
from an old version. But it's all correct.
Reviewed-by: Daniel Vetter
>
> /*
>* This is the point of no return - everything below never fails except
>* when the hw goes bonghits. Which means we can commit the new state on
>* the software side now.
> + *
> + * swap driver private state while still holding state_lock
>*/
> -
> - drm_atomic_helper_swap_state(state, true);
> -
> - /* swap driver private state while still holding state_lock */
> if (to_kms_state(state)->state)
> priv->kms->funcs->swap_state(priv->kms, state);
>
> @@ -275,6 +273,8 @@ int msm_atomic_commit(struct drm_device *dev,
>
> return 0;
>
> +err_free:
> + kfree(c);
> error:
> drm_atomic_helper_cleanup_planes(dev, state);
> return ret;
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/12] drm/atomic: Make drm_atomic_helper_swap_state waiting interruptible.
On Tue, Jul 11, 2017 at 04:33:02PM +0200, Maarten Lankhorst wrote: > drm_atomic_helper_swap_state could previously never fail, in order to still > continue it would set a limit of 10s on waiting for previous updates to > complete, > then it moved forward. This can be very bad when ignoring previous updates, > because the hw state and sw state may get out of sync when for example a > modeset > is ignored. > > By converting the swap_state to interruptible and handling the error in each > driver, > we fix this issue because if a update takes forever it can be aborted through > signals. > > Changes since first version: > - Split out driver conversions. > - Fix nouveau error handling first. > > Maarten Lankhorst (12): > drm/nouveau: Fix error handling in nv50_disp_atomic_commit > drm/atomic: Change drm_atomic_helper_swap_state to return an error. > drm/nouveau: Handle drm_atomic_helper_swap_state failure > drm/atmel-hlcdc: Handle drm_atomic_helper_swap_state failure > drm/i915: Handle drm_atomic_helper_swap_state failure > drm/mediatek: Handle drm_atomic_helper_swap_state failure > drm/msm: Handle drm_atomic_helper_swap_state failure > drm/tegra: Handle drm_atomic_helper_swap_state failure > drm/tilcdc: Handle drm_atomic_helper_swap_state failure > drm/vc4: Handle drm_atomic_helper_swap_state failure > drm/atomic: Add __must_check to drm_atomic_helper_swap_state. > drm/atomic: Allow drm_atomic_helper_swap_state to fail Hi Maarten, The set looks good to me. The core changes make sense and seem like a good step forward, and the driver changes seem like they do the right thing. Normally, I'd suggest waiting a week or so for maintainer acks to trickle in, but since this is fixing behavior in i915, it makes sense to expedite it. Perhaps ping individuals on IRC? For the whole set, Reviewed-by: Sean Paul Sean > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 13 ++- > drivers/gpu/drm/drm_atomic_helper.c | 35 > +--- > drivers/gpu/drm/i915/intel_display.c | 10 +++- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 7 +- > drivers/gpu/drm/msm/msm_atomic.c | 16 ++--- > drivers/gpu/drm/nouveau/nv50_display.c | 12 +++--- > drivers/gpu/drm/tegra/drm.c | 7 +- > drivers/gpu/drm/tilcdc/tilcdc_drv.c | 6 - > drivers/gpu/drm/vc4/vc4_kms.c| 2 +- > include/drm/drm_atomic_helper.h | 4 ++-- > 10 files changed, 75 insertions(+), 37 deletions(-) > > -- > 2.11.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.
On Fri, Jul 14, 2017 at 04:30:30PM +0200, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 04:33:04PM +0200, Maarten Lankhorst wrote:
> > We want to change swap_state to wait indefinitely, but to do this
> > swap_state should wait interruptibly. This requires propagating
> > the error to each driver.
> >
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: linux-ker...@vger.kernel.org
> > Cc: intel-gfx@lists.freedesktop.org
> > Signed-off-by: Maarten Lankhorst
>
> Reviewed-by: Daniel Vetter
>
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 22 --
> > include/drm/drm_atomic_helper.h | 3 +--
> > 2 files changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 667ec97d4efb..bfb98fbd0e0e 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1510,10 +1510,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
> >
> > if (!nonblock) {
> > ret = drm_atomic_helper_wait_for_fences(dev, state, true);
> > - if (ret) {
> > - drm_atomic_helper_cleanup_planes(dev, state);
> > - return ret;
> > - }
> > + if (ret)
> > + goto err;
> > }
> >
> > /*
> > @@ -1522,7 +1520,9 @@ int drm_atomic_helper_commit(struct drm_device *dev,
> > * the software side now.
> > */
> >
> > - drm_atomic_helper_swap_state(state, true);
> > + ret = drm_atomic_helper_swap_state(state, true);
> > + if (ret)
> > + goto err;
> >
> > /*
> > * Everything below can be run asynchronously without the need to grab
> > @@ -1551,6 +1551,10 @@ int drm_atomic_helper_commit(struct drm_device *dev,
> > commit_tail(state);
> >
> > return 0;
> > +
> > +err:
> > + drm_atomic_helper_cleanup_planes(dev, state);
> > + return ret;
> > }
> > EXPORT_SYMBOL(drm_atomic_helper_commit);
> >
> > @@ -2254,8 +2258,12 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
> > * the &drm_plane.state, &drm_crtc.state or &drm_connector.state pointer.
> > With
> > * the current atomic helpers this is almost always the case, since the
> > helpers
> > * don't pass the right state structures to the callbacks.
While you're changing this comment... would you mind s/proceeding/preceding/ and
s/swaped/swapped/ ?
Otherwise,
Reviewed-by: Sean Paul
> > + *
> > + * Returns:
> > + *
> > + * Always returns 0, cannot fail yet.
> > */
> > -void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
> > +int drm_atomic_helper_swap_state(struct drm_atomic_state *state,
> > bool stall)
> > {
> > int i;
> > @@ -2332,6 +2340,8 @@ void drm_atomic_helper_swap_state(struct
> > drm_atomic_state *state,
> >
> > __for_each_private_obj(state, obj, obj_state, i, funcs)
> > funcs->swap_state(obj, &state->private_objs[i].obj_state);
> > +
> > + return 0;
> > }
> > EXPORT_SYMBOL(drm_atomic_helper_swap_state);
> >
> > diff --git a/include/drm/drm_atomic_helper.h
> > b/include/drm/drm_atomic_helper.h
> > index dd196cc0afd7..37c9534ff691 100644
> > --- a/include/drm/drm_atomic_helper.h
> > +++ b/include/drm/drm_atomic_helper.h
> > @@ -84,8 +84,7 @@ void
> > drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc_state
> > *old_crtc_state,
> > bool atomic);
> >
> > -void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
> > - bool stall);
> > +int drm_atomic_helper_swap_state(struct drm_atomic_state *state, bool
> > stall);
> >
> > /* nonblocking commit helpers */
> > int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
> > --
> > 2.11.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page
On 07/13/2017 03:28 PM, Rodrigo Vivi wrote: On Wed, May 3, 2017 at 9:31 AM, Chris Wilson wrote: On Wed, May 03, 2017 at 09:12:18AM +, Oscar Mateo wrote: On 05/03/2017 08:52 AM, Mika Kuoppala wrote: Oscar Mateo [1] writes: On 05/02/2017 09:17 AM, Mika Kuoppala wrote: Chris Wilson [2] writes: On Fri, Apr 28, 2017 at 09:11:06AM +, Oscar Mateo wrote: The new batchbuffer for CNL surpasses the 4096 byte mark. Cc: Mika Kuoppala [3] Cc: Ben Widawsky [4] Signed-off-by: Oscar Mateo [5] Evil, 4k+ of nothing-ness that userspace then has to configure for itself for correctness anyway. Patch looks ok, but still question the sanity. Is there a requirement for CNL to init the renderstate? I would like to drop the render state init from CNL if we can't find evidence that it needs it. Bspec indicates that it doesnt. I'd like to drop as well, and I was hearing people around telling we didn't need anymore, however without this during power on I had bad failures... The best I could get from architecture (+Raf) is that setting valid and coherent values for the whole render state is required as soon as the context is created, no matter who does it. If you see failures when the KMD does not do it, that means the UMD must be missing something, right? -Mika Hi Mika, I can double-check with the hardware architects, but word around here is that render state init has never stopped being a requirement. Where did you see in the BSpec that it is not required for CNL? It would be great if you could refresh the answer and perhaps even get some answers to the 'why' parts. In the "Context Descriptor Format" section, it says: "Render CS Only: Render state need not be initialized; the Render Context Restore Inhibit bit in the Context/Save image in memory should be set to prevent restoring garbage render context." -Mika :_( The same section also says: Â â**See the Logical Ring Context Format section for details.â** Â And then â**Logical Ring Context Formatâ** section goes on to say: Â â**It is tedious for software to populate the engine context as per the requirements, it is recommended to implicitly use engine to populate this portion of the context. [â*¦] Software must program all the state required to initialize the engine in the ring buffer which would initialize the hardware state.â** Yet what the kernel programs is completely garbage for the user, so the user still has to program the initial GPU state to their own specifications. Just say no to policy in the kernel. We need a stronger reason than this, and if that was the only reason the original render state was merged, I am very angry. so... based on what I saw we need this, I agree the justification is not good because I could never actually understand or make any sense out of this golden context But we need a solution to this impasse, to be able to move forward... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/perf: prune OA configs
On 14/07/17 13:20, Matthew Auld wrote:
On 07/14, Lionel Landwerlin wrote:
In the following commit we'll introduce loadable userspace
configs. This change reworks how configurations are handled in the
perf driver and retains only the test configurations in kernel space.
We now store the test config in dev_priv and resolve the id only once
when opening the perf stream. The OA config is then handled through a
pointer to the structure holding the configuration details.
v2: Rework how test configs are handled (Lionel)
v3: Use u32 to hold number of register (Matthew)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 44 +-
drivers/gpu/drm/i915/i915_oa_bdw.c| 5360 +
drivers/gpu/drm/i915/i915_oa_bdw.h|8 +-
drivers/gpu/drm/i915/i915_oa_bxt.c| 2623 +---
drivers/gpu/drm/i915/i915_oa_bxt.h|8 +-
drivers/gpu/drm/i915/i915_oa_chv.c| 2806 +
drivers/gpu/drm/i915/i915_oa_chv.h|8 +-
drivers/gpu/drm/i915/i915_oa_glk.c| 2535 +---
drivers/gpu/drm/i915/i915_oa_glk.h|8 +-
drivers/gpu/drm/i915/i915_oa_hsw.c| 764 +
drivers/gpu/drm/i915/i915_oa_hsw.h|8 +-
drivers/gpu/drm/i915/i915_oa_kblgt2.c | 2971 +-
drivers/gpu/drm/i915/i915_oa_kblgt2.h |8 +-
drivers/gpu/drm/i915/i915_oa_kblgt3.c | 3020 +--
drivers/gpu/drm/i915/i915_oa_kblgt3.h |8 +-
drivers/gpu/drm/i915/i915_oa_sklgt2.c | 3458 +
drivers/gpu/drm/i915/i915_oa_sklgt2.h |8 +-
drivers/gpu/drm/i915/i915_oa_sklgt3.c | 3019 +--
drivers/gpu/drm/i915/i915_oa_sklgt3.h |8 +-
drivers/gpu/drm/i915/i915_oa_sklgt4.c | 3073 +--
drivers/gpu/drm/i915/i915_oa_sklgt4.h |8 +-
drivers/gpu/drm/i915/i915_perf.c | 309 +-
22 files changed, 504 insertions(+), 29558 deletions(-)
-static int gen8_emit_oa_config(struct drm_i915_gem_request *req)
+static int gen8_emit_oa_config(struct drm_i915_gem_request *req,
+ const struct i915_oa_config *oa_config)
{
struct drm_i915_private *dev_priv = req->i915;
- const struct i915_oa_reg *flex_regs = dev_priv->perf.oa.flex_regs;
- int n_flex_regs = dev_priv->perf.oa.flex_regs_len;
/* The MMIO offsets for Flex EU registers aren't contiguous */
u32 flex_mmio[] = {
i915_mmio_reg_offset(EU_PERF_CNTL0),
@@ -1601,11 +1594,14 @@ static int gen8_emit_oa_config(struct
drm_i915_gem_request *req)
u32 *cs;
int i;
- cs = intel_ring_begin(req, n_flex_regs * 2 + 4);
+ if (WARN_ON(!oa_config))
+ return -EINVAL;
+
+ cs = intel_ring_begin(req, oa_config->flex_regs_len * 2 + 4);
if (IS_ERR(cs))
return PTR_ERR(cs);
- *cs++ = MI_LOAD_REGISTER_IMM(n_flex_regs + 1);
+ *cs++ = MI_LOAD_REGISTER_IMM(oa_config->flex_regs_len + 1);
Something doesn't add up here, if we don't supply any flex registers, which
seems to be the case for the oa test configs, or potentially any user provided
config then we only reserve ring_begin(4)/IMM(1), but we still go off and write
out the default flex values as per flex_mmio. Also we could potentially over
reserve since we can only ever write out at most flex_mmio registers.
My first thought is perhaps:
int flex_max = ARRAY_SIZE(flex_mmio);
GEM_BUG_ON(flex_regs_len > flex_max);
cs = intel_ring_begin(req, flex_max * 2 + 4);
*cs++ = MI_LOAD_REGISTER_IMM(flex_max + 1);
for (i = 0; i < flex_max; i++) {
for (...) {
if (addr == mmio) {
value = ...
++count;
}
}
}
GEM_BUG_ON(count != flex_regs_len);
Thanks for pointing this out, there is indeed a problem.
*cs++ = i915_mmio_reg_offset(GEN8_OACTXCONTROL);
*cs++ = (dev_priv->perf.oa.period_exponent <<
GEN8_OA_TIMER_PERIOD_SHIFT) |
@@ -1624,9 +1620,9 @@ static int gen8_emit_oa_config(struct
drm_i915_gem_request *req)
u32 value = 0;
int j;
- for (j = 0; j < n_flex_regs; j++) {
- if (i915_mmio_reg_offset(flex_regs[j].addr) == mmio) {
- value = flex_regs[j].value;
+ for (j = 0; j < oa_config->flex_regs_len; j++) {
+ if (i915_mmio_reg_offset(oa_config->flex_regs[j].addr)
== mmio) {
+ value = oa_config->flex_regs[j].value;
break;
}
}
@@ -1641,7 +1637,8 @@ static int gen8_emit_oa_config(struct
drm_i915_gem_request *req)
return 0;
}
-static int gen8_switch_to_updated_kernel_context(struct drm_i915_private *dev_priv)
+static int gen8_switch_to_updated_kernel_context(struct drm_i915_private
*dev_priv,
+const struct i915_oa_config
*oa_config)
{
struct intel_eng
Re: [Intel-gfx] [PATCH v2 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.
On Tue, Jul 11, 2017 at 04:33:04PM +0200, Maarten Lankhorst wrote:
> We want to change swap_state to wait indefinitely, but to do this
> swap_state should wait interruptibly. This requires propagating
> the error to each driver.
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 22 --
> include/drm/drm_atomic_helper.h | 3 +--
> 2 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 667ec97d4efb..bfb98fbd0e0e 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1510,10 +1510,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
>
> if (!nonblock) {
> ret = drm_atomic_helper_wait_for_fences(dev, state, true);
> - if (ret) {
> - drm_atomic_helper_cleanup_planes(dev, state);
> - return ret;
> - }
> + if (ret)
> + goto err;
> }
>
> /*
> @@ -1522,7 +1520,9 @@ int drm_atomic_helper_commit(struct drm_device *dev,
>* the software side now.
>*/
>
> - drm_atomic_helper_swap_state(state, true);
> + ret = drm_atomic_helper_swap_state(state, true);
> + if (ret)
> + goto err;
>
> /*
>* Everything below can be run asynchronously without the need to grab
> @@ -1551,6 +1551,10 @@ int drm_atomic_helper_commit(struct drm_device *dev,
> commit_tail(state);
>
> return 0;
> +
> +err:
> + drm_atomic_helper_cleanup_planes(dev, state);
> + return ret;
> }
> EXPORT_SYMBOL(drm_atomic_helper_commit);
>
> @@ -2254,8 +2258,12 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
> * the &drm_plane.state, &drm_crtc.state or &drm_connector.state pointer.
> With
> * the current atomic helpers this is almost always the case, since the
> helpers
> * don't pass the right state structures to the callbacks.
> + *
> + * Returns:
> + *
> + * Always returns 0, cannot fail yet.
> */
> -void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
> +int drm_atomic_helper_swap_state(struct drm_atomic_state *state,
> bool stall)
> {
> int i;
> @@ -2332,6 +2340,8 @@ void drm_atomic_helper_swap_state(struct
> drm_atomic_state *state,
>
> __for_each_private_obj(state, obj, obj_state, i, funcs)
> funcs->swap_state(obj, &state->private_objs[i].obj_state);
> +
> + return 0;
> }
> EXPORT_SYMBOL(drm_atomic_helper_swap_state);
>
> diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> index dd196cc0afd7..37c9534ff691 100644
> --- a/include/drm/drm_atomic_helper.h
> +++ b/include/drm/drm_atomic_helper.h
> @@ -84,8 +84,7 @@ void
> drm_atomic_helper_disable_planes_on_crtc(struct drm_crtc_state
> *old_crtc_state,
>bool atomic);
>
> -void drm_atomic_helper_swap_state(struct drm_atomic_state *state,
> - bool stall);
> +int drm_atomic_helper_swap_state(struct drm_atomic_state *state, bool stall);
>
> /* nonblocking commit helpers */
> int drm_atomic_helper_setup_commit(struct drm_atomic_state *state,
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 01/12] drm/nouveau: Fix error handling in nv50_disp_atomic_commit
On Tue, Jul 11, 2017 at 04:33:03PM +0200, Maarten Lankhorst wrote:
> Make it more clear that post commit return ret is really return 0,
>
> and add a missing drm_atomic_helper_cleanup_planes when
> drm_atomic_helper_wait_for_fences fails.
>
> Fixes: 839ca903f12e ("drm/nouveau/kms/nv50: transition to atomic interfaces
> internally")
> Cc: Ben Skeggs
> Cc: dri-de...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: # v4.10+
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/nouveau/nv50_display.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
> b/drivers/gpu/drm/nouveau/nv50_display.c
> index 42a85c14aea0..8fb55b96c40f 100644
> --- a/drivers/gpu/drm/nouveau/nv50_display.c
> +++ b/drivers/gpu/drm/nouveau/nv50_display.c
> @@ -4119,7 +4119,7 @@ nv50_disp_atomic_commit(struct drm_device *dev,
> if (!nonblock) {
> ret = drm_atomic_helper_wait_for_fences(dev, state, true);
> if (ret)
> - goto done;
> + goto err_cleanup;
> }
>
> for_each_plane_in_state(state, plane, plane_state, i) {
> @@ -4147,7 +4147,7 @@ nv50_disp_atomic_commit(struct drm_device *dev,
> if (crtc->state->enable) {
> if (!drm->have_disp_power_ref) {
> drm->have_disp_power_ref = true;
> - return ret;
> + return 0;
> }
> active = true;
> break;
> @@ -4158,7 +4158,10 @@ nv50_disp_atomic_commit(struct drm_device *dev,
> pm_runtime_put_autosuspend(dev->dev);
> drm->have_disp_power_ref = false;
> }
> + goto done;
>
A bit convoluted, I prefer to wrap these in if (ret) to make them only run
for the failure case.
Either way: Reviewed-by: Daniel Vetter
> +err_cleanup:
> + drm_atomic_helper_cleanup_planes(dev, state);
> done:
> pm_runtime_put_autosuspend(dev->dev);
> return ret;
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 7/7] igt/kms_fbc_crc.c : Add Y-tile tests
Em Sex, 2017-07-14 às 19:25 +0530, Praveen Paneri escreveu:
> Hi Paulo,
>
> On Thursday 13 July 2017 02:31 AM, Paulo Zanoni wrote:
> > Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
> > > Now that we have support for Y-tiled buffers, add another
> > > iteration of tests for Y-tiled buffers.
> >
> > Have you tested this on platforms that don't support Y-tiled
> > buffers? I
>
> Unfortunately I haven't...
> > don't see a check for that, so I wonder if we'll just fail some
> > assertion or correctly hit some igt_skip() call I couldn't find.
>
> ...but I will add the check as you have mentioned
> >
> > More below.
> >
> > >
> > > Signed-off-by: Praveen Paneri
> > > ---
> > > tests/kms_fbc_crc.c | 71 +
> > >
> > >
> > > 1 file changed, 39 insertions(+), 32 deletions(-)
> > >
> > > diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
> > > index 7964e05..cdf04c1 100644
> > > --- a/tests/kms_fbc_crc.c
> > > +++ b/tests/kms_fbc_crc.c
> > > @@ -318,12 +318,10 @@ static void prepare_crtc(data_t *data)
> > > igt_output_set_pipe(output, data->pipe);
> > > }
> > >
> > > -static void create_fbs(data_t *data, bool tiled, struct igt_fb
> > > *fbs)
> > > +static void create_fbs(data_t *data, uint64_t tiling, struct
> > > igt_fb
> > > *fbs)
> > > {
> > > int rc;
> > > drmModeModeInfo *mode = igt_output_get_mode(data-
> > > >output);
> > > - uint64_t tiling = tiled ? LOCAL_I915_FORMAT_MOD_X_TILED
> > > :
> > > - LOCAL_DRM_FORMAT_MOD_NONE;
> > >
> > > rc = igt_create_color_fb(data->drm_fd, mode->hdisplay,
> > > mode-
> > > > vdisplay,
> > >
> > > DRM_FORMAT_XRGB, tiling,
> > > @@ -344,8 +342,8 @@ static void get_ref_crcs(data_t *data)
> > > struct igt_fb fbs[4];
> > > int i;
> > >
> > > - create_fbs(data, false, &fbs[0]);
> > > - create_fbs(data, false, &fbs[2]);
> > > + create_fbs(data, LOCAL_DRM_FORMAT_MOD_NONE, &fbs[0]);
> > > + create_fbs(data, LOCAL_DRM_FORMAT_MOD_NONE, &fbs[2]);
> > >
> > > fill_mmap_gtt(data, fbs[2].gem_handle, 0xff);
> > > fill_mmap_gtt(data, fbs[3].gem_handle, 0xff);
> > > @@ -366,7 +364,7 @@ static void get_ref_crcs(data_t *data)
> > > igt_remove_fb(data->drm_fd, &fbs[i]);
> > > }
> > >
> > > -static bool prepare_test(data_t *data, enum test_mode test_mode)
> > > +static bool prepare_test(data_t *data, enum test_mode test_mode,
> > > uint64_t tiling)
> > > {
> > > igt_display_t *display = &data->display;
> > > igt_output_t *output = data->output;
> > > @@ -374,7 +372,7 @@ static bool prepare_test(data_t *data, enum
> > > test_mode test_mode)
> > >
> > > data->primary = igt_output_get_plane_type(data->output,
> > > DRM_PLANE_TYPE_PRIMARY);
> > >
> > > - create_fbs(data, true, data->fb);
> > > + create_fbs(data, tiling, data->fb);
> > >
> > > igt_pipe_crc_free(data->pipe_crc);
> > > data->pipe_crc = NULL;
> > > @@ -484,32 +482,41 @@ static void run_test(data_t *data, enum
> > > test_mode mode)
> > >
> > > reset_display(data);
> > >
> > > - for_each_pipe_with_valid_output(display, data->pipe,
> > > data-
> > > > output) {
> > >
> > > - prepare_crtc(data);
> > > -
> > > - igt_info("Beginning %s on pipe %s, connector
> > > %s\n",
> > > - igt_subtest_name(),
> > > - kmstest_pipe_name(data->pipe),
> > > - igt_output_name(data->output));
> > > -
> > > - if (!prepare_test(data, mode)) {
> > > - igt_info("%s on pipe %s, connector %s:
> > > SKIPPED\n",
> > > - igt_subtest_name(),
> > > - kmstest_pipe_name(data->pipe),
> > > - igt_output_name(data-
> > > >output));
> > > - continue;
> > > + for (int tiling = I915_TILING_X;
> > > + tiling <= I915_TILING_Y; tiling++) {
> >
> > What I don't understand is why this part of the code chooses to go
> > with
> > the tiling constants (I915_TILING_) only to later convert them to
> > modifiers with igt_fb_tiling_to_mod(). If this loop iterated over
> > the
> > modifiers directly we wouldn't need that. The rest of the code only
> > cares about the modifiers.
>
> I chose to loop over tiling constants as they are in a simple
> arithmetic
> order. anyhow I will just change that.
Just put the two local_format stuff in an array and iterate over it.
>
> Also as mentioned above can I just add a check to skip Y-tiling
> tests
> for older platforms?
>
> igt_skip_on(intel_gen(intel_get_drm_devid(drm_fd)) < 9 &&
> tiling == I915_TILING_Y);
You can't do this here because the same subtest tests X tiling.
Perhaps we could make Y tiling be a separate subtest? I'm not a huge
fan of single tests that do tons of stuff.
>
> >
> >
> > > + for_each_pipe_with_valid_output(display,
> > > + data->pipe,
> > > data-
> > > > output
Re: [Intel-gfx] [RFC v2] drm/hdcp: drm enum property for HDCP State
On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
> DRM connector property is created to represent the content protection
> state of the connector and to configure the same.
>
> CP States defined:
> DRM_CP_UNSUPPORTED - CP is not supported
> DRM_CP_DISABLE - CP is disabled
> DRM_CP_ENABLE - CP is enabled
Why are we changing the names from the original version (that's used in CrOS)?
It's not
obvious what "CP" stands for when looking at the name.
>
> V2: Redesigned the property to match with CP needs of CrOS.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/drm_connector.c | 14 +
> include/drm/drm_hdcp.h | 44
> +
> include/drm/drm_mode_config.h | 5 +
> 3 files changed, 63 insertions(+)
> create mode 100644 include/drm/drm_hdcp.h
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 5cd61af..64895fb 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #include "drm_crtc_internal.h"
> #include "drm_internal.h"
> @@ -617,6 +618,13 @@ static const struct drm_prop_enum_list
> drm_link_status_enum_list[] = {
> };
> DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
>
> +static const struct drm_prop_enum_list drm_cp_enum_list[] = {
> + { DRM_CP_UNSUPPORTED, "CP Not Supported" },
> + { DRM_CP_DISABLE, "Disable CP" },
> + { DRM_CP_ENABLE,"Enable CP for Type0 content" },
Type0 has no meaning in this case. The whole point of using "Content Protection"
is to abstract the means of protection from userspace. The names are also much
more verbose than they need be. "Unsupported", "Disabled", "Enabled" are fine.
> +};
> +DRM_ENUM_NAME_FN(drm_get_cp_status_name, drm_cp_enum_list)
> +
> /**
> * drm_display_info_set_bus_formats - set the supported bus formats
> * @info: display info to store bus formats in
> @@ -789,6 +797,12 @@ int drm_connector_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.link_status_property = prop;
>
> + prop = drm_property_create_enum(dev, 0, "cp", drm_cp_enum_list,
> +ARRAY_SIZE(drm_cp_enum_list));
Your property name here, on the other hand, is not descriptive enough. Please
expand to something meaningful.
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.cp_property = prop;
> +
> return 0;
> }
>
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
Why create a new header for this? That seems a little excessive.
Sean
> new file mode 100644
> index 000..f6d0160
> --- /dev/null
> +++ b/include/drm/drm_hdcp.h
> @@ -0,0 +1,44 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and
> its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all copies and that both that
> copyright
> + * notice and this permission notice appear in supporting documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission. The copyright holders make no representations
> + * about the suitability of this software for any purpose. It is provided
> "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
> USE,
> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
> PERFORMANCE
> + * OF THIS SOFTWARE.
> + */
> +
> +/*
> + * Header for HDCP specific data
> + */
> +
> +#ifndef __DRM_HDCP_H__
> +#define __DRM_HDCP_H__
> +
> +/**
> + * CP property related information
> + */
> +enum drm_cp_state {
> +
> + /* HDCP sink and Src dont have any common HDCP ver supported */
> + DRM_CP_UNSUPPORTED,
> +
> + /* Disable Content Protection */
> + DRM_CP_DISABLE,
> +
> + /* Enable Content Protection */
> + DRM_CP_ENABLE,
> +};
> +#endif /* __DRM_HDCP_H__ */
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 4298171..7acb8b2 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -538,6 +538,11 @@ struct drm_mode_config {
>*/
> struct drm_property *link_status_property;
> /**
> + * @cp_property: Default connector property for
Re: [Intel-gfx] [PATCH] lib/igt_draw: Add Y-tiling support
On Friday 14 July 2017 03:03 AM, Paulo Zanoni wrote:
Em Sex, 2017-06-09 às 15:48 +0530, Praveen Paneri escreveu:
This patch adds Y-tiling support for igt_draw_rect function.
v2: Use helper function to get tile sizes (Ville)
v3: Moved igt_get_fb_tile_size() out of the for loop
for better performance (Paulo)
For some reason I thought this series was using my original patch, but
I realized it's not:
https://patchwork.freedesktop.org/patch/72039/
Now that I read our past emails, I wonder that maybe I didn't send you
this specific patch of that series. I'm sorry for that. Obviously I'm
biased towards my version. Which one do you think is better? Would you
be willing to give my version a r-b, in case you think it's better?
Your version looks better. I will add my r-b and post it
Thanks
Praveen
Thanks,
Paulo
Signed-off-by: Praveen Paneri
---
lib/igt_draw.c | 139 ++-
--
1 file changed, 94 insertions(+), 45 deletions(-)
diff --git a/lib/igt_draw.c b/lib/igt_draw.c
index 29aec85..2138bf7 100644
--- a/lib/igt_draw.c
+++ b/lib/igt_draw.c
@@ -136,32 +136,45 @@ static int swizzle_addr(int addr, int swizzle)
/* It's all in "pixel coordinates", so make sure you multiply/divide
by the bpp
* if you need to. */
-static int linear_x_y_to_tiled_pos(int x, int y, uint32_t stride,
int swizzle,
- int bpp)
+static int linear_x_y_to_tiled_pos(int fd, int x, int y, uint32_t
stride, int swizzle,
+ int bpp, int tiling, uint32_t
tile_width,
+ uint32_t tile_height)
{
- int x_tile_size, y_tile_size;
- int x_tile_n, y_tile_n, x_tile_off, y_tile_off;
- int line_size, tile_size;
+ uint32_t tile_size;
+ int tile_x, tile_y; /* Co-ordinates of the tile holding the
pixel */
+ int tile_x_off, tile_y_off; /* pixel position inside the
tile */
int tile_n, tile_off;
- int tiled_pos, tiles_per_line;
+ int line_size, tiles_per_line;
+ int tiled_pos;
int pixel_size = bpp / 8;
line_size = stride;
- x_tile_size = 512;
- y_tile_size = 8;
- tile_size = x_tile_size * y_tile_size;
- tiles_per_line = line_size / x_tile_size;
+ tile_size = tile_width * tile_height;
+ tiles_per_line = line_size / tile_width;
- y_tile_n = y / y_tile_size;
- y_tile_off = y % y_tile_size;
+ tile_y = y / tile_height;
+ tile_y_off = y % tile_height;
- x_tile_n = (x * pixel_size) / x_tile_size;
- x_tile_off = (x * pixel_size) % x_tile_size;
+ tile_x = (x * pixel_size) / tile_width;
+ tile_x_off = (x * pixel_size) % tile_width;
- tile_n = y_tile_n * tiles_per_line + x_tile_n;
- tile_off = y_tile_off * x_tile_size + x_tile_off;
- tiled_pos = tile_n * tile_size + tile_off;
+ tile_n = tile_y * tiles_per_line + tile_x;
+
+ if (tiling == I915_TILING_X ) {
+ tile_off = tile_y_off * tile_width + tile_x_off;
+ } else { /* (tiling == I915_TILING_Y ) */
+ int x_oword_n, x_oword_off;
+ int oword_size = 16;
+
+ /* computation inside the tile */
+ x_oword_n = tile_x_off / oword_size;
+ x_oword_off = tile_x_off % oword_size;
+ tile_off = x_oword_n * tile_height * oword_size
+ + tile_y_off * oword_size
+ + x_oword_off;
+ }
+ tiled_pos = tile_n * tile_size + tile_off;
tiled_pos = swizzle_addr(tiled_pos, swizzle);
return tiled_pos / pixel_size;
@@ -169,34 +182,48 @@ static int linear_x_y_to_tiled_pos(int x, int
y, uint32_t stride, int swizzle,
/* It's all in "pixel coordinates", so make sure you multiply/divide
by the bpp
* if you need to. */
-static void tiled_pos_to_x_y_linear(int tiled_pos, uint32_t stride,
- int swizzle, int bpp, int *x,
int *y)
+static void tiled_pos_to_x_y_linear(int fd, int tiled_pos, uint32_t
stride,
+ int swizzle, int bpp, int *x,
int *y,
+ int tiling, uint32_t tile_width,
+ uint32_t tile_height)
{
- int tile_n, tile_off, tiles_per_line, line_size;
- int x_tile_off, y_tile_off;
- int x_tile_n, y_tile_n;
- int x_tile_size, y_tile_size, tile_size;
+ uint32_t tile_size;
+ int tile_x, tile_y; /* Co-ordinates of the tile holding the
pixel */
+ int tile_x_off, tile_y_off; /* pixel position inside the
tile */
+ int tile_n, tile_off;
+ int line_size, tiles_per_line;
int pixel_size = bpp / 8;
tiled_pos = swizzle_addr(tiled_pos, swizzle);
line_size = stride;
- x_tile_size = 512;
- y_tile_size = 8;
- tile_size = x_tile_size * y_tile_size;
- tiles_per_line = line_size / x_tile_size;
+ tile_siz
Re: [Intel-gfx] [PATCH v2 5/7] tests/kms_draw_crc: add support for Y tiling
On Friday 14 July 2017 01:49 AM, Paulo Zanoni wrote:
Em Qua, 2017-07-12 às 13:45 +0530, Praveen Paneri escreveu:
Hi Paulo,
On Wednesday 12 July 2017 12:33 AM, Paulo Zanoni wrote:
Em Sex, 2017-04-28 às 20:07 +0530, Praveen Paneri escreveu:
From: Paulo Zanoni
This is the program that's supposed to test lib/igt_draw. We just
added Y tiling support for the library, so add the tests now.
This is not my original version of the patch, yet there's no
changelog
mentioning that this is a new version.
https://patchwork.freedesktop.org/patch/72040/
Why were the kmstest_unset_all_crtcs() calls added? My guess is
that
they ended up here as a rebase artifact, but please clarify if
there's
an actual reason.
Yes this is a rebase artifact and is not actually required. I will
fix it.
Or you can just give a reviewed-by tag to my original patch :).
Sure! I will add that in the next series :)
Thanks,
Praveen
Signed-off-by: Paulo Zanoni
Signed-off-by: Praveen Paneri
---
tests/kms_draw_crc.c | 58
++--
1 file changed, 43 insertions(+), 15 deletions(-)
diff --git a/tests/kms_draw_crc.c b/tests/kms_draw_crc.c
index c57d3a3..1d91b48 100644
--- a/tests/kms_draw_crc.c
+++ b/tests/kms_draw_crc.c
@@ -47,6 +47,13 @@ static const uint32_t formats[N_FORMATS] = {
DRM_FORMAT_XRGB2101010,
};
+#define N_TILING_METHODS 3
+static const uint64_t tilings[N_TILING_METHODS] = {
+ LOCAL_DRM_FORMAT_MOD_NONE,
+ LOCAL_I915_FORMAT_MOD_X_TILED,
+ LOCAL_I915_FORMAT_MOD_Y_TILED,
+};
+
struct base_crc {
bool set;
igt_crc_t crc;
@@ -151,6 +158,11 @@ static void draw_method_subtest(enum
igt_draw_method method,
{
igt_crc_t crc;
+ if (tiling == LOCAL_I915_FORMAT_MOD_Y_TILED)
+ igt_require(intel_gen(intel_get_drm_devid(drm_fd
))
= 9);
+
+ kmstest_unset_all_crtcs(drm_fd, drm_res);
+
/* Use IGT_DRAW_MMAP_GTT on an untiled buffer as the
parameter for
* comparison. Cache the value so we don't recompute it
for
every single
* subtest. */
@@ -208,6 +220,12 @@ static void fill_fb_subtest(void)
get_fill_crc(LOCAL_I915_FORMAT_MOD_X_TILED, &crc);
igt_assert_crc_equal(&crc, &base_crc);
+ if (intel_gen(intel_get_drm_devid(drm_fd)) >= 9) {
+ get_fill_crc(LOCAL_I915_FORMAT_MOD_Y_TILED,
&crc);
+ igt_assert_crc_equal(&crc, &base_crc);
+ }
+
+ kmstest_unset_all_crtcs(drm_fd, drm_res);
igt_remove_fb(drm_fd, &fb);
}
@@ -265,28 +283,38 @@ static const char *format_str(int
format_index)
}
}
+static const char *tiling_str(int tiling_index)
+{
+ switch (tilings[tiling_index]) {
+ case LOCAL_DRM_FORMAT_MOD_NONE:
+ return "untiled";
+ case LOCAL_I915_FORMAT_MOD_X_TILED:
+ return "xtiled";
+ case LOCAL_I915_FORMAT_MOD_Y_TILED:
+ return "ytiled";
+ default:
+ igt_assert(false);
+ }
+}
+
igt_main
{
enum igt_draw_method method;
- int format_index;
+ int format_idx, tiling_idx;
igt_fixture
setup_environment();
- for (format_index = 0; format_index < N_FORMATS;
format_index++) {
- for (method = 0; method < IGT_DRAW_METHOD_COUNT;
method++) {
- igt_subtest_f("draw-method-%s-%s-
untiled",
- format_str(format_index),
- igt_draw_get_method_name(m
etho
d))
- draw_method_subtest(method,
format_index,
- LOCAL_DRM_FO
RMAT
_MOD_NONE);
- igt_subtest_f("draw-method-%s-%s-tiled",
- format_str(format_index),
- igt_draw_get_method_name(m
etho
d))
- draw_method_subtest(method,
format_index,
- LOCAL_I915_FORMA
T_MO
D_X_TILED);
- }
- }
+ for (format_idx = 0; format_idx < N_FORMATS;
format_idx++) {
+ for (method = 0; method < IGT_DRAW_METHOD_COUNT;
method++) {
+ for (tiling_idx = 0; tiling_idx < N_TILING_METHODS;
tiling_idx++) {
+ igt_subtest_f("draw-method-%s-%s-%s",
+ format_str(format_idx),
+ igt_draw_get_method_name(method),
+ tiling_str(tiling_idx))
+ draw_method_subtest(method, format_idx,
+ tilings[tiling_idx])
;
+ } } }
igt_subtest("fill-fb")
fill_fb_subtest();
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
