Re: [Intel-gfx] [PATCH v2 09/20] drm/i915: Remove references to struct drm_device.pdev
ping for a review of the i915 patches
Am 01.12.20 um 11:35 schrieb Thomas Zimmermann:
Using struct drm_device.pdev is deprecated. Convert i915 to struct
drm_device.dev. No functional changes.
v2:
* move gt/ and gvt/ changes into separate patches
Signed-off-by: Thomas Zimmermann
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/display/intel_bios.c | 2 +-
drivers/gpu/drm/i915/display/intel_cdclk.c| 14 ++---
drivers/gpu/drm/i915/display/intel_csr.c | 2 +-
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 2 +-
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
drivers/gpu/drm/i915/display/intel_gmbus.c| 2 +-
.../gpu/drm/i915/display/intel_lpe_audio.c| 5 +++--
drivers/gpu/drm/i915/display/intel_opregion.c | 6 +++---
drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.c| 4 ++--
drivers/gpu/drm/i915/display/intel_quirks.c | 2 +-
drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
drivers/gpu/drm/i915/display/intel_vga.c | 8
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 6 +++---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 20 +--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
drivers/gpu/drm/i915/i915_getparam.c | 5 +++--
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
drivers/gpu/drm/i915/i915_pmu.c | 5 +++--
drivers/gpu/drm/i915/i915_suspend.c | 4 ++--
drivers/gpu/drm/i915/i915_switcheroo.c| 4 ++--
drivers/gpu/drm/i915/i915_vgpu.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 2 +-
drivers/gpu/drm/i915/intel_region_lmem.c | 8
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
drivers/gpu/drm/i915/selftests/mock_gtt.c | 2 +-
32 files changed, 68 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 4cc949b228f2..8879676372a3 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2088,7 +2088,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t size)
static struct vbt_header *oprom_get_vbt(struct drm_i915_private *dev_priv)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
void __iomem *p = NULL, *oprom;
struct vbt_header *vbt;
u16 vbt_size;
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index c449d28d0560..a6e13208dc50 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -96,7 +96,7 @@ static void fixed_450mhz_get_cdclk(struct drm_i915_private
*dev_priv,
static void i85x_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 hpllcc = 0;
/*
@@ -138,7 +138,7 @@ static void i85x_get_cdclk(struct drm_i915_private
*dev_priv,
static void i915gm_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 gcfgc = 0;
pci_read_config_word(pdev, GCFGC, );
@@ -162,7 +162,7 @@ static void i915gm_get_cdclk(struct drm_i915_private
*dev_priv,
static void i945gm_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
u16 gcfgc = 0;
pci_read_config_word(pdev, GCFGC, );
@@ -256,7 +256,7 @@ static unsigned int intel_hpll_vco(struct drm_i915_private
*dev_priv)
static void g33_get_cdclk(struct drm_i915_private *dev_priv,
struct intel_cdclk_config *cdclk_config)
{
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
static const u8 div_3200[] = { 12, 10, 8, 7, 5, 16 };
static const u8 div_4000[] = { 14, 12, 10, 8, 6, 20 };
static const u8 div_4800[] = { 20, 14, 12, 10, 8, 24 };
@@ -305,7 +305,7 @@ static void g33_get_cdclk(struct drm_i915_private *dev_priv,
static void pnv_get_cdclk(struct drm_i915_private *dev_priv,
[Intel-gfx] [PATCH v4 16/16] drm/i915: Enable PCON configuration for Color Conversion for TGL
This patch enables PCON configuration for color space conversion for TGL+ platfrom. This will help in supporting 8k@60 YUV420 modes common in HDMI 8k panels, through a capable PCON. Also allow 8k@60 YUV420 modes, only if PCON claims to support the color space conversion. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_ddi.c | 1 + drivers/gpu/drm/i915/display/intel_dp.c | 5 + 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 721a47bbc009..ed6b8ea85408 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3644,6 +3644,7 @@ static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state, if (!is_mst) intel_dp_set_power(intel_dp, DP_SET_POWER_D0); + intel_dp_configure_protocol_converter(intel_dp); intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true); /* * DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index b3f1190d8150..86289c925612 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -720,6 +720,11 @@ intel_dp_mode_valid_downstream(struct intel_connector *connector, const struct drm_display_info *info = >base.display_info; int tmds_clock; + /* Allow 8k YUV420 modes, only if PCON supports RGB->YUV conversion */ + if (mode->hdisplay == 7680 && drm_mode_is_420_only(info, mode) && + !intel_dp->dfp.rgb_to_ycbcr) + return MODE_NO_420; + /* * If PCON and HDMI2.1 sink both support FRL MODE, check FRL * bandwidth constraints. -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 15/16] drm/i915: Let PCON convert from RGB to YUV if it can
If PCON has capability to convert RGB->YUV colorspace and also
to 444->420 downsampling then for any YUV420 only mode, we can
let the PCON do all the conversion.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 37 +--
2 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index b41de41759a0..4150108bdc6d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1460,6 +1460,7 @@ struct intel_dp {
int pcon_max_frl_bw, sink_max_frl_bw;
u8 max_bpc;
bool ycbcr_444_to_420;
+ bool rgb_to_ycbcr;
} dfp;
/* Display stream compression testing */
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 30c76ba63232..b3f1190d8150 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -651,6 +651,10 @@ intel_dp_output_format(struct drm_connector *connector,
!drm_mode_is_420_only(info, mode))
return INTEL_OUTPUT_FORMAT_RGB;
+ if (intel_dp->dfp.rgb_to_ycbcr &&
+ intel_dp->dfp.ycbcr_444_to_420)
+ return INTEL_OUTPUT_FORMAT_RGB;
+
if (intel_dp->dfp.ycbcr_444_to_420)
return INTEL_OUTPUT_FORMAT_YCBCR444;
else
@@ -4365,13 +4369,12 @@ void intel_dp_configure_protocol_converter(struct
intel_dp *intel_dp)
"Failed to set protocol converter YCbCr 4:2:0
conversion mode to %s\n",
enableddisabled(intel_dp->dfp.ycbcr_444_to_420));
- tmp = 0;
-
- if (drm_dp_dpcd_writeb(_dp->aux,
- DP_PROTOCOL_CONVERTER_CONTROL_2, tmp) <= 0)
+ tmp = intel_dp->dfp.rgb_to_ycbcr ?
+ DP_CONVERSION_BT601_RGB_YCBCR_ENABLE : 0;
+ if (drm_dp_pcon_convert_rgb_to_ycbcr(_dp->aux, tmp) <= 0)
drm_dbg_kms(>drm,
- "Failed to set protocol converter YCbCr 4:2:2
conversion mode to %s\n",
- enableddisabled(false));
+ "Failed to set protocol converter RGB->YCbCr
conversion mode to %s\n",
+ enableddisabled(intel_dp->dfp.rgb_to_ycbcr));
}
static void intel_enable_dp(struct intel_atomic_state *state,
@@ -6897,7 +6900,7 @@ intel_dp_update_420(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
- bool is_branch, ycbcr_420_passthrough, ycbcr_444_to_420;
+ bool is_branch, ycbcr_420_passthrough, ycbcr_444_to_420, rgb_to_ycbcr;
/* No YCbCr output support on gmch platforms */
if (HAS_GMCH(i915))
@@ -6919,14 +6922,23 @@ intel_dp_update_420(struct intel_dp *intel_dp)
dp_to_dig_port(intel_dp)->lspcon.active ||
drm_dp_downstream_444_to_420_conversion(intel_dp->dpcd,
intel_dp->downstream_ports);
+ rgb_to_ycbcr = drm_dp_downstream_rgb_to_ycbcr_conversion(intel_dp->dpcd,
+
intel_dp->downstream_ports);
if (INTEL_GEN(i915) >= 11) {
+ /* Let PCON convert from RGB->YCbCr if possible */
+ if (is_branch && rgb_to_ycbcr && ycbcr_444_to_420) {
+ intel_dp->dfp.rgb_to_ycbcr = true;
+ intel_dp->dfp.ycbcr_444_to_420 = true;
+ connector->base.ycbcr_420_allowed = true;
+ } else {
/* Prefer 4:2:0 passthrough over 4:4:4->4:2:0 conversion */
- intel_dp->dfp.ycbcr_444_to_420 =
- ycbcr_444_to_420 && !ycbcr_420_passthrough;
+ intel_dp->dfp.ycbcr_444_to_420 =
+ ycbcr_444_to_420 && !ycbcr_420_passthrough;
- connector->base.ycbcr_420_allowed =
- !is_branch || ycbcr_444_to_420 || ycbcr_420_passthrough;
+ connector->base.ycbcr_420_allowed =
+ !is_branch || ycbcr_444_to_420 ||
ycbcr_420_passthrough;
+ }
} else {
/* 4:4:4->4:2:0 conversion is the only way */
intel_dp->dfp.ycbcr_444_to_420 = ycbcr_444_to_420;
@@ -6935,8 +6947,9 @@ intel_dp_update_420(struct intel_dp *intel_dp)
}
drm_dbg_kms(>drm,
- "[CONNECTOR:%d:%s] YCbCr 4:2:0 allowed? %s, YCbCr
4:4:4->4:2:0 conversion? %s\n",
+ "[CONNECTOR:%d:%s] RGB->YcbCr conversion? %s, YCbCr 4:2:0
allowed? %s, YCbCr 4:4:4->4:2:0 conversion? %s\n",
[Intel-gfx] [PATCH v4 14/16] drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding
When a source supporting DSC1.1 is connected to DSC1.2 HDMI2.1 sink
via DP HDMI2.1 PCON, the PCON can be configured to decode the
DSC1.1 compressed stream and encode to DSC1.2. It then sends the
DSC1.2 compressed stream to the HDMI2.1 sink.
This patch configures the PCON for DSC1.1 to DSC1.2 encoding, based
on the PCON's DSC encoder capablities and HDMI2.1 sink's DSC decoder
capabilities.
v2: Addressed review comments from Uma Shankar:
-fixed the error in packing pps parameter values
-added check for pcon in the pcon related function
-appended display in commit message
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 117 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
3 files changed, 118 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3ff8b18f1997..721a47bbc009 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3653,6 +3653,7 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
intel_dp_check_frl_training(intel_dp, crtc_state);
+ intel_dp_pcon_dsc_configure(intel_dp, crtc_state);
/*
* 7.i Follow DisplayPort specification training sequence (see notes for
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4dd272a34ee8..30c76ba63232 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4039,9 +4039,21 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp
*intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = _connector->base;
+ int max_frl_rate;
+ int max_lanes, rate_per_lane;
+ int max_dsc_lanes, dsc_rate_per_lane;
- return (connector->display_info.hdmi.max_frl_rate_per_lane *
- connector->display_info.hdmi.max_lanes);
+ max_lanes = connector->display_info.hdmi.max_lanes;
+ rate_per_lane = connector->display_info.hdmi.max_frl_rate_per_lane;
+ max_frl_rate = max_lanes * rate_per_lane;
+
+ if (connector->display_info.hdmi.dsc_cap.v_1p2) {
+ max_dsc_lanes = connector->display_info.hdmi.dsc_cap.max_lanes;
+ dsc_rate_per_lane =
connector->display_info.hdmi.dsc_cap.max_frl_rate_per_lane;
+ max_frl_rate = min(max_frl_rate, max_dsc_lanes *
dsc_rate_per_lane);
+ }
+
+ return max_frl_rate;
}
static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
@@ -4171,6 +4183,105 @@ void intel_dp_check_frl_training(struct intel_dp
*intel_dp,
}
}
+static int
+intel_dp_pcon_dsc_enc_slice_height(const struct intel_crtc_state *crtc_state)
+{
+
+ int vactive = crtc_state->hw.adjusted_mode.vdisplay;
+
+ return intel_hdmi_dsc_get_slice_height(vactive);
+}
+
+static int
+intel_dp_pcon_dsc_enc_slices(struct intel_dp *intel_dp,
+const struct intel_crtc_state *crtc_state)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = _connector->base;
+ int hdmi_throughput =
connector->display_info.hdmi.dsc_cap.clk_per_slice;
+ int hdmi_max_slices = connector->display_info.hdmi.dsc_cap.max_slices;
+ int pcon_max_slices =
drm_dp_pcon_dsc_max_slices(intel_dp->pcon_dsc_dpcd);
+ int pcon_max_slice_width =
drm_dp_pcon_dsc_max_slice_width(intel_dp->pcon_dsc_dpcd);
+
+
+ return intel_hdmi_dsc_get_num_slices(crtc_state, pcon_max_slices,
+pcon_max_slice_width,
+hdmi_max_slices, hdmi_throughput);
+}
+
+static int
+intel_dp_pcon_dsc_enc_bpp(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state,
+ int num_slices, int slice_width)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = _connector->base;
+ int output_format = crtc_state->output_format;
+ bool hdmi_all_bpp = connector->display_info.hdmi.dsc_cap.all_bpp;
+ int pcon_fractional_bpp =
drm_dp_pcon_dsc_bpp_incr(intel_dp->pcon_dsc_dpcd);
+ int hdmi_max_chunk_bytes =
+ connector->display_info.hdmi.dsc_cap.total_chunk_kbytes * 1024;
+
+ return intel_hdmi_dsc_get_bpp(pcon_fractional_bpp, slice_width,
+ num_slices, output_format, hdmi_all_bpp,
+ hdmi_max_chunk_bytes);
+}
+
+void
+intel_dp_pcon_dsc_configure(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+ u8 pps_param[6];
+ int
[Intel-gfx] [PATCH v4 13/16] drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1
The DP-HDMI2.1 PCON spec provides way for a source to set PPS
parameters: slice height, slice width and bits_per_pixel, based on
the HDMI2.1 sink capabilities. The DSC encoder of the PCON will
respect these parameters, while preparing the 128 byte PPS.
This patch adds helper functions to calculate these PPS paremeters as
per the HDMI2.1 specification.
v2: Addressed review comments given by Uma Shankar:
-added documentation for functions
-fixed typos and errors
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 233 ++
drivers/gpu/drm/i915/display/intel_hdmi.h | 7 +
2 files changed, 240 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index e10fdb369daa..41eb1c175a0e 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3428,3 +3428,236 @@ void intel_hdmi_init(struct drm_i915_private *dev_priv,
dig_port->aux_ch = intel_bios_port_aux_ch(dev_priv, port);
intel_hdmi_init_connector(dig_port, intel_connector);
}
+
+/*
+ * intel_hdmi_dsc_get_slice_height - get the dsc slice_height
+ * @vactive: Vactive of a display mode
+ *
+ * @return: appropriate dsc slice height for a given mode.
+ */
+int intel_hdmi_dsc_get_slice_height(int vactive)
+{
+ int slice_height;
+
+ /*
+* Slice Height determination : HDMI2.1 Section 7.7.5.2
+* Select smallest slice height >=96, that results in a valid PPS and
+* requires minimum padding lines required for final slice.
+*
+* Assumption : Vactive is even.
+*/
+ for (slice_height = 96; slice_height <= vactive; slice_height += 2)
+ if (vactive % slice_height == 0)
+ return slice_height;
+
+ return 0;
+}
+
+/*
+ * intel_hdmi_dsc_get_num_slices - get no. of dsc slices based on dsc encoder
+ * and dsc decoder capabilites
+ *
+ * @crtc_state: intel crtc_state
+ * @src_max_slices: maximum slices supported by the DSC encoder
+ * @src_max_slice_width: maximum slice width supported by DSC encoder
+ * @hdmi_max_slices: maximum slices supported by sink DSC decoder
+ * @hdmi_throughput: maximum clock per slice (MHz) supported by HDMI sink
+ *
+ * @return: num of dsc slices that can be supported by the dsc encoder
+ * and decoder.
+ */
+int
+intel_hdmi_dsc_get_num_slices(const struct intel_crtc_state *crtc_state,
+ int src_max_slices, int src_max_slice_width,
+ int hdmi_max_slices, int hdmi_throughput)
+{
+/* Pixel rates in KPixels/sec */
+#define HDMI_DSC_PEAK_PIXEL_RATE 272
+/*
+ * Rates at which the source and sink are required to process pixels in each
+ * slice, can be two levels: either atleast 34KHz or atleast 4KHz.
+ */
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_0 34
+#define HDMI_DSC_MAX_ENC_THROUGHPUT_1 40
+
+/* Spec limits the slice width to 2720 pixels */
+#define MAX_HDMI_SLICE_WIDTH 2720
+ int kslice_adjust;
+ int adjusted_clk_khz;
+ int min_slices;
+ int target_slices;
+ int max_throughput; /* max clock freq. in khz per slice */
+ int max_slice_width;
+ int slice_width;
+ int pixel_clock = crtc_state->hw.adjusted_mode.crtc_clock;
+
+ if (!hdmi_throughput)
+ return 0;
+
+ /*
+* Slice Width determination : HDMI2.1 Section 7.7.5.1
+* kslice_adjust factor for 4:2:0, and 4:2:2 formats is 0.5, where as
+* for 4:4:4 is 1.0. Multiplying these factors by 10 and later
+* dividing adjusted clock value by 10.
+*/
+ if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 ||
+ crtc_state->output_format == INTEL_OUTPUT_FORMAT_RGB)
+ kslice_adjust = 10;
+ else
+ kslice_adjust = 5;
+
+ /*
+* As per spec, the rate at which the source and the sink process
+* the pixels per slice are at two levels: atleast 340Mhz or 400Mhz.
+* This depends upon the pixel clock rate and output formats
+* (kslice adjust).
+* If pixel clock * kslice adjust >= 2720MHz slices can be processed
+* at max 340MHz, otherwise they can be processed at max 400MHz.
+*/
+
+ adjusted_clk_khz = DIV_ROUND_UP(kslice_adjust * pixel_clock, 10);
+
+ if (adjusted_clk_khz <= HDMI_DSC_PEAK_PIXEL_RATE)
+ max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_0;
+ else
+ max_throughput = HDMI_DSC_MAX_ENC_THROUGHPUT_1;
+
+ /*
+* Taking into account the sink's capability for maximum
+* clock per slice (in MHz) as read from HF-VSDB.
+*/
+ max_throughput = min(max_throughput, hdmi_throughput * 1000);
+
+ min_slices = DIV_ROUND_UP(adjusted_clk_khz, max_throughput);
+ max_slice_width = min(MAX_HDMI_SLICE_WIDTH,
[Intel-gfx] [PATCH v4 12/16] drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder
This patch adds support to read and store the DSC capabilities of the
HDMI2.1 PCon encoder. It also adds a new field to store these caps,
The caps are read during dfp update and can later be used to get the
PPS parameters for PCON-HDMI2.1 sink pair. Which inturn will be used
to take a call to override the existing PPS-metadata, by either
writing the entire new PPS metadata, or by writing only the
PPS override parameters.
v2: Restructured the code to read all capability DPCDs at once and store
in an array in intel_dp structure.
v3: rebase
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 20 +++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index c624c2f9b624..b41de41759a0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1362,6 +1362,7 @@ struct intel_dp {
u8 lttpr_common_caps[DP_LTTPR_COMMON_CAP_SIZE];
u8 lttpr_phy_caps[DP_MAX_LTTPR_COUNT][DP_LTTPR_PHY_CAP_SIZE];
u8 fec_capable;
+ u8 pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE];
/* source rates */
int num_source_rates;
const int *source_rates;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0616779d858e..4dd272a34ee8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3984,6 +3984,24 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
+static void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+ /* Clear the cached register set to avoid using stale values */
+
+ memset(intel_dp->pcon_dsc_dpcd, 0, sizeof(intel_dp->pcon_dsc_dpcd));
+
+ if (drm_dp_dpcd_read(_dp->aux, DP_PCON_DSC_ENCODER,
+intel_dp->pcon_dsc_dpcd,
+sizeof(intel_dp->pcon_dsc_dpcd)) < 0)
+ drm_err(>drm, "Failed to read DPCD register 0x%x\n",
+ DP_PCON_DSC_ENCODER);
+
+ drm_dbg_kms(>drm, "PCON ENCODER DSC DPCD: %*ph\n",
+ (int)sizeof(intel_dp->pcon_dsc_dpcd),
intel_dp->pcon_dsc_dpcd);
+}
+
static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
{
int bw_gbps[] = {9, 18, 24, 32, 40, 48};
@@ -6757,6 +6775,8 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
intel_dp->dfp.max_tmds_clock,
intel_dp->dfp.pcon_max_frl_bw,
intel_dp->dfp.sink_max_frl_bw);
+
+ intel_dp_get_pcon_dsc_cap(intel_dp);
}
static void
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 10/16] drm/i915: Check for FRL training before DP Link training
This patch calls functions to check FRL training requirements for an HDMI2.1 sink, when connected through PCON. The call is made before the DP link training. In case FRL is not required or failure during FRL training, the TMDS mode is selected for the pcon. v2: moved check_frl_training() just after FEC READY, before starting DP link training. v3: rebase Signed-off-by: Ankit Nautiyal Reviewed-by: Uma Shankar --- drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ drivers/gpu/drm/i915/display/intel_dp.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c index 6863236df1d0..3ff8b18f1997 100644 --- a/drivers/gpu/drm/i915/display/intel_ddi.c +++ b/drivers/gpu/drm/i915/display/intel_ddi.c @@ -3652,6 +3652,8 @@ static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state, */ intel_dp_sink_set_fec_ready(intel_dp, crtc_state); + intel_dp_check_frl_training(intel_dp, crtc_state); + /* * 7.i Follow DisplayPort specification training sequence (see notes for * failure handling) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 2aa07d82bc97..f8f82fe8c52a 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -4283,6 +4283,7 @@ static void intel_enable_dp(struct intel_atomic_state *state, intel_dp_set_power(intel_dp, DP_SET_POWER_D0); intel_dp_configure_protocol_converter(intel_dp); + intel_dp_check_frl_training(intel_dp, pipe_config); intel_dp_start_link_train(intel_dp, pipe_config); intel_dp_stop_link_train(intel_dp, pipe_config); @@ -6204,6 +6205,7 @@ int intel_dp_retrain_link(struct intel_encoder *encoder, !intel_dp_mst_is_master_trans(crtc_state)) continue; + intel_dp_check_frl_training(intel_dp, crtc_state); intel_dp_start_link_train(intel_dp, crtc_state); intel_dp_stop_link_train(intel_dp, crtc_state); break; -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 11/16] drm/i915: Add support for enabling link status and recovery
From: Swati Sharma
In this patch enables support for detecting link failures between
PCON and HDMI sink in i915 driver. HDMI link loss indication to
upstream DP source is indicated via IRQ_HPD. This is followed by
reading of HDMI link configuration status (HDMI_TX_LINK_ACTIVE_STATUS).
If the PCON → HDMI 2.1 link status is off; reinitiate frl link
training to recover. Also, report HDMI FRL link error count range for
each individual FRL active lane is indicated by
DOWNSTREAM_HDMI_ERROR_STATUS_LN registers.
v2: Checked for dpcd read and write failures and added debug message.
(Uma Shankar)
v3: rearranged code to re-start FRL link training or fall back to
TMDS mode.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 68 +++--
1 file changed, 65 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f8f82fe8c52a..0616779d858e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6032,6 +6032,43 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return link_ok;
}
+static void
+intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp)
+{
+ bool is_active;
+ u8 buf = 0;
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+ is_active = drm_dp_pcon_hdmi_link_active(_dp->aux);
+ if (intel_dp->frl.is_trained && !is_active) {
+ if (drm_dp_dpcd_readb(_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, ) < 0)
+ return;
+
+ buf &= ~DP_PCON_ENABLE_HDMI_LINK;
+ if (drm_dp_dpcd_writeb(_dp->aux,
DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
+ return;
+
+ drm_dp_pcon_hdmi_frl_link_error_count(_dp->aux,
_dp->attached_connector->base);
+
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
+
+ /* Restart FRL training or fall back to TMDS mode */
+ if (intel_dp_pcon_start_frl_training(intel_dp) < 0) {
+ int ret, mode;
+
+ drm_dbg(_priv->drm, "Couldnt restart FRL,
continuing with TMDS mode\n");
+ ret = drm_dp_pcon_reset_frl_config(_dp->aux);
+ mode = drm_dp_pcon_hdmi_link_mode(_dp->aux, NULL);
+
+ if (ret < 0 || mode != DP_PCON_HDMI_MODE_TMDS)
+ drm_dbg(_priv->drm, "Issue with PCON, cannot set
TMDS mode\n");
+ } else {
+ drm_dbg(_priv->drm, "FRL Re-training Completed\n");
+ }
+ }
+}
+
static bool
intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
{
@@ -6397,7 +6434,7 @@ intel_dp_hotplug(struct intel_encoder *encoder,
return state;
}
-static void intel_dp_check_service_irq(struct intel_dp *intel_dp)
+static void intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 val;
@@ -6421,6 +6458,30 @@ static void intel_dp_check_service_irq(struct intel_dp
*intel_dp)
drm_dbg_kms(>drm, "Sink specific irq unhandled\n");
}
+static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ u8 val;
+
+ if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
+ return;
+
+ if (drm_dp_dpcd_readb(_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, ) != 1 ||
!val) {
+ drm_dbg_kms(>drm, "Error in reading link service irq
vector\n");
+ return;
+ }
+
+ if (drm_dp_dpcd_writeb(_dp->aux,
+ DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1) {
+ drm_dbg_kms(>drm, "Error in writing link service irq
vector\n");
+ return;
+ }
+
+ if (val & HDMI_LINK_STATUS_CHANGED)
+ intel_dp_handle_hdmi_link_status_change(intel_dp);
+}
+
/*
* According to DP spec
* 5.1.2:
@@ -6460,7 +6521,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
return false;
}
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
+ intel_dp_check_link_service_irq(intel_dp);
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(_dp->aux);
@@ -6894,7 +6956,7 @@ intel_dp_detect(struct drm_connector *connector,
to_intel_connector(connector)->detect_edid)
status = connector_status_connected;
- intel_dp_check_service_irq(intel_dp);
+ intel_dp_check_device_service_irq(intel_dp);
out:
if (status != connector_status_connected && !intel_dp->is_mst)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH v4 09/16] drm/i915: Add support for starting FRL training for HDMI2.1 via PCON
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
v2: As suggested by Uma Shankar:
-renamed couple of variables for better clarity
-tweaked the macros used for correct semantics for true/false
-fixed other styling issues.
v3: Completed the TODO for condition for going to FRL mode.
Modified the condition to determine the required FRL b/w
based only on the Pcon and Sink's max FRL values.
Moved the frl structure initialization to intel_dp_init_connector().
v4: Fixed typo in initialization of frl structure.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar (v2)
---
.../drm/i915/display/intel_display_types.h| 7 +
drivers/gpu/drm/i915/display/intel_dp.c | 174 ++
drivers/gpu/drm/i915/display/intel_dp.h | 3 +
3 files changed, 184 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index f77a15303223..c624c2f9b624 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1339,6 +1339,11 @@ struct intel_dp_compliance {
u8 test_lane_count;
};
+struct intel_dp_pcon_frl {
+ bool is_trained;
+ int trained_rate_gbps;
+};
+
struct intel_dp {
i915_reg_t output_reg;
u32 DP;
@@ -1461,6 +1466,8 @@ struct intel_dp {
bool hobl_failed;
bool hobl_active;
+
+ struct intel_dp_pcon_frl frl;
};
enum lspcon_vendor {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2c3572891596..2aa07d82bc97 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3887,6 +3887,8 @@ static void intel_disable_dp(struct intel_atomic_state
*state,
intel_edp_backlight_off(old_conn_state);
intel_dp_set_power(intel_dp, DP_SET_POWER_D3);
intel_edp_panel_off(intel_dp);
+ intel_dp->frl.is_trained = false;
+ intel_dp->frl.trained_rate_gbps = 0;
}
static void g4x_disable_dp(struct intel_atomic_state *state,
@@ -3982,6 +3984,175 @@ cpt_set_link_train(struct intel_dp *intel_dp,
intel_de_posting_read(dev_priv, intel_dp->output_reg);
}
+static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
+{
+ int bw_gbps[] = {9, 18, 24, 32, 40, 48};
+ int i;
+
+ for (i = ARRAY_SIZE(bw_gbps) - 1; i >= 0; i--) {
+ if (frl_bw_mask & (1 << i))
+ return bw_gbps[i];
+ }
+ return 0;
+}
+
+static int intel_dp_pcon_set_frl_mask(int max_frl)
+{
+
+ switch (max_frl) {
+ case 48:
+ return DP_PCON_FRL_BW_MASK_48GBPS;
+ case 40:
+ return DP_PCON_FRL_BW_MASK_40GBPS;
+ case 32:
+ return DP_PCON_FRL_BW_MASK_32GBPS;
+ case 24:
+ return DP_PCON_FRL_BW_MASK_24GBPS;
+ case 18:
+ return DP_PCON_FRL_BW_MASK_18GBPS;
+ case 9:
+ return DP_PCON_FRL_BW_MASK_9GBPS;
+ }
+
+ return 0;
+}
+
+static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp)
+{
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = _connector->base;
+
+ return (connector->display_info.hdmi.max_frl_rate_per_lane *
+ connector->display_info.hdmi.max_lanes);
+}
+
+static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
+{
+#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
+#define PCON_CONCURRENT_MODE (1 > 0)
+#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
+#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
+#define TIMEOUT_FRL_READY_MS 500
+#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
+
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ int max_frl_bw, max_pcon_frl_bw, max_edid_frl_bw, ret;
+ u8 max_frl_bw_mask = 0, frl_trained_mask;
+ bool is_active;
+
+ ret = drm_dp_pcon_reset_frl_config(_dp->aux);
+ if (ret < 0)
+ return ret;
+
+ max_pcon_frl_bw = intel_dp->dfp.pcon_max_frl_bw;
+ drm_dbg(>drm, "PCON max rate = %d Gbps\n", max_pcon_frl_bw);
+
+ max_edid_frl_bw = intel_dp_hdmi_sink_max_frl(intel_dp);
+ drm_dbg(>drm, "Sink max rate from EDID = %d Gbps\n",
max_edid_frl_bw);
+
+ max_frl_bw = min(max_edid_frl_bw, max_pcon_frl_bw);
+
+ if (max_frl_bw <= 0)
+ return -EINVAL;
+
+ ret = drm_dp_pcon_frl_prepare(_dp->aux, false);
+ if (ret < 0)
+ return ret;
+ /* Wait for PCON to be FRL Ready */
+ wait_for(is_active = drm_dp_pcon_is_frl_ready(_dp->aux) == true,
TIMEOUT_FRL_READY_MS);
+
+ if (!is_active)
+ return -ETIMEDOUT;
+
+ max_frl_bw_mask = intel_dp_pcon_set_frl_mask(max_frl_bw);
+ ret =
[Intel-gfx] [PATCH v4 08/16] drm/i915: Capture max frl rate for PCON in dfp cap structure
HDMI2.1 PCON advertises Max FRL bandwidth supported by the PCON and
by the sink.
This patch captures these in dfp cap structure in intel_dp and uses
these to prune connector modes that cannot be supported by the PCON
and sink FRL bandwidth.
v2: Addressed review comments from Uma Shankar:
-tweaked the comparison of target bw and pcon frl bw to avoid roundup errors.
-minor modification of field names and comments.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 38 ++-
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5bc5bfbc4551..f77a15303223 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1451,6 +1451,7 @@ struct intel_dp {
struct {
int min_tmds_clock, max_tmds_clock;
int max_dotclock;
+ int pcon_max_frl_bw, sink_max_frl_bw;
u8 max_bpc;
bool ycbcr_444_to_420;
} dfp;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index cb5e42c3ecd5..2c3572891596 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -716,6 +716,29 @@ intel_dp_mode_valid_downstream(struct intel_connector
*connector,
const struct drm_display_info *info = >base.display_info;
int tmds_clock;
+ /*
+* If PCON and HDMI2.1 sink both support FRL MODE, check FRL
+* bandwidth constraints.
+*/
+ if (intel_dp->dfp.pcon_max_frl_bw) {
+ int target_bw;
+ int max_frl_bw;
+ int bpp = intel_dp_mode_min_output_bpp(>base, mode);
+
+ target_bw = bpp * target_clock;
+
+ max_frl_bw = min(intel_dp->dfp.pcon_max_frl_bw,
+intel_dp->dfp.sink_max_frl_bw);
+
+ /* converting bw from Gbps to Kbps*/
+ max_frl_bw = max_frl_bw * 100;
+
+ if (target_bw > max_frl_bw)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+ }
+
if (intel_dp->dfp.max_dotclock &&
target_clock > intel_dp->dfp.max_dotclock)
return MODE_CLOCK_HIGH;
@@ -6484,13 +6507,21 @@ intel_dp_update_dfp(struct intel_dp *intel_dp,
intel_dp->downstream_ports,
edid);
+ intel_dp->dfp.pcon_max_frl_bw =
+ drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd,
+ intel_dp->downstream_ports);
+
+ intel_dp->dfp.sink_max_frl_bw =
drm_dp_get_hdmi_sink_max_frl_bw(_dp->aux);
+
drm_dbg_kms(>drm,
- "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS
clock %d-%d\n",
+ "[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS
clock %d-%d, PCON Max FRL BW %dGbps, Sink Max FRL BW %dGbps\n",
connector->base.base.id, connector->base.name,
intel_dp->dfp.max_bpc,
intel_dp->dfp.max_dotclock,
intel_dp->dfp.min_tmds_clock,
- intel_dp->dfp.max_tmds_clock);
+ intel_dp->dfp.max_tmds_clock,
+ intel_dp->dfp.pcon_max_frl_bw,
+ intel_dp->dfp.sink_max_frl_bw);
}
static void
@@ -6582,6 +6613,9 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
intel_dp->dfp.min_tmds_clock = 0;
intel_dp->dfp.max_tmds_clock = 0;
+ intel_dp->dfp.pcon_max_frl_bw = 0;
+ intel_dp->dfp.sink_max_frl_bw = 0;
+
intel_dp->dfp.ycbcr_444_to_420 = false;
connector->base.ycbcr_420_allowed = false;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 07/16] drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion
DP Specification for DP2.0 to HDMI2.1 Pcon specifies support for conversion
of colorspace from RGB to YCbCr.
https://groups.vesa.org/wg/DP/document/previewpdf/15651
This patch adds the relavant registers and helper functions to
get the capability and set the color conversion bits for rgb->ycbcr
conversion through PCON.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 59 +
include/drm/drm_dp_helper.h | 10 +-
2 files changed, 68 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index d0626f57f99c..344662d5c295 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -949,6 +949,35 @@ bool drm_dp_downstream_444_to_420_conversion(const u8
dpcd[DP_RECEIVER_CAP_SIZE]
}
EXPORT_SYMBOL(drm_dp_downstream_444_to_420_conversion);
+/**
+ * drm_dp_downstream_rgb_to_ycbcr_conversion() - determine downstream facing
port
+ * RGB->YCbCr conversion
capability
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: downstream facing port capabilities
+ *
+ * Returns: whether the downstream facing port can convert RGB->YCbCr
+ */
+bool drm_dp_downstream_rgb_to_ycbcr_conversion(const u8
dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4])
+{
+ if (!drm_dp_is_branch(dpcd))
+ return false;
+
+ if (dpcd[DP_DPCD_REV] < 0x13)
+ return false;
+
+ switch (port_cap[0] & DP_DS_PORT_TYPE_MASK) {
+ case DP_DS_PORT_TYPE_HDMI:
+ if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] &
DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
+ return false;
+
+ return port_cap[3] & DP_DS_HDMI_BT601_RGB_YCBCR_CONV;
+ default:
+ return false;
+ }
+}
+EXPORT_SYMBOL(drm_dp_downstream_rgb_to_ycbcr_conversion);
+
/**
* drm_dp_downstream_mode() - return a mode for downstream facing port
* @dev: DRM device
@@ -3140,3 +3169,33 @@ int drm_dp_pcon_pps_override_param(struct drm_dp_aux
*aux, u8 pps_param[6])
return 0;
}
EXPORT_SYMBOL(drm_dp_pcon_pps_override_param);
+
+/*
+ * drm_dp_pcon_convert_rgb_to_ycbcr() - Configure the PCon to convert RGB to
Ycbcr
+ * @aux: displayPort AUX channel
+ * @color_spc: Color space conversion type
+ *
+ * Returns 0 on success, else returns negative error code.
+ */
+int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux *aux, u8 color_spc)
+{
+ int ret;
+ u8 buf;
+
+ if (color_spc != DP_CONVERSION_BT601_RGB_YCBCR_ENABLE ||
+ color_spc != DP_CONVERSION_BT709_RGB_YCBCR_ENABLE ||
+ color_spc != DP_CONVERSION_BT2020_RGB_YCBCR_ENABLE)
+ return -EINVAL;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, );
+ if (ret < 0)
+ return ret;
+
+ buf |= color_spc;
+ ret = drm_dp_dpcd_writeb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, buf);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_convert_rgb_to_ycbcr);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 347b4e1a55b4..1b3d54ed7a78 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -431,6 +431,9 @@ struct drm_device;
# define DP_DS_HDMI_YCBCR420_PASS_THROUGH (1 << 2)
# define DP_DS_HDMI_YCBCR444_TO_422_CONV(1 << 3)
# define DP_DS_HDMI_YCBCR444_TO_420_CONV(1 << 4)
+# define DP_DS_HDMI_BT601_RGB_YCBCR_CONV(1 << 5)
+# define DP_DS_HDMI_BT709_RGB_YCBCR_CONV(1 << 6)
+# define DP_DS_HDMI_BT2020_RGB_YCBCR_CONV (1 << 7)
#define DP_MAX_DOWNSTREAM_PORTS0x10
@@ -1217,7 +1220,9 @@ struct drm_device;
# define DP_PCON_ENC_PPS_OVERRIDE_DISABLED 0
# define DP_PCON_ENC_PPS_OVERRIDE_EN_PARAMS 1
# define DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER 2
-
+# define DP_CONVERSION_BT601_RGB_YCBCR_ENABLE (1 << 4)
+# define DP_CONVERSION_BT709_RGB_YCBCR_ENABLE (1 << 5)
+# define DP_CONVERSION_BT2020_RGB_YCBCR_ENABLE (1 << 6)
/* PCON Downstream HDMI ERROR Status per Lane */
#define DP_PCON_HDMI_ERROR_STATUS_LN0 0x3037
@@ -2178,5 +2183,8 @@ int drm_dp_pcon_dsc_bpp_incr(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE
int drm_dp_pcon_pps_default(struct drm_dp_aux *aux);
int drm_dp_pcon_pps_override_buf(struct drm_dp_aux *aux, u8 pps_buf[128]);
int drm_dp_pcon_pps_override_param(struct drm_dp_aux *aux, u8 pps_param[6]);
+bool drm_dp_downstream_rgb_to_ycbcr_conversion(const u8
dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4]);
+int drm_dp_pcon_convert_rgb_to_ycbcr(struct drm_dp_aux *aux, u8 color_spc);
#endif /* _DRM_DP_HELPER_H_ */
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 06/16] drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon
This patch adds registers for getting DSC encoder capability for
a HDMI2.1 PCon. It also addes helper functions to configure
DSC between the PCON and HDMI2.1 sink.
v2: Corrected offset for DSC encoder bpc and minor changes.
Also added helper functions for getting pcon dsc encoder capabilities
as suggested by Uma Shankar.
v3: Only setting the DSC bits for the Protocol Convertor control
registers, avoiding overwritining color conversion bits.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar (v2)
---
drivers/gpu/drm/drm_dp_helper.c | 203
include/drm/drm_dp_helper.h | 114 ++
2 files changed, 317 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5a9303de9ac2..d0626f57f99c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2937,3 +2937,206 @@ void drm_dp_pcon_hdmi_frl_link_error_count(struct
drm_dp_aux *aux,
}
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
+
+/*
+ * drm_dp_pcon_enc_is_dsc_1_2 - Does PCON Encoder supports DSC 1.2
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns true is PCON encoder is DSC 1.2 else returns false.
+ */
+bool drm_dp_pcon_enc_is_dsc_1_2(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 buf;
+ u8 major_v, minor_v;
+
+ buf = pcon_dsc_dpcd[DP_PCON_DSC_VERSION - DP_PCON_DSC_ENCODER];
+ major_v = (buf & DP_PCON_DSC_MAJOR_MASK) >> DP_PCON_DSC_MAJOR_SHIFT;
+ minor_v = (buf & DP_PCON_DSC_MINOR_MASK) >> DP_PCON_DSC_MINOR_SHIFT;
+
+ if (major_v == 1 && minor_v == 2)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_enc_is_dsc_1_2);
+
+/*
+ * drm_dp_pcon_dsc_max_slices - Get max slices supported by PCON DSC Encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns maximum no. of slices supported by the PCON DSC Encoder.
+ */
+int drm_dp_pcon_dsc_max_slices(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 slice_cap1, slice_cap2;
+
+ slice_cap1 = pcon_dsc_dpcd[DP_PCON_DSC_SLICE_CAP_1 -
DP_PCON_DSC_ENCODER];
+ slice_cap2 = pcon_dsc_dpcd[DP_PCON_DSC_SLICE_CAP_2 -
DP_PCON_DSC_ENCODER];
+
+ if (slice_cap2 & DP_PCON_DSC_24_PER_DSC_ENC)
+ return 24;
+ if (slice_cap2 & DP_PCON_DSC_20_PER_DSC_ENC)
+ return 20;
+ if (slice_cap2 & DP_PCON_DSC_16_PER_DSC_ENC)
+ return 16;
+ if (slice_cap1 & DP_PCON_DSC_12_PER_DSC_ENC)
+ return 12;
+ if (slice_cap1 & DP_PCON_DSC_10_PER_DSC_ENC)
+ return 10;
+ if (slice_cap1 & DP_PCON_DSC_8_PER_DSC_ENC)
+ return 8;
+ if (slice_cap1 & DP_PCON_DSC_6_PER_DSC_ENC)
+ return 6;
+ if (slice_cap1 & DP_PCON_DSC_4_PER_DSC_ENC)
+ return 4;
+ if (slice_cap1 & DP_PCON_DSC_2_PER_DSC_ENC)
+ return 2;
+ if (slice_cap1 & DP_PCON_DSC_1_PER_DSC_ENC)
+ return 1;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_max_slices);
+
+/*
+ * drm_dp_pcon_dsc_max_slice_width() - Get max slice width for Pcon DSC encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns maximum width of the slices in pixel width i.e. no. of pixels x 320.
+ */
+int drm_dp_pcon_dsc_max_slice_width(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 buf;
+
+ buf = pcon_dsc_dpcd[DP_PCON_DSC_MAX_SLICE_WIDTH - DP_PCON_DSC_ENCODER];
+
+ return buf * DP_DSC_SLICE_WIDTH_MULTIPLIER;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_max_slice_width);
+
+/*
+ * drm_dp_pcon_dsc_bpp_incr() - Get bits per pixel increment for PCON DSC
encoder
+ * @pcon_dsc_dpcd: DSC capabilities of the PCON DSC Encoder
+ *
+ * Returns the bpp precision supported by the PCON encoder.
+ */
+int drm_dp_pcon_dsc_bpp_incr(const u8
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
+{
+ u8 buf;
+
+ buf = pcon_dsc_dpcd[DP_PCON_DSC_BPP_INCR - DP_PCON_DSC_ENCODER];
+
+ switch (buf & DP_PCON_DSC_BPP_INCR_MASK) {
+ case DP_PCON_DSC_ONE_16TH_BPP:
+ return 16;
+ case DP_PCON_DSC_ONE_8TH_BPP:
+ return 8;
+ case DP_PCON_DSC_ONE_4TH_BPP:
+ return 4;
+ case DP_PCON_DSC_ONE_HALF_BPP:
+ return 2;
+ case DP_PCON_DSC_ONE_BPP:
+ return 1;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_pcon_dsc_bpp_incr);
+
+static
+int drm_dp_pcon_configure_dsc_enc(struct drm_dp_aux *aux, u8 pps_buf_config)
+{
+ u8 buf;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PROTOCOL_CONVERTER_CONTROL_2, );
+ if (ret < 0)
+ return ret;
+
+ buf |= DP_PCON_ENABLE_DSC_ENCODER;
+
+ if (pps_buf_config <= DP_PCON_ENC_PPS_OVERRIDE_EN_BUFFER) {
+ buf &= ~DP_PCON_ENCODER_PPS_OVERRIDE_MASK;
+ buf |= pps_buf_config << 2;
+ }
+
+
[Intel-gfx] [PATCH v4 05/16] drm/dp_helper: Add support for link failure detection
From: Swati Sharma
There are specific DPCDs defined for detecting link failures between
the PCON and HDMI sink and check the link status. In case of link
failure, PCON will communicate the same using an IRQ_HPD to source.
HDMI sink would have indicated the same to PCON using SCDC interrupt
mechanism. While source can always read final HDMI sink's status using
I2C over AUX, it is easier and faster to read the PCONs already read
HDMI sink status registers.
This patch adds the DPCDs required for link failure detection and
provide a helper function for printing error count/lane which might
help in debugging the link failure issues.
v2: Addressed comments from Uma Shankar:
-rephrased the commit message, as per the code.
-fixed styling issues
-added documentation for the helper function.
Signed-off-by: Swati Sharma
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 39 +
include/drm/drm_dp_helper.h | 17 ++
2 files changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 0aba865ff6be..5a9303de9ac2 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2898,3 +2898,42 @@ int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux,
u8 *frl_trained_mask)
return mode;
}
EXPORT_SYMBOL(drm_dp_pcon_hdmi_link_mode);
+
+/**
+ * drm_dp_pcon_hdmi_frl_link_error_count() - print the error count per lane
+ * during link failure between PCON and HDMI sink
+ * @aux: DisplayPort AUX channel
+ * @connector: DRM connector
+ * code.
+ **/
+
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector)
+{
+ u8 buf, error_count;
+ int i, num_error;
+ struct drm_hdmi_info *hdmi = >display_info.hdmi;
+
+ for (i = 0; i < hdmi->max_lanes; i++) {
+ if (drm_dp_dpcd_readb(aux, DP_PCON_HDMI_ERROR_STATUS_LN0 + i,
) < 0)
+ return;
+
+ error_count = buf & DP_PCON_HDMI_ERROR_COUNT_MASK;
+ switch (error_count) {
+ case DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS:
+ num_error = 100;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS:
+ num_error = 10;
+ break;
+ case DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS:
+ num_error = 3;
+ break;
+ default:
+ num_error = 0;
+ }
+
+ DRM_ERROR("More than %d errors since the last read for lane
%d", num_error, i);
+ }
+}
+EXPORT_SYMBOL(drm_dp_pcon_hdmi_frl_link_error_count);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 6afd314a33b8..ab6b7e4fb9ff 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -946,6 +946,11 @@ struct drm_device;
# define DP_CEC_IRQ (1 << 2)
#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */
+# define RX_CAP_CHANGED (1 << 0)
+# define LINK_STATUS_CHANGED (1 << 1)
+# define STREAM_STATUS_CHANGED (1 << 2)
+# define HDMI_LINK_STATUS_CHANGED(1 << 3)
+# define CONNECTED_OFF_ENTRY_REQUESTED (1 << 4)
#define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */
# define DP_PSR_LINK_CRC_ERROR (1 << 0)
@@ -1130,6 +1135,16 @@ struct drm_device;
#define DP_PROTOCOL_CONVERTER_CONTROL_20x3052 /* DP 1.3 */
# define DP_CONVERSION_TO_YCBCR422_ENABLE (1 << 0) /* DP 1.3 */
+/* PCON Downstream HDMI ERROR Status per Lane */
+#define DP_PCON_HDMI_ERROR_STATUS_LN0 0x3037
+#define DP_PCON_HDMI_ERROR_STATUS_LN1 0x3038
+#define DP_PCON_HDMI_ERROR_STATUS_LN2 0x3039
+#define DP_PCON_HDMI_ERROR_STATUS_LN3 0x303A
+# define DP_PCON_HDMI_ERROR_COUNT_MASK (0x7 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_THREE_PLUS (1 << 0)
+# define DP_PCON_HDMI_ERROR_COUNT_TEN_PLUS (1 << 1)
+# define DP_PCON_HDMI_ERROR_COUNT_HUNDRED_PLUS (1 << 2)
+
/* HDCP 1.3 and HDCP 2.2 */
#define DP_AUX_HDCP_BKSV 0x68000
#define DP_AUX_HDCP_RI_PRIME 0x68005
@@ -2047,5 +2062,7 @@ int drm_dp_pcon_frl_enable(struct drm_dp_aux *aux);
bool drm_dp_pcon_hdmi_link_active(struct drm_dp_aux *aux);
int drm_dp_pcon_hdmi_link_mode(struct drm_dp_aux *aux, u8 *frl_trained_mask);
+void drm_dp_pcon_hdmi_frl_link_error_count(struct drm_dp_aux *aux,
+ struct drm_connector *connector);
#endif /* _DRM_DP_HELPER_H_ */
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 04/16] drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
v2: Fixed typos and addressed other review comments from Uma Shankar.
-changed the commit message for better clarity (Uma Shankar)
-removed unnecessary argument supplied to a drm helper function.
-fixed return value for max frl read from pcon.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 302
include/drm/drm_dp_helper.h | 81 +
2 files changed, 383 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5bd0934004e3..0aba865ff6be 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -2596,3 +2596,305 @@ void drm_dp_vsc_sdp_log(const char *level, struct
device *dev,
#undef DP_SDP_LOG
}
EXPORT_SYMBOL(drm_dp_vsc_sdp_log);
+
+/**
+ * drm_dp_get_pcon_max_frl_bw() - maximum frl supported by PCON
+ * @dpcd: DisplayPort configuration data
+ * @port_cap: port capabilities
+ *
+ * Returns maximum frl bandwidth supported by PCON in GBPS,
+ * returns 0 if not supported.
+ **/
+int drm_dp_get_pcon_max_frl_bw(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
+ const u8 port_cap[4])
+{
+ int bw;
+ u8 buf;
+
+ buf = port_cap[2];
+ bw = buf & DP_PCON_MAX_FRL_BW;
+
+ switch (bw) {
+ case DP_PCON_MAX_9GBPS:
+ return 9;
+ case DP_PCON_MAX_18GBPS:
+ return 18;
+ case DP_PCON_MAX_24GBPS:
+ return 24;
+ case DP_PCON_MAX_32GBPS:
+ return 32;
+ case DP_PCON_MAX_40GBPS:
+ return 40;
+ case DP_PCON_MAX_48GBPS:
+ return 48;
+ case DP_PCON_MAX_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_pcon_max_frl_bw);
+
+/**
+ * drm_dp_get_hdmi_sink_max_frl_bw() - maximum frl supported by HDMI Sink
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns maximum frl bandwidth supported by HDMI in Gbps on success,
+ * returns 0, if not supported.
+ **/
+int drm_dp_get_hdmi_sink_max_frl_bw(struct drm_dp_aux *aux)
+{
+ u8 buf;
+ int bw, ret;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_SINK, );
+ if (ret < 0)
+ return 0;
+ bw = buf & DP_HDMI_SINK_LINK_BW;
+
+ switch (bw) {
+ case DP_HDMI_SINK_BW_9GBPS:
+ return 9;
+ case DP_HDMI_SINK_BW_18GBPS:
+ return 18;
+ case DP_HDMI_SINK_BW_24GBPS:
+ return 24;
+ case DP_HDMI_SINK_BW_32GBPS:
+ return 32;
+ case DP_HDMI_SINK_BW_40GBPS:
+ return 40;
+ case DP_HDMI_SINK_BW_48GBPS:
+ return 48;
+ case DP_HDMI_SINK_BW_0GBPS:
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_hdmi_sink_max_frl_bw);
+
+/**
+ * drm_dp_pcon_frl_prepare() - Prepare PCON for FRL.
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+int drm_dp_pcon_frl_prepare(struct drm_dp_aux *aux, bool enable_frl_ready_hpd)
+{
+ int ret;
+ u8 buf = DP_PCON_ENABLE_SOURCE_CTL_MODE |
+DP_PCON_ENABLE_LINK_FRL_MODE;
+
+ if (enable_frl_ready_hpd)
+ buf |= DP_PCON_ENABLE_HPD_READY;
+
+ ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_dp_pcon_frl_prepare);
+
+/**
+ * drm_dp_pcon_is_frl_ready() - Is PCON ready for FRL
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns true if success, else returns false.
+ **/
+bool drm_dp_pcon_is_frl_ready(struct drm_dp_aux *aux)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_TX_LINK_STATUS, );
+ if (ret < 0)
+ return false;
+
+ if (buf & DP_PCON_FRL_READY)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
+
+/**
+ * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
+ * @aux: DisplayPort AUX channel
+ * @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI sink
+ * @concurrent_mode: true if concurrent mode or operation is required,
+ * false otherwise.
+ *
+ * Returns 0 if success, else returns negative error code.
+ **/
+
+int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
+ bool concurrent_mode)
+{
+ int ret;
+ u8 buf;
+
+ ret = drm_dp_dpcd_readb(aux, DP_PCON_HDMI_LINK_CONFIG_1, );
+ if (ret < 0)
+ return ret;
+
+ if (concurrent_mode)
+ buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
+ else
+ buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
+
+ switch (max_frl_gbps) {
+ case 9:
+ buf |= DP_PCON_ENABLE_MAX_BW_9GBPS;
+
[Intel-gfx] [PATCH v4 03/16] drm/edid: Parse DSC1.2 cap fields from HFVSDB block
This patch parses HFVSDB fields for DSC1.2 capabilities of an
HDMI2.1 sink. These fields are required by a source to understand the
DSC capability of the sink, to set appropriate PPS parameters,
before transmitting compressed data stream.
v2: Addressed following issues as suggested by Uma Shankar:
-Added a new struct for hdmi dsc cap
-Fixed bugs in macros usage.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 59 +
include/drm/drm_connector.h | 43 +++
2 files changed, 102 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e657c321d9e4..ca368df2e5ac 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4941,11 +4941,70 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
if (hf_vsdb[7]) {
u8 max_frl_rate;
+ u8 dsc_max_frl_rate;
+ u8 dsc_max_slices;
+ struct drm_hdmi_dsc_cap *hdmi_dsc = >dsc_cap;
DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
drm_get_max_frl_rate(max_frl_rate, >max_lanes,
>max_frl_rate_per_lane);
+ hdmi_dsc->v_1p2 = hf_vsdb[11] & DRM_EDID_DSC_1P2;
+
+ if (hdmi_dsc->v_1p2) {
+ hdmi_dsc->native_420 = hf_vsdb[11] &
DRM_EDID_DSC_NATIVE_420;
+ hdmi_dsc->all_bpp = hf_vsdb[11] & DRM_EDID_DSC_ALL_BPP;
+
+ if (hf_vsdb[11] & DRM_EDID_DSC_16BPC)
+ hdmi_dsc->bpc_supported = 16;
+ else if (hf_vsdb[11] & DRM_EDID_DSC_12BPC)
+ hdmi_dsc->bpc_supported = 12;
+ else if (hf_vsdb[11] & DRM_EDID_DSC_10BPC)
+ hdmi_dsc->bpc_supported = 10;
+ else
+ hdmi_dsc->bpc_supported = 0;
+
+ dsc_max_frl_rate = (hf_vsdb[12] &
DRM_EDID_DSC_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(dsc_max_frl_rate,
_dsc->max_lanes,
+ _dsc->max_frl_rate_per_lane);
+ hdmi_dsc->total_chunk_kbytes = hf_vsdb[13] &
DRM_EDID_DSC_TOTAL_CHUNK_KBYTES;
+
+ dsc_max_slices = hf_vsdb[12] & DRM_EDID_DSC_MAX_SLICES;
+ switch (dsc_max_slices) {
+ case 1:
+ hdmi_dsc->max_slices = 1;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 2:
+ hdmi_dsc->max_slices = 2;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 3:
+ hdmi_dsc->max_slices = 4;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 4:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 340;
+ break;
+ case 5:
+ hdmi_dsc->max_slices = 8;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 6:
+ hdmi_dsc->max_slices = 12;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 7:
+ hdmi_dsc->max_slices = 16;
+ hdmi_dsc->clk_per_slice = 400;
+ break;
+ case 0:
+ default:
+ hdmi_dsc->max_slices = 0;
+ hdmi_dsc->clk_per_slice = 0;
+ }
+ }
}
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1a3b4776b458..1922b278ffad 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -175,6 +175,46 @@ struct drm_scdc {
struct drm_scrambling scrambling;
};
+/**
+ * struct drm_hdmi_dsc_cap - DSC capabilities of HDMI sink
+ *
+ * Describes the DSC support provided by HDMI 2.1 sink.
+ * The information is fetched fom additional HFVSDB blocks defined
+ * for HDMI 2.1.
+ */
+struct drm_hdmi_dsc_cap {
+ /** @v_1p2: flag for dsc1.2 version support by sink */
+ bool v_1p2;
+
+ /** @native_420: Does sink support DSC with 4:2:0 compression */
+ bool native_420;
+
+ /**
+* @all_bpp: Does sink support all bpp with 4:4:4: or 4:2:2
+
[Intel-gfx] [PATCH v4 02/16] drm/edid: Parse MAX_FRL field from HFVSDB block
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
v2: Fixed minor bugs, and removed extra wrapper function (Uma Shankar)
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 44 +
include/drm/drm_connector.h | 6 +
2 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 74f5a3197214..e657c321d9e4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4851,6 +4851,41 @@ static void drm_parse_vcdb(struct drm_connector
*connector, const u8 *db)
info->rgb_quant_range_selectable = true;
}
+static
+void drm_get_max_frl_rate(int max_frl_rate, u8 *max_lanes, u8
*max_rate_per_lane)
+{
+ switch (max_frl_rate) {
+ case 1:
+ *max_lanes = 3;
+ *max_rate_per_lane = 3;
+ break;
+ case 2:
+ *max_lanes = 3;
+ *max_rate_per_lane = 6;
+ break;
+ case 3:
+ *max_lanes = 4;
+ *max_rate_per_lane = 6;
+ break;
+ case 4:
+ *max_lanes = 4;
+ *max_rate_per_lane = 8;
+ break;
+ case 5:
+ *max_lanes = 4;
+ *max_rate_per_lane = 10;
+ break;
+ case 6:
+ *max_lanes = 4;
+ *max_rate_per_lane = 12;
+ break;
+ case 0:
+ default:
+ *max_lanes = 0;
+ *max_rate_per_lane = 0;
+ }
+}
+
static void drm_parse_ycbcr420_deep_color_info(struct drm_connector *connector,
const u8 *db)
{
@@ -4904,6 +4939,15 @@ static void drm_parse_hdmi_forum_vsdb(struct
drm_connector *connector,
}
}
+ if (hf_vsdb[7]) {
+ u8 max_frl_rate;
+
+ DRM_DEBUG_KMS("hdmi_21 sink detected. parsing edid\n");
+ max_frl_rate = (hf_vsdb[7] & DRM_EDID_MAX_FRL_RATE_MASK) >> 4;
+ drm_get_max_frl_rate(max_frl_rate, >max_lanes,
+ >max_frl_rate_per_lane);
+ }
+
drm_parse_ycbcr420_deep_color_info(connector, hf_vsdb);
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fcdc58d8b88b..1a3b4776b458 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -207,6 +207,12 @@ struct drm_hdmi_info {
/** @y420_dc_modes: bitmap of deep color support index */
u8 y420_dc_modes;
+
+ /** @max_frl_rate_per_lane: support fixed rate link */
+ u8 max_frl_rate_per_lane;
+
+ /** @max_lanes: supported by sink */
+ u8 max_lanes;
};
/**
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 01/16] drm/edid: Add additional HFVSDB fields for HDMI2.1
From: Swati Sharma
The HDMI2.1 extends HFVSDB (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields that are required for
HDMI2.1.
v2: Minor fixes + consistent naming for DPCD register masks
(Uma Shankar)
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
Reviewed-by: Uma Shankar
---
include/drm/drm_edid.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index e97daf6ffbb1..a158f585f658 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -229,6 +229,36 @@ struct detailed_timing {
DRM_EDID_YCBCR420_DC_36 | \
DRM_EDID_YCBCR420_DC_30)
+/* HDMI 2.1 additional fields */
+#define DRM_EDID_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_FAPA_START_LOCATION (1 << 0)
+#define DRM_EDID_ALLM (1 << 1)
+#define DRM_EDID_FVA (1 << 2)
+
+/* Deep Color specific */
+#define DRM_EDID_DC_30BIT_420 (1 << 0)
+#define DRM_EDID_DC_36BIT_420 (1 << 1)
+#define DRM_EDID_DC_48BIT_420 (1 << 2)
+
+/* VRR specific */
+#define DRM_EDID_CNMVRR(1 << 3)
+#define DRM_EDID_CINEMA_VRR(1 << 4)
+#define DRM_EDID_MDELTA(1 << 5)
+#define DRM_EDID_VRR_MAX_UPPER_MASK0xc0
+#define DRM_EDID_VRR_MAX_LOWER_MASK0xff
+#define DRM_EDID_VRR_MIN_MASK 0x3f
+
+/* DSC specific */
+#define DRM_EDID_DSC_10BPC (1 << 0)
+#define DRM_EDID_DSC_12BPC (1 << 1)
+#define DRM_EDID_DSC_16BPC (1 << 2)
+#define DRM_EDID_DSC_ALL_BPP (1 << 3)
+#define DRM_EDID_DSC_NATIVE_420(1 << 6)
+#define DRM_EDID_DSC_1P2 (1 << 7)
+#define DRM_EDID_DSC_MAX_FRL_RATE_MASK 0xf0
+#define DRM_EDID_DSC_MAX_SLICES0xf
+#define DRM_EDID_DSC_TOTAL_CHUNK_KBYTES0x3f
+
/* ELD Header Block */
#define DRM_ELD_HEADER_BLOCK_SIZE 4
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 00/16] Add support for DP-HDMI2.1 PCON
This patch series attempts to add support for a DP-HDMI2.1 Protocol Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata E5 to DisplayPort_v2.0: https://vesa.org/join-vesamemberships/member-downloads/?action=stamp=42299 The details are mentioned in: VESA DP-to-HDMI PCON Specification Standalone Document https://groups.vesa.org/wg/DP/document/15651 This series starts with adding support for FRL (Fixed Rate Link) Training between the PCON and HDMI2.1 sink. As per HDMI2.1 specification, a new data-channel or lane is added in FRL mode, by repurposing the TMDS clock Channel. Through FRL, higher bit-rate can be supported, ie. up to 12 Gbps/lane (48 Gbps over 4 lanes). With these patches, the HDMI2.1 PCON can be configured to achieve FRL training based on the maximum FRL rate supported by the panel, source and the PCON. The approach is to add the support for FRL training between PCON and HDMI2.1 sink and gradually add other blocks for supporting higher resolutions and other HDMI2.1 features, that can be supported by pcon for the sources that do not natively support HDMI2.1. This is done before the DP Link training between the source and PCON is started. In case of FRL training is not achieved, the PCON will work in the regular TMDS mode, without HDMI2.1 feature support. Any interruption in FRL training between the PCON and HDMI2.1 sink is notified through IRQ_HPD. On receiving the IRQ_HPD the concerned DPCD registers are read and FRL training is re-attempted. Currently, we have tested the FRL training and are able to enable 4K display with TGL Platform + Realtek PCON RTD2173 with HDMI2.1 supporting panel. v2: Addressed review comments and re-organized patches as suggested in comments on RFC patches. v3: Addressed review comments on previous version. v4: Added support for RGB->YCBCR conversion through PCON Ankit Nautiyal (12): drm/edid: Parse DSC1.2 cap fields from HFVSDB block drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON drm/dp_helper: Add support for Configuring DSC for HDMI2.1 Pcon drm/dp_helper: Add helpers to configure PCONs RGB-YCbCr Conversion drm/i915: Capture max frl rate for PCON in dfp cap structure drm/i915: Add support for starting FRL training for HDMI2.1 via PCON drm/i915: Check for FRL training before DP Link training drm/i915: Read DSC capabilities of the HDMI2.1 PCON encoder drm/i915: Add helper functions for calculating DSC parameters for HDMI2.1 drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding drm/i915: Let PCON convert from RGB to YUV if it can drm/i915: Enable PCON configuration for Color Conversion for TGL Swati Sharma (4): drm/edid: Add additional HFVSDB fields for HDMI2.1 drm/edid: Parse MAX_FRL field from HFVSDB block drm/dp_helper: Add support for link failure detection drm/i915: Add support for enabling link status and recovery drivers/gpu/drm/drm_dp_helper.c | 603 ++ drivers/gpu/drm/drm_edid.c| 103 +++ drivers/gpu/drm/i915/display/intel_ddi.c | 4 + .../drm/i915/display/intel_display_types.h| 10 + drivers/gpu/drm/i915/display/intel_dp.c | 457 - drivers/gpu/drm/i915/display/intel_dp.h | 5 + drivers/gpu/drm/i915/display/intel_hdmi.c | 233 +++ drivers/gpu/drm/i915/display/intel_hdmi.h | 7 + include/drm/drm_connector.h | 49 ++ include/drm/drm_dp_helper.h | 220 +++ include/drm/drm_edid.h| 30 + 11 files changed, 1704 insertions(+), 17 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC-v1 02/16] drm/i915/pxp: Enable PXP irq worker and callback stub
Hi Joonas,
All the modification will be included in rev2. Thanks!
> We should take >pxp as the first parameter and keep a tight scope.
DONE
> Again, we should be taking intel_pxp as parameter to tighten the scope.
DONE
>Instead of writing to register that is indicated to be "reserved" (RSVD), we
>should properly document the register in i915_reg.h and the comment should not
>be needed.
DONE, remove RSVD from its name and add document in i915_reg.h
> This INFO message is wrongly placed, either it should say "initializing" and
> be at the beginning or "initialized" and be at the end. Also see previous
> patch for more comments.
DONE,
>_ptr is a tautology, we can already see it's apointer.
DONE, remove the "_ptr"
> We should go from intel_pxp to intel_gt to i915 here, once the struct
> intel_pxp member is moved inside intel_gt
DONE, yes now pxp is in intel_gt
>The mapping between the callbacks and the hardware events are unclear.
>These all seem like display related events, so we probably need a split
>between the GT and display PXP code.
>It's hard to review as this only adds stubs and no actual flow. I think
>teardown interrupt handling should come later in the series after init and
>other code has been added.
Personally I would still prefer to put this in gt instead of display, because
when teardown happen it means the "crypto engine" (This should belong to gt)
has loss the key for display.
>This INFO message is wrongly placed, either it should say "initializing"
>and be at the beginning or "initialized" and be at the end. Also see previous
>patch for more comments.
DONE, change the log as "Protected Xe Path (PXP) protected content support
initialized " at the end.
>This enum here feels like a misplaced hunk. We should be adding the enums and
>structs only when they are used in the patch. Reviewing the logic and looking
>for dead code is much harder when structs are introduced way earlier than they
>are used.
>We should be adding the base structs at most and extending them as we add more
>functionality as we go.
DONE, Thanks for capturing this, this enum is for session management only and I
have removed this.
-Original Message-
From: Joonas Lahtinen
Sent: Monday, December 7, 2020 2:21 AM
To: Huang, Sean Z ; Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC-v1 02/16] drm/i915/pxp: Enable PXP irq worker and
callback stub
Quoting Huang, Sean Z (2020-12-07 02:21:20)
> Create the irq worker that serves as callback handler, those callback
> stubs should be called while the hardware key teardown occurs.
>
> Signed-off-by: Huang, Sean Z
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> @@ -13,6 +13,7 @@
> #include "intel_gt_irq.h"
> #include "intel_uncore.h"
> #include "intel_rps.h"
> +#include "pxp/intel_pxp.h"
>
> static void guc_irq_handler(struct intel_guc *guc, u16 iir) { @@
> -106,6 +107,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8
> instance,
> if (instance == OTHER_GTPM_INSTANCE)
> return gen11_rps_irq_handler(>rps, iir);
>
> + if (instance == OTHER_KCR_INSTANCE)
> + return intel_pxp_irq_handler(gt, iir);
We should take >pxp as the first parameter and keep a tight scope.
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -6,6 +6,58 @@
> #include "i915_drv.h"
> #include "intel_pxp.h"
>
> +static void intel_pxp_write_irq_mask_reg(struct drm_i915_private
> +*i915, u32 mask)
Again, we should be taking intel_pxp as parameter to tighten the scope.
> +{
> + /* crypto mask is in bit31-16 (Engine1 Interrupt Mask) */
> + intel_uncore_write(>uncore, GEN11_CRYPTO_RSVD_INTR_MASK,
> +mask << 16);
Instead of writing to register that is indicated to be "reserved"
(RSVD), we should properly document the register in i915_reg.h and the comment
should not be needed.
> +static void intel_pxp_irq_work(struct work_struct *work) {
> + struct intel_pxp *pxp_ptr = container_of(work,
> +typeof(*pxp_ptr), irq_work);
_ptr is a tautology, we can already see it's apointer.
> + struct drm_i915_private *i915 = container_of(pxp_ptr,
> + typeof(*i915), pxp);
We should go from intel_pxp to intel_gt to i915 here, once the struct intel_pxp
member is moved inside intel_gt
> + u32 events = 0;
> +
> + spin_lock_irq(>gt.irq_lock);
> + events = fetch_and_zero(_ptr->current_events);
> + spin_unlock_irq(>gt.irq_lock);
> +
> + if (events & PXP_IRQ_VECTOR_DISPLAY_PXP_STATE_TERMINATED ||
> + events & PXP_IRQ_VECTOR_DISPLAY_APP_TERM_PER_FW_REQ)
> + intel_pxp_teardown_required_callback(i915);
> +
> + if (events & PXP_IRQ_VECTOR_PXP_DISP_STATE_RESET_COMPLETE)
> + intel_pxp_global_terminate_complete_callback(i915);
The mapping between the callbacks and the hardware events are unclear.
These all seem like display related events, so we probably need a split between
the GT and display PXP code.
It's hard to review
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion
== Series Details == Series: series starting with [01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion URL : https://patchwork.freedesktop.org/series/84649/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9456_full -> Patchwork_19076_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19076_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19076_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19076_full: ### IGT changes ### Possible regressions * igt@gem_eio@in-flight-1us: - shard-snb: [PASS][1] -> [INCOMPLETE][2] +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/shard-snb2/igt@gem_...@in-flight-1us.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-snb5/igt@gem_...@in-flight-1us.html * igt@gem_eio@in-flight-internal-10ms: - shard-hsw: [PASS][3] -> [INCOMPLETE][4] +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/shard-hsw4/igt@gem_...@in-flight-internal-10ms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-hsw1/igt@gem_...@in-flight-internal-10ms.html * igt@perf_pmu@other-init-4: - shard-apl: [PASS][5] -> [FAIL][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/shard-apl1/igt@perf_...@other-init-4.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-apl7/igt@perf_...@other-init-4.html - shard-tglb: [PASS][7] -> [FAIL][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/shard-tglb8/igt@perf_...@other-init-4.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-tglb7/igt@perf_...@other-init-4.html - shard-glk: [PASS][9] -> [FAIL][10] +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/shard-glk1/igt@perf_...@other-init-4.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-glk4/igt@perf_...@other-init-4.html - shard-skl: [PASS][11] -> [FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/shard-skl1/igt@perf_...@other-init-4.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-skl10/igt@perf_...@other-init-4.html - shard-hsw: [PASS][13] -> [FAIL][14] +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/shard-hsw7/igt@perf_...@other-init-4.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-hsw1/igt@perf_...@other-init-4.html - shard-kbl: [PASS][15] -> [FAIL][16] +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/shard-kbl6/igt@perf_...@other-init-4.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-kbl7/igt@perf_...@other-init-4.html * igt@perf_pmu@other-read-4: - shard-snb: [PASS][17] -> [FAIL][18] +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/shard-snb7/igt@perf_...@other-read-4.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-snb6/igt@perf_...@other-read-4.html - shard-iclb: [PASS][19] -> [FAIL][20] +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/shard-iclb1/igt@perf_...@other-read-4.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-iclb3/igt@perf_...@other-read-4.html * igt@runner@aborted: - shard-snb: NOTRUN -> ([FAIL][21], [FAIL][22], [FAIL][23]) ([i915#2426]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-snb7/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-snb6/igt@run...@aborted.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-snb4/igt@run...@aborted.html New tests - New tests have been introduced between CI_DRM_9456_full and Patchwork_19076_full: ### New CI tests (1) ### * boot: - Statuses : 200 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_19076_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@vcs1: - shard-kbl: [PASS][24] -> [DMESG-WARN][25] ([i915#180]) [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/shard-kbl4/igt@gem_ctx_isolation@preservation...@vcs1.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/shard-kbl4/igt@gem_ctx_isolation@preservation...@vcs1.html *
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Fix ICL MG PHY vswing handling
== Series Details == Series: series starting with [1/2] drm/i915: Fix ICL MG PHY vswing handling URL : https://patchwork.freedesktop.org/series/84651/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9456 -> Patchwork_19077 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19077 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19077, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19077/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19077: ### IGT changes ### Possible regressions * igt@gem_exec_suspend@basic-s3: - fi-snb-2600:[PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19077/fi-snb-2600/igt@gem_exec_susp...@basic-s3.html New tests - New tests have been introduced between CI_DRM_9456 and Patchwork_19077: ### New CI tests (1) ### * boot: - Statuses : 1 fail(s) 38 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_19077 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_heartbeat: - fi-bsw-kefka: [PASS][3] -> [DMESG-FAIL][4] ([i915#2675] / [i915#541]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19077/fi-bsw-kefka/igt@i915_selftest@live@gt_heartbeat.html Warnings * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: [DMESG-FAIL][5] ([i915#2291]) -> [DMESG-FAIL][6] ([i915#1886] / [i915#2291]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19077/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#2675]: https://gitlab.freedesktop.org/drm/intel/issues/2675 [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Participating hosts (44 -> 39) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-tgl-y fi-bdw-samus Build changes - * Linux: CI_DRM_9456 -> Patchwork_19077 CI-20190529: 20190529 CI_DRM_9456: 4c841475fa2fe28db44c090a65ec58c632f705dd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5884: b1015a3267bbccb985b2fa7e3accb778c7bff0ed @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19077: c4a7651820892f181e8aa4e4389f0243d4ef79a4 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c4a765182089 drm/i915: Unify the sanity checks for the buf trans tables 6c4f73fa8880 drm/i915: Fix ICL MG PHY vswing handling == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19077/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Unify the sanity checks for the buf trans tables
From: Ville Syrjälä
Get rid of the "I like my random new style best" approach and unify
the handling for the DDI buf trans table sanity checks once again.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index c3a15ce66478..68693d4538e2 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2631,15 +2631,11 @@ static void icl_ddi_combo_vswing_program(struct
intel_encoder *encoder,
ddi_translations = ehl_get_combo_buf_trans(encoder, crtc_state,
_entries);
else
ddi_translations = icl_get_combo_buf_trans(encoder, crtc_state,
_entries);
- if (!ddi_translations)
- return;
- if (level >= n_entries) {
- drm_dbg_kms(_priv->drm,
- "DDI translation not found for level %d. Using %d
instead.",
- level, n_entries - 1);
+ if (drm_WARN_ON_ONCE(_priv->drm, !ddi_translations))
+ return;
+ if (drm_WARN_ON_ONCE(_priv->drm, level >= n_entries))
level = n_entries - 1;
- }
if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP)) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
@@ -2760,12 +2756,11 @@ static void icl_mg_phy_ddi_vswing_sequence(struct
intel_encoder *encoder,
u32 val;
ddi_translations = icl_get_mg_buf_trans(encoder, crtc_state,
_entries);
- if (level >= n_entries) {
- drm_dbg_kms(_priv->drm,
- "DDI translation not found for level %d. Using %d
instead.",
- level, n_entries - 1);
+
+ if (drm_WARN_ON_ONCE(_priv->drm, !ddi_translations))
+ return;
+ if (drm_WARN_ON_ONCE(_priv->drm, level >= n_entries))
level = n_entries - 1;
- }
/* Set MG_TX_LINK_PARAMS cri_use_fs32 to 0. */
for (ln = 0; ln < 2; ln++) {
@@ -2897,7 +2892,9 @@ tgl_dkl_phy_ddi_vswing_sequence(struct intel_encoder
*encoder,
ddi_translations = tgl_get_dkl_buf_trans(encoder, crtc_state,
_entries);
- if (level >= n_entries)
+ if (drm_WARN_ON_ONCE(_priv->drm, !ddi_translations))
+ return;
+ if (drm_WARN_ON_ONCE(_priv->drm, level >= n_entries))
level = n_entries - 1;
dpcnt_mask = (DKL_TX_PRESHOOT_COEFF_MASK |
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Fix ICL MG PHY vswing handling
From: Ville Syrjälä
The MH PHY vswing table does have all the entries these days. Get
rid of the old hacks in the code which claim otherwise.
This hack was totally bogus anyway. The correct way to handle the
lack of those two entries would have been to declare our max
vswing and pre-emph to both be level 2.
Cc: José Roberto de Souza
Cc: Clinton Taylor
Fixes: 9f7ffa297978 ("drm/i915/tc/icl: Update TC vswing tables")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 5193473c838c..c3a15ce66478 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2760,12 +2760,11 @@ static void icl_mg_phy_ddi_vswing_sequence(struct
intel_encoder *encoder,
u32 val;
ddi_translations = icl_get_mg_buf_trans(encoder, crtc_state,
_entries);
- /* The table does not have values for level 3 and level 9. */
- if (level >= n_entries || level == 3 || level == 9) {
+ if (level >= n_entries) {
drm_dbg_kms(_priv->drm,
"DDI translation not found for level %d. Using %d
instead.",
- level, n_entries - 2);
- level = n_entries - 2;
+ level, n_entries - 1);
+ level = n_entries - 1;
}
/* Set MG_TX_LINK_PARAMS cri_use_fs32 to 0. */
--
2.26.2
___
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 [01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion
== Series Details == Series: series starting with [01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion URL : https://patchwork.freedesktop.org/series/84649/ State : success == Summary == CI Bug Log - changes from CI_DRM_9456 -> Patchwork_19076 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/index.html New tests - New tests have been introduced between CI_DRM_9456 and Patchwork_19076: ### New CI tests (1) ### * boot: - Statuses : 1 fail(s) 39 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_19076 that come from known issues: ### IGT changes ### Issues hit * igt@gem_flink_basic@basic: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/fi-tgl-y/igt@gem_flink_ba...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/fi-tgl-y/igt@gem_flink_ba...@basic.html * igt@i915_selftest@live@execlists: - fi-kbl-x1275: [PASS][3] -> [INCOMPLETE][4] ([i915#1037] / [i915#794]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/fi-kbl-x1275/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/fi-kbl-x1275/igt@i915_selftest@l...@execlists.html Possible fixes * igt@fbdev@read: - fi-tgl-y: [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/fi-tgl-y/igt@fb...@read.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/fi-tgl-y/igt@fb...@read.html Warnings * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: [DMESG-FAIL][7] ([i915#2291]) -> [DMESG-FAIL][8] ([i915#1886] / [i915#2291]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9456/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html [i915#1037]: https://gitlab.freedesktop.org/drm/intel/issues/1037 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#794]: https://gitlab.freedesktop.org/drm/intel/issues/794 Participating hosts (44 -> 40) -- Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_9456 -> Patchwork_19076 CI-20190529: 20190529 CI_DRM_9456: 4c841475fa2fe28db44c090a65ec58c632f705dd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5884: b1015a3267bbccb985b2fa7e3accb778c7bff0ed @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19076: 4a7c2eb47d5fb3dc22fa0814478d9d8151507514 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4a7c2eb47d5f drm/i915/gt: Use ppHWSP for unshared non-semaphore related timelines 5897a5163031 drm/i915/selftests: Exercise relative timeline modes ed1ab4ac5b1b drm/i915/gt: Use indices for writing into relative timelines 11ea0d8331ac drm/i915/gt: Add timeline "mode" 107fec199b3b drm/i915/gt: Track timeline GGTT offset separately from subpage offset 9bca7d930567 drm/i915/gt: Wrap intel_timeline.has_initial_breadcrumb ed15b9c1dc0c drm/i915/gt: Track all timelines created using the HWSP 0a1b1851185e drm/i915: Encode fence specific waitqueue behaviour into the wait.flags 5262f5568eb4 drm/i915/gt: Track the overall awake/busy time 6361b87d60ab drm/i915/gem: Drop free_work for GEM contexts 9aee4973a7d2 drm/i915/gt: ce->inflight updates are now serialised f37050f84f95 drm/i915/gt: Simplify virtual engine handling for execlists_hold() a054dd6d033c drm/i915/gt: Resubmit the virtual engine on schedule-out 6734d7f31f44 drm/i915/gt: Shrink the critical section for irq signaling e3ad36a573bd drm/i915/gt: Remove virtual breadcrumb before transfer 5e2950689fd2 drm/i915/gt: Defer schedule_out until after the next dequeue 42287d3e2d7b drm/i915/gt: Decouple inflight virtual engines b8b733c1455e drm/i915/gt: Use virtual_engine during execlists_dequeue 8bdefb152916 drm/i915/gt: Replace direct submit with direct call to tasklet dab6937f810f drm/i915/gem: Drop false !i915_vma_is_closed assertion == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19076/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected
On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote: > On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote: > > Just as a side note. I was looking at tpm_tis_probe_irq_single() > > and that function is leaking the interrupt request if any of the > > checks afterwards fails, except for the final interrupt probe check > > which does a cleanup. That means on fail before that the interrupt > > handler stays requested up to the point where the module is > > removed. If that's a shared interrupt and some other device is > > active on the same line, then each interrupt from that device will > > call into the TPM code. Something like the below is needed. > > > > Also the X86 autoprobe mechanism is interesting: > > > > if (IS_ENABLED(CONFIG_X86)) > > for (i = 3; i <= 15; i++) > > if (!tpm_tis_probe_irq_single(chip, intmask, 0, > > i)) > > return; > > > > The third argument is 'flags' which is handed to request_irq(). So > > that won't ever be able to probe a shared interrupt. But if an > > interrupt number > 0 is handed to tpm_tis_core_init() the interrupt > > is requested with IRQF_SHARED. Same issue when the chip has an > > interrupt number in the register. It's also requested exclusive > > which is pretty likely to fail on ancient x86 machines. > > It is very likely none of this works any more, it has been repeatedly > reworked over the years and just left behind out of fear someone > needs it. I've thought it should be deleted for a while now. > > I suppose the original logic was to try and probe without SHARED > because a probe would need exclusive access to the interrupt to tell > if the TPM was actually the source, not some other device. > > It is all very old and very out of step with current thinking, IMHO. > I skeptical that TPM interrupts were ever valuable enough to deserve > this in the first place. For what it's worth, I agree. Trying to probe all 15 ISA interrupts is last millennium thinking we should completely avoid. If it's not described in ACPI then you don't get an interrupt full stop. James ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion
== Series Details == Series: series starting with [01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion URL : https://patchwork.freedesktop.org/series/84649/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1326:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:expected void *in +drivers/gpu/drm/i915/gt/selftest_reset.c:100:20:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:100:20: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:expected void const *src +drivers/gpu/drm/i915/gt/selftest_reset.c:101:46:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:101:46: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:expected void *in +drivers/gpu/drm/i915/gt/selftest_reset.c:136:20:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:136:20: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:expected void const *src +drivers/gpu/drm/i915/gt/selftest_reset.c:137:46:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:137:46: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:expected unsigned int [usertype] *s +drivers/gpu/drm/i915/gt/selftest_reset.c:98:34:got void [noderef] __iomem *[assigned] s +drivers/gpu/drm/i915/gt/selftest_reset.c:98:34: warning: incorrect type in argument 1 (different address spaces) +drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1447:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1501:15: warning: memset with byte count of 16777216 +./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:838:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:864:16: warning: trying to copy expression type 31 +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block
[Intel-gfx] [PATCH 15/20] drm/i915/gt: Wrap intel_timeline.has_initial_breadcrumb
In preparation for removing the has_initial_breadcrumb field, add a
helper function for the existing callers.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_timeline.c| 6 +++---
drivers/gpu/drm/i915/gt/intel_timeline.h| 6 ++
drivers/gpu/drm/i915/gt/selftest_timeline.c | 5 +++--
5 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index cf924a569723..0e87789d95b0 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3586,7 +3586,7 @@ static int gen8_emit_init_breadcrumb(struct i915_request
*rq)
u32 *cs;
GEM_BUG_ON(i915_request_has_initial_breadcrumb(rq));
- if (!i915_request_timeline(rq)->has_initial_breadcrumb)
+ if (!intel_timeline_has_initial_breadcrumb(i915_request_timeline(rq)))
return 0;
cs = intel_ring_begin(rq, 6);
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index a41b43f445b8..4744eeedc95b 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -945,7 +945,7 @@ static int ring_request_alloc(struct i915_request *request)
int ret;
GEM_BUG_ON(!intel_context_is_pinned(request->context));
- GEM_BUG_ON(i915_request_timeline(request)->has_initial_breadcrumb);
+
GEM_BUG_ON(intel_timeline_has_initial_breadcrumb(i915_request_timeline(request)));
/*
* Flush enough space to reduce the likelihood of waiting after
@@ -1268,7 +1268,7 @@ int intel_ring_submission_setup(struct intel_engine_cs
*engine)
err = PTR_ERR(timeline);
goto err;
}
- GEM_BUG_ON(timeline->has_initial_breadcrumb);
+ GEM_BUG_ON(intel_timeline_has_initial_breadcrumb(timeline));
err = intel_timeline_pin(timeline, NULL);
if (err)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 512afacd2bdc..ddc8e1b4f3b8 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -428,14 +428,14 @@ void intel_timeline_exit(struct intel_timeline *tl)
static u32 timeline_advance(struct intel_timeline *tl)
{
GEM_BUG_ON(!atomic_read(>pin_count));
- GEM_BUG_ON(tl->seqno & tl->has_initial_breadcrumb);
+ GEM_BUG_ON(tl->seqno & intel_timeline_has_initial_breadcrumb(tl));
- return tl->seqno += 1 + tl->has_initial_breadcrumb;
+ return tl->seqno += 1 + intel_timeline_has_initial_breadcrumb(tl);
}
static void timeline_rollback(struct intel_timeline *tl)
{
- tl->seqno -= 1 + tl->has_initial_breadcrumb;
+ tl->seqno -= 1 + intel_timeline_has_initial_breadcrumb(tl);
}
static noinline int
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.h
b/drivers/gpu/drm/i915/gt/intel_timeline.h
index 1ee680d31801..deb71a8dbd43 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.h
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.h
@@ -73,6 +73,12 @@ static inline void intel_timeline_put(struct intel_timeline
*timeline)
kref_put(>kref, __intel_timeline_free);
}
+static inline bool
+intel_timeline_has_initial_breadcrumb(const struct intel_timeline *tl)
+{
+ return tl->has_initial_breadcrumb;
+}
+
static inline int __intel_timeline_sync_set(struct intel_timeline *tl,
u64 context, u32 seqno)
{
diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c
b/drivers/gpu/drm/i915/gt/selftest_timeline.c
index e4285d5a0360..a6ff9d1605aa 100644
--- a/drivers/gpu/drm/i915/gt/selftest_timeline.c
+++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c
@@ -665,7 +665,7 @@ static int live_hwsp_wrap(void *arg)
if (IS_ERR(tl))
return PTR_ERR(tl);
- if (!tl->has_initial_breadcrumb || !tl->hwsp_cacheline)
+ if (!intel_timeline_has_initial_breadcrumb(tl) || !tl->hwsp_cacheline)
goto out_free;
err = intel_timeline_pin(tl, NULL);
@@ -1234,7 +1234,8 @@ static int live_hwsp_rollover_user(void *arg)
goto out;
tl = ce->timeline;
- if (!tl->has_initial_breadcrumb || !tl->hwsp_cacheline)
+ if (!intel_timeline_has_initial_breadcrumb(tl) ||
+ !tl->hwsp_cacheline)
goto out;
timeline_rollback(tl);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/20] drm/i915/selftests: Exercise relative timeline modes
A quick test to verify that the backend accepts each type of timeline
and can use them to track and control request emission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 93 +
1 file changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c
b/drivers/gpu/drm/i915/gt/selftest_timeline.c
index 6f355c8a4f81..4164be36bec9 100644
--- a/drivers/gpu/drm/i915/gt/selftest_timeline.c
+++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c
@@ -1364,9 +1364,102 @@ static int live_hwsp_recycle(void *arg)
return err;
}
+static int live_hwsp_relative(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ /*
+* Check backend support for different timeline modes.
+*/
+
+ for_each_engine(engine, gt, id) {
+ enum intel_timeline_mode mode;
+
+ if (!engine->schedule)
+ continue;
+
+ for (mode = INTEL_TIMELINE_ABSOLUTE;
+mode <= INTEL_TIMELINE_GLOBAL;
+mode++) {
+ struct intel_timeline *tl;
+ struct i915_request *rq;
+ struct intel_context *ce;
+ const char *msg;
+ int err;
+
+ if (mode == INTEL_TIMELINE_CONTEXT &&
+ INTEL_GEN(gt->i915) < 8)
+ continue;
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce))
+ return PTR_ERR(ce);
+
+ err = intel_context_alloc_state(ce);
+ if (err) {
+ intel_context_put(ce);
+ return err;
+ }
+
+ switch (mode) {
+ case INTEL_TIMELINE_ABSOLUTE:
+ tl = intel_timeline_create(gt);
+ msg = "local";
+ break;
+
+ case INTEL_TIMELINE_CONTEXT:
+ tl = __intel_timeline_create(gt,
+ce->state,
+0x400 |
INTEL_TIMELINE_CONTEXT);
+ msg = "ppHWSP";
+ break;
+
+ case INTEL_TIMELINE_GLOBAL:
+ tl = __intel_timeline_create(gt,
+
engine->status_page.vma,
+0x400);
+ msg = "HWSP";
+ break;
+ }
+ if (IS_ERR(tl)) {
+ intel_context_put(ce);
+ return PTR_ERR(tl);
+ }
+
+ pr_info("Testing %s timeline on %s\n",
+ msg, engine->name);
+
+ intel_timeline_put(ce->timeline);
+ ce->timeline = tl;
+
+ rq = intel_context_create_request(ce);
+ intel_context_put(ce);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ GEM_BUG_ON(rcu_access_pointer(rq->timeline) != tl);
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ if (i915_request_wait(rq, 0, HZ / 5) < 0) {
+ i915_request_put(rq);
+ return -EIO;
+ }
+
+ i915_request_put(rq);
+ }
+ }
+
+ return 0;
+}
+
int intel_timeline_live_selftests(struct drm_i915_private *i915)
{
static const struct i915_subtest tests[] = {
+ SUBTEST(live_hwsp_relative),
SUBTEST(live_hwsp_recycle),
SUBTEST(live_hwsp_engine),
SUBTEST(live_hwsp_alternate),
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/20] drm/i915/gem: Drop false !i915_vma_is_closed assertion
Closed vma are protected by the GT wakeref held as we lookup the vma, so we know that the vma will not be freed as we process it for the execbuf. Instead we expect to catch the closed status of the context, and simply allow the close-race on an individual vma to be washed away. Longer term, the GT wakeref protection will be removed by explicit vma.kref tracking. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2245 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c index b07dc1156a0e..193996144c84 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c @@ -534,8 +534,6 @@ eb_add_vma(struct i915_execbuffer *eb, struct drm_i915_gem_exec_object2 *entry = >exec[i]; struct eb_vma *ev = >vma[i]; - GEM_BUG_ON(i915_vma_is_closed(vma)); - ev->vma = vma; ev->exec = entry; ev->flags = entry->flags; -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/20] drm/i915/gt: Replace direct submit with direct call to tasklet
Rather than having special case code for opportunistically calling
process_csb() and performing a direct submit while holding the engine
spinlock for submitting the request, simply call the tasklet directly.
This allows us to retain the direct submission path, including the CS
draining to allow fast/immediate submissions, without requiring any
duplicated code paths, and most importantly greatly simplifying the
control flow by removing reentrancy. This will enable us to close a few
races in the virtual engines in the next few patches.
The trickiest part here is to ensure that paired operations (such as
schedule_in/schedule_out) remain under consistent locking domains,
e.g. when pulled outside of the engine->active.lock
v2: Use bh kicking, see commit 3c53776e29f8 ("Mark HI and TASKLET
softirq synchronous").
v3: Update engine-reset to be tasklet aware
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 35 +++--
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 3 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 140 +++---
drivers/gpu/drm/i915/gt/intel_reset.c | 60 +---
drivers/gpu/drm/i915/gt/intel_reset.h | 2 +
drivers/gpu/drm/i915/gt/selftest_context.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 7 +-
drivers/gpu/drm/i915/gt/selftest_lrc.c| 27 ++--
drivers/gpu/drm/i915/gt/selftest_reset.c | 8 +-
drivers/gpu/drm/i915/i915_request.c | 12 +-
drivers/gpu/drm/i915/i915_request.h | 1 +
drivers/gpu/drm/i915/i915_scheduler.c | 4 -
drivers/gpu/drm/i915/selftests/i915_request.c | 6 +-
drivers/gpu/drm/i915/selftests/igt_spinner.c | 3 +
15 files changed, 162 insertions(+), 150 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index d4e988b2816a..2ed03b88ec12 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1002,32 +1002,39 @@ static unsigned long stop_timeout(const struct
intel_engine_cs *engine)
return READ_ONCE(engine->props.stop_timeout_ms);
}
-int intel_engine_stop_cs(struct intel_engine_cs *engine)
+static int __intel_engine_stop_cs(struct intel_engine_cs *engine,
+ int fast_timeout_us,
+ int slow_timeout_ms)
{
struct intel_uncore *uncore = engine->uncore;
- const u32 base = engine->mmio_base;
- const i915_reg_t mode = RING_MI_MODE(base);
+ const i915_reg_t mode = RING_MI_MODE(engine->mmio_base);
int err;
+ intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
+ err = __intel_wait_for_register_fw(engine->uncore, mode,
+ MODE_IDLE, MODE_IDLE,
+ fast_timeout_us,
+ slow_timeout_ms,
+ NULL);
+
+ /* A final mmio read to let GPU writes be hopefully flushed to memory */
+ intel_uncore_posting_read_fw(uncore, mode);
+ return err;
+}
+
+int intel_engine_stop_cs(struct intel_engine_cs *engine)
+{
+ int err = 0;
+
if (INTEL_GEN(engine->i915) < 3)
return -ENODEV;
ENGINE_TRACE(engine, "\n");
-
- intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
-
- err = 0;
- if (__intel_wait_for_register_fw(uncore,
-mode, MODE_IDLE, MODE_IDLE,
-1000, stop_timeout(engine),
-NULL)) {
+ if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
ENGINE_TRACE(engine, "timed out on STOP_RING -> IDLE\n");
err = -ETIMEDOUT;
}
- /* A final mmio read to let GPU writes be hopefully flushed to memory */
- intel_uncore_posting_read_fw(uncore, mode);
-
return err;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 499b09cb4acf..99574378047f 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -136,7 +136,7 @@ __queue_and_release_pm(struct i915_request *rq,
list_add_tail(>link, >active_list);
/* Hand the request over to HW and so engine_retire() */
- __i915_request_queue(rq, NULL);
+ __i915_request_queue_bh(rq);
/* Let new submissions commence (and maybe retire this timeline) */
__intel_wakeref_defer_park(>wakeref);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index ee6312601c56..e71eef157231 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++
[Intel-gfx] [PATCH 12/20] drm/i915/gt: Track the overall awake/busy time
Since we wake the GT up before executing a request, and go to sleep as
soon as it is retired, the GT wake time not only represents how long the
device is powered up, but also provides a summary, albeit an overestimate,
of the device runtime (i.e. the rc0 time to compare against rc6 time).
v2: s/busy/awake/
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 5 ++-
drivers/gpu/drm/i915/gt/intel_gt_pm.c| 49
drivers/gpu/drm/i915/gt/intel_gt_pm.h| 2 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 24
drivers/gpu/drm/i915/i915_debugfs.c | 5 ++-
drivers/gpu/drm/i915/i915_pmu.c | 6 +++
include/uapi/drm/i915_drm.h | 1 +
7 files changed, 89 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
index 174a24553322..8975717ace06 100644
--- a/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/debugfs_gt_pm.c
@@ -11,6 +11,7 @@
#include "i915_drv.h"
#include "intel_gt.h"
#include "intel_gt_clock_utils.h"
+#include "intel_gt_pm.h"
#include "intel_llc.h"
#include "intel_rc6.h"
#include "intel_rps.h"
@@ -558,7 +559,9 @@ static int rps_boost_show(struct seq_file *m, void *data)
seq_printf(m, "RPS enabled? %s\n", yesno(intel_rps_is_enabled(rps)));
seq_printf(m, "RPS active? %s\n", yesno(intel_rps_is_active(rps)));
- seq_printf(m, "GPU busy? %s\n", yesno(gt->awake));
+ seq_printf(m, "GPU busy? %s, %llums\n",
+ yesno(gt->awake),
+ ktime_to_ms(intel_gt_get_awake_time(gt)));
seq_printf(m, "Boosts outstanding? %d\n",
atomic_read(>num_waiters));
seq_printf(m, "Interactive? %d\n", READ_ONCE(rps->power.interactive));
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 274aa0dd7050..c94e8ac884eb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -39,6 +39,28 @@ static void user_forcewake(struct intel_gt *gt, bool suspend)
intel_gt_pm_put(gt);
}
+static void runtime_begin(struct intel_gt *gt)
+{
+ local_irq_disable();
+ write_seqcount_begin(>stats.lock);
+ gt->stats.start = ktime_get();
+ gt->stats.active = true;
+ write_seqcount_end(>stats.lock);
+ local_irq_enable();
+}
+
+static void runtime_end(struct intel_gt *gt)
+{
+ local_irq_disable();
+ write_seqcount_begin(>stats.lock);
+ gt->stats.active = false;
+ gt->stats.total =
+ ktime_add(gt->stats.total,
+ ktime_sub(ktime_get(), gt->stats.start));
+ write_seqcount_end(>stats.lock);
+ local_irq_enable();
+}
+
static int __gt_unpark(struct intel_wakeref *wf)
{
struct intel_gt *gt = container_of(wf, typeof(*gt), wakeref);
@@ -67,6 +89,7 @@ static int __gt_unpark(struct intel_wakeref *wf)
i915_pmu_gt_unparked(i915);
intel_gt_unpark_requests(gt);
+ runtime_begin(gt);
return 0;
}
@@ -79,6 +102,7 @@ static int __gt_park(struct intel_wakeref *wf)
GT_TRACE(gt, "\n");
+ runtime_end(gt);
intel_gt_park_requests(gt);
i915_vma_parked(gt);
@@ -106,6 +130,7 @@ static const struct intel_wakeref_ops wf_ops = {
void intel_gt_pm_init_early(struct intel_gt *gt)
{
intel_wakeref_init(>wakeref, gt->uncore->rpm, _ops);
+ seqcount_mutex_init(>stats.lock, >wakeref.mutex);
}
void intel_gt_pm_init(struct intel_gt *gt)
@@ -339,6 +364,30 @@ int intel_gt_runtime_resume(struct intel_gt *gt)
return intel_uc_runtime_resume(>uc);
}
+static ktime_t __intel_gt_get_awake_time(const struct intel_gt *gt)
+{
+ ktime_t total = gt->stats.total;
+
+ if (gt->stats.active)
+ total = ktime_add(total,
+ ktime_sub(ktime_get(), gt->stats.start));
+
+ return total;
+}
+
+ktime_t intel_gt_get_awake_time(const struct intel_gt *gt)
+{
+ unsigned int seq;
+ ktime_t total;
+
+ do {
+ seq = read_seqcount_begin(>stats.lock);
+ total = __intel_gt_get_awake_time(gt);
+ } while (read_seqcount_retry(>stats.lock, seq));
+
+ return total;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftest_gt_pm.c"
#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index 60f0e2fbe55c..63846a856e7e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -58,6 +58,8 @@ int intel_gt_resume(struct intel_gt *gt);
void intel_gt_runtime_suspend(struct intel_gt *gt);
int intel_gt_runtime_resume(struct intel_gt *gt);
+ktime_t intel_gt_get_awake_time(const struct intel_gt *gt);
+
static inline bool is_mock_gt(const struct intel_gt *gt)
{
return I915_SELFTEST_ONLY(gt->awake == -ENODEV);
diff --git
[Intel-gfx] [PATCH 18/20] drm/i915/gt: Use indices for writing into relative timelines
Relative timelines are relative to either the global or per-process
HWSP, and so we can replace the absolute addressing with store-index
variants for position invariance.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 114 ---
drivers/gpu/drm/i915/gt/intel_timeline.h | 12 +++
2 files changed, 90 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index cde86a9ad435..4f80dd1991f5 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4944,7 +4944,19 @@ gen8_emit_fini_breadcrumb_tail(struct i915_request
*request, u32 *cs)
static u32 *emit_xcs_breadcrumb(struct i915_request *rq, u32 *cs)
{
- return gen8_emit_ggtt_write(cs, rq->fence.seqno, hwsp_offset(rq), 0);
+ struct intel_timeline *tl = rcu_dereference_protected(rq->timeline, 1);
+ unsigned int flags = MI_FLUSH_DW_OP_STOREDW;
+ u32 offset = hwsp_offset(rq);
+
+ if (intel_timeline_is_relative(tl)) {
+ offset = offset_in_page(offset);
+ flags |= MI_FLUSH_DW_STORE_INDEX;
+ }
+ GEM_BUG_ON(offset & 7);
+ if (intel_timeline_is_global(tl))
+ offset |= MI_FLUSH_DW_USE_GTT;
+
+ return __gen8_emit_flush_dw(cs, rq->fence.seqno, offset, flags);
}
static u32 *gen8_emit_fini_breadcrumb(struct i915_request *rq, u32 *cs)
@@ -4952,8 +4964,20 @@ static u32 *gen8_emit_fini_breadcrumb(struct
i915_request *rq, u32 *cs)
return gen8_emit_fini_breadcrumb_tail(rq, emit_xcs_breadcrumb(rq, cs));
}
-static u32 *gen8_emit_fini_breadcrumb_rcs(struct i915_request *request, u32
*cs)
+static u32 *gen8_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs)
{
+ struct intel_timeline *tl = rcu_dereference_protected(rq->timeline, 1);
+ unsigned int flags = PIPE_CONTROL_FLUSH_ENABLE | PIPE_CONTROL_CS_STALL;
+ u32 offset = hwsp_offset(rq);
+
+ if (intel_timeline_is_relative(tl)) {
+ offset = offset_in_page(offset);
+ flags |= PIPE_CONTROL_STORE_DATA_INDEX;
+ }
+ GEM_BUG_ON(offset & 7);
+ if (intel_timeline_is_global(tl))
+ flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
+
cs = gen8_emit_pipe_control(cs,
PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
PIPE_CONTROL_DEPTH_CACHE_FLUSH |
@@ -4961,29 +4985,36 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct
i915_request *request, u32 *cs)
0);
/* XXX flush+write+CS_STALL all in one upsets gem_concurrent_blt:kbl */
- cs = gen8_emit_ggtt_write_rcs(cs,
- request->fence.seqno,
- hwsp_offset(request),
- PIPE_CONTROL_FLUSH_ENABLE |
- PIPE_CONTROL_CS_STALL);
+ cs = __gen8_emit_write_rcs(cs, rq->fence.seqno, offset, 0, flags);
- return gen8_emit_fini_breadcrumb_tail(request, cs);
+ return gen8_emit_fini_breadcrumb_tail(rq, cs);
}
static u32 *
-gen11_emit_fini_breadcrumb_rcs(struct i915_request *request, u32 *cs)
+gen11_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs)
{
- cs = gen8_emit_ggtt_write_rcs(cs,
- request->fence.seqno,
- hwsp_offset(request),
- PIPE_CONTROL_CS_STALL |
- PIPE_CONTROL_TILE_CACHE_FLUSH |
- PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
- PIPE_CONTROL_DEPTH_CACHE_FLUSH |
- PIPE_CONTROL_DC_FLUSH_ENABLE |
- PIPE_CONTROL_FLUSH_ENABLE);
+ struct intel_timeline *tl = rcu_dereference_protected(rq->timeline, 1);
+ u32 offset = hwsp_offset(rq);
+ unsigned int flags;
+
+ flags = (PIPE_CONTROL_CS_STALL |
+PIPE_CONTROL_TILE_CACHE_FLUSH |
+PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
+PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+PIPE_CONTROL_DC_FLUSH_ENABLE |
+PIPE_CONTROL_FLUSH_ENABLE);
+
+ if (intel_timeline_is_relative(tl)) {
+ offset = offset_in_page(offset);
+ flags |= PIPE_CONTROL_STORE_DATA_INDEX;
+ }
+ GEM_BUG_ON(offset & 7);
+ if (intel_timeline_is_global(tl))
+ flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
+
+ cs = __gen8_emit_write_rcs(cs, rq->fence.seqno, offset, 0, flags);
- return gen8_emit_fini_breadcrumb_tail(request, cs);
+ return gen8_emit_fini_breadcrumb_tail(rq, cs);
}
/*
@@ -5043,23 +5074,34 @@ static u32 *gen12_emit_fini_breadcrumb(struct
i915_request *rq, u32 *cs)
}
static u32 *
-gen12_emit_fini_breadcrumb_rcs(struct
[Intel-gfx] [PATCH 07/20] drm/i915/gt: Shrink the critical section for irq signaling
Let's only wait for the list iterator when decoupling the virtual
breadcrumb, as the signaling of all the requests may take a long time,
during which we do not want to keep the tasklet spinning.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 2 ++
drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 3 ++-
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 63900edbde88..ac1e5f6c3c2c 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -239,6 +239,7 @@ static void signal_irq_work(struct irq_work *work)
intel_breadcrumbs_disarm_irq(b);
rcu_read_lock();
+ atomic_inc(>signaler_active);
list_for_each_entry_rcu(ce, >signalers, signal_link) {
struct i915_request *rq;
@@ -274,6 +275,7 @@ static void signal_irq_work(struct irq_work *work)
}
}
}
+ atomic_dec(>signaler_active);
rcu_read_unlock();
llist_for_each_safe(signal, sn, signal) {
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
index a74bb3062bd8..f672053d694d 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h
@@ -35,6 +35,7 @@ struct intel_breadcrumbs {
spinlock_t signalers_lock; /* protects the list of signalers */
struct list_head signalers;
struct llist_head signaled_requests;
+ atomic_t signaler_active;
spinlock_t irq_lock; /* protects the interrupt from hardirq context */
struct irq_work irq_work; /* for use from inside irq_lock */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index b3db16b2a5a4..35cded25c6c1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1401,7 +1401,8 @@ static void kick_siblings(struct i915_request *rq, struct
intel_context *ce)
* ce->signal_link.
*/
i915_request_cancel_breadcrumb(rq);
- irq_work_sync(>breadcrumbs->irq_work);
+ while (atomic_read(>breadcrumbs->signaler_active))
+ cpu_relax();
}
if (READ_ONCE(ve->request))
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/20] drm/i915/gt: Simplify virtual engine handling for execlists_hold()
Now that the tasklet completely controls scheduling of the requests, and
we postpone scheduling out the old requests, we can keep a hanging
virtual request bound to the engine on which it hung, and remove it from
te queue. On release, it will be returned to the same engine and remain
in its queue until it is scheduled; after which point it will become
eligible for transfer to a sibling. Instead, we could opt to resubmit the
request along the virtual engine on unhold, making it eligible for load
balancing immediately -- but that seems like a pointless optimisation
for a hanging context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index efc8edd9e219..5f90ecacc22b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2862,35 +2862,6 @@ static bool execlists_hold(struct intel_engine_cs
*engine,
goto unlock;
}
- if (rq->engine != engine) { /* preempted virtual engine */
- struct virtual_engine *ve = to_virtual_engine(rq->engine);
-
- /*
-* intel_context_inflight() is only protected by virtue
-* of process_csb() being called only by the tasklet (or
-* directly from inside reset while the tasklet is suspended).
-* Assert that neither of those are allowed to run while we
-* poke at the request queues.
-*/
- GEM_BUG_ON(!reset_in_progress(>execlists));
-
- /*
-* An unsubmitted request along a virtual engine will
-* remain on the active (this) engine until we are able
-* to process the context switch away (and so mark the
-* context as no longer in flight). That cannot have happened
-* yet, otherwise we would not be hanging!
-*/
- spin_lock(>base.active.lock);
- GEM_BUG_ON(intel_context_inflight(rq->context) != engine);
- GEM_BUG_ON(ve->request != rq);
- ve->request = NULL;
- spin_unlock(>base.active.lock);
- i915_request_put(rq);
-
- rq->engine = engine;
- }
-
/*
* Transfer this request onto the hold queue to prevent it
* being resumbitted to HW (and potentially completed) before we have
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/20] drm/i915/gt: Remove virtual breadcrumb before transfer
The issue with stale virtual breadcrumbs remain. Now we have the problem
that if the irq-signaler is still referencing the stale breadcrumb as we
transfer it to a new sibling, the list becomes spaghetti. This is a very
small window, but that doesn't stop it being hit infrequently. To
prevent the lists being tangled (the iterator starting on one engine's
b->signalers but walking onto another list), always decouple the virtual
breadcrumb on schedule-out and make sure that the walker has stepped out
of the lists.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 5 +++--
drivers/gpu/drm/i915/gt/intel_lrc.c | 15 +++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 00918300f53f..63900edbde88 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -454,15 +454,16 @@ void i915_request_cancel_breadcrumb(struct i915_request
*rq)
{
struct intel_breadcrumbs *b = READ_ONCE(rq->engine)->breadcrumbs;
struct intel_context *ce = rq->context;
+ unsigned long flags;
bool release;
if (!test_and_clear_bit(I915_FENCE_FLAG_SIGNAL, >fence.flags))
return;
- spin_lock(>signal_lock);
+ spin_lock_irqsave(>signal_lock, flags);
list_del_rcu(>signal_link);
release = remove_signaling_context(b, ce);
- spin_unlock(>signal_lock);
+ spin_unlock_irqrestore(>signal_lock, flags);
if (release)
intel_context_put(ce);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 0b7e86240f3b..b3db16b2a5a4 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1388,6 +1388,21 @@ static inline void execlists_schedule_in(struct
i915_request *rq, int idx)
static void kick_siblings(struct i915_request *rq, struct intel_context *ce)
{
struct virtual_engine *ve = container_of(ce, typeof(*ve), context);
+ struct intel_engine_cs *engine = rq->engine;
+
+ /* Flush concurrent rcu iterators in signal_irq_work */
+ if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags)) {
+ /*
+* After this point, the rq may be transferred to a new
+* sibling, so before we clear ce->inflight make sure that
+* the context has been removed from the b->signalers and
+* furthermore we need to make sure that the concurrent
+* iterator in signal_irq_work is no longer following
+* ce->signal_link.
+*/
+ i915_request_cancel_breadcrumb(rq);
+ irq_work_sync(>breadcrumbs->irq_work);
+ }
if (READ_ONCE(ve->request))
tasklet_hi_schedule(>base.execlists.tasklet);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/20] drm/i915/gt: Defer schedule_out until after the next dequeue
Inside schedule_out, we do extra work upon idling the context, such as
updating the runtime, kicking off retires, kicking virtual engines.
However, if we are in a series of processing single requests per
contexts, we may find ourselves scheduling out the context, only to
immediately schedule it back in during dequeue. This is just extra work
that we can avoid if we keep the context marked as inflight across the
dequeue. This becomes more significant later on for minimising virtual
engine misses.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 121 +++---
2 files changed, 80 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 52fa9c132746..10830eeab0f7 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -58,8 +58,8 @@ struct intel_context {
struct intel_engine_cs *engine;
struct intel_engine_cs *inflight;
-#define intel_context_inflight(ce) ptr_mask_bits(READ_ONCE((ce)->inflight), 2)
-#define intel_context_inflight_count(ce)
ptr_unmask_bits(READ_ONCE((ce)->inflight), 2)
+#define intel_context_inflight(ce) ptr_mask_bits(READ_ONCE((ce)->inflight), 3)
+#define intel_context_inflight_count(ce)
ptr_unmask_bits(READ_ONCE((ce)->inflight), 3)
struct i915_address_space *vm;
struct i915_gem_context __rcu *gem_context;
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 092425ced822..0b7e86240f3b 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2046,19 +2046,6 @@ static void set_preempt_timeout(struct intel_engine_cs
*engine,
active_preempt_timeout(engine, rq));
}
-static inline void clear_ports(struct i915_request **ports, int count)
-{
- memset_p((void **)ports, NULL, count);
-}
-
-static inline void
-copy_ports(struct i915_request **dst, struct i915_request **src, int count)
-{
- /* A memcpy_p() would be very useful here! */
- while (count--)
- WRITE_ONCE(*dst++, *src++); /* avoid write tearing */
-}
-
static void execlists_dequeue(struct intel_engine_cs *engine)
{
struct intel_engine_execlists * const execlists = >execlists;
@@ -2407,18 +2394,32 @@ static void execlists_dequeue_irq(struct
intel_engine_cs *engine)
local_irq_enable(); /* flush irq_work (e.g. breadcrumb enabling) */
}
-static void
-cancel_port_requests(struct intel_engine_execlists * const execlists)
+static inline void clear_ports(struct i915_request **ports, int count)
+{
+ memset_p((void **)ports, NULL, count);
+}
+
+static inline void
+copy_ports(struct i915_request **dst, struct i915_request **src, int count)
+{
+ /* A memcpy_p() would be very useful here! */
+ while (count--)
+ WRITE_ONCE(*dst++, *src++); /* avoid write tearing */
+}
+
+static struct i915_request **
+cancel_port_requests(struct intel_engine_execlists * const execlists,
+struct i915_request **inactive)
{
struct i915_request * const *port;
for (port = execlists->pending; *port; port++)
- execlists_schedule_out(*port);
+ *inactive++ = *port;
clear_ports(execlists->pending, ARRAY_SIZE(execlists->pending));
/* Mark the end of active before we overwrite *active */
for (port = xchg(>active, execlists->pending); *port; port++)
- execlists_schedule_out(*port);
+ *inactive++ = *port;
clear_ports(execlists->inflight, ARRAY_SIZE(execlists->inflight));
smp_wmb(); /* complete the seqlock for execlists_active() */
@@ -2428,6 +2429,8 @@ cancel_port_requests(struct intel_engine_execlists *
const execlists)
GEM_BUG_ON(execlists->pending[0]);
cancel_timer(>timer);
cancel_timer(>preempt);
+
+ return inactive;
}
static inline void
@@ -2555,7 +2558,8 @@ csb_read(const struct intel_engine_cs *engine, u64 *
const csb)
return entry;
}
-static void process_csb(struct intel_engine_cs *engine)
+static struct i915_request **
+process_csb(struct intel_engine_cs *engine, struct i915_request **inactive)
{
struct intel_engine_execlists * const execlists = >execlists;
u64 * const buf = execlists->csb_status;
@@ -2584,7 +2588,7 @@ static void process_csb(struct intel_engine_cs *engine)
head = execlists->csb_head;
tail = READ_ONCE(*execlists->csb_write);
if (unlikely(head == tail))
- return;
+ return inactive;
/*
* We will consume all events from HW, or at least pretend to.
@@ -2664,7 +2668,7 @@ static void process_csb(struct intel_engine_cs *engine)
/* cancel old inflight, prepare for switch */
[Intel-gfx] [PATCH 03/20] drm/i915/gt: Use virtual_engine during execlists_dequeue
Rather than going back and forth between the rb_node entry and the
virtual_engine type, store the ve local and reuse it. As the
container_of conversion from rb_node to virtual_engine requires a
variable offset, performing that conversion just once shaves off a bit
of code.
v2: Keep a single virtual engine lookup, for typical use.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 239
1 file changed, 105 insertions(+), 134 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index c8c0493cb0b1..372b008364cf 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -454,9 +454,15 @@ static int queue_prio(const struct intel_engine_execlists
*execlists)
return ((p->priority + 1) << I915_USER_PRIORITY_SHIFT) - ffs(p->used);
}
+static int virtual_prio(const struct intel_engine_execlists *el)
+{
+ struct rb_node *rb = rb_first_cached(>virtual);
+
+ return rb ? rb_entry(rb, struct ve_node, rb)->prio : INT_MIN;
+}
+
static inline bool need_preempt(const struct intel_engine_cs *engine,
- const struct i915_request *rq,
- struct rb_node *rb)
+ const struct i915_request *rq)
{
int last_prio;
@@ -493,25 +499,6 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
rq_prio(list_next_entry(rq, sched.link)) > last_prio)
return true;
- if (rb) {
- struct virtual_engine *ve =
- rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
- bool preempt = false;
-
- if (engine == ve->siblings[0]) { /* only preempt one sibling */
- struct i915_request *next;
-
- rcu_read_lock();
- next = READ_ONCE(ve->request);
- if (next)
- preempt = rq_prio(next) > last_prio;
- rcu_read_unlock();
- }
-
- if (preempt)
- return preempt;
- }
-
/*
* If the inflight context did not trigger the preemption, then maybe
* it was the set of queued requests? Pick the highest priority in
@@ -522,7 +509,8 @@ static inline bool need_preempt(const struct
intel_engine_cs *engine,
* ELSP[0] or ELSP[1] as, thanks again to PI, if it was the same
* context, it's priority would not exceed ELSP[0] aka last_prio.
*/
- return queue_prio(>execlists) > last_prio;
+ return max(virtual_prio(>execlists),
+ queue_prio(>execlists)) > last_prio;
}
__maybe_unused static inline bool
@@ -1810,6 +1798,35 @@ static bool virtual_matches(const struct virtual_engine
*ve,
return true;
}
+static struct virtual_engine *
+first_virtual_engine(struct intel_engine_cs *engine)
+{
+ struct intel_engine_execlists *el = >execlists;
+ struct rb_node *rb = rb_first_cached(>virtual);
+
+ while (rb) {
+ struct virtual_engine *ve =
+ rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
+ struct i915_request *rq = READ_ONCE(ve->request);
+
+ /* lazily cleanup after another engine handled rq */
+ if (!rq) {
+ rb_erase_cached(rb, >virtual);
+ RB_CLEAR_NODE(rb);
+ rb = rb_first_cached(>virtual);
+ continue;
+ }
+
+ if (!virtual_matches(ve, rq, engine)) {
+ rb = rb_next(rb);
+ continue;
+ }
+ return ve;
+ }
+
+ return NULL;
+}
+
static void virtual_xfer_context(struct virtual_engine *ve,
struct intel_engine_cs *engine)
{
@@ -1898,32 +1915,15 @@ static void defer_active(struct intel_engine_cs *engine)
static bool
need_timeslice(const struct intel_engine_cs *engine,
- const struct i915_request *rq,
- const struct rb_node *rb)
+ const struct i915_request *rq)
{
int hint;
if (!intel_engine_has_timeslices(engine))
return false;
- hint = engine->execlists.queue_priority_hint;
-
- if (rb) {
- const struct virtual_engine *ve =
- rb_entry(rb, typeof(*ve), nodes[engine->id].rb);
- const struct intel_engine_cs *inflight =
- intel_context_inflight(>context);
-
- if (!inflight || inflight == engine) {
- struct i915_request *next;
-
- rcu_read_lock();
- next = READ_ONCE(ve->request);
- if (next)
- hint = max(hint, rq_prio(next));
[Intel-gfx] [PATCH 04/20] drm/i915/gt: Decouple inflight virtual engines
Once a virtual engine has been bound to a sibling, it will remain bound
until we finally schedule out the last active request. We can not rebind
the context to a new sibling while it is inflight as the context save
will conflict, hence we wait. As we cannot then use any other sibliing
while the context is inflight, only kick the bound sibling while it
inflight and upon scheduling out the kick the rest (so that we can swap
engines on timeslicing if the previously bound engine becomes
oversubscribed).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 372b008364cf..092425ced822 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1388,9 +1388,8 @@ static inline void execlists_schedule_in(struct
i915_request *rq, int idx)
static void kick_siblings(struct i915_request *rq, struct intel_context *ce)
{
struct virtual_engine *ve = container_of(ce, typeof(*ve), context);
- struct i915_request *next = READ_ONCE(ve->request);
- if (next == rq || (next && next->execution_mask & ~rq->execution_mask))
+ if (READ_ONCE(ve->request))
tasklet_hi_schedule(>base.execlists.tasklet);
}
@@ -1810,17 +1809,13 @@ first_virtual_engine(struct intel_engine_cs *engine)
struct i915_request *rq = READ_ONCE(ve->request);
/* lazily cleanup after another engine handled rq */
- if (!rq) {
+ if (!rq || !virtual_matches(ve, rq, engine)) {
rb_erase_cached(rb, >virtual);
RB_CLEAR_NODE(rb);
rb = rb_first_cached(>virtual);
continue;
}
- if (!virtual_matches(ve, rq, engine)) {
- rb = rb_next(rb);
- continue;
- }
return ve;
}
@@ -5605,7 +5600,6 @@ static void virtual_submission_tasklet(unsigned long data)
if (unlikely(!mask))
return;
- local_irq_disable();
for (n = 0; n < ve->num_siblings; n++) {
struct intel_engine_cs *sibling = READ_ONCE(ve->siblings[n]);
struct ve_node * const node = >nodes[sibling->id];
@@ -5615,20 +5609,19 @@ static void virtual_submission_tasklet(unsigned long
data)
if (!READ_ONCE(ve->request))
break; /* already handled by a sibling's tasklet */
+ spin_lock_irq(>active.lock);
+
if (unlikely(!(mask & sibling->mask))) {
if (!RB_EMPTY_NODE(>rb)) {
- spin_lock(>active.lock);
rb_erase_cached(>rb,
>execlists.virtual);
RB_CLEAR_NODE(>rb);
- spin_unlock(>active.lock);
}
- continue;
- }
- spin_lock(>active.lock);
+ goto unlock_engine;
+ }
- if (!RB_EMPTY_NODE(>rb)) {
+ if (unlikely(!RB_EMPTY_NODE(>rb))) {
/*
* Cheat and avoid rebalancing the tree if we can
* reuse this node in situ.
@@ -5668,9 +5661,12 @@ static void virtual_submission_tasklet(unsigned long
data)
if (first && prio > sibling->execlists.queue_priority_hint)
tasklet_hi_schedule(>execlists.tasklet);
- spin_unlock(>active.lock);
+unlock_engine:
+ spin_unlock_irq(>active.lock);
+
+ if (intel_context_inflight(>context))
+ break;
}
- local_irq_enable();
}
static void virtual_submit_request(struct i915_request *rq)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/20] drm/i915/gt: Track timeline GGTT offset separately from subpage offset
Currently we know that the timeline status page is at most a page in
size, and so we can preserve the lower 12bits of the offset when
relocating the status page in the GGTT. If we want to use a larger
object, such as the context state, we may not necessarily use a position
within the first page and so need more than 12b.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/gen6_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_lrc.c| 2 +-
drivers/gpu/drm/i915/gt/intel_timeline.c | 17 +++--
drivers/gpu/drm/i915/gt/intel_timeline_types.h | 1 +
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_rc6.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_timeline.c| 16
8 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
index ce38d1bcaba3..2f59dd3bdc18 100644
--- a/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen6_engine_cs.c
@@ -161,7 +161,7 @@ u32 *gen6_emit_breadcrumb_rcs(struct i915_request *rq, u32
*cs)
PIPE_CONTROL_DC_FLUSH_ENABLE |
PIPE_CONTROL_QW_WRITE |
PIPE_CONTROL_CS_STALL);
- *cs++ = i915_request_active_timeline(rq)->hwsp_offset |
+ *cs++ = i915_request_active_timeline(rq)->ggtt_offset |
PIPE_CONTROL_GLOBAL_GTT;
*cs++ = rq->fence.seqno;
@@ -359,7 +359,7 @@ u32 *gen7_emit_breadcrumb_rcs(struct i915_request *rq, u32
*cs)
PIPE_CONTROL_QW_WRITE |
PIPE_CONTROL_GLOBAL_GTT_IVB |
PIPE_CONTROL_CS_STALL);
- *cs++ = i915_request_active_timeline(rq)->hwsp_offset;
+ *cs++ = i915_request_active_timeline(rq)->ggtt_offset;
*cs++ = rq->fence.seqno;
*cs++ = MI_USER_INTERRUPT;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 94c169e13f2b..4ccb3068dca1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1334,7 +1334,7 @@ static int print_ring(char *buf, int sz, struct
i915_request *rq)
len = scnprintf(buf, sz,
"ring:{start:%08x, hwsp:%08x, seqno:%08x,
runtime:%llums}, ",
i915_ggtt_offset(rq->ring->vma),
- tl ? tl->hwsp_offset : 0,
+ tl ? tl->ggtt_offset : 0,
hwsp_seqno(rq),
DIV_ROUND_CLOSEST_ULL(intel_context_get_total_runtime_ns(rq->context),
1000 * 1000));
@@ -1673,7 +1673,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (tl) {
drm_printf(m, "\t\tring->hwsp: 0x%08x\n",
- tl->hwsp_offset);
+ tl->ggtt_offset);
intel_timeline_put(tl);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 0e87789d95b0..cde86a9ad435 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3578,7 +3578,7 @@ static u32 hwsp_offset(const struct i915_request *rq)
if (cl)
return cl->ggtt_offset;
- return rcu_dereference_protected(rq->timeline, 1)->hwsp_offset;
+ return rcu_dereference_protected(rq->timeline, 1)->ggtt_offset;
}
static int gen8_emit_init_breadcrumb(struct i915_request *rq)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index ddc8e1b4f3b8..cb20fcbb326b 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -338,13 +338,11 @@ int intel_timeline_pin(struct intel_timeline *tl, struct
i915_gem_ww_ctx *ww)
if (err)
return err;
- tl->hwsp_offset =
- i915_ggtt_offset(tl->hwsp_ggtt) +
- offset_in_page(tl->hwsp_offset);
+ tl->ggtt_offset = i915_ggtt_offset(tl->hwsp_ggtt) + tl->hwsp_offset;
GT_TRACE(tl->gt, "timeline:%llx using HWSP offset:%x\n",
-tl->fence_context, tl->hwsp_offset);
+tl->fence_context, tl->ggtt_offset);
- cacheline_acquire(tl->hwsp_cacheline, tl->hwsp_offset);
+ cacheline_acquire(tl->hwsp_cacheline, tl->ggtt_offset);
if (atomic_fetch_inc(>pin_count)) {
cacheline_release(tl->hwsp_cacheline);
__i915_vma_unpin(tl->hwsp_ggtt);
@@ -512,14 +510,13 @@ __intel_timeline_get_seqno(struct intel_timeline *tl,
vaddr = page_mask_bits(cl->vaddr);
tl->hwsp_offset = cacheline * CACHELINE_BYTES;
- tl->hwsp_seqno =
- memset(vaddr +
[Intel-gfx] [PATCH 17/20] drm/i915/gt: Add timeline "mode"
Explicitly differentiate between the absolute and relative timelines,
and the global HWSP and ppHWSP relative offsets. When using a timeline
that is relative to a known status page, we can replace the absolute
addressing in the commands with indexed variants.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 21 ---
drivers/gpu/drm/i915/gt/intel_timeline.h | 2 +-
.../gpu/drm/i915/gt/intel_timeline_types.h| 10 +++--
3 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index cb20fcbb326b..da0a9659557a 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -229,7 +229,6 @@ static int intel_timeline_init(struct intel_timeline
*timeline,
timeline->gt = gt;
- timeline->has_initial_breadcrumb = !hwsp;
timeline->hwsp_cacheline = NULL;
if (!hwsp) {
@@ -246,13 +245,29 @@ static int intel_timeline_init(struct intel_timeline
*timeline,
return PTR_ERR(cl);
}
+ timeline->mode = INTEL_TIMELINE_ABSOLUTE;
timeline->hwsp_cacheline = cl;
timeline->hwsp_offset = cacheline * CACHELINE_BYTES;
vaddr = page_mask_bits(cl->vaddr);
} else {
- timeline->hwsp_offset = offset;
- vaddr = i915_gem_object_pin_map(hwsp->obj, I915_MAP_WB);
+ int preferred;
+
+ if (offset & INTEL_TIMELINE_CONTEXT) {
+ timeline->mode = INTEL_TIMELINE_CONTEXT;
+ timeline->hwsp_offset =
+ offset & ~INTEL_TIMELINE_CONTEXT;
+ preferred = i915_coherent_map_type(gt->i915);
+ } else {
+ timeline->mode = INTEL_TIMELINE_GLOBAL;
+ timeline->hwsp_offset = offset;
+ preferred = I915_MAP_WB;
+ }
+
+ vaddr = i915_gem_object_pin_map(hwsp->obj,
+ preferred | I915_MAP_OVERRIDE);
+ if (IS_ERR(vaddr))
+ vaddr = i915_gem_object_pin_map(hwsp->obj, I915_MAP_WC);
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.h
b/drivers/gpu/drm/i915/gt/intel_timeline.h
index deb71a8dbd43..69250de3a814 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.h
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.h
@@ -76,7 +76,7 @@ static inline void intel_timeline_put(struct intel_timeline
*timeline)
static inline bool
intel_timeline_has_initial_breadcrumb(const struct intel_timeline *tl)
{
- return tl->has_initial_breadcrumb;
+ return tl->mode == INTEL_TIMELINE_ABSOLUTE;
}
static inline int __intel_timeline_sync_set(struct intel_timeline *tl,
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline_types.h
b/drivers/gpu/drm/i915/gt/intel_timeline_types.h
index f187c5aac11c..32c51425a0c4 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_timeline_types.h
@@ -20,6 +20,12 @@ struct i915_syncmap;
struct intel_gt;
struct intel_timeline_hwsp;
+enum intel_timeline_mode {
+ INTEL_TIMELINE_ABSOLUTE = 0,
+ INTEL_TIMELINE_CONTEXT = BIT(0),
+ INTEL_TIMELINE_GLOBAL = BIT(1),
+};
+
struct intel_timeline {
u64 fence_context;
u32 seqno;
@@ -45,6 +51,8 @@ struct intel_timeline {
atomic_t pin_count;
atomic_t active_count;
+ enum intel_timeline_mode mode;
+
const u32 *hwsp_seqno;
struct i915_vma *hwsp_ggtt;
u32 hwsp_offset;
@@ -52,8 +60,6 @@ struct intel_timeline {
struct intel_timeline_cacheline *hwsp_cacheline;
- bool has_initial_breadcrumb;
-
/**
* List of breadcrumbs associated with GPU requests currently
* outstanding.
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/20] drm/i915/gt: Track all timelines created using the HWSP
We assume that the contents of the HWSP are lost across suspend, and so
upon resume we must restore critical values such as the timeline seqno.
Keep track of every timeline allocated that uses the HWSP as its storage
and so we can then reset all seqno values by walking that list.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c| 15 +--
drivers/gpu/drm/i915/gt/intel_timeline.h | 13 ++---
drivers/gpu/drm/i915/gt/intel_timeline_types.h | 2 ++
6 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 2ed03b88ec12..94c169e13f2b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -647,6 +647,8 @@ static int init_status_page(struct intel_engine_cs *engine)
void *vaddr;
int ret;
+ INIT_LIST_HEAD(>status_page.timelines);
+
/*
* Though the HWS register does support 36bit addresses, historically
* we have had hangs and corruption reported due to wild writes if
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 99574378047f..20b5a8aa76ce 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -60,6 +60,8 @@ static int __engine_unpark(struct intel_wakeref *wf)
/* Scrub the context image after our loss of control */
ce->ops->reset(ce);
+
+ GEM_BUG_ON(ce->timeline->seqno != *ce->timeline->hwsp_seqno);
}
if (engine->unpark)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index e71eef157231..c28f4e190fe6 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -68,6 +68,7 @@ typedef u8 intel_engine_mask_t;
#define ALL_ENGINES ((intel_engine_mask_t)~0ul)
struct intel_hw_status_page {
+ struct list_head timelines;
struct i915_vma *vma;
u32 *addr;
};
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index d5bd537de9b7..cf924a569723 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3537,7 +3537,10 @@ static int execlists_context_alloc(struct intel_context
*ce)
static void execlists_context_reset(struct intel_context *ce)
{
- CE_TRACE(ce, "reset\n");
+ CE_TRACE(ce, "reset { seqno:%x, *hwsp:%x, ring:%x }\n",
+ce->timeline->seqno,
+*ce->timeline->hwsp_seqno,
+ce->ring->emit);
GEM_BUG_ON(!intel_context_is_pinned(ce));
intel_ring_reset(ce->ring, ce->ring->emit);
@@ -4063,6 +4066,14 @@ static void reset_csb_pointers(struct intel_engine_cs
*engine)
GEM_BUG_ON(READ_ONCE(*execlists->csb_write) != reset_value);
}
+static void sanitize_timelines(struct intel_engine_cs *engine)
+{
+ struct intel_timeline *tl;
+
+ list_for_each_entry(tl, >status_page.timelines, engine_link)
+ intel_timeline_reset_seqno(tl);
+}
+
static void execlists_sanitize(struct intel_engine_cs *engine)
{
GEM_BUG_ON(execlists_active(>execlists));
@@ -4086,7 +4097,7 @@ static void execlists_sanitize(struct intel_engine_cs
*engine)
* that may be lost on resume/initialisation, and so we need to
* reset the value in the HWSP.
*/
- intel_timeline_reset_seqno(engine->kernel_context->timeline);
+ sanitize_timelines(engine);
/* And scrub the dirty cachelines for the HWSP */
clflush_cache_range(engine->status_page.addr, PAGE_SIZE);
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.h
b/drivers/gpu/drm/i915/gt/intel_timeline.h
index 634acebd0c4b..1ee680d31801 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.h
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.h
@@ -48,9 +48,16 @@ static inline struct intel_timeline *
intel_timeline_create_from_engine(struct intel_engine_cs *engine,
unsigned int offset)
{
- return __intel_timeline_create(engine->gt,
- engine->status_page.vma,
- offset);
+ struct intel_timeline *tl;
+
+ tl = __intel_timeline_create(engine->gt,
+engine->status_page.vma,
+offset);
+ if (IS_ERR(tl))
+ return tl;
+
+ list_add_tail(>engine_link, >status_page.timelines);
+ return tl;
}
static inline struct intel_timeline *
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline_types.h
b/drivers/gpu/drm/i915/gt/intel_timeline_types.h
index
[Intel-gfx] [PATCH 11/20] drm/i915/gem: Drop free_work for GEM contexts
The free_list and worker was introduced in commit 5f09a9c8ab6b ("drm/i915:
Allow contexts to be unreferenced locklessly"), but subsequently made
redundant by the removal of the last sleeping lock in commit 2935ed5339c4
("drm/i915: Remove logical HW ID"). As we can now free the GEM context
immediately from any context, remove the deferral of the free_list
v2: Lift removing the context from the global list into close().
Suggested-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 59 +++
drivers/gpu/drm/i915/gem/i915_gem_context.h | 1 -
.../gpu/drm/i915/gem/i915_gem_context_types.h | 1 -
drivers/gpu/drm/i915/i915_drv.h | 3 -
drivers/gpu/drm/i915/i915_gem.c | 2 -
.../gpu/drm/i915/selftests/mock_gem_device.c | 2 -
6 files changed, 8 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index a6299da64de4..8493af37eb8a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -333,13 +333,12 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx)
return e;
}
-static void i915_gem_context_free(struct i915_gem_context *ctx)
+void i915_gem_context_release(struct kref *ref)
{
- GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
+ struct i915_gem_context *ctx = container_of(ref, typeof(*ctx), ref);
- spin_lock(>i915->gem.contexts.lock);
- list_del(>link);
- spin_unlock(>i915->gem.contexts.lock);
+ trace_i915_context_free(ctx);
+ GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
mutex_destroy(>engines_mutex);
mutex_destroy(>lut_mutex);
@@ -353,37 +352,6 @@ static void i915_gem_context_free(struct i915_gem_context
*ctx)
kfree_rcu(ctx, rcu);
}
-static void contexts_free_all(struct llist_node *list)
-{
- struct i915_gem_context *ctx, *cn;
-
- llist_for_each_entry_safe(ctx, cn, list, free_link)
- i915_gem_context_free(ctx);
-}
-
-static void contexts_flush_free(struct i915_gem_contexts *gc)
-{
- contexts_free_all(llist_del_all(>free_list));
-}
-
-static void contexts_free_worker(struct work_struct *work)
-{
- struct i915_gem_contexts *gc =
- container_of(work, typeof(*gc), free_work);
-
- contexts_flush_free(gc);
-}
-
-void i915_gem_context_release(struct kref *ref)
-{
- struct i915_gem_context *ctx = container_of(ref, typeof(*ctx), ref);
- struct i915_gem_contexts *gc = >i915->gem.contexts;
-
- trace_i915_context_free(ctx);
- if (llist_add(>free_link, >free_list))
- schedule_work(>free_work);
-}
-
static inline struct i915_gem_engines *
__context_engines_static(const struct i915_gem_context *ctx)
{
@@ -632,6 +600,10 @@ static void context_close(struct i915_gem_context *ctx)
*/
lut_close(ctx);
+ spin_lock(>i915->gem.contexts.lock);
+ list_del(>link);
+ spin_unlock(>i915->gem.contexts.lock);
+
mutex_unlock(>mutex);
/*
@@ -849,9 +821,6 @@ i915_gem_create_context(struct drm_i915_private *i915,
unsigned int flags)
!HAS_EXECLISTS(i915))
return ERR_PTR(-EINVAL);
- /* Reap the stale contexts */
- contexts_flush_free(>gem.contexts);
-
ctx = __create_context(i915);
if (IS_ERR(ctx))
return ctx;
@@ -896,9 +865,6 @@ static void init_contexts(struct i915_gem_contexts *gc)
{
spin_lock_init(>lock);
INIT_LIST_HEAD(>list);
-
- INIT_WORK(>free_work, contexts_free_worker);
- init_llist_head(>free_list);
}
void i915_gem_init__contexts(struct drm_i915_private *i915)
@@ -906,12 +872,6 @@ void i915_gem_init__contexts(struct drm_i915_private *i915)
init_contexts(>gem.contexts);
}
-void i915_gem_driver_release__contexts(struct drm_i915_private *i915)
-{
- flush_work(>gem.contexts.free_work);
- rcu_barrier(); /* and flush the left over RCU frees */
-}
-
static int gem_context_register(struct i915_gem_context *ctx,
struct drm_i915_file_private *fpriv,
u32 *id)
@@ -985,7 +945,6 @@ int i915_gem_context_open(struct drm_i915_private *i915,
void i915_gem_context_close(struct drm_file *file)
{
struct drm_i915_file_private *file_priv = file->driver_priv;
- struct drm_i915_private *i915 = file_priv->dev_priv;
struct i915_address_space *vm;
struct i915_gem_context *ctx;
unsigned long idx;
@@ -997,8 +956,6 @@ void i915_gem_context_close(struct drm_file *file)
xa_for_each(_priv->vm_xa, idx, vm)
i915_vm_put(vm);
xa_destroy(_priv->vm_xa);
-
- contexts_flush_free(>gem.contexts);
}
int i915_gem_vm_create_ioctl(struct drm_device *dev, void *data,
diff --git
[Intel-gfx] [PATCH 13/20] drm/i915: Encode fence specific waitqueue behaviour into the wait.flags
Use the wait_queue_entry.flags to denote the special fence behaviour
(flattening continuations along fence chains, and for propagating
errors) rather than trying to detect ordinary waiters by their
functions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 038d4c6884c5..2744558f3050 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -18,10 +18,15 @@
#define I915_SW_FENCE_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr)
#endif
-#define I915_SW_FENCE_FLAG_ALLOC BIT(3) /* after WQ_FLAG_* for safety */
-
static DEFINE_SPINLOCK(i915_sw_fence_lock);
+#define WQ_FLAG_BITS \
+ BITS_PER_TYPE(typeof_member(struct wait_queue_entry, flags))
+
+/* after WQ_FLAG_* for safety */
+#define I915_SW_FENCE_FLAG_FENCE BIT(WQ_FLAG_BITS - 1)
+#define I915_SW_FENCE_FLAG_ALLOC BIT(WQ_FLAG_BITS - 2)
+
enum {
DEBUG_FENCE_IDLE = 0,
DEBUG_FENCE_NOTIFY,
@@ -154,10 +159,10 @@ static void __i915_sw_fence_wake_up_all(struct
i915_sw_fence *fence,
spin_lock_irqsave_nested(>lock, flags, 1 + !!continuation);
if (continuation) {
list_for_each_entry_safe(pos, next, >head, entry) {
- if (pos->func == autoremove_wake_function)
- pos->func(pos, TASK_NORMAL, 0, continuation);
- else
+ if (pos->flags & I915_SW_FENCE_FLAG_FENCE)
list_move_tail(>entry, continuation);
+ else
+ pos->func(pos, TASK_NORMAL, 0, continuation);
}
} else {
LIST_HEAD(extra);
@@ -166,9 +171,9 @@ static void __i915_sw_fence_wake_up_all(struct
i915_sw_fence *fence,
list_for_each_entry_safe(pos, next, >head, entry) {
int wake_flags;
- wake_flags = fence->error;
- if (pos->func == autoremove_wake_function)
- wake_flags = 0;
+ wake_flags = 0;
+ if (pos->flags & I915_SW_FENCE_FLAG_FENCE)
+ wake_flags = fence->error;
pos->func(pos, TASK_NORMAL, wake_flags, );
}
@@ -332,8 +337,8 @@ static int __i915_sw_fence_await_sw_fence(struct
i915_sw_fence *fence,
struct i915_sw_fence *signaler,
wait_queue_entry_t *wq, gfp_t gfp)
{
+ unsigned int pending;
unsigned long flags;
- int pending;
debug_fence_assert(fence);
might_sleep_if(gfpflags_allow_blocking(gfp));
@@ -349,7 +354,7 @@ static int __i915_sw_fence_await_sw_fence(struct
i915_sw_fence *fence,
if (unlikely(i915_sw_fence_check_if_after(fence, signaler)))
return -EINVAL;
- pending = 0;
+ pending = I915_SW_FENCE_FLAG_FENCE;
if (!wq) {
wq = kmalloc(sizeof(*wq), gfp);
if (!wq) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/20] drm/i915/gt: Resubmit the virtual engine on schedule-out
Having recognised that we do not change the sibling until we schedule
out, we can then defer the decision to resubmit the virtual engine from
the unwind of the active queue to scheduling out of the virtual context.
This improves our resilence in virtual engine scheduling, and should
eliminate the rare cases of gem_exec_balance failing.
By keeping the unwind order intact on the local engine, we can preserve
data dependency ordering while doing a preempt-to-busy pass until we
have determined the new ELSP. This means that if we try to timeslice
between a virtual engine and a data-dependent ordinary request, the pair
will maintain their relative ordering and we will avoid the
resubmission, cancelling the timeslicing until further change.
The dilemma though is that we then may end up in a situation where the
'demotion' of the virtual request to an ordinary request in the engine
queue results in filling the ELSP[] with virtual requests instead of
spreading the load across the engines. To compensate for this, we mark
each virtual request and refuse to resubmit a virtual request in the
secondary ELSP slots, thus forcing subsequent virtual requests to be
scheduled out after timeslicing. By delaying the decision until we
schedule out, we will avoid unnecessary resubmission.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2079
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2098
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 122 +++--
drivers/gpu/drm/i915/gt/selftest_lrc.c | 2 +-
2 files changed, 77 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 35cded25c6c1..efc8edd9e219 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -,38 +,23 @@ __unwind_incomplete_requests(struct intel_engine_cs
*engine)
__i915_request_unsubmit(rq);
- /*
-* Push the request back into the queue for later resubmission.
-* If this request is not native to this physical engine (i.e.
-* it came from a virtual source), push it back onto the virtual
-* engine so that it can be moved across onto another physical
-* engine as load dictates.
-*/
- if (likely(rq->execution_mask == engine->mask)) {
- GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
- if (rq_prio(rq) != prio) {
- prio = rq_prio(rq);
- pl = i915_sched_lookup_priolist(engine, prio);
- }
-
GEM_BUG_ON(RB_EMPTY_ROOT(>execlists.queue.rb_root));
-
- list_move(>sched.link, pl);
- set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
+ GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
+ if (rq_prio(rq) != prio) {
+ prio = rq_prio(rq);
+ pl = i915_sched_lookup_priolist(engine, prio);
+ }
+ GEM_BUG_ON(RB_EMPTY_ROOT(>execlists.queue.rb_root));
- /* Check in case we rollback so far we wrap [size/2] */
- if (intel_ring_direction(rq->ring,
-rq->tail,
-rq->ring->tail + 8) > 0)
- rq->context->lrc.desc |= CTX_DESC_FORCE_RESTORE;
+ list_move(>sched.link, pl);
+ set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
- active = rq;
- } else {
- struct intel_engine_cs *owner = rq->context->engine;
+ /* Check in case we rollback so far we wrap [size/2] */
+ if (intel_ring_direction(rq->ring,
+rq->tail,
+rq->ring->tail + 8) > 0)
+ rq->context->lrc.desc |= CTX_DESC_FORCE_RESTORE;
- WRITE_ONCE(rq->engine, owner);
- owner->submit_request(rq);
- active = NULL;
- }
+ active = rq;
}
return active;
@@ -1385,6 +1370,20 @@ static inline void execlists_schedule_in(struct
i915_request *rq, int idx)
GEM_BUG_ON(intel_context_inflight(ce) != rq->engine);
}
+static void
+resubmit_virtual_request(struct i915_request *rq, struct virtual_engine *ve)
+{
+ struct intel_engine_cs *engine = rq->engine;
+
+ spin_lock_irq(>active.lock);
+
+ clear_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
+ WRITE_ONCE(rq->engine, >base);
+ ve->base.submit_request(rq);
+
+ spin_unlock_irq(>active.lock);
+}
+
static void kick_siblings(struct i915_request *rq, struct
[Intel-gfx] [PATCH 10/20] drm/i915/gt: ce->inflight updates are now serialised
Since schedule-in and schedule-out are now both always under the tasklet
bitlock, we can reduce the individual atomic operations to simple
instructions and worry less.
This notably eliminates the race observed with intel_context_inflight in
__engine_unpark().
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2583
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 52 ++---
1 file changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 5f90ecacc22b..d5bd537de9b7 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1331,11 +1331,11 @@ __execlists_schedule_in(struct i915_request *rq)
ce->lrc.ccid = ce->tag;
} else {
/* We don't need a strict matching tag, just different values */
- unsigned int tag = ffs(READ_ONCE(engine->context_tag));
+ unsigned int tag = __ffs(engine->context_tag);
- GEM_BUG_ON(tag == 0 || tag >= BITS_PER_LONG);
- clear_bit(tag - 1, >context_tag);
- ce->lrc.ccid = tag << (GEN11_SW_CTX_ID_SHIFT - 32);
+ GEM_BUG_ON(tag >= BITS_PER_LONG);
+ __clear_bit(tag, >context_tag);
+ ce->lrc.ccid = (1 + tag) << (GEN11_SW_CTX_ID_SHIFT - 32);
BUILD_BUG_ON(BITS_PER_LONG > GEN12_MAX_CONTEXT_HW_ID);
}
@@ -1348,6 +1348,8 @@ __execlists_schedule_in(struct i915_request *rq)
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
intel_engine_context_in(engine);
+ CE_TRACE(ce, "schedule-in, ccid:%x\n", ce->lrc.ccid);
+
return engine;
}
@@ -1359,13 +1361,10 @@ static inline void execlists_schedule_in(struct
i915_request *rq, int idx)
GEM_BUG_ON(!intel_engine_pm_is_awake(rq->engine));
trace_i915_request_in(rq, idx);
- old = READ_ONCE(ce->inflight);
- do {
- if (!old) {
- WRITE_ONCE(ce->inflight, __execlists_schedule_in(rq));
- break;
- }
- } while (!try_cmpxchg(>inflight, , ptr_inc(old)));
+ old = ce->inflight;
+ if (!old)
+ old = __execlists_schedule_in(rq);
+ WRITE_ONCE(ce->inflight, ptr_inc(old));
GEM_BUG_ON(intel_context_inflight(ce) != rq->engine);
}
@@ -1418,12 +1417,11 @@ static void kick_siblings(struct i915_request *rq,
struct intel_context *ce)
tasklet_hi_schedule(>base.execlists.tasklet);
}
-static inline void
-__execlists_schedule_out(struct i915_request *rq,
-struct intel_engine_cs * const engine,
-unsigned int ccid)
+static inline void __execlists_schedule_out(struct i915_request *rq)
{
struct intel_context * const ce = rq->context;
+ struct intel_engine_cs * const engine = rq->engine;
+ unsigned int ccid;
/*
* NB process_csb() is not under the engine->active.lock and hence
@@ -1431,6 +1429,8 @@ __execlists_schedule_out(struct i915_request *rq,
* refrain from doing non-trivial work here.
*/
+ CE_TRACE(ce, "schedule-out, ccid:%x\n", ce->lrc.ccid);
+
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
execlists_check_context(ce, engine, "after");
@@ -1442,12 +1442,13 @@ __execlists_schedule_out(struct i915_request *rq,
i915_request_completed(rq))
intel_engine_add_retire(engine, ce->timeline);
+ ccid = ce->lrc.ccid;
ccid >>= GEN11_SW_CTX_ID_SHIFT - 32;
ccid &= GEN12_MAX_CONTEXT_HW_ID;
if (ccid < BITS_PER_LONG) {
GEM_BUG_ON(ccid == 0);
GEM_BUG_ON(test_bit(ccid - 1, >context_tag));
- set_bit(ccid - 1, >context_tag);
+ __set_bit(ccid - 1, >context_tag);
}
intel_context_update_runtime(ce);
@@ -1468,26 +1469,23 @@ __execlists_schedule_out(struct i915_request *rq,
*/
if (ce->engine != engine)
kick_siblings(rq, ce);
-
- intel_context_put(ce);
}
static inline void
execlists_schedule_out(struct i915_request *rq)
{
struct intel_context * const ce = rq->context;
- struct intel_engine_cs *cur, *old;
- u32 ccid;
trace_i915_request_out(rq);
- ccid = rq->context->lrc.ccid;
- old = READ_ONCE(ce->inflight);
- do
- cur = ptr_unmask_bits(old, 2) ? ptr_dec(old) : NULL;
- while (!try_cmpxchg(>inflight, , cur));
- if (!cur)
- __execlists_schedule_out(rq, old, ccid);
+ GEM_BUG_ON(!ce->inflight);
+ ce->inflight = ptr_dec(ce->inflight);
+ if (!intel_context_inflight_count(ce)) {
+ GEM_BUG_ON(ce->inflight != rq->engine);
+ __execlists_schedule_out(rq);
+ WRITE_ONCE(ce->inflight,
[Intel-gfx] [PATCH 20/20] drm/i915/gt: Use ppHWSP for unshared non-semaphore related timelines
When we are not using semaphores with a context/engine, we can simply
reuse the same seqno location across wraps, but we still require each
timeline to have its own address. For LRC submission, each context is
prefixed by a per-process HWSP, which provides us with a unique location
for each context-local timeline. A shared timeline that is common to
multiple contexts will continue to use a separate page.
This enables us to create position invariant contexts should we feel the
need to relocate them.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 37 +
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 4f80dd1991f5..67e8997279cb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -5432,6 +5432,14 @@ static struct intel_timeline *pinned_timeline(struct
intel_context *ce)
page_unmask_bits(tl));
}
+static struct intel_timeline *pphwsp_timeline(struct intel_context *ce,
+ struct i915_vma *state)
+{
+ return __intel_timeline_create(ce->engine->gt, state,
+ I915_GEM_HWS_SEQNO_ADDR |
+ INTEL_TIMELINE_CONTEXT);
+}
+
static int __execlists_context_alloc(struct intel_context *ce,
struct intel_engine_cs *engine)
{
@@ -5462,6 +5470,16 @@ static int __execlists_context_alloc(struct
intel_context *ce,
goto error_deref_obj;
}
+ ring = intel_engine_create_ring(engine, (unsigned long)ce->ring);
+ if (IS_ERR(ring)) {
+ ret = PTR_ERR(ring);
+ goto error_deref_obj;
+ }
+
+ ret = populate_lr_context(ce, ctx_obj, engine, ring);
+ if (ret)
+ goto error_ring_free;
+
if (!page_mask_bits(ce->timeline)) {
struct intel_timeline *tl;
@@ -5471,29 +5489,18 @@ static int __execlists_context_alloc(struct
intel_context *ce,
*/
if (unlikely(ce->timeline))
tl = pinned_timeline(ce);
- else
+ else if (intel_engine_has_semaphores(engine))
tl = intel_timeline_create(engine->gt);
+ else
+ tl = pphwsp_timeline(ce, vma);
if (IS_ERR(tl)) {
ret = PTR_ERR(tl);
- goto error_deref_obj;
+ goto error_ring_free;
}
ce->timeline = tl;
}
- ring = intel_engine_create_ring(engine, (unsigned long)ce->ring);
- if (IS_ERR(ring)) {
- ret = PTR_ERR(ring);
- goto error_deref_obj;
- }
-
- ret = populate_lr_context(ce, ctx_obj, engine, ring);
- if (ret) {
- drm_dbg(>i915->drm,
- "Failed to populate LRC: %d\n", ret);
- goto error_ring_free;
- }
-
ce->ring = ring;
ce->state = vma;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC-v1 01/16] drm/i915/pxp: Introduce Intel PXP component
>Repeating the same comment as on previous review, avoid including anything in
>i915_drv.h and only include in the relevant files that require to touch the
>internals of the structs.
I would still need to include i915_drv.h for macro INTEL_GEN(), hopefully it's
acceptable.
-Original Message-
From: Huang, Sean Z
Sent: Monday, December 7, 2020 10:26 AM
To: Joonas Lahtinen ;
Intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] [RFC-v1 01/16] drm/i915/pxp: Introduce Intel PXP
component
Hi Joonas,
Thanks for the details review. I have apply the modification according to the
review, and will update as rev2.
> Description is no more true for single-session only
DONE
> Same here, needs updating.
DONE
>Repeating the same comment as on previous review, avoid including anything in
>i915_drv.h and only include in the relevant files that require to touch the
>internals of the structs.
DONE
> I think this should instead go as part of intel_gt, not here.
DONE
> We should aim to only take struct intel_pxp as parameter for intel_pxp_*
> functions.
DONE, I think the suggestion is reasonable. I expect that will modify the code
significantly in the future commits, but let me try intel_pxp_* instead of i915
> This would be either a major kernel programmer error or the memory would be
> seriously corrupt. No point leaving such checks to production code, so
> GEM_BUG_ON(!i915) would be enough to run the checks in CI and debug builds.
DONE, I just remove the error check
> Also, we have not really initialized anything so it's really premature to
> print anything in this patch.
DONE, remove the print
> Same here, we really want to tighten the scope to intel_pxp and call
> this from intel_gt_fini(), so signature should look like: void
> intel_pxp_fini(struct intel_pxp *pxp)
DONE
Best regards,
Sean
-Original Message-
From: Joonas Lahtinen
Sent: Monday, December 7, 2020 2:01 AM
To: Huang, Sean Z ; Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC-v1 01/16] drm/i915/pxp: Introduce Intel PXP
component
Quoting Huang, Sean Z (2020-12-07 02:21:19)
> PXP (Protected Xe Path) is an i915 componment, available on GEN12+,
> that helps user space to establish the hardware protected session and
> manage the status of each alive software session, as well as the life
> cycle of each session.
>
> By design PXP will expose ioctl so allow user space to create, set,
> and destroy each session. It will also provide the communication
> chanel to TEE (Trusted Execution Environment) for the protected
> hardware session creation.
Description is no more true for single-session only.
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -130,6 +130,25 @@ config DRM_I915_GVT_KVMGT
> Choose this option if you want to enable KVMGT support for
> Intel GVT-g.
>
> +config DRM_I915_PXP
> + bool "Enable Intel PXP support for Intel Gen12+ platform"
> + depends on DRM_I915
> + select INTEL_MEI_PXP
> + default n
> + help
> + This option selects INTEL_MEI_ME if it isn't already selected to
> + enabled full PXP Services on Intel platforms.
> +
> + PXP is an i915 componment, available on Gen12+, that helps user
> + space to establish the hardware protected session and manage the
> + status of each alive software session, as well as the life cycle
> + of each session.
> +
> + PXP expose ioctl so allow user space to create, set, and destroy
> + each session. It will also provide the communication chanel to
> + TEE (Trusted Execution Environment) for the protected hardware
> + session creation.
Same here, needs updating.
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -105,6 +105,8 @@
>
> #include "intel_region_lmem.h"
>
> +#include "pxp/intel_pxp.h"
Repeating the same comment as on previous review, avoid including anything in
i915_drv.h and only include in the relevant files that require to touch the
internals of the structs.
> +
> /* General customization:
> */
>
> @@ -1215,6 +1217,8 @@ struct drm_i915_private {
> /* Mutex to protect the above hdcp component related values. */
> struct mutex hdcp_comp_mutex;
>
> + struct intel_pxp pxp;
I think this should instead go as part of intel_gt, not here.
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include "i915_drv.h"
> +#include "intel_pxp.h"
> +
> +int intel_pxp_init(struct drm_i915_private *i915)
We should aim to only take struct intel_pxp as parameter for intel_pxp_*
functions.
> +{
> + if (!i915)
> + return -EINVAL;
This would be either a major kernel programmer error or the memory would be
seriously corrupt. No point leaving such checks to production code, so
GEM_BUG_ON(!i915) would be enough to run the checks in CI and debug builds.
> + /* PXP
Re: [Intel-gfx] [RFC-v1 01/16] drm/i915/pxp: Introduce Intel PXP component
Hi Joonas,
Thanks for the details review. I have apply the modification according to the
review, and will update as rev2.
> Description is no more true for single-session only
DONE
> Same here, needs updating.
DONE
>Repeating the same comment as on previous review, avoid including anything in
>i915_drv.h and only include in the relevant files that require to touch the
>internals of the structs.
DONE
> I think this should instead go as part of intel_gt, not here.
DONE
> We should aim to only take struct intel_pxp as parameter for intel_pxp_*
> functions.
DONE, I think the suggestion is reasonable. I expect that will modify the code
significantly in the future commits, but let me try intel_pxp_* instead of i915
> This would be either a major kernel programmer error or the memory would be
> seriously corrupt. No point leaving such checks to production code, so
> GEM_BUG_ON(!i915) would be enough to run the checks in CI and debug builds.
DONE, I just remove the error check
> Also, we have not really initialized anything so it's really premature to
> print anything in this patch.
DONE, remove the print
> Same here, we really want to tighten the scope to intel_pxp and call this
> from intel_gt_fini(), so signature should look like: void
> intel_pxp_fini(struct intel_pxp *pxp)
DONE
Best regards,
Sean
-Original Message-
From: Joonas Lahtinen
Sent: Monday, December 7, 2020 2:01 AM
To: Huang, Sean Z ; Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [RFC-v1 01/16] drm/i915/pxp: Introduce Intel PXP
component
Quoting Huang, Sean Z (2020-12-07 02:21:19)
> PXP (Protected Xe Path) is an i915 componment, available on GEN12+,
> that helps user space to establish the hardware protected session and
> manage the status of each alive software session, as well as the life
> cycle of each session.
>
> By design PXP will expose ioctl so allow user space to create, set,
> and destroy each session. It will also provide the communication
> chanel to TEE (Trusted Execution Environment) for the protected
> hardware session creation.
Description is no more true for single-session only.
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -130,6 +130,25 @@ config DRM_I915_GVT_KVMGT
> Choose this option if you want to enable KVMGT support for
> Intel GVT-g.
>
> +config DRM_I915_PXP
> + bool "Enable Intel PXP support for Intel Gen12+ platform"
> + depends on DRM_I915
> + select INTEL_MEI_PXP
> + default n
> + help
> + This option selects INTEL_MEI_ME if it isn't already selected to
> + enabled full PXP Services on Intel platforms.
> +
> + PXP is an i915 componment, available on Gen12+, that helps user
> + space to establish the hardware protected session and manage the
> + status of each alive software session, as well as the life cycle
> + of each session.
> +
> + PXP expose ioctl so allow user space to create, set, and destroy
> + each session. It will also provide the communication chanel to
> + TEE (Trusted Execution Environment) for the protected hardware
> + session creation.
Same here, needs updating.
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -105,6 +105,8 @@
>
> #include "intel_region_lmem.h"
>
> +#include "pxp/intel_pxp.h"
Repeating the same comment as on previous review, avoid including anything in
i915_drv.h and only include in the relevant files that require to touch the
internals of the structs.
> +
> /* General customization:
> */
>
> @@ -1215,6 +1217,8 @@ struct drm_i915_private {
> /* Mutex to protect the above hdcp component related values. */
> struct mutex hdcp_comp_mutex;
>
> + struct intel_pxp pxp;
I think this should instead go as part of intel_gt, not here.
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include "i915_drv.h"
> +#include "intel_pxp.h"
> +
> +int intel_pxp_init(struct drm_i915_private *i915)
We should aim to only take struct intel_pxp as parameter for intel_pxp_*
functions.
> +{
> + if (!i915)
> + return -EINVAL;
This would be either a major kernel programmer error or the memory would be
seriously corrupt. No point leaving such checks to production code, so
GEM_BUG_ON(!i915) would be enough to run the checks in CI and debug builds.
> + /* PXP only available for GEN12+ */
> + if (INTEL_GEN(i915) < 12)
> + return 0;
I think -ENODEV would be more appropriate return value. Also, we should look
into returning this error value from inside the actual init code.
We want the user to be able to differentiate between kernel does not support
and hardware does not support status.
> + drm_info(>drm, "i915 PXP is inited with i915=[%p]\n",
> + i915);
We shouldn't be printing the pointer values, especially not in INFO level
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Improve error reporting for igt_mock_max_segment (rev2)
== Series Details == Series: drm/i915/selftests: Improve error reporting for igt_mock_max_segment (rev2) URL : https://patchwork.freedesktop.org/series/84641/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9453_full -> Patchwork_19075_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19075_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19075_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19075_full: ### IGT changes ### Possible regressions * igt@kms_flip_tiling@flip-yf-tiled@edp-1-pipe-c: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-skl5/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-c.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/shard-skl7/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-c.html New tests - New tests have been introduced between CI_DRM_9453_full and Patchwork_19075_full: ### New CI tests (1) ### * boot: - Statuses : 200 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_19075_full that come from known issues: ### IGT changes ### Issues hit * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][3] -> [INCOMPLETE][4] ([i915#1436]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-glk7/igt@gen9_exec_pa...@allowed-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/shard-glk3/igt@gen9_exec_pa...@allowed-all.html * igt@kms_color@pipe-a-ctm-0-5: - shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-skl1/igt@kms_co...@pipe-a-ctm-0-5.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/shard-skl1/igt@kms_co...@pipe-a-ctm-0-5.html * igt@kms_cursor_crc@pipe-a-cursor-256x256-random: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#54]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-256x256-random.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-256x256-random.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1: - shard-skl: [PASS][9] -> [FAIL][10] ([i915#2122]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-skl8/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/shard-skl3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#108145] / [i915#265]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109642] / [fdo#111068]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-iclb2/igt@kms_psr2_su@page_flip.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/shard-iclb6/igt@kms_psr2_su@page_flip.html * igt@sysfs_heartbeat_interval@mixed@bcs0: - shard-kbl: [PASS][15] -> [INCOMPLETE][16] ([i915#1731]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-kbl3/igt@sysfs_heartbeat_interval@mi...@bcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/shard-kbl3/igt@sysfs_heartbeat_interval@mi...@bcs0.html Possible fixes * igt@gem_workarounds@suspend-resume-context: - shard-apl: [INCOMPLETE][17] ([i915#2295]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-apl4/igt@gem_workarou...@suspend-resume-context.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/shard-apl4/igt@gem_workarou...@suspend-resume-context.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [DMESG-WARN][19] ([i915#1436] / [i915#716]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-skl4/igt@gen9_exec_pa...@allowed-single.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/shard-skl1/igt@gen9_exec_pa...@allowed-single.html * igt@i915_selftest@live@gt_heartbeat: - shard-skl: [DMESG-FAIL][21] ([i915#2291] / [i915#541]) -> [PASS][22] [21]:
Re: [Intel-gfx] [PATCH 03/17] drivers/gpu: Convert to mem*_page()
On Sun, Dec 06 2020 at 22:46, Ira Weiny wrote: > On Fri, Dec 04, 2020 at 11:33:08PM +0100, Thomas Gleixner wrote: >> On Fri, Dec 04 2020 at 08:05, Ira Weiny wrote: >> > So I think I'm going to submit the base patch to Andrew today (with some >> > cleanups per the comments in this thread). >> >> Could you please base that on tip core/mm where the kmap_local() muck is >> and use kmap_local() right away? > > Sure. Would that mean it should go through you and not Andrew? If Andrew has no objections of course. Thanks, tglx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] i915/query: Directly check query results against GETPARAM
Simplify the cross-check by asserting that the existence of an engine in
the list matches the existence of the engine as reported by GETPARAM.
By using the comparison, we check both directions at once.
Signed-off-by: Chris Wilson
Cc: Petri Latvala
---
tests/i915/i915_query.c | 49 -
1 file changed, 9 insertions(+), 40 deletions(-)
diff --git a/tests/i915/i915_query.c b/tests/i915/i915_query.c
index cdf2d3403..b415650ae 100644
--- a/tests/i915/i915_query.c
+++ b/tests/i915/i915_query.c
@@ -719,46 +719,15 @@ static void engines(int fd)
gem_context_reset_engines(fd, 0);
/* Check results match the legacy GET_PARAM (where we can). */
- for (i = 0; i < engines->num_engines; i++) {
- struct drm_i915_engine_info *engine =
- (struct drm_i915_engine_info *)>engines[i];
-
- switch (engine->engine.engine_class) {
- case I915_ENGINE_CLASS_RENDER:
- /* Will be tested later. */
- break;
- case I915_ENGINE_CLASS_COPY:
- igt_assert(gem_has_blt(fd));
- break;
- case I915_ENGINE_CLASS_VIDEO:
- switch (engine->engine.engine_instance) {
- case 0:
- igt_assert(gem_has_bsd(fd));
- break;
- case 1:
- igt_assert(gem_has_bsd2(fd));
- break;
- }
- break;
- case I915_ENGINE_CLASS_VIDEO_ENHANCE:
- igt_assert(gem_has_vebox(fd));
- break;
- default:
- igt_assert(0);
- }
- }
-
- /* Reverse check to the above - all GET_PARAM engines are present. */
- igt_assert(has_engine(engines, I915_ENGINE_CLASS_RENDER, 0));
- if (gem_has_blt(fd))
- igt_assert(has_engine(engines, I915_ENGINE_CLASS_COPY, 0));
- if (gem_has_bsd(fd))
- igt_assert(has_engine(engines, I915_ENGINE_CLASS_VIDEO, 0));
- if (gem_has_bsd2(fd))
- igt_assert(has_engine(engines, I915_ENGINE_CLASS_VIDEO, 1));
- if (gem_has_vebox(fd))
- igt_assert(has_engine(engines, I915_ENGINE_CLASS_VIDEO_ENHANCE,
- 0));
+ igt_assert_eq(has_engine(engines, I915_ENGINE_CLASS_RENDER, 0), 1);
+ igt_assert_eq(has_engine(engines, I915_ENGINE_CLASS_COPY, 0),
+ gem_has_blt(fd));
+ igt_assert_eq(has_engine(engines, I915_ENGINE_CLASS_VIDEO, 0),
+ gem_has_bsd(fd));
+ igt_assert_eq(has_engine(engines, I915_ENGINE_CLASS_VIDEO, 1),
+ gem_has_bsd2(fd));
+ igt_assert_eq(has_engine(engines, I915_ENGINE_CLASS_VIDEO_ENHANCE, 0),
+ gem_has_vebox(fd));
free(engines);
}
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] i915/query: Cross-check engine list against execbuf interface
Check that every engine listed can be used in execbuf.
Signed-off-by: Chris Wilson
Cc: Andi Shyti
Cc: Tvrtko Ursulin
---
tests/i915/i915_query.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/tests/i915/i915_query.c b/tests/i915/i915_query.c
index e7c6fc91e..cdf2d3403 100644
--- a/tests/i915/i915_query.c
+++ b/tests/i915/i915_query.c
@@ -633,6 +633,16 @@ has_engine(struct drm_i915_query_engine_info *engines,
return false;
}
+static void gem_context_reset_engines(int i915, uint32_t ctx)
+{
+ struct drm_i915_gem_context_param param = {
+ .ctx_id = ctx,
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ };
+
+ gem_context_set_param(i915, );
+}
+
static void engines(int fd)
{
struct drm_i915_query_engine_info *engines;
@@ -678,10 +688,24 @@ static void engines(int fd)
igt_assert_eq(engines->rsvd[1], 0);
igt_assert_eq(engines->rsvd[2], 0);
- /* Check results match the legacy GET_PARAM (where we can). */
+ /* Confirm the individual engines exist with EXECBUFFER2 */
for (i = 0; i < engines->num_engines; i++) {
struct drm_i915_engine_info *engine =
(struct drm_i915_engine_info *)>engines[i];
+ I915_DEFINE_CONTEXT_PARAM_ENGINES(p_engines, 1) = {
+ .engines = { engine->engine }
+ };
+ struct drm_i915_gem_context_param param = {
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(_engines),
+ .size = sizeof(p_engines),
+ };
+
+ struct drm_i915_gem_exec_object2 obj = {};
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ };
igt_debug("%u: class=%u instance=%u flags=%llx
capabilities=%llx\n",
i,
@@ -689,6 +713,15 @@ static void engines(int fd)
engine->engine.engine_instance,
engine->flags,
engine->capabilities);
+ gem_context_set_param(fd, );
+ igt_assert_eq(__gem_execbuf(fd, ), -ENOENT);
+ }
+ gem_context_reset_engines(fd, 0);
+
+ /* Check results match the legacy GET_PARAM (where we can). */
+ for (i = 0; i < engines->num_engines; i++) {
+ struct drm_i915_engine_info *engine =
+ (struct drm_i915_engine_info *)>engines[i];
switch (engine->engine.engine_class) {
case I915_ENGINE_CLASS_RENDER:
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Fixing the error handling of shmem_pin_map
== Series Details == Series: drm/i915/gt: Fixing the error handling of shmem_pin_map URL : https://patchwork.freedesktop.org/series/84637/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9453_full -> Patchwork_19074_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19074_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19074_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19074_full: ### IGT changes ### Possible regressions * igt@gem_exec_capture@capture: - shard-tglb: NOTRUN -> [TIMEOUT][1] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/shard-tglb6/igt@gem_exec_capt...@capture.html * igt@kms_flip_tiling@flip-yf-tiled@edp-1-pipe-c: - shard-skl: [PASS][2] -> [FAIL][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-skl5/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-c.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/shard-skl8/igt@kms_flip_tiling@flip-yf-ti...@edp-1-pipe-c.html * igt@kms_plane_alpha_blend@pipe-c-coverage-vs-premult-vs-constant: - shard-tglb: [PASS][4] -> [TIMEOUT][5] +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-tglb1/igt@kms_plane_alpha_bl...@pipe-c-coverage-vs-premult-vs-constant.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/shard-tglb6/igt@kms_plane_alpha_bl...@pipe-c-coverage-vs-premult-vs-constant.html New tests - New tests have been introduced between CI_DRM_9453_full and Patchwork_19074_full: ### New CI tests (1) ### * boot: - Statuses : 200 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_19074_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-queues-all: - shard-glk: [PASS][6] -> [DMESG-WARN][7] ([i915#118] / [i915#95]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-glk1/igt@gem_exec_whis...@basic-queues-all.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/shard-glk1/igt@gem_exec_whis...@basic-queues-all.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][8] -> [INCOMPLETE][9] ([i915#1436]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-glk7/igt@gen9_exec_pa...@allowed-all.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/shard-glk3/igt@gen9_exec_pa...@allowed-all.html * igt@i915_suspend@sysfs-reader: - shard-iclb: [PASS][10] -> [INCOMPLETE][11] ([i915#1185]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-iclb3/igt@i915_susp...@sysfs-reader.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/shard-iclb3/igt@i915_susp...@sysfs-reader.html * igt@kms_async_flips@test-time-stamp: - shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2574]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-tglb3/igt@kms_async_fl...@test-time-stamp.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/shard-tglb6/igt@kms_async_fl...@test-time-stamp.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][14] -> [FAIL][15] ([fdo#108145] / [i915#265]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_cursor_mmap_gtt: - shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#109441]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_gtt.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/shard-iclb7/igt@kms_psr@psr2_cursor_mmap_gtt.html Possible fixes * igt@gem_exec_whisper@basic-contexts-forked: - shard-glk: [DMESG-WARN][18] ([i915#118] / [i915#95]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-glk1/igt@gem_exec_whis...@basic-contexts-forked.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/shard-glk8/igt@gem_exec_whis...@basic-contexts-forked.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [INCOMPLETE][20] ([i915#2295]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/shard-apl4/igt@gem_workarou...@suspend-resume-context.html [21]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Improve error reporting for igt_mock_max_segment (rev2)
== Series Details ==
Series: drm/i915/selftests: Improve error reporting for igt_mock_max_segment
(rev2)
URL : https://patchwork.freedesktop.org/series/84641/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9453 -> Patchwork_19075
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_19075:
### CI changes ###
Possible regressions
* boot (NEW):
- {fi-dg1-1}: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/fi-dg1-1/boot.html
New tests
-
New tests have been introduced between CI_DRM_9453 and Patchwork_19075:
### New CI tests (1) ###
* boot:
- Statuses : 1 fail(s) 39 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_19075 that come from known issues:
### IGT changes ###
Issues hit
* igt@prime_self_import@basic-with_two_bos:
- fi-tgl-y: [PASS][2] -> [DMESG-WARN][3] ([i915#402]) +1 similar
issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html
Possible fixes
* igt@i915_hangman@error-state-basic:
- fi-tgl-y: [DMESG-WARN][4] ([i915#402]) -> [PASS][5] +2 similar
issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/fi-tgl-y/igt@i915_hang...@error-state-basic.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/fi-tgl-y/igt@i915_hang...@error-state-basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
Participating hosts (44 -> 40)
--
Additional (1): fi-dg1-1
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9453 -> Patchwork_19075
CI-20190529: 20190529
CI_DRM_9453: 52e2ca46b7e2aa62c0509bce0be189d2f5a7325f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5883: 02244f60c98b4e4106b1099ade3439b159ac848e @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19075: ce3956bde786d896f93a805cd80ea0d5f06b983f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ce3956bde786 drm/i915/selftests: Improve error reporting for
igt_mock_max_segment
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19075/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable outputs during unregister
On Fri, Dec 04, 2020 at 04:14:05PM +, Chris Wilson wrote: > Quoting Ville Syrjälä (2020-12-04 16:01:11) > > On Tue, Dec 01, 2020 at 10:38:57PM +, Chris Wilson wrote: > > > Quoting Ville Syrjälä (2020-12-01 16:05:17) > > > > On Fri, Nov 27, 2020 at 10:05:48PM +, Chris Wilson wrote: > > > > > Switch off the scanout during driver unregister, so we can shutdown > > > > > the > > > > > HW immediately for unbind. > > > > > > > > > > Signed-off-by: Chris Wilson > > > > > --- > > > > > drivers/gpu/drm/i915/i915_drv.c | 1 + > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > > > > b/drivers/gpu/drm/i915/i915_drv.c > > > > > index 320856b665a1..62d188e5cb8d 100644 > > > > > --- a/drivers/gpu/drm/i915/i915_drv.c > > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > > > > @@ -738,6 +738,7 @@ static void i915_driver_unregister(struct > > > > > drm_i915_private *dev_priv) > > > > >* events. > > > > >*/ > > > > > drm_kms_helper_poll_fini(_priv->drm); > > > > > + drm_atomic_helper_shutdown(_priv->drm); > > > > > > > > Looks like we already have this in remove(). Is that too late? > > > > > > For the operations we do during unbind, yes. > > > > > > For the core_hotplug/rebind dance, we have to reset the GPU while we > > > still have runtime-pm operational and have pushed the reset to > > > unregister (from experimentation that's as late as we can put it where > > > the GPU works after rebinding and we don't corrupt the system on unbind, > > > with the current hooks). You can guess how well gen3 likes that. > > > > > > But I don't think the right answer is to skip the reset for gen3. > > > Suppose we enable context support for gen3, then the reset would be > > > required as well, and so we would still need the whole display > > > shenanigans to turn it off. Moving the modeset to turn the display off > > > to the end of userspace seems reasonable. > > > > Yeah, just a bit odd to have the same call twice in the > > sequence. Can we remove the second call at least? > > I think we can, but I am sufficiently paranoid to leave it. > I presume if it is a no-op, it will return without touching HW? One can hope at least. > > > Also a bit annoying the unload sequence no longer matches the > > suspend sequence. Well, I guess it was never 100% anyway but > > I think it was a bit closer before this patch. But the whole > > thing is rather messy anyway so I guess t's not significantly > > worse after this. > > Yes, I feel things have been thrown into a bit of disarray by > haphazardly fixing unbind. > > The last* remaining fly in the ointment is rebinding iommu. Once we have > that solid (and the system stops randomly eating itself 1-10 minutes > after the test passes), we should be in a much better spot to safely > remove duplication and refine the flow. > > * that I am aware of. > -Chris -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Improve error reporting for igt_mock_max_segment
On 2020-12-07 at 13:03:46 +, Chris Wilson wrote:
> When we fail to find a single block large enough to require splitting,
> report the largest block we did find.
>
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc: Ramalingam C
> ---
> .../gpu/drm/i915/selftests/intel_memory_region.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> index a0b518c255de..a55079a061dd 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
> @@ -384,16 +384,15 @@ static int igt_mock_max_segment(void *arg)
> goto out_put;
> }
>
> - err = -EINVAL;
> + size = 0;
> list_for_each_entry(block, >mm.blocks, link) {
> - if (i915_buddy_block_size(>mm, block) > max_segment) {
> - err = 0;
> - break;
> - }
> + if (i915_buddy_block_size(>mm, block) > size)
> + size = i915_buddy_block_size(>mm, block);
> }
> - if (err) {
> - pr_err("%s: Failed to create a huge contiguous block\n",
> -__func__);
> + if (size < max_segment) {
> + pr_err("%s: Failed to create a huge contiguous block [> %u],
> largest block %lld\n",
> +__func__, max_segment, size);
> + err = -EINVAL;
Reviewed-by: Ramalingam C
> goto out_close;
> }
>
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 113/162] drm/i915: Create stolen memory region from local memory
On Fri, 27 Nov 2020, Matthew Auld wrote:
> From: CQ Tang
>
> Add "REGION_STOLEN" device info to dg1, create stolen memory
> region from upper portion of local device memory, starting
> from DSMBASE.
>
> The memory region is marked with "is_devmem=true".
>
> Cc: Joonas Lahtinen
> Cc: Matthew Auld
> Cc: Abdiel Janulgue
> Cc: Chris P Wilson
> Cc: Balestrieri, Francesco
> Cc: Niranjana Vishwanathapura
> Cc: Venkata S Dhanalakota
> Cc: Neel Desai
> Cc: Matthew Brost
> Cc: Sudeep Dutt
> Signed-off-by: CQ Tang
> Cc: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 4 +-
> drivers/gpu/drm/i915/gem/i915_gem_lmem.h | 7 +++
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 56 +-
> drivers/gpu/drm/i915/i915_pci.c| 2 +-
> drivers/gpu/drm/i915/i915_reg.h| 1 +
> drivers/gpu/drm/i915/intel_memory_region.c | 5 ++
> drivers/gpu/drm/i915/intel_memory_region.h | 2 +-
> 7 files changed, 71 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> index 71c07e1f6f26..b2fd2bc862c0 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> @@ -111,8 +111,8 @@ int i915_gem_object_lmem_pread(struct drm_i915_gem_object
> *obj,
> return ret;
> }
>
> -static int i915_gem_object_lmem_pwrite(struct drm_i915_gem_object *obj,
> -const struct drm_i915_gem_pwrite *arg)
> +int i915_gem_object_lmem_pwrite(struct drm_i915_gem_object *obj,
> + const struct drm_i915_gem_pwrite *arg)
> {
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
> struct intel_runtime_pm *rpm = >runtime_pm;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> index e11e0545e39c..c59aa6c014c7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.h
> @@ -11,9 +11,16 @@
> struct drm_i915_private;
> struct drm_i915_gem_object;
> struct intel_memory_region;
> +struct drm_i915_gem_pread;
> +struct drm_i915_gem_pwrite;
>
> extern const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops;
>
> +int i915_gem_object_lmem_pread(struct drm_i915_gem_object *obj,
> +const struct drm_i915_gem_pread *args);
> +int i915_gem_object_lmem_pwrite(struct drm_i915_gem_object *obj,
> + const struct drm_i915_gem_pwrite *args);
> +
> void __iomem *
> i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
> unsigned long n,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index 0ddf48e472a0..633745336f40 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -10,6 +10,7 @@
> #include
> #include
>
> +#include "gem/i915_gem_lmem.h"
> #include "gem/i915_gem_region.h"
> #include "i915_drv.h"
> #include "i915_gem_stolen.h"
> @@ -121,6 +122,14 @@ static int i915_adjust_stolen(struct drm_i915_private
> *i915,
> }
> }
>
> + /*
> + * With device local memory, we don't need to check the address range,
> + * this is device memory physical address, could overlap with system
> + * memory.
> + */
> + if (HAS_LMEM(i915))
> + return 0;
> +
> /*
>* Verify that nothing else uses this physical address. Stolen
>* memory should be reserved by the BIOS and hidden from the
> @@ -607,7 +616,7 @@ static void i915_gem_object_put_pages_stolen(struct
> drm_i915_gem_object *obj,
> kfree(pages);
> }
>
> -static const struct drm_i915_gem_object_ops i915_gem_object_stolen_ops = {
> +static struct drm_i915_gem_object_ops i915_gem_object_stolen_ops = {
Making driver specific ops non-const seems suspicious...
> .name = "i915_gem_object_stolen",
> .get_pages = i915_gem_object_get_pages_stolen,
> .put_pages = i915_gem_object_put_pages_stolen,
> @@ -716,7 +725,19 @@ i915_gem_object_create_stolen(struct drm_i915_private
> *i915,
>
> static int init_stolen(struct intel_memory_region *mem)
> {
> - intel_memory_region_set_name(mem, "stolen");
> + if (mem->type == INTEL_MEMORY_STOLEN_SYSTEM)
> + intel_memory_region_set_name(mem, "stolen-system");
> + else
> + intel_memory_region_set_name(mem, "stolen-local");
> +
> + if (HAS_LMEM(mem->i915)) {
> + i915_gem_object_stolen_ops.pread = i915_gem_object_lmem_pread;
> + i915_gem_object_stolen_ops.pwrite = i915_gem_object_lmem_pwrite;
...and AFAICT this modifies the ops for all devices, including the
integrated GPU, if any of the devices HAS_LMEM().
BR,
Jani.
> + if (!io_mapping_init_wc(>iomap,
> + mem->io_start,
> +
Re: [Intel-gfx] [PATCH i-g-t v2] runner: Don't kill a test on taint if watching timeouts
On Mon, 2020-12-07 at 15:09 +0200, Petri Latvala wrote:
> On Fri, Dec 04, 2020 at 08:50:07PM +0100, Janusz Krzysztofik wrote:
> > We may still be interested in results of a test even if it has tainted
> > the kernel. On the other hand, we need to kill the test on taint if no
> > other means of killing it on a jam is active.
> >
> > If abort on both kernel taint or a timeout is requested, decrease all
> > potential timeouts significantly while the taint is detected instead of
> > aborting immediately. However, report the taint as the reason of the
> > abort if a timeout decreased by the taint expires.
> >
> > v2: Fix missing show_kernel_task_state() lost on rebase conflict
> > resolution (Chris - thanks!)
> >
> > Signed-off-by: Janusz Krzysztofik
>
> The effects of this is that we sometimes now get more logs from a test
> at the cost of it not directly showing up as an incomplete. We would
> still get the igt@runner@aborted result for it so overall we still
> catch tainting cases.
>
> Chris's comments have been clarified off-list not to mean directly
> opposing this patch, so
>
>
> Reviewed-by: Petri Latvala
Thanks, pushed.
Janusz
>
>
>
> > ---
> > runner/executor.c | 26 --
> > 1 file changed, 20 insertions(+), 6 deletions(-)
> >
> > diff --git a/runner/executor.c b/runner/executor.c
> > index 1688ae41d..faf272d85 100644
> > --- a/runner/executor.c
> > +++ b/runner/executor.c
> > @@ -726,6 +726,8 @@ static const char *need_to_timeout(struct settings
> > *settings,
> >double time_since_kill,
> >size_t disk_usage)
> > {
> > + int decrease = 1;
> > +
> > if (killed) {
> > /*
> > * Timeout after being killed is a hardcoded amount
> > @@ -753,20 +755,32 @@ static const char *need_to_timeout(struct settings
> > *settings,
> > }
> >
> > /*
> > -* If we're configured to care about taints, kill the
> > -* test if there's a taint.
> > +* If we're configured to care about taints,
> > +* decrease timeouts in use if there's a taint,
> > +* or kill the test if no timeouts have been requested.
> > */
> > if (settings->abort_mask & ABORT_TAINT &&
> > - is_tainted(taints))
> > - return "Killing the test because the kernel is tainted.\n";
> > + is_tainted(taints)) {
> > + /* list of timeouts that may postpone immediate kill on taint */
> > + if (settings->per_test_timeout || settings->inactivity_timeout)
> > + decrease = 10;
> > + else
> > + return "Killing the test because the kernel is
> > tainted.\n";
> > + }
> >
> > if (settings->per_test_timeout != 0 &&
> > - time_since_subtest > settings->per_test_timeout)
> > + time_since_subtest > settings->per_test_timeout / decrease) {
> > + if (decrease > 1)
> > + return "Killing the test because the kernel is
> > tainted.\n";
> > return show_kernel_task_state("Per-test timeout exceeded.
> > Killing the current test with SIGQUIT.\n");
> > + }
> >
> > if (settings->inactivity_timeout != 0 &&
> > - time_since_activity > settings->inactivity_timeout)
> > + time_since_activity > settings->inactivity_timeout / decrease ) {
> > + if (decrease > 1)
> > + return "Killing the test because the kernel is
> > tainted.\n";
> > return show_kernel_task_state("Inactivity timeout exceeded.
> > Killing the current test with SIGQUIT.\n");
> > + }
> >
> > if (disk_usage_limit_exceeded(settings, disk_usage))
> > return "Disk usage limit exceeded.\n";
> > --
> > 2.21.1
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] runner: Don't kill a test on taint if watching timeouts
On Fri, Dec 04, 2020 at 08:50:07PM +0100, Janusz Krzysztofik wrote:
> We may still be interested in results of a test even if it has tainted
> the kernel. On the other hand, we need to kill the test on taint if no
> other means of killing it on a jam is active.
>
> If abort on both kernel taint or a timeout is requested, decrease all
> potential timeouts significantly while the taint is detected instead of
> aborting immediately. However, report the taint as the reason of the
> abort if a timeout decreased by the taint expires.
>
> v2: Fix missing show_kernel_task_state() lost on rebase conflict
> resolution (Chris - thanks!)
>
> Signed-off-by: Janusz Krzysztofik
The effects of this is that we sometimes now get more logs from a test
at the cost of it not directly showing up as an incomplete. We would
still get the igt@runner@aborted result for it so overall we still
catch tainting cases.
Chris's comments have been clarified off-list not to mean directly
opposing this patch, so
Reviewed-by: Petri Latvala
> ---
> runner/executor.c | 26 --
> 1 file changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/runner/executor.c b/runner/executor.c
> index 1688ae41d..faf272d85 100644
> --- a/runner/executor.c
> +++ b/runner/executor.c
> @@ -726,6 +726,8 @@ static const char *need_to_timeout(struct settings
> *settings,
> double time_since_kill,
> size_t disk_usage)
> {
> + int decrease = 1;
> +
> if (killed) {
> /*
>* Timeout after being killed is a hardcoded amount
> @@ -753,20 +755,32 @@ static const char *need_to_timeout(struct settings
> *settings,
> }
>
> /*
> - * If we're configured to care about taints, kill the
> - * test if there's a taint.
> + * If we're configured to care about taints,
> + * decrease timeouts in use if there's a taint,
> + * or kill the test if no timeouts have been requested.
>*/
> if (settings->abort_mask & ABORT_TAINT &&
> - is_tainted(taints))
> - return "Killing the test because the kernel is tainted.\n";
> + is_tainted(taints)) {
> + /* list of timeouts that may postpone immediate kill on taint */
> + if (settings->per_test_timeout || settings->inactivity_timeout)
> + decrease = 10;
> + else
> + return "Killing the test because the kernel is
> tainted.\n";
> + }
>
> if (settings->per_test_timeout != 0 &&
> - time_since_subtest > settings->per_test_timeout)
> + time_since_subtest > settings->per_test_timeout / decrease) {
> + if (decrease > 1)
> + return "Killing the test because the kernel is
> tainted.\n";
> return show_kernel_task_state("Per-test timeout exceeded.
> Killing the current test with SIGQUIT.\n");
> + }
>
> if (settings->inactivity_timeout != 0 &&
> - time_since_activity > settings->inactivity_timeout)
> + time_since_activity > settings->inactivity_timeout / decrease ) {
> + if (decrease > 1)
> + return "Killing the test because the kernel is
> tainted.\n";
> return show_kernel_task_state("Inactivity timeout exceeded.
> Killing the current test with SIGQUIT.\n");
> + }
>
> if (disk_usage_limit_exceeded(settings, disk_usage))
> return "Disk usage limit exceeded.\n";
> --
> 2.21.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Improve error reporting for igt_mock_max_segment
When we fail to find a single block large enough to require splitting,
report the largest block we did find.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Ramalingam C
---
.../gpu/drm/i915/selftests/intel_memory_region.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
index a0b518c255de..a55079a061dd 100644
--- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
@@ -384,16 +384,15 @@ static int igt_mock_max_segment(void *arg)
goto out_put;
}
- err = -EINVAL;
+ size = 0;
list_for_each_entry(block, >mm.blocks, link) {
- if (i915_buddy_block_size(>mm, block) > max_segment) {
- err = 0;
- break;
- }
+ if (i915_buddy_block_size(>mm, block) > size)
+ size = i915_buddy_block_size(>mm, block);
}
- if (err) {
- pr_err("%s: Failed to create a huge contiguous block\n",
- __func__);
+ if (size < max_segment) {
+ pr_err("%s: Failed to create a huge contiguous block [> %u],
largest block %lld\n",
+ __func__, max_segment, size);
+ err = -EINVAL;
goto out_close;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Improve error reporting for igt_mock_max_segment
When we fail to find a single block large enough to require splitting,
report the largest block we did find.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Ramalingam C
---
.../gpu/drm/i915/selftests/intel_memory_region.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
index a0b518c255de..b03c2adfcf27 100644
--- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
@@ -384,16 +384,15 @@ static int igt_mock_max_segment(void *arg)
goto out_put;
}
- err = -EINVAL;
+ size = 0;
list_for_each_entry(block, >mm.blocks, link) {
- if (i915_buddy_block_size(>mm, block) > max_segment) {
- err = 0;
- break;
- }
+ if (i915_buddy_block_size(>mm, block) > size)
+ size = i915_buddy_block_size(>mm, block);
}
- if (err) {
- pr_err("%s: Failed to create a huge contiguous block\n",
- __func__);
+ if (size < max_segment) {
+ pr_err("%s: Failed to create a huge contiguous block, largest
block %lld\n",
+ __func__, size);
+ err = -EINVAL;
goto out_close;
}
--
2.20.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/gt: Fixing the error handling of shmem_pin_map
== Series Details ==
Series: drm/i915/gt: Fixing the error handling of shmem_pin_map
URL : https://patchwork.freedesktop.org/series/84637/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9453 -> Patchwork_19074
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_19074:
### CI changes ###
Possible regressions
* boot (NEW):
- {fi-dg1-1}: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/fi-dg1-1/boot.html
New tests
-
New tests have been introduced between CI_DRM_9453 and Patchwork_19074:
### New CI tests (1) ###
* boot:
- Statuses : 1 fail(s) 39 pass(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_19074 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_getparams_basic@basic-subslice-total:
- fi-tgl-y: [PASS][2] -> [DMESG-WARN][3] ([i915#402]) +1 similar
issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html
Possible fixes
* igt@i915_hangman@error-state-basic:
- fi-tgl-y: [DMESG-WARN][4] ([i915#402]) -> [PASS][5] +2 similar
issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9453/fi-tgl-y/igt@i915_hang...@error-state-basic.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/fi-tgl-y/igt@i915_hang...@error-state-basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
Participating hosts (44 -> 40)
--
Additional (1): fi-dg1-1
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9453 -> Patchwork_19074
CI-20190529: 20190529
CI_DRM_9453: 52e2ca46b7e2aa62c0509bce0be189d2f5a7325f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5883: 02244f60c98b4e4106b1099ade3439b159ac848e @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_19074: 078213cdececf1a6a14eff6e67f004ff761d0cd3 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
078213cdecec drm/i915/gt: Fixing the error handling of shmem_pin_map
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19074/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC-v1 09/16] drm/i915/pxp: Func to send hardware session termination
Quoting Huang, Sean Z (2020-12-07 02:21:27)
> Implement the functions to allow PXP to send a GPU command, in
> order to terminate the hardware session, so hardware can recycle
> this session slot for the next usage.
>
> Signed-off-by: Huang, Sean Z
As we only have a singleton session support in this series, maybe this
patch is not needed?
I don't think we should add functions to arbitarily inject commands to VCS0
from another driver. We should add proper functions for the commands in i915
and call them on demand and add EXPORT_SYMBOL for them.
Regards, Joonas
> ---
> drivers/gpu/drm/i915/pxp/intel_pxp_sm.c | 150
> 1 file changed, 150 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
> index 056f65fbaf4e..c88243e02a3c 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
> @@ -3,13 +3,163 @@
> * Copyright(c) 2020, Intel Corporation. All rights reserved.
> */
>
> +#include "gt/intel_gpu_commands.h"
> +#include "gt/intel_gt.h"
> #include "gt/intel_context.h"
> +#include "gt/intel_gt_buffer_pool.h"
> #include "gt/intel_engine_pm.h"
>
> #include "intel_pxp.h"
> #include "intel_pxp_sm.h"
> #include "intel_pxp_context.h"
>
> +static struct i915_vma *pxp_get_batch(struct drm_i915_private *i915,
> + struct intel_context *ce,
> + struct intel_gt_buffer_pool_node *pool,
> + u32 *cmd_buf, int cmd_size_in_dw)
> +{
> + struct i915_vma *batch = ERR_PTR(-EINVAL);
> + u32 *cmd;
> +
> + if (!ce || !ce->engine || !cmd_buf)
> + return ERR_PTR(-EINVAL);
> +
> + if (cmd_size_in_dw * 4 > PAGE_SIZE) {
> + drm_err(>drm, "Failed to %s, invalid
> cmd_size_id_dw=[%d]\n",
> + __func__, cmd_size_in_dw);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + cmd = i915_gem_object_pin_map(pool->obj, I915_MAP_FORCE_WC);
> + if (IS_ERR(cmd)) {
> + drm_err(>drm, "Failed to i915_gem_object_pin_map()\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + memcpy(cmd, cmd_buf, cmd_size_in_dw * 4);
> +
> + if (drm_debug_enabled(DRM_UT_DRIVER)) {
> + print_hex_dump(KERN_DEBUG, "cmd binaries:",
> + DUMP_PREFIX_OFFSET, 4, 4, cmd, cmd_size_in_dw
> * 4, true);
> + }
> +
> + i915_gem_object_unpin_map(pool->obj);
> +
> + batch = i915_vma_instance(pool->obj, ce->vm, NULL);
> + if (IS_ERR(batch)) {
> + drm_err(>drm, "Failed to i915_vma_instance()\n");
> + return batch;
> + }
> +
> + return batch;
> +}
> +
> +static int pxp_submit_cmd(struct drm_i915_private *i915, u32 *cmd, int
> cmd_size_in_dw)
> +{
> + int err = -EINVAL;
> + struct i915_vma *batch;
> + struct i915_request *rq;
> + struct intel_context *ce = NULL;
> + bool is_engine_pm_get = false;
> + bool is_batch_vma_pin = false;
> + bool is_skip_req_on_err = false;
> + bool is_engine_get_pool = false;
> + struct intel_gt_buffer_pool_node *pool = NULL;
> + struct intel_gt *gt = NULL;
> +
> + if (!i915 || !HAS_ENGINE(>gt, VCS0) ||
> + !i915->gt.engine[VCS0]->kernel_context) {
> + err = -EINVAL;
> + goto end;
> + }
> +
> + if (!cmd || (cmd_size_in_dw * 4) > PAGE_SIZE) {
> + drm_err(>drm, "Failed to %s bad params\n", __func__);
> + return -EINVAL;
> + }
> +
> + gt = >gt;
> + ce = i915->gt.engine[VCS0]->kernel_context;
> +
> + intel_engine_pm_get(ce->engine);
> + is_engine_pm_get = true;
> +
> + pool = intel_gt_get_buffer_pool(gt, PAGE_SIZE);
> + if (IS_ERR(pool)) {
> + drm_err(>drm, "Failed to intel_engine_get_pool()\n");
> + goto end;
> + }
> + is_engine_get_pool = true;
> +
> + batch = pxp_get_batch(i915, ce, pool, cmd, cmd_size_in_dw);
> + if (IS_ERR(batch)) {
> + drm_err(>drm, "Failed to pxp_get_batch()\n");
> + goto end;
> + }
> +
> + err = i915_vma_pin(batch, 0, 0, PIN_USER);
> + if (err) {
> + drm_err(>drm, "Failed to i915_vma_pin()\n");
> + goto end;
> + }
> + is_batch_vma_pin = true;
> +
> + rq = intel_context_create_request(ce);
> + if (IS_ERR(rq)) {
> + drm_err(>drm, "Failed to
> intel_context_create_request()\n");
> + goto end;
> + }
> + is_skip_req_on_err = true;
> +
> + err = intel_gt_buffer_pool_mark_active(pool, rq);
> + if (err) {
> + drm_err(>drm, "Failed to
> intel_engine_pool_mark_active()\n");
> + goto end;
> + }
> +
> + i915_vma_lock(batch);
> +
Re: [Intel-gfx] [RFC-v1 08/16] drm/i915/pxp: Create the arbitrary session after boot
Quoting Huang, Sean Z (2020-12-07 02:21:26)
> Create the arbitrary session, with the fixed session id 0xf, after
> system boot, for the case that application allocates the protected
> buffer without establishing any protection session. Because the
> hardware requires at least one alive session for protected buffer
> creation. This arbitrary session needs to be re-created after
> teardown or power event because hardware encryption key won't be
> valid after such cases.
>
> Signed-off-by: Huang, Sean Z
Creating the arbitary (default) session only utilizes a minimal amount
of the session management related code introduced by this and previous
patches.
All of that dead code needs to be eliminated first, then we need to look
at what level of complexity can be eliminated from the patches.
If you can address the review comments from the earlier patch and
re-order the series according to the given guidance, that'll make the
review much more efficient going forward when the code is only added
when it used
Regards, Joonas
> ---
> drivers/gpu/drm/i915/pxp/intel_pxp.c | 47 ++-
> drivers/gpu/drm/i915/pxp/intel_pxp.h | 7 +
> drivers/gpu/drm/i915/pxp/intel_pxp_sm.c | 165 +++
> drivers/gpu/drm/i915/pxp/intel_pxp_sm.h | 8 ++
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 34 +
> drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 11 ++
> 6 files changed, 271 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> index 332d9baff29f..10f4b1de07c4 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -9,6 +9,43 @@
> #include "intel_pxp_sm.h"
> #include "intel_pxp_tee.h"
>
> +int intel_pxp_create_arb_session(struct drm_i915_private *i915)
> +{
> + struct pxp_tag pxptag;
> + int ret;
> +
> + lockdep_assert_held(>pxp.ctx->ctx_mutex);
> +
> + if (i915->pxp.ctx->flag_display_hm_surface_keys) {
> + drm_err(>drm, "%s: arb session is alive so skipping the
> creation\n",
> + __func__);
> + return 0;
> + }
> +
> + ret = intel_pxp_sm_reserve_arb_session(i915, );
> + if (ret) {
> + drm_err(>drm, "Failed to reserve session\n");
> + goto end;
> + }
> +
> + ret = intel_pxp_tee_cmd_create_arb_session(i915);
> + if (ret) {
> + drm_err(>drm, "Failed to send tee cmd for arb session
> creation\n");
> + goto end;
> + }
> +
> + ret = pxp_sm_mark_protected_session_in_play(i915, ARB_SESSION_TYPE,
> pxptag.session_id);
> + if (ret) {
> + drm_err(>drm, "Failed to mark session status in
> play\n");
> + goto end;
> + }
> +
> + i915->pxp.ctx->flag_display_hm_surface_keys = true;
> +
> +end:
> + return ret;
> +}
> +
> static void intel_pxp_write_irq_mask_reg(struct drm_i915_private *i915, u32
> mask)
> {
> /* crypto mask is in bit31-16 (Engine1 Interrupt Mask) */
> @@ -47,9 +84,17 @@ static int
> intel_pxp_global_terminate_complete_callback(struct drm_i915_private
>
> mutex_lock(>pxp.ctx->ctx_mutex);
>
> - if (i915->pxp.ctx->global_state_attacked)
> + if (i915->pxp.ctx->global_state_attacked) {
> i915->pxp.ctx->global_state_attacked = false;
>
> + /* Re-create the arb session after teardown handle complete */
> + ret = intel_pxp_create_arb_session(i915);
> + if (ret) {
> + drm_err(>drm, "Failed to create arb session\n");
> + goto end;
> + }
> + }
> +end:
> mutex_unlock(>pxp.ctx->ctx_mutex);
>
> return ret;
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> index 308d8d312a6d..e5f6e2b1bdfd 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -41,6 +41,8 @@ struct intel_gt;
> struct drm_i915_private;
>
> #ifdef CONFIG_DRM_I915_PXP
> +int intel_pxp_create_arb_session(struct drm_i915_private *i915);
> +
> void intel_pxp_irq_handler(struct intel_gt *gt, u16 iir);
> int i915_pxp_teardown_required_callback(struct drm_i915_private *i915);
> int i915_pxp_global_terminate_complete_callback(struct drm_i915_private
> *i915);
> @@ -48,6 +50,11 @@ int i915_pxp_global_terminate_complete_callback(struct
> drm_i915_private *i915);
> int intel_pxp_init(struct drm_i915_private *i915);
> void intel_pxp_uninit(struct drm_i915_private *i915);
> #else
> +static inline int intel_pxp_create_arb_session(struct drm_i915_private *i915)
> +{
> + return 0;
> +};
> +
> static inline void intel_pxp_irq_handler(struct intel_gt *gt, u16 iir)
> {
> }
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
> index 38c8b6d08b61..056f65fbaf4e 100644
> ---
Re: [Intel-gfx] [RFC-v1 07/16] drm/i915/pxp: Implement funcs to create the TEE channel
Quoting Huang, Sean Z (2020-12-07 02:21:25) > Currently ring3 driver sends the TEE commands directly to TEE, but > later, as our design, we would like to make ring3 sending the TEE > commands via the ring0 PXP ioctl action instead of TEE ioctl, so > we can centralize those protection operations at ring0 PXP. Kernel vs. userspace nomenclature to be used. The description feels incorrect given no IOCTL will be exposed. This is missing an explanation as to why it would be needed for singleton session, so I think this patch should not be included in the series. Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC-v1 06/16] drm/i915/pxp: Implement funcs to get/set PXP tag
Quoting Huang, Sean Z (2020-12-07 02:21:24)
> Implement the functions to get/set the PXP tag, which is 32-bit
> bitwise value containing the hardware session info, such as its
> session id, protection mode or whether it's enabled.
>
> Signed-off-by: Huang, Sean Z
By my understanding, this patch should not be needed at all for
singleton session? So I'm mostly skipping review here.
> -/**
> - * check_if_protected_type0_sessions_are_attacked - To check if type0 active
> sessions are attacked.
> - * @i915: i915 device handle.
> - *
> - * Return: true if HW shows protected sessions are attacked, false otherwise.
> - */
> -static bool check_if_protected_type0_sessions_are_attacked(struct
> drm_i915_private *i915)
> -{
> - i915_reg_t kcr_status_reg = KCR_STATUS_1;
> - u32 reg_value = 0;
> - u32 mask = 0x8000;
> - int ret;
> -
> - if (!i915)
> - return false;
> -
> - if (i915->pxp.ctx->global_state_attacked)
> - return true;
> -
> - ret = pxp_sm_reg_read(i915, kcr_status_reg.reg, _value);
> - if (ret) {
> - drm_err(>drm, "Failed to pxp_sm_reg_read\n");
> - goto end;
> - }
> -
> - if (reg_value & mask)
> - return true;
> -end:
> - return false;
> -}
Removal of code added previously in the series?
> int pxp_sm_set_kcr_init_reg(struct drm_i915_private *i915)
> {
> int ret;
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
> b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
> index 222a879be96d..b5012948f971 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
> @@ -20,6 +20,9 @@
> #define GEN12_KCR_TSIP_LOW _MMIO(0x32264) /* KCR type1 session in play
> 0-31 */
> #define GEN12_KCR_TSIP_HIGH _MMIO(0x32268) /* KCR type1 session in play
> 32-63 */
>
> +#define SESSION_TYPE_MASK BIT(7)
> +#define SESSION_ID_MASK (BIT(7) - 1)
> +
> enum pxp_session_types {
> SESSION_TYPE_TYPE0 = 0,
> SESSION_TYPE_TYPE1 = 1,
> @@ -36,6 +39,21 @@ enum pxp_protection_modes {
> PROTECTION_MODE_ALL
> };
>
> +struct pxp_tag {
> + union {
> + u32 value;
> + struct {
> + u32 session_id : 8;
> + u32 instance_id : 8;
> + u32 enable : 1;
> + u32 hm : 1;
> + u32 reserved_1 : 1;
> + u32 sm : 1;
> + u32 reserved_2 : 12;
> + };
It is not obvious if this is a software-only field. If it's software
only, we should just make these into normal variables. If it's hardware
related, it should be documented as a bitfield, like other hardware
writes. We avoid using this construct in i915.
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC-v1 05/16] drm/i915/pxp: Read register to check hardware session state
Quoting Huang, Sean Z (2020-12-07 02:21:23)
> Implement the functions to check the hardware protected session
> state via reading the hardware register session in play.
>
> Signed-off-by: Huang, Sean Z
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -12,6 +12,9 @@
> #define PXP_IRQ_VECTOR_DISPLAY_APP_TERM_PER_FW_REQ BIT(2)
> #define PXP_IRQ_VECTOR_PXP_DISP_STATE_RESET_COMPLETE BIT(3)
>
> +#define pxp_session_list(i915, session_type) (((session_type) ==
> SESSION_TYPE_TYPE0) ? \
> + &(i915)->pxp.ctx->active_pxp_type0_sessions :
> &(i915)->pxp.ctx->active_pxp_type1_sessions)
Definitely should be inline function with proper scope, and not taking
i915 directly. But we should only ever need a single session, so the
lists should not be needed.
> +
> #define MAX_TYPE0_SESSIONS 16
> #define MAX_TYPE1_SESSIONS 6
>
> diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
> b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
> index a2c9c71d2372..6413f401d939 100644
> --- a/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
> @@ -10,6 +10,21 @@
> #include "intel_pxp_sm.h"
> #include "intel_pxp_context.h"
>
> +static int pxp_sm_reg_read(struct drm_i915_private *i915, u32 offset, u32
> *regval)
See previous patch, has all the same problems as the write func.
> @@ -26,6 +41,168 @@ static int pxp_reg_write(struct drm_i915_private *i915,
> u32 offset, u32 regval)
> return 0;
> }
>
> +/**
> + * is_sw_session_active - Check if the given sw session id is active.
> + * @i915: i915 device handle.
> + * @session_type: Specified session type
> + * @session_index: Numeric session identifier.
> + * @is_in_play: Set false to return true if the specified session is active.
> + * Set true to also check if the session is active and in_play.
> + * @protection_mode: get the protection mode of specified session.
> + *
> + * The caller needs to use ctx_mutex lock to protect the session_list
> + * inside this function.
> + *
> + * Return : true if session with the same identifier is active (and in_play).
> + */
> +static bool is_sw_session_active(struct drm_i915_private *i915, int
> session_type,
> +int session_index, bool is_in_play, int
> *protection_mode)
By my understanding we only have a singleton session. Would expect
the same protection mode always, so this should be greatly simplified.
> +{
> + struct pxp_protected_session *current_session;
> +
> + lockdep_assert_held(>pxp.ctx->ctx_mutex);
> +
> + list_for_each_entry(current_session, pxp_session_list(i915,
> session_type), session_list) {
> + if (current_session->session_index == session_index) {
This is an extremely slow way of finding a session. But as we only
expect a single session, I think this whole function becomes
unnecessary.
> + if (protection_mode)
> + *protection_mode =
> current_session->protection_mode;
> +
> + if (is_in_play &&
> !current_session->session_is_in_play)
> + return false;
> +
> + return true;
> + }
> + }
> +
> + /* session id not found. return false */
> + return false;
> +}
> +
> +static bool is_hw_type0_session_in_play(struct drm_i915_private *i915, int
> session_index)
> +{
> + u32 regval_sip = 0;
> + u32 reg_session_id_mask;
> + bool hw_session_is_in_play = false;
> + int ret = 0;
> +
> + if (!i915 || session_index < 0 || session_index >= MAX_TYPE0_SESSIONS)
> + goto end;
> +
> + ret = pxp_sm_reg_read(i915, GEN12_KCR_SIP.reg, _sip);
As mentioned in previous patch, we should not wrap the MMIO read macros,
but hold the wakeref at higher level.
> + if (ret) {
> + drm_err(>drm, "Failed to read()\n");
I don't think these will be worthy ERROR message. We should collate
multiple error checks and at a top level emit an error message if
something failed.
> + goto end;
> + }
> +
> + reg_session_id_mask = (1 << session_index);
> + hw_session_is_in_play = (bool)(regval_sip & reg_session_id_mask);
All this should follow existing programming conventions and use existing
macros, so this function should not be much more than:
kcr_sip = intel_uncore_read(uncore, GEN12_KCR_SIP);
return kcr_sip & BIT(index);
> +end:
> + return hw_session_is_in_play;
> +}
> +
> +static bool is_hw_type1_session_in_play(struct drm_i915_private *i915, int
> session_index)
> +{
> + int ret = 0;
> + u32 regval_tsip_low = 0;
> + u32 regval_tsip_high = 0;
> + u64 reg_session_id_mask;
> + u64 regval_tsip;
> + bool hw_session_is_in_play = false;
> +
> + if (!i915 || session_index < 0 || session_index >= MAX_TYPE1_SESSIONS)
> + goto end;
> +
> + ret = pxp_sm_reg_read(i915, GEN12_KCR_TSIP_LOW.reg,
Re: [Intel-gfx] [RFC-v1 04/16] drm/i915/pxp: set KCR reg init during the boot time
Quoting Huang, Sean Z (2020-12-07 02:21:22)
> Set the KCR init during the boot time, which is required by
> hardware, to allow us doing further protection operation such
> as sending commands to GPU or TEE
>
> Signed-off-by: Huang, Sean Z
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -6,6 +6,7 @@
> #include "i915_drv.h"
> #include "intel_pxp.h"
> #include "intel_pxp_context.h"
> +#include "intel_pxp_sm.h"
>
> static void intel_pxp_write_irq_mask_reg(struct drm_i915_private *i915, u32
> mask)
> {
> @@ -77,6 +78,8 @@ static void intel_pxp_irq_work(struct work_struct *work)
>
> int intel_pxp_init(struct drm_i915_private *i915)
> {
> + int ret;
> +
> if (!i915)
> return -EINVAL;
>
> @@ -92,13 +95,19 @@ int intel_pxp_init(struct drm_i915_private *i915)
> return -EFAULT;
> }
>
> + ret = pxp_sm_set_kcr_init_reg(i915);
I think this should just be intel_pxp_sm_init() and then do whatever it
needs to initialize. Also as we plan on having only a single session, I
don't see why would we want a separate session management file/header.
So I would be inclined to just inline the KCR_INIT macro write here. If
this is moved to appropriate spot during intel_gt initialization, we
should have the hardware wakeref, so would be just a single
intel_uncore_write.
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.c
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#include "gt/intel_context.h"
> +#include "gt/intel_engine_pm.h"
> +
> +#include "intel_pxp.h"
> +#include "intel_pxp_sm.h"
> +#include "intel_pxp_context.h"
> +
> +static int pxp_reg_write(struct drm_i915_private *i915, u32 offset, u32
> regval)
> +{
> + intel_wakeref_t wakeref;
> +
> + if (!i915)
> + return -EINVAL;
Again, GEM_BUG_ON(!i915) should suffice.
> +
> + with_intel_runtime_pm(>runtime_pm, wakeref) {
> + i915_reg_t reg_offset = {offset};
See below, here we convert from u32 to i915_reg_t.
> +
> + intel_uncore_write(>uncore, reg_offset, regval);
> + }
I don't think we want to grab the wakeref at a low level reg_write
function but at a higher levels to clearly distinct functions that need
to access hardware and those who don't.
> + return 0;
> +}
> +
> +int pxp_sm_set_kcr_init_reg(struct drm_i915_private *i915)
> +{
> + int ret;
> +
> + ret = pxp_reg_write(i915, KCR_INIT.reg,
> KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
See above related to offset. Here we convert to u32. We shouldn't escape
the protection offered by _MMIO macro.
Based on the register name this feels like it should somehow be related
to display init?
> + if (ret)
> + drm_err(>drm, "Failed to write()\n");
There is an error message in the upper level function, so one of these
becomes redundant.
After this has been moved to intel_gt init, the hardware wakeref is
definitely held
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_sm.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#ifndef __INTEL_PXP_SM_H__
> +#define __INTEL_PXP_SM_H__
> +
> +#include "i915_drv.h"
> +#include "i915_reg.h"
> +
> +/* KCR register definitions */
> +#define KCR_INIT_MMIO(0x320f0)
> +#define KCR_INIT_MASK_SHIFT (16)
> +/* Setting KCR Init bit is required after system boot */
> +#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES (BIT(14) | (BIT(14) <<
> KCR_INIT_MASK_SHIFT))
If this is only used from single place, it should go to the .c file
that uses it.
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Fixing the error handling of shmem_pin_map
In that case can we merge the series http://intel-gfx-pw.fi.intel.com/series/6611/ ? If so please provide your R-b/Ack > -Original Message- > From: Chris Wilson > Sent: Monday, December 7, 2020 4:17 PM > To: C, Ramalingam ; intel-gfx g...@lists.freedesktop.org> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/gt: Fixing the error handling of > shmem_pin_map > > Quoting Ramalingam C (2020-12-07 10:28:12) > > Since i was size_t, at error handling if i is 0, then --i >= 0. > > Making i as int. > > The problem here is that size_t is 64b, but int 32b. > There's a patch by Colin King that does the trick. > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC-v1 03/16] drm/i915/pxp: Add PXP context for logical hardware states.
Quoting Huang, Sean Z (2020-12-07 02:21:21)
> Add PXP context which represents combined view
> of driver and logical HW states.
>
> Signed-off-by: Huang, Sean Z
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -5,6 +5,7 @@
>
> #include "i915_drv.h"
> #include "intel_pxp.h"
> +#include "intel_pxp_context.h"
>
> static void intel_pxp_write_irq_mask_reg(struct drm_i915_private *i915, u32
> mask)
> {
> @@ -28,12 +29,28 @@ static void intel_pxp_mask_irq(struct intel_gt *gt, u32
> mask)
>
> static int intel_pxp_teardown_required_callback(struct drm_i915_private
> *i915)
> {
> + mutex_lock(>pxp.ctx->ctx_mutex);
> +
> + i915->pxp.ctx->global_state_attacked = true;
> + i915->pxp.ctx->flag_display_hm_surface_keys = false;
> +
> + mutex_unlock(>pxp.ctx->ctx_mutex);
This should really have its own function intel_pxp_context_foobar()
that is called from this point. Also, as you see "ctx_mutex" is tautology
and "mutex" is enough when it's member of "ctx".
We seem to have two separate interrupts at the top level handler. Either
we should handle the interrupts separately or just have a single variable
"teardown_requested" that is flagged from here.
The effects of setting these variables can't be reviewed as not even the
initialization sequence has been added by the series, so this should
definitely be much more towards the end of the series.
> +
> return 0;
> }
>
> static int intel_pxp_global_terminate_complete_callback(struct
> drm_i915_private *i915)
> {
> - return 0;
> + int ret = 0;
> +
> + mutex_lock(>pxp.ctx->ctx_mutex);
> +
> + if (i915->pxp.ctx->global_state_attacked)
> + i915->pxp.ctx->global_state_attacked = false;
The if() check is pointless. Again, we should not directly poke such
deeply, but wrap it in a function.
> +
> + mutex_unlock(>pxp.ctx->ctx_mutex);
> +
> + return ret;
> }
>
> static void intel_pxp_irq_work(struct work_struct *work)
> @@ -69,6 +86,12 @@ int intel_pxp_init(struct drm_i915_private *i915)
>
> drm_info(>drm, "i915 PXP is inited with i915=[%p]\n", i915);
>
> + i915->pxp.ctx = intel_pxp_create_ctx(i915);
> + if (!i915->pxp.ctx) {
> + drm_err(>drm, "Failed to create pxp ctx\n");
> + return -EFAULT;
I think this should be -ENOMEM.
> + }
As we only intend to support a single context, we should avoid a pointer
+ alloc here and just use intel_pxp_context_init(>ctx)
> @@ -80,6 +103,10 @@ int intel_pxp_init(struct drm_i915_private *i915)
>
> void intel_pxp_uninit(struct drm_i915_private *i915)
> {
> + if (!i915 || INTEL_GEN(i915) < 12)
> + return;
> +
> + intel_pxp_destroy_ctx(i915);
intel_pxp_context_fini(>ctx);
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -12,6 +12,9 @@
> #define PXP_IRQ_VECTOR_DISPLAY_APP_TERM_PER_FW_REQ BIT(2)
> #define PXP_IRQ_VECTOR_PXP_DISP_STATE_RESET_COMPLETE BIT(3)
>
> +#define MAX_TYPE0_SESSIONS 16
> +#define MAX_TYPE1_SESSIONS 6
These should be prefixed with PXP_ also, we should not need these at all
if we only intend to support single-session.
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_context.c
> @@ -0,0 +1,45 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#include "intel_pxp_context.h"
> +
> +/**
> + * intel_pxp_create_ctx - To create a new pxp context.
> + * @i915: i915 device handle.
> + *
> + * Return: pointer to new_ctx, NULL for failure
> + */
> +struct pxp_context *intel_pxp_create_ctx(struct drm_i915_private *i915)
> +{
> + struct pxp_context *new_ctx = NULL;
Adding "new_" is tautology here. Also, we try to separate the allocation
and init to separate functions so that we can embed, like I suggested
above to embed the singleton context to intel_pxp as member, not
pointer.
> +
> + new_ctx = kzalloc(sizeof(*new_ctx), GFP_KERNEL);
> + if (!new_ctx)
> + return NULL;
> +
> + get_random_bytes(_ctx->ctx_id, sizeof(new_ctx->ctx_id));
"ctx_id" is again repeating as it's member of "ctx", so "id" should be
fine for member name.
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_context.h
> @@ -0,0 +1,44 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright(c) 2020, Intel Corporation. All rights reserved.
> + */
> +
> +#ifndef __INTEL_PXP_CONTEXT_H__
> +#define __INTEL_PXP_CONTEXT_H__
> +
> +#include
> +#include "i915_drv.h"
> +#include "pxp/intel_pxp.h"
> +
> +/* struct pxp_context - Represents combined view of driver and logical HW
> states. */
> +struct pxp_context {
> + /** @ctx_mutex: mutex to protect the pxp context */
> + struct mutex ctx_mutex;
> +
> + struct list_head active_pxp_type0_sessions;
> + struct list_head active_pxp_type1_sessions;
We shouldn't need any session tracking as we only have single session.
> + struct list_head user_ctx_list;
> +
> + u32
Re: [Intel-gfx] [PATCH] drm/i915/gt: Fixing the error handling of shmem_pin_map
Quoting Ramalingam C (2020-12-07 10:28:12) > Since i was size_t, at error handling if i is 0, then --i >= 0. > Making i as int. The problem here is that size_t is 64b, but int 32b. There's a patch by Colin King that does the trick. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Fixing the error handling of shmem_pin_map
Since i was size_t, at error handling if i is 0, then --i >= 0.
Making i as int.
Signed-off-by: Ramalingam C
cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/shmem_utils.c
b/drivers/gpu/drm/i915/gt/shmem_utils.c
index 463af675fadd..7de5bd15265c 100644
--- a/drivers/gpu/drm/i915/gt/shmem_utils.c
+++ b/drivers/gpu/drm/i915/gt/shmem_utils.c
@@ -52,8 +52,9 @@ struct file *shmem_create_from_object(struct
drm_i915_gem_object *obj)
void *shmem_pin_map(struct file *file)
{
struct page **pages;
- size_t n_pages, i;
+ size_t n_pages;
void *vaddr;
+ int i;
n_pages = file->f_mapping->host->i_size >> PAGE_SHIFT;
pages = kvmalloc_array(n_pages, sizeof(*pages), GFP_KERNEL);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC-v1 02/16] drm/i915/pxp: Enable PXP irq worker and callback stub
Quoting Huang, Sean Z (2020-12-07 02:21:20)
> Create the irq worker that serves as callback handler, those
> callback stubs should be called while the hardware key teardown
> occurs.
>
> Signed-off-by: Huang, Sean Z
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> @@ -13,6 +13,7 @@
> #include "intel_gt_irq.h"
> #include "intel_uncore.h"
> #include "intel_rps.h"
> +#include "pxp/intel_pxp.h"
>
> static void guc_irq_handler(struct intel_guc *guc, u16 iir)
> {
> @@ -106,6 +107,9 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8
> instance,
> if (instance == OTHER_GTPM_INSTANCE)
> return gen11_rps_irq_handler(>rps, iir);
>
> + if (instance == OTHER_KCR_INSTANCE)
> + return intel_pxp_irq_handler(gt, iir);
We should take >pxp as the first parameter and keep a tight scope.
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -6,6 +6,58 @@
> #include "i915_drv.h"
> #include "intel_pxp.h"
>
> +static void intel_pxp_write_irq_mask_reg(struct drm_i915_private *i915, u32
> mask)
Again, we should be taking intel_pxp as parameter to tighten the scope.
> +{
> + /* crypto mask is in bit31-16 (Engine1 Interrupt Mask) */
> + intel_uncore_write(>uncore, GEN11_CRYPTO_RSVD_INTR_MASK, mask
> << 16);
Instead of writing to register that is indicated to be "reserved"
(RSVD), we should properly document the register in i915_reg.h and the
comment should not be needed.
> +static void intel_pxp_irq_work(struct work_struct *work)
> +{
> + struct intel_pxp *pxp_ptr = container_of(work, typeof(*pxp_ptr),
> irq_work);
_ptr is a tautology, we can already see it's apointer.
> + struct drm_i915_private *i915 = container_of(pxp_ptr, typeof(*i915),
> pxp);
We should go from intel_pxp to intel_gt to i915 here, once the struct
intel_pxp member is moved inside intel_gt
> + u32 events = 0;
> +
> + spin_lock_irq(>gt.irq_lock);
> + events = fetch_and_zero(_ptr->current_events);
> + spin_unlock_irq(>gt.irq_lock);
> +
> + if (events & PXP_IRQ_VECTOR_DISPLAY_PXP_STATE_TERMINATED ||
> + events & PXP_IRQ_VECTOR_DISPLAY_APP_TERM_PER_FW_REQ)
> + intel_pxp_teardown_required_callback(i915);
> +
> + if (events & PXP_IRQ_VECTOR_PXP_DISP_STATE_RESET_COMPLETE)
> + intel_pxp_global_terminate_complete_callback(i915);
The mapping between the callbacks and the hardware events are unclear.
These all seem like display related events, so we probably need a split
between the GT and display PXP code.
It's hard to review as this only adds stubs and no actual flow. I think
teardown interrupt handling should come later in the series after init
and other code has been added.
> @@ -17,9 +69,45 @@ int intel_pxp_init(struct drm_i915_private *i915)
>
> drm_info(>drm, "i915 PXP is inited with i915=[%p]\n", i915);
This INFO message is wrongly placed, either it should say "initializing"
and be at the beginning or "initialized" and be at the end. Also see
previous patch for more comments.
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> @@ -8,18 +8,54 @@
>
> #include
>
> +#define PXP_IRQ_VECTOR_DISPLAY_PXP_STATE_TERMINATED BIT(1)
> +#define PXP_IRQ_VECTOR_DISPLAY_APP_TERM_PER_FW_REQ BIT(2)
> +#define PXP_IRQ_VECTOR_PXP_DISP_STATE_RESET_COMPLETE BIT(3)
> +
> +enum pxp_sm_session_req {
> + /* Request KMD to allocate session id and move it to IN INIT */
> + PXP_SM_REQ_SESSION_ID_INIT = 0x0,
> + /* Inform KMD that UMD has completed the initialization */
> + PXP_SM_REQ_SESSION_IN_PLAY,
> + /* Request KMD to terminate the session */
> + PXP_SM_REQ_SESSION_TERMINATE
> +};
This enum here feels like a misplaced hunk. We should be adding the
enums and structs only when they are used in the patch. Reviewing the
logic and looking for dead code is much harder when structs are
introduced way earlier than they are used.
We should be adding the base structs at most and extending them as we
add more functionality as we go.
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/rkl: Remove require_force_probe protection
Hi Chris, Are below results satisfying? Thanks, Tejas > -Original Message- > From: Kattamanchi, JaswanthX > Sent: 04 December 2020 15:11 > To: Surendrakumar Upadhyay, TejaskumarX > ; Chris Wilson > ; Pandey, Hariom ; > intel-gfx@lists.freedesktop.org > Cc: Naramasetti, LaxminarayanaX > Subject: RE: [Intel-gfx] [PATCH] drm/i915/rkl: Remove require_force_probe > protection > > Hi Tejas, > > As per your request triggered resume run on RKL CI machine, the testcases > which chris mentioned were passing with this run, Please find the below logs > for your reference > > Git ID : https://gitlab.freedesktop.org/drm/intel/-/issues/2743 > > igt@gem_exec_schedule@pi-ringfull@vcs0 : https://intel-gfx- > ci.01.org/tree/drm-tip/CI_DRM_9432/re-rkl-1/igt@gem_exec_schedule@pi- > ringf...@vcs0.html > > igt@gem_exec_schedule@pi-common@vcs0 : https://intel-gfx- > ci.01.org/tree/drm-tip/CI_DRM_9432/re-rkl-1/igt@gem_exec_schedule@pi- > com...@vcs0.html > > Regards, > Jaswanth Kattamanchi > > -Original Message- > From: Surendrakumar Upadhyay, TejaskumarX > > Sent: Thursday, December 3, 2020 4:38 PM > To: Chris Wilson ; Pandey, Hariom > ; intel-gfx@lists.freedesktop.org; Kattamanchi, > JaswanthX > Cc: Naramasetti, LaxminarayanaX > Subject: RE: [Intel-gfx] [PATCH] drm/i915/rkl: Remove require_force_probe > protection > > + Jaswant > > > -Original Message- > > From: Surendrakumar Upadhyay, TejaskumarX > > Sent: 03 December 2020 09:44 > > To: Chris Wilson ; Pandey, Hariom > > ; intel-gfx@lists.freedesktop.org > > Subject: RE: [Intel-gfx] [PATCH] drm/i915/rkl: Remove > > require_force_probe protection > > > > Hi Jaswant, > > > > Can you please re-run resume run on CI as well as local setup and > > share results here? If it passes in full resume run in either of setup > > we are good go with. > > > > Thanks, > > Tejas > > > > > -Original Message- > > > From: Chris Wilson > > > Sent: 30 November 2020 20:31 > > > To: Pandey, Hariom ; Surendrakumar > > Upadhyay, > > > TejaskumarX ; intel- > > > g...@lists.freedesktop.org > > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/rkl: Remove > > > require_force_probe protection > > > > > > Quoting Surendrakumar Upadhyay, TejaskumarX (2020-11-30 14:45:14) > > > > Hi Chris, > > > > > > > > The failing test was not part of BAT run, it ran in CI resume run > > > > and failed > > > there, however on manual run the same test got passed. Please find > > > attached results. > > > > > > One pass versus a major failure is not satisfactory. > > > > > > We can not say we are happy with the hardware/driver until it is > > > reliable, and forcewake is of fundamental importance for mmio > > > access, as well as execution. > > > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC-v1 01/16] drm/i915/pxp: Introduce Intel PXP component
Quoting Huang, Sean Z (2020-12-07 02:21:19)
> PXP (Protected Xe Path) is an i915 componment, available on GEN12+,
> that helps user space to establish the hardware protected session
> and manage the status of each alive software session, as well as
> the life cycle of each session.
>
> By design PXP will expose ioctl so allow user space to create, set,
> and destroy each session. It will also provide the communication
> chanel to TEE (Trusted Execution Environment) for the protected
> hardware session creation.
Description is no more true for single-session only.
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -130,6 +130,25 @@ config DRM_I915_GVT_KVMGT
> Choose this option if you want to enable KVMGT support for
> Intel GVT-g.
>
> +config DRM_I915_PXP
> + bool "Enable Intel PXP support for Intel Gen12+ platform"
> + depends on DRM_I915
> + select INTEL_MEI_PXP
> + default n
> + help
> + This option selects INTEL_MEI_ME if it isn't already selected to
> + enabled full PXP Services on Intel platforms.
> +
> + PXP is an i915 componment, available on Gen12+, that helps user
> + space to establish the hardware protected session and manage the
> + status of each alive software session, as well as the life cycle
> + of each session.
> +
> + PXP expose ioctl so allow user space to create, set, and destroy
> + each session. It will also provide the communication chanel to
> + TEE (Trusted Execution Environment) for the protected hardware
> + session creation.
Same here, needs updating.
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -105,6 +105,8 @@
>
> #include "intel_region_lmem.h"
>
> +#include "pxp/intel_pxp.h"
Repeating the same comment as on previous review, avoid including
anything in i915_drv.h and only include in the relevant files that
require to touch the internals of the structs.
> +
> /* General customization:
> */
>
> @@ -1215,6 +1217,8 @@ struct drm_i915_private {
> /* Mutex to protect the above hdcp component related values. */
> struct mutex hdcp_comp_mutex;
>
> + struct intel_pxp pxp;
I think this should instead go as part of intel_gt, not here.
> +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2020 Intel Corporation.
> + */
> +
> +#include "i915_drv.h"
> +#include "intel_pxp.h"
> +
> +int intel_pxp_init(struct drm_i915_private *i915)
We should aim to only take struct intel_pxp as parameter for intel_pxp_*
functions.
> +{
> + if (!i915)
> + return -EINVAL;
This would be either a major kernel programmer error or the memory would
be seriously corrupt. No point leaving such checks to production code,
so GEM_BUG_ON(!i915) would be enough to run the checks in CI and debug
builds.
> + /* PXP only available for GEN12+ */
> + if (INTEL_GEN(i915) < 12)
> + return 0;
I think -ENODEV would be more appropriate return value. Also, we should
look into returning this error value from inside the actual init code.
We want the user to be able to differentiate between kernel does not
support and hardware does not support status.
> + drm_info(>drm, "i915 PXP is inited with i915=[%p]\n", i915);
We shouldn't be printing the pointer values, especially not in INFO
level messages. INFO level messages should be useful for the end-user to
read. This is not very useful, we should instead consider something
along the lines of:
"Protected Xe Path (PXP) protected content support initialized"
Also, we have not really initialized anything so it's really premature
to print anything in this patch.
> +
> + return 0;
> +}
> +
> +void intel_pxp_uninit(struct drm_i915_private *i915)
Same here, we really want to tighten the scope to intel_pxp and call
this from intel_gt_fini(), so signature should look like:
void intel_pxp_fini(struct intel_pxp *pxp)
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display/dp: Compute the correct slice count for VDSC on DP
On 12/5/2020 2:28 AM, Manasi Navare wrote:
This patch fixes the slice count computation algorithm
for calculating the slice count based on Peak pixel rate
and the max slice width allowed on the DSC engines.
We need to ensure slice count > min slice count req
as per DP spec based on peak pixel rate and that it is
greater than min slice count based on the max slice width
advertised by DPCD. So use max of these two.
In the prev patch we were using min of these 2 causing it
to violate the max slice width limitation causing a blank
screen on 8K@60.
Fixes: d9218c8f6cf4 ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count
for DSC")
Cc: Ankit Nautiyal
Cc: Jani Nikula
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2d4d5e95af84..cb5e42c3ecd5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -615,7 +615,7 @@ static u8 intel_dp_dsc_get_slice_count(struct intel_dp
*intel_dp,
return 0;
}
/* Also take into account max slice width */
- min_slice_count = min_t(u8, min_slice_count,
+ min_slice_count = max_t(u8, min_slice_count,
DIV_ROUND_UP(mode_hdisplay,
max_slice_width));
Change looks good to me.
'min_slice_count' is essentially the least no. of slices that would be
sufficient. So max of the two values would be correct.
Also tested with this change on an 8k panel, we are able get 8 DSC
slices with this change, which is correct for 8k@60 resolution.
Reviewed-by: Ankit Nautiyal
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915/display: Protect pipe_update against dc3co exit
On 2020-12-04 at 17:51:34 +0200, Ville Syrjälä wrote:
> On Fri, Dec 04, 2020 at 01:40:03PM +0530, Anshuman Gupta wrote:
> > On 2020-11-30 at 17:28:32 +0200, Imre Deak wrote:
> > > On Mon, Nov 30, 2020 at 02:46:46PM +0530, Anshuman Gupta wrote:
> > > > At usual case DC3CO exit happen automatically by DMC f/w whenever
> > > > PSR2 clears idle. This happens smoothly by DMC f/w to work with flips.
> > > > But there are certain scenario where DC3CO Disallowed by driver
> > > > asynchronous with flips. In such scenario display engine could
> > > > be already in DC3CO state and driver has disallowed it,
> > > > It initiates DC3CO exit sequence in DMC f/w which requires a
> > > > dc3co exit delay of 200us in driver.
> > > > It requires to protect intel_pipe_update_{update_end} with
> > > > dc3co exit delay.
> > > >
> > > > Cc: Imre Deak
> > > > Cc:
> > > > Signed-off-by: Anshuman Gupta
> > >
> > > To make sure that it doesn't hide the root cause (or affects unrelated
> > > platforms), I'd only add locking around DC3co changes with a new lock,
> > > using lock/unlock helpers in intel_display_power.c called from
> > > intel_pipe_update_start/end.
> > >
> > > Also please submit this patch separately, w/o the optimization in patch
> > > 1/2, so we know that this change fixes the problem.
> > This patch doesn't seems to fix the issue.
> > Looks like there is some other set of display register updates before
> > completing the dc3co exit delay beyond intel_pipe_update_start/end causing
> > this issue.
>
> Not really sure I understand the DC3CO issue here, nor how grabbing a
> mutex across the update could help.
Thanks Ville for providing your input here, the display glitches is fixed by
https://patchwork.freedesktop.org/patch/405585/?series=84394=2 patch in case
of brightness being updated simultaneously with flips, so it was our wild guess
that if intel_pipe_update_start triggers before completing DC3CO exit delay in
tgl_disable_dc3co could cause the display glitches but that was not true.
>
> But anyways, maybe we should just:
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 2e2dd746921f..96276f0feddc 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16268,8 +16268,7 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
>
> drm_atomic_helper_wait_for_dependencies(>base);
>
> - if (state->modeset)
> - wakeref = intel_display_power_get(dev_priv,
> POWER_DOMAIN_MODESET);
> + wakeref = intel_display_power_get(dev_priv, POWER_DOMAIN_MODESET);
Certainly this should fix the issue. I will try this out but i feel this
could cause heavy lock contention around power_domains->lock in case
brightness being updated rapidly as the scenario of this issue.
We would also need
https://patchwork.freedesktop.org/patch/405585/?series=84394=2 patch as
well ?
Thanks,
Anshuman Gupta.
>
> for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> @@ -16415,8 +16414,8 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
>* the culprit.
>*/
> intel_uncore_arm_unclaimed_mmio_detection(_priv->uncore);
> - intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET,
> wakeref);
> }
> + intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET, wakeref);
> intel_runtime_pm_put(_priv->runtime_pm, state->wakeref);
>
> /*
>
> To get the DMC out of equation entirely for all plane updates?
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
