Re: [Intel-gfx] [RESEND-CI v4 13/15] drm/i915: prepare csc unit for YCBCR HDMI output
Regards
Shashank
On 6/29/2017 5:38 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
To support ycbcr HDMI output, we need a pipe CSC block to
do the RGB->YCBCR conversion, as the blender output is in RGB.
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, to perform RGB->YCBCR conversion
as per recommended spec values.
Please do a full reference to the "spec", including name, version and relevant
section.
Sure, will add more details.
V2: Rebase
V3: Rebase
V4: Rebase
Cc: Ville Syrjala
Cc: Daniel Vetter
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_color.c | 47 +++-
drivers/gpu/drm/i915/intel_display.c | 32
2 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 306c6b0..12d5f21 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -41,6 +41,19 @@
#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
+
+/* Direct spec values for RGB->YUV conversion matrix */
+#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
+
Not a big fan or hardcoding this in the register format. We already have the
code for converting a number to the right format for the register in
i915_load_csc_matrix(). I think it would make more sense to extract the code
that actually writes the matrix out of that function, so it would just
unconditionally use a matrix and coefficients passed as arguments. Then the
values above would be defined in the format expected for this new function.
Actually I had a small discussion on this with Ville, and we think that
the current CSC multiplication code is not correct.
So if CTM and limited color range is applied together, we might not be
getting the right values. So not planning to
reuse that code. I think while sending the BT2020 patches, we will add a
fix for that part too, but right now not working on it.
/*
* 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 +104,35 @@ 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);
+
+ /* We don't use high values for conversion */
+ I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+ I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+ I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+ /* Program direct spec values for RGB to YCBCR conversion matrix */
+ 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);
+
+ /* Spec postoffset values */
+ 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);
+
+ /* CSC mode before gamma */
+ 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 +143,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->hdmi_output > DRM_HDMI_OUTPUT_DEFAULT_RGB) {
+ i9xx_load_ycbcr_conversion_matrix(intel_crtc);
+ return;
+ } else if (crtc_state->ctm) {
Hmm, I'm not sure this is the right place to check for this condition. I mean,
we shouldn't allow the modeset to happen in this case.
If you please have a look at the intel_crtc_compute_ycbcr_config check
added in this patch, that's doing the same.
Its not allowing HDMI output conversion and pipe level CTM at the same
time.
struct drm_color_ctm *ctm =
(struct drm_color_ctm *)crtc_state->ctm->
Re: [Intel-gfx] [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset
Regards
Shashank
On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2017-06-21 at 16:04 +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
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_atomic.c | 6 ++
drivers/gpu/drm/i915/intel_display.c | 26 ++
drivers/gpu/drm/i915/intel_drv.h | 10 +-
drivers/gpu/drm/i915/intel_hdmi.c| 10 ++
drivers/gpu/drm/i915/intel_panel.c | 3 ++-
5 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 36d4e63..a8c9ac5 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
/* panel fitter case: assign as a crtc scaler */
scaler_id = &scaler_state->scaler_id;
+ } else if (i == SKL_HDMI_OUTPUT_INDEX) {
+ name = "HDMI-OUTPUT";
+ idx = intel_crtc->base.base.id;
+
+ /* hdmi output case: needs a pipe scaler */
+ scaler_id = &scaler_state->scaler_id;
} else {
name = "PLANE";
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index da29536..983f581 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4626,6 +4626,11 @@ 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->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
+ && scaler_user == SKL_HDMI_OUTPUT_INDEX)
Is it really necessary to check for both? If it is, what's the point of creating
SKL_HDMI_OUTPUT_INDEX?
Yes, else this will affect scaler update for planes, as this function
gets called to update the plane scalers too, at that time the output
will be still valid (as its at CRTC level), but the
scaler user would be different.
+ /* YCBCR 444 -> 420 conversion needs a scaler */
+ need_scaling = true;
+
/*
* if plane is being disabled or scaler is no more required or force
detach
* - free scaler binded to this plane/crtc
@@ -4673,6 +4678,26 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
}
/**
+ * skl_update_scaler_hdmi_output - Stages update to scaler state for HDMI.
+ * HDMI YCBCR 420 output needs a scaler, for downsampling.
+ *
+ * @state: crtc's scaler state
+ *
+ * Return
+ * 0 - scaler_usage updated successfully
+ *error - requested scaling cannot be supported or other error condition
+ */
+int skl_update_scaler_crtc_hdmi_output(struct intel_crtc_state *state)
+{
+ const struct drm_display_mode *mode = &state->base.adjusted_mode;
+
+ return skl_update_scaler(state, !state->base.active,
+ SKL_HDMI_OUTPUT_INDEX, &state->scaler_state.scaler_id,
+ state->pipe_src_w, state->pipe_src_h,
+ mode->crtc_hdisplay, mode->crtc_vdisplay);
+}
+
+/**
* skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
*
* @state: crtc's scaler state
@@ -8058,6 +8083,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);
+ enum drm_hdmi_output_type hdmi_out = intel_crtc->config->hdmi_output;
if (IS_BROADWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 9) {
u32 val = 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 38fe56c..2206aa8 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
* bit 31- crtc
*
* Instead of creating a new index to cover planes and crtc, using
@@ -484,6 +485,12 @@ struct intel_crtc_scaler_state {
* avilability.
*/
#define SKL_CRTC_INDEX 31
+
+ /*
+
Re: [Intel-gfx] [PATCH v5 7/7] drm: create hdmi output property
Regards
Shashank
On 6/27/2017 5:44 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:13PM +0530, Shashank Sharma wrote:
HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
- RGB
- YCBCR 444
- YCBCR 422
- YCBCR 420
This patch adds a drm property "hdmi_output_format", using which,
a user can specify its preference, for the HDMI output type. The
output type enums are similar to the mentioned outputs above. To
handle various subsampling of YCBCR output types, this property
allows two special cases:
- DRM_HDMI_OUTPUT_YCBCR_HQ
This indicates preferred output should be YCBCR output, with highest
subsampling rate by the source/sink, which can be typically:
- ycbcr444
- ycbcr422
- ycbcr420
- DRM_HDMI_OUTPUT_YCBCR_LQ
This indicates preferred output should be YCBCR output, with lowest
subsampling rate supported by source/sink, which can be:
- ycbcr420
- ycbcr422
- ycbcr444
I think we'll eventually need something more thorough than this to
allow full control over the AVI infoframe/MSA MISC/VSC SDP colormietry
stuff.
So I think we need to control at least these things:
- max bpc (some people seem to have some real needs to avoid deep color)
- rgb->ycbcr conversion (yes/no)
- ycbcr subsampling for the conversion and infoframe
- ycbcr encoding for the conversion and infoframe
- infoframe colorimetry
I've not really figured out how we'll tie all that together in a way
that doesn't get super confusing.
I think we will over complicate stuff, if we try to address everything
in this same series. My high level vision for the
work was:
- Let this series just deals with HDMI output, and handles the output
color model only, using the AVI IF (which is being handled already in
the next patch)
- The BT2020 patch series will (should) take care of everything which is
related to output color spaces (including AVI IF)
As this series deals with stuff which comes into picture post blending,
it should focus on just the output color model and sub-sampling, which
its doing
using the HDMI_OUTPUT property introduced.
But at the same time I agree, that max_bpc is something we should
introduce at the DRM level, instead of keeping it at driver level.
One idea might be that the infoframe stuff is totally independent of
the rest (ie. we'll define just an enum property for the infoframe
stuff in say this way:
"Automatic", "sRGB", "AdobeRGB", "YCbCr BT.601 4:2:2",
"xvYCC709 4:4:4", etc.
So none of the YCbCr output properties would actually affect the
infoframe unless the user has selected the default "Automatic" mode.
That should allow the user to output any kind of data through the pipe
in a pass through fashion (or with manually set up gamma/degamma/csc).
And configuring the inforame property would not affect the data passing
through the pipe in any way.
But I probably need to think more about this. So for now I think I'll
just want to get the automagic "use YCbCr 4:2:0 if we must" thing
working without any new properties getting in the way. We just have
to keep in mind that this automagic conversion thing must still work
when we add some properties, but I think that can generally be achieved
with some "Automatic" default property values.
Ok, I think I am getting the bigger picture now. Yes, I agree, it would
be pretty cool to have something
like this, which makes pipe completely independent in terms of what it
can produce vs what it is
informing via IF. But need to really sit and think about this well.
- Shashank
Default value of the property is set to 0 = RGB, so no changes if you
dont set the property.
PS: While doing modeset for YCBCR 420 only modes, this property is
ignored, as those timings can be supported only in YCBCR 420
output mode.
V2: Added description for the new variable to address build warning
V3: Rebase
V4: Rebase
V5: Added get_property counterpart to fix IGT BAT failures
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Daniel Vetter
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic.c| 4
drivers/gpu/drm/drm_atomic_helper.c | 4
drivers/gpu/drm/drm_connector.c | 32
include/drm/drm_connector.h | 18 ++
include/drm/drm_mode_config.h | 5 +
5 files changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 77dcef0..ea90f8e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1192,6 +1192,8 @@ int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
+ } else if (property == config->hdmi_output_property) {
+ state->hdmi_output = val;
} else if
Re: [Intel-gfx] [RESEND-CI v4 06/15] drm/edid: parse sink information before CEA blocks
Regards Shashank On 6/27/2017 5:25 PM, Ville Syrjälä wrote: On Wed, Jun 21, 2017 at 04:04:04PM +0530, Shashank Sharma wrote: CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. This block contains a map of indexes of CEA modes, which can support YCBCR 420 output also. To avoid multiple parsing of same CEA block, let's parse the sink information and get this map, before parsing CEA modes. This patch moves the call to drm_add_display_info function, before the mode parsing block. Signed-off-by: Shashank Sharma --- drivers/gpu/drm/drm_edid.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index b4583f6..42934b2 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4605,6 +4605,13 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) quirks = edid_get_quirks(edid); /* +* CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. +* To avoid multiple parsing of same block, lets parse that map +* from sink info, before parsing CEA modes. +*/ + drm_add_display_info(connector, edid); + This patch should come before the 4:2:0 mode parsing, no? Dint you ask me to move it later (in the previous series comments), for git-bisect regression type of changes ? Otherwise I think this should be fine so Reviewed-by: Ville Syrjälä Thanks. + /* * EDID spec says modes should be preferred in this order: * - preferred detailed mode * - other detailed modes from base block @@ -4632,8 +4639,6 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75)) edid_fixup_preferred(connector, quirks); - drm_add_display_info(connector, edid); - if (quirks & EDID_QUIRK_FORCE_6BPC) connector->display_info.bpc = 6; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 05/15] drm/edid: parse ycbcr 420 deep color information
Regards
Shashank
On 6/27/2017 5:23 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:03PM +0530, Shashank Sharma wrote:
CEA-861-F spec adds ycbcr420 deep color support information
in hf-vsdb block. This patch extends the existing hf-vsdb parsing
function by adding parsing of ycbcr420 deep color support from the
EDID and adding it into display information stored.
V2: Rebase
V3: Rebase
V4: Moved definition of y420_dc_modes into this patch, where its used
(Ville)
Cc: Ville Syrjälä
Cc: Jose Abreu
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 15 +++
include/drm/drm_connector.h | 3 +++
include/drm/drm_edid.h | 5 +
3 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8c7e73b..b4583f6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4196,6 +4196,19 @@ drm_default_rgb_quant_range(const struct
drm_display_mode *mode)
}
EXPORT_SYMBOL(drm_default_rgb_quant_range);
+static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
+const u8 *db)
+{
+ struct drm_hdmi_info *info = &connector->display_info.hdmi;
+
+ if (db[7] & DRM_EDID_YCBCR420_DC_48)
+ info->y420_dc_modes |= DRM_EDID_YCBCR420_DC_48;
+ if (db[7] & DRM_EDID_YCBCR420_DC_36)
+ info->y420_dc_modes |= DRM_EDID_YCBCR420_DC_36;
+ if (db[7] & DRM_EDID_YCBCR420_DC_30)
+ info->y420_dc_modes |= DRM_EDID_YCBCR420_DC_30;
y420_dc_modes = db[7] & (...);
will do if you plan to just copy the bits over.
Yep, that's a good idea.
Shashank
+}
+
static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector,
const u8 *hf_vsdb)
{
@@ -4236,6 +4249,8 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
scdc->scrambling.low_rates = true;
}
}
+
+ drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
}
static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ce2212d..1305fe9 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -156,6 +156,9 @@ struct drm_hdmi_info {
/** @y420_cmdb_map: bitmap of SVD index, to extraxt vcb modes */
unsigned long y420_cmdb_map;
+
+ /** @y420_dc_modes: bitmap of deep color support index */
+ u8 y420_dc_modes;
};
/**
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 89c0062..d4ff17c 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -213,6 +213,11 @@ struct detailed_timing {
#define DRM_EDID_HDMI_DC_30 (1 << 4)
#define DRM_EDID_HDMI_DC_Y444 (1 << 3)
+/* YCBCR 420 deep color modes */
+#define DRM_EDID_YCBCR420_DC_48 (1 << 6)
+#define DRM_EDID_YCBCR420_DC_36 (1 << 5)
+#define DRM_EDID_YCBCR420_DC_30 (1 << 4)
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 04/15] drm/edid: parse YCBCR 420 videomodes from EDID
Regards
Shashank
On 6/27/2017 5:22 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:02PM +0530, Shashank Sharma wrote:
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.
- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.
This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Emil Velikov
V2: Addressed
Review comments from Emil:
- Use 1ULL< 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
blocks.
V3: Addressed design/review comments from Ville
- Do not add flags in video modes, else we have to expose them to user
- There should not be a UABI change, and kernel should detect the
choice of the output based on type of mode, and the bitmaps.
- Use standard bitops from kernel bitmap header, instead of calculating
bit positions manually.
V4: Addressed review comments from Ville:
- s/ycbcr_420_vdb/y420vdb
- s/ycbcr_420_vcb/y420cmdb
- Be less verbose on description of do_y420vdb_modes
- Move newmode variable in the loop scope.
- Use svd_to_vic() to get a VIC, instead of 0x7f
- Remove bitmap description for CMDB modes & VDB modes
- Dont add connector->ycbcr_420_allowed check for cmdb modes
- Remove 'len' variable, in is_y420cmdb function, which is used
only once
- Add length check in is_y420vdb function
- Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
- Do not add print about YCBCR 420 modes
- Fix indentation in few places
- Move ycbcr420_dc_modes in next patch, where its used
- Add a separate patch for movement of drm_add_display_info()
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 157 +++-
include/drm/drm_connector.h | 20 ++
2 files changed, 174 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e2d1b30..8c7e73b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK 0x04
-#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_DATA_BLOCK_420 0x0E
+#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
#define EDID_BASIC_AUDIO (1 << 6)
#define EDID_CEA_YCRCB444 (1 << 5)
#define EDID_CEA_YCRCB422 (1 << 4)
@@ -3153,15 +3155,79 @@ drm_display_mode_from_vic_index(struct drm_connector
*connector,
return newmode;
}
+/*
+ * do_y420vdb_modes - Parse YCBCR 420 only modes
+ * @connector: connector corresponding to the HDMI sink
+ * @svds: start of the data block of CEA YCBCR 420 VDB
+ * @len: length of the CEA YCBCR 420 VDB
+ *
+ * Parse the CEA-861-F YCBCR 420 Video Data Block (Y420VDB)
+ * which contains modes which can be supported in YCBCR 420
+ * output format only.
+ */
+static int do_y420vdb_modes(struct drm_connector *connector,
+ const u8 *svds, u8 svds_len)
+{
+ int modes = 0, i;
+ struct drm_device *dev = connector->dev;
+ struct drm_display_info *info = &connector->display_info;
+ struct drm_hdmi_info *hdmi = &info->hdmi;
+
+ for (i = 0; i < svds_len; i++) {
+ u8 vic = svd_to_vic(svds[i]);
+ struct drm_display_mode *newmode;
+
+ newmode = drm_mode_duplicate(dev, &edid_cea_modes[vic]);
+ if (!newmode)
+ break;
+ bitmap_set(hdmi->y420_vdb_modes, vic, 1);
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+
+ if (modes > 0)
+ info->c
Re: [Intel-gfx] [RESEND-CI v4 03/15] drm/edid: Complete CEA modedb(VIC 1-107)
Regards
Shashank
On 6/27/2017 5:02 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:01PM +0530, Shashank Sharma wrote:
CEA-861-F specs defines new video modes to be used with
HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to
1-107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse new CEA modes using the existing methods, we have
to complete the modedb (VIC=65 onwards).
This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).
The patch was originaly discussed and reviewed here:
https://patchwork.freedesktop.org/patch/135810/
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Andrzej Hajda
Cc: Alex Deucher
Cc: Harry Wentland
V2: Rebase
V3: Rebase
V4: Added native bit handling as per CEA-861-F spec (Ville)
Reviewed-by: Jose Abreu
Reviewed-by: Alex Deucher
Acked-by: Harry Wentland
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 227 -
1 file changed, 226 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d312fe1..e2d1b30 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1006,6 +1006,221 @@ static const struct drm_display_mode edid_cea_modes[] =
{
2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
...
+ /* 77 - 1920x1080@100Hz */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
+ 2492, 2640, 0, 1080, 1084, 1094, 1125, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
...
+ /* 104 - 3840x2160p@25Hz 64:27 */
+ { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000, 3840, 4016,
+ 4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27},
https://lists.freedesktop.org/archives/dri-devel/2016-November/122669.html
Ok, looks like I missed this one while reformatting the patches, thanks
for reminder.
Will cross check as per your script output.
@@ -2902,6 +3117,16 @@ add_alternate_cea_modes(struct drm_connector *connector,
struct edid *edid)
return modes;
}
+static u8 svd_to_vic(u8 svd)
+{
+
+ /* 0-6 bit vic, 7th bit native mode indicator */
+ if (((svd >= 1) && (svd <= 64)) || ((svd >= 129) && (svd <= 192)))
Too many parentheses. lgtm otherwise.
Got it.
- Shashank
+ return svd & 127;
+
+ return svd;
+}
+
static struct drm_display_mode *
drm_display_mode_from_vic_index(struct drm_connector *connector,
const u8 *video_db, u8 video_len,
@@ -2915,7 +3140,7 @@ drm_display_mode_from_vic_index(struct drm_connector
*connector,
return NULL;
/* CEA modes are numbered 1..127 */
- vic = (video_db[video_index] & 127);
+ vic = svd_to_vic(video_db[video_index]);
if (!drm_valid_cea_vic(vic))
return NULL;
--
2.7.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: Fix the CURSOR_COEFF_MASK used in DDI Vswing Programming
the patch that introduces this error didn't land yet
so, could we squash to the original patch whenever that is reworked to
be resent?
On Thu, Jun 29, 2017 at 6:14 PM, Manasi Navare
wrote:
> The Cursor Coeff is lower 6 bits in the PORT_TX_DW4 register
> and hence the CURSOR_COEFF_MASK should be (0x3F << 0)
>
> Signed-off-by: Manasi Navare
> Cc: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c8647cf..64cc674 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1802,7 +1802,7 @@ enum skl_disp_power_wells {
> #define POST_CURSOR_2(x) ((x) << 6)
> #define POST_CURSOR_2_MASK (0x3F << 6)
> #define CURSOR_COEFF(x) ((x) << 0)
> -#define CURSOR_COEFF_MASK(0x3F << 6)
> +#define CURSOR_COEFF_MASK(0x3F << 0)
>
> #define _CNL_PORT_TX_DW5_GRP_AE0x162354
> #define _CNL_PORT_TX_DW5_GRP_B 0x1623D4
> --
> 2.1.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
Re: [Intel-gfx] [PATCH] drm/i915: Setting pch_id for HSW/BDW in virtual environment
> On Thu, 29 Jun 2017, Daniel Vetter wrote:
> > On Thu, Jun 15, 2017 at 11:11:45AM +0800, Xiong Zhang wrote:
> >> In a IGD passthrough environment, the real ISA bridge may doesn't exist.
> >> then pch_id couldn't be correctly gotten from ISA bridge, but pch_id is
> >> used to identify LPT_H and LPT_LP. Currently i915 treat all LPT pch as
> >> LPT_H,then errors occur when i915 runs on LPT_LP machines with igd
> >> passthrough.
> >>
> >> This patch set pch_id for HSW/BDW according to IGD type and isn't fully
> >> correct. But it solves such issue on HSW/BDW ult/ulx machines.
> >> QA CI system is blocked by this issue for a long time, it's better that
> >> we could merge it to unblock QA CI system.
> >>
> >> We know the root cause is in device model of virtual passthrough, and
> >> will resolve it in the future with several parts cooperation in kernel,
> >> qemu and xen.
> >>
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99938
> >>
> >> Signed-off-by: Xiong Zhang
> >> ---
> >> drivers/gpu/drm/i915/i915_drv.c | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> >> index 1f802de..2e664c5 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.c
> >> +++ b/drivers/gpu/drm/i915/i915_drv.c
> >> @@ -135,6 +135,10 @@ static enum intel_pch intel_virt_detect_pch(struct
> drm_i915_private *dev_priv)
> >>DRM_DEBUG_KMS("Assuming CouarPoint PCH\n");
> >>} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> >>ret = PCH_LPT;
> >> + if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
> >> + dev_priv->pch_id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
> >> + else
> >> + dev_priv->pch_id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
> >
> > So it's imo silly that we're leaking the pch_id to our code when we
> > already have pch_type, but oh well.
>
> It's for distinguishing between LP and non-LP, which we need in the
> code, and why we have this patch in the first place.
>
> > Anyway, this is all about the physical pch on the chip, nothing to do with
> > the virtualized one, and we've been hard-coding these forever.
> >
> > Reviewed-by: Daniel Vetter
> >
> > Afaiui if this isn't true on a machine, someone used a solder iron to
> > build something that Intel doesn't sell.
>
> Bspec says there are (at least) non-ULT/ULX Broadwells with LP PCH. We
> do seem to warn about the combo in the bare metal PCH detection, so I
> guess it's safe to assume they are rare. But strictly speaking this
> change just moves problems from one setup to another.
>
> This has all been covered in the thread that I linked to in my previous
> reply, and all of that discussion has been conveniently overlooked and
> ignored in this patch submission and the commit message.
[Zhang, Xiong Y] Yes, I remembered your concern and have been seeking
the accurate map between IGD and PCH in the past months. Unfortunately
no one could give us such document.
Then as Jonnas suggested, we try to pass real pch id from host to guest.
But we couldn't find a secure and acceptable register to pass such info.
Finally this issue blocks QA CI system for a long time and QA complained
this. So we decided to send this again and resolve part of issue.
This is a limitation of IGD passthrough and need a spec which define
how to pass real pch id from host to guest in virtual environment. But this
need the top level design and much more time.
thanks
>
> I'm not opposed to merging the patch, but this needs to be documented
> for posterity.
>
> Of course, this gets *much* more complicated from SKL/SPT on, where the
> combos can be mixed even more freely (e.g. SKL+KBP and KBL+SPT).
>
>
> BR,
> Jani.
>
>
>
> > -Daniel
> >
> >>DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
> >>} else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
> >>ret = PCH_SPT;
> >> --
> >> 2.7.4
> >>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> 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] ✓ Fi.CI.BAT: success for drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing Programming
== Series Details == Series: drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing Programming URL : https://patchwork.freedesktop.org/series/26588/ State : success == Summary == Series 26588v1 drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing Programming https://patchwork.freedesktop.org/api/1.0/series/26588/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: pass -> FAIL (fi-snb-2600) fdo#100215 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fi-bdw-5557u total:279 pass:264 dwarn:4 dfail:0 fail:0 skip:11 time:441s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:429s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:361s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:525s 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:483s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:595s fi-hsw-4770 total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:434s fi-hsw-4770r total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:410s 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:499s 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:467s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:566s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:586s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:557s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:454s fi-skl-6700hqtotal:279 pass:223 dwarn:1 dfail:0 fail:30 skip:24 time:342s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:468s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:474s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:437s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:547s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:402s 1da9a6d8d2402de8798b36d75bdd7d8b49728a5e drm-tip: 2017y-06m-29d-20h-16m-45s UTC integration manifest e7686b0 drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing Programming == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5077/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing Programming
The Cursor Coeff is lower 6 bits in the PORT_TX_DW4 register
and hence the CURSOR_COEFF_MASK should be (0x3F << 0)
Signed-off-by: Manasi Navare
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c8647cf..64cc674 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1802,7 +1802,7 @@ enum skl_disp_power_wells {
#define POST_CURSOR_2(x) ((x) << 6)
#define POST_CURSOR_2_MASK (0x3F << 6)
#define CURSOR_COEFF(x) ((x) << 0)
-#define CURSOR_COEFF_MASK(0x3F << 6)
+#define CURSOR_COEFF_MASK(0x3F << 0)
#define _CNL_PORT_TX_DW5_GRP_AE0x162354
#define _CNL_PORT_TX_DW5_GRP_B 0x1623D4
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/13] drm/fb-helper: Support deferred setup (fwd)
An unlock may be missing before line 2568.
julia
-- Forwarded message --
Date: Fri, 30 Jun 2017 01:26:56 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: Re: [Intel-gfx] [PATCH 10/13] drm/fb-helper: Support deferred setup
CC: kbuild-...@01.org
In-Reply-To: <20170627145936.18983-11-daniel.vet...@ffwll.ch>
TO: Daniel Vetter
CC: DRI Development
CC: Daniel Vetter , Intel Graphics Development
, Thierry Reding , John
Stultz , Liviu Dudau
Hi Daniel,
[auto build test WARNING on drm/drm-next]
[cannot apply to v4.12-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/fbdev-locking-rework-and-deferred-setup-take-2/20170629-075405
base: git://people.freedesktop.org/~airlied/linux.git drm-next
:: branch date: 18 hours ago
:: commit date: 18 hours ago
>> drivers/gpu/drm/drm_fb_helper.c:2568:2-8: preceding lock on line 2564
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 34aa55278652265fb627a38e182e60fc5afb7ee0
vim +2568 drivers/gpu/drm/drm_fb_helper.c
386516744 Dave Airlie2010-03-30 2558 {
719ad2ebd Thierry Reding 2017-06-27 2559 int err = 0;
5c4426a78 Dave Airlie2010-03-30 2560
f64c5573d Daniel Vetter 2015-08-25 2561 if (!drm_fbdev_emulation)
f64c5573d Daniel Vetter 2015-08-25 2562 return 0;
f64c5573d Daniel Vetter 2015-08-25 2563
719ad2ebd Thierry Reding 2017-06-27 @2564 mutex_lock(&fb_helper->lock);
34aa55278 Daniel Vetter 2017-06-27 2565 if (fb_helper->deferred_setup) {
34aa55278 Daniel Vetter 2017-06-27 2566 err =
__drm_fb_helper_initial_config(fb_helper,
34aa55278 Daniel Vetter 2017-06-27 2567
fb_helper->preferred_bpp);
34aa55278 Daniel Vetter 2017-06-27 @2568 return err;
34aa55278 Daniel Vetter 2017-06-27 2569 }
34aa55278 Daniel Vetter 2017-06-27 2570
50c3dc970 Daniel Vetter 2014-06-27 2571 if (!fb_helper->fb ||
!drm_fb_helper_is_bound(fb_helper)) {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] dma-buf/dma-fence: Extract __dma_fence_is_later()
Hi, 2017-06-29 Sean Paul : > On Thu, Jun 29, 2017 at 01:59:24PM +0100, Chris Wilson wrote: > > Often we have the task of comparing two seqno known to be on the same > > context, so provide a common __dma_fence_is_later(). > > > > Signed-off-by: Chris Wilson > > Cc: Sumit Semwal > > Cc: Sean Paul > > Hi Chris, > Thanks for writing the code and walking me through it. > > Whole set is > Reviewed-by: Sean Paul > > I'll leave Gustavo or Sumit to apply. Pushed all to drm-misc-next. Thanks! Gustavo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] intel: Add Cannonlake PCI IDs for Y-skus.
Reviewed-by: Clinton Taylor
-Clint
On 06/29/2017 02:34 PM, Rodrigo Vivi wrote:
By the Spec all CNL Y skus are 2+2, i.e. GT2.
This is a copy of merged i915's
commit 95578277cbdb ("drm/i915/cnl: Add Cannonlake PCI IDs for Y-skus.")
v2: Add kernel commit id for reference.
Cc: Anusha Srivatsa
Cc: Clinton Taylor
Signed-off-by: Rodrigo Vivi
---
intel/intel_chipset.h | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index e6b49d7..37579c6 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -237,6 +237,12 @@
#define PCI_CHIP_CANNONLAKE_U_GT2_1 0x5A5A
#define PCI_CHIP_CANNONLAKE_U_GT2_2 0x5A42
#define PCI_CHIP_CANNONLAKE_U_GT2_3 0x5A4A
+#define PCI_CHIP_CANNONLAKE_Y_GT2_00x5A51
+#define PCI_CHIP_CANNONLAKE_Y_GT2_10x5A59
+#define PCI_CHIP_CANNONLAKE_Y_GT2_20x5A41
+#define PCI_CHIP_CANNONLAKE_Y_GT2_30x5A49
+#define PCI_CHIP_CANNONLAKE_Y_GT2_40x5A71
+#define PCI_CHIP_CANNONLAKE_Y_GT2_50x5A79
#define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \
(devid) == PCI_CHIP_I915_GM || \
@@ -501,12 +507,20 @@
IS_GEN8(dev) || \
IS_GEN9(dev))
+#define IS_CNL_Y(devid) ((devid) == PCI_CHIP_CANNONLAKE_Y_GT2_0 || \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_1 || \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_2 || \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_3 || \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_4 || \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_5)
+
#define IS_CNL_U(devid) ((devid) == PCI_CHIP_CANNONLAKE_U_GT2_0
|| \
(devid) == PCI_CHIP_CANNONLAKE_U_GT2_1 || \
(devid) == PCI_CHIP_CANNONLAKE_U_GT2_2 || \
(devid) == PCI_CHIP_CANNONLAKE_U_GT2_3)
-#define IS_CANNONLAKE(devid) (IS_CNL_U(devid))
+#define IS_CANNONLAKE(devid) (IS_CNL_U(devid) || \
+IS_CNL_Y(devid))
#define IS_GEN10(devid) (IS_CANNONLAKE(devid))
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] intel: Add Cannonlake PCI IDs for U-skus.
Reviewed-by: Clinton Taylor
-Clint
On 06/29/2017 02:34 PM, Rodrigo Vivi wrote:
Platform enabling and its power-on are organized in different
skus (U x Y x S x H, etc). So instead of organizing it in
GT1 x GT2 x GT3 let's also use the platform sku.
This is a copy of merged i915's
commit e918d79a5d0a ("drm/i915/cnl: Add Cannonlake PCI IDs for U-skus.")
v2: Remove PCI IDs for SKU not mentioned in spec.
v3: Add kernel commit id for reference.
Cc: Anusha Srivatsa
Cc: Clinton Taylor
Signed-off-by: Rodrigo Vivi
---
intel/intel_chipset.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 891b50f..e6b49d7 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -233,6 +233,11 @@
#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7
#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8
+#define PCI_CHIP_CANNONLAKE_U_GT2_0 0x5A52
+#define PCI_CHIP_CANNONLAKE_U_GT2_10x5A5A
+#define PCI_CHIP_CANNONLAKE_U_GT2_20x5A42
+#define PCI_CHIP_CANNONLAKE_U_GT2_30x5A4A
+
#define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \
(devid) == PCI_CHIP_I915_GM || \
(devid) == PCI_CHIP_I945_GM || \
@@ -496,5 +501,13 @@
IS_GEN8(dev) || \
IS_GEN9(dev))
+#define IS_CNL_U(devid) ((devid) == PCI_CHIP_CANNONLAKE_U_GT2_0 || \
+(devid) == PCI_CHIP_CANNONLAKE_U_GT2_1 || \
+(devid) == PCI_CHIP_CANNONLAKE_U_GT2_2 || \
+(devid) == PCI_CHIP_CANNONLAKE_U_GT2_3)
+
+#define IS_CANNONLAKE(devid) (IS_CNL_U(devid))
+
+#define IS_GEN10(devid)(IS_CANNONLAKE(devid))
#endif /* _INTEL_CHIPSET_H */
___
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/7] dma-buf/dma-fence: Extract __dma_fence_is_later() (rev4)
== Series Details == Series: series starting with [1/7] dma-buf/dma-fence: Extract __dma_fence_is_later() (rev4) URL : https://patchwork.freedesktop.org/series/26551/ State : success == Summary == Series 26551v4 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/26551/revisions/4/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 +1 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:264 dwarn:4 dfail:0 fail:0 skip:11 time:444s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:427s 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:522s 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:486s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:481s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:593s fi-hsw-4770 total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:436s fi-hsw-4770r total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:409s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:416s 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:477s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:465s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:570s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:586s fi-pnv-d510 total:279 pass:221 dwarn:3 dfail:0 fail:0 skip:55 time:557s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:463s fi-skl-6700hqtotal:279 pass:223 dwarn:1 dfail:0 fail:30 skip:24 time:342s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:461s 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:432s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:542s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:404s 1da9a6d8d2402de8798b36d75bdd7d8b49728a5e drm-tip: 2017y-06m-29d-20h-16m-45s UTC integration manifest 3a3dede dma-buf/sw-sync: sync_pt is private and of fixed size 3475165b dma-buf/sw-sync: Reduce irqsave/irqrestore from known context 43e6ab0 dma-buf/sw-sync: Prevent user overflow on timeline advance a6dc7ca dma-buf/sw-sync: Fix the is-signaled test to handle u32 wraparound 8ba4a70 dma-buf/dma-fence: Extract __dma_fence_is_later() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5076/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 3/5] lib/cnl: Add Cannonlake PCI IDs for Y-skus.
Matches i915 support PCI device IDs
Reviewed-by: Clinton Taylor
-Clint
On 06/29/2017 02:18 PM, Rodrigo Vivi wrote:
By the Spec all CNL Y skus are 2+2, i.e. GT2.
This is a copy of merged i915's
commit 95578277cbdb ("drm/i915/cnl: Add Cannonlake PCI IDs for Y-skus.")
v2: Based on Anusha's kernel clean-up.
Cc: Anusha Srivatsa
Cc: Clinton Taylor
Signed-off-by: Rodrigo Vivi
---
lib/i915_pciids.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
index 8109e73..8a10a45 100644
--- a/lib/i915_pciids.h
+++ b/lib/i915_pciids.h
@@ -352,8 +352,17 @@
INTEL_VGA_DEVICE(0x5A42, info), \
INTEL_VGA_DEVICE(0x5A4A, info)
+#define INTEL_CNL_Y_GT2_IDS(info) \
+ INTEL_VGA_DEVICE(0x5A51, info), \
+ INTEL_VGA_DEVICE(0x5A59, info), \
+ INTEL_VGA_DEVICE(0x5A41, info), \
+ INTEL_VGA_DEVICE(0x5A49, info), \
+ INTEL_VGA_DEVICE(0x5A71, info), \
+ INTEL_VGA_DEVICE(0x5A79, info)
+
#define INTEL_CNL_IDS(info) \
- INTEL_CNL_U_GT2_IDS(info)
+ INTEL_CNL_U_GT2_IDS(info), \
+ INTEL_CNL_Y_GT2_IDS(info)
#define INTEL_CFL_U_IDS(info) \
INTEL_VGA_DEVICE(0x3EA5, info), /* ULT GT3 */ \
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/5] lib/cnl: Add Cannonlake PCI IDs for U-skus.
Reviewed-by: Clinton Taylor
-Clint
On 06/29/2017 02:18 PM, Rodrigo Vivi wrote:
Platform enabling and its power-on are organized in different
skus (U x Y x S x H, etc). So instead of organizing it in
GT1 x GT2 x GT3 let's also use the platform sku.
This is also the new Spec style what makes the review much
more easy and straightforward.
This is a copy of merged i915's
commit e918d79a5d0a ("drm/i915/cnl: Add Cannonlake PCI IDs for U-skus.")
v2: Based on Anusha's kernel clean-up.
v3: Add kernel commit id for reference.
Cc: Anusha Srivatsa
Cc: Clinton Taylor
Signed-off-by: Rodrigo Vivi
---
lib/i915_pciids.h | 9 +
lib/intel_device_info.c | 2 ++
2 files changed, 11 insertions(+)
diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
index 71cce60..8109e73 100644
--- a/lib/i915_pciids.h
+++ b/lib/i915_pciids.h
@@ -346,6 +346,15 @@
INTEL_VGA_DEVICE(0x3E9B, info), /* Halo GT2 */ \
INTEL_VGA_DEVICE(0x3E94, info) /* Halo GT2 */
+#define INTEL_CNL_U_GT2_IDS(info) \
+ INTEL_VGA_DEVICE(0x5A52, info), \
+ INTEL_VGA_DEVICE(0x5A5A, info), \
+ INTEL_VGA_DEVICE(0x5A42, info), \
+ INTEL_VGA_DEVICE(0x5A4A, info)
+
+#define INTEL_CNL_IDS(info) \
+ INTEL_CNL_U_GT2_IDS(info)
+
#define INTEL_CFL_U_IDS(info) \
INTEL_VGA_DEVICE(0x3EA5, info), /* ULT GT3 */ \
INTEL_VGA_DEVICE(0x3EA6, info), /* ULT GT3 */ \
diff --git a/lib/intel_device_info.c b/lib/intel_device_info.c
index dda5d11..8ea19f2 100644
--- a/lib/intel_device_info.c
+++ b/lib/intel_device_info.c
@@ -249,6 +249,8 @@ static const struct pci_id_match intel_device_match[] = {
INTEL_CFL_IDS(&intel_coffeelake_info),
+ INTEL_CNL_IDS(&intel_cannonlake_info),
+
INTEL_VGA_DEVICE(PCI_MATCH_ANY, &intel_generic_info),
};
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] intel/gen10: Add missed gen10 stuff
From: Ben Widawsky
This got lost on rebase, I believe
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 2 ++
intel/intel_decode.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 45a26da..71f140f 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3662,6 +3662,8 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
bufmgr_gem->gen = 8;
else if (IS_GEN9(bufmgr_gem->pci_device))
bufmgr_gem->gen = 9;
+ else if (IS_GEN10(bufmgr_gem->pci_device))
+ bufmgr_gem->gen = 10;
else {
free(bufmgr_gem);
bufmgr_gem = NULL;
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 2721ffd..3a81500 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -3827,7 +3827,9 @@ drm_intel_decode_context_alloc(uint32_t devid)
ctx->devid = devid;
ctx->out = stdout;
- if (IS_GEN9(devid))
+ if (IS_GEN10(devid))
+ ctx->gen = 10;
+ else if (IS_GEN9(devid))
ctx->gen = 9;
else if (IS_GEN8(devid))
ctx->gen = 8;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] intel: add GEN10 to IS_9XX.
From: Paulo Zanoni As far as I understand, IS_9XX should return true for it. Signed-off-by: Paulo Zanoni --- intel/intel_chipset.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index 37579c6..770d21f 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -505,7 +505,8 @@ IS_GEN6(dev) || \ IS_GEN7(dev) || \ IS_GEN8(dev) || \ -IS_GEN9(dev)) +IS_GEN9(dev) || \ +IS_GEN10(dev)) #define IS_CNL_Y(devid)((devid) == PCI_CHIP_CANNONLAKE_Y_GT2_0 || \ (devid) == PCI_CHIP_CANNONLAKE_Y_GT2_1 || \ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] intel: Add Cannonlake PCI IDs for U-skus.
Platform enabling and its power-on are organized in different
skus (U x Y x S x H, etc). So instead of organizing it in
GT1 x GT2 x GT3 let's also use the platform sku.
This is a copy of merged i915's
commit e918d79a5d0a ("drm/i915/cnl: Add Cannonlake PCI IDs for U-skus.")
v2: Remove PCI IDs for SKU not mentioned in spec.
v3: Add kernel commit id for reference.
Cc: Anusha Srivatsa
Cc: Clinton Taylor
Signed-off-by: Rodrigo Vivi
---
intel/intel_chipset.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 891b50f..e6b49d7 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -233,6 +233,11 @@
#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7
#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8
+#define PCI_CHIP_CANNONLAKE_U_GT2_00x5A52
+#define PCI_CHIP_CANNONLAKE_U_GT2_10x5A5A
+#define PCI_CHIP_CANNONLAKE_U_GT2_20x5A42
+#define PCI_CHIP_CANNONLAKE_U_GT2_30x5A4A
+
#define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \
(devid) == PCI_CHIP_I915_GM || \
(devid) == PCI_CHIP_I945_GM || \
@@ -496,5 +501,13 @@
IS_GEN8(dev) || \
IS_GEN9(dev))
+#define IS_CNL_U(devid)((devid) == PCI_CHIP_CANNONLAKE_U_GT2_0
|| \
+(devid) == PCI_CHIP_CANNONLAKE_U_GT2_1 || \
+(devid) == PCI_CHIP_CANNONLAKE_U_GT2_2 || \
+(devid) == PCI_CHIP_CANNONLAKE_U_GT2_3)
+
+#define IS_CANNONLAKE(devid) (IS_CNL_U(devid))
+
+#define IS_GEN10(devid)(IS_CANNONLAKE(devid))
#endif /* _INTEL_CHIPSET_H */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] intel: Add Cannonlake PCI IDs for Y-skus.
By the Spec all CNL Y skus are 2+2, i.e. GT2.
This is a copy of merged i915's
commit 95578277cbdb ("drm/i915/cnl: Add Cannonlake PCI IDs for Y-skus.")
v2: Add kernel commit id for reference.
Cc: Anusha Srivatsa
Cc: Clinton Taylor
Signed-off-by: Rodrigo Vivi
---
intel/intel_chipset.h | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index e6b49d7..37579c6 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -237,6 +237,12 @@
#define PCI_CHIP_CANNONLAKE_U_GT2_10x5A5A
#define PCI_CHIP_CANNONLAKE_U_GT2_20x5A42
#define PCI_CHIP_CANNONLAKE_U_GT2_30x5A4A
+#define PCI_CHIP_CANNONLAKE_Y_GT2_00x5A51
+#define PCI_CHIP_CANNONLAKE_Y_GT2_10x5A59
+#define PCI_CHIP_CANNONLAKE_Y_GT2_20x5A41
+#define PCI_CHIP_CANNONLAKE_Y_GT2_30x5A49
+#define PCI_CHIP_CANNONLAKE_Y_GT2_40x5A71
+#define PCI_CHIP_CANNONLAKE_Y_GT2_50x5A79
#define IS_MOBILE(devid) ((devid) == PCI_CHIP_I855_GM || \
(devid) == PCI_CHIP_I915_GM || \
@@ -501,12 +507,20 @@
IS_GEN8(dev) || \
IS_GEN9(dev))
+#define IS_CNL_Y(devid)((devid) == PCI_CHIP_CANNONLAKE_Y_GT2_0
|| \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_1 || \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_2 || \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_3 || \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_4 || \
+(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_5)
+
#define IS_CNL_U(devid)((devid) == PCI_CHIP_CANNONLAKE_U_GT2_0
|| \
(devid) == PCI_CHIP_CANNONLAKE_U_GT2_1 || \
(devid) == PCI_CHIP_CANNONLAKE_U_GT2_2 || \
(devid) == PCI_CHIP_CANNONLAKE_U_GT2_3)
-#define IS_CANNONLAKE(devid) (IS_CNL_U(devid))
+#define IS_CANNONLAKE(devid) (IS_CNL_U(devid) || \
+IS_CNL_Y(devid))
#define IS_GEN10(devid)(IS_CANNONLAKE(devid))
--
1.9.1
___
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/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts (rev2)
== Series Details == Series: drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts (rev2) URL : https://patchwork.freedesktop.org/series/26518/ State : success == Summary == Series 26518v2 drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts https://patchwork.freedesktop.org/api/1.0/series/26518/revisions/2/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 Test kms_busy: Subgroup basic-flip-default-a: dmesg-warn -> PASS (fi-skl-6700hq) fdo#101144 +3 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-skl-6700hq) fdo#101154 +24 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-6700hq) Subgroup basic-flip-vs-wf_vblank: skip -> PASS (fi-skl-6700hq) Subgroup basic-plain-flip: skip -> PASS (fi-skl-6700hq) Test kms_frontbuffer_tracking: Subgroup basic: skip -> PASS (fi-skl-6700hq) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: fail -> PASS (fi-skl-6700hq) fdo#100461 +1 Test kms_setmode: Subgroup basic-clone-single-crtc: warn -> PASS (fi-skl-6700hq) fdo#101518 Test kms_sink_crc_basic: fail -> PASS (fi-skl-6700hq) fdo#101519 Test pm_rpm: Subgroup basic-pci-d3-state: skip -> PASS (fi-skl-6700hq) Subgroup basic-rte: skip -> PASS (fi-skl-6700hq) fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144 fdo#101154 https://bugs.freedesktop.org/show_bug.cgi?id=101154 fdo#100461 https://bugs.freedesktop.org/show_bug.cgi?id=100461 fdo#101518 https://bugs.freedesktop.org/show_bug.cgi?id=101518 fdo#101519 https://bugs.freedesktop.org/show_bug.cgi?id=101519 fi-bdw-5557u total:279 pass:264 dwarn:4 dfail:0 fail:0 skip:11 time:441s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:426s 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:535s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:508s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:492s 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:591s fi-hsw-4770 total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:432s fi-hsw-4770r total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:418s 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:497s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:478s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:466s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:574s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:578s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:567s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:619s 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:477s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:439s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:554s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:403s 1da9a6d8d2402de8798b36d75bdd7d8b49728a5e drm-tip: 2017y-06m-29d-20h-16m-45s UTC integration manifest 9634753 drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5075/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/5] lib/cnl: Introduce Cannonlake platform defition.
Cannonlake is a Intel® Processor containing Intel® HD Graphics
following Kabylake.
It is Gen10.
Let's start by adding the platform definition based on previous
platforms.
On following patches we will start adding PCI IDs and the
platform specific changes.
Signed-off-by: Rodrigo Vivi
---
lib/intel_chipset.h | 3 +++
lib/intel_device_info.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
index 2468890..7fc9b3b 100644
--- a/lib/intel_chipset.h
+++ b/lib/intel_chipset.h
@@ -65,6 +65,7 @@ struct intel_device_info {
bool is_kabylake : 1;
bool is_geminilake : 1;
bool is_coffeelake : 1;
+ bool is_cannonlake : 1;
const char *codename;
};
@@ -160,6 +161,7 @@ void intel_check_pch(void);
#define IS_BROXTON(devid) (intel_get_device_info(devid)->is_broxton)
#define IS_GEMINILAKE(devid) (intel_get_device_info(devid)->is_geminilake)
#define IS_COFFEELAKE(devid) (intel_get_device_info(devid)->is_coffeelake)
+#define IS_CANNONLAKE(devid) (intel_get_device_info(devid)->is_cannonlake)
#define IS_GEN(devid, x) (intel_get_device_info(devid)->gen & (1u <<
((x)-1)))
#define AT_LEAST_GEN(devid, x) (intel_get_device_info(devid)->gen & -(1u <<
((x)-1)))
@@ -172,6 +174,7 @@ void intel_check_pch(void);
#define IS_GEN7(devid) IS_GEN(devid, 7)
#define IS_GEN8(devid) IS_GEN(devid, 8)
#define IS_GEN9(devid) IS_GEN(devid, 9)
+#define IS_GEN10(devid)IS_GEN(devid, 10)
#define IS_MOBILE(devid) (intel_get_device_info(devid)->is_mobile)
#define IS_965(devid) AT_LEAST_GEN(devid, 4)
diff --git a/lib/intel_device_info.c b/lib/intel_device_info.c
index 2c46aba..dda5d11 100644
--- a/lib/intel_device_info.c
+++ b/lib/intel_device_info.c
@@ -193,6 +193,12 @@ static const struct intel_device_info
intel_coffeelake_info = {
.codename = "coffeelake"
};
+static const struct intel_device_info intel_cannonlake_info = {
+ .gen = BIT(9),
+ .is_cannonlake = true,
+ .codename = "cannonlake"
+};
+
static const struct pci_id_match intel_device_match[] = {
INTEL_I810_IDS(&intel_i810_info),
INTEL_I815_IDS(&intel_i815_info),
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 5/5] lib/intel_batchbuffer: Add Gen10 support for render_copy and gpgpu_fillfunc.
None of the fields we use on render_copy and gpgpu_fill has changed when compared to gen9. So let's reuse them. Signed-off-by: Rodrigo Vivi --- lib/intel_batchbuffer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c index f135390..5344989 100644 --- a/lib/intel_batchbuffer.c +++ b/lib/intel_batchbuffer.c @@ -741,7 +741,7 @@ igt_render_copyfunc_t igt_get_render_copyfunc(int devid) copy = gen7_render_copyfunc; else if (IS_GEN8(devid)) copy = gen8_render_copyfunc; - else if (IS_GEN9(devid)) + else if (IS_GEN9(devid) || IS_GEN10(devid)) copy = gen9_render_copyfunc; return copy; @@ -789,7 +789,7 @@ igt_fillfunc_t igt_get_gpgpu_fillfunc(int devid) fill = gen7_gpgpu_fillfunc; else if (IS_BROADWELL(devid)) fill = gen8_gpgpu_fillfunc; - else if (IS_GEN9(devid)) + else if (IS_GEN9(devid) || IS_GEN10(devid)) fill = gen9_gpgpu_fillfunc; return fill; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/5] lib/instdone: Add Gen10 support.
Apparently nothing changed since BDW on these instdone bits.
So let's reuse instead of empty duplication.
Signed-off-by: Rodrigo Vivi
---
lib/instdone.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/lib/instdone.c b/lib/instdone.c
index 53d8215..510fce6 100644
--- a/lib/instdone.c
+++ b/lib/instdone.c
@@ -417,18 +417,10 @@ init_gen8_instdone(void)
init_gen75_instdone();
}
-static void
-init_gen9_instdone(void)
-{
- init_gen8_instdone();
-}
-
bool
init_instdone_definitions(uint32_t devid)
{
- if (IS_GEN9(devid)) {
- init_gen9_instdone();
- } else if (IS_GEN8(devid)) {
+ if (IS_GEN8(devid) || IS_GEN9(devid) || IS_GEN10(devid)) {
init_gen8_instdone();
} else if (IS_GEN7(devid)) {
init_gen7_instdone();
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/5] lib/cnl: Add Cannonlake PCI IDs for U-skus.
Platform enabling and its power-on are organized in different
skus (U x Y x S x H, etc). So instead of organizing it in
GT1 x GT2 x GT3 let's also use the platform sku.
This is also the new Spec style what makes the review much
more easy and straightforward.
This is a copy of merged i915's
commit e918d79a5d0a ("drm/i915/cnl: Add Cannonlake PCI IDs for U-skus.")
v2: Based on Anusha's kernel clean-up.
v3: Add kernel commit id for reference.
Cc: Anusha Srivatsa
Cc: Clinton Taylor
Signed-off-by: Rodrigo Vivi
---
lib/i915_pciids.h | 9 +
lib/intel_device_info.c | 2 ++
2 files changed, 11 insertions(+)
diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
index 71cce60..8109e73 100644
--- a/lib/i915_pciids.h
+++ b/lib/i915_pciids.h
@@ -346,6 +346,15 @@
INTEL_VGA_DEVICE(0x3E9B, info), /* Halo GT2 */ \
INTEL_VGA_DEVICE(0x3E94, info) /* Halo GT2 */
+#define INTEL_CNL_U_GT2_IDS(info) \
+ INTEL_VGA_DEVICE(0x5A52, info), \
+ INTEL_VGA_DEVICE(0x5A5A, info), \
+ INTEL_VGA_DEVICE(0x5A42, info), \
+ INTEL_VGA_DEVICE(0x5A4A, info)
+
+#define INTEL_CNL_IDS(info) \
+ INTEL_CNL_U_GT2_IDS(info)
+
#define INTEL_CFL_U_IDS(info) \
INTEL_VGA_DEVICE(0x3EA5, info), /* ULT GT3 */ \
INTEL_VGA_DEVICE(0x3EA6, info), /* ULT GT3 */ \
diff --git a/lib/intel_device_info.c b/lib/intel_device_info.c
index dda5d11..8ea19f2 100644
--- a/lib/intel_device_info.c
+++ b/lib/intel_device_info.c
@@ -249,6 +249,8 @@ static const struct pci_id_match intel_device_match[] = {
INTEL_CFL_IDS(&intel_coffeelake_info),
+ INTEL_CNL_IDS(&intel_cannonlake_info),
+
INTEL_VGA_DEVICE(PCI_MATCH_ANY, &intel_generic_info),
};
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/5] lib/cnl: Add Cannonlake PCI IDs for Y-skus.
By the Spec all CNL Y skus are 2+2, i.e. GT2.
This is a copy of merged i915's
commit 95578277cbdb ("drm/i915/cnl: Add Cannonlake PCI IDs for Y-skus.")
v2: Based on Anusha's kernel clean-up.
Cc: Anusha Srivatsa
Cc: Clinton Taylor
Signed-off-by: Rodrigo Vivi
---
lib/i915_pciids.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
index 8109e73..8a10a45 100644
--- a/lib/i915_pciids.h
+++ b/lib/i915_pciids.h
@@ -352,8 +352,17 @@
INTEL_VGA_DEVICE(0x5A42, info), \
INTEL_VGA_DEVICE(0x5A4A, info)
+#define INTEL_CNL_Y_GT2_IDS(info) \
+ INTEL_VGA_DEVICE(0x5A51, info), \
+ INTEL_VGA_DEVICE(0x5A59, info), \
+ INTEL_VGA_DEVICE(0x5A41, info), \
+ INTEL_VGA_DEVICE(0x5A49, info), \
+ INTEL_VGA_DEVICE(0x5A71, info), \
+ INTEL_VGA_DEVICE(0x5A79, info)
+
#define INTEL_CNL_IDS(info) \
- INTEL_CNL_U_GT2_IDS(info)
+ INTEL_CNL_U_GT2_IDS(info), \
+ INTEL_CNL_Y_GT2_IDS(info)
#define INTEL_CFL_U_IDS(info) \
INTEL_VGA_DEVICE(0x3EA5, info), /* ULT GT3 */ \
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] dma-buf/sw-sync: Use an rbtree to sort fences in the timeline
Reduce the list iteration when incrementing the timeline by storing the
fences in increasing order.
v2: Prevent spinlock recursion on free during create
v3: Fixup rebase conflict inside comments that escaped the compiler.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 49 ++--
drivers/dma-buf/sync_debug.h | 5 +
2 files changed, 48 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index f20d18c421a3..af1bc84802e5 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -96,6 +96,7 @@ static struct sync_timeline *sync_timeline_create(const char
*name)
obj->context = dma_fence_context_alloc(1);
strlcpy(obj->name, name, sizeof(obj->name));
+ obj->pt_tree = RB_ROOT;
INIT_LIST_HEAD(&obj->pt_list);
spin_lock_init(&obj->lock);
@@ -142,9 +143,13 @@ static void sync_timeline_signal(struct sync_timeline
*obj, unsigned int inc)
obj->value += inc;
- list_for_each_entry_safe(pt, next, &obj->pt_list, link)
- if (dma_fence_is_signaled_locked(&pt->base))
- list_del_init(&pt->link);
+ list_for_each_entry_safe(pt, next, &obj->pt_list, link) {
+ if (!dma_fence_is_signaled_locked(&pt->base))
+ break;
+
+ list_del_init(&pt->link);
+ rb_erase(&pt->node, &obj->pt_tree);
+ }
spin_unlock_irq(&obj->lock);
}
@@ -174,8 +179,38 @@ static struct sync_pt *sync_pt_create(struct sync_timeline
*obj,
INIT_LIST_HEAD(&pt->link);
spin_lock_irq(&obj->lock);
- if (!dma_fence_is_signaled_locked(&pt->base))
- list_add_tail(&pt->link, &obj->pt_list);
+ if (!dma_fence_is_signaled_locked(&pt->base)) {
+ struct rb_node **p = &obj->pt_tree.rb_node;
+ struct rb_node *parent = NULL;
+
+ while (*p) {
+ struct sync_pt *other;
+ int cmp;
+
+ parent = *p;
+ other = rb_entry(parent, typeof(*pt), node);
+ cmp = value - other->base.seqno;
+ if (cmp > 0) {
+ p = &parent->rb_right;
+ } else if (cmp < 0) {
+ p = &parent->rb_left;
+ } else {
+ if (dma_fence_get_rcu(&other->base)) {
+ dma_fence_put(&pt->base);
+ pt = other;
+ goto unlock;
+ }
+ p = &parent->rb_left;
+ }
+ }
+ rb_link_node(&pt->node, parent, p);
+ rb_insert_color(&pt->node, &obj->pt_tree);
+
+ parent = rb_next(&pt->node);
+ list_add_tail(&pt->link,
+ parent ? &rb_entry(parent, typeof(*pt),
node)->link : &obj->pt_list);
+ }
+unlock:
spin_unlock_irq(&obj->lock);
return pt;
@@ -202,8 +237,10 @@ static void timeline_fence_release(struct dma_fence *fence)
unsigned long flags;
spin_lock_irqsave(fence->lock, flags);
- if (!list_empty(&pt->link))
+ if (!list_empty(&pt->link)) {
list_del(&pt->link);
+ rb_erase(&pt->node, &parent->pt_tree);
+ }
spin_unlock_irqrestore(fence->lock, flags);
}
diff --git a/drivers/dma-buf/sync_debug.h b/drivers/dma-buf/sync_debug.h
index 6a2a8e69a7d0..d615a89f774c 100644
--- a/drivers/dma-buf/sync_debug.h
+++ b/drivers/dma-buf/sync_debug.h
@@ -14,6 +14,7 @@
#define _LINUX_SYNC_H
#include
+#include
#include
#include
@@ -25,6 +26,7 @@
* @kref: reference count on fence.
* @name: name of the sync_timeline. Useful for debugging
* @lock: lock protecting @pt_list and @value
+ * @pt_tree: rbtree of active (unsignaled/errored) sync_pts
* @pt_list: list of active (unsignaled/errored) sync_pts
* @sync_timeline_list:membership in global sync_timeline_list
*/
@@ -36,6 +38,7 @@ struct sync_timeline {
u64 context;
int value;
+ struct rb_root pt_tree;
struct list_headpt_list;
spinlock_t lock;
@@ -51,10 +54,12 @@ static inline struct sync_timeline *dma_fence_parent(struct
dma_fence *fence)
* struct sync_pt - sync_pt object
* @base: base fence object
* @link: link on the sync timeline's list
+ * @node: node in the sync timeline's tree
*/
struct sync_pt {
struct dma_fence base;
struct list_head link;
+
[Intel-gfx] [PATCH v2] dma-buf/sw-sync: Use an rbtree to sort fences in the timeline
Reduce the list iteration when incrementing the timeline by storing the
fences in increasing order.
v2: Prevent spinlock recursion on free during create
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 49 ++--
drivers/dma-buf/sync_debug.h | 9
2 files changed, 52 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index f20d18c421a3..af1bc84802e5 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -96,6 +96,7 @@ static struct sync_timeline *sync_timeline_create(const char
*name)
obj->context = dma_fence_context_alloc(1);
strlcpy(obj->name, name, sizeof(obj->name));
+ obj->pt_tree = RB_ROOT;
INIT_LIST_HEAD(&obj->pt_list);
spin_lock_init(&obj->lock);
@@ -142,9 +143,13 @@ static void sync_timeline_signal(struct sync_timeline
*obj, unsigned int inc)
obj->value += inc;
- list_for_each_entry_safe(pt, next, &obj->pt_list, link)
- if (dma_fence_is_signaled_locked(&pt->base))
- list_del_init(&pt->link);
+ list_for_each_entry_safe(pt, next, &obj->pt_list, link) {
+ if (!dma_fence_is_signaled_locked(&pt->base))
+ break;
+
+ list_del_init(&pt->link);
+ rb_erase(&pt->node, &obj->pt_tree);
+ }
spin_unlock_irq(&obj->lock);
}
@@ -174,8 +179,38 @@ static struct sync_pt *sync_pt_create(struct sync_timeline
*obj,
INIT_LIST_HEAD(&pt->link);
spin_lock_irq(&obj->lock);
- if (!dma_fence_is_signaled_locked(&pt->base))
- list_add_tail(&pt->link, &obj->pt_list);
+ if (!dma_fence_is_signaled_locked(&pt->base)) {
+ struct rb_node **p = &obj->pt_tree.rb_node;
+ struct rb_node *parent = NULL;
+
+ while (*p) {
+ struct sync_pt *other;
+ int cmp;
+
+ parent = *p;
+ other = rb_entry(parent, typeof(*pt), node);
+ cmp = value - other->base.seqno;
+ if (cmp > 0) {
+ p = &parent->rb_right;
+ } else if (cmp < 0) {
+ p = &parent->rb_left;
+ } else {
+ if (dma_fence_get_rcu(&other->base)) {
+ dma_fence_put(&pt->base);
+ pt = other;
+ goto unlock;
+ }
+ p = &parent->rb_left;
+ }
+ }
+ rb_link_node(&pt->node, parent, p);
+ rb_insert_color(&pt->node, &obj->pt_tree);
+
+ parent = rb_next(&pt->node);
+ list_add_tail(&pt->link,
+ parent ? &rb_entry(parent, typeof(*pt),
node)->link : &obj->pt_list);
+ }
+unlock:
spin_unlock_irq(&obj->lock);
return pt;
@@ -202,8 +237,10 @@ static void timeline_fence_release(struct dma_fence *fence)
unsigned long flags;
spin_lock_irqsave(fence->lock, flags);
- if (!list_empty(&pt->link))
+ if (!list_empty(&pt->link)) {
list_del(&pt->link);
+ rb_erase(&pt->node, &parent->pt_tree);
+ }
spin_unlock_irqrestore(fence->lock, flags);
}
diff --git a/drivers/dma-buf/sync_debug.h b/drivers/dma-buf/sync_debug.h
index 6a2a8e69a7d0..363c0a717b77 100644
--- a/drivers/dma-buf/sync_debug.h
+++ b/drivers/dma-buf/sync_debug.h
@@ -14,6 +14,7 @@
#define _LINUX_SYNC_H
#include
+#include
#include
#include
@@ -24,7 +25,12 @@
* struct sync_timeline - sync object
* @kref: reference count on fence.
* @name: name of the sync_timeline. Useful for debugging
+<<< HEAD
* @lock: lock protecting @pt_list and @value
+===
+ * @lock: lock protecting @child_list_head and fence.status
+ * @pt_tree: rbtree of active (unsignaled/errored) sync_pts
+>>> 0f78df23b9ec... dma-buf/sw-sync: Use an rbtree to sort fences in the
timeline
* @pt_list: list of active (unsignaled/errored) sync_pts
* @sync_timeline_list:membership in global sync_timeline_list
*/
@@ -36,6 +42,7 @@ struct sync_timeline {
u64 context;
int value;
+ struct rb_root pt_tree;
struct list_headpt_list;
spinlock_t lock;
@@ -51,10 +58,12 @@ static inline struct sync_timeline *dma_fence_parent(struct
dma_fence *fence)
* struct sync_pt - sync_pt object
* @base: base fence object
* @link: link on the
[Intel-gfx] [PATCH v2] dma-buf/sw-sync: Fix locking around sync_timeline lists
The sync_pt were not adding themselves atomically to the timeline lists,
corruption imminent. Only a single list is required to track the
unsignaled sync_pt, so reduce it and rename the lock more appropriately
along with using idiomatic names to distinguish a list from links along
it.
v2: Prevent spinlock recursion on free during create (next patch) and
fixup crossref in kerneldoc
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Sean Paul
Cc: Gustavo Padovan
---
drivers/dma-buf/sw_sync.c| 48 ++--
drivers/dma-buf/sync_debug.c | 9 -
drivers/dma-buf/sync_debug.h | 21 ---
3 files changed, 31 insertions(+), 47 deletions(-)
diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 6effa1ce010e..f20d18c421a3 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -96,9 +96,8 @@ static struct sync_timeline *sync_timeline_create(const char
*name)
obj->context = dma_fence_context_alloc(1);
strlcpy(obj->name, name, sizeof(obj->name));
- INIT_LIST_HEAD(&obj->child_list_head);
- INIT_LIST_HEAD(&obj->active_list_head);
- spin_lock_init(&obj->child_list_lock);
+ INIT_LIST_HEAD(&obj->pt_list);
+ spin_lock_init(&obj->lock);
sync_timeline_debug_add(obj);
@@ -139,17 +138,15 @@ static void sync_timeline_signal(struct sync_timeline
*obj, unsigned int inc)
trace_sync_timeline(obj);
- spin_lock_irq(&obj->child_list_lock);
+ spin_lock_irq(&obj->lock);
obj->value += inc;
- list_for_each_entry_safe(pt, next, &obj->active_list_head,
-active_list) {
+ list_for_each_entry_safe(pt, next, &obj->pt_list, link)
if (dma_fence_is_signaled_locked(&pt->base))
- list_del_init(&pt->active_list);
- }
+ list_del_init(&pt->link);
- spin_unlock_irq(&obj->child_list_lock);
+ spin_unlock_irq(&obj->lock);
}
/**
@@ -171,15 +168,15 @@ static struct sync_pt *sync_pt_create(struct
sync_timeline *obj,
if (!pt)
return NULL;
- spin_lock_irq(&obj->child_list_lock);
-
sync_timeline_get(obj);
- dma_fence_init(&pt->base, &timeline_fence_ops, &obj->child_list_lock,
+ dma_fence_init(&pt->base, &timeline_fence_ops, &obj->lock,
obj->context, value);
- list_add_tail(&pt->child_list, &obj->child_list_head);
- INIT_LIST_HEAD(&pt->active_list);
+ INIT_LIST_HEAD(&pt->link);
- spin_unlock_irq(&obj->child_list_lock);
+ spin_lock_irq(&obj->lock);
+ if (!dma_fence_is_signaled_locked(&pt->base))
+ list_add_tail(&pt->link, &obj->pt_list);
+ spin_unlock_irq(&obj->lock);
return pt;
}
@@ -200,15 +197,15 @@ static void timeline_fence_release(struct dma_fence
*fence)
{
struct sync_pt *pt = dma_fence_to_sync_pt(fence);
struct sync_timeline *parent = dma_fence_parent(fence);
- unsigned long flags;
- spin_lock_irqsave(fence->lock, flags);
+ if (!list_empty(&pt->link)) {
+ unsigned long flags;
- list_del(&pt->child_list);
- if (!list_empty(&pt->active_list))
- list_del(&pt->active_list);
-
- spin_unlock_irqrestore(fence->lock, flags);
+ spin_lock_irqsave(fence->lock, flags);
+ if (!list_empty(&pt->link))
+ list_del(&pt->link);
+ spin_unlock_irqrestore(fence->lock, flags);
+ }
sync_timeline_put(parent);
dma_fence_free(fence);
@@ -223,13 +220,6 @@ static bool timeline_fence_signaled(struct dma_fence
*fence)
static bool timeline_fence_enable_signaling(struct dma_fence *fence)
{
- struct sync_pt *pt = dma_fence_to_sync_pt(fence);
- struct sync_timeline *parent = dma_fence_parent(fence);
-
- if (timeline_fence_signaled(fence))
- return false;
-
- list_add_tail(&pt->active_list, &parent->active_list_head);
return true;
}
diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index 0e91632248ba..2264a075f6a9 100644
--- a/drivers/dma-buf/sync_debug.c
+++ b/drivers/dma-buf/sync_debug.c
@@ -119,13 +119,12 @@ static void sync_print_obj(struct seq_file *s, struct
sync_timeline *obj)
seq_printf(s, "%s: %d\n", obj->name, obj->value);
- spin_lock_irq(&obj->child_list_lock);
- list_for_each(pos, &obj->child_list_head) {
- struct sync_pt *pt =
- container_of(pos, struct sync_pt, child_list);
+ spin_lock_irq(&obj->lock);
+ list_for_each(pos, &obj->pt_list) {
+ struct sync_pt *pt = container_of(pos, struct sync_pt, link);
sync_print_fence(s, &pt->base, false);
}
- spin_unlock_irq(&obj->child_list_lock);
+ spin_unlock_irq(&obj->lock);
}
static void sync_print_sync
[Intel-gfx] [PATCH v3] drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts
This patch fixes the DP AUX CH timeouts observed during CI IGT
tests thus fixing the CI failures. This is done by adding a
quirk for a particular PCI device that requires the panel power
cycle delay (T12) to be set to 800ms which is 300msecs more than
the minimum value specified in the eDP spec. So a quirk is
implemented for that specific PCI device.
v3:
* Change some comments, specify the delay as 800 * 10 (Ville)
v2:
* Change the function and variable names to from PPS_T12_
to _T12 since it is a T12 delay (Clint)
Fixes: FDO #101144 #101515 #101154 #101167
Cc: Ville Syrjala
Cc: Clinton Taylor
Signed-off-by: Manasi Navare
Reviewed-by: Clinton Taylor
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 14 ++
drivers/gpu/drm/i915/intel_dp.c | 11 +++
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 427d10c..4327c8a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1168,6 +1168,7 @@ enum intel_sbi_destination {
#define QUIRK_INVERT_BRIGHTNESS (1<<2)
#define QUIRK_BACKLIGHT_PRESENT (1<<3)
#define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
+#define QUIRK_INCREASE_T12_DELAY (1<<6)
struct intel_fbdev;
struct intel_fbc_work;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4e03ca6..87dfde9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14765,6 +14765,17 @@ static void quirk_backlight_present(struct drm_device
*dev)
DRM_INFO("applying backlight present quirk\n");
}
+/* Toshiba Satellite P50-C-18C requires T12 delay to be min 800ms
+ * which is 300 ms greater than eDP spec T12 min.
+ */
+static void quirk_increase_t12_delay(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ dev_priv->quirks |= QUIRK_INCREASE_T12_DELAY;
+ DRM_INFO("Applying T12 delay quirk\n");
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -14848,6 +14859,9 @@ static struct intel_quirk intel_quirks[] = {
/* Dell Chromebook 11 (2015 version) */
{ 0x0a16, 0x1028, 0x0a35, quirk_backlight_present },
+
+ /* Toshiba Satellite P50-C-18C */
+ { 0x191B, 0x1179, 0xF840, quirk_increase_t12_delay },
};
static void intel_init_quirks(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 67bc8a7a..4d7e510 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5230,6 +5230,17 @@ intel_dp_init_panel_power_sequencer(struct drm_device
*dev,
intel_pps_dump_state("cur", &cur);
vbt = dev_priv->vbt.edp.pps;
+ /* On Toshiba Satellite P50-C-18C system the VBT T12 delay
+* of 500ms appears to be too short. Ocassionally the panel
+* just fails to power back on. Increasing the delay to 800ms
+* seems sufficient to avpid this problem.
+*/
+ if (dev_priv->quirks & QUIRK_INCREASE_T12_DELAY) {
+
+ vbt.t11_t12 = max_t(u16, vbt.t11_t12, 800 * 10);
+ DRM_DEBUG_KMS("Increasing T12 panel delay as per the quirk to
%d\n",
+ vbt.t11_t12);
+ }
/* T11_T12 delay is special and actually in units of 100ms, but zero
* based in the hw (so we need to add 100 ms). But the sw vbt
* table multiplies it with 1000 to make it in units of 100usec,
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts
Thanks for the review comments. Please find my responses below:
On Thu, Jun 29, 2017 at 11:24:48PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 28, 2017 at 05:14:31PM -0700, Manasi Navare wrote:
> > This patch fixes the DP AUX CH timeouts observed during CI IGT
> > tests thus fixing the CI failures. This is done by adding a
> > quirk for a particular PCI device that requires the panel power
> > cycle delay (T12) to be 300msecs more than the minimum value
> > specified in the eDP spec. So a quirk is implemented for that
> > specific PCI device.
> >
> > v2:
> > * Change the function and variable names to from PPS_T12_
> > to _T12 since it is a T12 delay (Clint)
> >
> > Fixes: FDO #101144 #101515 #101154 #101167
> > Cc: Ville Syrjala
> > Cc: Cinton Taylor
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_display.c | 12
> > drivers/gpu/drm/i915/intel_dp.c | 12
> > 3 files changed, 25 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 427d10c..4327c8a 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1168,6 +1168,7 @@ enum intel_sbi_destination {
> > #define QUIRK_INVERT_BRIGHTNESS (1<<2)
> > #define QUIRK_BACKLIGHT_PRESENT (1<<3)
> > #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > +#define QUIRK_INCREASE_T12_DELAY (1<<6)
> >
> > struct intel_fbdev;
> > struct intel_fbc_work;
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 4e03ca6..37beb62 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14765,6 +14765,15 @@ static void quirk_backlight_present(struct
> > drm_device *dev)
> > DRM_INFO("applying backlight present quirk\n");
> > }
> >
> > +/* Some systems require 300ms extra PPS T12 delay to be added to VBT value
> > */
>
> The comment disagrees with the code. Code uses 800ms explicitly instead of
> +300 ms.
>
Agree, I will change it to 800ms in the comment.
> > +static void quirk_increase_t12_delay(struct drm_device *dev)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(dev);
> > +
> > + dev_priv->quirks |= QUIRK_INCREASE_T12_DELAY;
> > + DRM_INFO("Applying T12 delay quirk\n");
> > +}
> > +
> > struct intel_quirk {
> > int device;
> > int subsystem_vendor;
> > @@ -14848,6 +14857,9 @@ static struct intel_quirk intel_quirks[] = {
> >
> > /* Dell Chromebook 11 (2015 version) */
> > { 0x0a16, 0x1028, 0x0a35, quirk_backlight_present },
> > +
> > + /* Toshiba Satellite P50-C-18C */
> > + { 0x191B, 0x1179, 0xF840, quirk_increase_t12_delay },
>
> Hmm. Looks like the 1179:f840 combo is present on a lot of Toshiba
> models. But we do have the device ID here too so the quirk shouldn't
> go totally overboard.
>
Yea this quirk should then get applied only to this device.
Do you have any other Toshiba laptop with 1179:f840 combo
to make sure it doesnt get applied on that?
> > };
> >
> > static void intel_init_quirks(struct drm_device *dev)
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 67bc8a7a..db6953e 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -49,6 +49,9 @@
> > #define INTEL_DP_RESOLUTION_STANDARD (2 <<
> > INTEL_DP_RESOLUTION_SHIFT_MASK)
> > #define INTEL_DP_RESOLUTION_FAILSAFE (3 <<
> > INTEL_DP_RESOLUTION_SHIFT_MASK)
> >
> > +/* PPS T12 Delay Quirk value for eDP */
> > +#define T11_T12_800MS 8000
>
> The define seems pointless. Just use the raw number in the code. Also
> writing it as 800*10 would be more consistent with the rest of the code.
>
Sounds good, will use 800*10
> > +
> > struct dp_link_dpll {
> > int clock;
> > struct dpll dpll;
> > @@ -5230,6 +5233,15 @@ intel_dp_init_panel_power_sequencer(struct
> > drm_device *dev,
> > intel_pps_dump_state("cur", &cur);
> >
> > vbt = dev_priv->vbt.edp.pps;
> > + /* Apply the QUIRK_INCREASE_T12_DELAY quirk for a specific
> > +* type of PCI device to avoid DP AUX CH Timeouts.
>
> That comment doesn't seem very helpful. I would put in something like:
>
> "On Toshiba the VBT t12 delay of 500ms appears to be too
> short. Occasionally the panel just fails to power back on. Increasing
> the delay to 800ms seems sufficient to avoid the problem."
>
Ok will do
Manasi
> > +*/
> > + if (dev_priv->quirks & QUIRK_INCREASE_T12_DELAY) {
> > +
> > + vbt.t11_t12 = max_t(u16, vbt.t11_t12, T11_T12_800MS);
> > + DRM_DEBUG_KMS("Increasing T12 panel delay as per the quirk to
> > %d\n",
> > + vbt.t11_t12);
> > + }
> > /* T11_T12 delay is special and actually in units of 100ms, but zero
> > * based in the hw (so we need to add 100 ms). But the sw vbt
> > * tab
[Intel-gfx] [PATCH] dri2: Sync i965_pci_ids.h from Mesa.
Copied from Mesa with no modifications. Gives us Coffee Lake and Cannon Lake PCI IDs. Cc: Kenneth Graunke Cc: Eric Anholt Signed-off-by: Rodrigo Vivi --- hw/xfree86/dri2/pci_ids/i965_pci_ids.h | 23 +++ 1 file changed, 23 insertions(+) diff --git a/hw/xfree86/dri2/pci_ids/i965_pci_ids.h b/hw/xfree86/dri2/pci_ids/i965_pci_ids.h index 17504f5..57e70b7 100644 --- a/hw/xfree86/dri2/pci_ids/i965_pci_ids.h +++ b/hw/xfree86/dri2/pci_ids/i965_pci_ids.h @@ -165,3 +165,26 @@ CHIPSET(0x5927, kbl_gt3, "Intel(R) Iris Plus Graphics 650 (Kaby Lake GT3)") CHIPSET(0x593B, kbl_gt4, "Intel(R) Kabylake GT4") CHIPSET(0x3184, glk, "Intel(R) HD Graphics (Geminilake)") CHIPSET(0x3185, glk_2x6, "Intel(R) HD Graphics (Geminilake 2x6)") +CHIPSET(0x3E90, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)") +CHIPSET(0x3E93, cfl_gt1, "Intel(R) HD Graphics (Coffeelake 2x6 GT1)") +CHIPSET(0x3E91, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)") +CHIPSET(0x3E92, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)") +CHIPSET(0x3E96, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)") +CHIPSET(0x3E9B, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)") +CHIPSET(0x3E94, cfl_gt2, "Intel(R) HD Graphics (Coffeelake 3x8 GT2)") +CHIPSET(0x3EA6, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)") +CHIPSET(0x3EA7, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)") +CHIPSET(0x3EA8, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)") +CHIPSET(0x3EA5, cfl_gt3, "Intel(R) HD Graphics (Coffeelake 3x8 GT3)") +CHIPSET(0x5A49, cnl_2x8, "Intel(R) HD Graphics (Cannonlake 2x8 GT0.5)") +CHIPSET(0x5A4A, cnl_2x8, "Intel(R) HD Graphics (Cannonlake 2x8 GT0.5)") +CHIPSET(0x5A41, cnl_3x8, "Intel(R) HD Graphics (Cannonlake 3x8 GT1)") +CHIPSET(0x5A42, cnl_3x8, "Intel(R) HD Graphics (Cannonlake 3x8 GT1)") +CHIPSET(0x5A44, cnl_3x8, "Intel(R) HD Graphics (Cannonlake 3x8 GT1)") +CHIPSET(0x5A59, cnl_4x8, "Intel(R) HD Graphics (Cannonlake 4x8 GT1.5)") +CHIPSET(0x5A5A, cnl_4x8, "Intel(R) HD Graphics (Cannonlake 4x8 GT1.5)") +CHIPSET(0x5A5C, cnl_4x8, "Intel(R) HD Graphics (Cannonlake 4x8 GT1.5)") +CHIPSET(0x5A50, cnl_5x8, "Intel(R) HD Graphics (Cannonlake 5x8 GT2)") +CHIPSET(0x5A51, cnl_5x8, "Intel(R) HD Graphics (Cannonlake 5x8 GT2)") +CHIPSET(0x5A52, cnl_5x8, "Intel(R) HD Graphics (Cannonlake 5x8 GT2)") +CHIPSET(0x5A54, cnl_5x8, "Intel(R) HD Graphics (Cannonlake 5x8 GT2)") -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts
On Wed, Jun 28, 2017 at 05:14:31PM -0700, Manasi Navare wrote:
> This patch fixes the DP AUX CH timeouts observed during CI IGT
> tests thus fixing the CI failures. This is done by adding a
> quirk for a particular PCI device that requires the panel power
> cycle delay (T12) to be 300msecs more than the minimum value
> specified in the eDP spec. So a quirk is implemented for that
> specific PCI device.
>
> v2:
> * Change the function and variable names to from PPS_T12_
> to _T12 since it is a T12 delay (Clint)
>
> Fixes: FDO #101144 #101515 #101154 #101167
> Cc: Ville Syrjala
> Cc: Cinton Taylor
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_display.c | 12
> drivers/gpu/drm/i915/intel_dp.c | 12
> 3 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 427d10c..4327c8a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1168,6 +1168,7 @@ enum intel_sbi_destination {
> #define QUIRK_INVERT_BRIGHTNESS (1<<2)
> #define QUIRK_BACKLIGHT_PRESENT (1<<3)
> #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> +#define QUIRK_INCREASE_T12_DELAY (1<<6)
>
> struct intel_fbdev;
> struct intel_fbc_work;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 4e03ca6..37beb62 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14765,6 +14765,15 @@ static void quirk_backlight_present(struct
> drm_device *dev)
> DRM_INFO("applying backlight present quirk\n");
> }
>
> +/* Some systems require 300ms extra PPS T12 delay to be added to VBT value */
The comment disagrees with the code. Code uses 800ms explicitly instead of
+300 ms.
> +static void quirk_increase_t12_delay(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + dev_priv->quirks |= QUIRK_INCREASE_T12_DELAY;
> + DRM_INFO("Applying T12 delay quirk\n");
> +}
> +
> struct intel_quirk {
> int device;
> int subsystem_vendor;
> @@ -14848,6 +14857,9 @@ static struct intel_quirk intel_quirks[] = {
>
> /* Dell Chromebook 11 (2015 version) */
> { 0x0a16, 0x1028, 0x0a35, quirk_backlight_present },
> +
> + /* Toshiba Satellite P50-C-18C */
> + { 0x191B, 0x1179, 0xF840, quirk_increase_t12_delay },
Hmm. Looks like the 1179:f840 combo is present on a lot of Toshiba
models. But we do have the device ID here too so the quirk shouldn't
go totally overboard.
> };
>
> static void intel_init_quirks(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 67bc8a7a..db6953e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -49,6 +49,9 @@
> #define INTEL_DP_RESOLUTION_STANDARD (2 << INTEL_DP_RESOLUTION_SHIFT_MASK)
> #define INTEL_DP_RESOLUTION_FAILSAFE (3 << INTEL_DP_RESOLUTION_SHIFT_MASK)
>
> +/* PPS T12 Delay Quirk value for eDP */
> +#define T11_T12_800MS8000
The define seems pointless. Just use the raw number in the code. Also
writing it as 800*10 would be more consistent with the rest of the code.
> +
> struct dp_link_dpll {
> int clock;
> struct dpll dpll;
> @@ -5230,6 +5233,15 @@ intel_dp_init_panel_power_sequencer(struct drm_device
> *dev,
> intel_pps_dump_state("cur", &cur);
>
> vbt = dev_priv->vbt.edp.pps;
> + /* Apply the QUIRK_INCREASE_T12_DELAY quirk for a specific
> + * type of PCI device to avoid DP AUX CH Timeouts.
That comment doesn't seem very helpful. I would put in something like:
"On Toshiba the VBT t12 delay of 500ms appears to be too
short. Occasionally the panel just fails to power back on. Increasing
the delay to 800ms seems sufficient to avoid the problem."
> + */
> + if (dev_priv->quirks & QUIRK_INCREASE_T12_DELAY) {
> +
> + vbt.t11_t12 = max_t(u16, vbt.t11_t12, T11_T12_800MS);
> + DRM_DEBUG_KMS("Increasing T12 panel delay as per the quirk to
> %d\n",
> + vbt.t11_t12);
> + }
> /* T11_T12 delay is special and actually in units of 100ms, but zero
>* based in the hw (so we need to add 100 ms). But the sw vbt
>* table multiplies it with 1000 to make it in units of 100usec,
> --
> 2.1.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 1/7] dma-buf/dma-fence: Extract __dma_fence_is_later()
On Thu, Jun 29, 2017 at 01:59:24PM +0100, Chris Wilson wrote:
> Often we have the task of comparing two seqno known to be on the same
> context, so provide a common __dma_fence_is_later().
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Sean Paul
Hi Chris,
Thanks for writing the code and walking me through it.
Whole set is
Reviewed-by: Sean Paul
I'll leave Gustavo or Sumit to apply.
Sean
> Cc: Gustavo Padovan
> ---
> include/linux/dma-fence.h | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index a5195a7d6f77..ac5987989e9a 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -336,6 +336,19 @@ dma_fence_is_signaled(struct dma_fence *fence)
> }
>
> /**
> + * __dma_fence_is_later - return if f1 is chronologically later than f2
> + * @f1: [in]the first fence's seqno
> + * @f2: [in]the second fence's seqno from the same context
> + *
> + * Returns true if f1 is chronologically later than f2. Both fences must be
> + * from the same context, since a seqno is not common across contexts.
> + */
> +static inline bool __dma_fence_is_later(u32 f1, u32 f2)
> +{
> + return (int)(f1 - f2) > 0;
> +}
> +
> +/**
> * dma_fence_is_later - return if f1 is chronologically later than f2
> * @f1: [in]the first fence from the same context
> * @f2: [in]the second fence from the same context
> @@ -349,7 +362,7 @@ static inline bool dma_fence_is_later(struct dma_fence
> *f1,
> if (WARN_ON(f1->context != f2->context))
> return false;
>
> - return (int)(f1->seqno - f2->seqno) > 0;
> + return __dma_fence_is_later(f1->seqno, f2->seqno);
> }
>
> /**
> --
> 2.13.1
--
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/cfl: Fix Workarounds.
patch merged to dinq.
thanks a lot for the review and sorry for causing trouble with the
version of that previous patch.
On Thu, Jun 29, 2017 at 1:02 PM, Pandiyan, Dhinakaran
wrote:
> I went and read Mika's review in [1] and also the patches posted and
> committed after that. The version currently in drm-tip deviates from his
> review and the fix here addresses Mika's comments correctly.
>
> Verified that BSpec does indeed say
> WaDisableKillLogic is applicable to only SKL and BXT.
>
>
> As for WaDisableHDCInvalidation, git blame indicates this is intended to
> be retained for all gen9 platforms.
>
> So this patch lgtm.
>
> Reviewed-by: Dhinakaran Pandiyan
>
> [1]
> https://lists.freedesktop.org/archives/intel-gfx/2017-June/130100.html
>
>
>
> -DK
>
> On Mon, 2017-06-19 at 14:21 -0700, Rodrigo Vivi wrote:
>> During the review of Coffee Lake workarounds Mika pointed out
>> that WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC
>> should be removed from CFL and with that I should carry the rv-b.
>>
>> However when doing the v2 I removed another Workaround that should
>> remain because although not mentioned by spec the history of hangs
>> around it advocates on its favor.
>>
>> On some follow-up patches I continued operating on the wrong
>> workardound, but Ville noticed that, so here is the fix for the
>> current CFL code that is upstream already.
>>
>> Fixes: 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake workarounds.")
>> Cc: Ville Syrjälä
>> Cc: Dhinakaran Pandiyan
>> Cc: Mika Kuoppala
>> Signed-off-by: Rodrigo Vivi
>> ---
>> drivers/gpu/drm/i915/intel_engine_cs.c | 14 +++---
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
>> b/drivers/gpu/drm/i915/intel_engine_cs.c
>> index a4487c5..5b4de71 100644
>> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
>> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
>> @@ -821,9 +821,10 @@ static int gen9_init_workarounds(struct intel_engine_cs
>> *engine)
>> I915_WRITE(BDW_SCRATCH1, I915_READ(BDW_SCRATCH1) |
>> GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE);
>>
>> - /* WaDisableKillLogic:bxt,skl,kbl,cfl */
>> - I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
>> -ECOCHK_DIS_TLB);
>> + /* WaDisableKillLogic:bxt,skl,kbl */
>> + if (!IS_COFFEELAKE(dev_priv))
>> + I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
>> +ECOCHK_DIS_TLB);
>>
>> /* WaClearFlowControlGpgpuContextSave:skl,bxt,kbl,glk,cfl */
>> /* WaDisablePartialInstShootdown:skl,bxt,kbl,glk,cfl */
>> @@ -894,10 +895,9 @@ static int gen9_init_workarounds(struct intel_engine_cs
>> *engine)
>> WA_SET_BIT_MASKED(HDC_CHICKEN0,
>> HDC_FORCE_NON_COHERENT);
>>
>> - /* WaDisableHDCInvalidation:skl,bxt,kbl */
>> - if (!IS_COFFEELAKE(dev_priv))
>> - I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
>> -BDW_DISABLE_HDC_INVALIDATION);
>> + /* WaDisableHDCInvalidation:skl,bxt,kbl,cfl */
>> + I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
>> +BDW_DISABLE_HDC_INVALIDATION);
>>
>> /* WaDisableSamplerPowerBypassForSOPingPong:skl,bxt,kbl,cfl */
>> if (IS_SKYLAKE(dev_priv) ||
> ___
> 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
Re: [Intel-gfx] [PATCH 4/5] drm/i915/gen9+: Don't remove secondary power well requests
This patch makes sense and seems the right thing to do...
However removing the sanitize with I915_WRITE(*, val & ~mask);
doesn't give me very comfortable...
I've seem many power well timeouts on cnl due the lack of that sanitize...
I will try to save some time here and do some experiments with cnl.
On Thu, Jun 29, 2017 at 8:37 AM, Imre Deak wrote:
> So far in an attempt to make sure all power wells get disabled during
> display uninitialization the driver removed any secondary request bits
> (BIOS, KVMR, DEBUG) that were set for a given power well. The known
> source for these requests was DMC's request on power well 1 and the misc
> IO power well. Since DMC is inactive (DC states are disabled) at the
> point we disable these power wells, there shouldn't be any reason to
> leave them on. However there are two problems with the above
> assumption: Bspec requires that the misc IO power well stays enabled
> (without providing a reason) and there can be KVMR requests that we
> can't remove anyway (the KVMR request register is R/O). Atm, a KVMR
> request can trigger a timeout WARN when trying to disable power wells.
>
> To make the code aligned to Bspec and to get rid of the KVMR WARN, don't
> try to remove the secondary requests, only detect them and stop polling
> for the power well disabled state when any one is set.
>
> Also add a comment about the timeout values required by Bspec when
> enabling power wells and the fact that waiting for them to get disabled
> is not required by Bspec.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98564
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 109
> ++--
> 1 file changed, 63 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 1fc75e6..2fe715b 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -341,6 +341,59 @@ static void skl_power_well_pre_disable(struct
> drm_i915_private *dev_priv,
> 1 << PIPE_C | 1 << PIPE_B);
> }
>
> +static void gen9_wait_for_power_well_enable(struct drm_i915_private
> *dev_priv,
> + struct i915_power_well
> *power_well)
> +{
> + int id = power_well->id;
> +
> + /* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
> + WARN_ON(intel_wait_for_register(dev_priv,
> + HSW_PWR_WELL_DRIVER,
> + SKL_POWER_WELL_STATE(id),
> + SKL_POWER_WELL_STATE(id),
> + 1));
> +}
> +
> +static u32 gen9_power_well_requesters(struct drm_i915_private *dev_priv, int
> id)
> +{
> + u32 req_mask = SKL_POWER_WELL_REQ(id);
> + u32 ret;
> +
> + ret = I915_READ(HSW_PWR_WELL_BIOS) & req_mask ? 1 : 0;
> + ret |= I915_READ(HSW_PWR_WELL_DRIVER) & req_mask ? 2 : 0;
> + ret |= I915_READ(HSW_PWR_WELL_KVMR) & req_mask ? 4 : 0;
> + ret |= I915_READ(HSW_PWR_WELL_DEBUG) & req_mask ? 8 : 0;
> +
> + return ret;
> +}
> +
> +static void gen9_wait_for_power_well_disable(struct drm_i915_private
> *dev_priv,
> +struct i915_power_well
> *power_well)
> +{
> + int id = power_well->id;
> + bool disabled;
> + u32 reqs;
> +
> + /*
> +* Bspec doesn't require waiting for PWs to get disabled, but still do
> +* this for paranoia. The known cases where a PW will be forced on:
> +* - a KVMR request on any power well via the KVMR request register
> +* - a DMC request on PW1 and MISC_IO power wells via the BIOS and
> +* DEBUG request registers
> +* Skip the wait in case any of the request bits are set and print a
> +* diagnostic message.
> +*/
> + wait_for((disabled = !(I915_READ(HSW_PWR_WELL_DRIVER) &
> + SKL_POWER_WELL_STATE(id))) ||
> +(reqs = gen9_power_well_requesters(dev_priv, id)), 1);
> + if (disabled)
> + return;
> +
> + DRM_DEBUG_KMS("%s forced on (bios:%d driver:%d kvmr:%d debug:%d)\n",
> + power_well->name,
> + !!(reqs & 1), !!(reqs & 2), !!(reqs & 4), !!(reqs & 8));
> +}
> +
> static void hsw_set_power_well(struct drm_i915_private *dev_priv,
>struct i915_power_well *power_well, bool
> enable)
> {
> @@ -746,45 +799,6 @@ void skl_disable_dc6(struct drm_i915_private *dev_priv)
> gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> }
>
> -static void
> -gen9_sanitize_power_well_requests(struct drm_i915_private *dev_priv,
> - struct i915_power_well *power_well)
> -{
> - enum skl_disp_power_wells power_well_id = power_well->id;
> - u32 val
Re: [Intel-gfx] [PATCH] drm/i915/cfl: Fix Workarounds.
I went and read Mika's review in [1] and also the patches posted and
committed after that. The version currently in drm-tip deviates from his
review and the fix here addresses Mika's comments correctly.
Verified that BSpec does indeed say
WaDisableKillLogic is applicable to only SKL and BXT.
As for WaDisableHDCInvalidation, git blame indicates this is intended to
be retained for all gen9 platforms.
So this patch lgtm.
Reviewed-by: Dhinakaran Pandiyan
[1]
https://lists.freedesktop.org/archives/intel-gfx/2017-June/130100.html
-DK
On Mon, 2017-06-19 at 14:21 -0700, Rodrigo Vivi wrote:
> During the review of Coffee Lake workarounds Mika pointed out
> that WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC
> should be removed from CFL and with that I should carry the rv-b.
>
> However when doing the v2 I removed another Workaround that should
> remain because although not mentioned by spec the history of hangs
> around it advocates on its favor.
>
> On some follow-up patches I continued operating on the wrong
> workardound, but Ville noticed that, so here is the fix for the
> current CFL code that is upstream already.
>
> Fixes: 46c26662d2f ("drm/i915/cfl: Introduce Coffee Lake workarounds.")
> Cc: Ville Syrjälä
> Cc: Dhinakaran Pandiyan
> Cc: Mika Kuoppala
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index a4487c5..5b4de71 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -821,9 +821,10 @@ static int gen9_init_workarounds(struct intel_engine_cs
> *engine)
> I915_WRITE(BDW_SCRATCH1, I915_READ(BDW_SCRATCH1) |
> GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE);
>
> - /* WaDisableKillLogic:bxt,skl,kbl,cfl */
> - I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> -ECOCHK_DIS_TLB);
> + /* WaDisableKillLogic:bxt,skl,kbl */
> + if (!IS_COFFEELAKE(dev_priv))
> + I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> +ECOCHK_DIS_TLB);
>
> /* WaClearFlowControlGpgpuContextSave:skl,bxt,kbl,glk,cfl */
> /* WaDisablePartialInstShootdown:skl,bxt,kbl,glk,cfl */
> @@ -894,10 +895,9 @@ static int gen9_init_workarounds(struct intel_engine_cs
> *engine)
> WA_SET_BIT_MASKED(HDC_CHICKEN0,
> HDC_FORCE_NON_COHERENT);
>
> - /* WaDisableHDCInvalidation:skl,bxt,kbl */
> - if (!IS_COFFEELAKE(dev_priv))
> - I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> -BDW_DISABLE_HDC_INVALIDATION);
> + /* WaDisableHDCInvalidation:skl,bxt,kbl,cfl */
> + I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
> +BDW_DISABLE_HDC_INVALIDATION);
>
> /* WaDisableSamplerPowerBypassForSOPingPong:skl,bxt,kbl,cfl */
> if (IS_SKYLAKE(dev_priv) ||
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Add support for CCS modifiers
On Fri, Jun 23, 2017 at 09:45:44AM -0700, Ben Widawsky wrote:
> v2:
> Support sprite plane.
> Support pipe C/D limitation on GEN9.
>
> This requires rebase on the correct Ville patches
>
> Cc: Daniel Stone
> Cc: Kristian Høgsberg
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/intel_display.c | 34 +--
> drivers/gpu/drm/i915/intel_sprite.c | 39
> +++-
> 2 files changed, 66 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 877a51514c61..2a0e5cd26059 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -93,7 +93,17 @@ static const uint32_t skl_primary_formats[] = {
> DRM_FORMAT_VYUY,
> };
>
> +static const uint64_t skl_format_modifiers_noccs[] = {
> + I915_FORMAT_MOD_Yf_TILED,
> + I915_FORMAT_MOD_Y_TILED,
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> static const uint64_t skl_format_modifiers[] = {
Maybe calls this _ccs[] then?
> + I915_FORMAT_MOD_Yf_TILED_CCS,
> + I915_FORMAT_MOD_Y_TILED_CCS,
> I915_FORMAT_MOD_Yf_TILED,
> I915_FORMAT_MOD_Y_TILED,
> I915_FORMAT_MOD_X_TILED,
> @@ -13872,17 +13882,13 @@ static bool skl_mod_supported(uint32_t format,
> uint64_t modifier)
> return false;
> }
> case DRM_FORMAT_RGB565:
> - case DRM_FORMAT_XRGB:
> - case DRM_FORMAT_XBGR:
> - case DRM_FORMAT_ARGB:
> - case DRM_FORMAT_ABGR:
> case DRM_FORMAT_XRGB2101010:
> case DRM_FORMAT_XBGR2101010:
> case DRM_FORMAT_YUYV:
> case DRM_FORMAT_YVYU:
> case DRM_FORMAT_UYVY:
> case DRM_FORMAT_VYUY:
> - /* All i915 modifiers are fine */
> + /* All non-ccs i915 modifiers are fine */
> switch (modifier) {
> case DRM_FORMAT_MOD_LINEAR:
> case I915_FORMAT_MOD_X_TILED:
> @@ -13892,6 +13898,12 @@ static bool skl_mod_supported(uint32_t format,
> uint64_t modifier)
> default:
> return false;
> }
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> + /* All i915 modifiers are fine */
> + return true;
> default:
> return false;
> }
> @@ -14123,13 +14135,23 @@ intel_primary_plane_create(struct drm_i915_private
> *dev_priv, enum pipe pipe)
> primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
> primary->check_plane = intel_check_primary_plane;
>
> - if (INTEL_GEN(dev_priv) >= 9) {
> + if (INTEL_GEN(dev_priv) >= 10) {
> intel_primary_formats = skl_primary_formats;
> num_formats = ARRAY_SIZE(skl_primary_formats);
> intel_format_modifiers = skl_format_modifiers;
>
> primary->update_plane = skylake_update_primary_plane;
> primary->disable_plane = skylake_disable_primary_plane;
> + } else if (INTEL_GEN(dev_priv) >= 9) {
> + intel_primary_formats = skl_primary_formats;
> + num_formats = ARRAY_SIZE(skl_primary_formats);
> + if (pipe >= PIPE_C)
I think I'd keep the gen10 stuff in the same branch still. Also this
misses GLK. So maybe something like this:
if (GEN >= 10 || IS_GLK || pipe != PIPE_C)
> + intel_format_modifiers = skl_format_modifiers;
> + else
> + intel_format_modifiers = skl_format_modifiers_noccs;
> +
> + primary->update_plane = skylake_update_primary_plane;
> + primary->disable_plane = skylake_disable_primary_plane;
> } else if (INTEL_GEN(dev_priv) >= 4) {
> intel_primary_formats = i965_primary_formats;
> num_formats = ARRAY_SIZE(i965_primary_formats);
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index e80834cb1f4c..de4454a8ef9e 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1085,7 +1085,17 @@ static uint32_t skl_plane_formats[] = {
> DRM_FORMAT_VYUY,
> };
>
> +static const uint64_t skl_plane_format_modifiers_noccs[] = {
> + I915_FORMAT_MOD_Yf_TILED,
> + I915_FORMAT_MOD_Y_TILED,
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> static const uint64_t skl_plane_format_modifiers[] = {
Again _ccs[] maybe?
> + I915_FORMAT_MOD_Yf_TILED_CCS,
> + I915_FORMAT_MOD_Y_TILED_CCS,
> I915_FORMAT_MOD_Yf_TILED,
> I915_FORMAT_MOD_Y_TILED,
> I915_FORMAT_MOD_X_TILED,
> @@ -1108,6 +1118,20 @@ static bool
> intel_sprite_plane_format_mod_supported(struct drm_plane *plane,
> modifier != DRM_FORMAT_MOD_LINEAR)
> return
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Add format modifiers for Intel
On Fri, Jun 23, 2017 at 09:45:43AM -0700, Ben Widawsky wrote:
> This was based on a patch originally by Kristian. It has been modified
> pretty heavily to use the new callbacks from the previous patch.
>
> v2:
> - Add LINEAR and Yf modifiers to list (Ville)
> - Combine i8xx and i965 into one list of formats (Ville)
> - Allow 1010102 formats for Y/Yf tiled (Ville)
>
> v3:
> - Handle cursor formats (Ville)
> - Put handling for LINEAR in the mod_support functions (Ville)
>
> v4:
> - List each modifier explicitly in supported modifiers (Ville)
> - Handle the CURSOR plane (Ville)
>
> v5:
> - Split out cursor and sprite handling (Ville)
>
> v6:
> - Actually use the sprite funcs (Emil)
> - Use unreachable (Emil)
>
> v7:
> - Only allow Intel modifiers and LINEAR (Ben)
>
> v8
> - Fix spite assert introduced in v6 (Daniel)
>
> Cc: Ville Syrjälä
> Cc: Kristian H. Kristensen
> Cc: Emil Velikov
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/intel_display.c | 136
> +--
> drivers/gpu/drm/i915/intel_sprite.c | 82 -
> 2 files changed, 211 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7d55c5e3df28..877a51514c61 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -72,6 +72,12 @@ static const uint32_t i965_primary_formats[] = {
> DRM_FORMAT_XBGR2101010,
> };
>
> +static const uint64_t i9xx_format_modifiers[] = {
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> static const uint32_t skl_primary_formats[] = {
> DRM_FORMAT_C8,
> DRM_FORMAT_RGB565,
> @@ -87,11 +93,24 @@ static const uint32_t skl_primary_formats[] = {
> DRM_FORMAT_VYUY,
> };
>
> +static const uint64_t skl_format_modifiers[] = {
> + I915_FORMAT_MOD_Yf_TILED,
> + I915_FORMAT_MOD_Y_TILED,
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> /* Cursor formats */
> static const uint32_t intel_cursor_formats[] = {
> DRM_FORMAT_ARGB,
> };
>
> +static const uint64_t cursor_format_modifiers[] = {
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
> struct intel_crtc_state *pipe_config);
> static void ironlake_pch_clock_get(struct intel_crtc *crtc,
> @@ -13810,6 +13829,108 @@ void intel_plane_destroy(struct drm_plane *plane)
> kfree(to_intel_plane(plane));
> }
>
> +static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + switch (format) {
> + case DRM_FORMAT_C8:
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_XRGB:
> + return modifier == DRM_FORMAT_MOD_LINEAR ||
> + modifier == I915_FORMAT_MOD_X_TILED;
> + default:
> + return false;
> + }
> +}
> +
> +static bool i965_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + switch (format) {
> + case DRM_FORMAT_C8:
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_XRGB2101010:
> + case DRM_FORMAT_XBGR2101010:
> + return modifier == DRM_FORMAT_MOD_LINEAR ||
> + modifier == I915_FORMAT_MOD_X_TILED;
> + default:
> + return false;
> + }
> +}
> +
> +static bool skl_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + switch (format) {
> + case DRM_FORMAT_C8:
> + switch (modifier) {
> + case DRM_FORMAT_MOD_LINEAR:
> + case I915_FORMAT_MOD_X_TILED:
> + case I915_FORMAT_MOD_Y_TILED:
> + return true;
> + default:
> + return false;
> + }
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> + case DRM_FORMAT_XRGB2101010:
> + case DRM_FORMAT_XBGR2101010:
> + case DRM_FORMAT_YUYV:
> + case DRM_FORMAT_YVYU:
> + case DRM_FORMAT_UYVY:
> + case DRM_FORMAT_VYUY:
> + /* All i915 modifiers are fine */
> + switch (modifier) {
> + case DRM_FORMAT_MOD_LINEAR:
> + case I915_FORMAT_MOD_X_TILED:
> + case I915_FORMAT_MOD_Y_TILED:
> + case I915_FORMAT_MOD_Yf_TILED:
> + return true;
> + default:
> + return false;
> + }
> + default:
> + return false;
> + }
> +}
I think I might bikeshed that as
skl_mod_supported()
{
switch (format) {
case DRM_FORMAT_XRGB:
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ARGB:
case D
Re: [Intel-gfx] [PATCH 2/4] drm: Create a format/modifier blob
On Fri, Jun 23, 2017 at 09:45:42AM -0700, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
>
> v2:
> * Removed __packed, and alignment (.+)
> * Fix indent in drm_format_modifier fields (Liviu)
> * Remove duplicated modifier > 64 check (Liviu)
> * Change comment about modifier (Liviu)
> * Remove arguments to blob creation, use plane instead (Liviu)
> * Fix data types (Ben)
> * Make the blob part of uapi (Daniel)
>
> v3:
> Remove unused ret field.
> Change i, and j to unsigned int (Emil)
>
> v4:
> Use plane->modifier_count instead of recounting (Daniel)
>
> Cc: Rob Clark
> Cc: Kristian H. Kristensen
> Signed-off-by: Ben Widawsky
> Reviewed-by: Daniel Stone (v2)
> Reviewed-by: Liviu Dudau (v2)
> Reviewed-by: Emil Velikov (v3)
> ---
> drivers/gpu/drm/drm_mode_config.c | 7
> drivers/gpu/drm/drm_plane.c | 83
> +++
> include/drm/drm_mode_config.h | 6 +++
> include/uapi/drm/drm_mode.h | 50 +++
> 4 files changed, 146 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index d9862259a2a7..6bfbc3839df5 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.gamma_lut_size_property = prop;
>
> + prop = drm_property_create(dev,
> +DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
> +"IN_FORMATS", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.modifiers = prop;
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index d3fc561d7b48..8a2d5765837a 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -62,6 +62,86 @@ static unsigned int drm_num_planes(struct drm_device *dev)
> return num;
> }
>
> +static inline u32 *
> +formats_ptr(struct drm_format_modifier_blob *blob)
> +{
> + return (u32 *)(((char *)blob) + blob->formats_offset);
> +}
> +
> +static inline struct drm_format_modifier *
> +modifiers_ptr(struct drm_format_modifier_blob *blob)
> +{
> + return (struct drm_format_modifier *)(((char *)blob) +
> blob->modifiers_offset);
> +}
> +
> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane
> *plane)
> +{
> + const struct drm_mode_config *config = &dev->mode_config;
> + struct drm_property_blob *blob;
> + struct drm_format_modifier *mod;
> + size_t blob_size, formats_size, modifiers_size;
> + struct drm_format_modifier_blob *blob_data;
> + unsigned int i, j;
> +
> + formats_size = sizeof(*plane->format_types) * plane->format_count;
sizeof(__u32) perhaps here since this is about the uabi, not about how
we store the formats internally.
> + if (WARN_ON(!formats_size)) {
> + /* 0 formats are never expected */
> + return 0;
> + }
> +
> + modifiers_size =
> + sizeof(struct drm_format_modifier) * plane->modifier_count;
> +
> + blob_size = sizeof(struct drm_format_modifier_blob);
> + /* Modifiers offset is a pointer to a struct with a 64 bit field so it
> + * should be naturally aligned to 8B.
> + */
> + blob_size += ALIGN(formats_size, 8);
Here it's ALIGN(format_size) ...
> + blob_size += modifiers_size;
> +
> + blob = drm_property_create_blob(dev, blob_size, NULL);
> + if (IS_ERR(blob))
> + return -1;
> +
> + blob_data = (struct drm_format_modifier_blob *)blob->data;
> + blob_data->version = FORMAT_BLOB_CURRENT;
> + blob_data->count_formats = plane->format_count;
> + blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
> + blob_data->count_modifiers = plane->modifier_count;
> +
> + blob_data->modifiers_offset =
> + ALIGN(blob_data->formats_offset + formats_size, 8);
... 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?).
> +
> + memcpy(formats_ptr(blob_data), plane->format_types, formats_size);
> +
> + /* If we can't determine support, just bail */
> + if (!plane->funcs->format_mod_supported)
> + goto done;
> +
> + mod = modifiers_ptr(blob_data);
> + for (i = 0; i < plane->modifier_count; i++) {
> + for (j = 0; j < plane->format_count; j++) {
> + if (plane->funcs->format_mod_supported(plane,
> +
> plane->format_types[j],
> +
Re: [Intel-gfx] [PATCH v4 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote: > Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42) > > From: Ville Syrjälä > > > > Introduce an rw_semaphore to protect the display commits. All normal > > commits use down_read() and hence can proceed in parallel, but GPU reset > > will use down_write() making sure no other commits are in progress when > > we have to pull the plug on the display engine on pre-g4x platforms. > > There are no modeset/gem locks taken inside __intel_atomic_commit_tail() > > itself, and we wait for all dependencies before the down_read(), and > > thus there is no chance of deadlocks with this scheme. > > This matches what I thought should be done (I didn't think of using > rwsem just a mutex, nice touch). The point I got stuck on was what > should be done after the reset? I expected another modeset to return the > state back or otherwise the inflight would get confused? I guess that can happen. For instance, if we have a crtc_enable() in flight, and then we do a reset before it gets committed we would end up doing crtc_enable() twice in a row without a crtc_disable in between. For page flips and such this shouldn't be a big deal in general. > > > During reset we should be recommiting the state that was committed last. > > But for now we'll settle for recommiting the last state for each object. > > Ah, I guess that explains the above. What is the complication with > restoring the current state as opposed to the next state? Well the main thing is just tracking which is the current state. That just needs refactoring the .atomic_duplicate_state() calling convention across the whole tree so that we can then duplicate the committed state rather than the latest state. Also due to the commit_hw_done() being potentially done after the modeset locks have been dropped, I don't think we can be certain of it getting called in the same order as swap_state(), hence when we track the committed state in commit_hw_done() we'll have to have some way to figure out if our new state is in fact the latest committed state for each object or if the calls got reordered. We don't insert any dependencies between two commits unless they touch the same active crtc, thus this reordering seems very much possible. Dunno if we should add some way to add such dependeencies whenever the same object is part of two otherwise independent commits, or if we just want to try and work with the reordered calls. My idea for the latter was some kind of seqno/age counter on the object states that allows me to recongnize which state is more recent. The object states aren't refcounted so hanging on to the wrong pointer could cause an oops the next time we have to perform a GPU reset. -- 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 2/5] drm/i915/skl: Don't disable misc IO power well during display uninit
Indeed very clear there... I don't know how did this never caused any big trouble... Reviewed-by: Rodrigo Vivi On Thu, Jun 29, 2017 at 8:36 AM, Imre Deak wrote: > Bspec requires leaving the misc IO power well enabled during display > uninit, so align the code accordingly. > > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_runtime_pm.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > b/drivers/gpu/drm/i915/intel_runtime_pm.c > index fd59016..8418879 100644 > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > @@ -2694,9 +2694,10 @@ static void skl_display_core_uninit(struct > drm_i915_private *dev_priv) > > mutex_lock(&power_domains->lock); > > - well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO); > - intel_power_well_disable(dev_priv, well); > - > + /* > +* BSpec says to keep the MISC IO power well enabled here, only > +* remove our request for power well 1. > +*/ > well = lookup_power_well(dev_priv, SKL_DISP_PW_1); > intel_power_well_disable(dev_priv, well); > > -- > 2.7.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
Re: [Intel-gfx] [PATCH 7/7] dma-buf/sw-sync: Use an rbtree to sort fences in the timeline
Quoting Sean Paul (2017-06-29 19:10:11)
> On Thu, Jun 29, 2017 at 01:59:30PM +0100, Chris Wilson wrote:
> > Reduce the list iteration when incrementing the timeline by storing the
> > fences in increasing order.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Sumit Semwal
> > Cc: Sean Paul
> > Cc: Gustavo Padovan
> > ---
> > drivers/dma-buf/sw_sync.c| 49
> > ++--
> > drivers/dma-buf/sync_debug.h | 5 +
> > 2 files changed, 48 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
> > index e51fe11bbbea..8cef5d345316 100644
> > --- a/drivers/dma-buf/sw_sync.c
> > +++ b/drivers/dma-buf/sw_sync.c
> > @@ -96,6 +96,7 @@ static struct sync_timeline *sync_timeline_create(const
> > char *name)
> > obj->context = dma_fence_context_alloc(1);
> > strlcpy(obj->name, name, sizeof(obj->name));
> >
> > + obj->pt_tree = RB_ROOT;
> > INIT_LIST_HEAD(&obj->pt_list);
> > spin_lock_init(&obj->lock);
> >
> > @@ -142,9 +143,13 @@ static void sync_timeline_signal(struct sync_timeline
> > *obj, unsigned int inc)
> >
> > obj->value += inc;
> >
> > - list_for_each_entry_safe(pt, next, &obj->pt_list, link)
> > - if (dma_fence_is_signaled_locked(&pt->base))
> > - list_del_init(&pt->link);
> > + list_for_each_entry_safe(pt, next, &obj->pt_list, link) {
> > + if (!dma_fence_is_signaled_locked(&pt->base))
> > + break;
> > +
> > + list_del_init(&pt->link);
> > + rb_erase(&pt->node, &obj->pt_tree);
> > + }
> >
> > spin_unlock_irq(&obj->lock);
> > }
> > @@ -174,8 +179,38 @@ static struct sync_pt *sync_pt_create(struct
> > sync_timeline *obj,
> > INIT_LIST_HEAD(&pt->link);
> >
> > spin_lock_irq(&obj->lock);
> > - if (!dma_fence_is_signaled_locked(&pt->base))
> > - list_add_tail(&pt->link, &obj->pt_list);
> > + if (!dma_fence_is_signaled_locked(&pt->base)) {
> > + struct rb_node **p = &obj->pt_tree.rb_node;
> > + struct rb_node *parent = NULL;
> > +
> > + while (*p) {
> > + struct sync_pt *other;
> > + int cmp;
> > +
> > + parent = *p;
> > + other = rb_entry(parent, typeof(*pt), node);
> > + cmp = value - other->base.seqno;
>
> We're imposing an implicit limitation on userspace here that points cannot be
> > INT_MAX apart (since they'll be in the wrong order in the tree).
That's not a new limitation. It's an artifact of using the u32 timeline/seqno.
> I wonder how much this patch will actually save, given that the number of
> active points
> on a given timeline should be small. Do we have any evidence that this
> optimization is warranted?
The good news is that for empty/small trees, the overhead is tiny, less
than the cost of the syscall. I honestly don't know who uses sw_sync and
so would benefit. I figured I would throw it out here since it was
trivial.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/gen9+: Add 10 us delay after power well 1/AUX IO pw disabling
Oh! indeed! Reviewed-by: Rodrigo Vivi On Thu, Jun 29, 2017 at 8:36 AM, Imre Deak wrote: > Bspec requires a 10 us delay after disabling power well 1 and - if not > toggled on-demand - the AUX IO power wells during display uninit. > > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_runtime_pm.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > b/drivers/gpu/drm/i915/intel_runtime_pm.c > index efe80ed..fd59016 100644 > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > @@ -2701,6 +2701,8 @@ static void skl_display_core_uninit(struct > drm_i915_private *dev_priv) > intel_power_well_disable(dev_priv, well); > > mutex_unlock(&power_domains->lock); > + > + usleep_range(10, 30); /* 10 us delay per Bspec */ > } > > void bxt_display_core_init(struct drm_i915_private *dev_priv, > @@ -2758,6 +2760,8 @@ void bxt_display_core_uninit(struct drm_i915_private > *dev_priv) > intel_power_well_disable(dev_priv, well); > > mutex_unlock(&power_domains->lock); > + > + usleep_range(10, 30); /* 10 us delay per Bspec */ > } > > #define CNL_PROCMON_IDX(val) \ > @@ -2859,6 +2863,8 @@ static void cnl_display_core_uninit(struct > drm_i915_private *dev_priv) > intel_power_well_disable(dev_priv, well); > mutex_unlock(&power_domains->lock); > > + usleep_range(10, 30); /* 10 us delay per Bspec */ > + > /* 5. Disable Comp */ > val = I915_READ(CHICKEN_MISC_2); > val |= COMP_PWR_DOWN; > -- > 2.7.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
Re: [Intel-gfx] [PATCH 7/7] dma-buf/sw-sync: Use an rbtree to sort fences in the timeline
On Thu, Jun 29, 2017 at 01:59:30PM +0100, Chris Wilson wrote:
> Reduce the list iteration when incrementing the timeline by storing the
> fences in increasing order.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Sean Paul
> Cc: Gustavo Padovan
> ---
> drivers/dma-buf/sw_sync.c| 49
> ++--
> drivers/dma-buf/sync_debug.h | 5 +
> 2 files changed, 48 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
> index e51fe11bbbea..8cef5d345316 100644
> --- a/drivers/dma-buf/sw_sync.c
> +++ b/drivers/dma-buf/sw_sync.c
> @@ -96,6 +96,7 @@ static struct sync_timeline *sync_timeline_create(const
> char *name)
> obj->context = dma_fence_context_alloc(1);
> strlcpy(obj->name, name, sizeof(obj->name));
>
> + obj->pt_tree = RB_ROOT;
> INIT_LIST_HEAD(&obj->pt_list);
> spin_lock_init(&obj->lock);
>
> @@ -142,9 +143,13 @@ static void sync_timeline_signal(struct sync_timeline
> *obj, unsigned int inc)
>
> obj->value += inc;
>
> - list_for_each_entry_safe(pt, next, &obj->pt_list, link)
> - if (dma_fence_is_signaled_locked(&pt->base))
> - list_del_init(&pt->link);
> + list_for_each_entry_safe(pt, next, &obj->pt_list, link) {
> + if (!dma_fence_is_signaled_locked(&pt->base))
> + break;
> +
> + list_del_init(&pt->link);
> + rb_erase(&pt->node, &obj->pt_tree);
> + }
>
> spin_unlock_irq(&obj->lock);
> }
> @@ -174,8 +179,38 @@ static struct sync_pt *sync_pt_create(struct
> sync_timeline *obj,
> INIT_LIST_HEAD(&pt->link);
>
> spin_lock_irq(&obj->lock);
> - if (!dma_fence_is_signaled_locked(&pt->base))
> - list_add_tail(&pt->link, &obj->pt_list);
> + if (!dma_fence_is_signaled_locked(&pt->base)) {
> + struct rb_node **p = &obj->pt_tree.rb_node;
> + struct rb_node *parent = NULL;
> +
> + while (*p) {
> + struct sync_pt *other;
> + int cmp;
> +
> + parent = *p;
> + other = rb_entry(parent, typeof(*pt), node);
> + cmp = value - other->base.seqno;
We're imposing an implicit limitation on userspace here that points cannot be
> INT_MAX apart (since they'll be in the wrong order in the tree).
I wonder how much this patch will actually save, given that the number of
active points
on a given timeline should be small. Do we have any evidence that this
optimization is warranted?
Sean
> + if (cmp > 0) {
> + p = &parent->rb_right;
> + } else if (cmp < 0) {
> + p = &parent->rb_left;
> + } else {
> + if (dma_fence_get_rcu(&other->base)) {
> + dma_fence_put(&pt->base);
> + pt = other;
> + goto unlock;
> + }
> + p = &parent->rb_left;
> + }
> + }
> + rb_link_node(&pt->node, parent, p);
> + rb_insert_color(&pt->node, &obj->pt_tree);
> +
> + parent = rb_next(&pt->node);
> + list_add_tail(&pt->link,
> + parent ? &rb_entry(parent, typeof(*pt),
> node)->link : &obj->pt_list);
> + }
> +unlock:
> spin_unlock_irq(&obj->lock);
>
> return pt;
> @@ -201,8 +236,10 @@ static void timeline_fence_release(struct dma_fence
> *fence)
>
> spin_lock_irqsave(fence->lock, flags);
>
> - if (!list_empty(&pt->link))
> + if (!list_empty(&pt->link)) {
> list_del(&pt->link);
> + rb_erase(&pt->node, &parent->pt_tree);
> + }
>
> spin_unlock_irqrestore(fence->lock, flags);
>
> diff --git a/drivers/dma-buf/sync_debug.h b/drivers/dma-buf/sync_debug.h
> index 899ba0e19fd3..b7a5fab12179 100644
> --- a/drivers/dma-buf/sync_debug.h
> +++ b/drivers/dma-buf/sync_debug.h
> @@ -14,6 +14,7 @@
> #define _LINUX_SYNC_H
>
> #include
> +#include
> #include
> #include
>
> @@ -25,6 +26,7 @@
> * @kref:reference count on fence.
> * @name:name of the sync_timeline. Useful for debugging
> * @lock:lock protecting @child_list_head and fence.status
> + * @pt_tree: rbtree of active (unsignaled/errored) sync_pts
> * @pt_list: list of active (unsignaled/errored) sync_pts
> * @sync_timeline_list: membership in global sync_timeline_list
> */
> @@ -36,6 +38,7 @@ struct sync_timeline {
> u64 context;
> int value;
>
> + struct rb_root pt_tree;
> struct list_headpt_list;
> spinlock_t lock;
>
> @@ -51,10 +54,12 @@ stati
Re: [Intel-gfx] [PATCH 3/5] drm/i915/bxt, glk: Fix assert on conditions for DC9 enabling
"Disable all display engine functions using the full mode set disable sequence on all pipes, transcoders, ports, planes, and power well 2 (PG2)." I hope at this point we really already did all the rest besides the PG2. Anyways I believe this patch itself makes total sense so: Reviewed-by: Rodrigo Vivi On Thu, Jun 29, 2017 at 8:37 AM, Imre Deak wrote: > What we want to assert based on the conditions required by Bspec is that > power well 2 is disabled, so no need to check for other power wells. > In addition we can only check if the driver's request is removed, the > actual state depends on whether the other request bits are set or not > (BIOS, KVMR, DEBUG). So check only the driver's request bit. > > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > b/drivers/gpu/drm/i915/intel_runtime_pm.c > index 8418879..1fc75e6 100644 > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > @@ -549,7 +549,9 @@ static void assert_can_enable_dc9(struct drm_i915_private > *dev_priv) > "DC9 already programmed to be enabled.\n"); > WARN_ONCE(I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5, > "DC5 still not disabled to enable DC9.\n"); > - WARN_ONCE(I915_READ(HSW_PWR_WELL_DRIVER), "Power well on.\n"); > + WARN_ONCE(I915_READ(HSW_PWR_WELL_DRIVER) & > + SKL_POWER_WELL_REQ(SKL_DISP_PW_2), > + "Power well 2 on.\n"); > WARN_ONCE(intel_irqs_enabled(dev_priv), > "Interrupts not disabled yet.\n"); > > -- > 2.7.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
Re: [Intel-gfx] [PATCH 5/5] drm/i915/cnl: Fix comment about AUX IO power well enable/disable
Reviewed-by: Rodrigo Vivi On Thu, Jun 29, 2017 at 8:37 AM, Imre Deak wrote: > The comments match an earlier version of the patch, fix them to match > the current state. > > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c > b/drivers/gpu/drm/i915/intel_runtime_pm.c > index 2fe715b..5eb9c5e 100644 > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c > @@ -2845,7 +2845,10 @@ static void cnl_display_core_init(struct > drm_i915_private *dev_priv, bool resume > val |= CL_POWER_DOWN_ENABLE; > I915_WRITE(CNL_PORT_CL1CM_DW5, val); > > - /* 4. Enable Power Well 1 (PG1) and Aux IO Power */ > + /* > +* 4. Enable Power Well 1 (PG1). > +*The AUX IO power wells will be enabled on demand. > +*/ > mutex_lock(&power_domains->lock); > well = lookup_power_well(dev_priv, SKL_DISP_PW_1); > intel_power_well_enable(dev_priv, well); > @@ -2877,7 +2880,11 @@ static void cnl_display_core_uninit(struct > drm_i915_private *dev_priv) > /* 3. Disable CD clock */ > cnl_uninit_cdclk(dev_priv); > > - /* 4. Disable Power Well 1 (PG1) and Aux IO Power */ > + /* > +* 4. Disable Power Well 1 (PG1). > +*The AUX IO power wells are toggled on demand, so they are > already > +*disabled at this point. > +*/ > mutex_lock(&power_domains->lock); > well = lookup_power_well(dev_priv, SKL_DISP_PW_1); > intel_power_well_disable(dev_priv, well); > -- > 2.7.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
Re: [Intel-gfx] [PATCH v4 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42) > From: Ville Syrjälä > > Introduce an rw_semaphore to protect the display commits. All normal > commits use down_read() and hence can proceed in parallel, but GPU reset > will use down_write() making sure no other commits are in progress when > we have to pull the plug on the display engine on pre-g4x platforms. > There are no modeset/gem locks taken inside __intel_atomic_commit_tail() > itself, and we wait for all dependencies before the down_read(), and > thus there is no chance of deadlocks with this scheme. This matches what I thought should be done (I didn't think of using rwsem just a mutex, nice touch). The point I got stuck on was what should be done after the reset? I expected another modeset to return the state back or otherwise the inflight would get confused? > During reset we should be recommiting the state that was committed last. > But for now we'll settle for recommiting the last state for each object. Ah, I guess that explains the above. What is the complication with restoring the current state as opposed to the next state? But I have to leave debating the merits of atomic internals to others. :| -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm 3/3] intel: PCI Ids for U SKU in CFL
series merged to libdrm. thanks for patches and review. On Wed, Jun 28, 2017 at 2:09 PM, Clint Taylor wrote: > > > On 06/21/2017 09:39 AM, Anusha Srivatsa wrote: >> >> Add the PCI IDs for U SKU IN CFL by following the spec. >> >> v2: Update IDs >> >> Cc: Rodrigo Vivi >> Signed-off-by: Anusha Srivatsa >> --- >> intel/intel_chipset.h | 12 +++- >> 1 file changed, 11 insertions(+), 1 deletion(-) >> >> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h >> index 4da145c..8a0d4ff 100644 >> --- a/intel/intel_chipset.h >> +++ b/intel/intel_chipset.h >> @@ -228,6 +228,10 @@ >> #define PCI_CHIP_COFFEELAKE_S_GT2_3 0x3E96 >> #define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B >> #define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7 >> +#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8 > > Matches values in i915 driver. > Reviewed-by: Clinton Taylor > >> #define IS_MOBILE(devid)((devid) == PCI_CHIP_I855_GM || \ >> (devid) == PCI_CHIP_I915_GM || \ >> @@ -469,8 +473,14 @@ >> #define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 >> || \ >>(devid) == PCI_CHIP_COFFEELAKE_H_GT2_2) >> +#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 >> || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_2 >> || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_3 >> || \ >> + (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4) >> + >> #define IS_COFFEELAKE(devid) (IS_CFL_S(devid) || \ >> - IS_CFL_H(devid)) >> + IS_CFL_H(devid) || \ >> + IS_CFL_U(devid)) >> #define IS_GEN9(devid) (IS_SKYLAKE(devid) || \ >> IS_BROXTON(devid) || \ > > > ___ > 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
Re: [Intel-gfx] [RESEND i-g-t 3/3] lib/cfl: Add PCI Ids for U SKU in CFl
series merged. thanks for the patches and reviews. On Wed, 2017-06-28 at 23:16 -0700, Anusha Srivatsa wrote: > Follow the spec and add ID for U SKU > > v2: Update IDs in accordance to the kernel commit: > d29fe702c9cb682df99146d24d06e5455f043101 (Chris) > > Cc: Rodrigo Vivi > Signed-off-by: Anusha Srivatsa > Reviewed-by: Clint Taylor > --- > lib/i915_pciids.h | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h > index c319e37..71cce60 100644 > --- a/lib/i915_pciids.h > +++ b/lib/i915_pciids.h > @@ -346,8 +346,15 @@ > INTEL_VGA_DEVICE(0x3E9B, info), /* Halo GT2 */ \ > INTEL_VGA_DEVICE(0x3E94, info) /* Halo GT2 */ > > +#define INTEL_CFL_U_IDS(info) \ > + INTEL_VGA_DEVICE(0x3EA5, info), /* ULT GT3 */ \ > + INTEL_VGA_DEVICE(0x3EA6, info), /* ULT GT3 */ \ > + INTEL_VGA_DEVICE(0x3EA7, info), /* ULT GT3 */ \ > + INTEL_VGA_DEVICE(0x3EA8, info) /* ULT GT3 */ > + > #define INTEL_CFL_IDS(info) \ > INTEL_CFL_S_IDS(info), \ > - INTEL_CFL_H_IDS(info) > + INTEL_CFL_H_IDS(info), \ > + INTEL_CFL_U_IDS(info) > > #endif /* _I915_PCIIDS_H */ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib/cfl: Introduce Coffeelake platform definition.
patch merged. thanks for the review.
On Thu, 2017-06-29 at 10:35 -0700, Clint Taylor wrote:
> Identical to other platforms.
>
> Reviewed-by: Clinton Taylor
>
> On 06/29/2017 10:18 AM, Rodrigo Vivi wrote:
> > Coffeelake is a Intel® Processor containing Intel® HD Graphics
> > following Kabylake.
> >
> > It is Gen9 graphics based platform on top of CNP PCH.
> >
> > On following patches we will start adding PCI IDs and the
> > platform specific changes.
> >
> > Signed-off-by: Rodrigo Vivi
> > ---
> > lib/intel_chipset.h | 2 ++
> > lib/intel_device_info.c | 6 ++
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
> > index 259b45f..2468890 100644
> > --- a/lib/intel_chipset.h
> > +++ b/lib/intel_chipset.h
> > @@ -64,6 +64,7 @@ struct intel_device_info {
> > bool is_broxton : 1;
> > bool is_kabylake : 1;
> > bool is_geminilake : 1;
> > + bool is_coffeelake : 1;
> > const char *codename;
> > };
> >
> > @@ -158,6 +159,7 @@ void intel_check_pch(void);
> > #define IS_SKYLAKE(devid) (intel_get_device_info(devid)->is_skylake)
> > #define IS_BROXTON(devid) (intel_get_device_info(devid)->is_broxton)
> > #define IS_GEMINILAKE(devid)
> > (intel_get_device_info(devid)->is_geminilake)
> > +#define IS_COFFEELAKE(devid)
> > (intel_get_device_info(devid)->is_coffeelake)
> >
> > #define IS_GEN(devid, x) (intel_get_device_info(devid)->gen & (1u <<
> > ((x)-1)))
> > #define AT_LEAST_GEN(devid, x)(intel_get_device_info(devid)->gen &
> > -(1u << ((x)-1)))
> > diff --git a/lib/intel_device_info.c b/lib/intel_device_info.c
> > index 2b0658c..199fa2d 100644
> > --- a/lib/intel_device_info.c
> > +++ b/lib/intel_device_info.c
> > @@ -187,6 +187,12 @@ static const struct intel_device_info
> > intel_geminilake_info = {
> > .codename = "geminilake"
> > };
> >
> > +static const struct intel_device_info intel_coffeelake_info = {
> > + .gen = BIT(8),
> > + .is_coffeelake = true,
> > + .codename = "coffeelake"
> > +};
> > +
> > static const struct pci_id_match intel_device_match[] = {
> > INTEL_I810_IDS(&intel_i810_info),
> > INTEL_I815_IDS(&intel_i815_info),
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] Add support for subtest-specific documentation
On 2017-06-22 07:30 AM, Petri Latvala wrote:
The current documentation for tests is limited to a single string per
test binary. This patch adds support for documenting individual
subtests.
The syntax for subtest documentation is:
igt_subtest_documentation("Frob knobs to see if one of the "
"crossbeams will go out of skew on the "
"treadle.");
igt_subtest("knob-frobbing-askew")
test_frob();
or with a format string:
for_example_loop(e) {
igt_subtest_documentation_f("Frob %s to see if one of the "
"crossbeams will go out of skew on the "
"treadle.", e->readable_name);
igt_subtest_f("%s-frob-askew", e->name)
test_frob(e);
}
The documentation cannot be extracted from just comments, because
associating them with the correct subtest name will then require doing
pattern matching in the documentation generator, for subtests where
the name is generated at runtime using igt_subtest_f.
This patch does not hook the subtest documentation to the doc
building. It adds command line parameters for --document-all-subtests
and --document-subtest , but using them blindly without
parallelizing will cause the docs build time to rise too much.
Signed-off-by: Petri Latvala
Acked-by: Leo Li
---
lib/igt_aux.c | 8 ++--
lib/igt_core.c | 147 +
lib/igt_core.h | 6 ++-
3 files changed, 126 insertions(+), 35 deletions(-)
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index eb563f7..4796b01 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -311,7 +311,7 @@ static void sig_handler(int i)
*/
void igt_fork_signal_helper(void)
{
- if (igt_only_list_subtests())
+ if (igt_only_collect_data())
return;
/* We pick SIGCONT as it is a "safe" signal - if we send SIGCONT to
@@ -344,7 +344,7 @@ void igt_fork_signal_helper(void)
*/
void igt_stop_signal_helper(void)
{
- if (igt_only_list_subtests())
+ if (igt_only_collect_data())
return;
igt_stop_helper(&signal_helper);
@@ -375,7 +375,7 @@ static void __attribute__((noreturn))
shrink_helper_process(int fd, pid_t pid)
*/
void igt_fork_shrink_helper(int drm_fd)
{
- assert(!igt_only_list_subtests());
+ assert(!igt_only_collect_data());
igt_require(igt_drop_caches_has(drm_fd, DROP_SHRINK_ALL));
igt_fork_helper(&shrink_helper)
shrink_helper_process(drm_fd, getppid());
@@ -473,7 +473,7 @@ void igt_stop_hang_detector(void)
#else
void igt_fork_hang_detector(int fd)
{
- if (igt_only_list_subtests())
+ if (igt_only_collect_data())
return;
}
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 9a5ed40..0324382 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -98,7 +98,7 @@
*
* To allow this i-g-t provides #igt_fixture code blocks for setup code
outside
* of subtests and automatically skips the subtest code blocks themselves. For
- * special cases igt_only_list_subtests() is also provided. For setup code only
+ * special cases igt_only_collect_data() is also provided. For setup code only
* shared by a group of subtest encapsulate the #igt_fixture block and all the
* subtestest in a #igt_subtest_group block.
*
@@ -231,9 +231,9 @@ static unsigned int exit_handler_count;
const char *igt_interactive_debug;
/* subtests helpers */
-static bool list_subtests = false;
-static char *run_single_subtest = NULL;
-static bool run_single_subtest_found = false;
+static char *single_subtest = NULL;
+static bool single_subtest_found = false;
+static char *current_subtest_documentation = NULL;
static const char *in_subtest = NULL;
static struct timespec subtest_time;
static clockid_t igt_clock = (clockid_t)-1;
@@ -243,6 +243,13 @@ static bool in_atexit_handler = false;
static enum {
CONT = 0, SKIP, FAIL
} skip_subtests_henceforth = CONT;
+static enum {
+ EXECUTE_ALL,
+ EXECUTE_SINGLE,
+ LIST_SUBTESTS,
+ DOCUMENT,
+ DOCUMENT_SINGLE
+} runmode = EXECUTE_ALL;
bool __igt_plain_output = false;
@@ -255,6 +262,8 @@ bool test_child;
enum {
OPT_LIST_SUBTESTS,
OPT_RUN_SUBTEST,
+ OPT_DOC_SUBTESTS,
+ OPT_DOC_SINGLE_SUBTEST,
OPT_DESCRIPTION,
OPT_DEBUG,
OPT_INTERACTIVE_DEBUG,
@@ -441,7 +450,7 @@ bool __igt_fixture(void)
{
assert(!in_fixture);
- if (igt_only_list_subtests())
+ if (igt_only_collect_data())
return false;
if (skip_subtests_henceforth)
@@ -535,7 +544,7 @@ static void low_mem_killer_disable(bool disable)
bool igt_exit_called;
static void common_exit_handler(int sig)
{
- if (!igt_only_list_subtests()) {
+ if (!igt_only_collect_data()) {
low_mem_killer_disable(false);
kick_fbcon(true);
}
@@ -555,7 +564,7 @@ static void print_versi
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/skl+: Scaling not supported in IF-ID Interlace mode
On Thu, Jun 29, 2017 at 10:10:30PM +0530, Mahesh Kumar wrote:
> GEN9+ Interlace fetch mode doesn't support pipe/plane scaling,
> This patch adds check to fail the flip if pipe/plane scaling is
> requested in Interlace fetch mode.
>
> Changes since V1:
> - move check to skl_update_scaler (ville)
> - mode to adjusted_mode (ville)
> - combine pipe/plane scaling check
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/intel_display.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 4e03ca6c946f..4f4f3d4ac297 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4612,6 +4612,9 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
> bool force_detach,
> &crtc_state->scaler_state;
> struct intel_crtc *intel_crtc =
> to_intel_crtc(crtc_state->base.crtc);
> + struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
> + const struct drm_display_mode *adjusted_mode =
> + &crtc_state->base.adjusted_mode;
> int need_scaling;
>
> /*
> @@ -4621,6 +4624,13 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
> bool force_detach,
>*/
> need_scaling = src_w != dst_w || src_h != dst_h;
>
> + /* Scaling/fitting not supported in IF-ID mode in GEN9+ */
> + if (INTEL_GEN(dev_priv) >=9 && need_scaling && crtc_state->base.enable
> + && adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
Indentation is off, and we like to put the '&&' at the end of the
previous line rather than at the start of the new line.
> + DRM_DEBUG_KMS("Pipe/Plane scaling not supported with IF-ID
> mode\n");
> + return -EINVAL;
> + }
> +
> /*
>* if plane is being disabled or scaler is no more required or force
> detach
>* - free scaler binded to this plane/crtc
> --
> 2.13.0
--
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 1/2] drm/i915/skl+: Check for supported plane configuration in Interlace mode
On Thu, Jun 29, 2017 at 10:10:29PM +0530, Mahesh Kumar wrote:
> In Gen9 platform Interlaced fetch mode doesn't support following plane
> configuration:
> - Y/Yf tiling
> - 90/270 rotation
> - YUV420 hybrid planar source pixel formats.
>
> This patch adds check to fail the flip if any of the above configuration
> is requested.
>
> Changes since V1:
> - handle checks in intel_plane_atomic_check_with_state (ville)
> - takeout plane scaler checks, combine with pipe scaler in next patch
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 33
> +++
> 1 file changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 4325cb0a04f5..2b60a67c5393 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -114,6 +114,8 @@ int intel_plane_atomic_check_with_state(struct
> intel_crtc_state *crtc_state,
> struct drm_i915_private *dev_priv = to_i915(plane->dev);
> struct drm_plane_state *state = &intel_state->base;
> struct intel_plane *intel_plane = to_intel_plane(plane);
> + const struct drm_display_mode *adjusted_mode =
> + &crtc_state->base.adjusted_mode;
Indentation is off in several places. Pls fix your editor.
> int ret;
>
> /*
> @@ -173,6 +175,37 @@ int intel_plane_atomic_check_with_state(struct
> intel_crtc_state *crtc_state,
> if (ret)
> return ret;
>
> + /*
> + * Y-tiling is not supported in IF-ID Interlace mode in
> + * GEN9 and above.
> + * Scaling is not supported with Interlaced fetch mode.
> + * YUV420 hybrid planar source pixel formats are not supported with
> + * Interlaced fetch mode.
> + */
> + if (state->fb && INTEL_GEN(dev_priv) >= 9 && crtc_state->base.enable &&
> + adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
> + struct drm_framebuffer *fb = state->fb;
> + struct drm_format_name_buf format_name;
> +
> + if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
> + fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
> + DRM_DEBUG_KMS("Y/Yf tiling not supported in IF-ID
> mode\n");
> + return -EINVAL;
> + }
> +
> + switch (fb->format->format) {
> + case DRM_FORMAT_NV12:
> + case DRM_FORMAT_YUV420:
> + case DRM_FORMAT_YVU420:
Non-NV12 should be dropped, but actually I think you can drop this check
entirely since skl_update_scaler() will already reject NV12 since
that always needs a scaler.
> + DRM_DEBUG_KMS("Unsupported pixel format %s for IF-ID\n",
> + drm_get_format_name(fb->format->format,
> + &format_name));
> + return -EINVAL;
> + default:
> + break;
> + }
> + }
> +
> /* FIXME pre-g4x don't work like this */
> if (intel_state->base.visible)
> crtc_state->active_planes |= BIT(intel_plane->id);
> --
> 2.13.0
--
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 i-g-t] lib/cfl: Introduce Coffeelake platform definition.
Identical to other platforms.
Reviewed-by: Clinton Taylor
On 06/29/2017 10:18 AM, Rodrigo Vivi wrote:
Coffeelake is a Intel® Processor containing Intel® HD Graphics
following Kabylake.
It is Gen9 graphics based platform on top of CNP PCH.
On following patches we will start adding PCI IDs and the
platform specific changes.
Signed-off-by: Rodrigo Vivi
---
lib/intel_chipset.h | 2 ++
lib/intel_device_info.c | 6 ++
2 files changed, 8 insertions(+)
diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
index 259b45f..2468890 100644
--- a/lib/intel_chipset.h
+++ b/lib/intel_chipset.h
@@ -64,6 +64,7 @@ struct intel_device_info {
bool is_broxton : 1;
bool is_kabylake : 1;
bool is_geminilake : 1;
+ bool is_coffeelake : 1;
const char *codename;
};
@@ -158,6 +159,7 @@ void intel_check_pch(void);
#define IS_SKYLAKE(devid) (intel_get_device_info(devid)->is_skylake)
#define IS_BROXTON(devid) (intel_get_device_info(devid)->is_broxton)
#define IS_GEMINILAKE(devid) (intel_get_device_info(devid)->is_geminilake)
+#define IS_COFFEELAKE(devid) (intel_get_device_info(devid)->is_coffeelake)
#define IS_GEN(devid, x) (intel_get_device_info(devid)->gen & (1u << ((x)-1)))
#define AT_LEAST_GEN(devid, x)(intel_get_device_info(devid)->gen & -(1u
<< ((x)-1)))
diff --git a/lib/intel_device_info.c b/lib/intel_device_info.c
index 2b0658c..199fa2d 100644
--- a/lib/intel_device_info.c
+++ b/lib/intel_device_info.c
@@ -187,6 +187,12 @@ static const struct intel_device_info
intel_geminilake_info = {
.codename = "geminilake"
};
+static const struct intel_device_info intel_coffeelake_info = {
+ .gen = BIT(8),
+ .is_coffeelake = true,
+ .codename = "coffeelake"
+};
+
static const struct pci_id_match intel_device_match[] = {
INTEL_I810_IDS(&intel_i810_info),
INTEL_I815_IDS(&intel_i815_info),
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] dma-buf/sw-sync: Fix locking around sync_timeline lists
Quoting Sean Paul (2017-06-29 18:22:10)
> On Thu, Jun 29, 2017 at 01:59:29PM +0100, Chris Wilson wrote:
> > The sync_pt were not adding themselves atomically to the timeline lists,
> > corruption imminent. Only a single list is required to track the
> > unsignaled sync_pt, so reduce it and rename the lock more appropriately
> > along with using idiomatic names to distinguish a list from links along
> > it.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Sumit Semwal
> > Cc: Sean Paul
> > Cc: Gustavo Padovan
> > ---
> > drivers/dma-buf/sw_sync.c| 39 ++-
> > drivers/dma-buf/sync_debug.c | 9 -
> > drivers/dma-buf/sync_debug.h | 21 -
> > 3 files changed, 26 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
> > index 6effa1ce010e..e51fe11bbbea 100644
> > --- a/drivers/dma-buf/sw_sync.c
> > +++ b/drivers/dma-buf/sw_sync.c
> > @@ -96,9 +96,8 @@ static struct sync_timeline *sync_timeline_create(const
> > char *name)
> > obj->context = dma_fence_context_alloc(1);
> > strlcpy(obj->name, name, sizeof(obj->name));
> >
> > - INIT_LIST_HEAD(&obj->child_list_head);
> > - INIT_LIST_HEAD(&obj->active_list_head);
> > - spin_lock_init(&obj->child_list_lock);
> > + INIT_LIST_HEAD(&obj->pt_list);
> > + spin_lock_init(&obj->lock);
> >
> > sync_timeline_debug_add(obj);
> >
> > @@ -139,17 +138,15 @@ static void sync_timeline_signal(struct sync_timeline
> > *obj, unsigned int inc)
> >
> > trace_sync_timeline(obj);
> >
> > - spin_lock_irq(&obj->child_list_lock);
> > + spin_lock_irq(&obj->lock);
> >
> > obj->value += inc;
> >
> > - list_for_each_entry_safe(pt, next, &obj->active_list_head,
> > - active_list) {
> > + list_for_each_entry_safe(pt, next, &obj->pt_list, link)
> > if (dma_fence_is_signaled_locked(&pt->base))
> > - list_del_init(&pt->active_list);
> > - }
> > + list_del_init(&pt->link);
> >
> > - spin_unlock_irq(&obj->child_list_lock);
> > + spin_unlock_irq(&obj->lock);
> > }
> >
> > /**
> > @@ -171,15 +168,15 @@ static struct sync_pt *sync_pt_create(struct
> > sync_timeline *obj,
> > if (!pt)
> > return NULL;
> >
> > - spin_lock_irq(&obj->child_list_lock);
> > -
> > sync_timeline_get(obj);
> > - dma_fence_init(&pt->base, &timeline_fence_ops, &obj->child_list_lock,
> > + dma_fence_init(&pt->base, &timeline_fence_ops, &obj->lock,
> > obj->context, value);
> > - list_add_tail(&pt->child_list, &obj->child_list_head);
> > - INIT_LIST_HEAD(&pt->active_list);
> > + INIT_LIST_HEAD(&pt->link);
> >
> > - spin_unlock_irq(&obj->child_list_lock);
> > + spin_lock_irq(&obj->lock);
> > + if (!dma_fence_is_signaled_locked(&pt->base))
> > + list_add_tail(&pt->link, &obj->pt_list);
> > + spin_unlock_irq(&obj->lock);
> >
> > return pt;
> > }
> > @@ -204,9 +201,8 @@ static void timeline_fence_release(struct dma_fence
> > *fence)
> >
> > spin_lock_irqsave(fence->lock, flags);
> >
> > - list_del(&pt->child_list);
> > - if (!list_empty(&pt->active_list))
> > - list_del(&pt->active_list);
> > + if (!list_empty(&pt->link))
> > + list_del(&pt->link);
> >
> > spin_unlock_irqrestore(fence->lock, flags);
> >
> > @@ -223,13 +219,6 @@ static bool timeline_fence_signaled(struct dma_fence
> > *fence)
> >
> > static bool timeline_fence_enable_signaling(struct dma_fence *fence)
> > {
> > - struct sync_pt *pt = dma_fence_to_sync_pt(fence);
> > - struct sync_timeline *parent = dma_fence_parent(fence);
> > -
> > - if (timeline_fence_signaled(fence))
> > - return false;
> > -
> > - list_add_tail(&pt->active_list, &parent->active_list_head);
> > return true;
>
> Shouldn't you still return false if the fence is already signaled?
Yes/no :)
In this case, it is immaterial as the only way the timeline can advance
is underneath its big lock and by signaling all the fences. So by the
time dma_fence calls fence->ops->enable_signaling under that same lock
we already know that the fence isn't signaled and can't suddenly be
signaled in the middle of the function call.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] dma-buf/sw-sync: Fix locking around sync_timeline lists
On Thu, Jun 29, 2017 at 01:59:29PM +0100, Chris Wilson wrote:
> The sync_pt were not adding themselves atomically to the timeline lists,
> corruption imminent. Only a single list is required to track the
> unsignaled sync_pt, so reduce it and rename the lock more appropriately
> along with using idiomatic names to distinguish a list from links along
> it.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Sean Paul
> Cc: Gustavo Padovan
> ---
> drivers/dma-buf/sw_sync.c| 39 ++-
> drivers/dma-buf/sync_debug.c | 9 -
> drivers/dma-buf/sync_debug.h | 21 -
> 3 files changed, 26 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
> index 6effa1ce010e..e51fe11bbbea 100644
> --- a/drivers/dma-buf/sw_sync.c
> +++ b/drivers/dma-buf/sw_sync.c
> @@ -96,9 +96,8 @@ static struct sync_timeline *sync_timeline_create(const
> char *name)
> obj->context = dma_fence_context_alloc(1);
> strlcpy(obj->name, name, sizeof(obj->name));
>
> - INIT_LIST_HEAD(&obj->child_list_head);
> - INIT_LIST_HEAD(&obj->active_list_head);
> - spin_lock_init(&obj->child_list_lock);
> + INIT_LIST_HEAD(&obj->pt_list);
> + spin_lock_init(&obj->lock);
>
> sync_timeline_debug_add(obj);
>
> @@ -139,17 +138,15 @@ static void sync_timeline_signal(struct sync_timeline
> *obj, unsigned int inc)
>
> trace_sync_timeline(obj);
>
> - spin_lock_irq(&obj->child_list_lock);
> + spin_lock_irq(&obj->lock);
>
> obj->value += inc;
>
> - list_for_each_entry_safe(pt, next, &obj->active_list_head,
> - active_list) {
> + list_for_each_entry_safe(pt, next, &obj->pt_list, link)
> if (dma_fence_is_signaled_locked(&pt->base))
> - list_del_init(&pt->active_list);
> - }
> + list_del_init(&pt->link);
>
> - spin_unlock_irq(&obj->child_list_lock);
> + spin_unlock_irq(&obj->lock);
> }
>
> /**
> @@ -171,15 +168,15 @@ static struct sync_pt *sync_pt_create(struct
> sync_timeline *obj,
> if (!pt)
> return NULL;
>
> - spin_lock_irq(&obj->child_list_lock);
> -
> sync_timeline_get(obj);
> - dma_fence_init(&pt->base, &timeline_fence_ops, &obj->child_list_lock,
> + dma_fence_init(&pt->base, &timeline_fence_ops, &obj->lock,
> obj->context, value);
> - list_add_tail(&pt->child_list, &obj->child_list_head);
> - INIT_LIST_HEAD(&pt->active_list);
> + INIT_LIST_HEAD(&pt->link);
>
> - spin_unlock_irq(&obj->child_list_lock);
> + spin_lock_irq(&obj->lock);
> + if (!dma_fence_is_signaled_locked(&pt->base))
> + list_add_tail(&pt->link, &obj->pt_list);
> + spin_unlock_irq(&obj->lock);
>
> return pt;
> }
> @@ -204,9 +201,8 @@ static void timeline_fence_release(struct dma_fence
> *fence)
>
> spin_lock_irqsave(fence->lock, flags);
>
> - list_del(&pt->child_list);
> - if (!list_empty(&pt->active_list))
> - list_del(&pt->active_list);
> + if (!list_empty(&pt->link))
> + list_del(&pt->link);
>
> spin_unlock_irqrestore(fence->lock, flags);
>
> @@ -223,13 +219,6 @@ static bool timeline_fence_signaled(struct dma_fence
> *fence)
>
> static bool timeline_fence_enable_signaling(struct dma_fence *fence)
> {
> - struct sync_pt *pt = dma_fence_to_sync_pt(fence);
> - struct sync_timeline *parent = dma_fence_parent(fence);
> -
> - if (timeline_fence_signaled(fence))
> - return false;
> -
> - list_add_tail(&pt->active_list, &parent->active_list_head);
> return true;
Shouldn't you still return false if the fence is already signaled?
> }
>
> diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
> index 0e91632248ba..2264a075f6a9 100644
> --- a/drivers/dma-buf/sync_debug.c
> +++ b/drivers/dma-buf/sync_debug.c
> @@ -119,13 +119,12 @@ static void sync_print_obj(struct seq_file *s, struct
> sync_timeline *obj)
>
> seq_printf(s, "%s: %d\n", obj->name, obj->value);
>
> - spin_lock_irq(&obj->child_list_lock);
> - list_for_each(pos, &obj->child_list_head) {
> - struct sync_pt *pt =
> - container_of(pos, struct sync_pt, child_list);
> + spin_lock_irq(&obj->lock);
> + list_for_each(pos, &obj->pt_list) {
> + struct sync_pt *pt = container_of(pos, struct sync_pt, link);
> sync_print_fence(s, &pt->base, false);
> }
> - spin_unlock_irq(&obj->child_list_lock);
> + spin_unlock_irq(&obj->lock);
> }
>
> static void sync_print_sync_file(struct seq_file *s,
> diff --git a/drivers/dma-buf/sync_debug.h b/drivers/dma-buf/sync_debug.h
> index 26fe8b9907b3..899ba0e19fd3 100644
> --- a/drivers/dma-buf/sync_debug.h
> +++ b/drivers/dma-buf/sync_debug.h
> @@ -24,42 +24,37 @@
> * struct sync_timeline - sync
[Intel-gfx] [PATCH i-g-t] lib/cfl: Introduce Coffeelake platform definition.
Coffeelake is a Intel® Processor containing Intel® HD Graphics
following Kabylake.
It is Gen9 graphics based platform on top of CNP PCH.
On following patches we will start adding PCI IDs and the
platform specific changes.
Signed-off-by: Rodrigo Vivi
---
lib/intel_chipset.h | 2 ++
lib/intel_device_info.c | 6 ++
2 files changed, 8 insertions(+)
diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h
index 259b45f..2468890 100644
--- a/lib/intel_chipset.h
+++ b/lib/intel_chipset.h
@@ -64,6 +64,7 @@ struct intel_device_info {
bool is_broxton : 1;
bool is_kabylake : 1;
bool is_geminilake : 1;
+ bool is_coffeelake : 1;
const char *codename;
};
@@ -158,6 +159,7 @@ void intel_check_pch(void);
#define IS_SKYLAKE(devid) (intel_get_device_info(devid)->is_skylake)
#define IS_BROXTON(devid) (intel_get_device_info(devid)->is_broxton)
#define IS_GEMINILAKE(devid) (intel_get_device_info(devid)->is_geminilake)
+#define IS_COFFEELAKE(devid) (intel_get_device_info(devid)->is_coffeelake)
#define IS_GEN(devid, x) (intel_get_device_info(devid)->gen & (1u <<
((x)-1)))
#define AT_LEAST_GEN(devid, x) (intel_get_device_info(devid)->gen & -(1u <<
((x)-1)))
diff --git a/lib/intel_device_info.c b/lib/intel_device_info.c
index 2b0658c..199fa2d 100644
--- a/lib/intel_device_info.c
+++ b/lib/intel_device_info.c
@@ -187,6 +187,12 @@ static const struct intel_device_info
intel_geminilake_info = {
.codename = "geminilake"
};
+static const struct intel_device_info intel_coffeelake_info = {
+ .gen = BIT(8),
+ .is_coffeelake = true,
+ .codename = "coffeelake"
+};
+
static const struct pci_id_match intel_device_match[] = {
INTEL_I810_IDS(&intel_i810_info),
INTEL_I815_IDS(&intel_i815_info),
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for Handle unsupported configuration with IF-ID (rev2)
== Series Details == Series: Handle unsupported configuration with IF-ID (rev2) URL : https://patchwork.freedesktop.org/series/26546/ State : warning == Summary == Series 26546v2 Handle unsupported configuration with IF-ID https://patchwork.freedesktop.org/api/1.0/series/26546/revisions/2/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 Test kms_force_connector_basic: Subgroup force-connector-state: skip -> PASS (fi-snb-2520m) fdo#101048 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-byt-j1900) Test drv_module_reload: Subgroup basic-no-display: pass -> DMESG-WARN (fi-bdw-5557u) k.org#196219 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101048 https://bugs.freedesktop.org/show_bug.cgi?id=101048 k.org#196219 https://bugzilla.kernel.org/show_bug.cgi?id=196219 fi-bdw-5557u total:279 pass:264 dwarn:4 dfail:0 fail:0 skip:11 time:447s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:428s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:352s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:536s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:507s fi-byt-j1900 total:279 pass:253 dwarn:2 dfail:0 fail:0 skip:24 time:480s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:479s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:593s fi-hsw-4770 total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:435s fi-hsw-4770r total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:414s 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:489s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:474s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:461s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:568s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:584s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:558s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:458s fi-skl-6700hqtotal:279 pass:223 dwarn:1 dfail:0 fail:30 skip:24 time:342s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:469s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:483s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:543s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:404s f7d0276ea92c21303ea253af21cfff0778ed5a39 drm-tip: 2017y-06m-29d-15h-35m-54s UTC integration manifest a181b47 drm/i915/skl+: Scaling not supported in IF-ID Interlace mode d8610a7 drm/i915/skl+: Check for supported plane configuration in Interlace mode == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5074/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Skip i915_swizzle_info in platforms without GPU side swizzle
On 6/29/2017 6:07 AM, Chris Wilson wrote:
Quoting Ville Syrjälä (2017-06-29 14:05:25)
On Wed, Jun 28, 2017 at 04:24:27PM -0700, Michel Thierry wrote:
There's no need to keep reading random registers in i915_swizzle_info if
the platform is not doing GPU side swizzling.
After HSW, swizzling is not used, and the CPU's memory controller
performs all the address swizzling modifications, commit be292e1563ac5b
("drm/i915/bdw: Let the memory controller do all the swizzling").
But BDW still contains the registers and hardware capability no? So
might be a good idea to be able to check that it's not misconfigured.
Especially in debugfs where it is useful to show both the hw state and
what we thought it should be.
Hi,
Yes, the registers are still there (but this may change). Are you ok if
I change this to apply only to GEN9+?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/skl+: Check for supported plane configuration in Interlace mode
In Gen9 platform Interlaced fetch mode doesn't support following plane
configuration:
- Y/Yf tiling
- 90/270 rotation
- YUV420 hybrid planar source pixel formats.
This patch adds check to fail the flip if any of the above configuration
is requested.
Changes since V1:
- handle checks in intel_plane_atomic_check_with_state (ville)
- takeout plane scaler checks, combine with pipe scaler in next patch
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 33 +++
1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 4325cb0a04f5..2b60a67c5393 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -114,6 +114,8 @@ int intel_plane_atomic_check_with_state(struct
intel_crtc_state *crtc_state,
struct drm_i915_private *dev_priv = to_i915(plane->dev);
struct drm_plane_state *state = &intel_state->base;
struct intel_plane *intel_plane = to_intel_plane(plane);
+ const struct drm_display_mode *adjusted_mode =
+ &crtc_state->base.adjusted_mode;
int ret;
/*
@@ -173,6 +175,37 @@ int intel_plane_atomic_check_with_state(struct
intel_crtc_state *crtc_state,
if (ret)
return ret;
+ /*
+* Y-tiling is not supported in IF-ID Interlace mode in
+* GEN9 and above.
+* Scaling is not supported with Interlaced fetch mode.
+* YUV420 hybrid planar source pixel formats are not supported with
+* Interlaced fetch mode.
+*/
+ if (state->fb && INTEL_GEN(dev_priv) >= 9 && crtc_state->base.enable &&
+ adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
+ struct drm_framebuffer *fb = state->fb;
+ struct drm_format_name_buf format_name;
+
+ if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
+ fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
+ DRM_DEBUG_KMS("Y/Yf tiling not supported in IF-ID
mode\n");
+ return -EINVAL;
+ }
+
+ switch (fb->format->format) {
+ case DRM_FORMAT_NV12:
+ case DRM_FORMAT_YUV420:
+ case DRM_FORMAT_YVU420:
+ DRM_DEBUG_KMS("Unsupported pixel format %s for IF-ID\n",
+ drm_get_format_name(fb->format->format,
+ &format_name));
+ return -EINVAL;
+ default:
+ break;
+ }
+ }
+
/* FIXME pre-g4x don't work like this */
if (intel_state->base.visible)
crtc_state->active_planes |= BIT(intel_plane->id);
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915/skl+: Scaling not supported in IF-ID Interlace mode
GEN9+ Interlace fetch mode doesn't support pipe/plane scaling,
This patch adds check to fail the flip if pipe/plane scaling is
requested in Interlace fetch mode.
Changes since V1:
- move check to skl_update_scaler (ville)
- mode to adjusted_mode (ville)
- combine pipe/plane scaling check
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4e03ca6c946f..4f4f3d4ac297 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4612,6 +4612,9 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
&crtc_state->scaler_state;
struct intel_crtc *intel_crtc =
to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+ const struct drm_display_mode *adjusted_mode =
+ &crtc_state->base.adjusted_mode;
int need_scaling;
/*
@@ -4621,6 +4624,13 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
*/
need_scaling = src_w != dst_w || src_h != dst_h;
+ /* Scaling/fitting not supported in IF-ID mode in GEN9+ */
+ if (INTEL_GEN(dev_priv) >=9 && need_scaling && crtc_state->base.enable
+ && adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
+ DRM_DEBUG_KMS("Pipe/Plane scaling not supported with IF-ID
mode\n");
+ return -EINVAL;
+ }
+
/*
* if plane is being disabled or scaler is no more required or force
detach
* - free scaler binded to this plane/crtc
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/2] Handle unsupported configuration with IF-ID
Gen9+ Interlace fetch mode doesn't support few plane configurations & pipe scaling. - Y-tile - 90/270 rotation - pipe/plane scaling - 420 planar formats Changes since V1: - Address review comments from ville Mahesh Kumar (2): drm/i915/skl+: Check for supported plane configuration in Interlace mode drm/i915/skl+: Scaling not supported in IF-ID Interlace mode drivers/gpu/drm/i915/intel_atomic_plane.c | 33 +++ drivers/gpu/drm/i915/intel_display.c | 10 ++ 2 files changed, 43 insertions(+) -- 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 gen9+: Sanitize power well disabling during display uninit
== Series Details == Series: gen9+: Sanitize power well disabling during display uninit URL : https://patchwork.freedesktop.org/series/26566/ State : success == Summary == Series 26566v1 gen9+: Sanitize power well disabling during display uninit https://patchwork.freedesktop.org/api/1.0/series/26566/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 Test kms_force_connector_basic: Subgroup force-connector-state: skip -> PASS (fi-snb-2520m) fdo#101048 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-skl-6260u) fdo#100461 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101048 https://bugs.freedesktop.org/show_bug.cgi?id=101048 fdo#100461 https://bugs.freedesktop.org/show_bug.cgi?id=100461 fi-bdw-5557u total:279 pass:265 dwarn:3 dfail:0 fail:0 skip:11 time:440s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:427s 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:533s 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: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:259 dwarn:4 dfail:0 fail:0 skip:16 time:437s fi-hsw-4770r total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:411s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:420s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:501s 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:464s 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:578s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:554s fi-skl-6260u total:237 pass:229 dwarn:0 dfail:0 fail:0 skip:7 fi-skl-6700hqtotal:279 pass:223 dwarn:1 dfail:0 fail:30 skip:24 time:341s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:468s 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:434s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:545s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:400s f7d0276ea92c21303ea253af21cfff0778ed5a39 drm-tip: 2017y-06m-29d-15h-35m-54s UTC integration manifest 8ccc622 drm/i915/cnl: Fix comment about AUX IO power well enable/disable ad26976 drm/i915/gen9+: Don't remove secondary power well requests 007dcbf drm/i915/bxt, glk: Fix assert on conditions for DC9 enabling 9d07cb0 drm/i915/skl: Don't disable misc IO power well during display uninit 1db4f41 drm/i915/gen9+: Add 10 us delay after power well 1/AUX IO pw disabling == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5073/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Setting pch_id for HSW/BDW in virtual environment
On Thu, Jun 29, 2017 at 06:22:45PM +0300, Jani Nikula wrote:
> On Thu, 29 Jun 2017, Daniel Vetter wrote:
> > On Thu, Jun 15, 2017 at 11:11:45AM +0800, Xiong Zhang wrote:
> >> In a IGD passthrough environment, the real ISA bridge may doesn't exist.
> >> then pch_id couldn't be correctly gotten from ISA bridge, but pch_id is
> >> used to identify LPT_H and LPT_LP. Currently i915 treat all LPT pch as
> >> LPT_H,then errors occur when i915 runs on LPT_LP machines with igd
> >> passthrough.
> >>
> >> This patch set pch_id for HSW/BDW according to IGD type and isn't fully
> >> correct. But it solves such issue on HSW/BDW ult/ulx machines.
> >> QA CI system is blocked by this issue for a long time, it's better that
> >> we could merge it to unblock QA CI system.
> >>
> >> We know the root cause is in device model of virtual passthrough, and
> >> will resolve it in the future with several parts cooperation in kernel,
> >> qemu and xen.
> >>
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99938
> >>
> >> Signed-off-by: Xiong Zhang
> >> ---
> >> drivers/gpu/drm/i915/i915_drv.c | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> >> b/drivers/gpu/drm/i915/i915_drv.c
> >> index 1f802de..2e664c5 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.c
> >> +++ b/drivers/gpu/drm/i915/i915_drv.c
> >> @@ -135,6 +135,10 @@ static enum intel_pch intel_virt_detect_pch(struct
> >> drm_i915_private *dev_priv)
> >>DRM_DEBUG_KMS("Assuming CouarPoint PCH\n");
> >>} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> >>ret = PCH_LPT;
> >> + if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
> >> + dev_priv->pch_id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
> >> + else
> >> + dev_priv->pch_id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
> >
> > So it's imo silly that we're leaking the pch_id to our code when we
> > already have pch_type, but oh well.
>
> It's for distinguishing between LP and non-LP, which we need in the
> code, and why we have this patch in the first place.
I guess we could add separate pch_types for the LP variants. But I think
that'll just slightly shift the complexity between the
HAS_PCH/HAS_PCH_H/HAS_PCH_LP macros.
Or maybe we should just nuke pch_type?
>
> > Anyway, this is all about the physical pch on the chip, nothing to do with
> > the virtualized one, and we've been hard-coding these forever.
> >
> > Reviewed-by: Daniel Vetter
> >
> > Afaiui if this isn't true on a machine, someone used a solder iron to
> > build something that Intel doesn't sell.
>
> Bspec says there are (at least) non-ULT/ULX Broadwells with LP PCH. We
> do seem to warn about the combo in the bare metal PCH detection, so I
> guess it's safe to assume they are rare. But strictly speaking this
> change just moves problems from one setup to another.
>
> This has all been covered in the thread that I linked to in my previous
> reply, and all of that discussion has been conveniently overlooked and
> ignored in this patch submission and the commit message.
>
> I'm not opposed to merging the patch, but this needs to be documented
> for posterity.
>
> Of course, this gets *much* more complicated from SKL/SPT on, where the
> combos can be mixed even more freely (e.g. SKL+KBP and KBL+SPT).
Actually I'm not sure we have PCH_KBP since it seems to be identical
to SPT? We don't have PCH_PPT or PCH_WPT either. So IMO we should either
remove PCH_KBP or add PCH_PPT+PCH_WPT.
>
>
> BR,
> Jani.
>
>
>
> > -Daniel
> >
> >>DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
> >>} else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
> >>ret = PCH_SPT;
> >> --
> >> 2.7.4
> >>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 05/20] drm/i915: introduce page_size members
On 2017.06.29 12:59:08 +0100, Chris Wilson wrote: > Quoting Matthew Auld (2017-06-29 12:54:51) > > On 29 June 2017 at 07:36, Zhenyu Wang wrote: > > > We need to fallback to default supported page size when vGPU is active > > > (intel_vgpu_active() is true). > > > Currently gvt gtt handling can't support huge page entry yet, we need to > > > check either hypervisor > > > mm can support huge guest page or just do emulation in gvt. > > That should already be the case, since the guest doesn't support the > > 48b PPGTT. But it looks you are working to change that, so I guess we > > should just do this anyway? > yes, 48b ppgtt guest will be supported. > Fwiw, I think it makes sense just to sanitize the > mkwrite_intel_info()->page_sizes under virtualisation. Primarily to > document what we know does not work at the moment and so different > features can be enabled individually. I just thought the minimal code change to take that into account, as long as it's after vgpu active/feature detect, that's fine too. > Or just disable gvt :-p That reason is not strong enough I believe. ;) -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] gen9+: Sanitize power well disabling during display uninit
This patchset aligns the display uninit sequence with Bspec, wrt. to disabling power well 1 and the misc IO power well. It also tunes down a timeout WARN to be a debug message when waiting for power wells to get disabled while KVMR is active. Imre Deak (5): drm/i915/gen9+: Add 10 us delay after power well 1/AUX IO pw disabling drm/i915/skl: Don't disable misc IO power well during display uninit drm/i915/bxt,glk: Fix assert on conditions for DC9 enabling drm/i915/gen9+: Don't remove secondary power well requests drm/i915/cnl: Fix comment about AUX IO power well enable/disable drivers/gpu/drm/i915/intel_runtime_pm.c | 137 1 file changed, 85 insertions(+), 52 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915/bxt, glk: Fix assert on conditions for DC9 enabling
What we want to assert based on the conditions required by Bspec is that power well 2 is disabled, so no need to check for other power wells. In addition we can only check if the driver's request is removed, the actual state depends on whether the other request bits are set or not (BIOS, KVMR, DEBUG). So check only the driver's request bit. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index 8418879..1fc75e6 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -549,7 +549,9 @@ static void assert_can_enable_dc9(struct drm_i915_private *dev_priv) "DC9 already programmed to be enabled.\n"); WARN_ONCE(I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5, "DC5 still not disabled to enable DC9.\n"); - WARN_ONCE(I915_READ(HSW_PWR_WELL_DRIVER), "Power well on.\n"); + WARN_ONCE(I915_READ(HSW_PWR_WELL_DRIVER) & + SKL_POWER_WELL_REQ(SKL_DISP_PW_2), + "Power well 2 on.\n"); WARN_ONCE(intel_irqs_enabled(dev_priv), "Interrupts not disabled yet.\n"); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915/gen9+: Add 10 us delay after power well 1/AUX IO pw disabling
Bspec requires a 10 us delay after disabling power well 1 and - if not toggled on-demand - the AUX IO power wells during display uninit. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_runtime_pm.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index efe80ed..fd59016 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -2701,6 +2701,8 @@ static void skl_display_core_uninit(struct drm_i915_private *dev_priv) intel_power_well_disable(dev_priv, well); mutex_unlock(&power_domains->lock); + + usleep_range(10, 30); /* 10 us delay per Bspec */ } void bxt_display_core_init(struct drm_i915_private *dev_priv, @@ -2758,6 +2760,8 @@ void bxt_display_core_uninit(struct drm_i915_private *dev_priv) intel_power_well_disable(dev_priv, well); mutex_unlock(&power_domains->lock); + + usleep_range(10, 30); /* 10 us delay per Bspec */ } #define CNL_PROCMON_IDX(val) \ @@ -2859,6 +2863,8 @@ static void cnl_display_core_uninit(struct drm_i915_private *dev_priv) intel_power_well_disable(dev_priv, well); mutex_unlock(&power_domains->lock); + usleep_range(10, 30); /* 10 us delay per Bspec */ + /* 5. Disable Comp */ val = I915_READ(CHICKEN_MISC_2); val |= COMP_PWR_DOWN; -- 2.7.4 ___ 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 drm/i915: Avoid undefined behaviour of "u32 >> 32" (rev2)
Quoting Patchwork (2017-06-29 16:27:13) > == Series Details == > > Series: drm/i915: Avoid undefined behaviour of "u32 >> 32" (rev2) > URL : https://patchwork.freedesktop.org/series/26556/ > State : success > > == Summary == > > Series 26556v2 drm/i915: Avoid undefined behaviour of "u32 >> 32" > https://patchwork.freedesktop.org/api/1.0/series/26556/revisions/2/mbox/ > > Test gem_exec_flush: > Subgroup basic-batch-kernel-default-uc: > pass -> FAIL (fi-snb-2600) fdo#17 > Test gem_exec_suspend: > Subgroup basic-s4-devices: > dmesg-warn -> PASS (fi-kbl-r) fdo#100125 > Test kms_cursor_legacy: > Subgroup basic-busy-flip-before-cursor-atomic: > fail -> PASS (fi-snb-2600) fdo#100215 > Test kms_pipe_crc_basic: > Subgroup hang-read-crc-pipe-a: > dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 +1 > > fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 > fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 > fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 > fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 Hopefully this explains the weird overrun of eb->buckets[] Tomi reported in eb_add_vma() under tight memory conditions. Pushed, thanks for the review, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915/cnl: Fix comment about AUX IO power well enable/disable
The comments match an earlier version of the patch, fix them to match the current state. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index 2fe715b..5eb9c5e 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -2845,7 +2845,10 @@ static void cnl_display_core_init(struct drm_i915_private *dev_priv, bool resume val |= CL_POWER_DOWN_ENABLE; I915_WRITE(CNL_PORT_CL1CM_DW5, val); - /* 4. Enable Power Well 1 (PG1) and Aux IO Power */ + /* +* 4. Enable Power Well 1 (PG1). +*The AUX IO power wells will be enabled on demand. +*/ mutex_lock(&power_domains->lock); well = lookup_power_well(dev_priv, SKL_DISP_PW_1); intel_power_well_enable(dev_priv, well); @@ -2877,7 +2880,11 @@ static void cnl_display_core_uninit(struct drm_i915_private *dev_priv) /* 3. Disable CD clock */ cnl_uninit_cdclk(dev_priv); - /* 4. Disable Power Well 1 (PG1) and Aux IO Power */ + /* +* 4. Disable Power Well 1 (PG1). +*The AUX IO power wells are toggled on demand, so they are already +*disabled at this point. +*/ mutex_lock(&power_domains->lock); well = lookup_power_well(dev_priv, SKL_DISP_PW_1); intel_power_well_disable(dev_priv, well); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915/skl: Don't disable misc IO power well during display uninit
Bspec requires leaving the misc IO power well enabled during display uninit, so align the code accordingly. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_runtime_pm.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index fd59016..8418879 100644 --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -2694,9 +2694,10 @@ static void skl_display_core_uninit(struct drm_i915_private *dev_priv) mutex_lock(&power_domains->lock); - well = lookup_power_well(dev_priv, SKL_DISP_PW_MISC_IO); - intel_power_well_disable(dev_priv, well); - + /* +* BSpec says to keep the MISC IO power well enabled here, only +* remove our request for power well 1. +*/ well = lookup_power_well(dev_priv, SKL_DISP_PW_1); intel_power_well_disable(dev_priv, well); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915/gen9+: Don't remove secondary power well requests
So far in an attempt to make sure all power wells get disabled during
display uninitialization the driver removed any secondary request bits
(BIOS, KVMR, DEBUG) that were set for a given power well. The known
source for these requests was DMC's request on power well 1 and the misc
IO power well. Since DMC is inactive (DC states are disabled) at the
point we disable these power wells, there shouldn't be any reason to
leave them on. However there are two problems with the above
assumption: Bspec requires that the misc IO power well stays enabled
(without providing a reason) and there can be KVMR requests that we
can't remove anyway (the KVMR request register is R/O). Atm, a KVMR
request can trigger a timeout WARN when trying to disable power wells.
To make the code aligned to Bspec and to get rid of the KVMR WARN, don't
try to remove the secondary requests, only detect them and stop polling
for the power well disabled state when any one is set.
Also add a comment about the timeout values required by Bspec when
enabling power wells and the fact that waiting for them to get disabled
is not required by Bspec.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98564
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 109 ++--
1 file changed, 63 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 1fc75e6..2fe715b 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -341,6 +341,59 @@ static void skl_power_well_pre_disable(struct
drm_i915_private *dev_priv,
1 << PIPE_C | 1 << PIPE_B);
}
+static void gen9_wait_for_power_well_enable(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well)
+{
+ int id = power_well->id;
+
+ /* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
+ WARN_ON(intel_wait_for_register(dev_priv,
+ HSW_PWR_WELL_DRIVER,
+ SKL_POWER_WELL_STATE(id),
+ SKL_POWER_WELL_STATE(id),
+ 1));
+}
+
+static u32 gen9_power_well_requesters(struct drm_i915_private *dev_priv, int
id)
+{
+ u32 req_mask = SKL_POWER_WELL_REQ(id);
+ u32 ret;
+
+ ret = I915_READ(HSW_PWR_WELL_BIOS) & req_mask ? 1 : 0;
+ ret |= I915_READ(HSW_PWR_WELL_DRIVER) & req_mask ? 2 : 0;
+ ret |= I915_READ(HSW_PWR_WELL_KVMR) & req_mask ? 4 : 0;
+ ret |= I915_READ(HSW_PWR_WELL_DEBUG) & req_mask ? 8 : 0;
+
+ return ret;
+}
+
+static void gen9_wait_for_power_well_disable(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well)
+{
+ int id = power_well->id;
+ bool disabled;
+ u32 reqs;
+
+ /*
+* Bspec doesn't require waiting for PWs to get disabled, but still do
+* this for paranoia. The known cases where a PW will be forced on:
+* - a KVMR request on any power well via the KVMR request register
+* - a DMC request on PW1 and MISC_IO power wells via the BIOS and
+* DEBUG request registers
+* Skip the wait in case any of the request bits are set and print a
+* diagnostic message.
+*/
+ wait_for((disabled = !(I915_READ(HSW_PWR_WELL_DRIVER) &
+ SKL_POWER_WELL_STATE(id))) ||
+(reqs = gen9_power_well_requesters(dev_priv, id)), 1);
+ if (disabled)
+ return;
+
+ DRM_DEBUG_KMS("%s forced on (bios:%d driver:%d kvmr:%d debug:%d)\n",
+ power_well->name,
+ !!(reqs & 1), !!(reqs & 2), !!(reqs & 4), !!(reqs & 8));
+}
+
static void hsw_set_power_well(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well, bool enable)
{
@@ -746,45 +799,6 @@ void skl_disable_dc6(struct drm_i915_private *dev_priv)
gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
}
-static void
-gen9_sanitize_power_well_requests(struct drm_i915_private *dev_priv,
- struct i915_power_well *power_well)
-{
- enum skl_disp_power_wells power_well_id = power_well->id;
- u32 val;
- u32 mask;
-
- mask = SKL_POWER_WELL_REQ(power_well_id);
-
- val = I915_READ(HSW_PWR_WELL_KVMR);
- if (WARN_ONCE(val & mask, "Clearing unexpected KVMR request for %s\n",
- power_well->name))
- I915_WRITE(HSW_PWR_WELL_KVMR, val & ~mask);
-
- val = I915_READ(HSW_PWR_WELL_BIOS);
- val |= I915_READ(HSW_PWR_WELL_DEBUG);
-
- if (!(val & mask))
- return;
-
- /*
-* DMC is known to force on the request bits for power well 1 on SKL
-* and BXT and the misc IO po
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid undefined behaviour of "u32 >> 32" (rev2)
== Series Details == Series: drm/i915: Avoid undefined behaviour of "u32 >> 32" (rev2) URL : https://patchwork.freedesktop.org/series/26556/ State : success == Summary == Series 26556v2 drm/i915: Avoid undefined behaviour of "u32 >> 32" https://patchwork.freedesktop.org/api/1.0/series/26556/revisions/2/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-r) fdo#100125 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 +1 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fi-bdw-5557u total:279 pass:264 dwarn:4 dfail:0 fail:0 skip:11 time:440s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:428s 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:535s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:506s 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:478s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:600s fi-hsw-4770 total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:437s fi-hsw-4770r total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:415s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:425s 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:475s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:468s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:566s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:581s 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:223 dwarn:1 dfail:0 fail:30 skip:24 time:351s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:461s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:476s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:433s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:409s ee2da0ac24fb8d50a03b263eb1fa2e82849eda95 drm-tip: 2017y-06m-29d-13h-14m-49s UTC integration manifest ef84925 drm/i915: Avoid undefined behaviour of "u32 >> 32" == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5072/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Setting pch_id for HSW/BDW in virtual environment
On Thu, 29 Jun 2017, Daniel Vetter wrote:
> On Thu, Jun 15, 2017 at 11:11:45AM +0800, Xiong Zhang wrote:
>> In a IGD passthrough environment, the real ISA bridge may doesn't exist.
>> then pch_id couldn't be correctly gotten from ISA bridge, but pch_id is
>> used to identify LPT_H and LPT_LP. Currently i915 treat all LPT pch as
>> LPT_H,then errors occur when i915 runs on LPT_LP machines with igd
>> passthrough.
>>
>> This patch set pch_id for HSW/BDW according to IGD type and isn't fully
>> correct. But it solves such issue on HSW/BDW ult/ulx machines.
>> QA CI system is blocked by this issue for a long time, it's better that
>> we could merge it to unblock QA CI system.
>>
>> We know the root cause is in device model of virtual passthrough, and
>> will resolve it in the future with several parts cooperation in kernel,
>> qemu and xen.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99938
>>
>> Signed-off-by: Xiong Zhang
>> ---
>> drivers/gpu/drm/i915/i915_drv.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 1f802de..2e664c5 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -135,6 +135,10 @@ static enum intel_pch intel_virt_detect_pch(struct
>> drm_i915_private *dev_priv)
>> DRM_DEBUG_KMS("Assuming CouarPoint PCH\n");
>> } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
>> ret = PCH_LPT;
>> +if (IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv))
>> +dev_priv->pch_id = INTEL_PCH_LPT_LP_DEVICE_ID_TYPE;
>> +else
>> +dev_priv->pch_id = INTEL_PCH_LPT_DEVICE_ID_TYPE;
>
> So it's imo silly that we're leaking the pch_id to our code when we
> already have pch_type, but oh well.
It's for distinguishing between LP and non-LP, which we need in the
code, and why we have this patch in the first place.
> Anyway, this is all about the physical pch on the chip, nothing to do with
> the virtualized one, and we've been hard-coding these forever.
>
> Reviewed-by: Daniel Vetter
>
> Afaiui if this isn't true on a machine, someone used a solder iron to
> build something that Intel doesn't sell.
Bspec says there are (at least) non-ULT/ULX Broadwells with LP PCH. We
do seem to warn about the combo in the bare metal PCH detection, so I
guess it's safe to assume they are rare. But strictly speaking this
change just moves problems from one setup to another.
This has all been covered in the thread that I linked to in my previous
reply, and all of that discussion has been conveniently overlooked and
ignored in this patch submission and the commit message.
I'm not opposed to merging the patch, but this needs to be documented
for posterity.
Of course, this gets *much* more complicated from SKL/SPT on, where the
combos can be mixed even more freely (e.g. SKL+KBP and KBL+SPT).
BR,
Jani.
> -Daniel
>
>> DRM_DEBUG_KMS("Assuming LynxPoint PCH\n");
>> } else if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
>> ret = PCH_SPT;
>> --
>> 2.7.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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] ✓ Fi.CI.BAT: success for drm/i915: Fix pre-g4x GPU reset, again
On Thu, Jun 29, 2017 at 02:24:21PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Fix pre-g4x GPU reset, again > URL : https://patchwork.freedesktop.org/series/26554/ > State : success > > == Summary == > > Series 26554v1 drm/i915: Fix pre-g4x GPU reset, again > https://patchwork.freedesktop.org/api/1.0/series/26554/revisions/1/mbox/ > > Test gem_exec_suspend: > Subgroup basic-s4-devices: > pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 > Test gem_ringfill: > Subgroup basic-default-hang: > dmesg-warn -> PASS (fi-blb-e6850) fdo#101600 +1 > Test kms_cursor_legacy: > Subgroup basic-busy-flip-before-cursor-atomic: > fail -> PASS (fi-snb-2600) fdo#100215 > Test kms_pipe_crc_basic: > Subgroup hang-read-crc-pipe-b: > pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 [ 484.554418] drm/i915: Resetting chip after gpu hang [ 484.723084] pipe B vblank wait timed out [ 484.723168] [ cut here ] [ 484.723303] WARNING: CPU: 3 PID: 3484 at drivers/gpu/drm/i915/intel_display.c:12906 __intel_atomic_commit_tail+0x101e/0x1050 [i915] And it seems to have happened for pipe A as well. So far I can't reproduce this on the Lenovo Ideapan PNV I have on my desk. > Subgroup suspend-read-crc-pipe-b: > dmesg-warn -> PASS (fi-byt-n2820) fdo#101517 > > fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 > fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 > fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 > fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 > fdo#101517 https://bugs.freedesktop.org/show_bug.cgi?id=101517 > > fi-bdw-5557u total:279 pass:264 dwarn:4 dfail:0 fail:0 skip:11 > time:448s > fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 > time:429s > fi-blb-e6850 total:279 pass:225 dwarn:0 dfail:0 fail:0 skip:54 > time:354s > fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 > time:530s > fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:512s > fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 > time:485s > fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 > time:495s > fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 > time:602s > fi-hsw-4770 total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 > time:433s > fi-hsw-4770r total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 > time:415s > 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:492s > fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:476s > fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 > time:465s > fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 > time:570s > fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 > time:581s > fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 > time:554s > fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:461s > fi-skl-6700hqtotal:279 pass:223 dwarn:1 dfail:0 fail:30 skip:24 > time:340s > fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 > time:463s > fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 > time:476s > fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 > time:437s > 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:405s > > ee2da0ac24fb8d50a03b263eb1fa2e82849eda95 drm-tip: 2017y-06m-29d-13h-14m-49s > UTC integration manifest > d37cc43 drm/i915: Solve the GPU reset vs. modeset deadlocks with an > rw_semaphore > e6e3d92 drm/i915: Refactor __intel_atomic_commit_tail() > c33eea0 drm/i915% Store vma gtt offset in plane state > 5ab92c4 drm/atomic: Introduce drm_atomic_helper_duplicate_committed_state() > 988bc43 drm/atomic: Refactor drm_atomic_state_realloc_connectors() > > == Logs == > > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5069/ -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Avoid undefined behaviour of "u32 >> 32"
When computing a hash for looking up relcoation target handles in an
execbuf, we start with a large size for the hashtable and proceed to
reduce it until the allocation suceeds. The final attempt is with an
order of 0 (i.e. a single element). This means that we then pass bits=0
to hash_32() which then computes "hash >> (32 - 0)" to lookup the single
element. Right shifting by a value the width of the operand is
undefined, so limit the smallest hash table we use to order 1.
v2: Keep the retry allocation flag for the final pass
Fixes: 4ff4b44cbb70 ("drm/i915: Store a direct lookup from object handle to
vma")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 38 +++---
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 718bb75ad387..b9cee8e37fb0 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -288,20 +288,26 @@ static int eb_create(struct i915_execbuffer *eb)
* direct lookup.
*/
do {
+ unsigned int flags;
+
+ /* While we can still reduce the allocation size, don't
+* raise a warning and allow the allocation to fail.
+* On the last pass though, we want to try as hard
+* as possible to perform the allocation and warn
+* if it fails.
+*/
+ flags = GFP_TEMPORARY;
+ if (size > 1)
+ flags |=__GFP_NORETRY | __GFP_NOWARN;
+
eb->buckets = kzalloc(sizeof(struct hlist_head) << size,
- GFP_TEMPORARY |
- __GFP_NORETRY |
- __GFP_NOWARN);
+ flags);
if (eb->buckets)
break;
} while (--size);
- if (unlikely(!eb->buckets)) {
- eb->buckets = kzalloc(sizeof(struct hlist_head),
- GFP_TEMPORARY);
- if (unlikely(!eb->buckets))
- return -ENOMEM;
- }
+ if (unlikely(!eb->buckets))
+ return -ENOMEM;
eb->lut_size = size;
} else {
@@ -453,7 +459,7 @@ eb_add_vma(struct i915_execbuffer *eb,
return err;
}
- if (eb->lut_size >= 0) {
+ if (eb->lut_size > 0) {
vma->exec_handle = entry->handle;
hlist_add_head(&vma->exec_node,
&eb->buckets[hash_32(entry->handle,
@@ -897,7 +903,7 @@ static void eb_release_vmas(const struct i915_execbuffer
*eb)
static void eb_reset_vmas(const struct i915_execbuffer *eb)
{
eb_release_vmas(eb);
- if (eb->lut_size >= 0)
+ if (eb->lut_size > 0)
memset(eb->buckets, 0,
sizeof(struct hlist_head) << eb->lut_size);
}
@@ -906,7 +912,7 @@ static void eb_destroy(const struct i915_execbuffer *eb)
{
GEM_BUG_ON(eb->reloc_cache.rq);
- if (eb->lut_size >= 0)
+ if (eb->lut_size > 0)
kfree(eb->buckets);
}
@@ -2185,8 +2191,11 @@ i915_gem_do_execbuffer(struct drm_device *dev,
}
}
- if (eb_create(&eb))
- return -ENOMEM;
+ err = eb_create(&eb);
+ if (err)
+ goto err_out_fence;
+
+ GEM_BUG_ON(!eb.lut_size);
err = eb_select_context(&eb);
if (unlikely(err))
@@ -2346,6 +2355,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
i915_gem_context_put(eb.ctx);
err_destroy:
eb_destroy(&eb);
+err_out_fence:
if (out_fence_fd != -1)
put_unused_fd(out_fence_fd);
err_in_fence:
--
2.13.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid undefined behaviour of "u32 >> 32"
Quoting Tvrtko Ursulin (2017-06-29 15:50:17)
>
> On 29/06/2017 14:49, Chris Wilson wrote:
> > When computing a hash for looking up relcoation target handles in an
> > execbuf, we start with a large size for the hashtable and proceed to
> > reduce it until the allocation suceeds. The final attempt is with an
> > order of 0 (i.e. a single element). This means that we then pass bits=0
> > to hash_32() which then computes "hash >> (32 - 0)" to lookup the single
> > element. Right shifting by a value the width of the operand is
> > undefined, so limit the smallest hash table we use to order 1.
> >
> > Fixes: 4ff4b44cbb70 ("drm/i915: Store a direct lookup from object handle to
> > vma")
> > Signed-off-by: Chris Wilson
> > Cc: Joonas Lahtinen
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 22 +++---
> > 1 file changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 718bb75ad387..54791bcb8ccb 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -296,12 +296,8 @@ static int eb_create(struct i915_execbuffer *eb)
> > break;
> > } while (--size);
> >
> > - if (unlikely(!eb->buckets)) {
> > - eb->buckets = kzalloc(sizeof(struct hlist_head),
> > - GFP_TEMPORARY);
>
> Want to maybe drop the NORETRY | NOWARN from the remaining allocation
> now? Wasn't it recently discussed that it is to feeble in it's attempts
> to allocate?
True that was the point of the allocate afterwards, so that we could do
it with the retry flags. Time for a respin.
-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 drm/i915: Fix pre-g4x GPU reset, again (rev2)
== Series Details == Series: drm/i915: Fix pre-g4x GPU reset, again (rev2) URL : https://patchwork.freedesktop.org/series/26554/ State : success == Summary == Series 26554v2 drm/i915: Fix pre-g4x GPU reset, again https://patchwork.freedesktop.org/api/1.0/series/26554/revisions/2/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 Test gem_ringfill: Subgroup basic-default-hang: dmesg-warn -> PASS (fi-blb-e6850) fdo#101600 +1 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 +1 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fi-bdw-5557u total:279 pass:264 dwarn:4 dfail:0 fail:0 skip:11 time:442s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:435s fi-blb-e6850 total:279 pass:225 dwarn:0 dfail:0 fail:0 skip:54 time:346s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:528s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:513s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:488s 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:596s fi-hsw-4770 total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:434s fi-hsw-4770r total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:414s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:420s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:505s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:474s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:471s 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:582s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:553s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:457s fi-skl-6700hqtotal:279 pass:223 dwarn:1 dfail:0 fail:30 skip:24 time:349s 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:475s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:436s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:543s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:402s ee2da0ac24fb8d50a03b263eb1fa2e82849eda95 drm-tip: 2017y-06m-29d-13h-14m-49s UTC integration manifest d25f19a drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore 8b50bb0 drm/i915: Refactor __intel_atomic_commit_tail() 37b6e58 drm/i915% Store vma gtt offset in plane state f385b63 drm/atomic: Introduce drm_atomic_helper_duplicate_committed_state() 1b8f5ad drm/atomic: Refactor drm_atomic_state_realloc_connectors() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5071/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl+: Pipe scaling not supported in IF-ID Interlace mode
Hi,
On Thursday 29 June 2017 07:46 PM, Ville Syrjälä wrote:
On Thu, Jun 29, 2017 at 02:27:40PM +0530, Mahesh Kumar wrote:
GEN9+ Interlace fetch mode doesn't support pipe scaling,
This patch adds check to fail the flip if pipe scaling is requested in
Interlace fetch mode.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_atomic.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 36d4e635e4ce..a1206d4f9a23 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -224,6 +224,7 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
struct intel_crtc_scaler_state *scaler_state =
&crtc_state->scaler_state;
struct drm_atomic_state *drm_state = crtc_state->base.state;
+ const struct drm_display_mode *mode = &crtc_state->base.adjusted_mode;
"adjusted_mode"
ok
int num_scalers_need;
int i, j;
@@ -248,6 +249,13 @@ int intel_atomic_setup_scalers(struct drm_i915_private *dev_priv,
return -EINVAL;
}
+ /* Scaling/fitting not supported in IF-ID mode in GEN9+ */
+ if (INTEL_GEN(dev_priv) >=9 && mode->flags & DRM_MODE_FLAG_INTERLACE &&
+ scaler_state->scaler_users & (1 << SKL_CRTC_INDEX)) {
+ DRM_DEBUG_KMS("Pipe Scaling not supported with IF-ID mode\n");
+ return -EINVAL;
+ }
Hmm. I think if you put this into skl_update_scaler() then it'll catch
both pipe and plane scalers for you automagically.
will update.
-Mahesh
+
/* walkthrough scaler_users bits and start assigning scalers */
for (i = 0; i < sizeof(scaler_state->scaler_users) * 8; i++) {
int *scaler_id;
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid undefined behaviour of "u32 >> 32"
On 29/06/2017 14:49, Chris Wilson wrote:
When computing a hash for looking up relcoation target handles in an
execbuf, we start with a large size for the hashtable and proceed to
reduce it until the allocation suceeds. The final attempt is with an
order of 0 (i.e. a single element). This means that we then pass bits=0
to hash_32() which then computes "hash >> (32 - 0)" to lookup the single
element. Right shifting by a value the width of the operand is
undefined, so limit the smallest hash table we use to order 1.
Fixes: 4ff4b44cbb70 ("drm/i915: Store a direct lookup from object handle to
vma")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 718bb75ad387..54791bcb8ccb 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -296,12 +296,8 @@ static int eb_create(struct i915_execbuffer *eb)
break;
} while (--size);
- if (unlikely(!eb->buckets)) {
- eb->buckets = kzalloc(sizeof(struct hlist_head),
- GFP_TEMPORARY);
Want to maybe drop the NORETRY | NOWARN from the remaining allocation
now? Wasn't it recently discussed that it is to feeble in it's attempts
to allocate?
- if (unlikely(!eb->buckets))
- return -ENOMEM;
- }
+ if (unlikely(!eb->buckets))
+ return -ENOMEM;
eb->lut_size = size;
} else {
@@ -453,7 +449,7 @@ eb_add_vma(struct i915_execbuffer *eb,
return err;
}
- if (eb->lut_size >= 0) {
+ if (eb->lut_size > 0) {
vma->exec_handle = entry->handle;
hlist_add_head(&vma->exec_node,
&eb->buckets[hash_32(entry->handle,
@@ -897,7 +893,7 @@ static void eb_release_vmas(const struct i915_execbuffer
*eb)
static void eb_reset_vmas(const struct i915_execbuffer *eb)
{
eb_release_vmas(eb);
- if (eb->lut_size >= 0)
+ if (eb->lut_size > 0)
memset(eb->buckets, 0,
sizeof(struct hlist_head) << eb->lut_size);
}
@@ -906,7 +902,7 @@ static void eb_destroy(const struct i915_execbuffer *eb)
{
GEM_BUG_ON(eb->reloc_cache.rq);
- if (eb->lut_size >= 0)
+ if (eb->lut_size > 0)
kfree(eb->buckets);
}
@@ -2185,8 +2181,11 @@ i915_gem_do_execbuffer(struct drm_device *dev,
}
}
- if (eb_create(&eb))
- return -ENOMEM;
+ err = eb_create(&eb);
+ if (err)
+ goto err_out_fence;
+
+ GEM_BUG_ON(!eb.lut_size);
err = eb_select_context(&eb);
if (unlikely(err))
@@ -2346,6 +2345,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
i915_gem_context_put(eb.ctx);
err_destroy:
eb_destroy(&eb);
+err_out_fence:
if (out_fence_fd != -1)
put_unused_fd(out_fence_fd);
err_in_fence:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
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: Avoid undefined behaviour of "u32 >> 32"
== Series Details == Series: drm/i915: Avoid undefined behaviour of "u32 >> 32" URL : https://patchwork.freedesktop.org/series/26556/ State : success == Summary == Series 26556v1 drm/i915: Avoid undefined behaviour of "u32 >> 32" https://patchwork.freedesktop.org/api/1.0/series/26556/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fi-bdw-5557u total:279 pass:264 dwarn:4 dfail:0 fail:0 skip:11 time:438s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:429s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:351s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:529s 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:491s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:484s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:596s fi-hsw-4770 total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:431s fi-hsw-4770r total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:413s 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:502s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:477s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:462s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:574s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:577s fi-pnv-d510 total:279 pass:221 dwarn:3 dfail:0 fail:0 skip:55 time:558s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:470s fi-skl-6700hqtotal:279 pass:223 dwarn:1 dfail:0 fail:30 skip:24 time:342s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:464s 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:435s 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:409s ee2da0ac24fb8d50a03b263eb1fa2e82849eda95 drm-tip: 2017y-06m-29d-13h-14m-49s UTC integration manifest dc1d4ae drm/i915: Avoid undefined behaviour of "u32 >> 32" == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5070/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
From: Ville Syrjälä
Introduce an rw_semaphore to protect the display commits. All normal
commits use down_read() and hence can proceed in parallel, but GPU reset
will use down_write() making sure no other commits are in progress when
we have to pull the plug on the display engine on pre-g4x platforms.
There are no modeset/gem locks taken inside __intel_atomic_commit_tail()
itself, and we wait for all dependencies before the down_read(), and
thus there is no chance of deadlocks with this scheme.
During reset we should be recommiting the state that was committed last.
But for now we'll settle for recommiting the last state for each object.
Hence we may commit things a bit too soon when a GPU reset occurs. The
rw_semaphore should guarantee that whatever state we observe in
obj->state during reset sticks around while we do the commit. The
obj->state pointer might change for some objects if another swap_state()
occurs while we do our thing, so there migth be some theoretical
mismatch which I tink we could avoid by grabbing the rw_semaphore also
around the swap_state(), but for now I didn't do that.
Another source of mismatch can happen because we sometimes use the
intel_crtc->config during the actual commit, and that only gets updated
when we do the commuit. Hence we may get some state via ->state, some
via the duplicated ->state, and some via ->config. We'll want to
fix this all by tracking the commited state properly, but that will
some bigger refactroing so for now we'll just choose to accept these
potential mismatches.
I left out the state readout from the post-reset display
reinitialization as that still likes to clobber crtc->state etc.
If we make it use a free standing atomic state and mke sure it doesn't
need any locks we could reintroduce it. For now I just mark the
post-reset display state as dirty as possible to make sure we
reinitialize everything.
One other potential issue remains in the form of display detection.
Either we need to protect that with the same rw_semaphore as well, or
perhaps it would be enough to force gmbus into bitbanging mode while
the reset is happening and we don't have interrupts, and just across
the actual hardware GPU reset we could hold the gmbus mutex.
v2: Keep intel_prepare/finish_reset() outside struct_mutex (Chris)
v3: Drop all the committed_state refactoring to make this less
obnoxious to backport (Daniel)
v4: Preserve the wedge timeout mechanism (Chris)
Cc: # for the brave
Cc: Daniel Vetter
Cc: Chris Wilson
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101597
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99093
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101600
Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for
request completion")
Fixes: 221fe7994554 ("drm/i915: Perform a direct reset of the GPU from the
waiter")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_display.c | 199 ---
2 files changed, 138 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index effbe4f72a64..88ddd27f61b0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2237,6 +2237,8 @@ struct drm_i915_private {
struct drm_atomic_state *modeset_restore_state;
struct drm_modeset_acquire_ctx reset_ctx;
+ struct rw_semaphore commit_sem;
+
struct list_head vm_list; /* Global list of all address spaces */
struct i915_ggtt ggtt; /* VM representing the global address space */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7cdd6ec97f80..f13c7d81d4a9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -123,6 +123,7 @@ static void ironlake_pfit_enable(struct intel_crtc *crtc);
static void intel_modeset_setup_hw_state(struct drm_device *dev,
struct drm_modeset_acquire_ctx *ctx);
static void intel_pre_disable_primary_noatomic(struct drm_crtc *crtc);
+static void __intel_atomic_commit_tail(struct drm_atomic_state *state, bool
is_reset);
struct intel_limit {
struct {
@@ -3491,27 +3492,85 @@ static bool gpu_reset_clobbers_display(struct
drm_i915_private *dev_priv)
INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv);
}
-void intel_prepare_reset(struct drm_i915_private *dev_priv)
+static void init_intel_state(struct intel_atomic_state *state)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ int i;
+
+ state->modeset = true;
+
+ for_each_oldnew_crtc_in_state(&state->base, crtc,
+ old_crtc_state, new_crtc_state, i) {
+ if (new_crtc_state->active)
+ state->active_crtcs |= 1 << i;
+ else
+ state
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix pre-g4x GPU reset, again
== Series Details == Series: drm/i915: Fix pre-g4x GPU reset, again URL : https://patchwork.freedesktop.org/series/26554/ State : success == Summary == Series 26554v1 drm/i915: Fix pre-g4x GPU reset, again https://patchwork.freedesktop.org/api/1.0/series/26554/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 Test gem_ringfill: Subgroup basic-default-hang: dmesg-warn -> PASS (fi-blb-e6850) fdo#101600 +1 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-n2820) fdo#101517 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fdo#101517 https://bugs.freedesktop.org/show_bug.cgi?id=101517 fi-bdw-5557u total:279 pass:264 dwarn:4 dfail:0 fail:0 skip:11 time:448s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:429s fi-blb-e6850 total:279 pass:225 dwarn:0 dfail:0 fail:0 skip:54 time:354s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:530s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:512s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:485s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:495s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:602s fi-hsw-4770 total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:433s fi-hsw-4770r total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:415s 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:492s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:465s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:570s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:581s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:554s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:461s fi-skl-6700hqtotal:279 pass:223 dwarn:1 dfail:0 fail:30 skip:24 time:340s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:463s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:476s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:437s 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:405s ee2da0ac24fb8d50a03b263eb1fa2e82849eda95 drm-tip: 2017y-06m-29d-13h-14m-49s UTC integration manifest d37cc43 drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore e6e3d92 drm/i915: Refactor __intel_atomic_commit_tail() c33eea0 drm/i915% Store vma gtt offset in plane state 5ab92c4 drm/atomic: Introduce drm_atomic_helper_duplicate_committed_state() 988bc43 drm/atomic: Refactor drm_atomic_state_realloc_connectors() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5069/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Add missing drm_atomic_state_clear to atomic_remove_fb
On Thu, Jun 29, 2017 at 04:57:25PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
> > Signed-off-by: Maarten Lankhorst
> > ---
> > drivers/gpu/drm/drm_framebuffer.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > b/drivers/gpu/drm/drm_framebuffer.c
> > index fc8ef42203ec..b3ef4f1c2630 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -832,6 +832,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
> > drm_atomic_clean_old_fb(dev, plane_mask, ret);
> >
> > if (ret == -EDEADLK) {
> > + drm_atomic_state_clear(state);
>
> Hmm. We seem to be missing this all over. Do those other places need it
> as well? Hard to say without a commit message explaining why we need it
> here.
>
> Should we just back it into drm_modeset_backoff() if it's always needed?
s/back/bake/
>
> > drm_modeset_backoff(&ctx);
> > goto retry;
> > }
> > --
> > 2.11.0
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 1/2] drm/i915/skl+: Check for supported plane configuration in Interlace mode
Hi,
On Thursday 29 June 2017 07:36 PM, Ville Syrjälä wrote:
On Thu, Jun 29, 2017 at 02:27:39PM +0530, Mahesh Kumar wrote:
In Gen9 platform Interlaced fetch mode doesn't support following plane
configuration:
- Y/Yf tiling
- 90/270 rotation
- Scaling
- YUV420 hybrid planar source pixel formats.
This patch adds check to fail the flip if any of the above configuration
is requested.
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_display.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4e03ca6c946f..1f2394a0c07d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11022,6 +11022,7 @@ int intel_plane_atomic_calc_changes(struct
drm_crtc_state *crtc_state,
calc_changes seems like the wrong place for this.
intel_plane_atomic_check_with_state() seems better.
ok, will move it to intel_plane_atomic_check_with_state()
bool is_crtc_enabled = crtc_state->active;
bool turn_off, turn_on, visible, was_visible;
struct drm_framebuffer *fb = plane_state->fb;
+ const struct drm_display_mode *mode = &crtc_state->adjusted_mode;
Please call it "adjusted_mode".
ok :)
int ret;
if (INTEL_GEN(dev_priv) >= 9 && plane->id != PLANE_CURSOR) {
@@ -11108,6 +11109,41 @@ int intel_plane_atomic_calc_changes(struct
drm_crtc_state *crtc_state,
!needs_scaling(old_plane_state))
pipe_config->disable_lp_wm = true;
+ /*
+* Y-tiling is not supported in IF-ID Interlace mode in
+* GEN9 and above.
+* Scaling is not supported with Interlaced fetch mode.
+* YUV420 hybrid planar source pixel formats are not supported with
+* Interlaced fetch mode.
+*/
+ if (visible && INTEL_GEN(dev_priv) >= 9 &&
I think here we probably want state->fb instead of visible.
Hmm. I guess it'll have to check for crtc_state->enable as well
to make sure the adjusted_mode is valid.
In fact it looks to me like we could perhaps combine these with
the already existing rotation vs. format/modifier checks in
intel_plane_atomic_check_with_state()
ok
thanks for review
-Mahesh
+ mode->flags & DRM_MODE_FLAG_INTERLACE) {
+ struct drm_format_name_buf format_name;
+
+ if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
+ fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
+ DRM_DEBUG_KMS("Y/Yf tiling not supported in IF-ID
mode\n");
+ return -EINVAL;
+ }
+
+ if (needs_scaling(to_intel_plane_state(plane_state))) {
+ DRM_DEBUG_KMS("Scaling not supported in IF-ID mode\n");
+ return -EINVAL;
+ }
+
+ switch (fb->format->format) {
+ case DRM_FORMAT_NV12:
+ case DRM_FORMAT_YUV420:
+ case DRM_FORMAT_YVU420:
We don't support those formats. NV12 we'll hopefully get some
time soon, so we could keep that.
+ DRM_DEBUG_KMS("Unsupported pixel format %s for IF-ID\n",
+ drm_get_format_name(fb->format->format,
+ &format_name));
+ return -EINVAL;
+ default:
+ break;
+ }
+ }
+
return 0;
}
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl+: Pipe scaling not supported in IF-ID Interlace mode
On Thu, Jun 29, 2017 at 02:27:40PM +0530, Mahesh Kumar wrote:
> GEN9+ Interlace fetch mode doesn't support pipe scaling,
> This patch adds check to fail the flip if pipe scaling is requested in
> Interlace fetch mode.
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 36d4e635e4ce..a1206d4f9a23 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -224,6 +224,7 @@ int intel_atomic_setup_scalers(struct drm_i915_private
> *dev_priv,
> struct intel_crtc_scaler_state *scaler_state =
> &crtc_state->scaler_state;
> struct drm_atomic_state *drm_state = crtc_state->base.state;
> + const struct drm_display_mode *mode = &crtc_state->base.adjusted_mode;
"adjusted_mode"
> int num_scalers_need;
> int i, j;
>
> @@ -248,6 +249,13 @@ int intel_atomic_setup_scalers(struct drm_i915_private
> *dev_priv,
> return -EINVAL;
> }
>
> + /* Scaling/fitting not supported in IF-ID mode in GEN9+ */
> + if (INTEL_GEN(dev_priv) >=9 && mode->flags & DRM_MODE_FLAG_INTERLACE &&
> + scaler_state->scaler_users & (1 << SKL_CRTC_INDEX)) {
> + DRM_DEBUG_KMS("Pipe Scaling not supported with IF-ID mode\n");
> + return -EINVAL;
> + }
Hmm. I think if you put this into skl_update_scaler() then it'll catch
both pipe and plane scalers for you automagically.
> +
> /* walkthrough scaler_users bits and start assigning scalers */
> for (i = 0; i < sizeof(scaler_state->scaler_users) * 8; i++) {
> int *scaler_id;
> --
> 2.13.0
--
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 series starting with [1/7] dma-buf/dma-fence: Extract __dma_fence_is_later()
== Series Details == Series: series starting with [1/7] dma-buf/dma-fence: Extract __dma_fence_is_later() URL : https://patchwork.freedesktop.org/series/26551/ State : success == Summary == Series 26551v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/26551/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 +1 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fi-bdw-5557u total:279 pass:264 dwarn:4 dfail:0 fail:0 skip:11 time:442s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:429s 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:535s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:505s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:486s 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:595s fi-hsw-4770 total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:439s fi-hsw-4770r total:279 pass:259 dwarn:4 dfail:0 fail:0 skip:16 time:415s 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:473s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:465s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:573s fi-kbl-r total:279 pass:260 dwarn:1 dfail:0 fail:0 skip:18 time:581s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:560s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:279 pass:223 dwarn:1 dfail:0 fail:30 skip:24 time:343s 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:477s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:542s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:402s ee2da0ac24fb8d50a03b263eb1fa2e82849eda95 drm-tip: 2017y-06m-29d-13h-14m-49s UTC integration manifest e86e242 dma-buf/sw-sync: Use an rbtree to sort fences in the timeline 92386d5 dma-buf/sw-sync: Fix locking around sync_timeline lists 70feb63 dma-buf/sw-sync: sync_pt is private and of fixed size 7011ddb dma-buf/sw-sync: Reduce irqsave/irqrestore from known context 51a02cf dma-buf/sw-sync: Prevent user overflow on timeline advance e1ffd68 dma-buf/sw-sync: Fix the is-signaled test to handle u32 wraparound 15fe0dd dma-buf/dma-fence: Extract __dma_fence_is_later() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5068/ ___ 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/skl+: Check for supported plane configuration in Interlace mode
On Thu, Jun 29, 2017 at 02:27:39PM +0530, Mahesh Kumar wrote:
> In Gen9 platform Interlaced fetch mode doesn't support following plane
> configuration:
> - Y/Yf tiling
> - 90/270 rotation
> - Scaling
> - YUV420 hybrid planar source pixel formats.
>
> This patch adds check to fail the flip if any of the above configuration
> is requested.
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/intel_display.c | 36
>
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 4e03ca6c946f..1f2394a0c07d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11022,6 +11022,7 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
calc_changes seems like the wrong place for this.
intel_plane_atomic_check_with_state() seems better.
> bool is_crtc_enabled = crtc_state->active;
> bool turn_off, turn_on, visible, was_visible;
> struct drm_framebuffer *fb = plane_state->fb;
> + const struct drm_display_mode *mode = &crtc_state->adjusted_mode;
Please call it "adjusted_mode".
> int ret;
>
> if (INTEL_GEN(dev_priv) >= 9 && plane->id != PLANE_CURSOR) {
> @@ -11108,6 +11109,41 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> !needs_scaling(old_plane_state))
> pipe_config->disable_lp_wm = true;
>
> + /*
> + * Y-tiling is not supported in IF-ID Interlace mode in
> + * GEN9 and above.
> + * Scaling is not supported with Interlaced fetch mode.
> + * YUV420 hybrid planar source pixel formats are not supported with
> + * Interlaced fetch mode.
> + */
> + if (visible && INTEL_GEN(dev_priv) >= 9 &&
I think here we probably want state->fb instead of visible.
Hmm. I guess it'll have to check for crtc_state->enable as well
to make sure the adjusted_mode is valid.
In fact it looks to me like we could perhaps combine these with
the already existing rotation vs. format/modifier checks in
intel_plane_atomic_check_with_state()
> + mode->flags & DRM_MODE_FLAG_INTERLACE) {
> + struct drm_format_name_buf format_name;
> +
> + if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
> + fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
> + DRM_DEBUG_KMS("Y/Yf tiling not supported in IF-ID
> mode\n");
> + return -EINVAL;
> + }
> +
> + if (needs_scaling(to_intel_plane_state(plane_state))) {
> + DRM_DEBUG_KMS("Scaling not supported in IF-ID mode\n");
> + return -EINVAL;
> + }
> +
> + switch (fb->format->format) {
> + case DRM_FORMAT_NV12:
> + case DRM_FORMAT_YUV420:
> + case DRM_FORMAT_YVU420:
We don't support those formats. NV12 we'll hopefully get some
time soon, so we could keep that.
> + DRM_DEBUG_KMS("Unsupported pixel format %s for IF-ID\n",
> + drm_get_format_name(fb->format->format,
> + &format_name));
> + return -EINVAL;
> + default:
> + break;
> + }
> + }
> +
> return 0;
> }
>
> --
> 2.13.0
--
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/atomic: Add missing drm_atomic_state_clear to atomic_remove_fb
On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_framebuffer.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index fc8ef42203ec..b3ef4f1c2630 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -832,6 +832,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
> drm_atomic_clean_old_fb(dev, plane_mask, ret);
>
> if (ret == -EDEADLK) {
> + drm_atomic_state_clear(state);
Hmm. We seem to be missing this all over. Do those other places need it
as well? Hard to say without a commit message explaining why we need it
here.
Should we just back it into drm_modeset_backoff() if it's always needed?
> drm_modeset_backoff(&ctx);
> goto retry;
> }
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
Quoting ville.syrj...@linux.intel.com (2017-06-29 14:49:48)
> @@ -2640,15 +2600,13 @@ static void i915_reset_device(struct drm_i915_private
> *dev_priv)
> char *error_event[] = { I915_ERROR_UEVENT "=1", NULL };
> char *reset_event[] = { I915_RESET_UEVENT "=1", NULL };
> char *reset_done_event[] = { I915_ERROR_UEVENT "=0", NULL };
> - struct wedge_me w;
>
> kobject_uevent_env(kobj, KOBJ_CHANGE, error_event);
>
> DRM_DEBUG_DRIVER("resetting chip\n");
> kobject_uevent_env(kobj, KOBJ_CHANGE, reset_event);
>
> - /* Use a watchdog to ensure that our reset completes */
> - i915_wedge_on_timeout(&w, dev_priv, 5*HZ) {
Keep the wedge-if-reset times out mechanism. It is a nice safe guard
against driver misbehaviour and not limited to breaking the previous
deadlock. If it fires, we get an error in dmesg to go along with the
lost data. I quickly grew fond of having this safe guard!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Avoid undefined behaviour of "u32 >> 32"
When computing a hash for looking up relcoation target handles in an
execbuf, we start with a large size for the hashtable and proceed to
reduce it until the allocation suceeds. The final attempt is with an
order of 0 (i.e. a single element). This means that we then pass bits=0
to hash_32() which then computes "hash >> (32 - 0)" to lookup the single
element. Right shifting by a value the width of the operand is
undefined, so limit the smallest hash table we use to order 1.
Fixes: 4ff4b44cbb70 ("drm/i915: Store a direct lookup from object handle to
vma")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 718bb75ad387..54791bcb8ccb 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -296,12 +296,8 @@ static int eb_create(struct i915_execbuffer *eb)
break;
} while (--size);
- if (unlikely(!eb->buckets)) {
- eb->buckets = kzalloc(sizeof(struct hlist_head),
- GFP_TEMPORARY);
- if (unlikely(!eb->buckets))
- return -ENOMEM;
- }
+ if (unlikely(!eb->buckets))
+ return -ENOMEM;
eb->lut_size = size;
} else {
@@ -453,7 +449,7 @@ eb_add_vma(struct i915_execbuffer *eb,
return err;
}
- if (eb->lut_size >= 0) {
+ if (eb->lut_size > 0) {
vma->exec_handle = entry->handle;
hlist_add_head(&vma->exec_node,
&eb->buckets[hash_32(entry->handle,
@@ -897,7 +893,7 @@ static void eb_release_vmas(const struct i915_execbuffer
*eb)
static void eb_reset_vmas(const struct i915_execbuffer *eb)
{
eb_release_vmas(eb);
- if (eb->lut_size >= 0)
+ if (eb->lut_size > 0)
memset(eb->buckets, 0,
sizeof(struct hlist_head) << eb->lut_size);
}
@@ -906,7 +902,7 @@ static void eb_destroy(const struct i915_execbuffer *eb)
{
GEM_BUG_ON(eb->reloc_cache.rq);
- if (eb->lut_size >= 0)
+ if (eb->lut_size > 0)
kfree(eb->buckets);
}
@@ -2185,8 +2181,11 @@ i915_gem_do_execbuffer(struct drm_device *dev,
}
}
- if (eb_create(&eb))
- return -ENOMEM;
+ err = eb_create(&eb);
+ if (err)
+ goto err_out_fence;
+
+ GEM_BUG_ON(!eb.lut_size);
err = eb_select_context(&eb);
if (unlikely(err))
@@ -2346,6 +2345,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
i915_gem_context_put(eb.ctx);
err_destroy:
eb_destroy(&eb);
+err_out_fence:
if (out_fence_fd != -1)
put_unused_fd(out_fence_fd);
err_in_fence:
--
2.13.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
From: Ville Syrjälä
Introduce an rw_semaphore to protect the display commits. All normal
commits use down_read() and hence can proceed in parallel, but GPU reset
will use down_write() making sure no other commits are in progress when
we have to pull the plug on the display engine on pre-g4x platforms.
There are no modeset/gem locks taken inside __intel_atomic_commit_tail()
itself, and we wait for all dependencies before the down_read(), and
thus there is no chance of deadlocks with this scheme.
During reset we should be recommiting the state that was committed last.
But for now we'll settle for recommiting the last state for each object.
Hence we may commit things a bit too soon when a GPU reset occurs. The
rw_semaphore should guarantee that whatever state we observe in
obj->state during reset sticks around while we do the commit. The
obj->state pointer might change for some objects if another swap_state()
occurs while we do our thing, so there migth be some theoretical
mismatch which I tink we could avoid by grabbing the rw_semaphore also
around the swap_state(), but for now I didn't do that.
Another source of mismatch can happen because we sometimes use the
intel_crtc->config during the actual commit, and that only gets updated
when we do the commuit. Hence we may get some state via ->state, some
via the duplicated ->state, and some via ->config. We'll want to
fix this all by tracking the commited state properly, but that will
some bigger refactroing so for now we'll just choose to accept these
potential mismatches.
I left out the state readout from the post-reset display
reinitialization as that still likes to clobber crtc->state etc.
If we make it use a free standing atomic state and mke sure it doesn't
need any locks we could reintroduce it. For now I just mark the
post-reset display state as dirty as possible to make sure we
reinitialize everything.
One other potential issue remains in the form of display detection.
Either we need to protect that with the same rw_semaphore as well, or
perhaps it would be enough to force gmbus into bitbanging mode while
the reset is happening and we don't have interrupts, and just across
the actual hardware GPU reset we could hold the gmbus mutex.
v2: Keep intel_prepare/finish_reset() outside struct_mutex (Chris)
v3: Drop all the committed_state refactoring to make this less
obnoxious to backport (Daniel)
Cc: sta...@vger.kernel.org # for the brave
Cc: Daniel Vetter
Cc: Chris Wilson
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101597
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99093
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101600
Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for
request completion")
Fixes: 221fe7994554 ("drm/i915: Perform a direct reset of the GPU from the
waiter")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_irq.c | 44 +---
drivers/gpu/drm/i915/intel_display.c | 199 ---
3 files changed, 139 insertions(+), 106 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index effbe4f72a64..88ddd27f61b0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2237,6 +2237,8 @@ struct drm_i915_private {
struct drm_atomic_state *modeset_restore_state;
struct drm_modeset_acquire_ctx reset_ctx;
+ struct rw_semaphore commit_sem;
+
struct list_head vm_list; /* Global list of all address spaces */
struct i915_ggtt ggtt; /* VM representing the global address space */
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index eb4f1dca2077..9d591f17fda3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2587,46 +2587,6 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
return ret;
}
-struct wedge_me {
- struct delayed_work work;
- struct drm_i915_private *i915;
- const char *name;
-};
-
-static void wedge_me(struct work_struct *work)
-{
- struct wedge_me *w = container_of(work, typeof(*w), work.work);
-
- dev_err(w->i915->drm.dev,
- "%s timed out, cancelling all in-flight rendering.\n",
- w->name);
- i915_gem_set_wedged(w->i915);
-}
-
-static void __init_wedge(struct wedge_me *w,
-struct drm_i915_private *i915,
-long timeout,
-const char *name)
-{
- w->i915 = i915;
- w->name = name;
-
- INIT_DELAYED_WORK_ONSTACK(&w->work, wedge_me);
- schedule_delayed_work(&w->work, timeout);
-}
-
-static void __fini_wedge(struct wedge_me *w)
-{
- cancel_delayed_work_sync(&w->work);
- destroy_delayed_work_on_stack(&w->work);
- w->i915 = NULL;
-}
-
-#define i915_wedge_on_timeout(W, DEV, TIMEOUT) \
- for (__init_we
[Intel-gfx] [PATCH 2/5] drm/atomic: Introduce drm_atomic_helper_duplicate_committed_state()
From: Ville Syrjälä
For i915 GPU reset handling we'll want to be able to duplicate the state
that was last committed to the hardware. For that purpose let's provide
a helper function that is supposed to duplicate the state last committed
to the hardware. For now we'll actually just duplicate the last swapped
state for each object. That isn't quite correct but being able to
duplicate the actaully committed state will require larger refactoring.
Since we will access obj->state without the protection of the
appropriate locks there is a small chance that this might blow up. That
problem too will get solved once we start dealing with the committed
state correctly.
Note that we duplicates the current tate to to both old_state and
new_state. For the purposes of i915 GPU reset we would only need one
of them, but we actually need two top level states; one for
disabling everything (which would need the duplicated state to be
old_state), and another to reenable everything (which would need the
duplicated state to be new_state). So to make it less comples I figured
I'd just always duplicate both. Might want to rethink this if for no
other reason that reducing the chances of memory allocation failure.
Due to the double state duplication we need
drm_atomic_helper_clean_committed_state() to clean up the duplicated
old_state since that's not handled by the normal drm_atomic_state
cleanup code.
TODO: do we want this in the helper, or maybe it should be just in i915?
v2: s/commited/committed/ everywhere (checkpatch)
Handle state duplication errors better
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 123
include/drm/drm_atomic_helper.h | 4 ++
2 files changed, 127 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 2f269e4267da..a6ee0d16f723 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3596,6 +3596,129 @@ drm_atomic_helper_duplicate_state(struct drm_device
*dev,
}
EXPORT_SYMBOL(drm_atomic_helper_duplicate_state);
+struct drm_atomic_state *
+drm_atomic_helper_duplicate_committed_state(struct drm_device *dev)
+{
+ struct drm_atomic_state *state;
+ struct drm_connector_list_iter conn_iter;
+ struct drm_connector *conn;
+ struct drm_plane *plane;
+ struct drm_crtc *crtc;
+ int err = 0;
+
+ state = drm_atomic_state_alloc(dev);
+ if (!state)
+ return ERR_PTR(-ENOMEM);
+
+ drm_for_each_plane(plane, dev) {
+ int i = drm_plane_index(plane);
+
+ state->planes[i].ptr = plane;
+ state->planes[i].state =
+ plane->funcs->atomic_duplicate_state(plane);
+ state->planes[i].new_state = state->planes[i].state;
+ state->planes[i].old_state =
+ plane->funcs->atomic_duplicate_state(plane);
+
+ if (!state->planes[i].state ||
+ !state->planes[i].old_state) {
+ err = -ENOMEM;
+ goto free;
+ }
+
+ state->planes[i].old_state->state = state;
+ }
+
+ drm_for_each_crtc(crtc, dev) {
+ int i = drm_crtc_index(crtc);
+
+ state->crtcs[i].ptr = crtc;
+ state->crtcs[i].state =
+ crtc->funcs->atomic_duplicate_state(crtc);
+ state->crtcs[i].new_state = state->crtcs[i].state;
+ state->crtcs[i].old_state =
+ crtc->funcs->atomic_duplicate_state(crtc);
+
+ if (!state->crtcs[i].state ||
+ !state->crtcs[i].old_state) {
+ err = -ENOMEM;
+ goto free;
+ }
+
+ state->crtcs[i].old_state->state = state;
+ }
+
+ drm_connector_list_iter_begin(dev, &conn_iter);
+ drm_for_each_connector_iter(conn, &conn_iter) {
+ int i = drm_connector_index(conn);
+
+ err = drm_atomic_state_realloc_connectors(conn->dev, state, i);
+ if (err)
+ break;
+
+ drm_connector_get(conn);
+ state->connectors[i].ptr = conn;
+ state->connectors[i].state =
conn->funcs->atomic_duplicate_state(conn);
+ state->connectors[i].new_state = state->connectors[i].state;
+ state->connectors[i].old_state =
conn->funcs->atomic_duplicate_state(conn);
+
+ if (!state->connectors[i].state ||
+ !state->connectors[i].old_state) {
+ err = -ENOMEM;
+ break;
+ }
+
+ state->connectors[i].old_state->state = state;
+ }
+ drm_connector_list_iter_end(&conn_iter);
+
+free:
+ if (err < 0) {
+ drm_atomic_helper_clean_committed_state(state);
+
[Intel-gfx] [PATCH 4/5] drm/i915: Refactor __intel_atomic_commit_tail()
From: Ville Syrjälä
Split intel_atomic_commit_tail() into a lower level function that does
the actual commit, and a higher level one that waits for the
dependencies and signals the commit as done. We'll reuse the lower
level function to perform commits during GPU resets.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4ce81a694bd2..7cdd6ec97f80 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13004,7 +13004,7 @@ static void
intel_atomic_helper_free_state_worker(struct work_struct *work)
intel_atomic_helper_free_state(dev_priv);
}
-static void intel_atomic_commit_tail(struct drm_atomic_state *state)
+static void __intel_atomic_commit_tail(struct drm_atomic_state *state)
{
struct drm_device *dev = state->dev;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
@@ -13017,8 +13017,6 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
unsigned crtc_vblank_mask = 0;
int i;
- drm_atomic_helper_wait_for_dependencies(state);
-
if (intel_state->modeset)
intel_display_power_get(dev_priv, POWER_DOMAIN_MODESET);
@@ -13143,8 +13141,6 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
if (intel_state->modeset && intel_can_enable_sagv(state))
intel_enable_sagv(dev_priv);
- drm_atomic_helper_commit_hw_done(state);
-
if (intel_state->modeset) {
/* As one of the primary mmio accessors, KMS has a high
* likelihood of triggering bugs in unclaimed access. After we
@@ -13155,6 +13151,18 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
}
+}
+
+static void intel_atomic_commit_tail(struct drm_atomic_state *state)
+{
+ struct drm_device *dev = state->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ drm_atomic_helper_wait_for_dependencies(state);
+
+ __intel_atomic_commit_tail(state);
+
+ drm_atomic_helper_commit_hw_done(state);
mutex_lock(&dev->struct_mutex);
drm_atomic_helper_cleanup_planes(dev, state);
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/atomic: Refactor drm_atomic_state_realloc_connectors()
From: Ville Syrjälä
Pull the code to reallocate the state->connectors[] array into a
helper function. We'll have another use for this later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic.c | 43 +--
include/drm/drm_atomic.h | 5 +
2 files changed, 34 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 095e87278a88..a9f02b214fc6 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1043,6 +1043,32 @@ drm_atomic_get_private_obj_state(struct drm_atomic_state
*state, void *obj,
}
EXPORT_SYMBOL(drm_atomic_get_private_obj_state);
+int drm_atomic_state_realloc_connectors(struct drm_device *dev,
+ struct drm_atomic_state *state,
+ int index)
+{
+ struct drm_mode_config *config = &dev->mode_config;
+ struct __drm_connnectors_state *c;
+ int alloc = max(index + 1, config->num_connector);
+
+ if (index < state->num_connector)
+ return 0;
+
+ c = krealloc(state->connectors,
+alloc * sizeof(*state->connectors), GFP_KERNEL);
+ if (!c)
+ return -ENOMEM;
+
+ state->connectors = c;
+ memset(&state->connectors[state->num_connector], 0,
+ sizeof(*state->connectors) * (alloc - state->num_connector));
+
+ state->num_connector = alloc;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_atomic_state_realloc_connectors);
+
/**
* drm_atomic_get_connector_state - get connector state
* @state: global atomic state object
@@ -1074,20 +1100,9 @@ drm_atomic_get_connector_state(struct drm_atomic_state
*state,
index = drm_connector_index(connector);
- if (index >= state->num_connector) {
- struct __drm_connnectors_state *c;
- int alloc = max(index + 1, config->num_connector);
-
- c = krealloc(state->connectors, alloc *
sizeof(*state->connectors), GFP_KERNEL);
- if (!c)
- return ERR_PTR(-ENOMEM);
-
- state->connectors = c;
- memset(&state->connectors[state->num_connector], 0,
- sizeof(*state->connectors) * (alloc -
state->num_connector));
-
- state->num_connector = alloc;
- }
+ ret = drm_atomic_state_realloc_connectors(connector->dev, state, index);
+ if (ret)
+ return ERR_PTR(ret);
if (state->connectors[index].state)
return state->connectors[index].state;
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 0196f264a418..5596ad58bcdc 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -324,6 +324,11 @@ drm_atomic_get_private_obj_state(struct drm_atomic_state
*state,
void *obj,
const struct drm_private_state_funcs *funcs);
+int __must_check
+drm_atomic_state_realloc_connectors(struct drm_device *dev,
+ struct drm_atomic_state *state,
+ int index);
+
/**
* drm_atomic_get_existing_crtc_state - get crtc state, if it exists
* @state: global atomic state object
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915% Store vma gtt offset in plane state
From: Ville Syrjälä
To avoid having to deference plane_state->vma during the commit phase of
plane updates, let's store the vma gtt offset (or the bus address when
we need it) in the plane state. This is crucial for doing the modeset
operations during GPU reset as as plane_state->vma gets cleared when we
duplicate the state and we won't be calling .prepare_fb() during GPU
reset plane commits.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 38 +---
drivers/gpu/drm/i915/intel_drv.h | 6 +-
drivers/gpu/drm/i915/intel_sprite.c | 8
3 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4e03ca6c946f..4ce81a694bd2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2744,7 +2744,7 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
if (!state->vma)
continue;
- if (intel_plane_ggtt_offset(state) == plane_config->base) {
+ if (state->gtt_offset == plane_config->base) {
fb = c->primary->fb;
drm_framebuffer_reference(fb);
goto valid_fb;
@@ -2771,6 +2771,8 @@ intel_find_initial_plane_obj(struct intel_crtc
*intel_crtc,
mutex_lock(&dev->struct_mutex);
intel_state->vma =
intel_pin_and_fence_fb_obj(fb, primary->state->rotation);
+ intel_state->gtt_offset = i915_ggtt_offset(intel_state->vma);
+
mutex_unlock(&dev->struct_mutex);
if (IS_ERR(intel_state->vma)) {
DRM_ERROR("failed to pin boot fb on pipe %d: %li\n",
@@ -3122,19 +3124,16 @@ static void i9xx_update_primary_plane(struct
intel_plane *primary,
I915_WRITE_FW(DSPSTRIDE(plane), fb->pitches[0]);
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
I915_WRITE_FW(DSPSURF(plane),
- intel_plane_ggtt_offset(plane_state) +
- crtc->dspaddr_offset);
+ plane_state->gtt_offset + crtc->dspaddr_offset);
I915_WRITE_FW(DSPOFFSET(plane), (y << 16) | x);
} else if (INTEL_GEN(dev_priv) >= 4) {
I915_WRITE_FW(DSPSURF(plane),
- intel_plane_ggtt_offset(plane_state) +
- crtc->dspaddr_offset);
+ plane_state->gtt_offset + crtc->dspaddr_offset);
I915_WRITE_FW(DSPTILEOFF(plane), (y << 16) | x);
I915_WRITE_FW(DSPLINOFF(plane), linear_offset);
} else {
I915_WRITE_FW(DSPADDR(plane),
- intel_plane_ggtt_offset(plane_state) +
- crtc->dspaddr_offset);
+ plane_state->gtt_offset + crtc->dspaddr_offset);
}
POSTING_READ_FW(reg);
@@ -3395,7 +3394,7 @@ static void skylake_update_primary_plane(struct
intel_plane *plane,
}
I915_WRITE_FW(PLANE_SURF(pipe, plane_id),
- intel_plane_ggtt_offset(plane_state) + surf_addr);
+ plane_state->gtt_offset + surf_addr);
POSTING_READ_FW(PLANE_SURF(pipe, plane_id));
@@ -9185,15 +9184,9 @@ static u32 intel_cursor_base(const struct
intel_plane_state *plane_state)
struct drm_i915_private *dev_priv =
to_i915(plane_state->base.plane->dev);
const struct drm_framebuffer *fb = plane_state->base.fb;
- const struct drm_i915_gem_object *obj = intel_fb_obj(fb);
u32 base;
- if (INTEL_INFO(dev_priv)->cursor_needs_physical)
- base = obj->phys_handle->busaddr;
- else
- base = intel_plane_ggtt_offset(plane_state);
-
- base += plane_state->main.offset;
+ base = plane_state->gtt_offset + plane_state->main.offset;
/* ILK+ do this automagically */
if (HAS_GMCH_DISPLAY(dev_priv) &&
@@ -10846,8 +10839,11 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
work->old_vma = to_intel_plane_state(primary->state)->vma;
to_intel_plane_state(primary->state)->vma = vma;
+ to_intel_plane_state(primary->state)->gtt_offset =
+ i915_ggtt_offset(vma);
- work->gtt_offset = i915_ggtt_offset(vma) + intel_crtc->dspaddr_offset;
+ work->gtt_offset = to_intel_plane_state(primary->state)->gtt_offset +
+ intel_crtc->dspaddr_offset;
work->rotation = crtc->primary->state->rotation;
/*
@@ -10903,6 +10899,8 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
i915_add_request(request);
cleanup_unpin:
to_intel_plane_state(primary->state)->vma = work->old_vma;
+ to_intel_plane_state(primary->state)->gtt_offset =
+ i915_ggtt_offset(work->old_vma);
intel_unpin_fb_vma(vma);
cle
[Intel-gfx] [PATCH 0/5] drm/i915: Fix pre-g4x GPU reset, again
From: Ville Syrjälä I set out to fix the pre-g4x GPU reset by protecting display commits with an rw_semaphore. I originally went all out and added infrastructure to track the committed state (as opposed the latest swapped state), but Daniel suggested that we want to backport the thing so I simplified it to just use obj->state instead. I will be posting the committed state handling as a followup as it will also DTRT if/when we will start allowing queueing multiple commits per-crtc. Not sure if we want to put the "committed" state stuf into the atomic helper or I should just pull it all into i915. Suggestions welcome. Series available here: git://github.com/vsyrjala/linux.git reset_commit_rwsem_norefactor_2, Ville Syrjälä (5): drm/atomic: Refactor drm_atomic_state_realloc_connectors() drm/atomic: Introduce drm_atomic_helper_duplicate_committed_state() drm/i915% Store vma gtt offset in plane state drm/i915: Refactor __intel_atomic_commit_tail() drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore drivers/gpu/drm/drm_atomic.c | 43 -- drivers/gpu/drm/drm_atomic_helper.c | 123 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_irq.c | 44 +- drivers/gpu/drm/i915/intel_display.c | 251 +++ drivers/gpu/drm/i915/intel_drv.h | 6 +- drivers/gpu/drm/i915/intel_sprite.c | 8 +- include/drm/drm_atomic.h | 5 + include/drm/drm_atomic_helper.h | 4 + 9 files changed, 338 insertions(+), 148 deletions(-) -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
