Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel tree
+ Dave as FYI
Quoting Daniel Vetter (2021-08-10 09:27:25)
> On Mon, Aug 09, 2021 at 09:19:39AM -0700, Matt Roper wrote:
> > On Mon, Aug 09, 2021 at 04:05:59PM +0200, Daniel Vetter wrote:
> > > On Fri, Aug 06, 2021 at 09:36:56AM +0300, Joonas Lahtinen wrote:
> > > > Hi Matt,
> > > >
> > > > Always use the dim tooling when applying patches, it will do the right
> > > > thing with regards to adding the S-o-b.
> > >
> > > fd.o server rejects any pushes that haven't been done by dim, so how did
> > > this get through?
> >
> > I definitely used dim for all of these patches, but I'm not sure how I
> > lost my s-o-b on this one. Maybe when I edited the commit message after
> > 'dim extract-tags' I accidentally deleted an extra line when I removed
> > the extract-tags marker? It's the only patch where the line is missing,
> > so it's almost certainly human error on my part rather than something
> > dim did wrong.
>
> Yeah that's an expected failure model, and dim is supposed to catch that
> by rechecking for sobs when you push. See dim_push_branch ->
> checkpatch_commit_push_range in dim. So you can hand-edit stuff however
> you want, dim /should/ catch it when pushing. That it didn't is kinda
> confusing and I'd like to know why that slipped through.
>
> > > Matt, can you pls figure out and type up the patch to
> > > plug that hole?
> >
> > Are you referring to a patch for dim here? The i915 patch has already
> > landed, so we can't change its commit message now.
>
> Yeah dim, not drm-intel, that can't be fixed anymore because it's all
> baked in.
> -Daniel
>
> >
> >
> > Matt
> >
> > >
> > > Thanks, Daniel
> > >
> > > >
> > > > Regards, Joonas
> > > >
> > > > Quoting Stephen Rothwell (2021-07-15 07:18:54)
> > > > > Hi all,
> > > > >
> > > > > Commit
> > > > >
> > > > > db47fe727e1f ("drm/i915/step:
> > > > > s/_revid_tbl/_revids")
> > > > >
> > > > > is missing a Signed-off-by from its committer.
> > > > >
> > > > > --
> > > > > Cheers,
> > > > > Stephen Rothwell
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> >
> > --
> > Matt Roper
> > Graphics Software Engineer
> > VTT-OSGC Platform Enablement
> > Intel Corporation
> > (916) 356-2795
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
[Intel-gfx] [PATCH v3] drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg
Till DISPLAY12 the PIPE_MISC bits 5-7 are used to set the
Dithering BPC, with valid values of 6, 8, 10 BPC.
For ADLP+ these bits are used to set the PORT OUTPUT BPC, with valid
values of: 6, 8, 10, 12 BPC, and need to be programmed whether
dithering is enabled or not.
This patch:
-corrects the bits 5-7 for PIPE MISC register for 12 BPC.
-renames the bits and mask to have generic names for these bits for
dithering bpc and port output bpc.
v3: Added a note for MIPI DSI which uses the PIPE_MISC for readout
for pipe_bpp. (Uma Shankar)
v2: Added 'display' to the subject and fixes tag. (Uma Shankar)
Fixes: 756f85cffef2 ("drm/i915/bdw: Broadwell has PIPEMISC")
Cc: Paulo Zanoni (v1)
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: # v3.13+
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_display.c | 34 ++--
drivers/gpu/drm/i915/i915_reg.h | 16 ++---
2 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index b25c596f6f7e..a257e5dc381c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5838,16 +5838,18 @@ static void bdw_set_pipemisc(const struct
intel_crtc_state *crtc_state)
switch (crtc_state->pipe_bpp) {
case 18:
- val |= PIPEMISC_DITHER_6_BPC;
+ val |= PIPEMISC_6_BPC;
break;
case 24:
- val |= PIPEMISC_DITHER_8_BPC;
+ val |= PIPEMISC_8_BPC;
break;
case 30:
- val |= PIPEMISC_DITHER_10_BPC;
+ val |= PIPEMISC_10_BPC;
break;
case 36:
- val |= PIPEMISC_DITHER_12_BPC;
+ /* Port output 12BPC defined for ADLP+ */
+ if (DISPLAY_VER(dev_priv) > 12)
+ val |= PIPEMISC_12_BPC_ADLP;
break;
default:
MISSING_CASE(crtc_state->pipe_bpp);
@@ -5900,15 +5902,27 @@ int bdw_get_pipemisc_bpp(struct intel_crtc *crtc)
tmp = intel_de_read(dev_priv, PIPEMISC(crtc->pipe));
- switch (tmp & PIPEMISC_DITHER_BPC_MASK) {
- case PIPEMISC_DITHER_6_BPC:
+ switch (tmp & PIPEMISC_BPC_MASK) {
+ case PIPEMISC_6_BPC:
return 18;
- case PIPEMISC_DITHER_8_BPC:
+ case PIPEMISC_8_BPC:
return 24;
- case PIPEMISC_DITHER_10_BPC:
+ case PIPEMISC_10_BPC:
return 30;
- case PIPEMISC_DITHER_12_BPC:
- return 36;
+ /*
+* PORT OUTPUT 12 BPC defined for ADLP+.
+*
+* TODO:
+* For previous platforms with DSI interface, bits 5:7
+* are used for storing pipe_bpp irrespective of dithering.
+* Since the value of 12 BPC is not defined for these bits
+* on older platforms, need to find a workaround for 12 BPC
+* MIPI DSI HW readout.
+*/
+ case PIPEMISC_12_BPC_ADLP:
+ if (DISPLAY_VER(dev_priv) > 12)
+ return 36;
+ fallthrough;
default:
MISSING_CASE(tmp);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 167eaa87501b..664970f2bc62 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6203,11 +6203,17 @@ enum {
#define PIPEMISC_HDR_MODE_PRECISION (1 << 23) /* icl+ */
#define PIPEMISC_OUTPUT_COLORSPACE_YUV (1 << 11)
#define PIPEMISC_PIXEL_ROUNDING_TRUNCREG_BIT(8) /* tgl+ */
-#define PIPEMISC_DITHER_BPC_MASK (7 << 5)
-#define PIPEMISC_DITHER_8_BPC(0 << 5)
-#define PIPEMISC_DITHER_10_BPC (1 << 5)
-#define PIPEMISC_DITHER_6_BPC(2 << 5)
-#define PIPEMISC_DITHER_12_BPC (3 << 5)
+/*
+ * For Display < 13, Bits 5-7 of PIPE MISC represent DITHER BPC with
+ * valid values of: 6, 8, 10 BPC.
+ * ADLP+, the bits 5-7 represent PORT OUTPUT BPC with valid values of:
+ * 6, 8, 10, 12 BPC.
+ */
+#define PIPEMISC_BPC_MASK(7 << 5)
+#define PIPEMISC_8_BPC (0 << 5)
+#define PIPEMISC_10_BPC (1 << 5)
+#define PIPEMISC_6_BPC (2 << 5)
+#define PIPEMISC_12_BPC_ADLP (4 << 5) /* adlp+ */
#define PIPEMISC_DITHER_ENABLE (1 << 4)
#define PIPEMISC_DITHER_TYPE_MASK(3 << 2)
#define PIPEMISC_DITHER_TYPE_SP (0 << 2)
--
2.25.1
[Intel-gfx] missing signoff on drm-intel-gt-next pull
dim: db47fe727e1f ("drm/i915/step:
s/_revid_tbl/_revids"): committer Signed-off-by
missing.
I'm not sure how much pain it is to fix that up, but
commit db47fe727e1fc516cf60fc9ab8299605ef3c2d54
Author: Anusha Srivatsa
Commit: Matt Roper
drm/i915/step: s/_revid_tbl/_revids
Simplify the stepping info array name.
Cc: Jani Nikula
Signed-off-by: Anusha Srivatsa
Reviewed-by: Jani Nikula
Link:
https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-2-matthew.d.ro...@intel.com
It's definitely missing an S-o-b by anyone who handled the patch.
Let me know if it's insanely painful to fix that.
Dave.
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/hdcp: reuse rx_info for mst stream type1 capability check
On 2021-08-10 at 16:52:12 -0700, Juston Li wrote:
> On some MST docking stations, rx_info can only be read after
> RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
> otherwise the read will return -EIO.
>
> This behavior causes the mst stream type1 capability test to fail to
> read rx_info and determine if the topology supports type1 and fallback
> to type0.
>
> To fix this, check for type1 capability when we receive rx_info within
> the AKE flow when we read RepeaterAuth_Send_ReceiverID_List instead
> of an explicit read just for type1 capability checking.
>
> This does require moving where we set stream_types to after
> hdcp2_authenticate_sink() when we get rx_info but this occurs before we
> do hdcp2_propagate_stream_management_info.
>
> Also, legacy HDCP 2.0/2.1 are not type 1 capable either so check for
> that as well.
>
> Changes since v2:
> - Remove no longer used variables in _intel_hdcp2_enable()
LGTM.
Reviewed-by: Ramalingam C
>
> Signed-off-by: Juston Li
> ---
> .../drm/i915/display/intel_display_types.h| 2 +
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 39 ---
> drivers/gpu/drm/i915/display/intel_hdcp.c | 49 ---
> 3 files changed, 23 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index dbdfe54d0340..c8b687ff0374 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -516,6 +516,8 @@ struct intel_hdcp {
> enum transcoder cpu_transcoder;
> /* Only used for DP MST stream encryption */
> enum transcoder stream_transcoder;
> +
> + bool topology_type1_capable;
> };
>
> struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 526fd58b9b51..2d39af63ec9b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -478,23 +478,6 @@ int intel_dp_hdcp2_write_msg(struct intel_digital_port
> *dig_port,
> return size;
> }
>
> -static int
> -get_rxinfo_hdcp_1_dev_downstream(struct intel_digital_port *dig_port, bool
> *hdcp_1_x)
> -{
> - u8 rx_info[HDCP_2_2_RXINFO_LEN];
> - int ret;
> -
> - ret = drm_dp_dpcd_read(_port->dp.aux,
> -DP_HDCP_2_2_REG_RXINFO_OFFSET,
> -(void *)rx_info, HDCP_2_2_RXINFO_LEN);
> -
> - if (ret != HDCP_2_2_RXINFO_LEN)
> - return ret >= 0 ? -EIO : ret;
> -
> - *hdcp_1_x = HDCP_2_2_HDCP1_DEVICE_CONNECTED(rx_info[1]) ? true : false;
> - return 0;
> -}
> -
> static
> ssize_t get_receiver_id_list_rx_info(struct intel_digital_port *dig_port,
> u32 *dev_cnt, u8 *byte)
> {
> @@ -664,27 +647,6 @@ int intel_dp_hdcp2_capable(struct intel_digital_port
> *dig_port,
> return 0;
> }
>
> -static
> -int intel_dp_mst_streams_type1_capable(struct intel_connector *connector,
> -bool *capable)
> -{
> - struct intel_digital_port *dig_port =
> intel_attached_dig_port(connector);
> - struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> - int ret;
> - bool hdcp_1_x;
> -
> - ret = get_rxinfo_hdcp_1_dev_downstream(dig_port, _1_x);
> - if (ret) {
> - drm_dbg_kms(>drm,
> - "[%s:%d] failed to read RxInfo ret=%d\n",
> - connector->base.name, connector->base.base.id, ret);
> - return ret;
> - }
> -
> - *capable = !hdcp_1_x;
> - return 0;
> -}
> -
> static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
> .write_an_aksv = intel_dp_hdcp_write_an_aksv,
> .read_bksv = intel_dp_hdcp_read_bksv,
> @@ -833,7 +795,6 @@ static const struct intel_hdcp_shim
> intel_dp_mst_hdcp_shim = {
> .stream_2_2_encryption = intel_dp_mst_hdcp2_stream_encryption,
> .check_2_2_link = intel_dp_mst_hdcp2_check_link,
> .hdcp_2_2_capable = intel_dp_hdcp2_capable,
> - .streams_type1_capable = intel_dp_mst_streams_type1_capable,
> .protocol = HDCP_PROTOCOL_DP,
> };
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index ebc2e32aec0b..1a2a98e2c6e3 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -33,21 +33,6 @@ static int intel_conn_to_vcpi(struct intel_connector
> *connector)
> return connector->port ? connector->port->vcpi.vcpi : 0;
> }
>
> -static bool
> -intel_streams_type1_capable(struct intel_connector *connector)
> -{
> - const struct intel_hdcp_shim *shim = connector->hdcp.shim;
> - bool capable = false;
> -
> - if (!shim)
> - return capable;
> -
> - if (shim->streams_type1_capable)
> - shim->streams_type1_capable(connector, );
> -
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List
On 2021-08-10 at 16:52:11 -0700, Juston Li wrote:
> When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by itself
> once to retrieve the DEVICE_COUNT to calculate the size of the
> ReceiverID list then read a second time as a part of reading ReceiverID
> list.
>
> On some MST docking stations, RxInfo can only be read after the RxStatus
> READY bit is set otherwise the read will return -EIO. The spec states that
> the READY bit should be cleared as soon as RxInfo has been read.
>
> In this case, the first RxInfo read succeeds but after the READY bit is
> cleared, the second read fails.
>
> Fix it by reading RxInfo once and storing it before reading the rest of
> RepeaterAuth_Send_ReceiverID_List once we know the size.
>
> Modify get_receiver_id_list_size() to read and store RxInfo in the
> message buffer and also parse DEVICE_COUNT so we know the size of
> RepeaterAuth_Send_ReceiverID_List.
>
> Afterwards, retrieve the rest of the message at the offset for
> seq_num_V.
>
> Changes in v4:
> - rebase and edit commit message
>
> Changes in v3:
> - remove comment
>
> Changes in v2:
> - remove unnecessary moving of drm_i915_private from patch 1
Looks good to me
Reviewed-by: Ramalingam C
>
> Signed-off-by: Juston Li
> Acked-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 30 ++--
> include/drm/drm_dp_helper.h | 2 +-
> 2 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 1d0096654776..526fd58b9b51 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -496,11 +496,10 @@ get_rxinfo_hdcp_1_dev_downstream(struct
> intel_digital_port *dig_port, bool *hdcp
> }
>
> static
> -ssize_t get_receiver_id_list_size(struct intel_digital_port *dig_port)
> +ssize_t get_receiver_id_list_rx_info(struct intel_digital_port *dig_port,
> u32 *dev_cnt, u8 *byte)
> {
> - u8 rx_info[HDCP_2_2_RXINFO_LEN];
> - u32 dev_cnt;
> ssize_t ret;
> + u8 *rx_info = byte;
>
> ret = drm_dp_dpcd_read(_port->dp.aux,
> DP_HDCP_2_2_REG_RXINFO_OFFSET,
> @@ -508,15 +507,11 @@ ssize_t get_receiver_id_list_size(struct
> intel_digital_port *dig_port)
> if (ret != HDCP_2_2_RXINFO_LEN)
> return ret >= 0 ? -EIO : ret;
>
> - dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
> + *dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
> HDCP_2_2_DEV_COUNT_LO(rx_info[1]));
>
> - if (dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
> - dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
> -
> - ret = sizeof(struct hdcp2_rep_send_receiverid_list) -
> - HDCP_2_2_RECEIVER_IDS_MAX_LEN +
> - (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
> + if (*dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
> + *dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
>
> return ret;
> }
> @@ -534,6 +529,7 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
> *dig_port,
> const struct hdcp2_dp_msg_data *hdcp2_msg_data;
> ktime_t msg_end = ktime_set(0, 0);
> bool msg_expired;
> + u32 dev_cnt;
>
> hdcp2_msg_data = get_hdcp2_dp_msg_data(msg_id);
> if (!hdcp2_msg_data)
> @@ -546,17 +542,21 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
> *dig_port,
>
> hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
>
> + /* DP adaptation msgs has no msg_id */
> + byte++;
> +
> if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
> - ret = get_receiver_id_list_size(dig_port);
> + ret = get_receiver_id_list_rx_info(dig_port, _cnt, byte);
> if (ret < 0)
> return ret;
>
> - size = ret;
> + byte += ret;
> + size = sizeof(struct hdcp2_rep_send_receiverid_list) -
> + HDCP_2_2_RXINFO_LEN - HDCP_2_2_RECEIVER_IDS_MAX_LEN +
> + (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
> }
> - bytes_to_recv = size - 1;
>
> - /* DP adaptation msgs has no msg_id */
> - byte++;
> + bytes_to_recv = size - 1;
>
> while (bytes_to_recv) {
> len = bytes_to_recv > DP_AUX_MAX_PAYLOAD_BYTES ?
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 3f2715eb965f..7476e7c6d0be 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1413,7 +1413,7 @@ enum drm_dp_phy {
> #define DP_HDCP_2_2_LC_INIT_OFFSET DP_HDCP_2_2_REG_RN_OFFSET
> #define DP_HDCP_2_2_LC_SEND_LPRIME_OFFSETDP_HDCP_2_2_REG_LPRIME_OFFSET
> #define DP_HDCP_2_2_SKE_SEND_EKS_OFFSET
> DP_HDCP_2_2_REG_EDKEY_KS_OFFSET
> -#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
> DP_HDCP_2_2_REG_RXINFO_OFFSET
> +#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
>
Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/hdcp: update cp_irq_count_cached in intel_dp_hdcp2_read_msg()
On 2021-08-10 at 16:52:10 -0700, Juston Li wrote:
> Update cp_irq_count_cached when reading messages rather than when
> writing a message to make sure the value is up to date and not
> stale from a previously handled CP_IRQ.
>
> AKE flow doesn't always respond to a read with a ACK write msg.
> E.g. AKE_Send_Pairing_Info will "timeout" because we received
> a CP_IRQ for reading AKE_Send_H_Prime but no write occurred between that
> and reading AKE_Send_Pairing_Info so cp_irq_count_cached is stale
> causing the wait to return right away rather than waiting for a new
> CP_IRQ.
LGTM.
Reviewed-by: Ramalingam C
>
> Signed-off-by: Juston Li
> Acked-by: Anshuman Gupta
> ---
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index d697d169e8c1..1d0096654776 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -446,8 +446,6 @@ static
> int intel_dp_hdcp2_write_msg(struct intel_digital_port *dig_port,
>void *buf, size_t size)
> {
> - struct intel_dp *dp = _port->dp;
> - struct intel_hdcp *hdcp = >attached_connector->hdcp;
> unsigned int offset;
> u8 *byte = buf;
> ssize_t ret, bytes_to_write, len;
> @@ -463,8 +461,6 @@ int intel_dp_hdcp2_write_msg(struct intel_digital_port
> *dig_port,
> bytes_to_write = size - 1;
> byte++;
>
> - hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
> -
> while (bytes_to_write) {
> len = bytes_to_write > DP_AUX_MAX_PAYLOAD_BYTES ?
> DP_AUX_MAX_PAYLOAD_BYTES : bytes_to_write;
> @@ -530,6 +526,8 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
> *dig_port,
> u8 msg_id, void *buf, size_t size)
> {
> struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> + struct intel_dp *dp = _port->dp;
> + struct intel_hdcp *hdcp = >attached_connector->hdcp;
> unsigned int offset;
> u8 *byte = buf;
> ssize_t ret, bytes_to_recv, len;
> @@ -546,6 +544,8 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
> *dig_port,
> if (ret < 0)
> return ret;
>
> + hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
> +
> if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
> ret = get_receiver_id_list_size(dig_port);
> if (ret < 0)
> --
> 2.31.1
>
Re: [Intel-gfx] [V3 2/7] drm/i915/jsl: program DSI panel GPIOs
On Tue, 10 Aug 2021, Jani Nikula wrote:
>On Tue, 10 Aug 2021, "Lee, Shawn C" wrote:
>> On Tue, 10 Aug 2021, Jani Nikula wrote:
>>>On Fri, 23 Jul 2021, Lee Shawn C wrote:
DSI driver should have its own implementation to toggle gpio pins
based on GPIO info coming from VBT sequences.
>>>
>>>Why?
>>>
>>
>> Without this change, we are not able to control gpio signal output to
>> meet MIPI panel's requirement for power on/off sequence.
>>
Cc: Ville Syrjala
Cc: Jani Nikula
Cc: Vandita Kulkarni
Cc: Cooper Chiou
Cc: William Tseng
Signed-off-by: Lee Shawn C
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 44 +++-
drivers/gpu/drm/i915/i915_reg.h | 10 +
2 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
index cc93e045a425..dd03e5629ba6 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
@@ -43,6 +43,7 @@
#include "intel_display_types.h"
#include "intel_dsi.h"
#include "intel_sideband.h"
+#include "intel_de.h"
#define MIPI_TRANSFER_MODE_SHIFT0
#define MIPI_VIRTUAL_CHANNEL_SHIFT 1
@@ -354,7 +355,48 @@ static void bxt_exec_gpio(struct drm_i915_private
*dev_priv, static void icl_exec_gpio(struct drm_i915_private *dev_priv,
u8 gpio_source, u8 gpio_index, bool value) {
-drm_dbg_kms(_priv->drm, "Skipping ICL GPIO element execution\n");
+u32 val;
+
+switch (gpio_index) {
+case ICL_GPIO_L_VDDEN_1:
+val = intel_de_read(dev_priv, ICP_PP_CONTROL(1));
+if (value)
+val |= PWR_STATE_TARGET;
+else
+val &= ~PWR_STATE_TARGET;
+intel_de_write(dev_priv, ICP_PP_CONTROL(1), val);
>>>
>>>All the PPS access should be in intel_pps.[ch] and protected with the pps
>>>mutex.
>>>
>>
>> OK! We will move icl_exec_gpio() into intel_pps.c and use pps mutex to
>> protect it.
>>
+break;
+case ICL_GPIO_L_BKLTEN_1:
+val = intel_de_read(dev_priv, ICP_PP_CONTROL(1));
+if (value)
+val |= BACKLIGHT_ENABLE;
+else
+val &= ~BACKLIGHT_ENABLE;
+intel_de_write(dev_priv, ICP_PP_CONTROL(1), val);
+break;
+case ICL_GPIO_DDPA_CTRLCLK_1:
+val = intel_de_read(dev_priv, GPIO(1));
+if (value)
+val |= GPIO_CLOCK_VAL_OUT;
+else
+val &= ~GPIO_CLOCK_VAL_OUT;
+val |= GPIO_CLOCK_DIR_MASK | GPIO_CLOCK_DIR_OUT |
GPIO_CLOCK_VAL_MASK;
+intel_de_write(dev_priv, GPIO(1), val);
+break;
+case ICL_GPIO_DDPA_CTRLDATA_1:
+val = intel_de_read(dev_priv, GPIO(1));
+if (value)
+val |= GPIO_DATA_VAL_OUT;
+else
+val &= ~GPIO_DATA_VAL_OUT;
+val |= GPIO_DATA_DIR_MASK | GPIO_DATA_DIR_OUT |
GPIO_DATA_VAL_MASK;
+intel_de_write(dev_priv, GPIO(1), val);
+break;
+default:
+/* TODO: Add support for remaining GPIOs */
+DRM_ERROR("Invalid GPIO number (%d) from VBT\n", gpio_index);
+break;
+}
}
static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8
*data) diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h index 943fe485c662..b725234e0e9c
100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5143,6 +5143,16 @@ enum {
#define _PP_STATUS 0x61200
#define PP_STATUS(pps_idx) _MMIO_PPS(pps_idx, _PP_STATUS)
#define PP_ON REG_BIT(31)
+
+#define _PP_CONTROL_1 0xc7204
+#define _PP_CONTROL_2 0xc7304
+#define ICP_PP_CONTROL(x) _MMIO(((x) == 1) ? _PP_CONTROL_1 : \
+ _PP_CONTROL_2)
+#define POWER_CYCLE_DELAY_MASK REG_GENMASK(8, 4)
+#define VDD_OVERRIDE_FORCE REG_BIT(3)
+#define BACKLIGHT_ENABLE REG_BIT(2)
+#define PWR_DOWN_ON_RESET REG_BIT(1)
+#define PWR_STATE_TARGET REG_BIT(0)
>>>
>>>These are all duplicate defines for existing PP_CONTROL() registers and
>>>macros.
>>
>> I found this patch on drm-tip branch and removed PP_CONTRL() defines.
>> https://patchwork.freedesktop.org/patch/291095/
>
>Look for PP_CONTROL(), not
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/hdcp: HDCP2.2 MST dock fixes (rev3)
== Series Details ==
Series: drm/i915/hdcp: HDCP2.2 MST dock fixes (rev3)
URL : https://patchwork.freedesktop.org/series/93570/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10465 -> Patchwork_20796
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20796 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20796, 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_20796/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20796:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@workarounds:
- fi-rkl-guc: NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20796/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
Known issues
Here are the changes found in Patchwork_20796 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-gfx:
- fi-rkl-guc: NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20796/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html
* igt@i915_pm_rpm@module-reload:
- fi-rkl-guc: NOTRUN -> [SKIP][3] ([i915#3844] / [i915#579])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20796/fi-rkl-guc/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [PASS][4] -> [INCOMPLETE][5] ([i915#2940])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20796/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
Possible fixes
* igt@core_hotunplug@unbind-rebind:
- fi-rkl-guc: [DMESG-WARN][6] ([i915#3925]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20796/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4: [FAIL][8] ([i915#1888]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20796/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
* igt@i915_selftest@live@hangcheck:
- {fi-jsl-1}: [INCOMPLETE][10] -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20796/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-rkl-11600: [SKIP][12] -> [PASS][13] +1 similar issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/fi-rkl-11600/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20796/fi-rkl-11600/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3844]: https://gitlab.freedesktop.org/drm/intel/issues/3844
[i915#3925]: https://gitlab.freedesktop.org/drm/intel/issues/3925
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
Participating hosts (37 -> 34)
--
Missing(3): fi-bdw-samus fi-bsw-cyan bat-jsl-1
Build changes
-
* Linux: CI_DRM_10465 -> Patchwork_20796
CI-20190529: 20190529
CI_DRM_10465: b183cdc9ca5e84a70c1d9d57ab317319fb6bed65 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6166: 63db0bc86c6321897ef829a5e7c9536a6f062b21 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20796: 7514cc648d75d684269cb468464e0df0427b4327 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7514cc648d75 drm/i915/hdcp: reuse rx_info for mst stream type1 capability check
4210742b1ffe drm/i915/hdcp: read RxInfo once when reading
RepeaterAuth_Send_ReceiverID_List
6282eb323586 drm/i915/hdcp: update cp_irq_count_cached in
intel_dp_hdcp2_read_msg()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20796/index.html
Re: [Intel-gfx] [PATCH v5 2/9] drm/i915/xehp: Loop over all gslices for INSTDONE processing
On Thu, Aug 05, 2021 at 09:36:40AM -0700, Matt Roper wrote:
We no longer have traditional slices on Xe_HP platforms, but the
INSTDONE registers are replicated according to gslice representation
which is similar. We can mostly re-use the existing instdone code with
just a few modifications:
* Create an alternate instdone loop macro that will iterate over the
flat DSS space, but still provide the gslice/dss steering values for
compatibility with the legacy code.
* We should allocate INSTDONE storage space according to the maximum
number of gslices rather than the maximum number of legacy slices to
ensure we have enough storage space to hold all of the values. XeHP
design has 8 gslices, whereas older platforms never had more than 3
slices.
Signed-off-by: Matt Roper
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 48 +++-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 12 -
drivers/gpu/drm/i915/gt/intel_sseu.h | 7 +++
drivers/gpu/drm/i915/i915_gpu_error.c| 32 +
4 files changed, 66 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 0d9105a31d84..58ed67894b3d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1163,16 +1163,16 @@ void intel_engine_get_instdone(const struct
intel_engine_cs *engine,
u32 mmio_base = engine->mmio_base;
int slice;
int subslice;
+ int iter;
memset(instdone, 0, sizeof(*instdone));
- switch (GRAPHICS_VER(i915)) {
- default:
+ if (GRAPHICS_VER(i915) >= 8) {
instdone->instdone =
intel_uncore_read(uncore, RING_INSTDONE(mmio_base));
if (engine->id != RCS0)
- break;
+ return;
instdone->slice_common =
intel_uncore_read(uncore, GEN7_SC_INSTDONE);
@@ -1182,21 +1182,32 @@ void intel_engine_get_instdone(const struct
intel_engine_cs *engine,
instdone->slice_common_extra[1] =
intel_uncore_read(uncore,
GEN12_SC_INSTDONE_EXTRA2);
}
- for_each_instdone_slice_subslice(i915, sseu, slice, subslice) {
- instdone->sampler[slice][subslice] =
- read_subslice_reg(engine, slice, subslice,
- GEN7_SAMPLER_INSTDONE);
- instdone->row[slice][subslice] =
- read_subslice_reg(engine, slice, subslice,
- GEN7_ROW_INSTDONE);
+
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
+ for_each_instdone_gslice_dss_xehp(i915, sseu, iter,
slice, subslice) {
+ instdone->sampler[slice][subslice] =
+ read_subslice_reg(engine, slice,
subslice,
+
GEN7_SAMPLER_INSTDONE);
+ instdone->row[slice][subslice] =
+ read_subslice_reg(engine, slice,
subslice,
+ GEN7_ROW_INSTDONE);
+ }
+ } else {
+ for_each_instdone_slice_subslice(i915, sseu, slice,
subslice) {
+ instdone->sampler[slice][subslice] =
+ read_subslice_reg(engine, slice,
subslice,
+
GEN7_SAMPLER_INSTDONE);
+ instdone->row[slice][subslice] =
+ read_subslice_reg(engine, slice,
subslice,
+ GEN7_ROW_INSTDONE);
+ }
}
- break;
- case 7:
+ } else if (GRAPHICS_VER(i915) >= 7) {
instdone->instdone =
intel_uncore_read(uncore, RING_INSTDONE(mmio_base));
if (engine->id != RCS0)
- break;
+ return;
instdone->slice_common =
intel_uncore_read(uncore, GEN7_SC_INSTDONE);
@@ -1204,22 +1215,15 @@ void intel_engine_get_instdone(const struct
intel_engine_cs *engine,
intel_uncore_read(uncore, GEN7_SAMPLER_INSTDONE);
instdone->row[0][0] =
intel_uncore_read(uncore, GEN7_ROW_INSTDONE);
-
- break;
- case 6:
- case 5:
- case 4:
+ } else if (GRAPHICS_VER(i915) >= 4) {
instdone->instdone =
intel_uncore_read(uncore, RING_INSTDONE(mmio_base));
Re: [Intel-gfx] [PATCH v5.1 4/9] drm/i915/xehpsdv: Add compute DSS type
On Fri, Aug 06, 2021 at 10:29:01AM -0700, Matt Roper wrote:
From: Stuart Summers
Starting in XeHP, the concept of slice has been removed in favor of
DSS (Dual-Subslice) masks for various workload types. These workloads have
been divided into those enabled for geometry and those enabled for compute.
i915 currently maintains a single set of S/SS/EU masks for the device.
The goal of this patch set is to minimize the amount of impact to prior
generations while still giving the user maximum flexibility.
v2:
- Generalize a comment about uapi access to geometry/compute masks; the
proposed uapi has changed since the comment was first written, and
will show up in a future series once the userspace code is published.
(Lucas)
v3:
- Eliminate unnecessary has_compute_dss flag. (Lucas)
- Drop unwanted comment change in uapi header. (Lucas)
Bspec: 33117, 33118, 20376
Cc: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: Stuart Summers
Signed-off-by: Steve Hampson
Signed-off-by: Matt Roper
Reviewed-by: Lucas De Marchi
thanks
Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 60 +---
drivers/gpu/drm/i915/gt/intel_sseu.h | 4 +-
drivers/gpu/drm/i915/i915_reg.h | 3 +-
3 files changed, 50 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index bbd272943c3f..b0e09b58005e 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -46,11 +46,11 @@ u32 intel_sseu_get_subslices(const struct sseu_dev_info
*sseu, u8 slice)
}
void intel_sseu_set_subslices(struct sseu_dev_info *sseu, int slice,
- u32 ss_mask)
+ u8 *subslice_mask, u32 ss_mask)
{
int offset = slice * sseu->ss_stride;
- memcpy(>subslice_mask[offset], _mask, sseu->ss_stride);
+ memcpy(_mask[offset], _mask, sseu->ss_stride);
}
unsigned int
@@ -100,14 +100,24 @@ static u16 compute_eu_total(const struct sseu_dev_info
*sseu)
return total;
}
-static void gen11_compute_sseu_info(struct sseu_dev_info *sseu,
- u8 s_en, u32 ss_en, u16 eu_en)
+static u32 get_ss_stride_mask(struct sseu_dev_info *sseu, u8 s, u32 ss_en)
+{
+ u32 ss_mask;
+
+ ss_mask = ss_en >> (s * sseu->max_subslices);
+ ss_mask &= GENMASK(sseu->max_subslices - 1, 0);
+
+ return ss_mask;
+}
+
+static void gen11_compute_sseu_info(struct sseu_dev_info *sseu, u8 s_en,
+ u32 g_ss_en, u32 c_ss_en, u16 eu_en)
{
int s, ss;
- /* ss_en represents entire subslice mask across all slices */
+ /* g_ss_en/c_ss_en represent entire subslice mask across all slices */
GEM_BUG_ON(sseu->max_slices * sseu->max_subslices >
- sizeof(ss_en) * BITS_PER_BYTE);
+ sizeof(g_ss_en) * BITS_PER_BYTE);
for (s = 0; s < sseu->max_slices; s++) {
if ((s_en & BIT(s)) == 0)
@@ -115,7 +125,22 @@ static void gen11_compute_sseu_info(struct sseu_dev_info
*sseu,
sseu->slice_mask |= BIT(s);
- intel_sseu_set_subslices(sseu, s, ss_en);
+ /*
+* XeHP introduces the concept of compute vs geometry DSS. To
+* reduce variation between GENs around subslice usage, store a
+* mask for both the geometry and compute enabled masks since
+* userspace will need to be able to query these masks
+* independently. Also compute a total enabled subslice count
+* for the purposes of selecting subslices to use in a
+* particular GEM context.
+*/
+ intel_sseu_set_subslices(sseu, s, sseu->compute_subslice_mask,
+get_ss_stride_mask(sseu, s, c_ss_en));
+ intel_sseu_set_subslices(sseu, s, sseu->geometry_subslice_mask,
+get_ss_stride_mask(sseu, s, g_ss_en));
+ intel_sseu_set_subslices(sseu, s, sseu->subslice_mask,
+get_ss_stride_mask(sseu, s,
+ g_ss_en | c_ss_en));
for (ss = 0; ss < sseu->max_subslices; ss++)
if (intel_sseu_has_subslice(sseu, s, ss))
@@ -129,7 +154,7 @@ static void gen12_sseu_info_init(struct intel_gt *gt)
{
struct sseu_dev_info *sseu = >info.sseu;
struct intel_uncore *uncore = gt->uncore;
- u32 dss_en;
+ u32 g_dss_en, c_dss_en = 0;
u16 eu_en = 0;
u8 eu_en_fuse;
u8 s_en;
@@ -160,7 +185,9 @@ static void gen12_sseu_info_init(struct intel_gt *gt)
s_en = intel_uncore_read(uncore, GEN11_GT_SLICE_ENABLE) &
GEN11_GT_S_ENA_MASK;
- dss_en = intel_uncore_read(uncore, GEN12_GT_DSS_ENABLE);
+
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/hdcp: HDCP2.2 MST dock fixes (rev3)
== Series Details == Series: drm/i915/hdcp: HDCP2.2 MST dock fixes (rev3) URL : https://patchwork.freedesktop.org/series/93570/ 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/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
[Intel-gfx] [PATCH v3 2/3] drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List
When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by itself
once to retrieve the DEVICE_COUNT to calculate the size of the
ReceiverID list then read a second time as a part of reading ReceiverID
list.
On some MST docking stations, RxInfo can only be read after the RxStatus
READY bit is set otherwise the read will return -EIO. The spec states that
the READY bit should be cleared as soon as RxInfo has been read.
In this case, the first RxInfo read succeeds but after the READY bit is
cleared, the second read fails.
Fix it by reading RxInfo once and storing it before reading the rest of
RepeaterAuth_Send_ReceiverID_List once we know the size.
Modify get_receiver_id_list_size() to read and store RxInfo in the
message buffer and also parse DEVICE_COUNT so we know the size of
RepeaterAuth_Send_ReceiverID_List.
Afterwards, retrieve the rest of the message at the offset for
seq_num_V.
Changes in v4:
- rebase and edit commit message
Changes in v3:
- remove comment
Changes in v2:
- remove unnecessary moving of drm_i915_private from patch 1
Signed-off-by: Juston Li
Acked-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 30 ++--
include/drm/drm_dp_helper.h | 2 +-
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 1d0096654776..526fd58b9b51 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -496,11 +496,10 @@ get_rxinfo_hdcp_1_dev_downstream(struct
intel_digital_port *dig_port, bool *hdcp
}
static
-ssize_t get_receiver_id_list_size(struct intel_digital_port *dig_port)
+ssize_t get_receiver_id_list_rx_info(struct intel_digital_port *dig_port, u32
*dev_cnt, u8 *byte)
{
- u8 rx_info[HDCP_2_2_RXINFO_LEN];
- u32 dev_cnt;
ssize_t ret;
+ u8 *rx_info = byte;
ret = drm_dp_dpcd_read(_port->dp.aux,
DP_HDCP_2_2_REG_RXINFO_OFFSET,
@@ -508,15 +507,11 @@ ssize_t get_receiver_id_list_size(struct
intel_digital_port *dig_port)
if (ret != HDCP_2_2_RXINFO_LEN)
return ret >= 0 ? -EIO : ret;
- dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
+ *dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
HDCP_2_2_DEV_COUNT_LO(rx_info[1]));
- if (dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
- dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
-
- ret = sizeof(struct hdcp2_rep_send_receiverid_list) -
- HDCP_2_2_RECEIVER_IDS_MAX_LEN +
- (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
+ if (*dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
+ *dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
return ret;
}
@@ -534,6 +529,7 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
const struct hdcp2_dp_msg_data *hdcp2_msg_data;
ktime_t msg_end = ktime_set(0, 0);
bool msg_expired;
+ u32 dev_cnt;
hdcp2_msg_data = get_hdcp2_dp_msg_data(msg_id);
if (!hdcp2_msg_data)
@@ -546,17 +542,21 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
+ /* DP adaptation msgs has no msg_id */
+ byte++;
+
if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
- ret = get_receiver_id_list_size(dig_port);
+ ret = get_receiver_id_list_rx_info(dig_port, _cnt, byte);
if (ret < 0)
return ret;
- size = ret;
+ byte += ret;
+ size = sizeof(struct hdcp2_rep_send_receiverid_list) -
+ HDCP_2_2_RXINFO_LEN - HDCP_2_2_RECEIVER_IDS_MAX_LEN +
+ (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
}
- bytes_to_recv = size - 1;
- /* DP adaptation msgs has no msg_id */
- byte++;
+ bytes_to_recv = size - 1;
while (bytes_to_recv) {
len = bytes_to_recv > DP_AUX_MAX_PAYLOAD_BYTES ?
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 3f2715eb965f..7476e7c6d0be 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1413,7 +1413,7 @@ enum drm_dp_phy {
#define DP_HDCP_2_2_LC_INIT_OFFSET DP_HDCP_2_2_REG_RN_OFFSET
#define DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET DP_HDCP_2_2_REG_LPRIME_OFFSET
#define DP_HDCP_2_2_SKE_SEND_EKS_OFFSET
DP_HDCP_2_2_REG_EDKEY_KS_OFFSET
-#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
DP_HDCP_2_2_REG_RXINFO_OFFSET
+#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
DP_HDCP_2_2_REG_SEQ_NUM_V_OFFSET
#define DP_HDCP_2_2_REP_SEND_ACK_OFFSETDP_HDCP_2_2_REG_V_OFFSET
#define DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET
#define DP_HDCP_2_2_REP_STREAM_READY_OFFSETDP_HDCP_2_2_REG_MPRIME_OFFSET
--
2.31.1
[Intel-gfx] [PATCH v3 3/3] drm/i915/hdcp: reuse rx_info for mst stream type1 capability check
On some MST docking stations, rx_info can only be read after
RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
otherwise the read will return -EIO.
This behavior causes the mst stream type1 capability test to fail to
read rx_info and determine if the topology supports type1 and fallback
to type0.
To fix this, check for type1 capability when we receive rx_info within
the AKE flow when we read RepeaterAuth_Send_ReceiverID_List instead
of an explicit read just for type1 capability checking.
This does require moving where we set stream_types to after
hdcp2_authenticate_sink() when we get rx_info but this occurs before we
do hdcp2_propagate_stream_management_info.
Also, legacy HDCP 2.0/2.1 are not type 1 capable either so check for
that as well.
Changes since v2:
- Remove no longer used variables in _intel_hdcp2_enable()
Signed-off-by: Juston Li
---
.../drm/i915/display/intel_display_types.h| 2 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 39 ---
drivers/gpu/drm/i915/display/intel_hdcp.c | 49 ---
3 files changed, 23 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index dbdfe54d0340..c8b687ff0374 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -516,6 +516,8 @@ struct intel_hdcp {
enum transcoder cpu_transcoder;
/* Only used for DP MST stream encryption */
enum transcoder stream_transcoder;
+
+ bool topology_type1_capable;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 526fd58b9b51..2d39af63ec9b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -478,23 +478,6 @@ int intel_dp_hdcp2_write_msg(struct intel_digital_port
*dig_port,
return size;
}
-static int
-get_rxinfo_hdcp_1_dev_downstream(struct intel_digital_port *dig_port, bool
*hdcp_1_x)
-{
- u8 rx_info[HDCP_2_2_RXINFO_LEN];
- int ret;
-
- ret = drm_dp_dpcd_read(_port->dp.aux,
- DP_HDCP_2_2_REG_RXINFO_OFFSET,
- (void *)rx_info, HDCP_2_2_RXINFO_LEN);
-
- if (ret != HDCP_2_2_RXINFO_LEN)
- return ret >= 0 ? -EIO : ret;
-
- *hdcp_1_x = HDCP_2_2_HDCP1_DEVICE_CONNECTED(rx_info[1]) ? true : false;
- return 0;
-}
-
static
ssize_t get_receiver_id_list_rx_info(struct intel_digital_port *dig_port, u32
*dev_cnt, u8 *byte)
{
@@ -664,27 +647,6 @@ int intel_dp_hdcp2_capable(struct intel_digital_port
*dig_port,
return 0;
}
-static
-int intel_dp_mst_streams_type1_capable(struct intel_connector *connector,
- bool *capable)
-{
- struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- int ret;
- bool hdcp_1_x;
-
- ret = get_rxinfo_hdcp_1_dev_downstream(dig_port, _1_x);
- if (ret) {
- drm_dbg_kms(>drm,
- "[%s:%d] failed to read RxInfo ret=%d\n",
- connector->base.name, connector->base.base.id, ret);
- return ret;
- }
-
- *capable = !hdcp_1_x;
- return 0;
-}
-
static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.write_an_aksv = intel_dp_hdcp_write_an_aksv,
.read_bksv = intel_dp_hdcp_read_bksv,
@@ -833,7 +795,6 @@ static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim
= {
.stream_2_2_encryption = intel_dp_mst_hdcp2_stream_encryption,
.check_2_2_link = intel_dp_mst_hdcp2_check_link,
.hdcp_2_2_capable = intel_dp_hdcp2_capable,
- .streams_type1_capable = intel_dp_mst_streams_type1_capable,
.protocol = HDCP_PROTOCOL_DP,
};
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index ebc2e32aec0b..1a2a98e2c6e3 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -33,21 +33,6 @@ static int intel_conn_to_vcpi(struct intel_connector
*connector)
return connector->port ? connector->port->vcpi.vcpi : 0;
}
-static bool
-intel_streams_type1_capable(struct intel_connector *connector)
-{
- const struct intel_hdcp_shim *shim = connector->hdcp.shim;
- bool capable = false;
-
- if (!shim)
- return capable;
-
- if (shim->streams_type1_capable)
- shim->streams_type1_capable(connector, );
-
- return capable;
-}
-
/*
* intel_hdcp_required_content_stream selects the most highest common possible
HDCP
* content_type for all streams in DP MST topology because security f/w doesn't
@@ -86,7 +71,7 @@ intel_hdcp_required_content_stream(struct
[Intel-gfx] [PATCH v3 1/3] drm/i915/hdcp: update cp_irq_count_cached in intel_dp_hdcp2_read_msg()
Update cp_irq_count_cached when reading messages rather than when
writing a message to make sure the value is up to date and not
stale from a previously handled CP_IRQ.
AKE flow doesn't always respond to a read with a ACK write msg.
E.g. AKE_Send_Pairing_Info will "timeout" because we received
a CP_IRQ for reading AKE_Send_H_Prime but no write occurred between that
and reading AKE_Send_Pairing_Info so cp_irq_count_cached is stale
causing the wait to return right away rather than waiting for a new
CP_IRQ.
Signed-off-by: Juston Li
Acked-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index d697d169e8c1..1d0096654776 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -446,8 +446,6 @@ static
int intel_dp_hdcp2_write_msg(struct intel_digital_port *dig_port,
void *buf, size_t size)
{
- struct intel_dp *dp = _port->dp;
- struct intel_hdcp *hdcp = >attached_connector->hdcp;
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_write, len;
@@ -463,8 +461,6 @@ int intel_dp_hdcp2_write_msg(struct intel_digital_port
*dig_port,
bytes_to_write = size - 1;
byte++;
- hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
-
while (bytes_to_write) {
len = bytes_to_write > DP_AUX_MAX_PAYLOAD_BYTES ?
DP_AUX_MAX_PAYLOAD_BYTES : bytes_to_write;
@@ -530,6 +526,8 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
u8 msg_id, void *buf, size_t size)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ struct intel_dp *dp = _port->dp;
+ struct intel_hdcp *hdcp = >attached_connector->hdcp;
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_recv, len;
@@ -546,6 +544,8 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
if (ret < 0)
return ret;
+ hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
+
if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
ret = get_receiver_id_list_size(dig_port);
if (ret < 0)
--
2.31.1
[Intel-gfx] [PATCH v3 0/3] drm/i915/hdcp: HDCP2.2 MST dock fixes
Fixes to get HDCP2.2 over MST working on MST docking stations with certain behaviors that cause the current flow to fail. Tested with Dell WD-19 and Lenovo ThinkPad USB Type-C Dock Gen 2. These fixes should make the flow more robust to handle behaviors that as far as I can tell are unclear in the HDCP spec: RxInfo contains repeater topology information needed for MST. The behavior on these docks is that this can only be read during RepeaterAuth_Send_ReceiverID_List when the RxStatus READY bit is set otherwise the dock will return NACK. It seems these docks treat reading this range at any other time as invalid when the READY bit isn't set possibly because it could be stale. The HDCP spec also states the READY bit is cleared after RxInfo is read. These fixes address this behavior by only reading RxInfo once during the AKE flow and reusing that data. Changes since v2: - Remove no longer used variables in _intel_hdcp2_enable() Changes since v1: - Fix subject line for 3/3 Juston Li (3): drm/i915/hdcp: update cp_irq_count_cached in intel_dp_hdcp2_read_msg() drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List drm/i915/hdcp: reuse rx_info for mst stream type1 capability check .../drm/i915/display/intel_display_types.h| 2 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 77 +-- drivers/gpu/drm/i915/display/intel_hdcp.c | 49 +--- include/drm/drm_dp_helper.h | 2 +- 4 files changed, 43 insertions(+), 87 deletions(-) -- 2.31.1
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use locked access to ctx->engines in set_priority
== Series Details == Series: drm/i915: Use locked access to ctx->engines in set_priority URL : https://patchwork.freedesktop.org/series/93558/ State : success == Summary == CI Bug Log - changes from CI_DRM_10465_full -> Patchwork_20794_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20794_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-apl: NOTRUN -> [DMESG-WARN][1] ([i915#180]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-apl6/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_ctx_persistence@legacy-engines-mixed-process: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +6 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#2369] / [i915#3063] / [i915#3648]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-tglb3/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-tglb3/igt@gem_...@unwedge-stress.html - shard-iclb: [PASS][5] -> [TIMEOUT][6] ([i915#2369] / [i915#2481] / [i915#3070]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-iclb1/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-iclb6/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-kbl7/igt@gem_exec_f...@basic-deadline.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-kbl6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-kbl: [PASS][9] -> [SKIP][10] ([fdo#109271]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-kbl6/igt@gem_exec_fair@basic-none-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-kbl4/igt@gem_exec_fair@basic-none-sh...@rcs0.html - shard-apl: [PASS][11] -> [SKIP][12] ([fdo#109271]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-apl3/igt@gem_exec_fair@basic-none-sh...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-apl7/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2842]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-iclb5/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#2849]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#2190]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-kbl4/igt@gem_huc_c...@huc-copy.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][20] ([i915#2658]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-apl8/igt@gem_pr...@exhaustion.html - shard-snb: NOTRUN -> [WARN][21] ([i915#2658]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-snb5/igt@gem_pr...@exhaustion.html * igt@gem_workarounds@suspend-resume: - shard-skl: [PASS][22] -> [INCOMPLETE][23] ([i915#198]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-skl1/igt@gem_workarou...@suspend-resume.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-skl5/igt@gem_workarou...@suspend-resume.html * igt@gen9_exec_parse@batch-invalid-length: - shard-tglb: NOTRUN -> [SKIP][24] ([i915#2856]) [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/shard-tglb1/igt@gen9_exec_pa...@batch-invalid-length.html *
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hdcp: HDCP2.2 MST dock fixes (rev2)
== Series Details == Series: drm/i915/hdcp: HDCP2.2 MST dock fixes (rev2) URL : https://patchwork.freedesktop.org/series/93570/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/display/intel_hdcp.o drivers/gpu/drm/i915/display/intel_hdcp.c: In function ‘_intel_hdcp2_enable’: drivers/gpu/drm/i915/display/intel_hdcp.c:1931:25: error: unused variable ‘data’ [-Werror=unused-variable] struct hdcp_port_data *data = _port->hdcp_port_data; ^~~~ cc1: all warnings being treated as errors scripts/Makefile.build:271: recipe for target 'drivers/gpu/drm/i915/display/intel_hdcp.o' failed make[4]: *** [drivers/gpu/drm/i915/display/intel_hdcp.o] Error 1 scripts/Makefile.build:514: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:514: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:514: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1851: recipe for target 'drivers' failed make: *** [drivers] Error 2
[Intel-gfx] ✗ Fi.CI.IGT: failure for Tweaked Wa_14010685332 for all PCHs
== Series Details == Series: Tweaked Wa_14010685332 for all PCHs URL : https://patchwork.freedesktop.org/series/93548/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10464_full -> Patchwork_20792_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20792_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20792_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_20792_full: ### IGT changes ### Possible regressions * igt@kms_frontbuffer_tracking@psr-rgb565-draw-blt: - shard-skl: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-skl4/igt@kms_frontbuffer_track...@psr-rgb565-draw-blt.html Known issues Here are the changes found in Patchwork_20792_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@smoketest: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-snb6/igt@gem_ctx_persiste...@smoketest.html * igt@gem_eio@in-flight-contexts-1us: - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#3063]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/shard-tglb5/igt@gem_...@in-flight-contexts-1us.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-tglb5/igt@gem_...@in-flight-contexts-1us.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][5] ([i915#3354]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-snb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/shard-glk5/igt@gem_exec_f...@basic-deadline.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-glk6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-glk9/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_params@invalid-bsd1-flag-on-vebox: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/shard-skl1/igt@gem_exec_par...@invalid-bsd1-flag-on-vebox.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-skl5/igt@gem_exec_par...@invalid-bsd1-flag-on-vebox.html * igt@gem_pread@exhaustion: - shard-skl: NOTRUN -> [WARN][13] ([i915#2658]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-skl8/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@input-checking: - shard-snb: NOTRUN -> [DMESG-WARN][14] ([i915#3002]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-snb6/igt@gem_userptr_bl...@input-checking.html * igt@gem_userptr_blits@vma-merge: - shard-skl: NOTRUN -> [FAIL][15] ([i915#3318]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-skl8/igt@gem_userptr_bl...@vma-merge.html * igt@gem_workarounds@suspend-resume-fd: - shard-apl: [PASS][16] -> [DMESG-WARN][17] ([i915#180]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/shard-apl8/igt@gem_workarou...@suspend-resume-fd.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-apl3/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_pm_dc@dc6-psr: - shard-skl: NOTRUN -> [FAIL][18] ([i915#454]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-skl9/igt@i915_pm...@dc6-psr.html * igt@i915_pm_dc@dc9-dpms: - shard-skl: NOTRUN -> [FAIL][19] ([i915#545]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-skl4/igt@i915_pm...@dc9-dpms.html * igt@i915_pm_rpm@basic-rte: - shard-apl: NOTRUN -> [FAIL][20] ([i915#579]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/shard-apl1/igt@i915_pm_...@basic-rte.html * igt@i915_pm_rpm@gem-pread: - shard-tglb: NOTRUN -> [SKIP][21] ([i915#579]) [21]:
[Intel-gfx] [PATCH v2 3/3] drm/i915/hdcp: reuse rx_info for mst stream type1 capability check
On some MST docking stations, rx_info can only be read after
RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
otherwise the read will return -EIO.
This behavior causes the mst stream type1 capability test to fail to
read rx_info and determine if the topology supports type1 and fallback
to type0.
To fix this, check for type1 capability when we receive rx_info within
the AKE flow when we read RepeaterAuth_Send_ReceiverID_List instead
of an explicit read just for type1 capability checking.
This does require moving where we set stream_types to after
hdcp2_authenticate_sink() when we get rx_info but this occurs before we
do hdcp2_propagate_stream_management_info.
Also, legacy HDCP 2.0/2.1 are not type 1 capable either so check for
that as well.
Signed-off-by: Juston Li
---
.../drm/i915/display/intel_display_types.h| 2 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 39 ---
drivers/gpu/drm/i915/display/intel_hdcp.c | 47 +--
3 files changed, 23 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index dbdfe54d0340..c8b687ff0374 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -516,6 +516,8 @@ struct intel_hdcp {
enum transcoder cpu_transcoder;
/* Only used for DP MST stream encryption */
enum transcoder stream_transcoder;
+
+ bool topology_type1_capable;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 526fd58b9b51..2d39af63ec9b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -478,23 +478,6 @@ int intel_dp_hdcp2_write_msg(struct intel_digital_port
*dig_port,
return size;
}
-static int
-get_rxinfo_hdcp_1_dev_downstream(struct intel_digital_port *dig_port, bool
*hdcp_1_x)
-{
- u8 rx_info[HDCP_2_2_RXINFO_LEN];
- int ret;
-
- ret = drm_dp_dpcd_read(_port->dp.aux,
- DP_HDCP_2_2_REG_RXINFO_OFFSET,
- (void *)rx_info, HDCP_2_2_RXINFO_LEN);
-
- if (ret != HDCP_2_2_RXINFO_LEN)
- return ret >= 0 ? -EIO : ret;
-
- *hdcp_1_x = HDCP_2_2_HDCP1_DEVICE_CONNECTED(rx_info[1]) ? true : false;
- return 0;
-}
-
static
ssize_t get_receiver_id_list_rx_info(struct intel_digital_port *dig_port, u32
*dev_cnt, u8 *byte)
{
@@ -664,27 +647,6 @@ int intel_dp_hdcp2_capable(struct intel_digital_port
*dig_port,
return 0;
}
-static
-int intel_dp_mst_streams_type1_capable(struct intel_connector *connector,
- bool *capable)
-{
- struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- int ret;
- bool hdcp_1_x;
-
- ret = get_rxinfo_hdcp_1_dev_downstream(dig_port, _1_x);
- if (ret) {
- drm_dbg_kms(>drm,
- "[%s:%d] failed to read RxInfo ret=%d\n",
- connector->base.name, connector->base.base.id, ret);
- return ret;
- }
-
- *capable = !hdcp_1_x;
- return 0;
-}
-
static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.write_an_aksv = intel_dp_hdcp_write_an_aksv,
.read_bksv = intel_dp_hdcp_read_bksv,
@@ -833,7 +795,6 @@ static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim
= {
.stream_2_2_encryption = intel_dp_mst_hdcp2_stream_encryption,
.check_2_2_link = intel_dp_mst_hdcp2_check_link,
.hdcp_2_2_capable = intel_dp_hdcp2_capable,
- .streams_type1_capable = intel_dp_mst_streams_type1_capable,
.protocol = HDCP_PROTOCOL_DP,
};
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index ebc2e32aec0b..fa6a60faa6a7 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -33,21 +33,6 @@ static int intel_conn_to_vcpi(struct intel_connector
*connector)
return connector->port ? connector->port->vcpi.vcpi : 0;
}
-static bool
-intel_streams_type1_capable(struct intel_connector *connector)
-{
- const struct intel_hdcp_shim *shim = connector->hdcp.shim;
- bool capable = false;
-
- if (!shim)
- return capable;
-
- if (shim->streams_type1_capable)
- shim->streams_type1_capable(connector, );
-
- return capable;
-}
-
/*
* intel_hdcp_required_content_stream selects the most highest common possible
HDCP
* content_type for all streams in DP MST topology because security f/w doesn't
@@ -86,7 +71,7 @@ intel_hdcp_required_content_stream(struct intel_digital_port
*dig_port)
if (conn_dig_port != dig_port)
[Intel-gfx] [PATCH v2 2/3] drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List
When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by itself
once to retrieve the DEVICE_COUNT to calculate the size of the
ReceiverID list then read a second time as a part of reading ReceiverID
list.
On some MST docking stations, RxInfo can only be read after the RxStatus
READY bit is set otherwise the read will return -EIO. The spec states that
the READY bit should be cleared as soon as RxInfo has been read.
In this case, the first RxInfo read succeeds but after the READY bit is
cleared, the second read fails.
Fix it by reading RxInfo once and storing it before reading the rest of
RepeaterAuth_Send_ReceiverID_List once we know the size.
Modify get_receiver_id_list_size() to read and store RxInfo in the
message buffer and also parse DEVICE_COUNT so we know the size of
RepeaterAuth_Send_ReceiverID_List.
Afterwards, retrieve the rest of the message at the offset for
seq_num_V.
Changes in v4:
- rebase and edit commit message
Changes in v3:
- remove comment
Changes in v2:
- remove unnecessary moving of drm_i915_private from patch 1
Signed-off-by: Juston Li
Acked-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 30 ++--
include/drm/drm_dp_helper.h | 2 +-
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 1d0096654776..526fd58b9b51 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -496,11 +496,10 @@ get_rxinfo_hdcp_1_dev_downstream(struct
intel_digital_port *dig_port, bool *hdcp
}
static
-ssize_t get_receiver_id_list_size(struct intel_digital_port *dig_port)
+ssize_t get_receiver_id_list_rx_info(struct intel_digital_port *dig_port, u32
*dev_cnt, u8 *byte)
{
- u8 rx_info[HDCP_2_2_RXINFO_LEN];
- u32 dev_cnt;
ssize_t ret;
+ u8 *rx_info = byte;
ret = drm_dp_dpcd_read(_port->dp.aux,
DP_HDCP_2_2_REG_RXINFO_OFFSET,
@@ -508,15 +507,11 @@ ssize_t get_receiver_id_list_size(struct
intel_digital_port *dig_port)
if (ret != HDCP_2_2_RXINFO_LEN)
return ret >= 0 ? -EIO : ret;
- dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
+ *dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
HDCP_2_2_DEV_COUNT_LO(rx_info[1]));
- if (dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
- dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
-
- ret = sizeof(struct hdcp2_rep_send_receiverid_list) -
- HDCP_2_2_RECEIVER_IDS_MAX_LEN +
- (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
+ if (*dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
+ *dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
return ret;
}
@@ -534,6 +529,7 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
const struct hdcp2_dp_msg_data *hdcp2_msg_data;
ktime_t msg_end = ktime_set(0, 0);
bool msg_expired;
+ u32 dev_cnt;
hdcp2_msg_data = get_hdcp2_dp_msg_data(msg_id);
if (!hdcp2_msg_data)
@@ -546,17 +542,21 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
+ /* DP adaptation msgs has no msg_id */
+ byte++;
+
if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
- ret = get_receiver_id_list_size(dig_port);
+ ret = get_receiver_id_list_rx_info(dig_port, _cnt, byte);
if (ret < 0)
return ret;
- size = ret;
+ byte += ret;
+ size = sizeof(struct hdcp2_rep_send_receiverid_list) -
+ HDCP_2_2_RXINFO_LEN - HDCP_2_2_RECEIVER_IDS_MAX_LEN +
+ (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
}
- bytes_to_recv = size - 1;
- /* DP adaptation msgs has no msg_id */
- byte++;
+ bytes_to_recv = size - 1;
while (bytes_to_recv) {
len = bytes_to_recv > DP_AUX_MAX_PAYLOAD_BYTES ?
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 3f2715eb965f..7476e7c6d0be 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1413,7 +1413,7 @@ enum drm_dp_phy {
#define DP_HDCP_2_2_LC_INIT_OFFSET DP_HDCP_2_2_REG_RN_OFFSET
#define DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET DP_HDCP_2_2_REG_LPRIME_OFFSET
#define DP_HDCP_2_2_SKE_SEND_EKS_OFFSET
DP_HDCP_2_2_REG_EDKEY_KS_OFFSET
-#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
DP_HDCP_2_2_REG_RXINFO_OFFSET
+#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
DP_HDCP_2_2_REG_SEQ_NUM_V_OFFSET
#define DP_HDCP_2_2_REP_SEND_ACK_OFFSETDP_HDCP_2_2_REG_V_OFFSET
#define DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET
#define DP_HDCP_2_2_REP_STREAM_READY_OFFSETDP_HDCP_2_2_REG_MPRIME_OFFSET
--
2.31.1
[Intel-gfx] [PATCH v2 1/3] drm/i915/hdcp: update cp_irq_count_cached in intel_dp_hdcp2_read_msg()
Update cp_irq_count_cached when reading messages rather than when
writing a message to make sure the value is up to date and not
stale from a previously handled CP_IRQ.
AKE flow doesn't always respond to a read with a ACK write msg.
E.g. AKE_Send_Pairing_Info will "timeout" because we received
a CP_IRQ for reading AKE_Send_H_Prime but no write occurred between that
and reading AKE_Send_Pairing_Info so cp_irq_count_cached is stale
causing the wait to return right away rather than waiting for a new
CP_IRQ.
Signed-off-by: Juston Li
Acked-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index d697d169e8c1..1d0096654776 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -446,8 +446,6 @@ static
int intel_dp_hdcp2_write_msg(struct intel_digital_port *dig_port,
void *buf, size_t size)
{
- struct intel_dp *dp = _port->dp;
- struct intel_hdcp *hdcp = >attached_connector->hdcp;
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_write, len;
@@ -463,8 +461,6 @@ int intel_dp_hdcp2_write_msg(struct intel_digital_port
*dig_port,
bytes_to_write = size - 1;
byte++;
- hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
-
while (bytes_to_write) {
len = bytes_to_write > DP_AUX_MAX_PAYLOAD_BYTES ?
DP_AUX_MAX_PAYLOAD_BYTES : bytes_to_write;
@@ -530,6 +526,8 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
u8 msg_id, void *buf, size_t size)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ struct intel_dp *dp = _port->dp;
+ struct intel_hdcp *hdcp = >attached_connector->hdcp;
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_recv, len;
@@ -546,6 +544,8 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
if (ret < 0)
return ret;
+ hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
+
if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
ret = get_receiver_id_list_size(dig_port);
if (ret < 0)
--
2.31.1
[Intel-gfx] [PATCH v2 0/3] drm/i915/hdcp: HDCP2.2 MST dock fixes
Fixes to get HDCP2.2 over MST working on MST docking stations with certain behaviors that cause the current flow to fail. Tested with Dell WD-19 and Lenovo ThinkPad USB Type-C Dock Gen 2. These fixes should make the flow more robust to handle behaviors that as far as I can tell are unclear in the HDCP spec: RxInfo contains repeater topology information needed for MST. The behavior on these docks is that this can only be read during RepeaterAuth_Send_ReceiverID_List when the RxStatus READY bit is set otherwise the dock will return NACK. It seems these docks treat reading this range at any other time as invalid when the READY bit isn't set possibly because it could be stale. The HDCP spec also states the READY bit is cleared after RxInfo is read. These fixes address this behavior by only reading RxInfo once during the AKE flow and reusing that data. Changes since v1: - Fix subject line for 3/3 Juston Li (3): drm/i915/hdcp: update cp_irq_count_cached in intel_dp_hdcp2_read_msg() drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List drm/i915/hdcp: reuse rx_info for mst stream type1 capability check .../drm/i915/display/intel_display_types.h| 2 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 77 +-- drivers/gpu/drm/i915/display/intel_hdcp.c | 47 +-- include/drm/drm_dp_helper.h | 2 +- 4 files changed, 43 insertions(+), 85 deletions(-) -- 2.31.1
Re: [Intel-gfx] [PATCH 5/6] drm/i915/gen12: Update shadowed register table
Reviewed-by: Caz Yokoyama
-caz
On Wed, 2021-07-28 at 22:41 -0700, Matt Roper wrote:
> The bspec lists many shadowed registers (i.e., registers for which we
> don't need to grab forcewake when writing) that we weren't tracking
> in
> the driver. Although we may not actually use all of these registers
> right now, it's best to just match the bspec list exactly.
>
> Note that the bspec also lists registers that are shadowed for
> various
> HW-internal accesses; we can ignore those and just list the ones that
> are shadowed for accesses from the IA/CPU.
>
> Bspec: 52077
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 23 ++-
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 31e0456dce5a..42acf106a6df 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -984,23 +984,28 @@ static const struct i915_range
> gen11_shadowed_regs[] = {
>
> static const struct i915_range gen12_shadowed_regs[] = {
> { .start = 0x2030, .end = 0x2030 },
> - { .start = 0x2550, .end = 0x2550 },
> + { .start = 0x2510, .end = 0x2550 },
> { .start = 0xA008, .end = 0xA00C },
> + { .start = 0xA188, .end = 0xA188 },
> + { .start = 0xA278, .end = 0xA278 },
> + { .start = 0xA540, .end = 0xA56C },
> + { .start = 0xC4C8, .end = 0xC4C8 },
> + { .start = 0xC4D4, .end = 0xC4D4 },
> + { .start = 0xC600, .end = 0xC600 },
> { .start = 0x22030, .end = 0x22030 },
> - { .start = 0x22550, .end = 0x22550 },
> + { .start = 0x22510, .end = 0x22550 },
> { .start = 0x1C0030, .end = 0x1C0030 },
> - { .start = 0x1C0550, .end = 0x1C0550 },
> + { .start = 0x1C0510, .end = 0x1C0550 },
> { .start = 0x1C4030, .end = 0x1C4030 },
> - { .start = 0x1C4550, .end = 0x1C4550 },
> + { .start = 0x1C4510, .end = 0x1C4550 },
> { .start = 0x1C8030, .end = 0x1C8030 },
> - { .start = 0x1C8550, .end = 0x1C8550 },
> + { .start = 0x1C8510, .end = 0x1C8550 },
> { .start = 0x1D0030, .end = 0x1D0030 },
> - { .start = 0x1D0550, .end = 0x1D0550 },
> + { .start = 0x1D0510, .end = 0x1D0550 },
> { .start = 0x1D4030, .end = 0x1D4030 },
> - { .start = 0x1D4550, .end = 0x1D4550 },
> + { .start = 0x1D4510, .end = 0x1D4550 },
> { .start = 0x1D8030, .end = 0x1D8030 },
> - { .start = 0x1D8550, .end = 0x1D8550 },
> - /* TODO: Other registers are not yet used */
> + { .start = 0x1D8510, .end = 0x1D8550 },
> };
>
> static const struct i915_range xehp_shadowed_regs[] = {
Re: [Intel-gfx] [PATCH 4/6] drm/i915/gen11: Update shadowed register table
Reviewed-by: Caz Yokoyama
-caz
On Wed, 2021-07-28 at 22:41 -0700, Matt Roper wrote:
> The bspec lists many shadowed registers (i.e., registers for which we
> don't need to grab forcewake when writing) that we weren't tracking
> in
> the driver. Although we may not actually use all of these registers
> right now, it's best to just match the bspec list exactly.
>
> Note that the bspec also lists registers that are shadowed for
> various
> HW-internal accesses; we can ignore those and just list the ones that
> are shadowed for accesses from the IA/CPU.
>
> Bspec: 18333
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 22 ++
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 2cfbc16f7dee..31e0456dce5a 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -960,20 +960,26 @@ static const struct i915_range
> gen11_shadowed_regs[] = {
> { .start = 0x2550, .end = 0x2550 },
> { .start = 0xA008, .end = 0xA00C },
> { .start = 0x22030, .end = 0x22030 },
> - { .start = 0x22550, .end = 0x22550 },
> + { .start = 0x22230, .end = 0x22230 },
> + { .start = 0x22510, .end = 0x22550 },
> { .start = 0x1C0030, .end = 0x1C0030 },
> - { .start = 0x1C0550, .end = 0x1C0550 },
> + { .start = 0x1C0230, .end = 0x1C0230 },
> + { .start = 0x1C0510, .end = 0x1C0550 },
> { .start = 0x1C4030, .end = 0x1C4030 },
> - { .start = 0x1C4550, .end = 0x1C4550 },
> + { .start = 0x1C4230, .end = 0x1C4230 },
> + { .start = 0x1C4510, .end = 0x1C4550 },
> { .start = 0x1C8030, .end = 0x1C8030 },
> - { .start = 0x1C8550, .end = 0x1C8550 },
> + { .start = 0x1C8230, .end = 0x1C8230 },
> + { .start = 0x1C8510, .end = 0x1C8550 },
> { .start = 0x1D0030, .end = 0x1D0030 },
> - { .start = 0x1D0550, .end = 0x1D0550 },
> + { .start = 0x1D0230, .end = 0x1D0230 },
> + { .start = 0x1D0510, .end = 0x1D0550 },
> { .start = 0x1D4030, .end = 0x1D4030 },
> - { .start = 0x1D4550, .end = 0x1D4550 },
> + { .start = 0x1D4230, .end = 0x1D4230 },
> + { .start = 0x1D4510, .end = 0x1D4550 },
> { .start = 0x1D8030, .end = 0x1D8030 },
> - { .start = 0x1D8550, .end = 0x1D8550 },
> - /* TODO: Other registers are not yet used */
> + { .start = 0x1D8230, .end = 0x1D8230 },
> + { .start = 0x1D8510, .end = 0x1D8550 },
> };
>
> static const struct i915_range gen12_shadowed_regs[] = {
Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: Make shadow tables range-based
Reviewed-by: Caz Yokoyama
-caz
On Thu, 2021-07-29 at 14:59 -0700, Matt Roper wrote:
> On Thu, Jul 29, 2021 at 02:55:17PM -0700, Yokoyama, Caz wrote:
> > On Thu, 2021-07-29 at 08:21 -0700, Matt Roper wrote:
> > > Rather than defining our shadow tables as a list of individual
> > > registers, provide them as a list of register ranges; we'll have
> > > some
> > > ranges of multiple registers being added soon (and we already
> > > have a
> > > couple adjacent registers that we can squash into a single range
> > > now).
> > >
> > > This change also defines the table with hex literal values rather
> > > than
> > > symbolic register names; since that's how the tables are defined
> > > in
> > > the
> > > bspec, this change will make it easier to review the tables
> > > overall.
> > >
> > > v2:
> > > - Force signed comparison on range overlap sanity check
> > >
> > > Signed-off-by: Matt Roper
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 +-
> > > drivers/gpu/drm/i915/intel_uncore.c | 160 +---
> > >
> > > --
> > > drivers/gpu/drm/i915/intel_uncore.h | 6 +
> > > drivers/gpu/drm/i915/selftests/intel_uncore.c | 32 ++--
> > > 4 files changed, 108 insertions(+), 103 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > index 9173df59821a..7558414bafb2 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > @@ -1963,12 +1963,7 @@ void intel_engine_apply_workarounds(struct
> > > intel_engine_cs *engine)
> > > wa_list_apply(engine->gt, >wa_list);
> > > }
> > >
> > > -struct mcr_range {
> > > - u32 start;
> > > - u32 end;
> > > -};
> > > -
> > > -static const struct mcr_range mcr_ranges_gen8[] = {
> > > +static const struct i915_range mcr_ranges_gen8[] = {
> > > { .start = 0x5500, .end = 0x55ff },
> > > { .start = 0x7000, .end = 0x7fff },
> > > { .start = 0x9400, .end = 0x97ff },
> > > @@ -1977,7 +1972,7 @@ static const struct mcr_range
> > > mcr_ranges_gen8[]
> > > = {
> > > {},
> > > };
> > >
> > > -static const struct mcr_range mcr_ranges_gen12[] = {
> > > +static const struct i915_range mcr_ranges_gen12[] = {
> > > { .start = 0x8150, .end = 0x815f },
> > > { .start = 0x9520, .end = 0x955f },
> > > { .start = 0xb100, .end = 0xb3ff },
> > > @@ -1986,7 +1981,7 @@ static const struct mcr_range
> > > mcr_ranges_gen12[] = {
> > > {},
> > > };
> > >
> > > -static const struct mcr_range mcr_ranges_xehp[] = {
> > > +static const struct i915_range mcr_ranges_xehp[] = {
> > > { .start = 0x4000, .end = 0x4aff },
> > > { .start = 0x5200, .end = 0x52ff },
> > > { .start = 0x5400, .end = 0x7fff },
> > > @@ -2004,7 +1999,7 @@ static const struct mcr_range
> > > mcr_ranges_xehp[]
> > > = {
> > >
> > > static bool mcr_range(struct drm_i915_private *i915, u32 offset)
> > > {
> > > - const struct mcr_range *mcr_ranges;
> > > + const struct i915_range *mcr_ranges;
> > > int i;
> > >
> > > if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
> > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > > b/drivers/gpu/drm/i915/intel_uncore.c
> > > index ea910f7ee635..2cfbc16f7dee 100644
> > > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > > @@ -946,101 +946,95 @@ static const struct intel_forcewake_range
> > > __vlv_fw_ranges[] = {
> > > find_fw_domain(uncore, offset)
> > >
> > > /* *Must* be sorted by offset! See intel_shadow_table_check().
> > > */
> > > -static const i915_reg_t gen8_shadowed_regs[] = {
> > > - RING_TAIL(RENDER_RING_BASE),/* 0x2000 (base) */
> > > - GEN6_RPNSWREQ, /* 0xA008 *
> > > - GEN6_RC_VIDEO_FREQ, /* 0xA00C */
> > > - RING_TAIL(GEN6_BSD_RING_BASE), /* 0x12000 (base) */
> > > - RING_TAIL(VEBOX_RING_BASE), /* 0x1a000 (base) */
> > > - RING_TAIL(BLT_RING_BASE), /* 0x22000 (base) */
> > > +static const struct i915_range gen8_shadowed_regs[] = {
> > > + { .start = 0x2030, .end = 0x2030 },
> > > + { .start = 0xA008, .end = 0xA00C },
> > > + { .start = 0x12030, .end = 0x12030 },
> > > + { .start = 0x1a030, .end = 0x1a030 },
> > > + { .start = 0x22030, .end = 0x22030 },
> > You are replacing macro defined values by literal values. These
> > macro
> > defined values are no longer used in this patch, but used in other
> > places such as intel_rps.c:gen6_rps_set(). What plan do you have
> > about
> > the same address is defined in 2 ways, i.e. macro and literal
> > value?
>
> These are ranges of registers offsets (similar to what we already do
> elsewhere in the driver for multicast ranges, forcewake ranges,
> etc.),
> whereas individual registers used throughout the driver are still
> defined in i915_reg.h. Some of these wind up being
[Intel-gfx] [PATCH 2/3] drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List
From: Juston Li
Date: Mon, 9 Aug 2021 12:55:06 -0700
Subject: [Intel-gfx] [PATCH 3/3] drm/i915/hdcp: reuse rx_info for mst stream
type1 capability check
On some MST docking stations, rx_info can only be read after
RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set
otherwise the read will return -EIO.
This behavior causes the mst stream type1 capability test to fail to
read rx_info and determine if the topology supports type1 and fallback
to type0.
To fix this, check for type1 capability when we receive rx_info within
the AKE flow when we read RepeaterAuth_Send_ReceiverID_List instead
of an explicit read just for type1 capability checking.
This does require moving where we set stream_types to after
hdcp2_authenticate_sink() when we get rx_info but this occurs before we
do hdcp2_propagate_stream_management_info.
Also, legacy HDCP 2.0/2.1 are not type 1 capable either so check for
that as well.
Signed-off-by: Juston Li
---
.../drm/i915/display/intel_display_types.h| 2 +
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 39 ---
drivers/gpu/drm/i915/display/intel_hdcp.c | 47 +--
3 files changed, 23 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index dbdfe54d0340..c8b687ff0374 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -516,6 +516,8 @@ struct intel_hdcp {
enum transcoder cpu_transcoder;
/* Only used for DP MST stream encryption */
enum transcoder stream_transcoder;
+
+ bool topology_type1_capable;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 526fd58b9b51..2d39af63ec9b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -478,23 +478,6 @@ int intel_dp_hdcp2_write_msg(struct intel_digital_port
*dig_port,
return size;
}
-static int
-get_rxinfo_hdcp_1_dev_downstream(struct intel_digital_port *dig_port, bool
*hdcp_1_x)
-{
- u8 rx_info[HDCP_2_2_RXINFO_LEN];
- int ret;
-
- ret = drm_dp_dpcd_read(_port->dp.aux,
- DP_HDCP_2_2_REG_RXINFO_OFFSET,
- (void *)rx_info, HDCP_2_2_RXINFO_LEN);
-
- if (ret != HDCP_2_2_RXINFO_LEN)
- return ret >= 0 ? -EIO : ret;
-
- *hdcp_1_x = HDCP_2_2_HDCP1_DEVICE_CONNECTED(rx_info[1]) ? true : false;
- return 0;
-}
-
static
ssize_t get_receiver_id_list_rx_info(struct intel_digital_port *dig_port, u32
*dev_cnt, u8 *byte)
{
@@ -664,27 +647,6 @@ int intel_dp_hdcp2_capable(struct intel_digital_port
*dig_port,
return 0;
}
-static
-int intel_dp_mst_streams_type1_capable(struct intel_connector *connector,
- bool *capable)
-{
- struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- int ret;
- bool hdcp_1_x;
-
- ret = get_rxinfo_hdcp_1_dev_downstream(dig_port, _1_x);
- if (ret) {
- drm_dbg_kms(>drm,
- "[%s:%d] failed to read RxInfo ret=%d\n",
- connector->base.name, connector->base.base.id, ret);
- return ret;
- }
-
- *capable = !hdcp_1_x;
- return 0;
-}
-
static const struct intel_hdcp_shim intel_dp_hdcp_shim = {
.write_an_aksv = intel_dp_hdcp_write_an_aksv,
.read_bksv = intel_dp_hdcp_read_bksv,
@@ -833,7 +795,6 @@ static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim
= {
.stream_2_2_encryption = intel_dp_mst_hdcp2_stream_encryption,
.check_2_2_link = intel_dp_mst_hdcp2_check_link,
.hdcp_2_2_capable = intel_dp_hdcp2_capable,
- .streams_type1_capable = intel_dp_mst_streams_type1_capable,
.protocol = HDCP_PROTOCOL_DP,
};
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index ebc2e32aec0b..fa6a60faa6a7 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -33,21 +33,6 @@ static int intel_conn_to_vcpi(struct intel_connector
*connector)
return connector->port ? connector->port->vcpi.vcpi : 0;
}
-static bool
-intel_streams_type1_capable(struct intel_connector *connector)
-{
- const struct intel_hdcp_shim *shim = connector->hdcp.shim;
- bool capable = false;
-
- if (!shim)
- return capable;
-
- if (shim->streams_type1_capable)
- shim->streams_type1_capable(connector, );
-
- return capable;
-}
-
/*
* intel_hdcp_required_content_stream selects the most highest common possible
HDCP
* content_type for all streams in DP MST topology because security f/w
[Intel-gfx] [PATCH 2/3] drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List
When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by itself
once to retrieve the DEVICE_COUNT to calculate the size of the
ReceiverID list then read a second time as a part of reading ReceiverID
list.
On some MST docking stations, RxInfo can only be read after the RxStatus
READY bit is set otherwise the read will return -EIO. The spec states that
the READY bit should be cleared as soon as RxInfo has been read.
In this case, the first RxInfo read succeeds but after the READY bit is
cleared, the second read fails.
Fix it by reading RxInfo once and storing it before reading the rest of
RepeaterAuth_Send_ReceiverID_List once we know the size.
Modify get_receiver_id_list_size() to read and store RxInfo in the
message buffer and also parse DEVICE_COUNT so we know the size of
RepeaterAuth_Send_ReceiverID_List.
Afterwards, retrieve the rest of the message at the offset for
seq_num_V.
Changes in v4:
- rebase and edit commit message
Changes in v3:
- remove comment
Changes in v2:
- remove unnecessary moving of drm_i915_private from patch 1
Signed-off-by: Juston Li
Acked-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 30 ++--
include/drm/drm_dp_helper.h | 2 +-
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 1d0096654776..526fd58b9b51 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -496,11 +496,10 @@ get_rxinfo_hdcp_1_dev_downstream(struct
intel_digital_port *dig_port, bool *hdcp
}
static
-ssize_t get_receiver_id_list_size(struct intel_digital_port *dig_port)
+ssize_t get_receiver_id_list_rx_info(struct intel_digital_port *dig_port, u32
*dev_cnt, u8 *byte)
{
- u8 rx_info[HDCP_2_2_RXINFO_LEN];
- u32 dev_cnt;
ssize_t ret;
+ u8 *rx_info = byte;
ret = drm_dp_dpcd_read(_port->dp.aux,
DP_HDCP_2_2_REG_RXINFO_OFFSET,
@@ -508,15 +507,11 @@ ssize_t get_receiver_id_list_size(struct
intel_digital_port *dig_port)
if (ret != HDCP_2_2_RXINFO_LEN)
return ret >= 0 ? -EIO : ret;
- dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
+ *dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
HDCP_2_2_DEV_COUNT_LO(rx_info[1]));
- if (dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
- dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
-
- ret = sizeof(struct hdcp2_rep_send_receiverid_list) -
- HDCP_2_2_RECEIVER_IDS_MAX_LEN +
- (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
+ if (*dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT)
+ *dev_cnt = HDCP_2_2_MAX_DEVICE_COUNT;
return ret;
}
@@ -534,6 +529,7 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
const struct hdcp2_dp_msg_data *hdcp2_msg_data;
ktime_t msg_end = ktime_set(0, 0);
bool msg_expired;
+ u32 dev_cnt;
hdcp2_msg_data = get_hdcp2_dp_msg_data(msg_id);
if (!hdcp2_msg_data)
@@ -546,17 +542,21 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
+ /* DP adaptation msgs has no msg_id */
+ byte++;
+
if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
- ret = get_receiver_id_list_size(dig_port);
+ ret = get_receiver_id_list_rx_info(dig_port, _cnt, byte);
if (ret < 0)
return ret;
- size = ret;
+ byte += ret;
+ size = sizeof(struct hdcp2_rep_send_receiverid_list) -
+ HDCP_2_2_RXINFO_LEN - HDCP_2_2_RECEIVER_IDS_MAX_LEN +
+ (dev_cnt * HDCP_2_2_RECEIVER_ID_LEN);
}
- bytes_to_recv = size - 1;
- /* DP adaptation msgs has no msg_id */
- byte++;
+ bytes_to_recv = size - 1;
while (bytes_to_recv) {
len = bytes_to_recv > DP_AUX_MAX_PAYLOAD_BYTES ?
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 3f2715eb965f..7476e7c6d0be 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1413,7 +1413,7 @@ enum drm_dp_phy {
#define DP_HDCP_2_2_LC_INIT_OFFSET DP_HDCP_2_2_REG_RN_OFFSET
#define DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET DP_HDCP_2_2_REG_LPRIME_OFFSET
#define DP_HDCP_2_2_SKE_SEND_EKS_OFFSET
DP_HDCP_2_2_REG_EDKEY_KS_OFFSET
-#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
DP_HDCP_2_2_REG_RXINFO_OFFSET
+#define DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET
DP_HDCP_2_2_REG_SEQ_NUM_V_OFFSET
#define DP_HDCP_2_2_REP_SEND_ACK_OFFSETDP_HDCP_2_2_REG_V_OFFSET
#define DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET DP_HDCP_2_2_REG_SEQ_NUM_M_OFFSET
#define DP_HDCP_2_2_REP_STREAM_READY_OFFSETDP_HDCP_2_2_REG_MPRIME_OFFSET
--
2.31.1
[Intel-gfx] [PATCH 1/3] drm/i915/hdcp: update cp_irq_count_cached in intel_dp_hdcp2_read_msg()
Update cp_irq_count_cached when reading messages rather than when
writing a message to make sure the value is up to date and not
stale from a previously handled CP_IRQ.
AKE flow doesn't always respond to a read with a ACK write msg.
E.g. AKE_Send_Pairing_Info will "timeout" because we received
a CP_IRQ for reading AKE_Send_H_Prime but no write occurred between that
and reading AKE_Send_Pairing_Info so cp_irq_count_cached is stale
causing the wait to return right away rather than waiting for a new
CP_IRQ.
Signed-off-by: Juston Li
Acked-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index d697d169e8c1..1d0096654776 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -446,8 +446,6 @@ static
int intel_dp_hdcp2_write_msg(struct intel_digital_port *dig_port,
void *buf, size_t size)
{
- struct intel_dp *dp = _port->dp;
- struct intel_hdcp *hdcp = >attached_connector->hdcp;
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_write, len;
@@ -463,8 +461,6 @@ int intel_dp_hdcp2_write_msg(struct intel_digital_port
*dig_port,
bytes_to_write = size - 1;
byte++;
- hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
-
while (bytes_to_write) {
len = bytes_to_write > DP_AUX_MAX_PAYLOAD_BYTES ?
DP_AUX_MAX_PAYLOAD_BYTES : bytes_to_write;
@@ -530,6 +526,8 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
u8 msg_id, void *buf, size_t size)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ struct intel_dp *dp = _port->dp;
+ struct intel_hdcp *hdcp = >attached_connector->hdcp;
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_recv, len;
@@ -546,6 +544,8 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
if (ret < 0)
return ret;
+ hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
+
if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {
ret = get_receiver_id_list_size(dig_port);
if (ret < 0)
--
2.31.1
[Intel-gfx] [PATCH 0/3] drm/i915/hdcp: HDCP2.2 MST dock fixes
Fixes to get HDCP2.2 over MST working on MST docking stations with certain behaviors that cause the current flow to fail. Tested with Dell WD-19 and Lenovo ThinkPad USB Type-C Dock Gen 2. These fixes should make the flow more robust to handle behaviors that as far as I can tell are unclear in the HDCP spec: RxInfo contains repeater topology information needed for MST. The behavior on these docks is that this can only be read during RepeaterAuth_Send_ReceiverID_List when the RxStatus READY bit is set otherwise the dock will return NACK. It seems these docks treat reading this range at any other time as invalid when the READY bit isn't set possibly because it could be stale. The HDCP spec also states the READY bit is cleared after RxInfo is read. These fixes address this behavior by only reading RxInfo once during the AKE flow and reusing that data. Juston Li (3): drm/i915/hdcp: update cp_irq_count_cached in intel_dp_hdcp2_read_msg() drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List drm/i915/hdcp: reuse rx_info for mst stream type1 capability check .../drm/i915/display/intel_display_types.h| 2 + drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 77 +-- drivers/gpu/drm/i915/display/intel_hdcp.c | 47 +-- include/drm/drm_dp_helper.h | 2 +- 4 files changed, 43 insertions(+), 85 deletions(-) -- 2.31.1
Re: [Intel-gfx] [PATCH v5 9/9] drm/i915/dg2: Configure PCON in DP pre-enable path
On Thu, 2021-08-05 at 09:36 -0700, Matt Roper wrote: > From: Ankit Nautiyal > > Add the functions to configure HDMI2.1 pcon for DG2, before DP link > training. Reviewed-by: José Roberto de Souza > > Signed-off-by: Ankit Nautiyal > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/display/intel_ddi.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index d8162951b78f..e932fd0fe7e2 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -2402,6 +2402,7 @@ static void dg2_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, crtc_state); > intel_dp_sink_set_decompression_state(intel_dp, crtc_state, true); > /* >* DDI FEC: "anticipates enabling FEC encoding sets the FEC_READY bit > @@ -2409,6 +2410,8 @@ static void dg2_ddi_pre_enable_dp(struct > intel_atomic_state *state, >* training >*/ > intel_dp_sink_set_fec_ready(intel_dp, crtc_state); > + intel_dp_check_frl_training(intel_dp); > + intel_dp_pcon_dsc_configure(intel_dp, crtc_state); > > /* >* 5.h Follow DisplayPort specification training sequence (see notes for
Re: [Intel-gfx] [PATCH 10/46] drm/i915/guc: Take engine PM when a context is pinned with GuC submission
On Tue, Aug 10, 2021 at 08:43:50AM +0200, Daniel Vetter wrote:
> On Mon, Aug 09, 2021 at 06:11:37PM +, Matthew Brost wrote:
> > On Mon, Aug 09, 2021 at 04:23:42PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 03, 2021 at 03:29:07PM -0700, Matthew Brost wrote:
> > > > Taking a PM reference to prevent intel_gt_wait_for_idle from short
> > > > circuiting while a scheduling of user context could be enabled.
> > > >
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > > drivers/gpu/drm/i915/Makefile | 1 +
> > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 36 +--
> > > > 2 files changed, 34 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/Makefile
> > > > b/drivers/gpu/drm/i915/Makefile
> > > > index 903de270f2db..5e3a1e2095b0 100644
> > > > --- a/drivers/gpu/drm/i915/Makefile
> > > > +++ b/drivers/gpu/drm/i915/Makefile
> > > > @@ -103,6 +103,7 @@ gt-y += \
> > > > gt/intel_gt_clock_utils.o \
> > > > gt/intel_gt_irq.o \
> > > > gt/intel_gt_pm.o \
> > > > + gt/intel_gt_pm_unpark_work.o \
> > >
> > > This file isn't here?
> > >
> >
> > Yep, included this in the wrong patch. Should be in:
> > https://patchwork.freedesktop.org/patch/448462/?series=92789=2
> >
> > > Also pm stuff tends to have very nasty locking requirements, doing special
> > > stuff like this in the backend tends to lead to really big surprises. I
> > > think two options to make sure our locking design stays consistent:
> > > - Lift this to generic code.
> >
> > Not sure I'm following this, intel_engine_pm_get/put are generic calls.
> > Those calls should have all the correct annoations. If they don't we can
> > add them.
>
> But you only call them in the GuC backend, not in all of them. Which is an
> inconsistency in locking, and unfortunately runtime pm is extremely nasty,
> so having potentially very divergent locking behind the same interface in
> the same driver is a recipe for an unmaintainable mess.
>
> Iow, if the high-level code runs on execlist or the ringbuffer backend we
> still need to go through at least the lockdep motions of what you're
> adding here.
>
> This is similar in spirit to all the might_sleep/might_lock calls we have
> all over the kernel where in many cases something doesn't happen, but we
> need to make sure it's allowed to have a consistent design.
>
> So essentially in the intel_context_pin and all these functions put a
> intel_engine_pm_might_get (which compiles out without debugging enabled),
> unconditionally, across all platforms and sched backends.
>
Ok, I see your point here. We currently don't have a
intel_engine_pm_might_get but I think this translates to roughly:
might_lock(engine_pm_wf_mutex)
intel_gt_pm_might_get
Will dig in a big a more and add the annotations to the next rev.
Matt
> In general I think backend specific locking (irrespective of what kind of
> backend or interface you implement) is a pretty bad idea in the kernel,
> and needs to be avoided if at all possible. Avoid here means "pull the
> might_lock/might_sleep/might_whatever checks into generic code".
> -Daniel
>
> > Matt
> >
> > > - expose some engine_pm_migt_get/put() calls which do have the right set
> > > of might_lock annoations, and call those in the generic code.
> > >
> > > Imo the worst kernel abstractions are those where all implementations
> > > look the same, except for locking. Unfortunately i915-gem code is full
> > > of this stuff, and we need to stop this by enlisting lockdep to check the
> > > contracts for us.
> > > -Daniel
> > >
> > > > gt/intel_gt_pm_irq.o \
> > > > gt/intel_gt_requests.o \
> > > > gt/intel_gtt.o \
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > index 7fe4d1559a81..c5d9548bfd00 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > @@ -2056,7 +2056,12 @@ static int guc_context_pre_pin(struct
> > > > intel_context *ce,
> > > >
> > > > static int guc_context_pin(struct intel_context *ce, void *vaddr)
> > > > {
> > > > - return __guc_context_pin(ce, ce->engine, vaddr);
> > > > + int ret = __guc_context_pin(ce, ce->engine, vaddr);
> > > > +
> > > > + if (likely(!ret && !intel_context_is_barrier(ce)))
> > > > + intel_engine_pm_get(ce->engine);
> > > > +
> > > > + return ret;
> > > > }
> > > >
> > > > static void guc_context_unpin(struct intel_context *ce)
> > > > @@ -2067,6 +2072,9 @@ static void guc_context_unpin(struct
> > > > intel_context *ce)
> > > >
> > > > unpin_guc_id(guc, ce, true);
> > > > lrc_unpin(ce);
> > > > +
> > > > + if (likely(!intel_context_is_barrier(ce)))
> > > > + intel_engine_pm_put(ce->engine);
> > > > }
> > > >
> > > > static void guc_context_post_unpin(struct
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/doc/rfc: drop lmem uapi section
== Series Details == Series: drm/doc/rfc: drop lmem uapi section URL : https://patchwork.freedesktop.org/series/93553/ State : success == Summary == CI Bug Log - changes from CI_DRM_10465_full -> Patchwork_20793_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20793_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +6 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][2] -> [TIMEOUT][3] ([i915#2369] / [i915#3063] / [i915#3648]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-tglb3/igt@gem_...@unwedge-stress.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-tglb6/igt@gem_...@unwedge-stress.html - shard-snb: NOTRUN -> [FAIL][4] ([i915#3354]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-snb6/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-kbl7/igt@gem_exec_f...@basic-deadline.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-kbl3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@rcs0: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-glk7/igt@gem_exec_fair@basic-n...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-glk9/igt@gem_exec_fair@basic-n...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2842]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][15] -> [SKIP][16] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-snb: NOTRUN -> [SKIP][17] ([fdo#109271]) +507 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_exec_whisper@basic-queues-forked: - shard-glk: [PASS][18] -> [DMESG-WARN][19] ([i915#118] / [i915#95]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-glk1/igt@gem_exec_whis...@basic-queues-forked.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-glk7/igt@gem_exec_whis...@basic-queues-forked.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][20] ([i915#2658]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-apl2/igt@gem_pr...@exhaustion.html - shard-snb: NOTRUN -> [WARN][21] ([i915#2658]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-snb6/igt@gem_pr...@exhaustion.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][22] -> [DMESG-WARN][23] ([i915#1436] / [i915#716]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/shard-skl2/igt@gen9_exec_pa...@allowed-single.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-skl3/igt@gen9_exec_pa...@allowed-single.html * igt@gen9_exec_parse@batch-invalid-length: - shard-tglb: NOTRUN -> [SKIP][24] ([i915#2856]) [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/shard-tglb6/igt@gen9_exec_pa...@batch-invalid-length.html * igt@i915_pm_rpm@basic-rte: - shard-apl: NOTRUN
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Tweaked Wa_14010685332 for all PCHs
Re-reported. -Original Message- From: Gupta, Anshuman Sent: Tuesday, August 10, 2021 8:23 AM To: Vudum, Lakshminarayana Cc: intel-gfx@lists.freedesktop.org Subject: Re: ✗ Fi.CI.BAT: failure for Tweaked Wa_14010685332 for all PCHs On 2021-08-10 at 13:57:29 +, Patchwork wrote: > == Series Details == > > Series: Tweaked Wa_14010685332 for all PCHs > URL : https://patchwork.freedesktop.org/series/93548/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10464 -> Patchwork_20792 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_20792 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20792, 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_20792/index.html > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_20792: > > ### IGT changes ### > > Possible regressions > > * igt@core_hotunplug@unbind-rebind: > - fi-rkl-guc: NOTRUN -> [DMESG-WARN][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/ig > t@core_hotunp...@unbind-rebind.html Hi Lakshmi , Above CI BAT failure is a unrealted failure(not realted to display), it seems related to core power. could you plese create the issue and re-report the result. Thanks, Anshuman Gupta. > > > Known issues > > > Here are the changes found in Patchwork_20792 that come from known issues: > > ### CI changes ### > > Issues hit > > * boot: > - fi-kbl-soraka: [PASS][2] -> [FAIL][3] ([i915#3895]) >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-kbl-soraka/boot.html >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-kbl-soraka > /boot.html > > > > ### IGT changes ### > > Issues hit > > * igt@prime_vgem@basic-userptr: > - fi-rkl-guc: NOTRUN -> [SKIP][4] ([i915#3301]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/ig > t@prime_v...@basic-userptr.html > > * igt@prime_vgem@basic-write: > - fi-rkl-guc: NOTRUN -> [SKIP][5] ([i915#3291]) +2 similar issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/ig > t@prime_v...@basic-write.html > > > Possible fixes > > * igt@i915_pm_rps@basic-api: > - fi-rkl-guc: [DMESG-WARN][6] ([i915#3925]) -> [PASS][7] >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-rkl-guc/igt@i915_pm_...@basic-api.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/ig > t@i915_pm_...@basic-api.html > > > Warnings > > * igt@runner@aborted: > - fi-rkl-guc: [FAIL][8] ([i915#3925]) -> [FAIL][9] ([i915#1602]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-rkl-guc/igt@run...@aborted.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/ig > t@run...@aborted.html > > > [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 > [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291 > [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 > [i915#3895]: https://gitlab.freedesktop.org/drm/intel/issues/3895 > [i915#3925]: https://gitlab.freedesktop.org/drm/intel/issues/3925 > > > Participating hosts (37 -> 34) > -- > > Missing(3): fi-bdw-samus fi-bsw-cyan bat-jsl-1 > > > Build changes > - > > * Linux: CI_DRM_10464 -> Patchwork_20792 > > CI-20190529: 20190529 > CI_DRM_10464: 294a55f328023a4e36f46e5eb6c4859076efd850 @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_6165: df5d05d742275b049f6f3c852a86c4769966b126 @ > https://gitlab.freedesktop.org/drm/igt-gpu-tools.git > Patchwork_20792: 0af364b9489343e7bf0eb498f34d70f67dd7551c @ > git://anongit.freedesktop.org/gfx-ci/linux > > > == Linux commits == > > 0af364b94893 drm/i915: Tweaked Wa_14010685332 for all PCHs > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/index.html
[Intel-gfx] [PATCH 5.13 059/175] drm/i915: fix i915_globals_exit() section mismatch error
From: Randy Dunlap
[ Upstream commit a07296453bf2778952a09b6244a695bf7607babb ]
Fix modpost Section mismatch error in i915_globals_exit().
Since both an __init function and an __exit function can call
i915_globals_exit(), any function that i915_globals_exit() calls
should not be marked as __init or __exit. I.e., it needs to be
available for either of them.
WARNING: modpost: vmlinux.o(.text+0x8b796a): Section mismatch in reference from
the function i915_globals_exit() to the function
.exit.text:__i915_globals_flush()
The function i915_globals_exit() references a function in an exit section.
Often the function __i915_globals_flush() has valid usage outside the exit
section
and the fix is to remove the __exit annotation of __i915_globals_flush.
ERROR: modpost: Section mismatches detected.
Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.
Fixes: 1354d830cb8f ("drm/i915: Call i915_globals_exit() if
pci_register_device() fails")
Signed-off-by: Randy Dunlap
Cc: Jason Ekstrand
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Dave Airlie
Link:
https://patchwork.freedesktop.org/patch/msgid/20210804204147.2070-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/i915/i915_globals.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_globals.c
b/drivers/gpu/drm/i915/i915_globals.c
index e27739a50bee..57d2943884ab 100644
--- a/drivers/gpu/drm/i915/i915_globals.c
+++ b/drivers/gpu/drm/i915/i915_globals.c
@@ -139,7 +139,7 @@ void i915_globals_unpark(void)
atomic_inc();
}
-static void __exit __i915_globals_flush(void)
+static void __i915_globals_flush(void)
{
atomic_inc(); /* skip shrinking */
--
2.30.2
Re: [Intel-gfx] [PATCH 25/46] drm/i915/guc: Update debugfs for GuC multi-lrc
On Tue, Aug 10, 2021 at 11:27:31AM +0200, Daniel Vetter wrote:
> On Tue, Aug 10, 2021 at 11:23:39AM +0200, Daniel Vetter wrote:
> > On Mon, Aug 09, 2021 at 07:13:11PM +, Matthew Brost wrote:
> > > On Mon, Aug 09, 2021 at 06:36:44PM +0200, Daniel Vetter wrote:
> > > > On Tue, Aug 03, 2021 at 03:29:22PM -0700, Matthew Brost wrote:
> > > > > Display the workqueue status in debugfs for GuC contexts that are in
> > > > > parent-child relationship.
> > > > >
> > > > > Signed-off-by: Matthew Brost
> > > > > ---
> > > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 56
> > > > > +--
> > > > > 1 file changed, 39 insertions(+), 17 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > index 30df1c8db491..44a7582c9aed 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > > @@ -4527,31 +4527,53 @@ void intel_guc_submission_print_info(struct
> > > > > intel_guc *guc,
> > > > > gse_log_submission_info(guc->gse[i], p, i);
> > > > > }
> > > > >
> > > > > +static inline void guc_log_context(struct drm_printer *p,
> > > > > +struct intel_context *ce)
> > > > > +{
> > > > > + drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id);
> > > > > + drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
> > > > > + drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
> > > > > +ce->ring->head,
> > > > > +ce->lrc_reg_state[CTX_RING_HEAD]);
> > > > > + drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
> > > > > +ce->ring->tail,
> > > > > +ce->lrc_reg_state[CTX_RING_TAIL]);
> > > > > + drm_printf(p, "\t\tContext Pin Count: %u\n",
> > > > > +atomic_read(>pin_count));
> > > > > + drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
> > > > > +atomic_read(>guc_id_ref));
> > > > > + drm_printf(p, "\t\tNumber Requests Not Ready: %u\n",
> > > > > +atomic_read(>guc_num_rq_not_ready));
> > > > > + drm_printf(p, "\t\tSchedule State: 0x%x, 0x%x\n\n",
> > > > > +ce->guc_state.sched_state,
> > > > > +atomic_read(>guc_sched_state_no_lock));
> > > >
> > > > It's all debugfs, but I think proper locking even there is good. It at
> > > > least reduces the confusion when the locking scheme is largely
> > > > undocumented. Also given how much we have rcu for everything would be
> > > > good
> > > > to double-check all pointer dererences are properly protected.
> > > >
> > >
> > > Not sure if I 100% follow this but I don't think any of the pointers
> > > dref here are RCU protected. Certainly none of the GuC ones are.
> > >
> > > Will double before the next respin though.
> > >
> > > > > +}
> > > > > +
> > > > > void intel_guc_submission_print_context_info(struct intel_guc *guc,
> > > > >struct drm_printer *p)
> > > > > {
> > > > > struct intel_context *ce;
> > > > > unsigned long index;
> > > > > xa_for_each(>context_lookup, index, ce) {
> > > >
> > > > xa_for_each doesn't provide any guarantees, so doesn't protect against
> > > > concurrent removeal or anything like that. We need to do better than
> > > > that.
> > >
> > > https://elixir.bootlin.com/linux/latest/source/include/linux/xarray.h#L498
> > > 'It is safe to modify the array during the iteration.'
> >
> > The xarray. Not the thing you're dereferencing, because the xarray only
> > stores pointers, not your data structure. So yeah correct statement is
> > that it doesn't provide you any guarantees beyond "the iterator wont be
> > confused if the xarray itself is modified during iteration". Which isn't
> > what you need here, you need a lot more.
>
> Or spelled out: The pointer you get could become immediately meaningless,
> before you can look at it, due to a concurrent removal/release. All the
> xa_for_each guarantees you is that on the next round you get the next
> pointer, until you got them all (plus/minus concurrent changes). But that
> next pointer could have become meaningless right away too.
>
> So you need your own locking to make use of these pointers you got and
> make sure they're not immediately meaningless before your loop body even
> started.
>
Ok, I think I see your point. Likely whenever we do a xa_for_each over
>context_lookup we should just grab its lock as if it is in the
xarray we have reference to object looked up. Also everytime we use
xa_for_each on >context_lookup it is a corner case we it is ok to
block anyone else from using this (e.g. during a reset, checking
debugfs, etc...). Does that sound correct?
Matt
> One of the reasons why I think this is so important is that debugfs files
> nest a lot of loops fairly often, so are good
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use locked access to ctx->engines in set_priority
== Series Details ==
Series: drm/i915: Use locked access to ctx->engines in set_priority
URL : https://patchwork.freedesktop.org/series/93558/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10465 -> Patchwork_20794
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/index.html
Known issues
Here are the changes found in Patchwork_20794 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-rkl-guc: NOTRUN -> [SKIP][1] ([i915#3844] / [i915#579])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/fi-rkl-guc/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@workarounds:
- fi-rkl-guc: NOTRUN -> [INCOMPLETE][2] ([i915#3920])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
Possible fixes
* igt@core_hotunplug@unbind-rebind:
- fi-rkl-guc: [DMESG-WARN][3] ([i915#3925]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4: [FAIL][5] ([i915#1888]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
* igt@i915_selftest@live@hangcheck:
- {fi-jsl-1}: [INCOMPLETE][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-rkl-11600: [SKIP][9] -> [PASS][10] +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/fi-rkl-11600/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/fi-rkl-11600/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#3844]: https://gitlab.freedesktop.org/drm/intel/issues/3844
[i915#3920]: https://gitlab.freedesktop.org/drm/intel/issues/3920
[i915#3925]: https://gitlab.freedesktop.org/drm/intel/issues/3925
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
Participating hosts (37 -> 34)
--
Missing(3): fi-bdw-samus fi-bsw-cyan bat-jsl-1
Build changes
-
* Linux: CI_DRM_10465 -> Patchwork_20794
CI-20190529: 20190529
CI_DRM_10465: b183cdc9ca5e84a70c1d9d57ab317319fb6bed65 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6166: 63db0bc86c6321897ef829a5e7c9536a6f062b21 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20794: cc99b1d7369b827a644c1fe30ab082ad7e10dca7 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
cc99b1d7369b drm/i915: Use locked access to ctx->engines in set_priority
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20794/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for Tweaked Wa_14010685332 for all PCHs
== Series Details == Series: Tweaked Wa_14010685332 for all PCHs URL : https://patchwork.freedesktop.org/series/93548/ State : success == Summary == CI Bug Log - changes from CI_DRM_10464 -> Patchwork_20792 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/index.html Known issues Here are the changes found in Patchwork_20792 that come from known issues: ### CI changes ### Issues hit * boot: - fi-kbl-soraka: [PASS][1] -> [FAIL][2] ([i915#3895]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-kbl-soraka/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-kbl-soraka/boot.html ### IGT changes ### Issues hit * igt@core_hotunplug@unbind-rebind: - fi-rkl-guc: NOTRUN -> [DMESG-WARN][3] ([i915#3925]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html * igt@prime_vgem@basic-userptr: - fi-rkl-guc: NOTRUN -> [SKIP][4] ([i915#3301]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@prime_v...@basic-userptr.html * igt@prime_vgem@basic-write: - fi-rkl-guc: NOTRUN -> [SKIP][5] ([i915#3291]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@prime_v...@basic-write.html Possible fixes * igt@i915_pm_rps@basic-api: - fi-rkl-guc: [DMESG-WARN][6] ([i915#3925]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-rkl-guc/igt@i915_pm_...@basic-api.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@i915_pm_...@basic-api.html Warnings * igt@runner@aborted: - fi-rkl-guc: [FAIL][8] ([i915#3925]) -> [FAIL][9] ([i915#1602]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-rkl-guc/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@run...@aborted.html [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291 [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 [i915#3895]: https://gitlab.freedesktop.org/drm/intel/issues/3895 [i915#3925]: https://gitlab.freedesktop.org/drm/intel/issues/3925 Participating hosts (37 -> 34) -- Missing(3): fi-bdw-samus fi-bsw-cyan bat-jsl-1 Build changes - * Linux: CI_DRM_10464 -> Patchwork_20792 CI-20190529: 20190529 CI_DRM_10464: 294a55f328023a4e36f46e5eb6c4859076efd850 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6165: df5d05d742275b049f6f3c852a86c4769966b126 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20792: 0af364b9489343e7bf0eb498f34d70f67dd7551c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0af364b94893 drm/i915: Tweaked Wa_14010685332 for all PCHs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/index.html
Re: [Intel-gfx] [PATCH 1/2] ALSA: hda: Release controller display power during shutdown/reboot
my 7820hk sound card is alc662 android_x86:/ # aplay -l List of PLAYBACK Hardware Devices card 0: PCH [HDA Intel PCH], device 0: ALC662 rev3 Analog [ALC662 rev3 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 10: HDMI 4 [HDMI 4] Subdevices: 1/1 Subdevice #0: subdevice #0 android_x86:/ # 2021-08-10 22:50 GMT+08:00, youling257 : > it cause my intel 7820hk cpu failed shutdown. >
Re: [Intel-gfx] [PATCH 1/2] ALSA: hda: Release controller display power during shutdown/reboot
it cause my intel 7820hk cpu failed shutdown.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Use locked access to ctx->engines in set_priority
== Series Details ==
Series: drm/i915: Use locked access to ctx->engines in set_priority
URL : https://patchwork.freedesktop.org/series/93558/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cc99b1d7369b drm/i915: Use locked access to ctx->engines in set_priority
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 89ff76bf9b3b ("drm/i915/gem:
Utilize rcu iteration of context engines")'
#8:
commit 89ff76bf9b3b0b86e6bbe344bd6378d8661303fc
-:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#17:
ccbc1b97948a ("drm/i915/gem: Don't allow changing the VM on running contexts
(v4)")
-:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit ccbc1b97948a ("drm/i915/gem:
Don't allow changing the VM on running contexts (v4)")'
#17:
ccbc1b97948a ("drm/i915/gem: Don't allow changing the VM on running contexts
(v4)")
-:18: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit c7a71fc8ee04 ("drm/i915: Drop
getparam support for I915_CONTEXT_PARAM_ENGINES")'
#18:
c7a71fc8ee04 ("drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES")
-:19: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 4a766ae40ec8 ("drm/i915: Drop
the CONTEXT_CLONE API (v2)")'
#19:
4a766ae40ec8 ("drm/i915: Drop the CONTEXT_CLONE API (v2)")
-:139: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 4 errors, 2 warnings, 0 checks, 93 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/doc/rfc: drop lmem uapi section
== Series Details ==
Series: drm/doc/rfc: drop lmem uapi section
URL : https://patchwork.freedesktop.org/series/93553/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10465 -> Patchwork_20793
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/index.html
Known issues
Here are the changes found in Patchwork_20793 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-gfx:
- fi-rkl-guc: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html
* igt@i915_pm_rpm@module-reload:
- fi-rkl-guc: NOTRUN -> [SKIP][2] ([i915#3844] / [i915#579])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/fi-rkl-guc/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@core_hotunplug@unbind-rebind:
- fi-rkl-guc: [DMESG-WARN][3] ([i915#3925]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-1115g4: [FAIL][5] ([i915#1888]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
* igt@i915_selftest@live@hangcheck:
- {fi-jsl-1}: [INCOMPLETE][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-rkl-11600: [SKIP][9] -> [PASS][10] +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10465/fi-rkl-11600/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/fi-rkl-11600/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#3844]: https://gitlab.freedesktop.org/drm/intel/issues/3844
[i915#3925]: https://gitlab.freedesktop.org/drm/intel/issues/3925
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
Participating hosts (37 -> 34)
--
Missing(3): fi-bdw-samus fi-bsw-cyan bat-jsl-1
Build changes
-
* Linux: CI_DRM_10465 -> Patchwork_20793
CI-20190529: 20190529
CI_DRM_10465: b183cdc9ca5e84a70c1d9d57ab317319fb6bed65 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6166: 63db0bc86c6321897ef829a5e7c9536a6f062b21 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20793: 9b42c1263b1cd77017886f6162c35a77602b9152 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9b42c1263b1c drm/doc/rfc: drop lmem uapi section
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20793/index.html
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Tweaked Wa_14010685332 for all PCHs
On 2021-08-10 at 13:57:29 +, Patchwork wrote: > == Series Details == > > Series: Tweaked Wa_14010685332 for all PCHs > URL : https://patchwork.freedesktop.org/series/93548/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_10464 -> Patchwork_20792 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_20792 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_20792, 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_20792/index.html > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_20792: > > ### IGT changes ### > > Possible regressions > > * igt@core_hotunplug@unbind-rebind: > - fi-rkl-guc: NOTRUN -> [DMESG-WARN][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html Hi Lakshmi , Above CI BAT failure is a unrealted failure(not realted to display), it seems related to core power. could you plese create the issue and re-report the result. Thanks, Anshuman Gupta. > > > Known issues > > > Here are the changes found in Patchwork_20792 that come from known issues: > > ### CI changes ### > > Issues hit > > * boot: > - fi-kbl-soraka: [PASS][2] -> [FAIL][3] ([i915#3895]) >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-kbl-soraka/boot.html >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-kbl-soraka/boot.html > > > > ### IGT changes ### > > Issues hit > > * igt@prime_vgem@basic-userptr: > - fi-rkl-guc: NOTRUN -> [SKIP][4] ([i915#3301]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@prime_v...@basic-userptr.html > > * igt@prime_vgem@basic-write: > - fi-rkl-guc: NOTRUN -> [SKIP][5] ([i915#3291]) +2 similar issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@prime_v...@basic-write.html > > > Possible fixes > > * igt@i915_pm_rps@basic-api: > - fi-rkl-guc: [DMESG-WARN][6] ([i915#3925]) -> [PASS][7] >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-rkl-guc/igt@i915_pm_...@basic-api.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@i915_pm_...@basic-api.html > > > Warnings > > * igt@runner@aborted: > - fi-rkl-guc: [FAIL][8] ([i915#3925]) -> [FAIL][9] ([i915#1602]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-rkl-guc/igt@run...@aborted.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@run...@aborted.html > > > [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 > [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291 > [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 > [i915#3895]: https://gitlab.freedesktop.org/drm/intel/issues/3895 > [i915#3925]: https://gitlab.freedesktop.org/drm/intel/issues/3925 > > > Participating hosts (37 -> 34) > -- > > Missing(3): fi-bdw-samus fi-bsw-cyan bat-jsl-1 > > > Build changes > - > > * Linux: CI_DRM_10464 -> Patchwork_20792 > > CI-20190529: 20190529 > CI_DRM_10464: 294a55f328023a4e36f46e5eb6c4859076efd850 @ > git://anongit.freedesktop.org/gfx-ci/linux > IGT_6165: df5d05d742275b049f6f3c852a86c4769966b126 @ > https://gitlab.freedesktop.org/drm/igt-gpu-tools.git > Patchwork_20792: 0af364b9489343e7bf0eb498f34d70f67dd7551c @ > git://anongit.freedesktop.org/gfx-ci/linux > > > == Linux commits == > > 0af364b94893 drm/i915: Tweaked Wa_14010685332 for all PCHs > > == Logs == > > For more details see: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/index.html
[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/doc/rfc: drop lmem uapi section
== Series Details == Series: drm/doc/rfc: drop lmem uapi section URL : https://patchwork.freedesktop.org/series/93553/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 /home/cidrm/kernel/Documentation/gpu/rfc/i915_gem_lmem.rst:21: WARNING: Unknown target name: "i915 mmap". /home/cidrm/kernel/Documentation/gpu/rfc/i915_gem_lmem.rst:22: WARNING: Unknown target name: "i915 set/get caching".
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/doc/rfc: drop lmem uapi section
== Series Details ==
Series: drm/doc/rfc: drop lmem uapi section
URL : https://patchwork.freedesktop.org/series/93553/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9b42c1263b1c drm/doc/rfc: drop lmem uapi section
-:13: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 727ecd99a4c9 ("drm/doc/rfc: drop
the i915_gem_lmem.h header")'
#13:
uapi definitions to the real include/uapi/ folder in 727ecd99a4c9
-:137: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 3 lines checked
Re: [Intel-gfx] [PATCH v2] fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
On Tue, Aug 10, 2021 at 10:49 PM Alex Deucher wrote:
>
> On Tue, Aug 10, 2021 at 4:36 AM Imre Deak wrote:
> >
> > Hi Kai-Heng, Alex,
> >
> > could you add your ack if the fix looks ok and you're ok if I push it to
> > the i915 tree?
> >
>
> Acked-by: Alex Deucher
Acked-by: Kai-Heng Feng
>
> > Thanks,
> > Imre
> >
> > On Mon, Aug 09, 2021 at 04:31:46PM +0300, Imre Deak wrote:
> > > Atm the EFI FB platform driver gets a runtime PM reference for the
> > > associated GFX PCI device during probing the EFI FB platform device and
> > > releases it only when the platform device gets unbound.
> > >
> > > When fbcon switches to the FB provided by the PCI device's driver (for
> > > instance i915/drmfb), the EFI FB will get only unregistered without the
> > > EFI FB platform device getting unbound, keeping the runtime PM reference
> > > acquired during the platform device probing. This reference will prevent
> > > the PCI driver from runtime suspending the device.
> > >
> > > Fix this by releasing the RPM reference from the EFI FB's destroy hook,
> > > called when the FB gets unregistered.
> > >
> > > While at it assert that pm_runtime_get_sync() didn't fail.
> > >
> > > v2:
> > > - Move pm_runtime_get_sync() before register_framebuffer() to avoid its
> > > race wrt. efifb_destroy()->pm_runtime_put(). (Daniel)
> > > - Assert that pm_runtime_get_sync() didn't fail.
> > > - Clarify commit message wrt. platform/PCI device/driver and driver
> > > removal vs. device unbinding.
> > >
> > > Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at
> > > PCI D0")
> > > Cc: Kai-Heng Feng
> > > Cc: Daniel Vetter
> > > Reviewed-by: Daniel Vetter (v1)
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/video/fbdev/efifb.c | 21 ++---
> > > 1 file changed, 14 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> > > index 8ea8f079cde26..edca3703b9640 100644
> > > --- a/drivers/video/fbdev/efifb.c
> > > +++ b/drivers/video/fbdev/efifb.c
> > > @@ -47,6 +47,8 @@ static bool use_bgrt = true;
> > > static bool request_mem_succeeded = false;
> > > static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
> > >
> > > +static struct pci_dev *efifb_pci_dev;/* dev with BAR covering
> > > the efifb */
> > > +
> > > static struct fb_var_screeninfo efifb_defined = {
> > > .activate = FB_ACTIVATE_NOW,
> > > .height = -1,
> > > @@ -243,6 +245,9 @@ static inline void efifb_show_boot_graphics(struct
> > > fb_info *info) {}
> > >
> > > static void efifb_destroy(struct fb_info *info)
> > > {
> > > + if (efifb_pci_dev)
> > > + pm_runtime_put(_pci_dev->dev);
> > > +
> > > if (info->screen_base) {
> > > if (mem_flags & (EFI_MEMORY_UC | EFI_MEMORY_WC))
> > > iounmap(info->screen_base);
> > > @@ -333,7 +338,6 @@ ATTRIBUTE_GROUPS(efifb);
> > >
> > > static bool pci_dev_disabled;/* FB base matches BAR of a
> > > disabled device */
> > >
> > > -static struct pci_dev *efifb_pci_dev;/* dev with BAR covering
> > > the efifb */
> > > static struct resource *bar_resource;
> > > static u64 bar_offset;
> > >
> > > @@ -569,17 +573,22 @@ static int efifb_probe(struct platform_device *dev)
> > > pr_err("efifb: cannot allocate colormap\n");
> > > goto err_groups;
> > > }
> > > +
> > > + if (efifb_pci_dev)
> > > + WARN_ON(pm_runtime_get_sync(_pci_dev->dev) < 0);
> > > +
> > > err = register_framebuffer(info);
> > > if (err < 0) {
> > > pr_err("efifb: cannot register framebuffer\n");
> > > - goto err_fb_dealoc;
> > > + goto err_put_rpm_ref;
> > > }
> > > fb_info(info, "%s frame buffer device\n", info->fix.id);
> > > - if (efifb_pci_dev)
> > > - pm_runtime_get_sync(_pci_dev->dev);
> > > return 0;
> > >
> > > -err_fb_dealoc:
> > > +err_put_rpm_ref:
> > > + if (efifb_pci_dev)
> > > + pm_runtime_put(_pci_dev->dev);
> > > +
> > > fb_dealloc_cmap(>cmap);
> > > err_groups:
> > > sysfs_remove_groups(>dev.kobj, efifb_groups);
> > > @@ -603,8 +612,6 @@ static int efifb_remove(struct platform_device *pdev)
> > > unregister_framebuffer(info);
> > > sysfs_remove_groups(>dev.kobj, efifb_groups);
> > > framebuffer_release(info);
> > > - if (efifb_pci_dev)
> > > - pm_runtime_put(_pci_dev->dev);
> > >
> > > return 0;
> > > }
> > > --
> > > 2.27.0
> > >
Re: [Intel-gfx] [PATCH v2] fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
On Tue, Aug 10, 2021 at 4:36 AM Imre Deak wrote:
>
> Hi Kai-Heng, Alex,
>
> could you add your ack if the fix looks ok and you're ok if I push it to
> the i915 tree?
>
Acked-by: Alex Deucher
> Thanks,
> Imre
>
> On Mon, Aug 09, 2021 at 04:31:46PM +0300, Imre Deak wrote:
> > Atm the EFI FB platform driver gets a runtime PM reference for the
> > associated GFX PCI device during probing the EFI FB platform device and
> > releases it only when the platform device gets unbound.
> >
> > When fbcon switches to the FB provided by the PCI device's driver (for
> > instance i915/drmfb), the EFI FB will get only unregistered without the
> > EFI FB platform device getting unbound, keeping the runtime PM reference
> > acquired during the platform device probing. This reference will prevent
> > the PCI driver from runtime suspending the device.
> >
> > Fix this by releasing the RPM reference from the EFI FB's destroy hook,
> > called when the FB gets unregistered.
> >
> > While at it assert that pm_runtime_get_sync() didn't fail.
> >
> > v2:
> > - Move pm_runtime_get_sync() before register_framebuffer() to avoid its
> > race wrt. efifb_destroy()->pm_runtime_put(). (Daniel)
> > - Assert that pm_runtime_get_sync() didn't fail.
> > - Clarify commit message wrt. platform/PCI device/driver and driver
> > removal vs. device unbinding.
> >
> > Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI
> > D0")
> > Cc: Kai-Heng Feng
> > Cc: Daniel Vetter
> > Reviewed-by: Daniel Vetter (v1)
> > Signed-off-by: Imre Deak
> > ---
> > drivers/video/fbdev/efifb.c | 21 ++---
> > 1 file changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> > index 8ea8f079cde26..edca3703b9640 100644
> > --- a/drivers/video/fbdev/efifb.c
> > +++ b/drivers/video/fbdev/efifb.c
> > @@ -47,6 +47,8 @@ static bool use_bgrt = true;
> > static bool request_mem_succeeded = false;
> > static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
> >
> > +static struct pci_dev *efifb_pci_dev;/* dev with BAR covering the
> > efifb */
> > +
> > static struct fb_var_screeninfo efifb_defined = {
> > .activate = FB_ACTIVATE_NOW,
> > .height = -1,
> > @@ -243,6 +245,9 @@ static inline void efifb_show_boot_graphics(struct
> > fb_info *info) {}
> >
> > static void efifb_destroy(struct fb_info *info)
> > {
> > + if (efifb_pci_dev)
> > + pm_runtime_put(_pci_dev->dev);
> > +
> > if (info->screen_base) {
> > if (mem_flags & (EFI_MEMORY_UC | EFI_MEMORY_WC))
> > iounmap(info->screen_base);
> > @@ -333,7 +338,6 @@ ATTRIBUTE_GROUPS(efifb);
> >
> > static bool pci_dev_disabled;/* FB base matches BAR of a disabled
> > device */
> >
> > -static struct pci_dev *efifb_pci_dev;/* dev with BAR covering the
> > efifb */
> > static struct resource *bar_resource;
> > static u64 bar_offset;
> >
> > @@ -569,17 +573,22 @@ static int efifb_probe(struct platform_device *dev)
> > pr_err("efifb: cannot allocate colormap\n");
> > goto err_groups;
> > }
> > +
> > + if (efifb_pci_dev)
> > + WARN_ON(pm_runtime_get_sync(_pci_dev->dev) < 0);
> > +
> > err = register_framebuffer(info);
> > if (err < 0) {
> > pr_err("efifb: cannot register framebuffer\n");
> > - goto err_fb_dealoc;
> > + goto err_put_rpm_ref;
> > }
> > fb_info(info, "%s frame buffer device\n", info->fix.id);
> > - if (efifb_pci_dev)
> > - pm_runtime_get_sync(_pci_dev->dev);
> > return 0;
> >
> > -err_fb_dealoc:
> > +err_put_rpm_ref:
> > + if (efifb_pci_dev)
> > + pm_runtime_put(_pci_dev->dev);
> > +
> > fb_dealloc_cmap(>cmap);
> > err_groups:
> > sysfs_remove_groups(>dev.kobj, efifb_groups);
> > @@ -603,8 +612,6 @@ static int efifb_remove(struct platform_device *pdev)
> > unregister_framebuffer(info);
> > sysfs_remove_groups(>dev.kobj, efifb_groups);
> > framebuffer_release(info);
> > - if (efifb_pci_dev)
> > - pm_runtime_put(_pci_dev->dev);
> >
> > return 0;
> > }
> > --
> > 2.27.0
> >
Re: [Intel-gfx] [PATCH] drm/doc/rfc: drop lmem uapi section
Acked-by: Jason Ekstrand
On Tue, Aug 10, 2021 at 7:34 AM Daniel Vetter wrote:
>
> We still have quite a bit more work to do with overall reworking of
> the ttm-based dg1 code, but the uapi stuff is now finalized with the
> latest pull. So remove that.
>
> This also fixes kerneldoc build warnings because we've included the
> same headers in two places, resulting in sphinx complaining about
> duplicated symbols. This regression has been created when we moved the
> uapi definitions to the real include/uapi/ folder in 727ecd99a4c9
> ("drm/doc/rfc: drop the i915_gem_lmem.h header")
>
> Reported-by: Stephen Rothwell
> Cc: Stephen Rothwell
> Fixes: 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header")
> Cc: Matthew Auld
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/rfc/i915_gem_lmem.rst | 107
> 1 file changed, 107 deletions(-)
>
> diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst
> b/Documentation/gpu/rfc/i915_gem_lmem.rst
> index 675ba8620d66..91be041e68cc 100644
> --- a/Documentation/gpu/rfc/i915_gem_lmem.rst
> +++ b/Documentation/gpu/rfc/i915_gem_lmem.rst
> @@ -22,110 +22,3 @@ real, with all the uAPI bits is:
> * SET/GET ioctl caching(see `I915 SET/GET CACHING`_)
> * Send RFC(with mesa-dev on cc) for final sign off on the uAPI
> * Add pciid for DG1 and turn on uAPI for real
> -
> -New object placement and region query uAPI
> -==
> -Starting from DG1 we need to give userspace the ability to allocate buffers
> from
> -device local-memory. Currently the driver supports gem_create, which can
> place
> -buffers in system memory via shmem, and the usual assortment of other
> -interfaces, like dumb buffers and userptr.
> -
> -To support this new capability, while also providing a uAPI which will work
> -beyond just DG1, we propose to offer three new bits of uAPI:
> -
> -DRM_I915_QUERY_MEMORY_REGIONS
> --
> -New query ID which allows userspace to discover the list of supported memory
> -regions(like system-memory and local-memory) for a given device. We identify
> -each region with a class and instance pair, which should be unique. The class
> -here would be DEVICE or SYSTEM, and the instance would be zero, on platforms
> -like DG1.
> -
> -Side note: The class/instance design is borrowed from our existing engine
> uAPI,
> -where we describe every physical engine in terms of its class, and the
> -particular instance, since we can have more than one per class.
> -
> -In the future we also want to expose more information which can further
> -describe the capabilities of a region.
> -
> -.. kernel-doc:: include/uapi/drm/i915_drm.h
> -:functions: drm_i915_gem_memory_class
> drm_i915_gem_memory_class_instance drm_i915_memory_region_info
> drm_i915_query_memory_regions
> -
> -GEM_CREATE_EXT
> ---
> -New ioctl which is basically just gem_create but now allows userspace to
> provide
> -a chain of possible extensions. Note that if we don't provide any extensions
> and
> -set flags=0 then we get the exact same behaviour as gem_create.
> -
> -Side note: We also need to support PXP[1] in the near future, which is also
> -applicable to integrated platforms, and adds its own gem_create_ext
> extension,
> -which basically lets userspace mark a buffer as "protected".
> -
> -.. kernel-doc:: include/uapi/drm/i915_drm.h
> -:functions: drm_i915_gem_create_ext
> -
> -I915_GEM_CREATE_EXT_MEMORY_REGIONS
> ---
> -Implemented as an extension for gem_create_ext, we would now allow userspace
> to
> -optionally provide an immutable list of preferred placements at creation
> time,
> -in priority order, for a given buffer object. For the placements we expect
> -them each to use the class/instance encoding, as per the output of the
> regions
> -query. Having the list in priority order will be useful in the future when
> -placing an object, say during eviction.
> -
> -.. kernel-doc:: include/uapi/drm/i915_drm.h
> -:functions: drm_i915_gem_create_ext_memory_regions
> -
> -One fair criticism here is that this seems a little over-engineered[2]. If we
> -just consider DG1 then yes, a simple gem_create.flags or something is totally
> -all that's needed to tell the kernel to allocate the buffer in local-memory
> or
> -whatever. However looking to the future we need uAPI which can also support
> -upcoming Xe HP multi-tile architecture in a sane way, where there can be
> -multiple local-memory instances for a given device, and so using both class
> and
> -instance in our uAPI to describe regions is desirable, although specifically
> -for DG1 it's uninteresting, since we only have a single local-memory
> instance.
> -
> -Existing uAPI issues
> -
> -Some potential issues we still need to resolve.
> -
> -I915 MMAP
> --
> -In i915 there are multiple ways to MMAP GEM object, including mapping the
> same
> -object using
[Intel-gfx] ✗ Fi.CI.BAT: failure for Tweaked Wa_14010685332 for all PCHs
== Series Details == Series: Tweaked Wa_14010685332 for all PCHs URL : https://patchwork.freedesktop.org/series/93548/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10464 -> Patchwork_20792 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20792 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20792, 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_20792/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20792: ### IGT changes ### Possible regressions * igt@core_hotunplug@unbind-rebind: - fi-rkl-guc: NOTRUN -> [DMESG-WARN][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html Known issues Here are the changes found in Patchwork_20792 that come from known issues: ### CI changes ### Issues hit * boot: - fi-kbl-soraka: [PASS][2] -> [FAIL][3] ([i915#3895]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-kbl-soraka/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-kbl-soraka/boot.html ### IGT changes ### Issues hit * igt@prime_vgem@basic-userptr: - fi-rkl-guc: NOTRUN -> [SKIP][4] ([i915#3301]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@prime_v...@basic-userptr.html * igt@prime_vgem@basic-write: - fi-rkl-guc: NOTRUN -> [SKIP][5] ([i915#3291]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@prime_v...@basic-write.html Possible fixes * igt@i915_pm_rps@basic-api: - fi-rkl-guc: [DMESG-WARN][6] ([i915#3925]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-rkl-guc/igt@i915_pm_...@basic-api.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@i915_pm_...@basic-api.html Warnings * igt@runner@aborted: - fi-rkl-guc: [FAIL][8] ([i915#3925]) -> [FAIL][9] ([i915#1602]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-rkl-guc/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/fi-rkl-guc/igt@run...@aborted.html [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291 [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 [i915#3895]: https://gitlab.freedesktop.org/drm/intel/issues/3895 [i915#3925]: https://gitlab.freedesktop.org/drm/intel/issues/3925 Participating hosts (37 -> 34) -- Missing(3): fi-bdw-samus fi-bsw-cyan bat-jsl-1 Build changes - * Linux: CI_DRM_10464 -> Patchwork_20792 CI-20190529: 20190529 CI_DRM_10464: 294a55f328023a4e36f46e5eb6c4859076efd850 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6165: df5d05d742275b049f6f3c852a86c4769966b126 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20792: 0af364b9489343e7bf0eb498f34d70f67dd7551c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0af364b94893 drm/i915: Tweaked Wa_14010685332 for all PCHs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20792/index.html
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Make workaround upper bounds exclusive
On Tue, 2021-08-10 at 15:58 +0300, Jani Nikula wrote:
> On Mon, 19 Jul 2021, "Souza, Jose" wrote:
> > On Fri, 2021-07-16 at 22:14 -0700, Matt Roper wrote:
> > > Workarounds are documented in the bspec with an exclusive upper
> > > bound
> > > (i.e., a "fixed" stepping that no longer needs the workaround).
> > > This
> > > makes our driver's use of an inclusive upper bound for stepping
> > > ranges
> > > confusing; the differing notation between code and bspec makes it
> > > very
> > > easy for mistakes to creep in.
> > >
> > > Let's switch the upper bound of our IS_{GT,DISP}_STEP macros over
> > > to use
> > > an exclusive upper bound like the bspec does. This also has the
> > > benefit
> > > of helping make sure workarounds are properly handled for new
> > > minor
> > > steppings that show up (e.g., an A1 between the A0 and B0 we
> > > already
> > > knew about) --- if the new intermediate stepping pulls in
> > > hardware fixes
> > > early, there will be an update to the workaround definition which
> > > lets
> > > us know we need to change our code. If the new stepping does not
> > > pull a
> > > hardware fix earlier, then the new stepping will already be
> > > captured
> > > properly by the "[begin, fix)" range in the code.
> > >
> > > We'll probably need to be extra vigilant in code review of new
> > > workarounds for the near future to make sure developers notice
> > > the new
> > > semantics of workaround bounds. But we just migrated a bunch of
> > > our
> > > platforms from the IS_REVID bounds over to IS_{GT,DISP}_STEP, so
> > > people
> > > are already adjusting to the new macros and now is a good time to
> > > make
> > > this change too.
> > >
> > > Signed-off-by: Matt Roper
>
> It's been merged already, but I think this is a good example of a
> patch
> where simple review is just not enough. Needs maintainers in Cc and
> acks
> on top.
I agree. But I like the approach of getting this aligned with all other
internal tools we have to track w/a.
late-acked-by me...
>
> BR,
> Jani.
>
>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
> > > .../drm/i915/display/intel_display_power.c | 8 +++---
> > > drivers/gpu/drm/i915/display/intel_psr.c | 18 ++--
> > > .../drm/i915/display/skl_universal_plane.c | 8 +++---
> > > drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
> > > drivers/gpu/drm/i915/gt/intel_region_lmem.c | 2 +-
> > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 28 +
> > > --
> > > drivers/gpu/drm/i915/i915_drv.h | 4 +--
> > > drivers/gpu/drm/i915/intel_device_info.c | 2 +-
> > > drivers/gpu/drm/i915/intel_pm.c | 8 +++---
> > > 10 files changed, 41 insertions(+), 41 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index 71067a62264d..944fb13b9d98 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -2879,7 +2879,7 @@ void intel_init_cdclk_hooks(struct
> > > drm_i915_private *dev_priv)
> > > dev_priv->display.modeset_calc_cdclk =
> > > bxt_modeset_calc_cdclk;
> > > dev_priv->display.calc_voltage_level =
> > > tgl_calc_voltage_level;
> > > /* Wa_22011320316:adl-p[a0] */
> > > - if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0,
> > > STEP_A0))
> > > + if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0,
> > > STEP_B0))
> > > dev_priv->cdclk.table =
> > > adlp_a_step_cdclk_table;
> > > else
> > > dev_priv->cdclk.table = adlp_cdclk_table;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > index e3aaf9678b07..bec380e58f40 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > @@ -5799,10 +5799,10 @@ static void tgl_bw_buddy_init(struct
> > > drm_i915_private *dev_priv)
> > > int config, i;
> > >
> > > if (IS_ALDERLAKE_S(dev_priv) ||
> > > - IS_DG1_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
> > > - IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
> > > - IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> > > - /* Wa_1409767108:tgl,rkl,dg1,adl-s */
> > > + IS_DG1_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> > > + IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> > > + IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0))
> > > + /* Wa_1409767108:tgl,dg1,adl-s */
> > > table = wa_1409767108_buddy_page_masks;
> > > else
> > > table = tgl_buddy_page_masks;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index
Re: [Intel-gfx] [PULL] gvt-fixes
On Tue, Aug 10, 2021 at 01:01:33PM +0800, Zhenyu Wang wrote: > > Hi, > > Here's one regression fix for windows VM hang issue on recent drivers. > > Thanks > -- > The following changes since commit c90b4503ccf42d9d367e843c223df44aa550e82a: > > drm/i915/gvt: Clear d3_entered on elsp cmd submission. (2021-07-08 16:42:34 > +0800) > > are available in the Git repository at: > > https://github.com/intel/gvt-linux tags/gvt-fixes-2021-08-10 > > for you to fetch changes up to 699aa57b35672c3b2f230e2b7e5d0ab8c2bde80a: > > drm/i915/gvt: Fix cached atomics setting for Windows VM (2021-08-09 > 14:42:09 +0800) pulled, thanks > > > gvt-fixes-2021-08-10 > > - Fix windows VM hang issue for atomics workaround (Zhenyu) > > > Zhenyu Wang (1): > drm/i915/gvt: Fix cached atomics setting for Windows VM > > drivers/gpu/drm/i915/gvt/handlers.c | 1 + > drivers/gpu/drm/i915/gvt/mmio_context.c | 2 ++ > 2 files changed, 3 insertions(+)
[Intel-gfx] [PULL] drm-intel-next
Hi Dave & Daniel - drm-intel-next-2021-08-10-1: drm/i915 changes for v5.15: Features: - Basic DG2 platform enabling (Matt, Animesh, Gwan-gyeong, José) - Add PSF GV point support for display bandwidth calculation (Stan) - Add platform release id version support (Lucas) - Add support for forcing DSC BPP for testing (Vandita, Patnana) Refactoring and cleanups: - Remove CNL support completely (Lucas) - Revid/stepping cleanup (Matt, Anusha) - Make display stepping check upper bounds exclusive (Matt) - Remove old GEN macros (Lucas) - Refactor DG1 interrupt handler (Paulo) - Refactor DMC stepping info (Anusha) Fixes: - Fix XELPD color capability reporting; it's not yet enabled (Uma) - Fix DG1 memory bandwidth computation (Clint) - Fix mux on certain HP laptops (Kai-Heng) - Various display workarounds (José, Matt, Imre) - Fix error state dumps wrt SFC_DONE (Matt) - Fix DG1 and XEPLD audio power domains (Anshuman) - Fix ADL-P and ADL-S ddi buf translation tables (Matt) - Fix DP/HDMI modeset sequences causing issues on ADL-P (José) - PSR2 fixes (José) - Fix DP MST modeset with FEC on TGL+ - Fix MBUS DBOX A credits on ADL-P (José) - Fix DP PHY test training set programming (Khaled) - Fix dgfx pcode uncore init done wait (Badal) - Fix DSC disable fuse check on GLK (Lucas) - Fix shared dpll mismatch for bigjoiner secondary pipe (Manasi) - Fix ADL-P underrun recovery (Matt) - Fix permissions on FEC support debugfs file (Vandita) Misc: - Backmerge drm-next (Rodrigo) - Bump RKL and TGL DMC firmware version (Anusha) BR, Jani. The following changes since commit e73f0f0ee7541171d89f2e2491130c7771ba58d3: Linux 5.14-rc1 (2021-07-11 15:07:40 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2021-08-10-1 for you to fetch changes up to 3bfa7d40ce736ffbbfe07127061f54b359ee2b12: drm/i915/dg2: Add support for new DG2-G11 revid 0x5 (2021-08-06 09:03:10 -0700) drm/i915 changes for v5.15: Features: - Basic DG2 platform enabling (Matt, Animesh, Gwan-gyeong, José) - Add PSF GV point support for display bandwidth calculation (Stan) - Add platform release id version support (Lucas) - Add support for forcing DSC BPP for testing (Vandita, Patnana) Refactoring and cleanups: - Remove CNL support completely (Lucas) - Revid/stepping cleanup (Matt, Anusha) - Make display stepping check upper bounds exclusive (Matt) - Remove old GEN macros (Lucas) - Refactor DG1 interrupt handler (Paulo) - Refactor DMC stepping info (Anusha) Fixes: - Fix XELPD color capability reporting; it's not yet enabled (Uma) - Fix DG1 memory bandwidth computation (Clint) - Fix mux on certain HP laptops (Kai-Heng) - Various display workarounds (José, Matt, Imre) - Fix error state dumps wrt SFC_DONE (Matt) - Fix DG1 and XEPLD audio power domains (Anshuman) - Fix ADL-P and ADL-S ddi buf translation tables (Matt) - Fix DP/HDMI modeset sequences causing issues on ADL-P (José) - PSR2 fixes (José) - Fix DP MST modeset with FEC on TGL+ - Fix MBUS DBOX A credits on ADL-P (José) - Fix DP PHY test training set programming (Khaled) - Fix dgfx pcode uncore init done wait (Badal) - Fix DSC disable fuse check on GLK (Lucas) - Fix shared dpll mismatch for bigjoiner secondary pipe (Manasi) - Fix ADL-P underrun recovery (Matt) - Fix permissions on FEC support debugfs file (Vandita) Misc: - Backmerge drm-next (Rodrigo) - Bump RKL and TGL DMC firmware version (Anusha) Animesh Manna (1): drm/i915/dg2: Update to bigjoiner path Anshuman Gupta (2): drm/i915/debugfs: DISPLAY_VER 13 lpsp capability drm/i915/dg1: Adjust the AUDIO power domain Anusha Srivatsa (5): drm/i915/step: s/_revid_tbl/_revids drm/i915/step: Add macro magic for handling steps drm/i915/dmc: Change intel_get_stepping_info() drm/i915/firmware: Update to DMC v2.12 on TGL drm/i915/firmware: Update to DMC v2.03 on RKL Badal Nilawar (1): drm/i915: dgfx cards need to wait on pcode's uncore init done Clint Taylor (1): drm/i915/dg1: Compute MEM Bandwidth using MCHBAR Gwan-gyeong Mun (1): drm/i915/dg2: Update lane disable power state during PSR Imre Deak (2): drm/i915/adlp: Add workaround to disable CMTG clock gating drm/i915: Apply CMTG clock disabling WA while DPLL0 is enabled Jani Nikula (1): drm/i915/plane: add intel_plane_helper_add() helper José Roberto de Souza (10): drm/i915/display: Settle on "adl-x" in WA comments drm/i915: Limit Wa_22010178259 to affected platforms drm/i915/display/xelpd: Extend Wa_14011508470 drm/i915/display/adl_p: Implement PSR changes drm/i915/display: Disable FBC when PSR2 is enabled display 12 and newer drm/i915/dg2: Add DG2 to the PSR2 defeature list drm/i915/display/psr2: Mark as updated all planes that intersect with pipe_clip drm/i915/display/psr2:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Tweaked Wa_14010685332 for all PCHs
== Series Details == Series: Tweaked Wa_14010685332 for all PCHs URL : https://patchwork.freedesktop.org/series/93548/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0af364b94893 drm/i915: Tweaked Wa_14010685332 for all PCHs -:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #7: despite Wa_14010685332 original sequence, thus blocks entry to deeper s0ix state. total: 0 errors, 1 warnings, 0 checks, 73 lines checked
Re: [Intel-gfx] [PATCH] drm/i915/display: Fix shared dpll mismatch for bigjoiner slave
On Wed, 14 Jul 2021, Manasi Navare wrote: > Currently when we do the HW state readout, we dont set the shared dpll to NULL > for the bigjoiner slave which should not have a DPLL assigned. So it has > some garbage while the HW state readout is NULL. So explicitly reset > the shared dpll for bigjoiner slave pipe. > > Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/3465 > Cc: Ville Syrjälä > Cc: Ankit Nautiyal > Tested-By: Swati Sharma > Signed-off-by: Manasi Navare > --- > drivers/gpu/drm/i915/display/intel_display.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 65ddb6ca16e6..c274bfb8e549 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -9006,6 +9006,10 @@ verify_crtc_state(struct intel_crtc *crtc, > if (!new_crtc_state->hw.active) > return; > > + if (new_crtc_state->bigjoiner_slave) > + /* No PLLs set for slave */ > + pipe_config->shared_dpll = NULL; > + I know it's been merged already, but feels wrong to have this in verify_crtc_state(). Kind of out of place. BR, Jani. > intel_pipe_config_sanity_check(dev_priv, pipe_config); > > if (!intel_pipe_config_compare(new_crtc_state, -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH] drm/i915: Use locked access to ctx->engines in set_priority
This essentially reverts
commit 89ff76bf9b3b0b86e6bbe344bd6378d8661303fc
Author: Chris Wilson
Date: Thu Apr 2 13:42:18 2020 +0100
drm/i915/gem: Utilize rcu iteration of context engines
Note that the other use of __context_engines_await have disappeard in
the following commits:
ccbc1b97948a ("drm/i915/gem: Don't allow changing the VM on running contexts
(v4)")
c7a71fc8ee04 ("drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES")
4a766ae40ec8 ("drm/i915: Drop the CONTEXT_CLONE API (v2)")
None of these have any business to optimize their engine lookup with
rcu, unless extremely convincing benchmark data and a solid analysis
why we can't make that workload (whatever it is that does) faster with
a proper design fix.
Also since there's only one caller of context_apply_all left and it's
really just a loop, inline it and then inline the lopp body too. This
is how all other callers that take the engine lock loop over engines,
it's much simpler.
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniel Vetter
Cc: Jason Ekstrand
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 72 -
1 file changed, 14 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index dbaeb924a437..fd169cf2f75a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1284,49 +1284,6 @@ static int __context_set_persistence(struct
i915_gem_context *ctx, bool state)
return 0;
}
-static inline struct i915_gem_engines *
-__context_engines_await(const struct i915_gem_context *ctx,
- bool *user_engines)
-{
- struct i915_gem_engines *engines;
-
- rcu_read_lock();
- do {
- engines = rcu_dereference(ctx->engines);
- GEM_BUG_ON(!engines);
-
- if (user_engines)
- *user_engines = i915_gem_context_user_engines(ctx);
-
- /* successful await => strong mb */
- if (unlikely(!i915_sw_fence_await(>fence)))
- continue;
-
- if (likely(engines == rcu_access_pointer(ctx->engines)))
- break;
-
- i915_sw_fence_complete(>fence);
- } while (1);
- rcu_read_unlock();
-
- return engines;
-}
-
-static void
-context_apply_all(struct i915_gem_context *ctx,
- void (*fn)(struct intel_context *ce, void *data),
- void *data)
-{
- struct i915_gem_engines_iter it;
- struct i915_gem_engines *e;
- struct intel_context *ce;
-
- e = __context_engines_await(ctx, NULL);
- for_each_gem_engine(ce, e, it)
- fn(ce, data);
- i915_sw_fence_complete(>fence);
-}
-
static struct i915_gem_context *
i915_gem_create_context(struct drm_i915_private *i915,
const struct i915_gem_proto_context *pc)
@@ -1776,23 +1733,11 @@ set_persistence(struct i915_gem_context *ctx,
return __context_set_persistence(ctx, args->value);
}
-static void __apply_priority(struct intel_context *ce, void *arg)
-{
- struct i915_gem_context *ctx = arg;
-
- if (!intel_engine_has_timeslices(ce->engine))
- return;
-
- if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
- intel_engine_has_semaphores(ce->engine))
- intel_context_set_use_semaphores(ce);
- else
- intel_context_clear_use_semaphores(ce);
-}
-
static int set_priority(struct i915_gem_context *ctx,
const struct drm_i915_gem_context_param *args)
{
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
int err;
err = validate_priority(ctx->i915, args);
@@ -1800,7 +1745,18 @@ static int set_priority(struct i915_gem_context *ctx,
return err;
ctx->sched.priority = args->value;
- context_apply_all(ctx, __apply_priority, ctx);
+
+ for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
+ if (!intel_engine_has_timeslices(ce->engine))
+ continue;
+
+ if (ctx->sched.priority >= I915_PRIORITY_NORMAL &&
+ intel_engine_has_semaphores(ce->engine))
+ intel_context_set_use_semaphores(ce);
+ else
+ intel_context_clear_use_semaphores(ce);
+ }
+ i915_gem_context_unlock_engines(ctx);
return 0;
}
--
2.32.0
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Make workaround upper bounds exclusive
On Mon, 19 Jul 2021, "Souza, Jose" wrote:
> On Fri, 2021-07-16 at 22:14 -0700, Matt Roper wrote:
>> Workarounds are documented in the bspec with an exclusive upper bound
>> (i.e., a "fixed" stepping that no longer needs the workaround). This
>> makes our driver's use of an inclusive upper bound for stepping ranges
>> confusing; the differing notation between code and bspec makes it very
>> easy for mistakes to creep in.
>>
>> Let's switch the upper bound of our IS_{GT,DISP}_STEP macros over to use
>> an exclusive upper bound like the bspec does. This also has the benefit
>> of helping make sure workarounds are properly handled for new minor
>> steppings that show up (e.g., an A1 between the A0 and B0 we already
>> knew about) --- if the new intermediate stepping pulls in hardware fixes
>> early, there will be an update to the workaround definition which lets
>> us know we need to change our code. If the new stepping does not pull a
>> hardware fix earlier, then the new stepping will already be captured
>> properly by the "[begin, fix)" range in the code.
>>
>> We'll probably need to be extra vigilant in code review of new
>> workarounds for the near future to make sure developers notice the new
>> semantics of workaround bounds. But we just migrated a bunch of our
>> platforms from the IS_REVID bounds over to IS_{GT,DISP}_STEP, so people
>> are already adjusting to the new macros and now is a good time to make
>> this change too.
>>
>> Signed-off-by: Matt Roper
It's been merged already, but I think this is a good example of a patch
where simple review is just not enough. Needs maintainers in Cc and acks
on top.
BR,
Jani.
>> ---
>> drivers/gpu/drm/i915/display/intel_cdclk.c| 2 +-
>> .../drm/i915/display/intel_display_power.c| 8 +++---
>> drivers/gpu/drm/i915/display/intel_psr.c | 18 ++--
>> .../drm/i915/display/skl_universal_plane.c| 8 +++---
>> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
>> drivers/gpu/drm/i915/gt/intel_region_lmem.c | 2 +-
>> drivers/gpu/drm/i915/gt/intel_workarounds.c | 28 +--
>> drivers/gpu/drm/i915/i915_drv.h | 4 +--
>> drivers/gpu/drm/i915/intel_device_info.c | 2 +-
>> drivers/gpu/drm/i915/intel_pm.c | 8 +++---
>> 10 files changed, 41 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
>> b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> index 71067a62264d..944fb13b9d98 100644
>> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
>> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> @@ -2879,7 +2879,7 @@ void intel_init_cdclk_hooks(struct drm_i915_private
>> *dev_priv)
>> dev_priv->display.modeset_calc_cdclk = bxt_modeset_calc_cdclk;
>> dev_priv->display.calc_voltage_level = tgl_calc_voltage_level;
>> /* Wa_22011320316:adl-p[a0] */
>> -if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0))
>> +if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
>> dev_priv->cdclk.table = adlp_a_step_cdclk_table;
>> else
>> dev_priv->cdclk.table = adlp_cdclk_table;
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
>> b/drivers/gpu/drm/i915/display/intel_display_power.c
>> index e3aaf9678b07..bec380e58f40 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
>> @@ -5799,10 +5799,10 @@ static void tgl_bw_buddy_init(struct
>> drm_i915_private *dev_priv)
>> int config, i;
>>
>> if (IS_ALDERLAKE_S(dev_priv) ||
>> -IS_DG1_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
>> -IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_A0) ||
>> -IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
>> -/* Wa_1409767108:tgl,rkl,dg1,adl-s */
>> +IS_DG1_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
>> +IS_RKL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
>> +IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0))
>> +/* Wa_1409767108:tgl,dg1,adl-s */
>> table = wa_1409767108_buddy_page_masks;
>> else
>> table = tgl_buddy_page_masks;
>> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
>> b/drivers/gpu/drm/i915/display/intel_psr.c
>> index 0a3d42c8d47d..f0381edefded 100644
>> --- a/drivers/gpu/drm/i915/display/intel_psr.c
>> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
>> @@ -546,7 +546,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>> val |= intel_psr2_get_tp_time(intel_dp);
>>
>> /* Wa_22012278275:adl-p */
>> -if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_D1)) {
>> +if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_E0)) {
>> static const u8 map[] = {
>> 2, /* 5 lines */
>> 1, /* 6 lines */
>> @@ -593,7 +593,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>>
[Intel-gfx] [PATCH] drm/doc/rfc: drop lmem uapi section
We still have quite a bit more work to do with overall reworking of
the ttm-based dg1 code, but the uapi stuff is now finalized with the
latest pull. So remove that.
This also fixes kerneldoc build warnings because we've included the
same headers in two places, resulting in sphinx complaining about
duplicated symbols. This regression has been created when we moved the
uapi definitions to the real include/uapi/ folder in 727ecd99a4c9
("drm/doc/rfc: drop the i915_gem_lmem.h header")
Reported-by: Stephen Rothwell
Cc: Stephen Rothwell
Fixes: 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header")
Cc: Matthew Auld
Signed-off-by: Daniel Vetter
---
Documentation/gpu/rfc/i915_gem_lmem.rst | 107
1 file changed, 107 deletions(-)
diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst
b/Documentation/gpu/rfc/i915_gem_lmem.rst
index 675ba8620d66..91be041e68cc 100644
--- a/Documentation/gpu/rfc/i915_gem_lmem.rst
+++ b/Documentation/gpu/rfc/i915_gem_lmem.rst
@@ -22,110 +22,3 @@ real, with all the uAPI bits is:
* SET/GET ioctl caching(see `I915 SET/GET CACHING`_)
* Send RFC(with mesa-dev on cc) for final sign off on the uAPI
* Add pciid for DG1 and turn on uAPI for real
-
-New object placement and region query uAPI
-==
-Starting from DG1 we need to give userspace the ability to allocate buffers
from
-device local-memory. Currently the driver supports gem_create, which can place
-buffers in system memory via shmem, and the usual assortment of other
-interfaces, like dumb buffers and userptr.
-
-To support this new capability, while also providing a uAPI which will work
-beyond just DG1, we propose to offer three new bits of uAPI:
-
-DRM_I915_QUERY_MEMORY_REGIONS
--
-New query ID which allows userspace to discover the list of supported memory
-regions(like system-memory and local-memory) for a given device. We identify
-each region with a class and instance pair, which should be unique. The class
-here would be DEVICE or SYSTEM, and the instance would be zero, on platforms
-like DG1.
-
-Side note: The class/instance design is borrowed from our existing engine uAPI,
-where we describe every physical engine in terms of its class, and the
-particular instance, since we can have more than one per class.
-
-In the future we also want to expose more information which can further
-describe the capabilities of a region.
-
-.. kernel-doc:: include/uapi/drm/i915_drm.h
-:functions: drm_i915_gem_memory_class
drm_i915_gem_memory_class_instance drm_i915_memory_region_info
drm_i915_query_memory_regions
-
-GEM_CREATE_EXT
---
-New ioctl which is basically just gem_create but now allows userspace to
provide
-a chain of possible extensions. Note that if we don't provide any extensions
and
-set flags=0 then we get the exact same behaviour as gem_create.
-
-Side note: We also need to support PXP[1] in the near future, which is also
-applicable to integrated platforms, and adds its own gem_create_ext extension,
-which basically lets userspace mark a buffer as "protected".
-
-.. kernel-doc:: include/uapi/drm/i915_drm.h
-:functions: drm_i915_gem_create_ext
-
-I915_GEM_CREATE_EXT_MEMORY_REGIONS
---
-Implemented as an extension for gem_create_ext, we would now allow userspace to
-optionally provide an immutable list of preferred placements at creation time,
-in priority order, for a given buffer object. For the placements we expect
-them each to use the class/instance encoding, as per the output of the regions
-query. Having the list in priority order will be useful in the future when
-placing an object, say during eviction.
-
-.. kernel-doc:: include/uapi/drm/i915_drm.h
-:functions: drm_i915_gem_create_ext_memory_regions
-
-One fair criticism here is that this seems a little over-engineered[2]. If we
-just consider DG1 then yes, a simple gem_create.flags or something is totally
-all that's needed to tell the kernel to allocate the buffer in local-memory or
-whatever. However looking to the future we need uAPI which can also support
-upcoming Xe HP multi-tile architecture in a sane way, where there can be
-multiple local-memory instances for a given device, and so using both class and
-instance in our uAPI to describe regions is desirable, although specifically
-for DG1 it's uninteresting, since we only have a single local-memory instance.
-
-Existing uAPI issues
-
-Some potential issues we still need to resolve.
-
-I915 MMAP
--
-In i915 there are multiple ways to MMAP GEM object, including mapping the same
-object using different mapping types(WC vs WB), i.e multiple active mmaps per
-object. TTM expects one MMAP at most for the lifetime of the object. If it
-turns out that we have to backpedal here, there might be some potential
-userspace fallout.
-
-I915 SET/GET CACHING
-
-In i915 we have set/get_caching
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem/ttm: prefer kernel types
== Series Details == Series: drm/i915/gem/ttm: prefer kernel types URL : https://patchwork.freedesktop.org/series/93541/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10464 -> Patchwork_20791 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20791 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20791, 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_20791/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20791: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gt_lrc: - fi-rkl-guc: NOTRUN -> [DMESG-WARN][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20791/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html Known issues Here are the changes found in Patchwork_20791 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-gfx: - fi-rkl-guc: NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20791/fi-rkl-guc/igt@amdgpu/amd_ba...@cs-gfx.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-1115g4: [PASS][3] -> [FAIL][4] ([i915#1888]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20791/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html * igt@i915_pm_rpm@module-reload: - fi-rkl-guc: NOTRUN -> [SKIP][5] ([i915#3844] / [i915#579]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20791/fi-rkl-guc/igt@i915_pm_...@module-reload.html * igt@prime_vgem@basic-userptr: - fi-rkl-guc: NOTRUN -> [SKIP][6] ([i915#3301]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20791/fi-rkl-guc/igt@prime_v...@basic-userptr.html * igt@prime_vgem@basic-write: - fi-rkl-guc: NOTRUN -> [SKIP][7] ([i915#3291]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20791/fi-rkl-guc/igt@prime_v...@basic-write.html Possible fixes * igt@gem_exec_suspend@basic-s0: - fi-tgl-1115g4: [FAIL][8] ([i915#1888]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20791/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html * igt@i915_pm_rps@basic-api: - fi-rkl-guc: [DMESG-WARN][10] ([i915#3925]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10464/fi-rkl-guc/igt@i915_pm_...@basic-api.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20791/fi-rkl-guc/igt@i915_pm_...@basic-api.html [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291 [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301 [i915#3844]: https://gitlab.freedesktop.org/drm/intel/issues/3844 [i915#3925]: https://gitlab.freedesktop.org/drm/intel/issues/3925 [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579 Participating hosts (37 -> 33) -- Missing(4): fi-bdw-samus fi-bsw-cyan bat-jsl-1 fi-apl-guc Build changes - * Linux: CI_DRM_10464 -> Patchwork_20791 CI-20190529: 20190529 CI_DRM_10464: 294a55f328023a4e36f46e5eb6c4859076efd850 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6165: df5d05d742275b049f6f3c852a86c4769966b126 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20791: 5f5e1301423731d5c2deee844b627636e6208b02 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5f5e13014237 drm/i915/gem/ttm: prefer kernel types == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20791/index.html
Re: [Intel-gfx] [V3 2/7] drm/i915/jsl: program DSI panel GPIOs
On Tue, 10 Aug 2021, "Lee, Shawn C" wrote:
> On Tue, 10 Aug 2021, Jani Nikula wrote:
>>On Fri, 23 Jul 2021, Lee Shawn C wrote:
>>> DSI driver should have its own implementation to toggle gpio pins
>>> based on GPIO info coming from VBT sequences.
>>
>>Why?
>>
>
> Without this change, we are not able to control gpio signal output to
> meet MIPI panel's requirement for power on/off sequence.
>
>>>
>>> Cc: Ville Syrjala
>>> Cc: Jani Nikula
>>> Cc: Vandita Kulkarni
>>> Cc: Cooper Chiou
>>> Cc: William Tseng
>>> Signed-off-by: Lee Shawn C
>>> ---
>>> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 44 +++-
>>> drivers/gpu/drm/i915/i915_reg.h | 10 +
>>> 2 files changed, 53 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>>> b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>>> index cc93e045a425..dd03e5629ba6 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>>> @@ -43,6 +43,7 @@
>>> #include "intel_display_types.h"
>>> #include "intel_dsi.h"
>>> #include "intel_sideband.h"
>>> +#include "intel_de.h"
>>>
>>> #define MIPI_TRANSFER_MODE_SHIFT0
>>> #define MIPI_VIRTUAL_CHANNEL_SHIFT 1
>>> @@ -354,7 +355,48 @@ static void bxt_exec_gpio(struct drm_i915_private
>>> *dev_priv, static void icl_exec_gpio(struct drm_i915_private *dev_priv,
>>>u8 gpio_source, u8 gpio_index, bool value) {
>>> -drm_dbg_kms(_priv->drm, "Skipping ICL GPIO element execution\n");
>>> +u32 val;
>>> +
>>> +switch (gpio_index) {
>>> +case ICL_GPIO_L_VDDEN_1:
>>> +val = intel_de_read(dev_priv, ICP_PP_CONTROL(1));
>>> +if (value)
>>> +val |= PWR_STATE_TARGET;
>>> +else
>>> +val &= ~PWR_STATE_TARGET;
>>> +intel_de_write(dev_priv, ICP_PP_CONTROL(1), val);
>>
>>All the PPS access should be in intel_pps.[ch] and protected with the pps
>>mutex.
>>
>
> OK! We will move icl_exec_gpio() into intel_pps.c and use pps mutex to
> protect it.
>
>>> +break;
>>> +case ICL_GPIO_L_BKLTEN_1:
>>> +val = intel_de_read(dev_priv, ICP_PP_CONTROL(1));
>>> +if (value)
>>> +val |= BACKLIGHT_ENABLE;
>>> +else
>>> +val &= ~BACKLIGHT_ENABLE;
>>> +intel_de_write(dev_priv, ICP_PP_CONTROL(1), val);
>>> +break;
>>> +case ICL_GPIO_DDPA_CTRLCLK_1:
>>> +val = intel_de_read(dev_priv, GPIO(1));
>>> +if (value)
>>> +val |= GPIO_CLOCK_VAL_OUT;
>>> +else
>>> +val &= ~GPIO_CLOCK_VAL_OUT;
>>> +val |= GPIO_CLOCK_DIR_MASK | GPIO_CLOCK_DIR_OUT |
>>> GPIO_CLOCK_VAL_MASK;
>>> +intel_de_write(dev_priv, GPIO(1), val);
>>> +break;
>>> +case ICL_GPIO_DDPA_CTRLDATA_1:
>>> +val = intel_de_read(dev_priv, GPIO(1));
>>> +if (value)
>>> +val |= GPIO_DATA_VAL_OUT;
>>> +else
>>> +val &= ~GPIO_DATA_VAL_OUT;
>>> +val |= GPIO_DATA_DIR_MASK | GPIO_DATA_DIR_OUT |
>>> GPIO_DATA_VAL_MASK;
>>> +intel_de_write(dev_priv, GPIO(1), val);
>>> +break;
>>> +default:
>>> +/* TODO: Add support for remaining GPIOs */
>>> +DRM_ERROR("Invalid GPIO number (%d) from VBT\n", gpio_index);
>>> +break;
>>> +}
>>> }
>>>
>>> static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8
>>> *data) diff --git a/drivers/gpu/drm/i915/i915_reg.h
>>> b/drivers/gpu/drm/i915/i915_reg.h index 943fe485c662..b725234e0e9c
>>> 100644
>>> --- a/drivers/gpu/drm/i915/i915_reg.h
>>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>>> @@ -5143,6 +5143,16 @@ enum {
>>> #define _PP_STATUS 0x61200
>>> #define PP_STATUS(pps_idx) _MMIO_PPS(pps_idx, _PP_STATUS)
>>> #define PP_ON REG_BIT(31)
>>> +
>>> +#define _PP_CONTROL_1 0xc7204
>>> +#define _PP_CONTROL_2 0xc7304
>>> +#define ICP_PP_CONTROL(x) _MMIO(((x) == 1) ? _PP_CONTROL_1 : \
>>> + _PP_CONTROL_2)
>>> +#define POWER_CYCLE_DELAY_MASK REG_GENMASK(8, 4)
>>> +#define VDD_OVERRIDE_FORCE REG_BIT(3)
>>> +#define BACKLIGHT_ENABLE REG_BIT(2)
>>> +#define PWR_DOWN_ON_RESET REG_BIT(1)
>>> +#define PWR_STATE_TARGET REG_BIT(0)
>>
>>These are all duplicate defines for existing PP_CONTROL() registers and
>>macros.
>
> I found this patch on drm-tip branch and removed PP_CONTRL() defines.
> https://patchwork.freedesktop.org/patch/291095/
Look for PP_CONTROL(), not ICL_PP_CONTROL().
>
> Best regards,
> Shawn
>
>>
>>> /*
>>> * Indicates that all dependencies of the panel are on:
>>> *
>>
>>--
>>Jani Nikula, Intel Open Source Graphics
Re: [Intel-gfx] [PATCH] drm/i915/gem/ttm: prefer kernel types
On Tue, 10 Aug 2021, Daniel Vetter wrote:
> On Tue, Aug 10, 2021 at 11:41:28AM +0300, Jani Nikula wrote:
>> Avoid uintXX_t types in the driver.
>>
>> Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
>> Cc: Thomas Hellström
>> Cc: Matthew Auld
>> Cc: Maarten Lankhorst
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>> index 771eb2963123..ffda88156e32 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>> @@ -168,7 +168,7 @@ i915_ttm_placement_from_obj(const struct
>> drm_i915_gem_object *obj,
>> }
>>
>> static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
>> - uint32_t page_flags)
>> + u32 page_flags)
>
> It's for the ttm_device_funcs ops table, I thinhk we should fix it there
> and across the board?
>
> Otherwise a bit ocd mismatch :-)
Well, the above is the only uintXX_t reference in i915.
BR,
Jani.
> -Daniel
>
>> {
>> struct ttm_resource_manager *man =
>> ttm_manager_type(bo->bdev, bo->resource->mem_type);
>> --
>> 2.20.1
>>
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [CI v2 1/1] drm/i915: Tweaked Wa_14010685332 for all PCHs
dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H platform
despite Wa_14010685332 original sequence, thus blocks entry to deeper s0ix
state.
The Tweaked Wa_14010685332 sequence fixes this issue, therefore use tweaked
Wa_14010685332 sequence for every PCH since PCH_CNP.
v2:
- removed RKL from comment and simplified condition. [Rodrigo]
Fixes: b896898c7369 ("drm/i915: Tweaked Wa_14010685332 for PCHs used on gen11
platforms")
Cc: Matt Roper
Cc: Rodrigo Vivi
Cc: Imre Deak
Signed-off-by: Anshuman Gupta
Reviewed-by: Rodrigo Vivi
---
.../drm/i915/display/intel_display_power.c| 16 +++---
drivers/gpu/drm/i915/i915_irq.c | 21 ---
2 files changed, 8 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 5da293369f30..cce1a926fcc1 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -6329,13 +6329,13 @@ void intel_display_power_suspend_late(struct
drm_i915_private *i915)
if (DISPLAY_VER(i915) >= 11 || IS_GEMINILAKE(i915) ||
IS_BROXTON(i915)) {
bxt_enable_dc9(i915);
- /* Tweaked Wa_14010685332:icp,jsp,mcc */
- if (INTEL_PCH_TYPE(i915) >= PCH_ICP && INTEL_PCH_TYPE(i915) <=
PCH_MCC)
- intel_de_rmw(i915, SOUTH_CHICKEN1,
-SBCLK_RUN_REFCLK_DIS,
SBCLK_RUN_REFCLK_DIS);
} else if (IS_HASWELL(i915) || IS_BROADWELL(i915)) {
hsw_enable_pc8(i915);
}
+
+ /* Tweaked Wa_14010685332:cnp,icp,jsp,mcc,tgp,adp */
+ if (INTEL_PCH_TYPE(i915) >= PCH_CNP && INTEL_PCH_TYPE(i915) < PCH_DG1)
+ intel_de_rmw(i915, SOUTH_CHICKEN1, SBCLK_RUN_REFCLK_DIS,
SBCLK_RUN_REFCLK_DIS);
}
void intel_display_power_resume_early(struct drm_i915_private *i915)
@@ -6344,13 +6344,13 @@ void intel_display_power_resume_early(struct
drm_i915_private *i915)
IS_BROXTON(i915)) {
gen9_sanitize_dc_state(i915);
bxt_disable_dc9(i915);
- /* Tweaked Wa_14010685332:icp,jsp,mcc */
- if (INTEL_PCH_TYPE(i915) >= PCH_ICP && INTEL_PCH_TYPE(i915) <=
PCH_MCC)
- intel_de_rmw(i915, SOUTH_CHICKEN1,
SBCLK_RUN_REFCLK_DIS, 0);
-
} else if (IS_HASWELL(i915) || IS_BROADWELL(i915)) {
hsw_disable_pc8(i915);
}
+
+ /* Tweaked Wa_14010685332:cnp,icp,jsp,mcc,tgp,adp */
+ if (INTEL_PCH_TYPE(i915) >= PCH_CNP && INTEL_PCH_TYPE(i915) < PCH_DG1)
+ intel_de_rmw(i915, SOUTH_CHICKEN1, SBCLK_RUN_REFCLK_DIS, 0);
}
void intel_display_power_suspend(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 17d336218b67..9bc4f4a8e12e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3079,24 +3079,6 @@ static void valleyview_irq_reset(struct drm_i915_private
*dev_priv)
spin_unlock_irq(_priv->irq_lock);
}
-static void cnp_display_clock_wa(struct drm_i915_private *dev_priv)
-{
- struct intel_uncore *uncore = _priv->uncore;
-
- /*
-* Wa_14010685332:cnp/cmp,tgp,adp
-* TODO: Clarify which platforms this applies to
-* TODO: Figure out if this workaround can be applied in the s0ix
suspend/resume handlers as
-* on earlier platforms and whether the workaround is also needed for
runtime suspend/resume
-*/
- if (INTEL_PCH_TYPE(dev_priv) == PCH_CNP ||
- (INTEL_PCH_TYPE(dev_priv) >= PCH_TGP && INTEL_PCH_TYPE(dev_priv) <
PCH_DG1)) {
- intel_uncore_rmw(uncore, SOUTH_CHICKEN1, SBCLK_RUN_REFCLK_DIS,
-SBCLK_RUN_REFCLK_DIS);
- intel_uncore_rmw(uncore, SOUTH_CHICKEN1, SBCLK_RUN_REFCLK_DIS,
0);
- }
-}
-
static void gen8_display_irq_reset(struct drm_i915_private *dev_priv)
{
struct intel_uncore *uncore = _priv->uncore;
@@ -3130,7 +3112,6 @@ static void gen8_irq_reset(struct drm_i915_private
*dev_priv)
if (HAS_PCH_SPLIT(dev_priv))
ibx_irq_reset(dev_priv);
- cnp_display_clock_wa(dev_priv);
}
static void gen11_display_irq_reset(struct drm_i915_private *dev_priv)
@@ -3174,8 +3155,6 @@ static void gen11_display_irq_reset(struct
drm_i915_private *dev_priv)
if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
GEN3_IRQ_RESET(uncore, SDE);
-
- cnp_display_clock_wa(dev_priv);
}
static void gen11_irq_reset(struct drm_i915_private *dev_priv)
--
2.26.2
[Intel-gfx] [CI v2 0/1] Tweaked Wa_14010685332 for all PCHs
This revision is floated to get the CI results. Rev3 Patchwork Link : https://patchwork.freedesktop.org/series/88435/#rev3 David Box has tested the Rev3 and provided that confirmation that it is working on TGL-H Dell platforms. Rev4 and Rev5 have some patchwork issues due to that CI build is failing. Anshuman Gupta (1): drm/i915: Tweaked Wa_14010685332 for all PCHs .../drm/i915/display/intel_display_power.c| 16 +++--- drivers/gpu/drm/i915/i915_irq.c | 21 --- 2 files changed, 8 insertions(+), 29 deletions(-) -- 2.26.2
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg
> -Original Message-
> From: Nautiyal, Ankit K
> Sent: Monday, August 2, 2021 6:27 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Zanoni, Paulo R
> ; ville.syrj...@linux.intel.com;
> daniel.vet...@ffwll.ch;
> jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
> ; sta...@vger.kernel.org
> Subject: [PATCH v2] drm/i915/display: Fix the 12 BPC bits for PIPE_MISC reg
>
> From: Ankit Nautiyal
>
> Till DISPLAY12 the PIPE_MISC bits 5-7 are used to set the Dithering BPC, with
> valid
> values of 6, 8, 10 BPC, with Dithering bit enabled.
> Also, these bits are used in case of HW readout for pipe_bpp in case of DSI.
> For ADLP+ these bits are used to set the PORT OUTPUT BPC, with valid values
> of: 6,
> 8, 10, 12 BPC, and need to be programmed whether dithering is enabled or not.
>
> This patch:
> -corrects the bits 5-7 for PIPE MISC register for 12 BPC.
> -renames the bits and mask to have generic names for these bits for dithering
> bpc
> and port output bpc.
>
> v2: Addressed the comments and suggestions from Uma Shankar:
> -Add 'display' in subject
> -Add Fixes tag in the commit message.
> -Take care of DSI case which uses the bits for getting pipe_bpp.
>
> Fixes: 756f85cffef2 ("drm/i915/bdw: Broadwell has PIPEMISC")
> Cc: Paulo Zanoni (v1)
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: intel-gfx@lists.freedesktop.org
> Cc: # v3.13+
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 18 +-
> drivers/gpu/drm/i915/i915_reg.h | 15 ++-
> 2 files changed, 19 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 65ddb6c..9766b36 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5760,16 +5760,16 @@ static void bdw_set_pipemisc(const struct
> intel_crtc_state *crtc_state)
>
> switch (crtc_state->pipe_bpp) {
> case 18:
> - val |= PIPEMISC_DITHER_6_BPC;
> + val |= PIPEMISC_6_BPC;
> break;
> case 24:
> - val |= PIPEMISC_DITHER_8_BPC;
> + val |= PIPEMISC_8_BPC;
> break;
> case 30:
> - val |= PIPEMISC_DITHER_10_BPC;
> + val |= PIPEMISC_10_BPC;
> break;
> case 36:
> - val |= PIPEMISC_DITHER_12_BPC;
> + val |= PIPEMISC_12_BPC;
Isn't this bit not supported on prior to Gen13 platforms, so from that
perspective it's an
Invalid operation. Can you confirm.
> break;
> default:
> MISSING_CASE(crtc_state->pipe_bpp);
> @@ -5822,14 +5822,14 @@ int bdw_get_pipemisc_bpp(struct intel_crtc *crtc)
>
> tmp = intel_de_read(dev_priv, PIPEMISC(crtc->pipe));
>
> - switch (tmp & PIPEMISC_DITHER_BPC_MASK) {
> - case PIPEMISC_DITHER_6_BPC:
> + switch (tmp & PIPEMISC_BPC_MASK) {
> + case PIPEMISC_6_BPC:
> return 18;
> - case PIPEMISC_DITHER_8_BPC:
> + case PIPEMISC_8_BPC:
> return 24;
> - case PIPEMISC_DITHER_10_BPC:
> + case PIPEMISC_10_BPC:
> return 30;
> - case PIPEMISC_DITHER_12_BPC:
> + case PIPEMISC_12_BPC:
> return 36;
Same here.
> default:
> MISSING_CASE(tmp);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 943fe48..bbfe4f4 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6166,11 +6166,16 @@ enum {
> #define PIPEMISC_HDR_MODE_PRECISION(1 << 23) /* icl+ */
> #define PIPEMISC_OUTPUT_COLORSPACE_YUV (1 << 11)
> #define PIPEMISC_PIXEL_ROUNDING_TRUNC REG_BIT(8) /* tgl+ */
> -#define PIPEMISC_DITHER_BPC_MASK (7 << 5)
> -#define PIPEMISC_DITHER_8_BPC (0 << 5)
> -#define PIPEMISC_DITHER_10_BPC (1 << 5)
> -#define PIPEMISC_DITHER_6_BPC (2 << 5)
> -#define PIPEMISC_DITHER_12_BPC (3 << 5)
> +/*
> + * For Display < 13, Bits 5-7 of PIPE MISC represent DITHER BPC.
> + * ADLP+, the bits 5-7 represent PORT OUTPUT BPC with valid values of:
> + * 6, 8, 10, 12 BPC.
> + */
> +#define PIPEMISC_BPC_MASK (7 << 5)
> +#define PIPEMISC_8_BPC (0 << 5)
> +#define PIPEMISC_10_BPC(1 << 5)
> +#define PIPEMISC_6_BPC (2 << 5)
> +#define PIPEMISC_12_BPC(4 << 5) /* adlp+ */
> #define PIPEMISC_DITHER_ENABLE (1 << 4)
> #define PIPEMISC_DITHER_TYPE_MASK (3 << 2)
> #define PIPEMISC_DITHER_TYPE_SP(0 << 2)
> --
> 2.8.1
Re: [Intel-gfx] [PATCH] DRM: i915: i915_perf: Fixed compiler warning
On 09/08/2021 05:33, Julius Victorian wrote: From: Julius Fixed compiler warning: "left shift of negative value" Signed-off-by: Julius Victorian Reviewed-by: Lionel Landwerlin Thanks! --- drivers/gpu/drm/i915/i915_perf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index 9f94914958c3..7b852974241e 100644 --- a/drivers/gpu/drm/i915/i915_perf.c +++ b/drivers/gpu/drm/i915/i915_perf.c @@ -2804,7 +2804,7 @@ get_default_sseu_config(struct intel_sseu *out_sseu, * all available subslices per slice. */ out_sseu->subslice_mask = - ~(~0 << (hweight8(out_sseu->subslice_mask) / 2)); + ~(~0U << (hweight8(out_sseu->subslice_mask) / 2)); out_sseu->slice_mask = 0x1; } }
Re: [Intel-gfx] [PATCH 3/3] drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2H
On Mon, Aug 09, 2021 at 07:41:29PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 04:03:28PM +0200, Daniel Vetter wrote:
> > On Sun, Aug 08, 2021 at 11:07:57AM -0700, Matthew Brost wrote:
> > > While debugging an issue with full GT resets I went down a rabbit hole
> > > thinking the scrubbing of lost G2H wasn't working correctly. This proved
> > > to be incorrect as this was working just fine but this chase inspired me
> > > to write a selftest to prove that this works. This simple selftest
> > > injects errors dropping various G2H and then issues a full GT reset
> > > proving that the scrubbing of these G2H doesn't blow up.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 18 +++
> > > drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 126 ++
> > > .../drm/i915/selftests/i915_live_selftests.h | 1 +
> > > .../i915/selftests/intel_scheduler_helpers.c | 12 ++
> > > .../i915/selftests/intel_scheduler_helpers.h | 2 +
> > > 6 files changed, 163 insertions(+)
> > > create mode 100644 drivers/gpu/drm/i915/gt/uc/selftest_guc.c
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > index e54351a170e2..fec5ff7ef168 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > @@ -198,6 +198,10 @@ struct intel_context {
> > >*/
> > > u8 guc_prio;
> > > u32 guc_prio_count[GUC_CLIENT_PRIORITY_NUM];
> > > +
> >
> > I know the existing stuff isn't following this at all, but for anything
> > new we really should put some kerneldoc into structures. This probably
> > means you need to open-code the #ifdef here, since this macro will likely
> > upset kerneldoc parsing.
> >
>
> Ok, got it.
>
> > > + I915_SELFTEST_DECLARE(bool drop_schedule_enable);
> > > + I915_SELFTEST_DECLARE(bool drop_schedule_disable);
> > > + I915_SELFTEST_DECLARE(bool drop_deregister);
> > > };
> > >
> > > #endif /* __INTEL_CONTEXT_TYPES__ */
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > index cd8df078ca87..d13dc56bae43 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > @@ -2618,6 +2618,11 @@ int intel_guc_deregister_done_process_msg(struct
> > > intel_guc *guc,
> > >
> > > trace_intel_context_deregister_done(ce);
> > >
> > > + if (I915_SELFTEST_ONLY(ce->drop_deregister)) {
> > > + I915_SELFTEST_DECLARE(ce->drop_deregister = false;)
> >
> > This macro wrapping is quite nasty, can't we just #ifdef this? Especially
> > the _DECLARE name really doesn't expect a statement.
> >
>
> Had it like that originally then remember these marcos and in the past
> people have complained when I didn't use them, so yes pretty much a
> bikeshed. I personally like the ifdef myself.
I think the plain #ifdef is much clearer in the code. The
I915_SELFTEST_ONLY macro makes some sense to compile stuff out in some
cases and make sure it's wrapped in unlikely when enabled, and often
that's good enough. But not here.
Also because it breaks kerneldoc I don't like the macro really in structs
either. Anything that discourages people from writing solid comments is
Not Good at All :-) So another reason to not like I915_SELFTEST_DECLARE()
macro.
-Daniel
>
> Matt
>
> > Aside from these bikesheds I don't have a much to say on the test logic
> > itself, since I'm far from knowledgable on guc stuff ...
> > -Daniel
> >
> >
> > > + return 0;
> > > + }
> > > +
> > > if (context_wait_for_deregister_to_register(ce)) {
> > > struct intel_runtime_pm *runtime_pm =
> > > >engine->gt->i915->runtime_pm;
> > > @@ -2672,10 +2677,19 @@ int intel_guc_sched_done_process_msg(struct
> > > intel_guc *guc,
> > > trace_intel_context_sched_done(ce);
> > >
> > > if (context_pending_enable(ce)) {
> > > + if (I915_SELFTEST_ONLY(ce->drop_schedule_enable)) {
> > > + I915_SELFTEST_DECLARE(ce->drop_schedule_enable = false;)
> > > + return 0;
> > > + }
> > > clr_context_pending_enable(ce);
> > > } else if (context_pending_disable(ce)) {
> > > bool banned;
> > >
> > > + if (I915_SELFTEST_ONLY(ce->drop_schedule_disable)) {
> > > + I915_SELFTEST_DECLARE(ce->drop_schedule_disable =
> > > false;)
> > > + return 0;
> > > + }
> > > +
> > > /*
> > >* Unpin must be done before __guc_signal_context_fence,
> > >* otherwise a race exists between the requests getting
> > > @@ -3047,3 +3061,7 @@ bool intel_guc_virtual_engine_has_heartbeat(const
> > > struct intel_engine_cs *ve)
> > >
> > > return false;
> > > }
> > > +
> > >
Re: [Intel-gfx] [PATCH 2/3] drm/i915/selftests: Fix memory corruption in live_lrc_isolation
On Mon, Aug 09, 2021 at 07:37:39PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 03:38:38PM +0200, Daniel Vetter wrote:
> > On Sun, Aug 08, 2021 at 11:07:56AM -0700, Matthew Brost wrote:
> > > GuC submission has exposed an existing memory corruption in
> > > live_lrc_isolation. We believe that some writes to the watchdog offsets
> > > in the LRC (0x178 & 0x17c) can result in trashing of portions of the
> > > address space. With GuC submission there are additional objects which
> > > can move the context redzone into the space that is trashed. To
> > > workaround this avoid poisoning the watchdog.
> >
> > A Bspec reference here would be good (we can quote anything that's marked
> > for public release, so doesn't have one of the IP markers).
> >
>
> Let me see what I dig up in the bspec.
>
> BTW - Hopefully we can root cause this soon with a proper fix.
Well if it's work-in-progress duct-tape without reference that's fine
too, then perhaps sprinkle a JIRA number here (just not the full link,
intel IT doesn't like those leaking). Just something that in a few months
when someone reads that code they can stitch together the story again.
-Daniel
>
> > Also I think the above should be replicated in condensed form instead of
> > the XXX comment.
> >
>
> Sure.
>
> Matt
>
> > With those: Acked-by: Daniel Vetter since I
> > definitely have enough clue here for a detailed review.
> > -Daniel
> >
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/selftest_lrc.c | 29 +-
> > > 1 file changed, 28 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > > b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > > index b0977a3b699b..6500e9fce8a0 100644
> > > --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > > +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> > > @@ -1074,6 +1074,32 @@ record_registers(struct intel_context *ce,
> > > goto err_after;
> > > }
> > >
> > > +static u32 safe_offset(u32 offset, u32 reg)
> > > +{
> > > + /* XXX skip testing of watchdog */
> > > + if (offset == 0x178 || offset == 0x17c)
> > > + reg = 0;
> > > +
> > > + return reg;
> > > +}
> > > +
> > > +static int get_offset_mask(struct intel_engine_cs *engine)
> > > +{
> > > + if (GRAPHICS_VER(engine->i915) < 12)
> > > + return 0xfff;
> > > +
> > > + switch (engine->class) {
> > > + default:
> > > + case RENDER_CLASS:
> > > + return 0x07ff;
> > > + case COPY_ENGINE_CLASS:
> > > + return 0x0fff;
> > > + case VIDEO_DECODE_CLASS:
> > > + case VIDEO_ENHANCEMENT_CLASS:
> > > + return 0x3fff;
> > > + }
> > > +}
> > > +
> > > static struct i915_vma *load_context(struct intel_context *ce, u32
> > > poison)
> > > {
> > > struct i915_vma *batch;
> > > @@ -1117,7 +1143,8 @@ static struct i915_vma *load_context(struct
> > > intel_context *ce, u32 poison)
> > > len = (len + 1) / 2;
> > > *cs++ = MI_LOAD_REGISTER_IMM(len);
> > > while (len--) {
> > > - *cs++ = hw[dw];
> > > + *cs++ = safe_offset(hw[dw] &
> > > get_offset_mask(ce->engine),
> > > + hw[dw]);
> > > *cs++ = poison;
> > > dw += 2;
> > > }
> > > --
> > > 2.28.0
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Fix several issues related to resets / request cancelation
On Mon, Aug 09, 2021 at 07:35:22PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 03:35:26PM +0200, Daniel Vetter wrote:
> > On Sun, Aug 08, 2021 at 11:07:55AM -0700, Matthew Brost wrote:
> > > Resets are notoriously hard to get fully working and notoriously racey,
> > > especially with selftests / IGTs that do all sorts of wild things that
> > > would be near impossible to hit during normal use cases. Even though
> > > likely impossible to hit, anything selftests / IGTs uncover needs to be
> > > fixed. This patch addresses 7 such issues.
> > >
> > > 1. A small race that could result in incorrect accounting of the number
> > > of outstanding G2H. Basically prior to this patch we did not increment
> > > the number of outstanding G2H if we encoutered a GT reset while sending
> > > a H2G. This was incorrect as the context state had already been updated
> > > to anticipate a G2H response thus the counter should be incremented.
> > >
> > > 2. When unwinding requests on a reset context, if other requests in the
> > > context are in the priority list the requests could be resubmitted out
> > > of seqno order. Traverse the list of active requests in reserve and
> > > append to the head of the priority list to fix this.
> > >
> > > 3. Don't drop ce->guc_active.lock when unwinding a context after reset.
> > > At one point we had to drop this because of a lock inversion but that is
> > > no longer the case. It is much safer to hold the lock so let's do that.
> > >
> > > 4. Prior to this patch the blocked context counter was cleared on
> > > init_sched_state (used during registering a context & resets) which is
> > > incorrect. This state needs to be persistent or the counter can read the
> > > incorrect value.
> > >
> > > 5. Flush the work queue for GuC generated G2H messages during a GT reset.
> > >
> > > 6. Do not clear enable during a context reset if a schedule enable is in
> > > flight.
> > >
> > > 7. When unblocking a context, do not enable scheduling if the context is
> > > banned.
> >
> > I think each of the above should be a separate patch. I think it would
> > also be good if each fix references the commits that introduced/changed
> > something.
> >
>
> Sure, just was trying to cheat and make our lives easier with less
> patches to backport into DII.
>
> > Most of this stuff is extremely hard to get right, and unfortunately our
> > current code is way too fond of lockless trickery (which really isn't a
> > great idea in the reset code). We need to apply as much care as possible
> > here.
> >
>
> Yep, resets are hard. It is hard because like ten other async things
> (e.g. a new submission, registering a context, banning a context,
> canceling a request, processing a G2H, trying to idle the GPU, unpinning
> a context) can all be happening at the same time. Hopefully when we move
> the DRM scheduler we can remove some of these async operations,
> perma-pinned contexts would also help too. Have a story for that + a
> story to simplify the locking.
A bit an aside, but drm/sched has a pretty solid story around resets,
including what to do if your reset domain escalates (probably more useful
for the execlist backend than GuC) and how it's all synchronized.
I do need to review the barriers for when you permanently wedge an engine,
and the support for that isn't well encapsulated nor documented. But it's
there (amdgpu uses that when the reset fails, kinda like we do), and
that's about the only gap I've found thus far around drm/sched reset
support.
So should all be substantially clarified once we get there.
-Daniel
>
> > Also expect me to ask a lot of annoying questions about all the atomic_t
> > you touch :-)
>
> Looking forward to it.
>
> Matt
>
> > -Daniel
> >
> >
> > >
> > > Fixes: f4eb1f3fe946 ("drm/i915/guc: Ensure G2H response has space in
> > > buffer")
> > > Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
> > > Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC
> > > interface")
> > > Signed-off-by: Matthew Brost
> > > Cc:
> > > ---
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 43 ---
> > > 1 file changed, 27 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > index 87d8dc8f51b9..cd8df078ca87 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > @@ -152,7 +152,7 @@ static inline void init_sched_state(struct
> > > intel_context *ce)
> > > {
> > > /* Only should be called from guc_lrc_desc_pin() */
> > > atomic_set(>guc_sched_state_no_lock, 0);
> > > - ce->guc_state.sched_state = 0;
> > > + ce->guc_state.sched_state &= SCHED_STATE_BLOCKED_MASK;
> > > }
> > >
> > > static inline bool
> > > @@ -360,11 +360,13 @@ static int guc_submission_send_busy_loop(struct
> > > intel_guc *guc,
> > > {
> > > int
Re: [Intel-gfx] [PATCH] drm/i915/gem/ttm: prefer kernel types
On Tue, Aug 10, 2021 at 11:41:28AM +0300, Jani Nikula wrote:
> Avoid uintXX_t types in the driver.
>
> Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
> Cc: Thomas Hellström
> Cc: Matthew Auld
> Cc: Maarten Lankhorst
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 771eb2963123..ffda88156e32 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -168,7 +168,7 @@ i915_ttm_placement_from_obj(const struct
> drm_i915_gem_object *obj,
> }
>
> static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
> - uint32_t page_flags)
> + u32 page_flags)
It's for the ttm_device_funcs ops table, I thinhk we should fix it there
and across the board?
Otherwise a bit ocd mismatch :-)
-Daniel
> {
> struct ttm_resource_manager *man =
> ttm_manager_type(bo->bdev, bo->resource->mem_type);
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH] drm/i915: Release ctx->syncobj on final put, not on ctx close
On Mon, Aug 09, 2021 at 08:47:14PM +0200, Daniel Vetter wrote:
> On Sun, Aug 8, 2021 at 2:56 AM Jason Ekstrand wrote:
> >
> > On August 6, 2021 15:18:59 Daniel Vetter wrote:
> >
> >> gem context refcounting is another exercise in least locking design it
> >> seems, where most things get destroyed upon context closure (which can
> >> race with anything really). Only the actual memory allocation and the
> >> locks survive while holding a reference.
> >>
> >> This tripped up Jason when reimplementing the single timeline feature
> >> in
> >>
> >> commit 00dae4d3d35d4f526929633b76e00b0ab4d3970d
> >> Author: Jason Ekstrand
> >> Date: Thu Jul 8 10:48:12 2021 -0500
> >>
> >> drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)
> >>
> >> We could fix the bug by holding ctx->mutex, but it's cleaner to just
> >
> >
> > What bug is this fixing, exactly?
>
> Oh lol I was all busy ranting and not explaining :-) I found it while
> auditing other context stuff, so that other patch has the longer
> commit message with more history, but that patch is also now tied into
> the vm-dercuify, so short summary: You put the syncobj in context
> close (i.e. CTX_DESTRY ioctl or close(drmfd)), not in the final
> kref_put. Which means you're open to a use-after-free if you race
> against an execbuf. ctx->vm is equally broken (but for other ioctl),
> once this fix here is merged I send out the ctx->vm fix because that's
> tied into the vm-dercuify now due to conflicts.
CI caught more, so just explaining what I'm fixing here isn't going to be
enough.
The troubel is that drm_syncobj_put is now called from very awkward
places, and I need to see whether we can fix that. Or whether we need more
work_struct (like we have already for i915_address_space) for the final
release.
-Daniel
> -Daniel
>
> >
> > --Jason
> >
> >>
> >> make the context object actually invariant over its _entire_ lifetime.
> >>
> >> Signed-off-by: Daniel Vetter
> >> Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj
> >> (v4)")
> >> Cc: Jason Ekstrand
> >> Cc: Chris Wilson
> >> Cc: Tvrtko Ursulin
> >> Cc: Joonas Lahtinen
> >> Cc: Matthew Brost
> >> Cc: Matthew Auld
> >> Cc: Maarten Lankhorst
> >> Cc: "Thomas Hellström"
> >> Cc: Lionel Landwerlin
> >> Cc: Dave Airlie
> >> ---
> >> drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +++---
> >> 1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >> index 754b9b8d4981..93ba0197d70a 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >> @@ -940,6 +940,9 @@ void i915_gem_context_release(struct kref *ref)
> >> trace_i915_context_free(ctx);
> >> GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
> >>
> >> + if (ctx->syncobj)
> >> + drm_syncobj_put(ctx->syncobj);
> >> +
> >> mutex_destroy(>engines_mutex);
> >> mutex_destroy(>lut_mutex);
> >>
> >> @@ -1159,9 +1162,6 @@ static void context_close(struct i915_gem_context
> >> *ctx)
> >> if (vm)
> >> i915_vm_close(vm);
> >>
> >> - if (ctx->syncobj)
> >> - drm_syncobj_put(ctx->syncobj);
> >> -
> >> ctx->file_priv = ERR_PTR(-EBADF);
> >>
> >> /*
> >> --
> >> 2.32.0
> >
> >
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [V3 2/7] drm/i915/jsl: program DSI panel GPIOs
On Tue, 10 Aug 2021, Jani Nikula wrote:
>On Fri, 23 Jul 2021, Lee Shawn C wrote:
>> DSI driver should have its own implementation to toggle gpio pins
>> based on GPIO info coming from VBT sequences.
>
>Why?
>
Without this change, we are not able to control gpio signal output to
meet MIPI panel's requirement for power on/off sequence.
>>
>> Cc: Ville Syrjala
>> Cc: Jani Nikula
>> Cc: Vandita Kulkarni
>> Cc: Cooper Chiou
>> Cc: William Tseng
>> Signed-off-by: Lee Shawn C
>> ---
>> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 44 +++-
>> drivers/gpu/drm/i915/i915_reg.h | 10 +
>> 2 files changed, 53 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>> b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>> index cc93e045a425..dd03e5629ba6 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>> @@ -43,6 +43,7 @@
>> #include "intel_display_types.h"
>> #include "intel_dsi.h"
>> #include "intel_sideband.h"
>> +#include "intel_de.h"
>>
>> #define MIPI_TRANSFER_MODE_SHIFT0
>> #define MIPI_VIRTUAL_CHANNEL_SHIFT 1
>> @@ -354,7 +355,48 @@ static void bxt_exec_gpio(struct drm_i915_private
>> *dev_priv, static void icl_exec_gpio(struct drm_i915_private *dev_priv,
>>u8 gpio_source, u8 gpio_index, bool value) {
>> -drm_dbg_kms(_priv->drm, "Skipping ICL GPIO element execution\n");
>> +u32 val;
>> +
>> +switch (gpio_index) {
>> +case ICL_GPIO_L_VDDEN_1:
>> +val = intel_de_read(dev_priv, ICP_PP_CONTROL(1));
>> +if (value)
>> +val |= PWR_STATE_TARGET;
>> +else
>> +val &= ~PWR_STATE_TARGET;
>> +intel_de_write(dev_priv, ICP_PP_CONTROL(1), val);
>
>All the PPS access should be in intel_pps.[ch] and protected with the pps
>mutex.
>
OK! We will move icl_exec_gpio() into intel_pps.c and use pps mutex to protect
it.
>> +break;
>> +case ICL_GPIO_L_BKLTEN_1:
>> +val = intel_de_read(dev_priv, ICP_PP_CONTROL(1));
>> +if (value)
>> +val |= BACKLIGHT_ENABLE;
>> +else
>> +val &= ~BACKLIGHT_ENABLE;
>> +intel_de_write(dev_priv, ICP_PP_CONTROL(1), val);
>> +break;
>> +case ICL_GPIO_DDPA_CTRLCLK_1:
>> +val = intel_de_read(dev_priv, GPIO(1));
>> +if (value)
>> +val |= GPIO_CLOCK_VAL_OUT;
>> +else
>> +val &= ~GPIO_CLOCK_VAL_OUT;
>> +val |= GPIO_CLOCK_DIR_MASK | GPIO_CLOCK_DIR_OUT |
>> GPIO_CLOCK_VAL_MASK;
>> +intel_de_write(dev_priv, GPIO(1), val);
>> +break;
>> +case ICL_GPIO_DDPA_CTRLDATA_1:
>> +val = intel_de_read(dev_priv, GPIO(1));
>> +if (value)
>> +val |= GPIO_DATA_VAL_OUT;
>> +else
>> +val &= ~GPIO_DATA_VAL_OUT;
>> +val |= GPIO_DATA_DIR_MASK | GPIO_DATA_DIR_OUT |
>> GPIO_DATA_VAL_MASK;
>> +intel_de_write(dev_priv, GPIO(1), val);
>> +break;
>> +default:
>> +/* TODO: Add support for remaining GPIOs */
>> +DRM_ERROR("Invalid GPIO number (%d) from VBT\n", gpio_index);
>> +break;
>> +}
>> }
>>
>> static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8
>> *data) diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index 943fe485c662..b725234e0e9c
>> 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -5143,6 +5143,16 @@ enum {
>> #define _PP_STATUS 0x61200
>> #define PP_STATUS(pps_idx) _MMIO_PPS(pps_idx, _PP_STATUS)
>> #define PP_ON REG_BIT(31)
>> +
>> +#define _PP_CONTROL_1 0xc7204
>> +#define _PP_CONTROL_2 0xc7304
>> +#define ICP_PP_CONTROL(x) _MMIO(((x) == 1) ? _PP_CONTROL_1 : \
>> + _PP_CONTROL_2)
>> +#define POWER_CYCLE_DELAY_MASK REG_GENMASK(8, 4)
>> +#define VDD_OVERRIDE_FORCE REG_BIT(3)
>> +#define BACKLIGHT_ENABLE REG_BIT(2)
>> +#define PWR_DOWN_ON_RESET REG_BIT(1)
>> +#define PWR_STATE_TARGET REG_BIT(0)
>
>These are all duplicate defines for existing PP_CONTROL() registers and macros.
I found this patch on drm-tip branch and removed PP_CONTRL() defines.
https://patchwork.freedesktop.org/patch/291095/
Best regards,
Shawn
>
>> /*
>> * Indicates that all dependencies of the panel are on:
>> *
>
>--
>Jani Nikula, Intel Open Source Graphics Center
>
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Free all DMC payloads
On Mon, Aug 09, 2021 at 03:05:37PM -0700, Lucas De Marchi wrote: > On Mon, Aug 09, 2021 at 10:00:34PM +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Free all DMC payloads > > URL : https://patchwork.freedesktop.org/series/93521/ > > State : failure > > > > == Summary == > > > > CI Bug Log - changes from CI_DRM_10461 -> Patchwork_20789 > > > > > > Summary > > --- > > > > **FAILURE** > > > > Serious unknown changes coming with Patchwork_20789 absolutely need to be > > verified manually. > > > > If you think the reported changes have nothing to do with the changes > > introduced in Patchwork_20789, 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_20789/index.html > > > > Possible new issues > > --- > > > > Here are the unknown changes that may have been introduced in > > Patchwork_20789: > > > > ### IGT changes ### > > > > Possible regressions > > > > * igt@core_hotunplug@unbind-rebind: > >- fi-rkl-guc: [PASS][1] -> [DMESG-WARN][2] > > [1]: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10461/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html > > [2]: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20789/fi-rkl-guc/igt@core_hotunp...@unbind-rebind.html > > > AccessDenied > Access Denied > H0EEPVCR70HST0VN > 493NvO3WzGD1zhkvRRk6un+6HruE4hYwXX3W4OCSZWpluozyHRqL5h3rprp7q7erF2wu5xQa0is= > > > ??? > > I noticed this happening sometimes and working after some minutes/hours. > Is there a perm going out of sync on CI systems? Because of reasons, the patchwork post happens before syncing the files to AWS. The file sync can fail or take an undetermined amount of time so it's done asynchronously. Typically the files get synced within around 2 minutes of posting to patchwork but sometimes (~once a month) sync fails and the files get there as part of the next test result sync job. -- Petri Latvala
Re: [Intel-gfx] [V3 2/7] drm/i915/jsl: program DSI panel GPIOs
On Fri, 23 Jul 2021, Lee Shawn C wrote:
> DSI driver should have its own implementation to toggle
> gpio pins based on GPIO info coming from VBT sequences.
Why?
>
> Cc: Ville Syrjala
> Cc: Jani Nikula
> Cc: Vandita Kulkarni
> Cc: Cooper Chiou
> Cc: William Tseng
> Signed-off-by: Lee Shawn C
> ---
> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 44 +++-
> drivers/gpu/drm/i915/i915_reg.h | 10 +
> 2 files changed, 53 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> index cc93e045a425..dd03e5629ba6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
> @@ -43,6 +43,7 @@
> #include "intel_display_types.h"
> #include "intel_dsi.h"
> #include "intel_sideband.h"
> +#include "intel_de.h"
>
> #define MIPI_TRANSFER_MODE_SHIFT 0
> #define MIPI_VIRTUAL_CHANNEL_SHIFT 1
> @@ -354,7 +355,48 @@ static void bxt_exec_gpio(struct drm_i915_private
> *dev_priv,
> static void icl_exec_gpio(struct drm_i915_private *dev_priv,
> u8 gpio_source, u8 gpio_index, bool value)
> {
> - drm_dbg_kms(_priv->drm, "Skipping ICL GPIO element execution\n");
> + u32 val;
> +
> + switch (gpio_index) {
> + case ICL_GPIO_L_VDDEN_1:
> + val = intel_de_read(dev_priv, ICP_PP_CONTROL(1));
> + if (value)
> + val |= PWR_STATE_TARGET;
> + else
> + val &= ~PWR_STATE_TARGET;
> + intel_de_write(dev_priv, ICP_PP_CONTROL(1), val);
All the PPS access should be in intel_pps.[ch] and protected with the
pps mutex.
> + break;
> + case ICL_GPIO_L_BKLTEN_1:
> + val = intel_de_read(dev_priv, ICP_PP_CONTROL(1));
> + if (value)
> + val |= BACKLIGHT_ENABLE;
> + else
> + val &= ~BACKLIGHT_ENABLE;
> + intel_de_write(dev_priv, ICP_PP_CONTROL(1), val);
> + break;
> + case ICL_GPIO_DDPA_CTRLCLK_1:
> + val = intel_de_read(dev_priv, GPIO(1));
> + if (value)
> + val |= GPIO_CLOCK_VAL_OUT;
> + else
> + val &= ~GPIO_CLOCK_VAL_OUT;
> + val |= GPIO_CLOCK_DIR_MASK | GPIO_CLOCK_DIR_OUT |
> GPIO_CLOCK_VAL_MASK;
> + intel_de_write(dev_priv, GPIO(1), val);
> + break;
> + case ICL_GPIO_DDPA_CTRLDATA_1:
> + val = intel_de_read(dev_priv, GPIO(1));
> + if (value)
> + val |= GPIO_DATA_VAL_OUT;
> + else
> + val &= ~GPIO_DATA_VAL_OUT;
> + val |= GPIO_DATA_DIR_MASK | GPIO_DATA_DIR_OUT |
> GPIO_DATA_VAL_MASK;
> + intel_de_write(dev_priv, GPIO(1), val);
> + break;
> + default:
> + /* TODO: Add support for remaining GPIOs */
> + DRM_ERROR("Invalid GPIO number (%d) from VBT\n", gpio_index);
> + break;
> + }
> }
>
> static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 943fe485c662..b725234e0e9c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5143,6 +5143,16 @@ enum {
> #define _PP_STATUS 0x61200
> #define PP_STATUS(pps_idx) _MMIO_PPS(pps_idx, _PP_STATUS)
> #define PP_ON REG_BIT(31)
> +
> +#define _PP_CONTROL_10xc7204
> +#define _PP_CONTROL_20xc7304
> +#define ICP_PP_CONTROL(x)_MMIO(((x) == 1) ? _PP_CONTROL_1 : \
> + _PP_CONTROL_2)
> +#define POWER_CYCLE_DELAY_MASK REG_GENMASK(8, 4)
> +#define VDD_OVERRIDE_FORCE REG_BIT(3)
> +#define BACKLIGHT_ENABLEREG_BIT(2)
> +#define PWR_DOWN_ON_RESET REG_BIT(1)
> +#define PWR_STATE_TARGETREG_BIT(0)
These are all duplicate defines for existing PP_CONTROL() registers and
macros.
> /*
> * Indicates that all dependencies of the panel are on:
> *
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 25/46] drm/i915/guc: Update debugfs for GuC multi-lrc
On Tue, Aug 10, 2021 at 11:23:39AM +0200, Daniel Vetter wrote:
> On Mon, Aug 09, 2021 at 07:13:11PM +, Matthew Brost wrote:
> > On Mon, Aug 09, 2021 at 06:36:44PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 03, 2021 at 03:29:22PM -0700, Matthew Brost wrote:
> > > > Display the workqueue status in debugfs for GuC contexts that are in
> > > > parent-child relationship.
> > > >
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 56 +--
> > > > 1 file changed, 39 insertions(+), 17 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > index 30df1c8db491..44a7582c9aed 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > @@ -4527,31 +4527,53 @@ void intel_guc_submission_print_info(struct
> > > > intel_guc *guc,
> > > > gse_log_submission_info(guc->gse[i], p, i);
> > > > }
> > > >
> > > > +static inline void guc_log_context(struct drm_printer *p,
> > > > + struct intel_context *ce)
> > > > +{
> > > > + drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id);
> > > > + drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
> > > > + drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
> > > > + ce->ring->head,
> > > > + ce->lrc_reg_state[CTX_RING_HEAD]);
> > > > + drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
> > > > + ce->ring->tail,
> > > > + ce->lrc_reg_state[CTX_RING_TAIL]);
> > > > + drm_printf(p, "\t\tContext Pin Count: %u\n",
> > > > + atomic_read(>pin_count));
> > > > + drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
> > > > + atomic_read(>guc_id_ref));
> > > > + drm_printf(p, "\t\tNumber Requests Not Ready: %u\n",
> > > > + atomic_read(>guc_num_rq_not_ready));
> > > > + drm_printf(p, "\t\tSchedule State: 0x%x, 0x%x\n\n",
> > > > + ce->guc_state.sched_state,
> > > > + atomic_read(>guc_sched_state_no_lock));
> > >
> > > It's all debugfs, but I think proper locking even there is good. It at
> > > least reduces the confusion when the locking scheme is largely
> > > undocumented. Also given how much we have rcu for everything would be good
> > > to double-check all pointer dererences are properly protected.
> > >
> >
> > Not sure if I 100% follow this but I don't think any of the pointers
> > dref here are RCU protected. Certainly none of the GuC ones are.
> >
> > Will double before the next respin though.
> >
> > > > +}
> > > > +
> > > > void intel_guc_submission_print_context_info(struct intel_guc *guc,
> > > > struct drm_printer *p)
> > > > {
> > > > struct intel_context *ce;
> > > > unsigned long index;
> > > > xa_for_each(>context_lookup, index, ce) {
> > >
> > > xa_for_each doesn't provide any guarantees, so doesn't protect against
> > > concurrent removeal or anything like that. We need to do better than that.
> >
> > https://elixir.bootlin.com/linux/latest/source/include/linux/xarray.h#L498
> > 'It is safe to modify the array during the iteration.'
>
> The xarray. Not the thing you're dereferencing, because the xarray only
> stores pointers, not your data structure. So yeah correct statement is
> that it doesn't provide you any guarantees beyond "the iterator wont be
> confused if the xarray itself is modified during iteration". Which isn't
> what you need here, you need a lot more.
Or spelled out: The pointer you get could become immediately meaningless,
before you can look at it, due to a concurrent removal/release. All the
xa_for_each guarantees you is that on the next round you get the next
pointer, until you got them all (plus/minus concurrent changes). But that
next pointer could have become meaningless right away too.
So you need your own locking to make use of these pointers you got and
make sure they're not immediately meaningless before your loop body even
started.
One of the reasons why I think this is so important is that debugfs files
nest a lot of loops fairly often, so are good cheat-sheet for the locking
if it happens to be undocumented (which also shouldn't be the case). Ofc
if there's no locking in debugfs, no cheat-sheet :-)
Cheers, Daniel
> -Daniel
>
> >
> > Matt
> >
> > > -Daniel
> > >
> > > > - drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id);
> > > > - drm_printf(p, "\tHW Context Desc: 0x%08x\n",
> > > > ce->lrc.lrca);
> > > > - drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
> > > > - ce->ring->head,
> > > > - ce->lrc_reg_state[CTX_RING_HEAD]);
> > > > -
Re: [Intel-gfx] [PATCH 25/46] drm/i915/guc: Update debugfs for GuC multi-lrc
On Mon, Aug 09, 2021 at 07:13:11PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 06:36:44PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:22PM -0700, Matthew Brost wrote:
> > > Display the workqueue status in debugfs for GuC contexts that are in
> > > parent-child relationship.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 56 +--
> > > 1 file changed, 39 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > index 30df1c8db491..44a7582c9aed 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > @@ -4527,31 +4527,53 @@ void intel_guc_submission_print_info(struct
> > > intel_guc *guc,
> > > gse_log_submission_info(guc->gse[i], p, i);
> > > }
> > >
> > > +static inline void guc_log_context(struct drm_printer *p,
> > > +struct intel_context *ce)
> > > +{
> > > + drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id);
> > > + drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
> > > + drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
> > > +ce->ring->head,
> > > +ce->lrc_reg_state[CTX_RING_HEAD]);
> > > + drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
> > > +ce->ring->tail,
> > > +ce->lrc_reg_state[CTX_RING_TAIL]);
> > > + drm_printf(p, "\t\tContext Pin Count: %u\n",
> > > +atomic_read(>pin_count));
> > > + drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
> > > +atomic_read(>guc_id_ref));
> > > + drm_printf(p, "\t\tNumber Requests Not Ready: %u\n",
> > > +atomic_read(>guc_num_rq_not_ready));
> > > + drm_printf(p, "\t\tSchedule State: 0x%x, 0x%x\n\n",
> > > +ce->guc_state.sched_state,
> > > +atomic_read(>guc_sched_state_no_lock));
> >
> > It's all debugfs, but I think proper locking even there is good. It at
> > least reduces the confusion when the locking scheme is largely
> > undocumented. Also given how much we have rcu for everything would be good
> > to double-check all pointer dererences are properly protected.
> >
>
> Not sure if I 100% follow this but I don't think any of the pointers
> dref here are RCU protected. Certainly none of the GuC ones are.
>
> Will double before the next respin though.
>
> > > +}
> > > +
> > > void intel_guc_submission_print_context_info(struct intel_guc *guc,
> > >struct drm_printer *p)
> > > {
> > > struct intel_context *ce;
> > > unsigned long index;
> > > xa_for_each(>context_lookup, index, ce) {
> >
> > xa_for_each doesn't provide any guarantees, so doesn't protect against
> > concurrent removeal or anything like that. We need to do better than that.
>
> https://elixir.bootlin.com/linux/latest/source/include/linux/xarray.h#L498
> 'It is safe to modify the array during the iteration.'
The xarray. Not the thing you're dereferencing, because the xarray only
stores pointers, not your data structure. So yeah correct statement is
that it doesn't provide you any guarantees beyond "the iterator wont be
confused if the xarray itself is modified during iteration". Which isn't
what you need here, you need a lot more.
-Daniel
>
> Matt
>
> > -Daniel
> >
> > > - drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id);
> > > - drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
> > > - drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
> > > -ce->ring->head,
> > > -ce->lrc_reg_state[CTX_RING_HEAD]);
> > > - drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
> > > -ce->ring->tail,
> > > -ce->lrc_reg_state[CTX_RING_TAIL]);
> > > - drm_printf(p, "\t\tContext Pin Count: %u\n",
> > > -atomic_read(>pin_count));
> > > - drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
> > > -atomic_read(>guc_id_ref));
> > > - drm_printf(p, "\t\tNumber Requests Not Ready: %u\n",
> > > -atomic_read(>guc_num_rq_not_ready));
> > > - drm_printf(p, "\t\tSchedule State: 0x%x, 0x%x\n\n",
> > > -ce->guc_state.sched_state,
> > > -atomic_read(>guc_sched_state_no_lock));
> > > + GEM_BUG_ON(intel_context_is_child(ce));
> > >
> > > + guc_log_context(p, ce);
> > > guc_log_context_priority(p, ce);
> > > +
> > > + if (intel_context_is_parent(ce)) {
> > > + struct guc_process_desc *desc = __get_process_desc(ce);
> > > + struct intel_context *child;
> > > +
> > > + drm_printf(p, "\t\tWQI Head: %u\n",
> > > +READ_ONCE(desc->head));
> > > +
Re: [Intel-gfx] [PATCH 20/46] drm/i915/guc: Add hang check to GuC submit engine
On Mon, Aug 09, 2021 at 07:05:58PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 05:35:25PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:17PM -0700, Matthew Brost wrote:
> > > The heartbeat uses a single instance of a GuC submit engine (GSE) to do
> > > the hang check. As such if a different GSE's state machine hangs, the
> > > heartbeat cannot detect this hang. Add timer to each GSE which in turn
> > > can disable all submissions if it is hung.
> > >
> > > Cc: John Harrison
> > > Signed-off-by: Matthew Brost
> > > ---
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 36 +++
> > > .../i915/gt/uc/intel_guc_submission_types.h | 3 ++
> > > 2 files changed, 39 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > index afb9b4bb8971..2d8296bcc583 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > @@ -105,15 +105,21 @@ static bool tasklet_blocked(struct
> > > guc_submit_engine *gse)
> > > return test_bit(GSE_STATE_TASKLET_BLOCKED, >flags);
> > > }
> > >
> > > +/* 2 seconds seems like a reasonable timeout waiting for a G2H */
> > > +#define MAX_TASKLET_BLOCKED_NS 20
> > > static void set_tasklet_blocked(struct guc_submit_engine *gse)
> > > {
> > > lockdep_assert_held(>sched_engine.lock);
> > > + hrtimer_start_range_ns(>hang_timer,
> > > +ns_to_ktime(MAX_TASKLET_BLOCKED_NS), 0,
> > > +HRTIMER_MODE_REL_PINNED);
> > > set_bit(GSE_STATE_TASKLET_BLOCKED, >flags);
> >
> > So with drm/scheduler the reset handling is assumed to be
> > single-threaded, and there's quite complex rules around that. I've
> > recently worked with Boris Brezillion to clarify all this a bit and
> > improve docs. Does this all still work in that glorious future? Might be
> > good to at least sprinkle some comments/thoughts around in the commit
> > message about the envisaged future direction for all this stuff, to keep
> > people in the loop. Especially future people.
> >
> > Ofc plan is still to just largely land all this.
> >
> > Also: set_bit is an unordered atomic, which means you need barriers, which
> > meanes ... *insert the full rant about justifying/documenting lockless
> > algorithms from earlier *
> >
>
> lockdep_assert_held(>sched_engine.lock);
>
> Not lockless. Also spin locks act as barriers, right?
Well if that spinlock is protecting that bit then that's good, but then it
shouldn't be an atomic set_bit. In that case:
- either make the entire bitfield non-atomic so it's clear there's boring
dumb locking going on
- or split out your new bit into a separate field so that there's no false
sharing with the existing bitfield state machinery, and add a kernel doc
to that field explaining the locking
set_bit itself is atomic and unordered, so means you need barriers and all
that. If you don't have a lockless algorithm, don't use atomic bitops to
avoid confusing readers because set_bit/test_bit sets of all the warning
bells.
And yes it's annoying that for bitops the atomic ones don't have an
atomic_ prefix. The non-atomic ones have a __ prefix. This is honestly why
I don't think we should use bitfields as much as we do, because the main
use-case for them is when you have bitfields which are longer than 64bits.
They come from the cpumask world, and linux supports a lot of cpus.
Open-coding non-atomic simple bitfields with the usual C operators is
perfectly fine and legible imo. But that part is maybe more a bikeshed.
> > But I think this all falls out with the removal of the guc-id allocation
> > scheme?
>
> Yes, this patch is getting deleted.
That works too :-)
-Daniel
>
> Matt
>
> > -Daniel
> >
> > > }
> > >
> > > static void __clr_tasklet_blocked(struct guc_submit_engine *gse)
> > > {
> > > lockdep_assert_held(>sched_engine.lock);
> > > + hrtimer_cancel(>hang_timer);
> > > clear_bit(GSE_STATE_TASKLET_BLOCKED, >flags);
> > > }
> > >
> > > @@ -1028,6 +1034,7 @@ static void disable_submission(struct intel_guc
> > > *guc)
> > > if (__tasklet_is_enabled(_engine->tasklet)) {
> > > GEM_BUG_ON(!guc->ct.enabled);
> > > __tasklet_disable_sync_once(_engine->tasklet);
> > > + hrtimer_try_to_cancel(>gse[i]->hang_timer);
> > > sched_engine->tasklet.callback = NULL;
> > > }
> > > }
> > > @@ -3750,6 +3757,33 @@ static void guc_sched_engine_destroy(struct kref
> > > *kref)
> > > kfree(gse);
> > > }
> > >
> > > +static enum hrtimer_restart gse_hang(struct hrtimer *hrtimer)
> > > +{
> > > + struct guc_submit_engine *gse =
> > > + container_of(hrtimer, struct guc_submit_engine, hang_timer);
> > > + struct intel_guc *guc = gse->sched_engine.private_data;
> > > +
> > > +#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> >
Re: [Intel-gfx] [PATCH 19/46] drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids
On Mon, Aug 09, 2021 at 07:03:12PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 05:31:38PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:16PM -0700, Matthew Brost wrote:
> > > Assign contexts in parent-child relationship consecutive guc_ids. This
> > > is accomplished by partitioning guc_id space between ones that need to
> > > be consecutive (1/16 available guc_ids) and ones that do not (15/16 of
> > > available guc_ids). The consecutive search is implemented via the bitmap
> > > API.
> > >
> > > This is a precursor to the full GuC multi-lrc implementation but aligns
> > > to how GuC mutli-lrc interface is defined - guc_ids must be consecutive
> > > when using the GuC multi-lrc interface.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_context.h | 6 +
> > > drivers/gpu/drm/i915/gt/intel_reset.c | 3 +-
> > > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 7 +-
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 222 --
> > > .../i915/gt/uc/intel_guc_submission_types.h | 10 +
> > > 5 files changed, 179 insertions(+), 69 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > > b/drivers/gpu/drm/i915/gt/intel_context.h
> > > index c208691fc87d..7ce3b3d2edb7 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > > @@ -54,6 +54,12 @@ static inline bool intel_context_is_parent(struct
> > > intel_context *ce)
> > > return !!ce->guc_number_children;
> > > }
> > >
> > > +static inline struct intel_context *
> > > +intel_context_to_parent(struct intel_context *ce)
> > > +{
> > > + return intel_context_is_child(ce) ? ce->parent : ce;
> > > +}
> > > +
> > > void intel_context_bind_parent_child(struct intel_context *parent,
> > >struct intel_context *child);
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> > > b/drivers/gpu/drm/i915/gt/intel_reset.c
> > > index ea763138197f..c3d4baa1b2b8 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> > > @@ -849,6 +849,7 @@ static void reset_finish(struct intel_gt *gt,
> > > intel_engine_mask_t awake)
> > >
> > > static void nop_submit_request(struct i915_request *request)
> > > {
> > > + struct intel_context *ce = intel_context_to_parent(request->context);
> > > RQ_TRACE(request, "-EIO\n");
> > >
> > > /*
> > > @@ -857,7 +858,7 @@ static void nop_submit_request(struct i915_request
> > > *request)
> > >* this for now.
> > >*/
> > > if (intel_engine_uses_guc(request->engine))
> > > - intel_guc_decr_num_rq_not_ready(request->context);
> > > + intel_guc_decr_num_rq_not_ready(ce);
> > >
> > > request = i915_request_mark_eio(request);
> > > if (request) {
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > index c0c60ccabfa4..30a0f364db8f 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > @@ -24,6 +24,7 @@ struct __guc_ads_blob;
> > >
> > > enum {
> > > GUC_SUBMIT_ENGINE_SINGLE_LRC,
> > > + GUC_SUBMIT_ENGINE_MULTI_LRC,
> > > GUC_SUBMIT_ENGINE_MAX
> > > };
> > >
> > > @@ -59,8 +60,10 @@ struct intel_guc {
> > > struct ida guc_ids;
> > > u32 num_guc_ids;
> > > u32 max_guc_ids;
> > > - struct list_head guc_id_list_no_ref;
> > > - struct list_head guc_id_list_unpinned;
> > > + unsigned long *guc_ids_bitmap;
> > > +#define MAX_GUC_ID_ORDER (order_base_2(MAX_ENGINE_INSTANCE + 1))
> > > + struct list_head guc_id_list_no_ref[MAX_GUC_ID_ORDER + 1];
> > > + struct list_head guc_id_list_unpinned[MAX_GUC_ID_ORDER + 1];
> >
> > Random new global lists definitely need kerneldoc about what is on them,
> > how they're linked, what their lifetime rules are and what locks we're
> > holding.
> >
> > Leaving this all to reviews to figure out, and worse, future readers of
> > your code, is not kind.
> >
>
> Got it.
I forgot the usual disclaimer: I know that the current code isn't
following this at all. But wee have to start somewhere :-/
> > > spinlock_t destroy_lock;/* protects list / worker */
> > > struct list_head destroyed_contexts;
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > index f23dd716723f..afb9b4bb8971 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > @@ -169,6 +169,15 @@ static void clr_guc_ids_exhausted(struct
> > > guc_submit_engine *gse)
> > > clear_bit(GSE_STATE_GUC_IDS_EXHAUSTED, >flags);
> > > }
> > >
> > > +/*
> > > + * We reserve 1/16 of the guc_ids for multi-lrc as these need to be
> > > contiguous
> >
> > I think it'd be good to put down the reason here for why. Is this a
> > requirement of the
Re: [Intel-gfx] [PATCH 16/46] drm/i915/guc: Implement GuC parent-child context pin / unpin functions
On Tue, Aug 10, 2021 at 10:53:37AM +0200, Daniel Vetter wrote:
> On Mon, Aug 09, 2021 at 06:58:23PM +, Matthew Brost wrote:
> > On Mon, Aug 09, 2021 at 05:17:34PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 03, 2021 at 03:29:13PM -0700, Matthew Brost wrote:
> > > > Implement GuC parent-child context pin / unpin functions in which in any
> > > > contexts in the relationship are pinned all the contexts are pinned. The
> > > > parent owns most of the pinning / unpinning process and the children
> > > > direct any pins / unpins to the parent.
> > > >
> > > > Patch implements a number of unused functions that will be connected
> > > > later in the series.
> > > >
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > > drivers/gpu/drm/i915/gt/intel_context.c | 187 --
> > > > drivers/gpu/drm/i915/gt/intel_context.h | 43 +---
> > > > drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
> > > > .../drm/i915/gt/intel_execlists_submission.c | 25 ++-
> > > > drivers/gpu/drm/i915/gt/intel_lrc.c | 26 +--
> > > > drivers/gpu/drm/i915/gt/intel_lrc.h | 6 +-
> > > > .../gpu/drm/i915/gt/intel_ring_submission.c | 5 +-
> > > > drivers/gpu/drm/i915/gt/mock_engine.c | 4 +-
> > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 183 +++--
> > > > 9 files changed, 371 insertions(+), 112 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > index 8cb92b10b547..bb4c14656067 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > @@ -158,8 +158,8 @@ static void __ring_retire(struct intel_ring *ring)
> > > > intel_ring_unpin(ring);
> > > > }
> > > >
> > > > -static int intel_context_pre_pin(struct intel_context *ce,
> > > > -struct i915_gem_ww_ctx *ww)
> > > > +static int __intel_context_pre_pin(struct intel_context *ce,
> > > > + struct i915_gem_ww_ctx *ww)
> > > > {
> > > > int err;
> > > >
> > > > @@ -190,7 +190,7 @@ static int intel_context_pre_pin(struct
> > > > intel_context *ce,
> > > > return err;
> > > > }
> > > >
> > > > -static void intel_context_post_unpin(struct intel_context *ce)
> > > > +static void __intel_context_post_unpin(struct intel_context *ce)
> > > > {
> > > > if (ce->state)
> > > > __context_unpin_state(ce->state);
> > > > @@ -199,13 +199,85 @@ static void intel_context_post_unpin(struct
> > > > intel_context *ce)
> > > > __ring_retire(ce->ring);
> > > > }
> > > >
> > > > -int __intel_context_do_pin_ww(struct intel_context *ce,
> > > > - struct i915_gem_ww_ctx *ww)
> > > > +static int intel_context_pre_pin(struct intel_context *ce,
> > > > +struct i915_gem_ww_ctx *ww)
> > > > {
> > > > - bool handoff = false;
> > > > - void *vaddr;
> > > > + struct intel_context *child;
> > > > + int err, i = 0;
> > > > +
> > > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > > +
> > > > + for_each_child(ce, child) {
> > > > + err = __intel_context_pre_pin(child, ww);
> > > > + if (unlikely(err))
> > > > + goto unwind;
> > > > + ++i;
> > > > + }
> > > > +
> > > > + err = __intel_context_pre_pin(ce, ww);
> > > > + if (unlikely(err))
> > > > + goto unwind;
> > > > +
> > > > + return 0;
> > > > +
> > > > +unwind:
> > > > + for_each_child(ce, child) {
> > > > + if (!i--)
> > > > + break;
> > > > + __intel_context_post_unpin(ce);
> > > > + }
> > > > +
> > > > + return err;
> > > > +}
> > > > +
> > > > +static void intel_context_post_unpin(struct intel_context *ce)
> > > > +{
> > > > + struct intel_context *child;
> > > > +
> > > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > > +
> > > > + for_each_child(ce, child)
> > > > + __intel_context_post_unpin(child);
> > > > +
> > > > + __intel_context_post_unpin(ce);
> > > > +}
> > > > +
> > > > +static int __do_ww_lock(struct intel_context *ce,
> > > > + struct i915_gem_ww_ctx *ww)
> > > > +{
> > > > + int err = i915_gem_object_lock(ce->timeline->hwsp_ggtt->obj,
> > > > ww);
> > > > +
> > > > + if (!err && ce->ring->vma->obj)
> > > > + err = i915_gem_object_lock(ce->ring->vma->obj, ww);
> > > > + if (!err && ce->state)
> > > > + err = i915_gem_object_lock(ce->state->obj, ww);
> > > > +
> > > > + return err;
> > > > +}
> > > > +
> > > > +static int do_ww_lock(struct intel_context *ce,
> > > > + struct i915_gem_ww_ctx *ww)
> > > > +{
> > > > + struct intel_context *child;
> > > > int err = 0;
>
Re: [Intel-gfx] [PATCH 16/46] drm/i915/guc: Implement GuC parent-child context pin / unpin functions
On Mon, Aug 09, 2021 at 06:58:23PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 05:17:34PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:13PM -0700, Matthew Brost wrote:
> > > Implement GuC parent-child context pin / unpin functions in which in any
> > > contexts in the relationship are pinned all the contexts are pinned. The
> > > parent owns most of the pinning / unpinning process and the children
> > > direct any pins / unpins to the parent.
> > >
> > > Patch implements a number of unused functions that will be connected
> > > later in the series.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_context.c | 187 --
> > > drivers/gpu/drm/i915/gt/intel_context.h | 43 +---
> > > drivers/gpu/drm/i915/gt/intel_context_types.h | 4 +-
> > > .../drm/i915/gt/intel_execlists_submission.c | 25 ++-
> > > drivers/gpu/drm/i915/gt/intel_lrc.c | 26 +--
> > > drivers/gpu/drm/i915/gt/intel_lrc.h | 6 +-
> > > .../gpu/drm/i915/gt/intel_ring_submission.c | 5 +-
> > > drivers/gpu/drm/i915/gt/mock_engine.c | 4 +-
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 183 +++--
> > > 9 files changed, 371 insertions(+), 112 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > index 8cb92b10b547..bb4c14656067 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > @@ -158,8 +158,8 @@ static void __ring_retire(struct intel_ring *ring)
> > > intel_ring_unpin(ring);
> > > }
> > >
> > > -static int intel_context_pre_pin(struct intel_context *ce,
> > > - struct i915_gem_ww_ctx *ww)
> > > +static int __intel_context_pre_pin(struct intel_context *ce,
> > > +struct i915_gem_ww_ctx *ww)
> > > {
> > > int err;
> > >
> > > @@ -190,7 +190,7 @@ static int intel_context_pre_pin(struct intel_context
> > > *ce,
> > > return err;
> > > }
> > >
> > > -static void intel_context_post_unpin(struct intel_context *ce)
> > > +static void __intel_context_post_unpin(struct intel_context *ce)
> > > {
> > > if (ce->state)
> > > __context_unpin_state(ce->state);
> > > @@ -199,13 +199,85 @@ static void intel_context_post_unpin(struct
> > > intel_context *ce)
> > > __ring_retire(ce->ring);
> > > }
> > >
> > > -int __intel_context_do_pin_ww(struct intel_context *ce,
> > > - struct i915_gem_ww_ctx *ww)
> > > +static int intel_context_pre_pin(struct intel_context *ce,
> > > + struct i915_gem_ww_ctx *ww)
> > > {
> > > - bool handoff = false;
> > > - void *vaddr;
> > > + struct intel_context *child;
> > > + int err, i = 0;
> > > +
> > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > +
> > > + for_each_child(ce, child) {
> > > + err = __intel_context_pre_pin(child, ww);
> > > + if (unlikely(err))
> > > + goto unwind;
> > > + ++i;
> > > + }
> > > +
> > > + err = __intel_context_pre_pin(ce, ww);
> > > + if (unlikely(err))
> > > + goto unwind;
> > > +
> > > + return 0;
> > > +
> > > +unwind:
> > > + for_each_child(ce, child) {
> > > + if (!i--)
> > > + break;
> > > + __intel_context_post_unpin(ce);
> > > + }
> > > +
> > > + return err;
> > > +}
> > > +
> > > +static void intel_context_post_unpin(struct intel_context *ce)
> > > +{
> > > + struct intel_context *child;
> > > +
> > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > +
> > > + for_each_child(ce, child)
> > > + __intel_context_post_unpin(child);
> > > +
> > > + __intel_context_post_unpin(ce);
> > > +}
> > > +
> > > +static int __do_ww_lock(struct intel_context *ce,
> > > + struct i915_gem_ww_ctx *ww)
> > > +{
> > > + int err = i915_gem_object_lock(ce->timeline->hwsp_ggtt->obj, ww);
> > > +
> > > + if (!err && ce->ring->vma->obj)
> > > + err = i915_gem_object_lock(ce->ring->vma->obj, ww);
> > > + if (!err && ce->state)
> > > + err = i915_gem_object_lock(ce->state->obj, ww);
> > > +
> > > + return err;
> > > +}
> > > +
> > > +static int do_ww_lock(struct intel_context *ce,
> > > + struct i915_gem_ww_ctx *ww)
> > > +{
> > > + struct intel_context *child;
> > > int err = 0;
> > >
> > > + GEM_BUG_ON(intel_context_is_child(ce));
> > > +
> > > + for_each_child(ce, child) {
> > > + err = __do_ww_lock(child, ww);
> > > + if (unlikely(err))
> > > + return err;
> > > + }
> > > +
> > > + return __do_ww_lock(ce, ww);
> > > +}
> > > +
> > > +static int __intel_context_do_pin_ww(struct intel_context *ce,
> > > + struct i915_gem_ww_ctx *ww)
> > > +{
> > > + bool handoff = false;
> > > + int err;
> > > +
> > > if (unlikely(!test_bit(CONTEXT_ALLOC_BIT, >flags))) {
> > > err =
Re: [Intel-gfx] [PATCH 15/46] drm/i915/guc: Introduce context parent-child relationship
On Mon, Aug 09, 2021 at 06:44:16PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 04:37:55PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:12PM -0700, Matthew Brost wrote:
> > > Introduce context parent-child relationship. Once this relationship is
> > > created all pinning / unpinning operations are directed to the parent
> > > context. The parent context is responsible for pinning all of its'
> > > children and itself.
> > >
> > > This is a precursor to the full GuC multi-lrc implementation but aligns
> > > to how GuC mutli-lrc interface is defined - a single H2G is used
> > > register / deregister all of the contexts simultaneously.
> > >
> > > Subsequent patches in the series will implement the pinning / unpinning
> > > operations for parent / child contexts.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_context.c | 29 +++
> > > drivers/gpu/drm/i915/gt/intel_context.h | 18
> > > drivers/gpu/drm/i915/gt/intel_context_types.h | 12
> > > 3 files changed, 59 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > index 745e84c72c90..8cb92b10b547 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > @@ -395,6 +395,8 @@ intel_context_init(struct intel_context *ce, struct
> > > intel_engine_cs *engine)
> > > spin_lock_init(>guc_state.lock);
> > > INIT_LIST_HEAD(>guc_state.fences);
> > >
> > > + INIT_LIST_HEAD(>guc_child_list);
> > > +
> > > spin_lock_init(>guc_active.lock);
> > > INIT_LIST_HEAD(>guc_active.requests);
> > >
> > > @@ -414,10 +416,17 @@ intel_context_init(struct intel_context *ce, struct
> > > intel_engine_cs *engine)
> > >
> > > void intel_context_fini(struct intel_context *ce)
> > > {
> > > + struct intel_context *child, *next;
> > > +
> > > if (ce->timeline)
> > > intel_timeline_put(ce->timeline);
> > > i915_vm_put(ce->vm);
> > >
> > > + /* Need to put the creation ref for the children */
> > > + if (intel_context_is_parent(ce))
> > > + for_each_child_safe(ce, child, next)
> > > + intel_context_put(child);
> > > +
> > > mutex_destroy(>pin_mutex);
> > > i915_active_fini(>active);
> > > }
> > > @@ -533,6 +542,26 @@ struct i915_request
> > > *intel_context_find_active_request(struct intel_context *ce)
> > > return active;
> > > }
> > >
> > > +void intel_context_bind_parent_child(struct intel_context *parent,
> > > + struct intel_context *child)
> > > +{
> > > + /*
> > > + * Callers responsibility to validate that this function is used
> > > + * correctly but we use GEM_BUG_ON here ensure that they do.
> > > + */
> > > + GEM_BUG_ON(!intel_engine_uses_guc(parent->engine));
> > > + GEM_BUG_ON(intel_context_is_pinned(parent));
> > > + GEM_BUG_ON(intel_context_is_child(parent));
> > > + GEM_BUG_ON(intel_context_is_pinned(child));
> > > + GEM_BUG_ON(intel_context_is_child(child));
> > > + GEM_BUG_ON(intel_context_is_parent(child));
> > > +
> > > + parent->guc_number_children++;
> > > + list_add_tail(>guc_child_link,
> > > + >guc_child_list);
> > > + child->parent = parent;
> > > +}
> > > +
> > > #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> > > #include "selftest_context.c"
> > > #endif
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > > b/drivers/gpu/drm/i915/gt/intel_context.h
> > > index c41098950746..ad6ce5ac4824 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > > @@ -44,6 +44,24 @@ void intel_context_free(struct intel_context *ce);
> > > int intel_context_reconfigure_sseu(struct intel_context *ce,
> > > const struct intel_sseu sseu);
> > >
> > > +static inline bool intel_context_is_child(struct intel_context *ce)
> > > +{
> > > + return !!ce->parent;
> > > +}
> > > +
> > > +static inline bool intel_context_is_parent(struct intel_context *ce)
> > > +{
> > > + return !!ce->guc_number_children;
> > > +}
> > > +
> > > +void intel_context_bind_parent_child(struct intel_context *parent,
> > > + struct intel_context *child);
> > > +
> > > +#define for_each_child(parent, ce)\
> > > + list_for_each_entry(ce, &(parent)->guc_child_list, guc_child_link)
> > > +#define for_each_child_safe(parent, ce, cn)\
> > > + list_for_each_entry_safe(ce, cn, &(parent)->guc_child_list,
> > > guc_child_link)
> > > +
> > > /**
> > > * intel_context_lock_pinned - Stablises the 'pinned' status of the HW
> > > context
> > > * @ce - the context
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > index 2df79ba39867..66b22b370a72 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > +++
[Intel-gfx] [PATCH] drm/i915/gem/ttm: prefer kernel types
Avoid uintXX_t types in the driver.
Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Maarten Lankhorst
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 771eb2963123..ffda88156e32 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -168,7 +168,7 @@ i915_ttm_placement_from_obj(const struct
drm_i915_gem_object *obj,
}
static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
-uint32_t page_flags)
+u32 page_flags)
{
struct ttm_resource_manager *man =
ttm_manager_type(bo->bdev, bo->resource->mem_type);
--
2.20.1
Re: [Intel-gfx] [PATCH v2] fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
Hi Kai-Heng, Alex,
could you add your ack if the fix looks ok and you're ok if I push it to
the i915 tree?
Thanks,
Imre
On Mon, Aug 09, 2021 at 04:31:46PM +0300, Imre Deak wrote:
> Atm the EFI FB platform driver gets a runtime PM reference for the
> associated GFX PCI device during probing the EFI FB platform device and
> releases it only when the platform device gets unbound.
>
> When fbcon switches to the FB provided by the PCI device's driver (for
> instance i915/drmfb), the EFI FB will get only unregistered without the
> EFI FB platform device getting unbound, keeping the runtime PM reference
> acquired during the platform device probing. This reference will prevent
> the PCI driver from runtime suspending the device.
>
> Fix this by releasing the RPM reference from the EFI FB's destroy hook,
> called when the FB gets unregistered.
>
> While at it assert that pm_runtime_get_sync() didn't fail.
>
> v2:
> - Move pm_runtime_get_sync() before register_framebuffer() to avoid its
> race wrt. efifb_destroy()->pm_runtime_put(). (Daniel)
> - Assert that pm_runtime_get_sync() didn't fail.
> - Clarify commit message wrt. platform/PCI device/driver and driver
> removal vs. device unbinding.
>
> Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI
> D0")
> Cc: Kai-Heng Feng
> Cc: Daniel Vetter
> Reviewed-by: Daniel Vetter (v1)
> Signed-off-by: Imre Deak
> ---
> drivers/video/fbdev/efifb.c | 21 ++---
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 8ea8f079cde26..edca3703b9640 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -47,6 +47,8 @@ static bool use_bgrt = true;
> static bool request_mem_succeeded = false;
> static u64 mem_flags = EFI_MEMORY_WC | EFI_MEMORY_UC;
>
> +static struct pci_dev *efifb_pci_dev;/* dev with BAR covering the
> efifb */
> +
> static struct fb_var_screeninfo efifb_defined = {
> .activate = FB_ACTIVATE_NOW,
> .height = -1,
> @@ -243,6 +245,9 @@ static inline void efifb_show_boot_graphics(struct
> fb_info *info) {}
>
> static void efifb_destroy(struct fb_info *info)
> {
> + if (efifb_pci_dev)
> + pm_runtime_put(_pci_dev->dev);
> +
> if (info->screen_base) {
> if (mem_flags & (EFI_MEMORY_UC | EFI_MEMORY_WC))
> iounmap(info->screen_base);
> @@ -333,7 +338,6 @@ ATTRIBUTE_GROUPS(efifb);
>
> static bool pci_dev_disabled;/* FB base matches BAR of a disabled
> device */
>
> -static struct pci_dev *efifb_pci_dev;/* dev with BAR covering the
> efifb */
> static struct resource *bar_resource;
> static u64 bar_offset;
>
> @@ -569,17 +573,22 @@ static int efifb_probe(struct platform_device *dev)
> pr_err("efifb: cannot allocate colormap\n");
> goto err_groups;
> }
> +
> + if (efifb_pci_dev)
> + WARN_ON(pm_runtime_get_sync(_pci_dev->dev) < 0);
> +
> err = register_framebuffer(info);
> if (err < 0) {
> pr_err("efifb: cannot register framebuffer\n");
> - goto err_fb_dealoc;
> + goto err_put_rpm_ref;
> }
> fb_info(info, "%s frame buffer device\n", info->fix.id);
> - if (efifb_pci_dev)
> - pm_runtime_get_sync(_pci_dev->dev);
> return 0;
>
> -err_fb_dealoc:
> +err_put_rpm_ref:
> + if (efifb_pci_dev)
> + pm_runtime_put(_pci_dev->dev);
> +
> fb_dealloc_cmap(>cmap);
> err_groups:
> sysfs_remove_groups(>dev.kobj, efifb_groups);
> @@ -603,8 +612,6 @@ static int efifb_remove(struct platform_device *pdev)
> unregister_framebuffer(info);
> sysfs_remove_groups(>dev.kobj, efifb_groups);
> framebuffer_release(info);
> - if (efifb_pci_dev)
> - pm_runtime_put(_pci_dev->dev);
>
> return 0;
> }
> --
> 2.27.0
>
Re: [Intel-gfx] [PATCH v4 09/14] vfio/pci: Change vfio_pci_try_bus_reset() to use the dev_set
Looks good, Reviewed-by: Christoph Hellwig
Re: [Intel-gfx] [PATCH 14/46] drm/i915: Expose logical engine instance to user
On Mon, Aug 09, 2021 at 06:37:01PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 04:30:06PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:11PM -0700, Matthew Brost wrote:
> > > Expose logical engine instance to user via query engine info IOCTL. This
> > > is required for split-frame workloads as these needs to be placed on
> > > engines in a logically contiguous order. The logical mapping can change
> > > based on fusing. Rather than having user have knowledge of the fusing we
> > > simply just expose the logical mapping with the existing query engine
> > > info IOCTL.
> > >
> > > Cc: Tvrtko Ursulin
> > > Signed-off-by: Matthew Brost
> >
> > Uapi must have a link to the userspace MR/patch set using this, and to the
> > igt patch set validating it.
> >
>
> Have an IGT:
> https://patchwork.freedesktop.org/patch/447008/?series=93071=1
>
> Not sure when the media UMD is going to be updated upstream to use this.
> Does that mean I can't merge this until the media UMD is ready? Seems
> like it but isn't that a circular dependency? How can the media team
> develop for a new uAPI that isn't in the kernel yet?
Yes and no. Full explainer here:
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
In the drm subsystem this is pretty much the only rule where if you break
it the book will be thrown at you with extreme prejudice.
Also wrt circular: If the umd aren't set up to test their branches against
kernel branches they need to fix their stuff. I know that internally
that's not been done, and its a disaster, but in upstream there's no room
for excuses. Both kernel and userspace needs to be in branches until it's
ready for merging.
> For what it is worth the downstream release is already using this.
Yeah which is another problem, shipping new uapi in downstream before it's
in upstream is decidedly not great.
-Daniel
>
> Matt
>
> > Ideally in each patch, since it's way too hard to unfortunately find the
> > cover letter late on.
> >
> > Jason even went as far as making this a hard requirement because he wasted
> > a bit too much time trying to find the userspace for new uapi:
> >
> > https://lore.kernel.org/dri-devel/20210804185704.624883-1-ja...@jlekstrand.net/
> >
> > Cheers, Daniel
> >
> > >---
> > > drivers/gpu/drm/i915/i915_query.c | 2 ++
> > > include/uapi/drm/i915_drm.h | 8 +++-
> > > 2 files changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_query.c
> > > b/drivers/gpu/drm/i915/i915_query.c
> > > index e49da36c62fb..8a72923fbdba 100644
> > > --- a/drivers/gpu/drm/i915/i915_query.c
> > > +++ b/drivers/gpu/drm/i915/i915_query.c
> > > @@ -124,7 +124,9 @@ query_engine_info(struct drm_i915_private *i915,
> > > for_each_uabi_engine(engine, i915) {
> > > info.engine.engine_class = engine->uabi_class;
> > > info.engine.engine_instance = engine->uabi_instance;
> > > + info.flags = I915_ENGINE_INFO_HAS_LOGICAL_INSTANCE;
> > > info.capabilities = engine->uabi_capabilities;
> > > + info.logical_instance = ilog2(engine->logical_mask);
> > >
> > > if (copy_to_user(info_ptr, , sizeof(info)))
> > > return -EFAULT;
> > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > index 7f13d241417f..ef72e07fe08c 100644
> > > --- a/include/uapi/drm/i915_drm.h
> > > +++ b/include/uapi/drm/i915_drm.h
> > > @@ -2706,14 +2706,20 @@ struct drm_i915_engine_info {
> > >
> > > /** @flags: Engine flags. */
> > > __u64 flags;
> > > +#define I915_ENGINE_INFO_HAS_LOGICAL_INSTANCE(1 << 0)
> > >
> > > /** @capabilities: Capabilities of this engine. */
> > > __u64 capabilities;
> > > #define I915_VIDEO_CLASS_CAPABILITY_HEVC (1 << 0)
> > > #define I915_VIDEO_AND_ENHANCE_CLASS_CAPABILITY_SFC (1 << 1)
> > >
> > > + /** @logical_instance: Logical instance of engine */
> > > + __u16 logical_instance;
> > > +
> > > /** @rsvd1: Reserved fields. */
> > > - __u64 rsvd1[4];
> > > + __u16 rsvd1[3];
> > > + /** @rsvd2: Reserved fields. */
> > > + __u64 rsvd2[3];
> > > };
> > >
> > > /**
> > > --
> > > 2.28.0
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 13/46] drm/i915: Add logical engine mapping
On Mon, Aug 09, 2021 at 06:28:58PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 04:28:04PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:10PM -0700, Matthew Brost wrote:
> > > Add logical engine mapping. This is required for split-frame, as
> > > workloads need to be placed on engines in a logically contiguous manner.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 60 ---
> > > drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
> > > .../drm/i915/gt/intel_execlists_submission.c | 1 +
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 2 +-
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 21 +--
> > > 5 files changed, 56 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > index 0d9105a31d84..4d790f9a65dd 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > @@ -290,7 +290,8 @@ static void nop_irq_handler(struct intel_engine_cs
> > > *engine, u16 iir)
> > > GEM_DEBUG_WARN_ON(iir);
> > > }
> > >
> > > -static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id
> > > id)
> > > +static int intel_engine_setup(struct intel_gt *gt, enum intel_engine_id
> > > id,
> > > + u8 logical_instance)
> > > {
> > > const struct engine_info *info = _engines[id];
> > > struct drm_i915_private *i915 = gt->i915;
> > > @@ -334,6 +335,7 @@ static int intel_engine_setup(struct intel_gt *gt,
> > > enum intel_engine_id id)
> > >
> > > engine->class = info->class;
> > > engine->instance = info->instance;
> > > + engine->logical_mask = BIT(logical_instance);
> > > __sprint_engine_name(engine);
> > >
> > > engine->props.heartbeat_interval_ms =
> > > @@ -572,6 +574,37 @@ static intel_engine_mask_t init_engine_mask(struct
> > > intel_gt *gt)
> > > return info->engine_mask;
> > > }
> > >
> > > +static void populate_logical_ids(struct intel_gt *gt, u8 *logical_ids,
> > > + u8 class, const u8 *map, u8 num_instances)
> > > +{
> > > + int i, j;
> > > + u8 current_logical_id = 0;
> > > +
> > > + for (j = 0; j < num_instances; ++j) {
> > > + for (i = 0; i < ARRAY_SIZE(intel_engines); ++i) {
> > > + if (!HAS_ENGINE(gt, i) ||
> > > + intel_engines[i].class != class)
> > > + continue;
> > > +
> > > + if (intel_engines[i].instance == map[j]) {
> > > + logical_ids[intel_engines[i].instance] =
> > > + current_logical_id++;
> > > + break;
> > > + }
> > > + }
> > > + }
> > > +}
> > > +
> > > +static void setup_logical_ids(struct intel_gt *gt, u8 *logical_ids, u8
> > > class)
> > > +{
> > > + int i;
> > > + u8 map[MAX_ENGINE_INSTANCE + 1];
> > > +
> > > + for (i = 0; i < MAX_ENGINE_INSTANCE + 1; ++i)
> > > + map[i] = i;
> > > + populate_logical_ids(gt, logical_ids, class, map, ARRAY_SIZE(map));
> > > +}
> > > +
> > > /**
> > > * intel_engines_init_mmio() - allocate and prepare the Engine Command
> > > Streamers
> > > * @gt: pointer to struct intel_gt
> > > @@ -583,7 +616,8 @@ int intel_engines_init_mmio(struct intel_gt *gt)
> > > struct drm_i915_private *i915 = gt->i915;
> > > const unsigned int engine_mask = init_engine_mask(gt);
> > > unsigned int mask = 0;
> > > - unsigned int i;
> > > + unsigned int i, class;
> > > + u8 logical_ids[MAX_ENGINE_INSTANCE + 1];
> > > int err;
> > >
> > > drm_WARN_ON(>drm, engine_mask == 0);
> > > @@ -593,15 +627,23 @@ int intel_engines_init_mmio(struct intel_gt *gt)
> > > if (i915_inject_probe_failure(i915))
> > > return -ENODEV;
> > >
> > > - for (i = 0; i < ARRAY_SIZE(intel_engines); i++) {
> > > - if (!HAS_ENGINE(gt, i))
> > > - continue;
> > > + for (class = 0; class < MAX_ENGINE_CLASS + 1; ++class) {
> > > + setup_logical_ids(gt, logical_ids, class);
> > >
> > > - err = intel_engine_setup(gt, i);
> > > - if (err)
> > > - goto cleanup;
> > > + for (i = 0; i < ARRAY_SIZE(intel_engines); ++i) {
> > > + u8 instance = intel_engines[i].instance;
> > > +
> > > + if (intel_engines[i].class != class ||
> > > + !HAS_ENGINE(gt, i))
> > > + continue;
> > >
> > > - mask |= BIT(i);
> > > + err = intel_engine_setup(gt, i,
> > > + logical_ids[instance]);
> > > + if (err)
> > > + goto cleanup;
> > > +
> > > + mask |= BIT(i);
> > > + }
> > > }
> > >
> > > /*
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > >
Re: [Intel-gfx] [PATCH 11/46] drm/i915/guc: Don't call switch_to_kernel_context with GuC submission
On Mon, Aug 09, 2021 at 06:20:51PM +, Matthew Brost wrote: > On Mon, Aug 09, 2021 at 04:27:01PM +0200, Daniel Vetter wrote: > > On Tue, Aug 03, 2021 at 03:29:08PM -0700, Matthew Brost wrote: > > > Calling switch_to_kernel_context isn't needed if the engine PM reference > > > is taken while all contexts are pinned. By not calling > > > switch_to_kernel_context we save on issuing a request to the engine. > > > > > > Signed-off-by: Matthew Brost > > > --- > > > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 > > > 1 file changed, 4 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > index 1f07ac4e0672..58099de6bf07 100644 > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c > > > @@ -162,6 +162,10 @@ static bool switch_to_kernel_context(struct > > > intel_engine_cs *engine) > > > unsigned long flags; > > > bool result = true; > > > > > > + /* No need to switch_to_kernel_context if GuC submission */ > > > > Maybe whack a big FIXME on here that we should unravel this properly. > > Sure, can add a FIXME here. > > > Currently the execlist backend assumptions are leaked all over the place, > > leading to stuff like this. Which means extremely fragile code. > > > > Yes, this something required for execlists implemented in what should be > generic code. > > > I currently don't have a great idea on how exactly we should do that, but > > oh well. > > Me either, it will be a process. > > > > > btw just in case we ever want to make guc lrc properly evictable (which as > > the og use-case for this function, way, way back), would we need to fully > > Can you explain what you mean by fully evictable? Not getting what you > mean in this context. > > > unregister them from guc? At least I'm assuming there's no other trick > > If scheduling is disabled on the context (currently done on unpin) you are > free move anything around as the GuC is guaranteed not to touch the > context state. If on re-pin something has moved (e.g. the LRC vaddr is > different), you need to unregister and re-register the context with the > GuC. So at that point GuC also guarantees that it's not left in the hw engine? Execlist has this barrier request to fully unload the ctx from the hw, and that's also why I cam on the topic of OA. > > like the below one. > > > > Another aside: How does the perf/OA patching work on GuC? > > > > Not my area of expertise but perf somewhat a WIP. The plan is for the > GuC to write out some stats to HWSP I think? John Harrison is working to > get this fully implemented. > > OA is working afaik, with Umesh Nerlige Ramappa being the expert here. I think it's OA that I'm thinking of here: We have code in i915_perf.c to patch all the ctx currently in the system, so that they have a consistent OA config. That's also relying on this barrier stuff, and I was wondering how that will work with GuC. -Daniel > > Matt > > > Anyway, patch looks legit: > > > > Reviewed-by: Daniel Vetter > > > > > > > + if (intel_engine_uses_guc(engine)) > > > + return true; > > > + > > > /* GPU is pointing to the void, as good as in the kernel context. */ > > > if (intel_gt_is_wedged(engine->gt)) > > > return true; > > > -- > > > 2.28.0 > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 10/46] drm/i915/guc: Take engine PM when a context is pinned with GuC submission
On Mon, Aug 09, 2021 at 06:11:37PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 04:23:42PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:07PM -0700, Matthew Brost wrote:
> > > Taking a PM reference to prevent intel_gt_wait_for_idle from short
> > > circuiting while a scheduling of user context could be enabled.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/Makefile | 1 +
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 36 +--
> > > 2 files changed, 34 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > > index 903de270f2db..5e3a1e2095b0 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -103,6 +103,7 @@ gt-y += \
> > > gt/intel_gt_clock_utils.o \
> > > gt/intel_gt_irq.o \
> > > gt/intel_gt_pm.o \
> > > + gt/intel_gt_pm_unpark_work.o \
> >
> > This file isn't here?
> >
>
> Yep, included this in the wrong patch. Should be in:
> https://patchwork.freedesktop.org/patch/448462/?series=92789=2
>
> > Also pm stuff tends to have very nasty locking requirements, doing special
> > stuff like this in the backend tends to lead to really big surprises. I
> > think two options to make sure our locking design stays consistent:
> > - Lift this to generic code.
>
> Not sure I'm following this, intel_engine_pm_get/put are generic calls.
> Those calls should have all the correct annoations. If they don't we can
> add them.
But you only call them in the GuC backend, not in all of them. Which is an
inconsistency in locking, and unfortunately runtime pm is extremely nasty,
so having potentially very divergent locking behind the same interface in
the same driver is a recipe for an unmaintainable mess.
Iow, if the high-level code runs on execlist or the ringbuffer backend we
still need to go through at least the lockdep motions of what you're
adding here.
This is similar in spirit to all the might_sleep/might_lock calls we have
all over the kernel where in many cases something doesn't happen, but we
need to make sure it's allowed to have a consistent design.
So essentially in the intel_context_pin and all these functions put a
intel_engine_pm_might_get (which compiles out without debugging enabled),
unconditionally, across all platforms and sched backends.
In general I think backend specific locking (irrespective of what kind of
backend or interface you implement) is a pretty bad idea in the kernel,
and needs to be avoided if at all possible. Avoid here means "pull the
might_lock/might_sleep/might_whatever checks into generic code".
-Daniel
> Matt
>
> > - expose some engine_pm_migt_get/put() calls which do have the right set
> > of might_lock annoations, and call those in the generic code.
> >
> > Imo the worst kernel abstractions are those where all implementations
> > look the same, except for locking. Unfortunately i915-gem code is full
> > of this stuff, and we need to stop this by enlisting lockdep to check the
> > contracts for us.
> > -Daniel
> >
> > > gt/intel_gt_pm_irq.o \
> > > gt/intel_gt_requests.o \
> > > gt/intel_gtt.o \
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > index 7fe4d1559a81..c5d9548bfd00 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > @@ -2056,7 +2056,12 @@ static int guc_context_pre_pin(struct
> > > intel_context *ce,
> > >
> > > static int guc_context_pin(struct intel_context *ce, void *vaddr)
> > > {
> > > - return __guc_context_pin(ce, ce->engine, vaddr);
> > > + int ret = __guc_context_pin(ce, ce->engine, vaddr);
> > > +
> > > + if (likely(!ret && !intel_context_is_barrier(ce)))
> > > + intel_engine_pm_get(ce->engine);
> > > +
> > > + return ret;
> > > }
> > >
> > > static void guc_context_unpin(struct intel_context *ce)
> > > @@ -2067,6 +2072,9 @@ static void guc_context_unpin(struct intel_context
> > > *ce)
> > >
> > > unpin_guc_id(guc, ce, true);
> > > lrc_unpin(ce);
> > > +
> > > + if (likely(!intel_context_is_barrier(ce)))
> > > + intel_engine_pm_put(ce->engine);
> > > }
> > >
> > > static void guc_context_post_unpin(struct intel_context *ce)
> > > @@ -3002,8 +3010,30 @@ static int guc_virtual_context_pre_pin(struct
> > > intel_context *ce,
> > > static int guc_virtual_context_pin(struct intel_context *ce, void *vaddr)
> > > {
> > > struct intel_engine_cs *engine = guc_virtual_get_sibling(ce->engine, 0);
> > > + int ret = __guc_context_pin(ce, engine, vaddr);
> > > + intel_engine_mask_t tmp, mask = ce->engine->mask;
> > > +
> > > + if (likely(!ret))
> > > + for_each_engine_masked(engine, ce->engine->gt, mask, tmp)
> > > + intel_engine_pm_get(engine);
> > >
> > > - return __guc_context_pin(ce, engine, vaddr);
> >
Re: [Intel-gfx] [PATCH 0/1] Fix gem_ctx_persistence failures with GuC submission
On Wed, Jul 28, 2021 at 05:33:59PM -0700, Matthew Brost wrote: > Should fix below failures with GuC submission for the following tests: > gem_exec_balancer --r noheartbeat > gem_ctx_persistence --r heartbeat-close > > Not going to fix: > gem_ctx_persistence --r heartbeat-many > gem_ctx_persistence --r heartbeat-stop After looking at that big thread and being very confused: Are we fixing an actual use-case here, or is this another case of blindly following igts tests just because they exist? I'm leaning towards that we should stall on this, and first document what exactly is the actual intention behind all this, and then fix up the tests to match (if needed). And only then fix up GuC to match whatever we actually want to do. -Daniel > > As the above tests change the heartbeat value to 0 (off) after the > context is closed and we have no way to detect that with GuC submission > unless we keep a list of closed but running contexts which seems like > overkill for a non-real world use case. We likely should just skip these > tests with GuC submission. > > Signed-off-by: Matthew Brost > > Matthew Brost (1): > drm/i915: Check if engine has heartbeat when closing a context > > drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +++-- > drivers/gpu/drm/i915/gt/intel_context_types.h | 2 ++ > drivers/gpu/drm/i915/gt/intel_engine.h| 21 ++- > .../drm/i915/gt/intel_execlists_submission.c | 14 + > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 +- > .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 -- > 6 files changed, 26 insertions(+), 24 deletions(-) > > -- > 2.28.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Check if engine has heartbeat when closing a context
On Mon, Aug 09, 2021 at 04:12:52PM -0700, John Harrison wrote: > On 8/6/2021 12:46, Daniel Vetter wrote: > > Seen this fly by and figured I dropped a few thoughts in here. At the > > likely cost of looking a bit out of whack :-) > > > > On Fri, Aug 6, 2021 at 8:01 PM John Harrison > > wrote: > > > On 8/2/2021 02:40, Tvrtko Ursulin wrote: > > > > On 30/07/2021 19:13, John Harrison wrote: > > > > > On 7/30/2021 02:49, Tvrtko Ursulin wrote: > > > > > > On 30/07/2021 01:13, John Harrison wrote: > > > > > > > On 7/28/2021 17:34, Matthew Brost wrote: > > > > > > > > If an engine associated with a context does not have a > > > > > > > > heartbeat, > > > > > > > > ban it > > > > > > > > immediately. This is needed for GuC submission as a idle pulse > > > > > > > > doesn't > > > > > > > > kick the context off the hardware where it then can check for a > > > > > > > > heartbeat and ban the context. > > > > > > Pulse, that is a request with I915_PRIORITY_BARRIER, does not > > > > > > preempt a running normal priority context? > > > > > > > > > > > > Why does it matter then whether or not heartbeats are enabled - when > > > > > > heartbeat just ends up sending the same engine pulse (eventually, > > > > > > with raising priority)? > > > > > The point is that the pulse is pointless. See the rest of my comments > > > > > below, specifically "the context will get resubmitted to the hardware > > > > > after the pulse completes". To re-iterate... > > > > > > > > > > Yes, it preempts the context. Yes, it does so whether heartbeats are > > > > > enabled or not. But so what? Who cares? You have preempted a context. > > > > > It is no longer running on the hardware. BUT IT IS STILL A VALID > > > > > CONTEXT. > > > > It is valid yes, and it even may be the current ABI so another > > > > question is whether it is okay to change that. > > > > > > > > > The backend scheduler will just resubmit it to the hardware as soon > > > > > as the pulse completes. The only reason this works at all is because > > > > > of the horrid hack in the execlist scheduler's back end > > > > > implementation (in __execlists_schedule_in): > > > > > if (unlikely(intel_context_is_closed(ce) && > > > > >!intel_engine_has_heartbeat(engine))) > > > > > intel_context_set_banned(ce); > > > > Right, is the above code then needed with this patch - when ban is > > > > immediately applied on the higher level? > > > > > > > > > The actual back end scheduler is saying "Is this a zombie context? Is > > > > > the heartbeat disabled? Then ban it". No other scheduler backend is > > > > > going to have knowledge of zombie context status or of the heartbeat > > > > > status. Nor are they going to call back into the higher levels of the > > > > > i915 driver to trigger a ban operation. Certainly a hardware > > > > > implemented scheduler is not going to be looking at private i915 > > > > > driver information to decide whether to submit a context or whether > > > > > to tell the OS to kill it off instead. > > > > > > > > > > For persistence to work with a hardware scheduler (or a non-Intel > > > > > specific scheduler such as the DRM one), the handling of zombie > > > > > contexts, banning, etc. *must* be done entirely in the front end. It > > > > > cannot rely on any backend hacks. That means you can't rely on any > > > > > fancy behaviour of pulses. > > > > > > > > > > If you want to ban a context then you must explicitly ban that > > > > > context. If you want to ban it at some later point then you need to > > > > > track it at the top level as a zombie and then explicitly ban that > > > > > zombie at whatever later point. > > > > I am still trying to understand it all. If I go by the commit message: > > > > > > > > """ > > > > This is needed for GuC submission as a idle pulse doesn't > > > > kick the context off the hardware where it then can check for a > > > > heartbeat and ban the context. > > > > """ > > > > > > > > That did not explain things for me. Sentence does not appear to make > > > > sense. Now, it seems "kick off the hardware" is meant as revoke and > > > > not just preempt. Which is fine, perhaps just needs to be written more > > > > explicitly. But the part of checking for heartbeat after idle pulse > > > > does not compute for me. It is the heartbeat which emits idle pulses, > > > > not idle pulse emitting heartbeats. > > > I am in agreement that the commit message is confusing and does not > > > explain either the problem or the solution. > > > > > > > > > > > > > > But anyway, I can buy the handling at the front end story completely. > > > > It makes sense. We just need to agree that a) it is okay to change the > > > > ABI and b) remove the backend check from execlists if it is not needed > > > > any longer. > > > > > > > > And if ABI change is okay then commit message needs to talk about it > > > > loudly and clearly. > > > I don't think we have a choice. The current ABI is not and
Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel tree
On Mon, Aug 09, 2021 at 09:19:39AM -0700, Matt Roper wrote:
> On Mon, Aug 09, 2021 at 04:05:59PM +0200, Daniel Vetter wrote:
> > On Fri, Aug 06, 2021 at 09:36:56AM +0300, Joonas Lahtinen wrote:
> > > Hi Matt,
> > >
> > > Always use the dim tooling when applying patches, it will do the right
> > > thing with regards to adding the S-o-b.
> >
> > fd.o server rejects any pushes that haven't been done by dim, so how did
> > this get through?
>
> I definitely used dim for all of these patches, but I'm not sure how I
> lost my s-o-b on this one. Maybe when I edited the commit message after
> 'dim extract-tags' I accidentally deleted an extra line when I removed
> the extract-tags marker? It's the only patch where the line is missing,
> so it's almost certainly human error on my part rather than something
> dim did wrong.
Yeah that's an expected failure model, and dim is supposed to catch that
by rechecking for sobs when you push. See dim_push_branch ->
checkpatch_commit_push_range in dim. So you can hand-edit stuff however
you want, dim /should/ catch it when pushing. That it didn't is kinda
confusing and I'd like to know why that slipped through.
> > Matt, can you pls figure out and type up the patch to
> > plug that hole?
>
> Are you referring to a patch for dim here? The i915 patch has already
> landed, so we can't change its commit message now.
Yeah dim, not drm-intel, that can't be fixed anymore because it's all
baked in.
-Daniel
>
>
> Matt
>
> >
> > Thanks, Daniel
> >
> > >
> > > Regards, Joonas
> > >
> > > Quoting Stephen Rothwell (2021-07-15 07:18:54)
> > > > Hi all,
> > > >
> > > > Commit
> > > >
> > > > db47fe727e1f ("drm/i915/step:
> > > > s/_revid_tbl/_revids")
> > > >
> > > > is missing a Signed-off-by from its committer.
> > > >
> > > > --
> > > > Cheers,
> > > > Stephen Rothwell
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
>
> --
> Matt Roper
> Graphics Software Engineer
> VTT-OSGC Platform Enablement
> Intel Corporation
> (916) 356-2795
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Free all DMC payloads (rev2)
== Series Details ==
Series: drm/i915: Free all DMC payloads (rev2)
URL : https://patchwork.freedesktop.org/series/93521/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10462_full -> Patchwork_20790_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20790_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_pm_rpm@gem-mmap-type@fixed}:
- {shard-rkl}:NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-rkl-5/igt@i915_pm_rpm@gem-mmap-t...@fixed.html
* igt@runner@aborted:
- {shard-rkl}:NOTRUN -> ([FAIL][2], [FAIL][3], [FAIL][4],
[FAIL][5], [FAIL][6], [FAIL][7]) ([i915#1602] / [i915#2029] / [i915#3002] /
[i915#3810] / [i915#3811])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-rkl-2/igt@run...@aborted.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-rkl-1/igt@run...@aborted.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-rkl-6/igt@run...@aborted.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-rkl-6/igt@run...@aborted.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-rkl-5/igt@run...@aborted.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-rkl-2/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_20790_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-mixed-process:
- shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +1
similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-snb6/igt@gem_ctx_persiste...@engines-mixed-process.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#2846])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10462/shard-glk6/igt@gem_exec_f...@basic-deadline.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-glk6/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10462/shard-kbl7/igt@gem_exec_fair@basic-none-...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-kbl2/igt@gem_exec_fair@basic-none-...@rcs0.html
* igt@gem_exec_fair@basic-none@rcs0:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10462/shard-glk1/igt@gem_exec_fair@basic-n...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-glk7/igt@gem_exec_fair@basic-n...@rcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl: [PASS][15] -> [SKIP][16] ([fdo#109271])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10462/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html
- shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2842])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10462/shard-tglb5/igt@gem_exec_fair@basic-p...@vecs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-tglb2/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_exec_whisper@basic-fds-forked:
- shard-glk: [PASS][19] -> [DMESG-WARN][20] ([i915#118] /
[i915#95]) +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10462/shard-glk6/igt@gem_exec_whis...@basic-fds-forked.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-glk3/igt@gem_exec_whis...@basic-fds-forked.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][21] -> [SKIP][22] ([i915#2190])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10462/shard-tglb1/igt@gem_huc_c...@huc-copy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-tglb6/igt@gem_huc_c...@huc-copy.html
* igt@gem_pread@exhaustion:
- shard-apl: NOTRUN -> [WARN][23] ([i915#2658])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-apl6/igt@gem_pr...@exhaustion.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-apl: NOTRUN -> [SKIP][24] ([fdo#109271] / [i915#3323])
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20790/shard-apl6/igt@gem_userptr_bl...@dmabuf-sync.html
* igt@gem_userptr_blits@vma-merge:
- shard-apl: NOTRUN -> [FAIL][25] ([i915#3318])
[25]:
