Re: [Intel-gfx] [PATCH v2 12/14] vfio: Add cdev for vfio_device
> From: Liu, Yi L
> Sent: Monday, February 6, 2023 5:06 PM
> +
> +static struct vfio {
> + dev_t device_devt;
> +} vfio;
the structure is meaningless.
> +int vfio_device_fops_open(struct inode *inode, struct file *filep)
> +{
> + struct vfio_device *device = container_of(inode->i_cdev,
> + struct vfio_device, cdev);
> + struct vfio_device_file *df;
> + int ret;
> +
> + if (!vfio_device_try_get_registration(device))
> + return -ENODEV;
> +
> + /*
> + * device access is blocked until .open_device() is called
> + * in BIND_IOMMUFD.
> + */
this comment is more related to the whole function instead of the
following allocation code. Move it to be the function comment.
> @@ -51,6 +52,7 @@ struct vfio_device {
> /* Members below here are private, not for driver use */
> unsigned int index;
> struct device device; /* device.kref covers object life circle */
> + struct cdev cdev;
only if CDEV is configured.
Re: [Intel-gfx] [PATCH v2 13/14] vfio: Add ioctls for device cdev using iommufd
> From: Yan Zhao
> Sent: Tuesday, February 7, 2023 11:41 AM
>
> On Mon, Feb 06, 2023 at 01:05:31AM -0800, Yi Liu wrote:
> ...
>
> > +void vfio_device_cdev_close(struct vfio_device_file *df)
> > +{
> > + mutex_lock(&df->device->dev_set->lock);
> > + vfio_device_close(df);
> > + vfio_device_put_kvm(df->device);
> > + mutex_unlock(&df->device->dev_set->lock);
> > +}
> > +
>
> ...
>
> > +long vfio_device_ioctl_bind_iommufd(struct vfio_device_file *df,
> > + unsigned long arg)
> > +{
> > + struct vfio_device *device = df->device;
> > + struct vfio_device_bind_iommufd bind;
> > + struct iommufd_ctx *iommufd = NULL;
> > + unsigned long minsz;
> > + struct fd f;
> > + int ret;
> > +
> > + minsz = offsetofend(struct vfio_device_bind_iommufd, iommufd);
> > +
> > + if (copy_from_user(&bind, (void __user *)arg, minsz))
> > + return -EFAULT;
> > +
> > + if (bind.argsz < minsz || bind.flags)
> > + return -EINVAL;
> > +
> > + if (!device->ops->bind_iommufd)
> > + return -ENODEV;
> > +
> > + mutex_lock(&device->dev_set->lock);
> > + /*
> > +* If already been bound to an iommufd, or already set noiommu
> > +* then fail it.
> > +*/
> > + if (df->iommufd || df->noiommu) {
> > + ret = -EINVAL;
> > + goto out_unlock;
> > + }
> > +
> > + /* iommufd < 0 means noiommu mode */
> > + if (bind.iommufd < 0) {
> > + if (!capable(CAP_SYS_RAWIO)) {
> > + ret = -EPERM;
> > + goto out_unlock;
> > + }
> > + df->noiommu = true;
> > + } else {
> > + f = fdget(bind.iommufd);
> > + if (!f.file) {
> > + ret = -EBADF;
> > + goto out_unlock;
> > + }
> > + iommufd = iommufd_ctx_from_file(f.file);
> > + if (IS_ERR(iommufd)) {
> > + ret = PTR_ERR(iommufd);
> > + goto out_put_file;
> > + }
> > + }
> > +
> > + /*
> > +* Before the first device open, get the KVM pointer currently
> > +* associated with the device file (if there is) and obtain a
> > +* reference. This reference is held until device closed. Save
> > +* the pointer in the device for use by drivers.
> > +*/
> > + vfio_device_get_kvm_safe(df);
> > +
> > + df->iommufd = iommufd;
> > + ret = vfio_device_open(df, &bind.out_devid, NULL);
> > + if (ret)
> > + goto out_put_kvm;
> > +
> > + ret = copy_to_user((void __user *)arg + minsz,
> > + &bind.out_devid,
> > + sizeof(bind.out_devid)) ? -EFAULT : 0;
> > + if (ret)
> > + goto out_close_device;
> > +
> > + if (iommufd)
> > + fdput(f);
> > + else if (df->noiommu)
> > + dev_warn(device->dev, "vfio-noiommu device used by user
> "
> > +"(%s:%d)\n", current->comm,
> task_pid_nr(current));
> > + mutex_unlock(&device->dev_set->lock);
> > + return 0;
> > +
> > +out_close_device:
> > + vfio_device_close(df);
> vfio_device_close() is called here if any error after vfio_device_open().
> But it will also be called unconditionally in vfio_device_cdev_close() and
> cause a wrong value of device->open_count.
Oh, yes yes. Good catch. Vfio_device_cdev_close() should check either the
open_count or access_granted.
> df->access_granted in patch 07 can also be of wrong true value after
> this vfio_device_close().
access_granted will surely be wrong if open_count is not correctly
counted.
Regards,
Yi Liu
[Intel-gfx] [PATCH v9 7/7] drm/i915/dsc: Add debugfs entry to validate DSC output formats
From: Swati Sharma
DSC_Output_Format_Sink_Support entry is added to i915_dsc_fec_support_show
to depict if sink supports DSC output formats (RGB/YCbCr420/YCbCr444).
Also, new debugfs entry is created to enforce output format. This is
required because of our driver policy. For ex. if a mode is supported
in both RGB and YCbCr420 output formats by the sink, our policy is to
try RGB first and fall back to YCbCr420, if mode cannot be shown
using RGB. So, to test other output formats like YCbCr420 or YCbCr444,
we need a debugfs entry (force_dsc_output_format) to force this
output format.
Signed-off-by: Swati Sharma
---
.../drm/i915/display/intel_crtc_state_dump.c | 4 +-
.../drm/i915/display/intel_crtc_state_dump.h | 2 +
.../drm/i915/display/intel_display_debugfs.c | 77 +++
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 11 +++
5 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
index 2422d6ef5777..9913f22e0f79 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
@@ -115,13 +115,13 @@ static void snprintf_output_types(char *buf, size_t len,
WARN_ON_ONCE(output_types != 0);
}
-static const char * const output_format_str[] = {
+const char * const output_format_str[] = {
[INTEL_OUTPUT_FORMAT_RGB] = "RGB",
[INTEL_OUTPUT_FORMAT_YCBCR420] = "YCBCR4:2:0",
[INTEL_OUTPUT_FORMAT_YCBCR444] = "YCBCR4:4:4",
};
-static const char *output_formats(enum intel_output_format format)
+const char *output_formats(enum intel_output_format format)
{
if (format >= ARRAY_SIZE(output_format_str))
return "invalid";
diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.h
b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.h
index 9399c35b7e5e..daf0a7cc0702 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.h
+++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.h
@@ -8,9 +8,11 @@
struct intel_crtc_state;
struct intel_atomic_state;
+enum intel_output_format;
void intel_crtc_state_dump(const struct intel_crtc_state *crtc_state,
struct intel_atomic_state *state,
const char *context);
+const char *output_formats(enum intel_output_format format);
#endif /* __INTEL_CRTC_STATE_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 9e2fb8626c96..27b7d8dafe66 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -12,6 +12,7 @@
#include "i915_irq.h"
#include "i915_reg.h"
#include "intel_de.h"
+#include "intel_crtc_state_dump.h"
#include "intel_display_debugfs.h"
#include "intel_display_power.h"
#include "intel_display_power_well.h"
@@ -1770,6 +1771,13 @@ static int i915_dsc_fec_support_show(struct seq_file *m,
void *data)
str_yes_no(crtc_state->dsc.compression_enable));
seq_printf(m, "DSC_Sink_Support: %s\n",
str_yes_no(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)));
+ seq_printf(m, "DSC_Output_Format_Sink_Support: RGB: %s
YCBCR420: %s YCBCR444: %s\n",
+
str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
+
DP_DSC_RGB)),
+
str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
+
DP_DSC_YCbCr420_Native)),
+
str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
+
DP_DSC_YCbCr444)));
seq_printf(m, "Force_DSC_Enable: %s\n",
str_yes_no(intel_dp->force_dsc_en));
if (!intel_dp_is_edp(intel_dp))
@@ -1895,6 +1903,72 @@ static const struct file_operations i915_dsc_bpc_fops = {
.write = i915_dsc_bpc_write
};
+static int i915_dsc_output_format_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+ struct drm_device *dev = connector->dev;
+ struct drm_crtc *crtc;
+ struct intel_crtc_state *crtc_state;
+ struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
+ int ret;
+
+ if (!encoder)
+ return -ENODEV;
+
+ ret =
drm_modeset_lock_single_interruptible(&dev->mode_config.connection_mutex);
+ if (ret)
+ return ret;
+
+ crtc = connector->state->crtc;
+ if (connector->status != connector_status_connected || !crtc) {
+ ret = -ENODEV;
+ goto o
[Intel-gfx] [PATCH v9 2/7] drm/i915/dp: Check if DSC supports the given output_format
From: Ankit Nautiyal
Go with DSC only if the given output_format is supported.
v2: Use drm helper to get DSC format support for sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 30 +
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index cb4fbcd935db..73a7baccd7d0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1494,6 +1494,31 @@ static int intel_dp_dsc_compute_params(struct
intel_encoder *encoder,
return drm_dsc_compute_rc_parameters(vdsc_cfg);
}
+static bool intel_dp_dsc_supports_format(struct intel_dp *intel_dp,
+enum intel_output_format output_format)
+{
+ u8 sink_dsc_format;
+
+ switch (output_format) {
+ case INTEL_OUTPUT_FORMAT_RGB:
+ sink_dsc_format = DP_DSC_RGB;
+ break;
+ case INTEL_OUTPUT_FORMAT_YCBCR444:
+ sink_dsc_format = DP_DSC_YCbCr444;
+ break;
+ case INTEL_OUTPUT_FORMAT_YCBCR420:
+ if (min(intel_dp_source_dsc_version_minor(intel_dp),
+ intel_dp_sink_dsc_version_minor(intel_dp)) < 2)
+ return false;
+ sink_dsc_format = DP_DSC_YCbCr420_Native;
+ break;
+ default:
+ return false;
+ }
+
+ return drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
sink_dsc_format);
+}
+
int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state,
@@ -1514,11 +1539,16 @@ int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
if (!intel_dp_supports_dsc(intel_dp, pipe_config))
return -EINVAL;
+ if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
+ return -EINVAL;
+
if (compute_pipe_bpp)
pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
conn_state->max_requested_bpc);
else
pipe_bpp = pipe_config->pipe_bpp;
+ pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
conn_state->max_requested_bpc);
+
if (intel_dp->force_dsc_bpc) {
pipe_bpp = intel_dp->force_dsc_bpc * 3;
drm_dbg_kms(&dev_priv->drm, "Input DSC BPP forced to %d",
pipe_bpp);
--
2.25.1
[Intel-gfx] [PATCH v9 5/7] drm/i915: Fill in native_420 field
Now that we have laid the groundwork for YUV420 Enablement
we fill up native_420 field in vdsc_cfg and add appropriate
checks wherever required.
---v2
-adding native_422 field as 0 [Vandita]
-filling in second_line_bpg_offset, second_line_offset_adj
and nsl_bpg_offset in vds_cfg when native_420 is true
---v3
-adding display version check to solve igt issue
--v7
-remove is_pipe_dsc check as its always true for D14 [Jani]
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
drivers/gpu/drm/i915/display/intel_dp.c | 3 -
drivers/gpu/drm/i915/display/intel_vdsc.c | 72 ++-
3 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 003cac918228..f8c999fa3242 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1534,8 +1534,6 @@ static int gen11_dsi_dsc_compute_config(struct
intel_encoder *encoder,
if (crtc_state->dsc.slice_count > 1)
crtc_state->dsc.dsc_split = true;
- vdsc_cfg->convert_rgb = true;
-
/* FIXME: initialize from VBT */
vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 73a7baccd7d0..250d9cdd14b8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1470,9 +1470,6 @@ static int intel_dp_dsc_compute_params(struct
intel_encoder *encoder,
min(intel_dp_source_dsc_version_minor(intel_dp),
intel_dp_sink_dsc_version_minor(intel_dp));
- vdsc_cfg->convert_rgb = intel_dp->dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP
- DP_DSC_SUPPORT] &
- DP_DSC_RGB;
-
line_buf_depth = drm_dp_dsc_sink_line_buf_depth(intel_dp->dsc_dpcd);
if (!line_buf_depth) {
drm_dbg_kms(&i915->drm,
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index ed16f63d6355..13ad853e24eb 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -460,14 +460,47 @@ int intel_dsc_compute_params(struct intel_crtc_state
*pipe_config)
vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
pipe_config->dsc.slice_count);
-
- /* Gen 11 does not support YCbCr */
+ /*
+* According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb
is 0
+* else 1
+*/
+ vdsc_cfg->convert_rgb = !(pipe_config->output_format ==
INTEL_OUTPUT_FORMAT_YCBCR420 ||
+ pipe_config->output_format ==
INTEL_OUTPUT_FORMAT_YCBCR444);
+
+ if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ vdsc_cfg->native_420 = true;
+ /* We do not support YcBCr422 as of now */
+ vdsc_cfg->native_422 = false;
+ /* Gen 11 does not support YCbCr422 */
vdsc_cfg->simple_422 = false;
/* Gen 11 does not support VBR */
vdsc_cfg->vbr_enable = false;
/* Gen 11 only supports integral values of bpp */
vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
+ /*
+* According to DSC 1.2 specs if native_420 is set:
+* -We need to double the current bpp.
+* -second_line_bpg_offset is 12 in general and equal to
2*(slice_height-1) if slice
+* height < 8.
+* -second_line_offset_adj is 512 as shown by emperical values to yeild
best chroma
+* preservation in second line.
+* -nsl_bpg_offset is calculated as second_line_offset/slice_height -1
then rounded
+* up to 16 fractional bits, we left shift second line offset by 11 to
preserve 11
+* fractional bits.
+*/
+ if (vdsc_cfg->native_420) {
+ vdsc_cfg->bits_per_pixel <<= 1;
+ if (vdsc_cfg->slice_height >= 8)
+ vdsc_cfg->second_line_bpg_offset = 12;
+ else
+ vdsc_cfg->second_line_bpg_offset =
+ 2 * (vdsc_cfg->slice_height - 1);
+ vdsc_cfg->second_line_offset_adj = 512;
+ vdsc_cfg->nsl_bpg_offset =
DIV_ROUND_UP(vdsc_cfg->second_line_bpg_offset << 11,
+ vdsc_cfg->slice_height
- 1);
+ }
+
vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
@@ -594,8 +627,13 @@ static void intel_dsc_pps_configure(const struct
intel_crtc_state *crtc_state)
DSC_VER_MIN_SHIFT |
vdsc_cfg->bits_per_component << DSC_BPC_SHIFT |
vdsc_cfg->line_buf_depth << DSC_LINE_BUF_DEPTH_SHIFT;
- if (vdsc_cfg->dsc_version_minor == 2)
+
[Intel-gfx] [PATCH v9 6/7] drm/i915/vdsc: Check slice design requirement
Add function to check if slice design requirements are being
met as defined in Bspec: 49259 in the section
Slice Design Requirement
--v7
-remove full bspec link [Jani]
-rename intel_dsc_check_slice_design_req to
intel_dsc_slice_dimensions_valid [Jani]
--v8
-fix condition to check if slice width and height are
of two
-fix minimum pixel in slice condition
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 32 +++
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 13ad853e24eb..6ebefc195e83 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -447,6 +447,29 @@ calculate_rc_params(struct rc_parameters *rc,
}
}
+static int intel_dsc_slice_dimensions_valid(struct intel_crtc_state
*pipe_config,
+ struct drm_dsc_config *vdsc_cfg)
+{
+ if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_RGB ||
+ pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
+ if (vdsc_cfg->slice_height > 4095)
+ return -EINVAL;
+ if (vdsc_cfg->slice_height * vdsc_cfg->slice_width >= 15000)
+ return -EINVAL;
+ } else if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
+ if (vdsc_cfg->slice_width % 2)
+ return -EINVAL;
+ if (vdsc_cfg->slice_height % 2)
+ return -EINVAL;
+ if (vdsc_cfg->slice_height > 4094)
+ return -EINVAL;
+ if (vdsc_cfg->slice_height * vdsc_cfg->slice_width >= 3)
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int intel_dsc_compute_params(struct intel_crtc_state *pipe_config)
{
struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
@@ -455,11 +478,20 @@ int intel_dsc_compute_params(struct intel_crtc_state
*pipe_config)
u16 compressed_bpp = pipe_config->dsc.compressed_bpp;
const struct rc_parameters *rc_params;
struct rc_parameters *rc = NULL;
+ int err;
u8 i = 0;
vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
pipe_config->dsc.slice_count);
+
+ err = intel_dsc_slice_dimensions_valid(pipe_config, vdsc_cfg);
+
+ if (err) {
+ drm_dbg_kms(&dev_priv->drm, "Slice dimension requirements not
met\n");
+ return err;
+ }
+
/*
* According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb
is 0
* else 1
--
2.25.1
[Intel-gfx] [PATCH v9 3/7] drm/i915: Adding the new registers for DSC
Adding new DSC register which are introducted MTL onwards
Signed-off-by: Suraj Kandpal
Reviewed-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_reg.h | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 596efc940ee7..9e25e21d37e4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7715,6 +7715,8 @@ enum skl_power_gate {
#define ICL_DSC1_PICTURE_PARAMETER_SET_0(pipe) _MMIO_PIPE((pipe) - PIPE_B, \
_ICL_DSC1_PICTURE_PARAMETER_SET_0_PB, \
_ICL_DSC1_PICTURE_PARAMETER_SET_0_PC)
+#define DSC_NATIVE_422_ENABLE BIT(23)
+#define DSC_NATIVE_420_ENABLE BIT(22)
#define DSC_ALT_ICH_SEL (1 << 20)
#define DSC_VBR_ENABLE(1 << 19)
#define DSC_422_ENABLE(1 << 18)
@@ -7959,6 +7961,32 @@ enum skl_power_gate {
#define DSC_SLICE_PER_LINE(slice_per_line)((slice_per_line) << 16)
#define DSC_SLICE_CHUNK_SIZE(slice_chunk_size)
((slice_chunk_size) << 0)
+/* MTL Display Stream Compression registers */
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PB 0x782B4
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PB 0x783B4
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PC 0x784B4
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PC 0x785B4
+#define MTL_DSC0_PICTURE_PARAMETER_SET_17(pipe)_MMIO_PIPE((pipe) -
PIPE_B, \
+
_MTL_DSC0_PICTURE_PARAMETER_SET_17_PB, \
+
_MTL_DSC0_PICTURE_PARAMETER_SET_17_PC)
+#define MTL_DSC1_PICTURE_PARAMETER_SET_17(pipe)_MMIO_PIPE((pipe) -
PIPE_B, \
+
_MTL_DSC1_PICTURE_PARAMETER_SET_17_PB, \
+
_MTL_DSC1_PICTURE_PARAMETER_SET_17_PC)
+#define DSC_SL_BPG_OFFSET(offset) ((offset) << 27)
+
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PB 0x782B8
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PB 0x783B8
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PC 0x784B8
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PC 0x785B8
+#define MTL_DSC0_PICTURE_PARAMETER_SET_18(pipe)_MMIO_PIPE((pipe) -
PIPE_B, \
+
_MTL_DSC0_PICTURE_PARAMETER_SET_18_PB, \
+
_MTL_DSC0_PICTURE_PARAMETER_SET_18_PC)
+#define MTL_DSC1_PICTURE_PARAMETER_SET_18(pipe)_MMIO_PIPE((pipe) -
PIPE_B, \
+
_MTL_DSC1_PICTURE_PARAMETER_SET_18_PB, \
+
_MTL_DSC1_PICTURE_PARAMETER_SET_18_PC)
+#define DSC_NSL_BPG_OFFSET(offset) ((offset) << 16)
+#define DSC_SL_OFFSET_ADJ(offset) ((offset) << 0)
+
/* Icelake Rate Control Buffer Threshold Registers */
#define DSCA_RC_BUF_THRESH_0 _MMIO(0x6B230)
#define DSCA_RC_BUF_THRESH_0_UDW _MMIO(0x6B230 + 4)
--
2.25.1
[Intel-gfx] [PATCH v9 0/7] Enable YCbCr420 for VDSC
This patch series aims to enable the YCbCr420 format for DSC. Changes are mostly compute params related for hdmi,dp and dsi along with the addition of new rc_tables for native_420 and corresponding changes to macros used to fetch them. ---v2 -add fields missed for vdsc_cfg [Vandita] -add corresponding registers and writing to the [Vandita] ---v3 -add 11 bit left shift missed in nsl_bpg_offset calculation ---v4 -add display version check before writing in new pps register ---v5 -add helper to check if sink supports given format with DSC -add debugfs entry to enforce DSC with YCbCr420 format only --v6 -add patch to check dsc slice design requirement [Vandita] --v7 -fix function name to intel_slice_dimensions_valid [Jani] -remove full bspec link just add the ref number [Jani] -remove patches for debug fs will float them as a seprate series -Add more description for YUV420 Enablement [Vandita] --v8 -fix slice width and height 2's multiple check -fix minimum pixel requirement in slice check --v9 -Add debugfs entry to validate output format Ankit Nautiyal (2): drm/dp_helper: Add helper to check if the sink supports given format with DSC drm/i915/dp: Check if DSC supports the given output_format Suraj Kandpal (4): drm/i915: Adding the new registers for DSC drm/i915: Enable YCbCr420 for VDSC drm/i915: Fill in native_420 field drm/i915/vdsc: Check slice design requirement Swati Sharma (1): drm/i915/dsc: Add debugfs entry to validate DSC output formats drivers/gpu/drm/i915/display/icl_dsi.c| 2 - .../drm/i915/display/intel_crtc_state_dump.c | 4 +- .../drm/i915/display/intel_crtc_state_dump.h | 2 + .../drm/i915/display/intel_display_debugfs.c | 77 .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_dp.c | 44 - .../gpu/drm/i915/display/intel_qp_tables.c| 187 -- .../gpu/drm/i915/display/intel_qp_tables.h| 4 +- drivers/gpu/drm/i915/display/intel_vdsc.c | 106 +- drivers/gpu/drm/i915/i915_reg.h | 28 +++ include/drm/display/drm_dp_helper.h | 7 + 11 files changed, 438 insertions(+), 24 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH v9 4/7] drm/i915: Enable YCbCr420 for VDSC
Implementation of VDSC for YCbCr420.
Add QP tables for 8,10,12 BPC from rc_tables.h in intel_qp_tables.c
(Derived from C-Model, which is given along with DSC1.2a Spec from Vesa)
intel_lookup_range_min/max_qp functons need to take into account the
output format. Based on that appropriate qp table need to be chosen.
Other rc_parameters need to be set where currently values for 444 format
is hardcoded in calculate_rc_parameters( ).
vdsc_cfg struct needs to be filled with output format information, where
these are hardcoded for 444 format.
Bspec: 49259
Signed-off-by: Suraj Kandpal
Reviewed-by: Vandita Kulkarni
---
.../gpu/drm/i915/display/intel_qp_tables.c| 187 --
.../gpu/drm/i915/display/intel_qp_tables.h| 4 +-
drivers/gpu/drm/i915/display/intel_vdsc.c | 4 +-
3 files changed, 180 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_qp_tables.c
b/drivers/gpu/drm/i915/display/intel_qp_tables.c
index 6f8e4ec5c0fb..6e86c0971d24 100644
--- a/drivers/gpu/drm/i915/display/intel_qp_tables.c
+++ b/drivers/gpu/drm/i915/display/intel_qp_tables.c
@@ -17,6 +17,15 @@
/* from BPP 6 to 36 in steps of 0.5 */
#define RC_RANGE_QP444_12BPC_MAX_NUM_BPP 61
+/* from BPP 6 to 24 in steps of 0.5 */
+#define RC_RANGE_QP420_8BPC_MAX_NUM_BPP17
+
+/* from BPP 6 to 30 in steps of 0.5 */
+#define RC_RANGE_QP420_10BPC_MAX_NUM_BPP 23
+
+/* from BPP 6 to 36 in steps of 0.5 */
+#define RC_RANGE_QP420_12BPC_MAX_NUM_BPP 29
+
/*
* These qp tables are as per the C model
* and it has the rows pointing to bpps which increment
@@ -283,26 +292,182 @@ static const u8
rc_range_maxqp444_12bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP444_12BPC
11, 11, 10, 10, 10, 10, 10, 9, 9, 8, 8, 8, 8, 8, 7, 7, 6, 6, 6, 6, 5,
5, 4 }
};
-#define PARAM_TABLE(_minmax, _bpc, _row, _col) do { \
- if (bpc == (_bpc)) \
- return rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+static const u8
rc_range_minqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8BPC_MAX_NUM_BPP] = {
+ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 3, 3, 3, 3, 3, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0 },
+ { 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
+ { 3, 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
+ { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
+ { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 0 },
+ { 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 2, 1, 1 },
+ { 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 3, 3, 3, 3, 2, 1, 1 },
+ { 5, 5, 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4, 3, 2, 2, 1 },
+ { 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 4, 4, 3, 3, 2, 1 },
+ { 9, 8, 8, 7, 7, 7, 7, 7, 7, 6, 5, 5, 4, 3, 3, 3, 2 },
+ { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3 }
+};
+
+static const u8
rc_range_maxqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8BPC_MAX_NUM_BPP] = {
+ { 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 4, 4, 4, 4, 4, 3, 2, 2, 1, 1, 1, 1, 0, 0, 0, 0, 0 },
+ { 5, 5, 5, 5, 5, 4, 3, 2, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
+ { 6, 6, 6, 6, 6, 5, 4, 3, 2, 2, 2, 1, 1, 1, 1, 0, 0 },
+ { 7, 7, 7, 7, 7, 5, 4, 3, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
+ { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 2, 2, 2, 1, 1, 0 },
+ { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 3, 2, 2, 2, 1, 1 },
+ { 8, 8, 8, 8, 8, 7, 6, 5, 4, 4, 4, 3, 3, 2, 2, 2, 1 },
+ { 9, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1 },
+ { 10, 10, 9, 9, 9, 8, 7, 6, 5, 5, 5, 4, 4, 3, 3, 2, 2 },
+ { 10, 10, 10, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 2, 2 },
+ { 11, 11, 10, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4, 3, 3, 2 },
+ { 11, 11, 11, 10, 9, 9, 9, 8, 7, 7, 6, 5, 5, 4, 4, 3, 2 },
+ { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 4, 4, 4, 3 },
+ { 14, 13, 13, 12, 11, 11, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4 }
+};
+
+static const u8
rc_range_minqp420_10bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_10BPC_MAX_NUM_BPP] =
{
+ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 4, 4, 4, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 4, 4, 4, 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 5, 5, 5, 4, 4, 4, 4, 4, 4, 3, 3, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0 },
+ { 7, 7, 7, 6, 6, 5, 5, 4, 4, 3, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0 },
+ { 7, 7, 7, 7, 7, 6, 5, 5, 5, 5, 5, 4, 3, 3, 2, 2, 1, 1, 1, 1, 1, 0, 0 },
+ { 7, 7, 7, 7, 7, 6, 6, 5, 5, 5, 5, 4, 4, 4, 3, 2, 2, 2, 2, 1, 1, 1, 0 },
+ { 7, 7, 7, 7, 7, 7, 6, 6, 6, 6, 6, 5, 4, 4, 4, 3, 2, 2, 2, 1, 1, 1, 0 },
+ { 7, 7, 7, 7, 7, 7, 7, 7, 6, 6, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 2, 1, 1 },
+ { 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 6, 6, 5, 5, 4, 4, 3,
[Intel-gfx] [PATCH v9 1/7] drm/dp_helper: Add helper to check if the sink supports given format with DSC
From: Ankit Nautiyal
Add helper function to check if the DP sink supports DSC with the given
output format.
Signed-off-by: Ankit Nautiyal
---
include/drm/display/drm_dp_helper.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index ab55453f2d2c..d529d0254b68 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -194,6 +194,13 @@ drm_dp_dsc_sink_max_slice_width(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
DP_DSC_SLICE_WIDTH_MULTIPLIER;
}
+/* Check if sink supports DSC with given output format */
+static inline bool
+drm_dp_dsc_sink_supports_format(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
u8 output_format)
+{
+ return dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP - DP_DSC_SUPPORT] &
output_format;
+}
+
/* Forward Error Correction Support on DP 1.4 */
static inline bool
drm_dp_sink_supports_fec(const u8 fec_capable)
--
2.25.1
Re: [Intel-gfx] [PATCH v6 8/9] drm/i915/dsc: Allow DSC only with YCbCr420 format when forced from debugfs
Hi Jani, Thanks for the review. Have floated https://patchwork.freedesktop.org/patch/521301/ addressing your review comments. Corresponding IGT https://patchwork.freedesktop.org/series/113253/ On 11-Jan-23 7:24 PM, Jani Nikula wrote: On Wed, 11 Jan 2023, Suraj Kandpal wrote: From: Swati Sharma If force_dsc_ycbcr420_en is set through debugfs allow DSC iff output_format is INTEL_OUTPUT_FORMAT_YCBCR420. Squash this with the previous patch. Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/display/intel_dp.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 2adac42e585d..666ee85dd23a 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -1528,6 +1528,10 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp, if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format)) return -EINVAL; + if (intel_dp->force_dsc_ycbcr420_en && + pipe_config->output_format != INTEL_OUTPUT_FORMAT_YCBCR420) + return -EINVAL; It would be more generally useful, and perhaps even cleaner to implement, to force the output format, as in *any* output format, instead of having a specific force_dsc_ycbcr420_en. BR, Jani. + if (compute_pipe_bpp) pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, conn_state->max_requested_bpc); else -- ~Swati Sharma
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix eDP+DSI dual panel systems
== Series Details ==
Series: drm/i915: Fix eDP+DSI dual panel systems
URL : https://patchwork.freedesktop.org/series/113728/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12707 -> Patchwork_113728v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_113728v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_113728v1, 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_113728v1/index.html
Participating hosts (37 -> 35)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113728v1:
### IGT changes ###
Possible regressions
* igt@gem_exec_suspend@basic-s3@smem:
- fi-cfl-8700k: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/fi-cfl-8700k/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v1/fi-cfl-8700k/igt@gem_exec_suspend@basic...@smem.html
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-elk-e7500: [PASS][3] -> [FAIL][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/fi-elk-e7500/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v1/fi-elk-e7500/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@load:
- {bat-atsm-1}: [PASS][5] -> [ABORT][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/bat-atsm-1/igt@i915_module_l...@load.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v1/bat-atsm-1/igt@i915_module_l...@load.html
* igt@i915_selftest@live@guc:
- {bat-rpls-2}: [PASS][7] -> [DMESG-FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/bat-rpls-2/igt@i915_selftest@l...@guc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v1/bat-rpls-2/igt@i915_selftest@l...@guc.html
* igt@i915_selftest@live@slpc:
- {bat-rpls-2}: [DMESG-FAIL][9] ([i915#6367]) -> [ABORT][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/bat-rpls-2/igt@i915_selftest@l...@slpc.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html
Known issues
Here are the changes found in Patchwork_113728v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_suspend@basic-s3-without-i915:
- fi-elk-e7500: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/fi-elk-e7500/igt@i915_susp...@basic-s3-without-i915.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v1/fi-elk-e7500/igt@i915_susp...@basic-s3-without-i915.html
Possible fixes
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][13] ([i915#7229]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@i915_selftest@live@gt_lrc:
- {bat-dg2-11}: [INCOMPLETE][15] ([i915#7609] / [i915#7913]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113728v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
[i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
[i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
Build changes
-
* Linux: CI_DRM_12707 -> Patchwork_113728v1
CI-20190529: 20190529
CI_DRM_12707: 4553eb97820406ff3cbc51a3348ffabfe3b3110e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7152: 790b81207a0a6705213ec
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix eDP+DSI dual panel systems
== Series Details == Series: drm/i915: Fix eDP+DSI dual panel systems URL : https://patchwork.freedesktop.org/series/113728/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm
[Intel-gfx] [PATCH 3/3] drm/i915: Pick the backlight controller based on VBT on ICP+
From: Ville Syrjälä
Use the second backlight controller on ICP+ if the VBT asks
us to do so.
On pre-MTP we also check the chicken bit to make sure the
pins have been correctly muxed by the firmware.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_backlight.c| 34 +--
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 5b7da72c95b8..a4e4b7f79e4d 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -1431,6 +1431,30 @@ bxt_setup_backlight(struct intel_connector *connector,
enum pipe unused)
return 0;
}
+static int cnp_num_backlight_controllers(struct drm_i915_private *i915)
+{
+ if (INTEL_PCH_TYPE(i915) >= PCH_DG1)
+ return 1;
+
+ if (INTEL_PCH_TYPE(i915) >= PCH_ICP)
+ return 2;
+
+ return 1;
+}
+
+static bool cnp_backlight_controller_is_valid(struct drm_i915_private *i915,
int controller)
+{
+ if (controller < 0 || controller >= cnp_num_backlight_controllers(i915))
+ return false;
+
+ if (controller == 1 &&
+ INTEL_PCH_TYPE(i915) >= PCH_ICP &&
+ INTEL_PCH_TYPE(i915) < PCH_MTP)
+ return intel_de_read(i915, SOUTH_CHICKEN1) &
ICP_SECOND_PPS_IO_SELECT;
+
+ return true;
+}
+
static int
cnp_setup_backlight(struct intel_connector *connector, enum pipe unused)
{
@@ -1440,10 +1464,14 @@ cnp_setup_backlight(struct intel_connector *connector,
enum pipe unused)
/*
* CNP has the BXT implementation of backlight, but with only one
-* controller. TODO: ICP has multiple controllers but we only use
-* controller 0 for now.
+* controller. ICP+ can have two controllers, depending on pin muxing.
*/
- panel->backlight.controller = 0;
+ panel->backlight.controller = connector->panel.vbt.backlight.controller;
+ if (!cnp_backlight_controller_is_valid(i915,
panel->backlight.controller)) {
+ drm_dbg_kms(&i915->drm, "Invalid backlight controller %d,
assuming 0\n",
+ panel->backlight.controller);
+ panel->backlight.controller = 0;
+ }
pwm_ctl = intel_de_read(i915,
BXT_BLC_PWM_CTL(panel->backlight.controller));
--
2.39.1
[Intel-gfx] [PATCH 2/3] drm/i915: Populate encoder->devdata for DSI on icl+
From: Ville Syrjälä
We now have some eDP+DSI dual panel systems floating around
where the DSI panel is the secondary LFP and thus needs to
consult "panel type 2" in VBT in order to locate all the
other panel type dependante stuff correctly.
To that end we need to pass in the devdata to
intel_bios_init_panel_late(), otherwise it'll just assume
we want the primary panel type. So let's try to just populate
the vbt.ports[] stuff and encoder->devdata for icl+ DSI
panels as well.
We can't do this on older platforms as there we risk a DSI
port aliasing with a HDMI/DP port, which is a totally legal
thing as the DSI ports live in their own little parallel
universe.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/icl_dsi.c| 3 ++-
drivers/gpu/drm/i915/display/intel_bios.c | 15 ---
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 003cac918228..05e749861658 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1951,7 +1951,8 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
/* attach connector to encoder */
intel_connector_attach_encoder(intel_connector, encoder);
- intel_bios_init_panel_late(dev_priv, &intel_connector->panel, NULL,
NULL);
+ encoder->devdata = intel_bios_encoder_data_lookup(dev_priv, port);
+ intel_bios_init_panel_late(dev_priv, &intel_connector->panel,
encoder->devdata, NULL);
mutex_lock(&dev_priv->drm.mode_config.mutex);
intel_panel_add_vbt_lfp_fixed_mode(intel_connector);
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 06a2d98d2277..1cd8af88ce50 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2593,6 +2593,12 @@ intel_bios_encoder_supports_edp(const struct
intel_bios_encoder_data *devdata)
devdata->child.device_type & DEVICE_TYPE_INTERNAL_CONNECTOR;
}
+static bool
+intel_bios_encoder_supports_dsi(const struct intel_bios_encoder_data *devdata)
+{
+ return devdata->child.device_type & DEVICE_TYPE_MIPI_OUTPUT;
+}
+
static int _intel_bios_hdmi_level_shift(const struct intel_bios_encoder_data
*devdata)
{
if (!devdata || devdata->i915->display.vbt.version < 158)
@@ -2643,7 +2649,7 @@ static void print_ddi_port(const struct
intel_bios_encoder_data *devdata,
{
struct drm_i915_private *i915 = devdata->i915;
const struct child_device_config *child = &devdata->child;
- bool is_dvi, is_hdmi, is_dp, is_edp, is_crt, supports_typec_usb,
supports_tbt;
+ bool is_dvi, is_hdmi, is_dp, is_edp, is_dsi, is_crt,
supports_typec_usb, supports_tbt;
int dp_boost_level, dp_max_link_rate, hdmi_boost_level,
hdmi_level_shift, max_tmds_clock;
is_dvi = intel_bios_encoder_supports_dvi(devdata);
@@ -2651,13 +2657,14 @@ static void print_ddi_port(const struct
intel_bios_encoder_data *devdata,
is_crt = intel_bios_encoder_supports_crt(devdata);
is_hdmi = intel_bios_encoder_supports_hdmi(devdata);
is_edp = intel_bios_encoder_supports_edp(devdata);
+ is_dsi = intel_bios_encoder_supports_dsi(devdata);
supports_typec_usb = intel_bios_encoder_supports_typec_usb(devdata);
supports_tbt = intel_bios_encoder_supports_tbt(devdata);
drm_dbg_kms(&i915->drm,
- "Port %c VBT info: CRT:%d DVI:%d HDMI:%d DP:%d eDP:%d
LSPCON:%d USB-Type-C:%d TBT:%d DSC:%d\n",
- port_name(port), is_crt, is_dvi, is_hdmi, is_dp, is_edp,
+ "Port %c VBT info: CRT:%d DVI:%d HDMI:%d DP:%d eDP:%d
DSI:%d LSPCON:%d USB-Type-C:%d TBT:%d DSC:%d\n",
+ port_name(port), is_crt, is_dvi, is_hdmi, is_dp, is_edp,
is_dsi,
HAS_LSPCON(i915) && child->lspcon,
supports_typec_usb, supports_tbt,
devdata->dsc != NULL);
@@ -2710,6 +2717,8 @@ static void parse_ddi_port(struct intel_bios_encoder_data
*devdata)
enum port port;
port = dvo_port_to_port(i915, child->dvo_port);
+ if (port == PORT_NONE && DISPLAY_VER(i915) >= 11)
+ port = dsi_dvo_port_to_port(i915, child->dvo_port);
if (port == PORT_NONE)
return;
--
2.39.1
[Intel-gfx] [PATCH 1/3] drm/i915: Fix VBT DSI DVO port handling
From: Ville Syrjälä
Turns out modern (icl+) VBTs still declare their DSI ports
as MIPI-A and MIPI-C despite the PHYs now being A and B.
Remap appropriately to allow the panels declared as MIPI-C
to work.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 33 ---
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index e6ca51232dcf..06a2d98d2277 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2467,6 +2467,22 @@ static enum port dvo_port_to_port(struct
drm_i915_private *i915,
dvo_port);
}
+static enum port
+dsi_dvo_port_to_port(struct drm_i915_private *i915, u8 dvo_port)
+{
+ switch (dvo_port) {
+ case DVO_PORT_MIPIA:
+ return PORT_A;
+ case DVO_PORT_MIPIC:
+ if (DISPLAY_VER(i915) >= 11)
+ return PORT_B;
+ else
+ return PORT_C;
+ default:
+ return PORT_NONE;
+ }
+}
+
static int parse_bdb_230_dp_max_link_rate(const int vbt_max_link_rate)
{
switch (vbt_max_link_rate) {
@@ -3442,19 +3458,16 @@ bool intel_bios_is_dsi_present(struct drm_i915_private
*i915,
dvo_port = child->dvo_port;
- if (dvo_port == DVO_PORT_MIPIA ||
- (dvo_port == DVO_PORT_MIPIB && DISPLAY_VER(i915) >= 11) ||
- (dvo_port == DVO_PORT_MIPIC && DISPLAY_VER(i915) < 11)) {
- if (port)
- *port = dvo_port - DVO_PORT_MIPIA;
- return true;
- } else if (dvo_port == DVO_PORT_MIPIB ||
- dvo_port == DVO_PORT_MIPIC ||
- dvo_port == DVO_PORT_MIPID) {
+ if (dsi_dvo_port_to_port(i915, dvo_port) == PORT_NONE) {
drm_dbg_kms(&i915->drm,
"VBT has unsupported DSI port %c\n",
port_name(dvo_port - DVO_PORT_MIPIA));
+ continue;
}
+
+ if (port)
+ *port = dsi_dvo_port_to_port(i915, dvo_port);
+ return true;
}
return false;
@@ -3539,7 +3552,7 @@ bool intel_bios_get_dsc_params(struct intel_encoder
*encoder,
if (!(child->device_type & DEVICE_TYPE_MIPI_OUTPUT))
continue;
- if (child->dvo_port - DVO_PORT_MIPIA == encoder->port) {
+ if (dsi_dvo_port_to_port(i915, child->dvo_port) ==
encoder->port) {
if (!devdata->dsc)
return false;
--
2.39.1
[Intel-gfx] [PATCH 0/3] drm/i915: Fix eDP+DSI dual panel systems
From: Ville Syrjälä Several fixes to light up the secondary (DSI) panel on Lenovo ThinkBook Plus Gen 3. References: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Ville Syrjälä (3): drm/i915: Fix VBT DSI DVO port handling drm/i915: Populate encoder->devdata for DSI on icl+ drm/i915: Pick the backlight controller based on VBT on ICP+ drivers/gpu/drm/i915/display/icl_dsi.c| 3 +- .../gpu/drm/i915/display/intel_backlight.c| 34 +++-- drivers/gpu/drm/i915/display/intel_bios.c | 48 ++- 3 files changed, 68 insertions(+), 17 deletions(-) -- 2.39.1
Re: [Intel-gfx] [PATCH v2 11/14] vfio: Make vfio_device_open() exclusive between group path and device cdev path
> From: Liu, Yi L
> Sent: Monday, February 6, 2023 5:05 PM
>
> struct vfio_device_file *
> -vfio_allocate_device_file(struct vfio_device *device)
> +vfio_allocate_device_file(struct vfio_device *device, bool is_cdev_device)
> {
> struct vfio_device_file *df;
>
> @@ -407,6 +407,7 @@ vfio_allocate_device_file(struct vfio_device *device)
> return ERR_PTR(-ENOMEM);
>
> df->device = device;
> + df->is_cdev_device = is_cdev_device;
You missed Alex's comment that the one caller can open code the
assignment instead of introducing an unmemorable Boolean arg here.
>
> + /*
> + * Device cdev path cannot support multiple device open since
> + * it doesn't have a secure way for it. So a second device
> + * open attempt should be failed if the caller is from a cdev
> + * path or the device has already been opened by a cdev path.
> + */
> + if (device->open_count != 0 &&
> + (df->is_cdev_device || device->single_open))
> + return -EINVAL;
> +
If we are gonna handle the exclusive open via dma ownership, then
here we don't need a new single_open flag inside vfio_device since
only one interface (cdev or group) could be used to open this device.
Just preventing multi-open in cdev is sufficient here.
Re: [Intel-gfx] [PATCH v2 10/14] vfio-iommufd: Add detach_ioas for emulated VFIO devices
> From: Liu, Yi L
> Sent: Monday, February 6, 2023 5:05 PM
> @@ -149,14 +149,18 @@ int vfio_iommufd_emulated_bind(struct
> vfio_device *vdev,
> }
> EXPORT_SYMBOL_GPL(vfio_iommufd_emulated_bind);
>
> +static void __vfio_iommufd_access_destroy(struct vfio_device *vdev)
> +{
> + iommufd_access_destroy(vdev->iommufd_access);
> + vdev->iommufd_access = NULL;
> +}
> +
> void vfio_iommufd_emulated_unbind(struct vfio_device *vdev)
> {
> lockdep_assert_held(&vdev->dev_set->lock);
>
> - if (vdev->iommufd_access) {
> - iommufd_access_destroy(vdev->iommufd_access);
> - vdev->iommufd_access = NULL;
> - }
> + if (vdev->iommufd_access)
> + __vfio_iommufd_access_destroy(vdev);
same comment as in last patch.
Re: [Intel-gfx] [PATCH v2 09/14] vfio-iommufd: Add detach_ioas support for physical VFIO devices
> From: Liu, Yi L
> Sent: Monday, February 6, 2023 5:05 PM
>
> +static void __vfio_iommufd_detach(struct vfio_device *vdev)
> +{
> + iommufd_device_detach(vdev->iommufd_device);
> + vdev->iommufd_attached = false;
> +}
> +
> void vfio_iommufd_physical_unbind(struct vfio_device *vdev)
> {
> lockdep_assert_held(&vdev->dev_set->lock);
>
> - if (vdev->iommufd_attached) {
> - iommufd_device_detach(vdev->iommufd_device);
> - vdev->iommufd_attached = false;
> - }
> + if (vdev->iommufd_attached)
> + __vfio_iommufd_detach(vdev);
I'm not sure whether this abstraction really improves things.
Just two callers. and the old code reads clearer to me which
checks a flag, does something and then clear the flag.
> @@ -74,6 +74,7 @@ struct vfio_device {
> * @unbind_iommufd: Opposite of bind_iommufd
> * @attach_ioas: Called when attaching device to an IOAS/HWPT managed
> by the
> *bound iommufd. Undo in unbind_iommufd.
"Undo in unbind_iommufd if @detach_ioas is not called".
> + * @detach_ioas: Opposite of attach_ioas, this is for runtime undo.
remove "this is for runtime undo" which is confusing.
[Intel-gfx] ✓ Fi.CI.BAT: success for More drm_dbg to guc_dbg changes (rev2)
== Series Details ==
Series: More drm_dbg to guc_dbg changes (rev2)
URL : https://patchwork.freedesktop.org/series/113624/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12707 -> Patchwork_113624v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/index.html
Participating hosts (37 -> 34)
--
Missing(3): fi-kbl-soraka bat-atsm-1 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113624v2 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- {bat-dg2-11}: [INCOMPLETE][1] ([i915#7609] / [i915#7913]) ->
[PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12707/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7982]: https://gitlab.freedesktop.org/drm/intel/issues/7982
Build changes
-
* Linux: CI_DRM_12707 -> Patchwork_113624v2
CI-20190529: 20190529
CI_DRM_12707: 4553eb97820406ff3cbc51a3348ffabfe3b3110e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7152: 790b81207a0a6705213ec5ea645bc5e223b2ce1d @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113624v2: 4553eb97820406ff3cbc51a3348ffabfe3b3110e @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
d462a41ecae2 drm/i915/guc: More debug print updates - GuC logging
91c4d02dce7c drm/i915/guc: More debug print updates - GuC SLPC
336c66228bf9 drm/i915/guc: More debug print updates - GuC selftests
64bebe805074 drm/i915/guc: More debug print updates - GuC reg capture
91c3c7c8bb8d drm/i915/guc: More debug print updates - GSC firmware
5d3c51740897 drm/i915/guc: More debug print updates - UC firmware
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113624v2/index.html
Re: [Intel-gfx] [PATCHv3] drm/i915: Support Async Flip on Linear buffers
> -Original Message- > From: Murthy, Arun R > Sent: Thursday, February 2, 2023 4:59 PM > To: Ville Syrjälä > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville > Subject: RE: [Intel-gfx] [PATCHv3] drm/i915: Support Async Flip on Linear > buffers > > > -Original Message- > > From: Ville Syrjälä > > Sent: Thursday, February 2, 2023 2:54 PM > > To: Murthy, Arun R > > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville > > > > Subject: Re: [Intel-gfx] [PATCHv3] drm/i915: Support Async Flip on > > Linear buffers > > > > On Thu, Feb 02, 2023 at 06:51:49AM +, Murthy, Arun R wrote: > > > Gentle Reminder! > > > The patch is pending since a long time. > > > > Please review the igt changes here: > > https://patchwork.freedesktop.org/series/113525/ > > then we can actually test this (and any other new modifier in the future). > > > Done! > This patch is to add support for linear buffer in the driver and shouldn't > conflict with the IGT patch series > https://patchwork.freedesktop.org/series/113525/ > Since this patch doesn't conflict with the IGT series https://patchwork.freedesktop.org/series/113525/ Can this patch be reviewed and merged? Thanks and Regards, Arun R Murthy > Thanks and Regards, > Arun R Murthy > > > > > > > > Thanks and Regards, > > > Arun R Murthy > > > --- > > > > > > > -Original Message- > > > > From: Murthy, Arun R > > > > Sent: Monday, January 23, 2023 12:14 PM > > > > To: 'Ville Syrjälä' > > > > Cc: 'intel-gfx@lists.freedesktop.org' > > > > ; > > > > Syrjala, Ville > > > > Subject: RE: [Intel-gfx] [PATCHv3] drm/i915: Support Async Flip on > > > > Linear buffers > > > > > > > > Any review comments on this. Gentle Reminder! > > > > > > > > Thanks and Regards, > > > > Arun R Murthy > > > > > > > > > > > > > -Original Message- > > > > > From: Murthy, Arun R > > > > > Sent: Tuesday, January 17, 2023 2:09 PM > > > > > To: 'Ville Syrjälä' > > > > > Cc: 'intel-gfx@lists.freedesktop.org' > > > > > ; > > > > > Syrjala, Ville > > > > > Subject: RE: [Intel-gfx] [PATCHv3] drm/i915: Support Async Flip > > > > > on Linear buffers > > > > > > > > > > Gentle Reminder! > > > > > > > > > > Thanks and Regards, > > > > > Arun R Murthy > > > > > --- > > > > > > > > > > > -Original Message- > > > > > > From: Murthy, Arun R > > > > > > Sent: Friday, January 13, 2023 12:57 PM > > > > > > To: Ville Syrjälä > > > > > > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville > > > > > > > > > > > > Subject: RE: [Intel-gfx] [PATCHv3] drm/i915: Support Async > > > > > > Flip on Linear buffers > > > > > > > > > > > > > On Fri, Oct 28, 2022 at 03:23:02AM +, Murthy, Arun R wrote: > > > > > > > > Gentle Reminder! > > > > > > > > > > > > > > Is the igt stuff merged, and did this pass the test? > > > > > > > > > > > > > With IGT alone the tests will fail without the kernel patch. > > > > > > The > > > > > > tests(https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_112722v2 > > > > > > /s > > > > > > hard > > > > > > s- > > > > > > all.html?testfilter=kms_async_flips) are passing with IGT and > > > > > > kernel > > > > patch. > > > > > > > > > > > > Thanks and Regards, > > > > > > Arun R Murthy > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > From: Murthy, Arun R > > > > > > > > > Sent: Monday, October 10, 2022 1:24 PM > > > > > > > > > To: 'intel-gfx@lists.freedesktop.org' > > > > > > > > > > > > > > > > > > Cc: Syrjala, Ville > > > > > > > > > Subject: RE: [PATCHv3] drm/i915: Support Async Flip on > > > > > > > > > Linear buffers > > > > > > > > > > > > > > > > > > Ville, > > > > > > > > > Gentle reminder! > > > > > > > > > > > > > > > > > > Thanks and Regards, > > > > > > > > > Arun R Murthy > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > > From: Murthy, Arun R > > > > > > > > > > Sent: Monday, September 19, 2022 10:38 AM > > > > > > > > > > To: 'intel-gfx@lists.freedesktop.org' > > > > > > > > > > > > > > > > > > > > Cc: Syrjala, Ville > > > > > > > > > > Subject: RE: [PATCHv3] drm/i915: Support Async Flip on > > > > > > > > > > Linear buffers > > > > > > > > > > > > > > > > > > > > If no comments, can anyone merge the patch! > > > > > > > > > > > > > > > > > > > > Thanks and Regards, > > > > > > > > > > Arun R Murthy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > > > From: Murthy, Arun R > > > > > > > > > > > Sent: Wednesday, September 14, 2022 4:21 PM > > > > > > > > > > > To: Murthy, Arun R ; intel- > > > > > > > > > > > g...@lists.freedesktop.org > > > > > > > > > > > Cc: Syrjala, Ville > > > > > > > > > > > Subject: RE: [PATCHv3] drm/i915: Support Async Flip > > > > > > > > > > > on Linear buffers > > > > > > > > > > > > > > > > > > > > > > Gentle
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for More drm_dbg to guc_dbg changes (rev2)
== Series Details ==
Series: More drm_dbg to guc_dbg changes (rev2)
URL : https://patchwork.freedesktop.org/series/113624/
State : warning
== Summary ==
Error: dim checkpatch failed
800ec7a87261 drm/i915/guc: More debug print updates - UC firmware
219cdc2fb45b drm/i915/guc: More debug print updates - GSC firmware
c1a8660e46a5 drm/i915/guc: More debug print updates - GuC reg capture
-:101: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#101: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:622:
if (!caplist) {
+ guc_dbg(guc, "Failed to alloc cached register capture list");
-:118: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#118: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:663:
if (!null_header) {
+ guc_dbg(guc, "Failed to alloc cached register capture null
list");
total: 0 errors, 2 warnings, 0 checks, 214 lines checked
9f9950373225 drm/i915/guc: More debug print updates - GuC selftests
-:68: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#68: FILE: drivers/gpu/drm/i915/gt/uc/selftest_guc.c:158:
if (!ce) {
+ guc_err(guc, "Context array allocation failed\n");
total: 0 errors, 1 warnings, 0 checks, 280 lines checked
88c7ab4b276b drm/i915/guc: More debug print updates - GuC SLPC
c0b7351f1f37 drm/i915/guc: More debug print updates - GuC logging
-:19: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_gt' - possible side-effects?
#19: FILE: drivers/gpu/drm/i915/gt/intel_gt_print.h:31:
+#define gt_notice_ratelimited(_gt, _fmt, ...) \
+ dev_notice_ratelimited((_gt)->i915->drm.dev, "GT%u: " _fmt,
(_gt)->info.id, ##__VA_ARGS__)
total: 0 errors, 0 warnings, 1 checks, 27 lines checked
[Intel-gfx] [PATCHv3 2/2] i915/display/dp: SDP CRC16 for 128b132b link layer
Enable SDP error detection configuration, this will set CRC16 in 128b/132b link layer. For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is added to enable/disable SDP CRC applicable for DP2.0 only, but the default value of this bit will enable CRC16 in 128b/132b hence skipping this write. Corrective actions on SDP corruption is yet to be defined. v2: Moved the CRC enable to link training init(Jani N) v3: Moved crc enable to ddi pre enable Signed-off-by: Arun R Murthy --- .../gpu/drm/i915/display/intel_dp_link_training.c| 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index 3d3efcf02011..7064e465423b 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -1453,4 +1453,16 @@ void intel_dp_start_link_train(struct intel_dp *intel_dp, if (!passed) intel_dp_schedule_fallback_link_training(intel_dp, crtc_state); + + /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */ + if (intel_dp_is_uhbr(crtc_state) && passed) + drm_dp_dpcd_writeb(&intel_dp->aux, + DP_SDP_ERROR_DETECTION_CONFIGURATION, + DP_SDP_CRC16_128B132B_EN); + /* +* VIDEO_DIP_CTL register bit 31 should be set to '0' to not +* disable SDP CRC. This is applicable for Display version 13. +* Default value of bit 31 is '0' hence discarding the write +*/ + /* TODO: Corrective actions on SDP corruption yet to be defined */ } -- 2.25.1
[Intel-gfx] [PATCHv2 1/2] drm: Add SDP Error Detection Configuration Register
DP2.0 E11 defines a new register to facilitate SDP error detection by a 128B/132B capable DPRX device. v2: Update the macro name to reflect the DP spec(Harry) Signed-off-by: Arun R Murthy Reviewed-by: Harry Wentland --- include/drm/display/drm_dp.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h index 632376c291db..358db4a9f167 100644 --- a/include/drm/display/drm_dp.h +++ b/include/drm/display/drm_dp.h @@ -692,6 +692,9 @@ # define DP_FEC_LANE_2_SELECT (2 << 4) # define DP_FEC_LANE_3_SELECT (3 << 4) +#define DP_SDP_ERROR_DETECTION_CONFIGURATION 0x121 /* DP 2.0 E11 */ +#define DP_SDP_CRC16_128B132B_EN BIT(0) + #define DP_AUX_FRAME_SYNC_VALUE0x15c /* eDP 1.4 */ # define DP_AUX_FRAME_SYNC_VALID (1 << 0) -- 2.25.1
[Intel-gfx] [PATCHv3 0/2] DP2.0 SDP CRC16 for 128/132b link layer
*** BLURB HERE *** Arun R Murthy (2): drm: Add SDP Error Detection Configuration Register i915/display/dp: SDP CRC16 for 128b132b link layer .../gpu/drm/i915/display/intel_dp_link_training.c| 12 include/drm/display/drm_dp.h | 3 +++ 2 files changed, 15 insertions(+) -- 2.25.1
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pcode: Give the punit time to settle before fatally failing
== Series Details ==
Series: drm/i915/pcode: Give the punit time to settle before fatally failing
URL : https://patchwork.freedesktop.org/series/113717/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12704_full -> Patchwork_113717v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113717v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_softpin@noreloc-s3:
- {shard-tglu-9}: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/shard-tglu-9/igt@gem_soft...@noreloc-s3.html
Known issues
Here are the changes found in Patchwork_113717v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk: [PASS][2] -> [FAIL][3] ([i915#2346])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-glk4/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/shard-glk3/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
* igt@kms_dsc@dsc-with-bpc-formats:
- shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271]) +8 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/shard-glk6/igt@kms_...@dsc-with-bpc-formats.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a2:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2122]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-glk9/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a2.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/shard-glk7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a2.html
Possible fixes
* igt@fbdev@info:
- {shard-rkl}:[SKIP][7] ([i915#2582]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-rkl-1/igt@fb...@info.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/shard-rkl-6/igt@fb...@info.html
* igt@gem_bad_reloc@negative-reloc-lut:
- {shard-rkl}:[SKIP][9] ([i915#3281]) -> [PASS][10] +4 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-rkl-1/igt@gem_bad_re...@negative-reloc-lut.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/shard-rkl-5/igt@gem_bad_re...@negative-reloc-lut.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][11] ([i915#6268]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-rkl-1/igt@gem_ctx_e...@basic-nohangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/shard-rkl-5/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_exec_balancer@fairslice:
- {shard-rkl}:[SKIP][13] ([i915#6259]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-rkl-5/igt@gem_exec_balan...@fairslice.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/shard-rkl-2/igt@gem_exec_balan...@fairslice.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [FAIL][15] ([i915#2846]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-glk5/igt@gem_exec_f...@basic-deadline.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/shard-glk9/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-glk: [FAIL][17] ([i915#2842]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-glk8/igt@gem_exec_fair@basic-n...@vecs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/shard-glk8/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- {shard-tglu}: [FAIL][19] ([i915#2842]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-tglu-2/igt@gem_exec_fair@basic-throt...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/shard-tglu-3/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_exec_schedule@semaphore-power:
- {shard-rkl}:[SKIP][21] ([i915#7276]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-rkl-1/igt@gem_exec_sched...@semaphore-power.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/shar
[Intel-gfx] [PATCH v2 0/6] More drm_dbg to guc_dbg changes
From: John Harrison Update more print messages to the new scheme. v2: Also change all errors to %pe rather than %d (MichalW). Few other tweaks. Signed-off-by: John Harrison John Harrison (6): drm/i915/guc: More debug print updates - UC firmware drm/i915/guc: More debug print updates - GSC firmware drm/i915/guc: More debug print updates - GuC reg capture drm/i915/guc: More debug print updates - GuC selftests drm/i915/guc: More debug print updates - GuC SLPC drm/i915/guc: More debug print updates - GuC logging drivers/gpu/drm/i915/gt/intel_gt_print.h | 3 + drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 9 +- drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 7 +- .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 51 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 3 +- drivers/gpu/drm/i915/gt/uc/intel_guc_print.h | 3 + drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 8 +- drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 61 - drivers/gpu/drm/i915/gt/uc/intel_uc.c | 42 +++ drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 116 +- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 42 --- .../drm/i915/gt/uc/selftest_guc_hangcheck.c | 23 ++-- .../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 11 +- 13 files changed, 174 insertions(+), 205 deletions(-) -- 2.39.1
[Intel-gfx] [PATCH v2 2/6] drm/i915/guc: More debug print updates - GSC firmware
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
v2: Also change prints to use %pe for error values (MichalW).
Signed-off-by: John Harrison
Acked-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 9 -
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 7 +++
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index e73d4440c5e82..1d9fdfb112681 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -6,6 +6,7 @@
#include "gt/intel_engine_pm.h"
#include "gt/intel_gpu_commands.h"
#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
#include "gt/intel_ring.h"
#include "intel_gsc_fw.h"
@@ -88,9 +89,8 @@ static int gsc_fw_load(struct intel_gsc_uc *gsc)
i915_request_put(rq);
if (err)
- drm_err(&gsc_uc_to_gt(gsc)->i915->drm,
- "Request submission for GSC load failed (%d)\n",
- err);
+ gt_err(gsc_uc_to_gt(gsc), "Request submission for GSC load
failed %pe\n",
+ ERR_PTR(err));
return err;
}
@@ -200,8 +200,7 @@ int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc)
/* FW is not fully operational until we enable SW proxy */
intel_uc_fw_change_status(gsc_fw, INTEL_UC_FIRMWARE_TRANSFERRED);
- drm_info(>->i915->drm, "Loaded GSC firmware %s\n",
-gsc_fw->file_selected.path);
+ gt_info(gt, "Loaded GSC firmware %s\n", gsc_fw->file_selected.path);
return 0;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index fd21dbd2663be..8afd42cbded96 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -6,6 +6,7 @@
#include
#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
#include "intel_gsc_uc.h"
#include "intel_gsc_fw.h"
#include "i915_drv.h"
@@ -59,7 +60,6 @@ int intel_gsc_uc_init(struct intel_gsc_uc *gsc)
{
static struct lock_class_key gsc_lock;
struct intel_gt *gt = gsc_uc_to_gt(gsc);
- struct drm_i915_private *i915 = gt->i915;
struct intel_engine_cs *engine = gt->engine[GSC0];
struct intel_context *ce;
struct i915_vma *vma;
@@ -81,8 +81,7 @@ int intel_gsc_uc_init(struct intel_gsc_uc *gsc)
I915_GEM_HWS_GSC_ADDR,
&gsc_lock, "gsc_context");
if (IS_ERR(ce)) {
- drm_err(>->i915->drm,
- "failed to create GSC CS ctx for FW communication\n");
+ gt_err(gt, "failed to create GSC CS ctx for FW
communication\n");
err = PTR_ERR(ce);
goto out_vma;
}
@@ -98,7 +97,7 @@ int intel_gsc_uc_init(struct intel_gsc_uc *gsc)
out_fw:
intel_uc_fw_fini(&gsc->fw);
out:
- i915_probe_error(i915, "failed with %d\n", err);
+ gt_probe_error(gt, "GSC init failed %pe\n", ERR_PTR(err));
return err;
}
--
2.39.1
[Intel-gfx] [PATCH v2 3/6] drm/i915/guc: More debug print updates - GuC reg capture
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
v2: Upgrade the no node found message to a warning on the grounds of
it being quite important if the error capture can't find any register
state information.
Signed-off-by: John Harrison
Reviewed-by: Alan Previn
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 51 ---
1 file changed, 21 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index fc3b994626a4f..101d44de729b1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -15,6 +15,7 @@
#include "guc_capture_fwif.h"
#include "intel_guc_capture.h"
#include "intel_guc_fwif.h"
+#include "intel_guc_print.h"
#include "i915_drv.h"
#include "i915_gpu_error.h"
#include "i915_irq.h"
@@ -353,7 +354,6 @@ guc_capture_alloc_steered_lists_xe_hpg(struct intel_guc
*guc,
u32 ipver)
{
struct intel_gt *gt = guc_to_gt(guc);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct sseu_dev_info *sseu;
int slice, subslice, i, iter, num_steer_regs, num_tot_regs = 0;
const struct __guc_mmio_reg_descr_group *list;
@@ -402,7 +402,7 @@ guc_capture_alloc_steered_lists_xe_hpg(struct intel_guc
*guc,
}
}
- drm_dbg(&i915->drm, "GuC-capture found %d-ext-regs.\n", num_tot_regs);
+ guc_dbg(guc, "capture found %d ext-regs.\n", num_tot_regs);
guc->capture->extlists = extlists;
}
@@ -477,7 +477,6 @@ guc_capture_list_init(struct intel_guc *guc, u32 owner, u32
type, u32 classid,
struct guc_mmio_reg *ptr, u16 num_entries)
{
u32 i = 0, j = 0;
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
const struct __guc_mmio_reg_descr_group *reglists =
guc->capture->reglists;
struct __guc_mmio_reg_descr_group *extlists = guc->capture->extlists;
const struct __guc_mmio_reg_descr_group *match;
@@ -509,8 +508,7 @@ guc_capture_list_init(struct intel_guc *guc, u32 owner, u32
type, u32 classid,
}
}
if (i < num_entries)
- drm_dbg(&i915->drm, "GuC-capture: Init reglist short %d out
%d.\n",
- (int)i, (int)num_entries);
+ guc_dbg(guc, "Got short capture reglist init: %d out %d.\n", i,
num_entries);
return 0;
}
@@ -540,12 +538,11 @@ guc_capture_getlistsize(struct intel_guc *guc, u32 owner,
u32 type, u32 classid,
size_t *size, bool is_purpose_est)
{
struct intel_guc_state_capture *gc = guc->capture;
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct __guc_capture_ads_cache *cache =
&gc->ads_cache[owner][type][classid];
int num_regs;
if (!gc->reglists) {
- drm_warn(&i915->drm, "GuC-capture: No reglist on this
device\n");
+ guc_warn(guc, "No capture reglist for this device\n");
return -ENODEV;
}
@@ -557,9 +554,9 @@ guc_capture_getlistsize(struct intel_guc *guc, u32 owner,
u32 type, u32 classid,
if (!is_purpose_est && owner == GUC_CAPTURE_LIST_INDEX_PF &&
!guc_capture_get_one_list(gc->reglists, owner, type, classid)) {
if (type == GUC_CAPTURE_LIST_TYPE_GLOBAL)
- drm_warn(&i915->drm, "Missing GuC-Err-Cap reglist
Global!\n");
+ guc_warn(guc, "Missing capture reglist: global!\n");
else
- drm_warn(&i915->drm, "Missing GuC-Err-Cap reglist
%s(%u):%s(%u)!\n",
+ guc_warn(guc, "Missing capture reglist:
%s(%u):%s(%u)!\n",
__stringify_type(type), type,
__stringify_engclass(classid), classid);
return -ENODATA;
@@ -592,7 +589,6 @@ intel_guc_capture_getlist(struct intel_guc *guc, u32 owner,
u32 type, u32 classi
{
struct intel_guc_state_capture *gc = guc->capture;
struct __guc_capture_ads_cache *cache =
&gc->ads_cache[owner][type][classid];
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct guc_debug_capture_list *listnode;
int ret, num_regs;
u8 *caplist, *tmp;
@@ -623,7 +619,7 @@ intel_guc_capture_getlist(struct intel_guc *guc, u32 owner,
u32 type, u32 classi
caplist = kzalloc(size, GFP_KERNEL);
if (!caplist) {
- drm_dbg(&i915->drm, "GuC-capture: failed to alloc cached
caplist");
+ guc_dbg(guc, "Failed to alloc cached register capture list");
return -ENOMEM;
}
@@ -653,7 +649,6 @@ intel_guc_capture_getnullheader(struct intel_guc *guc,
void **outptr, size_t *size)
{
struct intel_guc_state_capture *gc = guc->capture;
- struct drm_i915_private *i9
[Intel-gfx] [PATCH v2 4/6] drm/i915/guc: More debug print updates - GuC selftests
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
v2: Also change prints to use %pe for error values (MichalW).
Fix a context leak on error due to a -- being too early.
Use the correct header file for the debug macros.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 42 ++-
.../drm/i915/gt/uc/selftest_guc_hangcheck.c | 23 +-
.../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 11 ++---
3 files changed, 40 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
index e28518fe8b908..1fd760539f77b 100644
--- a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
@@ -3,6 +3,8 @@
* Copyright �� 2021 Intel Corporation
*/
+#include "gt/intel_gt_print.h"
+#include "intel_guc_print.h"
#include "selftests/igt_spinner.h"
#include "selftests/intel_scheduler_helpers.h"
@@ -65,7 +67,7 @@ static int intel_guc_scrub_ctbs(void *arg)
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
ret = PTR_ERR(ce);
- drm_err(>->i915->drm, "Failed to create context, %d:
%d\n", i, ret);
+ gt_err(gt, "Failed to create context %d: %pe\n", i, ce);
goto err;
}
@@ -86,7 +88,7 @@ static int intel_guc_scrub_ctbs(void *arg)
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
- drm_err(>->i915->drm, "Failed to create request, %d:
%d\n", i, ret);
+ gt_err(gt, "Failed to create request %d: %pe\n", i, rq);
goto err;
}
@@ -96,7 +98,7 @@ static int intel_guc_scrub_ctbs(void *arg)
for (i = 0; i < 3; ++i) {
ret = i915_request_wait(last[i], 0, HZ);
if (ret < 0) {
- drm_err(>->i915->drm, "Last request failed to
complete: %d\n", ret);
+ gt_err(gt, "Last request failed to complete: %pe\n",
ERR_PTR(ret));
goto err;
}
i915_request_put(last[i]);
@@ -113,7 +115,7 @@ static int intel_guc_scrub_ctbs(void *arg)
/* GT will not idle if G2H are lost */
ret = intel_gt_wait_for_idle(gt, HZ);
if (ret < 0) {
- drm_err(>->i915->drm, "GT failed to idle: %d\n", ret);
+ gt_err(gt, "GT failed to idle: %pe\n", ERR_PTR(ret));
goto err;
}
@@ -153,7 +155,7 @@ static int intel_guc_steal_guc_ids(void *arg)
ce = kcalloc(GUC_MAX_CONTEXT_ID, sizeof(*ce), GFP_KERNEL);
if (!ce) {
- drm_err(>->i915->drm, "Context array allocation failed\n");
+ guc_err(guc, "Context array allocation failed\n");
return -ENOMEM;
}
@@ -166,25 +168,25 @@ static int intel_guc_steal_guc_ids(void *arg)
ce[context_index] = intel_context_create(engine);
if (IS_ERR(ce[context_index])) {
ret = PTR_ERR(ce[context_index]);
+ guc_err(guc, "Failed to create context: %pe\n",
ce[context_index]);
ce[context_index] = NULL;
- drm_err(>->i915->drm, "Failed to create context: %d\n", ret);
goto err_wakeref;
}
ret = igt_spinner_init(&spin, engine->gt);
if (ret) {
- drm_err(>->i915->drm, "Failed to create spinner: %d\n", ret);
+ guc_err(guc, "Failed to create spinner: %pe\n", ERR_PTR(ret));
goto err_contexts;
}
spin_rq = igt_spinner_create_request(&spin, ce[context_index],
MI_ARB_CHECK);
if (IS_ERR(spin_rq)) {
ret = PTR_ERR(spin_rq);
- drm_err(>->i915->drm, "Failed to create spinner request:
%d\n", ret);
+ guc_err(guc, "Failed to create spinner request: %pe\n",
spin_rq);
goto err_contexts;
}
ret = request_add_spin(spin_rq, &spin);
if (ret) {
- drm_err(>->i915->drm, "Failed to add Spinner request: %d\n",
ret);
+ guc_err(guc, "Failed to add Spinner request: %pe\n",
ERR_PTR(ret));
goto err_spin_rq;
}
@@ -192,9 +194,9 @@ static int intel_guc_steal_guc_ids(void *arg)
while (ret != -EAGAIN) {
ce[++context_index] = intel_context_create(engine);
if (IS_ERR(ce[context_index])) {
- ret = PTR_ERR(ce[context_index--]);
- ce[context_index] = NULL;
- drm_err(>->i915->drm, "Failed to create context:
%d\n", ret);
+ ret = PTR_ERR(ce[context_index]);
+ guc_err(guc, "Failed to create context: %pe\n",
ce[context_index]);
+ ce[context_index--] = NULL;
[Intel-gfx] [PATCH v2 6/6] drm/i915/guc: More debug print updates - GuC logging
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/intel_gt_print.h | 3 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 3 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_print.h | 3 +++
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_print.h
b/drivers/gpu/drm/i915/gt/intel_gt_print.h
index 5d9da355ce242..55a336a9ff061 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_print.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_print.h
@@ -28,6 +28,9 @@
#define gt_err_ratelimited(_gt, _fmt, ...) \
drm_err_ratelimited(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id,
##__VA_ARGS__)
+#define gt_notice_ratelimited(_gt, _fmt, ...) \
+ dev_notice_ratelimited((_gt)->i915->drm.dev, "GT%u: " _fmt,
(_gt)->info.id, ##__VA_ARGS__)
+
#define gt_probe_error(_gt, _fmt, ...) \
do { \
if (i915_error_injected()) \
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index c3792ddeec802..818e9e0e66a83 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -333,8 +333,7 @@ bool intel_guc_check_log_buf_overflow(struct intel_guc_log
*log,
log->stats[type].sampled_overflow += 16;
}
-
dev_notice_ratelimited(guc_to_gt(log_to_guc(log))->i915->drm.dev,
- "GuC log buffer overflow\n");
+ guc_notice_ratelimited(log_to_guc(log), "log buffer
overflow\n");
}
return overflow;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
index e75989d4ba067..2465d05638b40 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
@@ -30,6 +30,9 @@
#define guc_err_ratelimited(_guc, _fmt, ...) \
guc_printk((_guc), err_ratelimited, _fmt, ##__VA_ARGS__)
+#define guc_notice_ratelimited(_guc, _fmt, ...) \
+ guc_printk((_guc), notice_ratelimited, _fmt, ##__VA_ARGS__)
+
#define guc_probe_error(_guc, _fmt, ...) \
guc_printk((_guc), probe_error, _fmt, ##__VA_ARGS__)
--
2.39.1
[Intel-gfx] [PATCH v2 5/6] drm/i915/guc: More debug print updates - GuC SLPC
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
v2: Also change prints to use %pe for error values (MichalW).
Signed-off-by: John Harrison
Acked-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 8 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 61 -
2 files changed, 26 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
index b5855091cf6a9..23b287cefb943 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
@@ -6,6 +6,7 @@
#include
#include "intel_guc_rc.h"
+#include "intel_guc_print.h"
#include "gt/intel_gt.h"
#include "i915_drv.h"
@@ -70,13 +71,12 @@ static int __guc_rc_control(struct intel_guc *guc, bool
enable)
ret = guc_action_control_gucrc(guc, enable);
if (ret) {
- i915_probe_error(guc_to_gt(guc)->i915, "Failed to %s GuC RC
(%pe)\n",
-str_enable_disable(enable), ERR_PTR(ret));
+ guc_probe_error(guc, "Failed to %s RC (%pe)\n",
+ str_enable_disable(enable), ERR_PTR(ret));
return ret;
}
- drm_info(>->i915->drm, "GuC RC: %s\n",
-str_enabled_disabled(enable));
+ guc_info(guc, "RC: %s\n", str_enabled_disabled(enable));
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index 63464933cbceb..026d73855f36c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -9,6 +9,7 @@
#include "i915_drv.h"
#include "i915_reg.h"
#include "intel_guc_slpc.h"
+#include "intel_guc_print.h"
#include "intel_mchbar_regs.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_regs.h"
@@ -171,14 +172,12 @@ static int guc_action_slpc_query(struct intel_guc *guc,
u32 offset)
static int slpc_query_task_state(struct intel_guc_slpc *slpc)
{
struct intel_guc *guc = slpc_to_guc(slpc);
- struct drm_i915_private *i915 = slpc_to_i915(slpc);
u32 offset = intel_guc_ggtt_offset(guc, slpc->vma);
int ret;
ret = guc_action_slpc_query(guc, offset);
if (unlikely(ret))
- i915_probe_error(i915, "Failed to query task state (%pe)\n",
-ERR_PTR(ret));
+ guc_probe_error(guc, "Failed to query task state: %pe\n",
ERR_PTR(ret));
drm_clflush_virt_range(slpc->vaddr, SLPC_PAGE_SIZE_BYTES);
@@ -188,15 +187,14 @@ static int slpc_query_task_state(struct intel_guc_slpc
*slpc)
static int slpc_set_param(struct intel_guc_slpc *slpc, u8 id, u32 value)
{
struct intel_guc *guc = slpc_to_guc(slpc);
- struct drm_i915_private *i915 = slpc_to_i915(slpc);
int ret;
GEM_BUG_ON(id >= SLPC_MAX_PARAM);
ret = guc_action_slpc_set_param(guc, id, value);
if (ret)
- i915_probe_error(i915, "Failed to set param %d to %u (%pe)\n",
-id, value, ERR_PTR(ret));
+ guc_probe_error(guc, "Failed to set param %d to %u: %pe\n",
+ id, value, ERR_PTR(ret));
return ret;
}
@@ -212,8 +210,8 @@ static int slpc_unset_param(struct intel_guc_slpc *slpc, u8
id)
static int slpc_force_min_freq(struct intel_guc_slpc *slpc, u32 freq)
{
- struct drm_i915_private *i915 = slpc_to_i915(slpc);
struct intel_guc *guc = slpc_to_guc(slpc);
+ struct drm_i915_private *i915 = slpc_to_i915(slpc);
intel_wakeref_t wakeref;
int ret = 0;
@@ -236,9 +234,8 @@ static int slpc_force_min_freq(struct intel_guc_slpc *slpc,
u32 freq)
SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
freq);
if (ret)
- drm_notice(&i915->drm,
- "Failed to send set_param for min freq(%d):
(%d)\n",
- freq, ret);
+ guc_notice(guc, "Failed to send set_param for min
freq(%d): %pe\n",
+ freq, ERR_PTR(ret));
}
return ret;
@@ -267,7 +264,6 @@ static void slpc_boost_work(struct work_struct *work)
int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
{
struct intel_guc *guc = slpc_to_guc(slpc);
- struct drm_i915_private *i915 = slpc_to_i915(slpc);
u32 size = PAGE_ALIGN(sizeof(struct slpc_shared_data));
int err;
@@ -275,9 +271,7 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
err = intel_guc_allocate_and_map_vma(guc, size, &slpc->vma, (void
**)&slpc->vaddr);
if (unlikely(err)) {
- i915_probe_error(i915,
-"Failed to allocate SLPC struct (err=%pe)\n",
-ERR
[Intel-gfx] [PATCH v2 1/6] drm/i915/guc: More debug print updates - UC firmware
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
v2: Also change prints to use %pe for error values (MichalW).
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 42
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 116 +++
2 files changed, 73 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index de7f987cf6111..6648691bd6450 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -83,15 +83,15 @@ static int __intel_uc_reset_hw(struct intel_uc *uc)
static void __confirm_options(struct intel_uc *uc)
{
- struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
+ struct intel_gt *gt = uc_to_gt(uc);
+ struct drm_i915_private *i915 = gt->i915;
- drm_dbg(&i915->drm,
- "enable_guc=%d (guc:%s submission:%s huc:%s slpc:%s)\n",
- i915->params.enable_guc,
- str_yes_no(intel_uc_wants_guc(uc)),
- str_yes_no(intel_uc_wants_guc_submission(uc)),
- str_yes_no(intel_uc_wants_huc(uc)),
- str_yes_no(intel_uc_wants_guc_slpc(uc)));
+ gt_dbg(gt, "enable_guc=%d (guc:%s submission:%s huc:%s slpc:%s)\n",
+ i915->params.enable_guc,
+ str_yes_no(intel_uc_wants_guc(uc)),
+ str_yes_no(intel_uc_wants_guc_submission(uc)),
+ str_yes_no(intel_uc_wants_huc(uc)),
+ str_yes_no(intel_uc_wants_guc_slpc(uc)));
if (i915->params.enable_guc == 0) {
GEM_BUG_ON(intel_uc_wants_guc(uc));
@@ -102,26 +102,22 @@ static void __confirm_options(struct intel_uc *uc)
}
if (!intel_uc_supports_guc(uc))
- drm_info(&i915->drm,
-"Incompatible option enable_guc=%d - %s\n",
-i915->params.enable_guc, "GuC is not supported!");
+ gt_info(gt, "Incompatible option enable_guc=%d - %s\n",
+ i915->params.enable_guc, "GuC is not supported!");
if (i915->params.enable_guc & ENABLE_GUC_LOAD_HUC &&
!intel_uc_supports_huc(uc))
- drm_info(&i915->drm,
-"Incompatible option enable_guc=%d - %s\n",
-i915->params.enable_guc, "HuC is not supported!");
+ gt_info(gt, "Incompatible option enable_guc=%d - %s\n",
+ i915->params.enable_guc, "HuC is not supported!");
if (i915->params.enable_guc & ENABLE_GUC_SUBMISSION &&
!intel_uc_supports_guc_submission(uc))
- drm_info(&i915->drm,
-"Incompatible option enable_guc=%d - %s\n",
-i915->params.enable_guc, "GuC submission is N/A");
+ gt_info(gt, "Incompatible option enable_guc=%d - %s\n",
+ i915->params.enable_guc, "GuC submission is N/A");
if (i915->params.enable_guc & ~ENABLE_GUC_MASK)
- drm_info(&i915->drm,
-"Incompatible option enable_guc=%d - %s\n",
-i915->params.enable_guc, "undocumented flag");
+ gt_info(gt, "Incompatible option enable_guc=%d - %s\n",
+ i915->params.enable_guc, "undocumented flag");
}
void intel_uc_init_early(struct intel_uc *uc)
@@ -549,10 +545,8 @@ static int __uc_init_hw(struct intel_uc *uc)
intel_gsc_uc_load_start(&uc->gsc);
- gt_info(gt, "GuC submission %s\n",
- str_enabled_disabled(intel_uc_uses_guc_submission(uc)));
- gt_info(gt, "GuC SLPC %s\n",
- str_enabled_disabled(intel_uc_uses_guc_slpc(uc)));
+ guc_info(guc, "submission %s\n",
str_enabled_disabled(intel_uc_uses_guc_submission(uc)));
+ guc_info(guc, "SLPC %s\n",
str_enabled_disabled(intel_uc_uses_guc_slpc(uc)));
return 0;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 65672ff826054..264c952f777bb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -11,6 +11,7 @@
#include
#include "gem/i915_gem_lmem.h"
+#include "gt/intel_gt_print.h"
#include "intel_uc_fw.h"
#include "intel_uc_fw_abi.h"
#include "i915_drv.h"
@@ -44,11 +45,10 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
enum intel_uc_fw_status status)
{
uc_fw->__status = status;
- drm_dbg(&__uc_fw_to_gt(uc_fw)->i915->drm,
- "%s firmware -> %s\n",
- intel_uc_fw_type_repr(uc_fw->type),
- status == INTEL_UC_FIRMWARE_SELECTED ?
- uc_fw->file_selected.path : intel_uc_fw_status_repr(status));
+ gt_dbg(__uc_fw_to_gt(uc_fw), "%s firmware -> %s\n",
+ intel_uc_fw_type_repr(uc_fw->type),
+ status == INTEL_UC_FIRMWARE_SELE
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Move display power initialization during driver probing later
== Series Details ==
Series: series starting with [1/3] drm/i915: Move display power initialization
during driver probing later
URL : https://patchwork.freedesktop.org/series/113711/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12704_full -> Patchwork_113711v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113711v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_dsc@dsc-basic}:
- {shard-tglu-10}:NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/shard-tglu-10/igt@kms_...@dsc-basic.html
* igt@kms_rotation_crc@primary-rotation-270:
- {shard-rkl}:[SKIP][2] ([i915#1845] / [i915#4098]) ->
[INCOMPLETE][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-rkl-4/igt@kms_rotation_...@primary-rotation-270.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/shard-rkl-6/igt@kms_rotation_...@primary-rotation-270.html
Known issues
Here are the changes found in Patchwork_113711v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk: [PASS][4] -> [FAIL][5] ([i915#2842])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@kms_dsc@dsc-with-bpc-formats:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271]) +8 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/shard-glk3/igt@kms_...@dsc-with-bpc-formats.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#79])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-glk4/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][9] ([i915#7742]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-rkl-3/igt@drm_fdi...@virtual-idle.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/shard-rkl-1/igt@drm_fdi...@virtual-idle.html
* igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[FAIL][11] ([fdo#103375]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-rkl-3/igt@gem_...@in-flight-suspend.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/shard-rkl-2/igt@gem_...@in-flight-suspend.html
* igt@gem_exec_balancer@fairslice:
- {shard-rkl}:[SKIP][13] ([i915#6259]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-rkl-5/igt@gem_exec_balan...@fairslice.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/shard-rkl-6/igt@gem_exec_balan...@fairslice.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][15] ([i915#2842]) -> [PASS][16] +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_softpin@noreloc-s3:
- {shard-rkl}:[ABORT][17] -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-rkl-4/igt@gem_soft...@noreloc-s3.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/shard-rkl-5/igt@gem_soft...@noreloc-s3.html
* igt@i915_pm_dc@dc5-psr:
- {shard-rkl}:[SKIP][19] ([i915#658]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-rkl-5/igt@i915_pm...@dc5-psr.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/shard-rkl-6/igt@i915_pm...@dc5-psr.html
* igt@i915_pm_rc6_residency@rc6-idle@vcs0:
- {shard-dg1}:[FAIL][21] ([i915#3591]) -> [PASS][22] +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/shard-dg1-14/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/shard-dg1-14/igt@i915_pm_rc6_reside
Re: [Intel-gfx] [PATCH v2 13/14] vfio: Add ioctls for device cdev using iommufd
On Mon, Feb 06, 2023 at 01:05:31AM -0800, Yi Liu wrote:
...
> +void vfio_device_cdev_close(struct vfio_device_file *df)
> +{
> + mutex_lock(&df->device->dev_set->lock);
> + vfio_device_close(df);
> + vfio_device_put_kvm(df->device);
> + mutex_unlock(&df->device->dev_set->lock);
> +}
> +
...
> +long vfio_device_ioctl_bind_iommufd(struct vfio_device_file *df,
> + unsigned long arg)
> +{
> + struct vfio_device *device = df->device;
> + struct vfio_device_bind_iommufd bind;
> + struct iommufd_ctx *iommufd = NULL;
> + unsigned long minsz;
> + struct fd f;
> + int ret;
> +
> + minsz = offsetofend(struct vfio_device_bind_iommufd, iommufd);
> +
> + if (copy_from_user(&bind, (void __user *)arg, minsz))
> + return -EFAULT;
> +
> + if (bind.argsz < minsz || bind.flags)
> + return -EINVAL;
> +
> + if (!device->ops->bind_iommufd)
> + return -ENODEV;
> +
> + mutex_lock(&device->dev_set->lock);
> + /*
> + * If already been bound to an iommufd, or already set noiommu
> + * then fail it.
> + */
> + if (df->iommufd || df->noiommu) {
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> + /* iommufd < 0 means noiommu mode */
> + if (bind.iommufd < 0) {
> + if (!capable(CAP_SYS_RAWIO)) {
> + ret = -EPERM;
> + goto out_unlock;
> + }
> + df->noiommu = true;
> + } else {
> + f = fdget(bind.iommufd);
> + if (!f.file) {
> + ret = -EBADF;
> + goto out_unlock;
> + }
> + iommufd = iommufd_ctx_from_file(f.file);
> + if (IS_ERR(iommufd)) {
> + ret = PTR_ERR(iommufd);
> + goto out_put_file;
> + }
> + }
> +
> + /*
> + * Before the first device open, get the KVM pointer currently
> + * associated with the device file (if there is) and obtain a
> + * reference. This reference is held until device closed. Save
> + * the pointer in the device for use by drivers.
> + */
> + vfio_device_get_kvm_safe(df);
> +
> + df->iommufd = iommufd;
> + ret = vfio_device_open(df, &bind.out_devid, NULL);
> + if (ret)
> + goto out_put_kvm;
> +
> + ret = copy_to_user((void __user *)arg + minsz,
> +&bind.out_devid,
> +sizeof(bind.out_devid)) ? -EFAULT : 0;
> + if (ret)
> + goto out_close_device;
> +
> + if (iommufd)
> + fdput(f);
> + else if (df->noiommu)
> + dev_warn(device->dev, "vfio-noiommu device used by user "
> + "(%s:%d)\n", current->comm, task_pid_nr(current));
> + mutex_unlock(&device->dev_set->lock);
> + return 0;
> +
> +out_close_device:
> + vfio_device_close(df);
vfio_device_close() is called here if any error after vfio_device_open().
But it will also be called unconditionally in vfio_device_cdev_close() and
cause a wrong value of device->open_count.
df->access_granted in patch 07 can also be of wrong true value after
this vfio_device_close().
> +out_put_kvm:
> + vfio_device_put_kvm(device);
> +out_put_file:
> + if (iommufd)
> + fdput(f);
> +out_unlock:
> + df->iommufd = NULL;
> + df->noiommu = false;
> + mutex_unlock(&device->dev_set->lock);
> + return ret;
> +}
> +
Re: [Intel-gfx] [PATCH v2 08/14] vfio: Add infrastructure for bind_iommufd from userspace
> From: Liu, Yi L > Sent: Monday, February 6, 2023 5:05 PM > > For the device fd opened from cdev, userspace needs to bind it to an > iommufd and attach it to IOAS managed by iommufd. With such operations, > userspace can set up a secure DMA context and hence access device. > > This changes the existing vfio_iommufd_bind() to accept a pt_id pointer > as an optional input, and also an dev_id pointer to selectively return > the dev_id to prepare for adding bind_iommufd ioctl, which does the bind > first and then attach IOAS. > > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v2 07/14] vfio: Block device access via device fd until device is opened
> From: Liu, Yi L > Sent: Monday, February 6, 2023 5:05 PM > > Allow the vfio_device file to be in a state where the device FD is > opened but the device cannot be used by userspace (i.e. its .open_device() > hasn't been called). This inbetween state is not used when the device > FD is spawned from the group FD, however when we create the device FD > directly by opening a cdev it will be opened in the blocked state. > > The reason for the inbetween state is userspace only gets a FD but ...is "that" userspace... > doesn't have the secure until binding the FD to an iommufd. So in the "doesn't gain access permission until..." > blocked state, only the bind operation is allowed, other device accesses remove the last part which duplicates with "only ... is allowed" > are not allowed. Completing bind will allow user to further access the > device. > > This is implemented by adding a flag in struct vfio_device_file to mark > the blocked state and using a simple smp_load_acquire() to obtain the > flag value and serialize all the device setup with the thread accessing > this device. > > Following this lockless scheme, it can safely handle the device FD > unbound->bound but it cannot handle bound->unbound. To allow this we'd > need to add a lock on all the vfio ioctls which seems costly. So once > device FD is bound, it remains bound until the FD is closed. > > Suggested-by: Jason Gunthorpe > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v2 06/14] vfio: Pass struct vfio_device_file * to vfio_device_open/close()
> From: Liu, Yi L > Sent: Monday, February 6, 2023 5:05 PM > > This avoids passing too much parameters in multiple functions. > > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v2 05/14] kvm/vfio: Accept vfio device file from userspace
> From: Liu, Yi L > Sent: Monday, February 6, 2023 5:05 PM > > This defines KVM_DEV_VFIO_FILE* and make alias with > KVM_DEV_VFIO_GROUP*. > Old userspace uses KVM_DEV_VFIO_GROUP* works as well. > > Signed-off-by: Yi Liu > --- > Documentation/virt/kvm/devices/vfio.rst | 40 ++--- > include/uapi/linux/kvm.h| 16 +++--- > virt/kvm/vfio.c | 16 +- > 3 files changed, 42 insertions(+), 30 deletions(-) > > diff --git a/Documentation/virt/kvm/devices/vfio.rst > b/Documentation/virt/kvm/devices/vfio.rst > index 2d20dc561069..7f84ec26ca4a 100644 > --- a/Documentation/virt/kvm/devices/vfio.rst > +++ b/Documentation/virt/kvm/devices/vfio.rst > @@ -9,23 +9,26 @@ Device types supported: >- KVM_DEV_TYPE_VFIO > > Only one VFIO instance may be created per VM. The created device > -tracks VFIO groups in use by the VM and features of those groups > -important to the correctness and acceleration of the VM. As groups > -are enabled and disabled for use by the VM, KVM should be updated > -about their presence. When registered with KVM, a reference to the > -VFIO-group is held by KVM. > +tracks VFIO files (group or device) in use by the VM and features > +of those groups/devices important to the correctness and acceleration > +of the VM. As groups/devices are enabled and disabled for use by the > +VM, KVM should be updated about their presence. When registered with > +KVM, a reference to the VFIO file is held by KVM. > > Groups: "Files" > - KVM_DEV_VFIO_GROUP > - > -KVM_DEV_VFIO_GROUP attributes: > - KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device > tracking > - kvm_device_attr.addr points to an int32_t file descriptor > - for the VFIO group. > - KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM > device tracking > - kvm_device_attr.addr points to an int32_t file descriptor > - for the VFIO group. > - KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: attaches a guest visible TCE > table > + KVM_DEV_VFIO_FILE > + - alias: KVM_DEV_VFIO_GROUP > + > +KVM_DEV_VFIO_FILE attributes: > + KVM_DEV_VFIO_FILE_ADD: Add a VFIO file (group/device) to VFIO-KVM > device > + tracking kvm_device_attr.addr points to an int32_t file descriptor "... device tracking" and "kvm_device.attr.addr points to..." are two sentences. They are deliberately arranged to be in different lines. > + for the VFIO file. > + - alias: KVM_DEV_VFIO_GROUP_ADD > + KVM_DEV_VFIO_FILE_DEL: Remove a VFIO file (group/device) from VFIO- > KVM > + device tracking kvm_device_attr.addr points to an int32_t file > + descriptor for the VFIO file. ditto > + - alias: KVM_DEV_VFIO_GROUP_DEL > + KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: attaches a guest visible TCE table > allocated by sPAPR KVM. somehow here it should emphasize that the file can only be group > kvm_device_attr.addr points to a struct:: > > @@ -36,6 +39,7 @@ KVM_DEV_VFIO_GROUP attributes: > > where: > > - - @groupfd is a file descriptor for a VFIO group; > - - @tablefd is a file descriptor for a TCE table allocated via > - KVM_CREATE_SPAPR_TCE. > + *) @groupfd is a file descriptor for a VFIO group; > + *) @tablefd is a file descriptor for a TCE table allocated via why changing above two lines? > +KVM_CREATE_SPAPR_TCE. > + - alias: KVM_DEV_VFIO_FILE_SET_SPAPR_TCE GROUP
Re: [Intel-gfx] [PATCH v2 03/14] vfio: Accept vfio device file in the driver facing kAPI
> From: Liu, Yi L > Sent: Monday, February 6, 2023 5:05 PM > > This makes the vfio file kAPIs to accepte vfio device files, also a > preparation for vfio device cdev support. > > For the kvm set with vfio device file, kvm pointer is stored in struct > vfio_device_file, and use kvm_ref_lock to protect kvm set and kvm > pointer usage within VFIO. This kvm pointer will be set to vfio_device > after device file is bound to iommufd in the cdev path. > > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Clean up of register capture search
On 2/3/2023 23:29, Teres Alexis, Alan Previn wrote:
I see you are inferring that a guc-id of zero can be valid.
I am guessing that might have contributed to some lost captures?
Thanks for catching this.
I'm not inferring anything. I might be implying something, though. The
patch description probably should have mentioned that change. I'll add
something in.
There is nothing special about id zero. The lower X many ids are
reserved for multi-LRC use. So you won't see zero being allocated
normally. But run a multi-LRC app/test and the first context allocated
should be id zero.
John.
Reviewed-by: Alan Previn
On Thu, 2023-02-02 at 17:10 -0800, john.c.harri...@intel.com wrote:
From: John Harrison
The comparison in the search for a matching register capture node was
not the most readable. So remove two redundant terms and re-format to
keep each term on a single line, and only one term per line.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 710999d7189ee..87b080dd6bead 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1627,9 +1627,8 @@ void intel_guc_capture_get_matching_node(struct intel_gt
*gt,
list_for_each_entry_safe(n, ntmp, &guc->capture->outlist, link) {
if (n->eng_inst == GUC_ID_TO_ENGINE_INSTANCE(ee->engine->guc_id)
&&
n->eng_class == GUC_ID_TO_ENGINE_CLASS(ee->engine->guc_id)
&&
- n->guc_id && n->guc_id == ce->guc_id.id &&
- (n->lrca & CTX_GTT_ADDRESS_MASK) && (n->lrca &
CTX_GTT_ADDRESS_MASK) ==
- (ce->lrc.lrca & CTX_GTT_ADDRESS_MASK)) {
+ n->guc_id == ce->guc_id.id &&
+ (n->lrca & CTX_GTT_ADDRESS_MASK) == (ce->lrc.lrca &
CTX_GTT_ADDRESS_MASK)) {
list_del(&n->link);
ee->guc_capture_node = n;
ee->guc_capture = guc->capture;
Re: [Intel-gfx] [PATCH 3/6] drm/i915/guc: More debug print updates - GuC reg capture
On 2/4/2023 00:19, Teres Alexis, Alan Previn wrote: So i do have one request - but its a nit - for the following case, should it be a guc_warn instead of a guc_dbg? (last hunk in this patch) "No register capture node found for 0x%04X / 0x%08X\n", ce->guc_id.id, ce->lrc.lrca);" Did that get discussed in the original code review? I vaguely recall some reason for it not being a warning. But maybe I'm thinking of something else? Otherwise LGTM, Reviewed-by: Alan Previn On Thu, 2023-02-02 at 16:11 -0800, john.c.harri...@intel.com wrote: From: John Harrison Update a bunch more debug prints to use the new GT based scheme. Signed-off-by: John Harrison --- .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 51 --- 1 file changed, 21 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c index fc3b994626a4f..5f6e3594dda62 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c @@ -15,6 +15,7 @@ alan:snip
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Factor out a function disabling fused-off display
On 2/6/23 11:35, Imre Deak wrote:
Factor out a function used both on older and new platforms to disable
the display functionality if the display is fused-off.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_device_info.c | 34 +---
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 044ac552c9280..9d6d1fad9f1d9 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -369,6 +369,21 @@ void intel_device_info_runtime_init_early(struct
drm_i915_private *i915)
intel_device_info_subplatform_init(i915);
}
+static void disable_fused_off_display(struct drm_i915_private *i915)
+{
+ struct intel_runtime_info *runtime = RUNTIME_INFO(i915);
+
+ drm_info(&i915->drm, "Display fused off, disabling\n");
+
+ runtime->pipe_mask = 0;
+ runtime->cpu_transcoder_mask = 0;
+ runtime->fbc_mask = 0;
+ runtime->has_hdcp = 0;
+ runtime->fbc_mask = 0;
+ runtime->has_dmc = 0;
+ runtime->has_dsc = 0;
+}
+
/**
* intel_device_info_runtime_init - initialize runtime info
* @dev_priv: the i915 device
@@ -454,11 +469,7 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
sfuse_strap & SFUSE_STRAP_DISPLAY_DISABLED ||
(HAS_PCH_CPT(dev_priv) &&
!(sfuse_strap & SFUSE_STRAP_FUSE_LOCK))) {
- drm_info(&dev_priv->drm,
-"Display fused off, disabling\n");
- runtime->pipe_mask = 0;
- runtime->cpu_transcoder_mask = 0;
- runtime->fbc_mask = 0;
+ disable_fused_off_display(dev_priv);
} else if (fuse_strap & IVB_PIPE_C_DISABLE) {
drm_info(&dev_priv->drm, "PipeC fused off\n");
runtime->pipe_mask &= ~BIT(PIPE_C);
@@ -502,17 +513,8 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
}
if ((IS_DGFX(dev_priv) || DISPLAY_VER(dev_priv) >= 14) &&
- !(intel_de_read(dev_priv, GU_CNTL_PROTECTED) & DEPRESENT)) {
- drm_info(&dev_priv->drm, "Display fused off, disabling\n");
-
- runtime->pipe_mask = 0;
- runtime->cpu_transcoder_mask = 0;
- runtime->fbc_mask = 0;
- runtime->has_hdcp = 0;
- runtime->fbc_mask = 0;
- runtime->has_dmc = 0;
- runtime->has_dsc = 0;
- }
+ !(intel_de_read(dev_priv, GU_CNTL_PROTECTED) & DEPRESENT))
+ disable_fused_off_display(dev_priv);
if (GRAPHICS_VER(dev_priv) == 6 && i915_vtd_active(dev_priv)) {
drm_info(&dev_priv->drm,
Tested on Intel Arc A370M. Thank you for the fix.
Tested-by: iczero
Re: [Intel-gfx] [PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
On Wed, 2023-02-01 at 17:04 +0200, Imre Deak wrote:
>
> Yes, this patch should have no functional change, so please check what
> would apply to other drivers as well.
>
> Could you also check Ville's comment about storing start_slot elsewhere
> than the atomic state (leaving only time_slots there). I wonder if that
> would work, at least it would simplify things I think.
Ideally it'd be nice if we could have all this info in the atomic commit, but
yeah - you're not the first person to find this a bit confusing. FWIW though,
the way we store start_slot right now is intended to follow the same kind of
behavior we have with atomic CRTC commit dependencies, I think I also made it
that way so all of the state would be in a single place but there's no hard
requirement for it.
So if you guys think it'd be better design-wise to store this something else,
I've got no strong feelings either way
>
> > For 0-2:
> >
> > Reviewed-by: Lyude Paul
>
> Thanks.
>
> >
> > >
> > > Cc: Lyude Paul
> > > Cc: Ville Syrjälä
> > > Cc: Ben Skeggs
> > > Cc: Karol Herbst
> > > Cc: Harry Wentland
> > > Cc: Alex Deucher
> > > Cc: Wayne Lin
> > > Cc: sta...@vger.kernel.org # 6.1
> > > Cc: dri-de...@lists.freedesktop.org
> > > Reviewed-by: Ville Syrjälä
> > > Signed-off-by: Imre Deak
> > > ---
> > > .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
> > > drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 ++-
> > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-
> > > drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> > > include/drm/display/drm_dp_mst_helper.h | 3 ++-
> > > 5 files changed, 21 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > index a50319fc42b11..180d3893b68da 100644
> > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > @@ -208,7 +208,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
> > > if (enable)
> > > drm_dp_add_payload_part1(mst_mgr, mst_state, payload);
> > > else
> > > - drm_dp_remove_payload(mst_mgr, mst_state, payload);
> > > + drm_dp_remove_payload(mst_mgr, mst_state, payload, payload);
> > >
> > > /* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
> > >* AUX message. The sequence is slot 1-63 allocated sequence for each
> > > diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > index 847c10aa2098c..1990ff5dc7ddd 100644
> > > --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> > > @@ -3342,7 +3342,8 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
> > > * drm_dp_remove_payload() - Remove an MST payload
> > > * @mgr: Manager to use.
> > > * @mst_state: The MST atomic state
> > > - * @payload: The payload to write
> > > + * @old_payload: The payload with its old state
> > > + * @new_payload: The payload to write
> > > *
> > > * Removes a payload from an MST topology if it was successfully
> > > assigned a start slot. Also updates
> > > * the starting time slots of all other payloads which would have been
> > > shifted towards the start of
> > > @@ -3350,36 +3351,37 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
> > > */
> > > void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr *mgr,
> > > struct drm_dp_mst_topology_state *mst_state,
> > > -struct drm_dp_mst_atomic_payload *payload)
> > > +const struct drm_dp_mst_atomic_payload *old_payload,
> > > +struct drm_dp_mst_atomic_payload *new_payload)
> > > {
> > > struct drm_dp_mst_atomic_payload *pos;
> > > bool send_remove = false;
> > >
> > > /* We failed to make the payload, so nothing to do */
> > > - if (payload->vc_start_slot == -1)
> > > + if (new_payload->vc_start_slot == -1)
> > > return;
> > >
> > > mutex_lock(&mgr->lock);
> > > - send_remove = drm_dp_mst_port_downstream_of_branch(payload->port,
> > > mgr->mst_primary);
> > > + send_remove = drm_dp_mst_port_downstream_of_branch(new_payload->port,
> > > mgr->mst_primary);
> > > mutex_unlock(&mgr->lock);
> > >
> > > if (send_remove)
> > > - drm_dp_destroy_payload_step1(mgr, mst_state, payload);
> > > + drm_dp_destroy_payload_step1(mgr, mst_state, new_payload);
> > > else
> > > drm_dbg_kms(mgr->dev, "Payload for VCPI %d not in topology, not
> > > sending remove\n",
> > > - payload->vcpi);
> > > + new_payload->vcpi);
> > >
> > > list_for_each_entry(pos, &mst_state->payloads, next) {
> > > - if (pos != payload && pos->vc_start_slot >
> > > payload->vc_start_slot)
> > > - pos->vc_start_slot -= payload->time_slots;
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/4] drm/i915/dp_mst: Add the MST topology state for modesetted CRTCs
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/dp_mst: Add the MST topology
state for modesetted CRTCs
URL : https://patchwork.freedesktop.org/series/113703/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12703_full -> Patchwork_113703v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_113703v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/shard-glk2/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][3] ([fdo#109271])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/shard-glk3/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][4] ([i915#7742]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/shard-rkl-1/igt@drm_fdinfo@i...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/shard-rkl-5/igt@drm_fdinfo@i...@rcs0.html
* igt@fbdev@write:
- {shard-rkl}:[SKIP][6] ([i915#2582]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/shard-rkl-5/igt@fb...@write.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/shard-rkl-6/igt@fb...@write.html
* igt@gem_bad_reloc@negative-reloc-lut:
- {shard-rkl}:[SKIP][8] ([i915#3281]) -> [PASS][9] +2 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/shard-rkl-2/igt@gem_bad_re...@negative-reloc-lut.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/shard-rkl-5/igt@gem_bad_re...@negative-reloc-lut.html
* igt@gem_exec_fair@basic-deadline:
- {shard-rkl}:[FAIL][10] ([i915#2846]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/shard-rkl-1/igt@gem_exec_f...@basic-deadline.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/shard-rkl-1/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- {shard-rkl}:[FAIL][12] ([i915#2842]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/shard-rkl-3/igt@gem_exec_fair@basic-none-s...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/shard-rkl-3/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-tglu}: [FAIL][14] ([i915#2842]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/shard-tglu-4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/shard-tglu-6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_readwrite@read-bad-handle:
- {shard-rkl}:[SKIP][16] ([i915#3282]) -> [PASS][17] +2 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/shard-rkl-2/igt@gem_readwr...@read-bad-handle.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/shard-rkl-5/igt@gem_readwr...@read-bad-handle.html
* igt@gen9_exec_parse@basic-rejected:
- {shard-rkl}:[SKIP][18] ([i915#2527]) -> [PASS][19] +1 similar
issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/shard-rkl-1/igt@gen9_exec_pa...@basic-rejected.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/shard-rkl-5/igt@gen9_exec_pa...@basic-rejected.html
* igt@i915_pipe_stress@stress-xrgb-ytiled:
- {shard-rkl}:[SKIP][20] ([i915#4098]) -> [PASS][21] +1 similar
issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/shard-rkl-5/igt@i915_pipe_str...@stress-xrgb-ytiled.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/shard-rkl-6/igt@i915_pipe_str...@stress-xrgb-ytiled.html
* igt@i915_pm_dc@dc5-psr:
- {shard-rkl}:[SKIP][22] ([i915#658]) -> [PASS][23] +1 similar issue
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/shard-rkl-3/igt@i915_pm...@dc5-psr.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/shard-rkl-6/igt@i915_pm...@dc5-psr.html
* igt@i915_pm_dc@dc9-dpms:
- {shard-rkl}:[SKIP][24] ([i915#3361]) -> [PASS][25]
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/shard-rkl-5/igt@i
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pcode: Give the punit time to settle before fatally failing
== Series Details ==
Series: drm/i915/pcode: Give the punit time to settle before fatally failing
URL : https://patchwork.freedesktop.org/series/113717/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12704 -> Patchwork_113717v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/index.html
Participating hosts (36 -> 36)
--
Additional (1): fi-kbl-soraka
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113717v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-rpls-2}: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
Known issues
Here are the changes found in Patchwork_113717v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][5] ([i915#1886])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][6] ([i915#7913])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/fi-kbl-soraka/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271]) +15 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#7828])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/bat-dg1-5/igt@kms_chamelium_...@common-hpd-after-suspend.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [ABORT][9] ([i915#4983]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@slpc:
- {bat-rplp-1}: [DMESG-FAIL][11] ([i915#6367] / [i915#7913]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/bat-rplp-1/igt@i915_selftest@l...@slpc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/bat-rplp-1/igt@i915_selftest@l...@slpc.html
* igt@kms_busy@basic@modeset:
- fi-elk-e7500: [FAIL][13] -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/fi-elk-e7500/igt@kms_busy@ba...@modeset.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113717v1/fi-elk-e7500/igt@kms_busy@ba...@modeset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12704 -> Patchwork_113717v1
CI-20190529: 20190529
CI_DRM_12704: 0f138ae07efe477bd51695d63b03394050bb6e07 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7152: 790b81207a0a6705213ec5ea645bc5e223b2ce1d @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113717v1: 0f138ae07efe477bd51695d63b03394050bb6e07 @
git://anongit.freedesktop.
Re: [Intel-gfx] [PATCH] i915: fix memory leak with using debugfs_lookup()
On Thu, Feb 02, 2023 at 03:13:09PM +0100, Greg Kroah-Hartman wrote: > When calling debugfs_lookup() the result must have dput() called on it, > otherwise the memory will leak over time. To make things simpler, just > call debugfs_lookup_and_remove() instead which handles all of the logic > at once. > > Cc: Zhenyu Wang > Cc: Zhi Wang > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi > Cc: Tvrtko Ursulin > Cc: David Airlie > Cc: Daniel Vetter > Cc: intel-gvt-...@lists.freedesktop.org > Cc: intel-gfx@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Greg Kroah-Hartman Reviewed-by: Rodrigo Vivi Zhenyu or Zhi, could you please propagate this through your gvt branch? > --- > drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c > b/drivers/gpu/drm/i915/gvt/kvmgt.c > index 8ae7039b3683..de675d799c7d 100644 > --- a/drivers/gpu/drm/i915/gvt/kvmgt.c > +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c > @@ -699,7 +699,7 @@ static void intel_vgpu_close_device(struct vfio_device > *vfio_dev) > > clear_bit(INTEL_VGPU_STATUS_ATTACHED, vgpu->status); > > - debugfs_remove(debugfs_lookup(KVMGT_DEBUGFS_FILENAME, vgpu->debugfs)); > + debugfs_lookup_and_remove(KVMGT_DEBUGFS_FILENAME, vgpu->debugfs); > > kvm_page_track_unregister_notifier(vgpu->vfio_device.kvm, > &vgpu->track_node); > -- > 2.39.1 >
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915: Fix GEN8_MISCCPCTL
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Fix GEN8_MISCCPCTL
URL : https://patchwork.freedesktop.org/series/113713/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12704 -> Patchwork_113713v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_113713v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_113713v1, 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_113713v1/index.html
Participating hosts (36 -> 34)
--
Missing(2): bat-atsm-1 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113713v1:
### IGT changes ###
Possible regressions
* igt@kms_flip@basic-flip-vs-modeset@b-dp1:
- fi-elk-e7500: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/fi-elk-e7500/igt@kms_flip@basic-flip-vs-mode...@b-dp1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113713v1/fi-elk-e7500/igt@kms_flip@basic-flip-vs-mode...@b-dp1.html
Known issues
Here are the changes found in Patchwork_113713v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#7828])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113713v1/bat-dg1-5/igt@kms_chamelium_...@common-hpd-after-suspend.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [ABORT][4] ([i915#4983]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113713v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][6] ([i915#6367]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113713v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@kms_busy@basic@modeset:
- fi-elk-e7500: [FAIL][8] -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/fi-elk-e7500/igt@kms_busy@ba...@modeset.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113713v1/fi-elk-e7500/igt@kms_busy@ba...@modeset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
Build changes
-
* Linux: CI_DRM_12704 -> Patchwork_113713v1
CI-20190529: 20190529
CI_DRM_12704: 0f138ae07efe477bd51695d63b03394050bb6e07 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7152: 790b81207a0a6705213ec5ea645bc5e223b2ce1d @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113713v1: 0f138ae07efe477bd51695d63b03394050bb6e07 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
204afd36a3d7 drm/i915: Remove unused/wrong INF_UNIT_LEVEL_CLKGATE
80322c878d54 drm/i915: Fix GEN8_MISCCPCTL
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113713v1/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Move display power initialization during driver probing later
== Series Details ==
Series: series starting with [1/3] drm/i915: Move display power initialization
during driver probing later
URL : https://patchwork.freedesktop.org/series/113711/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12704 -> Patchwork_113711v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/index.html
Participating hosts (36 -> 34)
--
Missing(2): bat-dg1-6 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113711v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg1-5: NOTRUN -> [SKIP][1] ([i915#7828])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/bat-dg1-5/igt@kms_chamelium_...@common-hpd-after-suspend.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-1}: [ABORT][2] ([i915#6311] / [i915#7359]) -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [ABORT][4] ([i915#4983]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][6] ([i915#6367]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html
- {bat-rplp-1}: [DMESG-FAIL][8] ([i915#6367] / [i915#7913]) ->
[PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/bat-rplp-1/igt@i915_selftest@l...@slpc.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/bat-rplp-1/igt@i915_selftest@l...@slpc.html
* igt@kms_busy@basic@modeset:
- fi-elk-e7500: [FAIL][10] -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/fi-elk-e7500/igt@kms_busy@ba...@modeset.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/fi-elk-e7500/igt@kms_busy@ba...@modeset.html
* igt@kms_frontbuffer_tracking@basic:
- fi-ilk-650: [SKIP][12] ([fdo#109271]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12704/fi-ilk-650/igt@kms_frontbuffer_track...@basic.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/fi-ilk-650/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978
Build changes
-
* Linux: CI_DRM_12704 -> Patchwork_113711v1
CI-20190529: 20190529
CI_DRM_12704: 0f138ae07efe477bd51695d63b03394050bb6e07 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7152: 790b81207a0a6705213ec5ea645bc5e223b2ce1d @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113711v1: 0f138ae07efe477bd51695d63b03394050bb6e07 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
c7501e069ea5 drm/i915: Factor out a function disabling fused-off display
d86c59ea710b drm/i915/dgfx, mtl+: Disable display functionality if it's
globally fused-off
bb6af122c552 drm/i915: Move display power initialization during driver probing
later
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113711v1/index.html
Re: [Intel-gfx] [PATCH v2] drm/i915/huc: Add and use HuC oriented print macros
On 2/3/2023 12:59 AM, Michal Wajdeczko wrote:
Like we did it for GuC, introduce some helper print macros for
HuC to have unified format of messages that also include GT#.
While around improve some messages and use %pe if possible.
v2: update GSC/PXP timeout message
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
Cc: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 44 ++
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 410905da8e97..72884e21470b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,6 +6,7 @@
#include
#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
#include "intel_guc_reg.h"
#include "intel_huc.h"
#include "i915_drv.h"
@@ -13,6 +14,15 @@
#include
#include
+#define huc_printk(_huc, _level, _fmt, ...) \
+ gt_##_level(huc_to_gt(_huc), "HuC: " _fmt, ##__VA_ARGS__)
+#define huc_err(_huc, _fmt, ...) huc_printk((_huc), err, _fmt,
##__VA_ARGS__)
+#define huc_warn(_huc, _fmt, ...) huc_printk((_huc), warn, _fmt,
##__VA_ARGS__)
+#define huc_notice(_huc, _fmt, ...)huc_printk((_huc), notice, _fmt,
##__VA_ARGS__)
+#define huc_info(_huc, _fmt, ...) huc_printk((_huc), info, _fmt,
##__VA_ARGS__)
+#define huc_dbg(_huc, _fmt, ...) huc_printk((_huc), dbg, _fmt,
##__VA_ARGS__)
+#define huc_probe_error(_huc, _fmt, ...) huc_printk((_huc), probe_error, _fmt,
##__VA_ARGS__)
+
/**
* DOC: HuC
*
@@ -107,11 +117,9 @@ static enum hrtimer_restart
huc_delayed_load_timer_callback(struct hrtimer *hrti
if (!intel_huc_is_authenticated(huc)) {
if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_GSC)
- drm_notice(&huc_to_gt(huc)->i915->drm,
- "timed out waiting for MEI GSC init to load
HuC\n");
+ huc_notice(huc, "timed out waiting for MEI GSC\n");
else if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_PXP)
- drm_notice(&huc_to_gt(huc)->i915->drm,
- "timed out waiting for MEI PXP init to load
HuC\n");
+ huc_notice(huc, "timed out waiting for MEI PXP\n");
else
MISSING_CASE(huc->delayed_load.status);
@@ -174,8 +182,7 @@ static int gsc_notifier(struct notifier_block *nb, unsigned long action, void *d
case BUS_NOTIFY_DRIVER_NOT_BOUND: /* mei driver fails to be bound */
case BUS_NOTIFY_UNBIND_DRIVER: /* mei driver about to be unbound */
- drm_info(&huc_to_gt(huc)->i915->drm,
-"mei driver not bound, disabling HuC load\n");
+ huc_info(huc, "MEI driver not bound, disabling load\n");
gsc_init_error(huc);
break;
}
@@ -193,8 +200,7 @@ void intel_huc_register_gsc_notifier(struct intel_huc *huc,
struct bus_type *bus
huc->delayed_load.nb.notifier_call = gsc_notifier;
ret = bus_register_notifier(bus, &huc->delayed_load.nb);
if (ret) {
- drm_err(&huc_to_gt(huc)->i915->drm,
- "failed to register GSC notifier\n");
+ huc_err(huc, "failed to register GSC notifier %pe\n",
ERR_PTR(ret));
huc->delayed_load.nb.notifier_call = NULL;
gsc_init_error(huc);
}
@@ -306,29 +312,25 @@ static int check_huc_loading_mode(struct intel_huc *huc)
GSC_LOADS_HUC;
if (fw_needs_gsc != hw_uses_gsc) {
- drm_err(>->i915->drm,
- "mismatch between HuC FW (%s) and HW (%s) load modes\n",
- HUC_LOAD_MODE_STRING(fw_needs_gsc),
- HUC_LOAD_MODE_STRING(hw_uses_gsc));
+ huc_err(huc, "mismatch between FW (%s) and HW (%s) load
modes\n",
+ HUC_LOAD_MODE_STRING(fw_needs_gsc),
HUC_LOAD_MODE_STRING(hw_uses_gsc));
return -ENOEXEC;
}
/* make sure we can access the GSC via the mei driver if we need it */
if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) && IS_ENABLED(CONFIG_INTEL_MEI_GSC))
&&
fw_needs_gsc) {
- drm_info(>->i915->drm,
-"Can't load HuC due to missing MEI modules\n");
+ huc_info(huc, "can't load due to missing MEI modules\n");
return -EIO;
}
- drm_dbg(>->i915->drm, "GSC loads huc=%s\n", str_yes_no(fw_needs_gsc));
+ huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(fw_needs_gsc));
return 0;
}
int intel_huc_init(struct intel_huc *huc)
{
- struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
int err;
err = check_huc_loading_mode(huc);
@@ -345,7 +347,7 @@ int intel_huc_init(struct
Re: [Intel-gfx] [PATCH] drm/i915/gt: Avoid redundant pointer validity check
On Tue, Feb 07, 2023 at 12:12:18AM +0530, Deepak R Varma wrote:
> On Mon, Feb 06, 2023 at 10:33:13AM +, Matthew Auld wrote:
> > On 06/02/2023 09:45, Tvrtko Ursulin wrote:
> > >
> > > Hi,
> > >
> > > Adding Matt & Thomas as potential candidates to review.
> > >
> > > Regards,
> > >
> > > Tvrtko
> > >
> > > On 03/02/2023 19:30, Deepak R Varma wrote:
> > > > The macro definition of gen6_for_all_pdes() expands to a for loop such
> > > > that it breaks when the page table is null. Hence there is no need to
> > > > again test validity of the page table entry pointers in the pde list.
> > > > This change is identified using itnull.cocci semantic patch.
> > > >
> > > > Signed-off-by: Deepak R Varma
> > > > ---
> > > > Please note: Proposed change is compile tested only.
> > > >
> > > > drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 5 ++---
> > > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> > > > b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> > > > index 5aaacc53fa4c..787b9e6d9f59 100644
> > > > --- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> > > > +++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> > > > @@ -258,8 +258,7 @@ static void gen6_ppgtt_free_pd(struct gen6_ppgtt
> > > > *ppgtt)
> > > > u32 pde;
> > > > gen6_for_all_pdes(pt, pd, pde)
> > > > - if (pt)
> > > > - free_pt(&ppgtt->base.vm, pt);
> > > > + free_pt(&ppgtt->base.vm, pt);
> > > > }
> > > > static void gen6_ppgtt_cleanup(struct i915_address_space *vm)
> > > > @@ -304,7 +303,7 @@ static void pd_vma_unbind(struct
> > > > i915_address_space *vm,
> > > > /* Free all no longer used page tables */
> > > > gen6_for_all_pdes(pt, ppgtt->base.pd, pde) {
> > > > - if (!pt || atomic_read(&pt->used))
> > > > + if (atomic_read(&pt->used))
> >
> > Wow, I was really confused trying to remember how this all works.
> >
> > The gen6_for_all_pdes() does:
> >
> > (pt = i915_pt_entry(pd, iter), true)
> >
> > So NULL pt is expected, and does not 'break' here, since 'true' is always
> > the value that decides whether to terminate the loop. So this patch would
> > lead to NULL ptr deref, AFAICT.
>
> Hello Matt,
> I understand it now. I was misreading the true as part of the function
> argument.
> Could you please also comment if the implementation of gen6_ppgtt_free_pd() in
> the same file is safe? It doesn't appear to have an check on pt validity here.
Please ignore the question. I understand it now. My apologies for inconvenience.
The patch is invalid and can be dropped.
deepak.
>
> Thank you,
> deepak.
>
> >
> >
> >
> > > > continue;
> > > > free_pt(&ppgtt->base.vm, pt);
Re: [Intel-gfx] [PATCH] drm/i915/gt: Avoid redundant pointer validity check
On Mon, Feb 06, 2023 at 10:33:13AM +, Matthew Auld wrote:
> On 06/02/2023 09:45, Tvrtko Ursulin wrote:
> >
> > Hi,
> >
> > Adding Matt & Thomas as potential candidates to review.
> >
> > Regards,
> >
> > Tvrtko
> >
> > On 03/02/2023 19:30, Deepak R Varma wrote:
> > > The macro definition of gen6_for_all_pdes() expands to a for loop such
> > > that it breaks when the page table is null. Hence there is no need to
> > > again test validity of the page table entry pointers in the pde list.
> > > This change is identified using itnull.cocci semantic patch.
> > >
> > > Signed-off-by: Deepak R Varma
> > > ---
> > > Please note: Proposed change is compile tested only.
> > >
> > > drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 5 ++---
> > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> > > b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> > > index 5aaacc53fa4c..787b9e6d9f59 100644
> > > --- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> > > +++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
> > > @@ -258,8 +258,7 @@ static void gen6_ppgtt_free_pd(struct gen6_ppgtt
> > > *ppgtt)
> > > u32 pde;
> > > gen6_for_all_pdes(pt, pd, pde)
> > > - if (pt)
> > > - free_pt(&ppgtt->base.vm, pt);
> > > + free_pt(&ppgtt->base.vm, pt);
> > > }
> > > static void gen6_ppgtt_cleanup(struct i915_address_space *vm)
> > > @@ -304,7 +303,7 @@ static void pd_vma_unbind(struct
> > > i915_address_space *vm,
> > > /* Free all no longer used page tables */
> > > gen6_for_all_pdes(pt, ppgtt->base.pd, pde) {
> > > - if (!pt || atomic_read(&pt->used))
> > > + if (atomic_read(&pt->used))
>
> Wow, I was really confused trying to remember how this all works.
>
> The gen6_for_all_pdes() does:
>
> (pt = i915_pt_entry(pd, iter), true)
>
> So NULL pt is expected, and does not 'break' here, since 'true' is always
> the value that decides whether to terminate the loop. So this patch would
> lead to NULL ptr deref, AFAICT.
Hello Matt,
I understand it now. I was misreading the true as part of the function argument.
Could you please also comment if the implementation of gen6_ppgtt_free_pd() in
the same file is safe? It doesn't appear to have an check on pt validity here.
Thank you,
deepak.
>
>
>
> > > continue;
> > > free_pt(&ppgtt->base.vm, pt);
[Intel-gfx] [PATCH v2] drm/i915/pcode: Give the punit time to settle before fatally failing
From: Aravind Iddamsetty
During module load the punit might still be busy with its booting
routines. During this time we try to communicate with it but we
fail because we don't receive any feedback from it and we return
immediately with a -EINVAL fatal error.
At this point the driver load is "dramatically" aborted. The
following error message notifies us about it.
i915 :4d:00.0: drm_WARN_ON_ONCE(timeout_base_ms > 3)
It would be enough to wait a little in order to give the punit
the chance to come up bright and shiny, ready to interact with
the driver.
Wait up 10 seconds for the punit to settle and complete any
outstanding transactions upon module load. If it still fails try
again with a longer timeout, 180s, 3 minutes. If it still fails
then return -EPROBE_DEFER, in order to give the punit a second
chance.
Even if these timers might look long, we should consider that the
punit, depending on the platforms, might need long times to
complete its routines. Besides we want to try anything possible
to move forward before deciding to abort the driver's load.
The issue has been reported in:
https://gitlab.freedesktop.org/drm/intel/-/issues/7814
The changes in this patch are valid only and uniquely during
boot. The common transactions with the punit during the driver's
normal operation are not affected.
Signed-off-by: Aravind Iddamsetty
Co-developed-by: Chris Wilson
Signed-off-by: Chris Wilson
Signed-off-by: Andi Shyti
Cc: Rodrigo Vivi
---
Hi,
I'm proposing again the same patch as v1 with a hopefully more
descriptive commit log in order to minimize the
misunderstandings that we had during the v1 review.
Thanks,
Andi
Changelog:
==
v1 -> v2:
- write a more descriptive commit log.
- add Chris SoB which was triggering a checkpatch error.
drivers/gpu/drm/i915/intel_pcode.c | 35 ++
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pcode.c
b/drivers/gpu/drm/i915/intel_pcode.c
index a234d9b4ed143..3db2ba439bb57 100644
--- a/drivers/gpu/drm/i915/intel_pcode.c
+++ b/drivers/gpu/drm/i915/intel_pcode.c
@@ -204,15 +204,42 @@ int skl_pcode_request(struct intel_uncore *uncore, u32
mbox, u32 request,
#undef COND
}
+static int pcode_init_wait(struct intel_uncore *uncore, int timeout_ms)
+{
+ if (__intel_wait_for_register_fw(uncore,
+GEN6_PCODE_MAILBOX,
+GEN6_PCODE_READY, 0,
+500, timeout_ms,
+NULL))
+ return -EPROBE_DEFER;
+
+ return skl_pcode_request(uncore,
+DG1_PCODE_STATUS,
+DG1_UNCORE_GET_INIT_STATUS,
+DG1_UNCORE_INIT_STATUS_COMPLETE,
+DG1_UNCORE_INIT_STATUS_COMPLETE, timeout_ms);
+}
+
int intel_pcode_init(struct intel_uncore *uncore)
{
+ int err;
+
if (!IS_DGFX(uncore->i915))
return 0;
- return skl_pcode_request(uncore, DG1_PCODE_STATUS,
-DG1_UNCORE_GET_INIT_STATUS,
-DG1_UNCORE_INIT_STATUS_COMPLETE,
-DG1_UNCORE_INIT_STATUS_COMPLETE, 18);
+ /*
+* Wait 10 seconds so that the punit to settle and complete
+* any outstanding transactions upon module load
+*/
+ err = pcode_init_wait(uncore, 1);
+
+ if (err) {
+ drm_notice(&uncore->i915->drm,
+ "Waiting for HW initialisation...\n");
+ err = pcode_init_wait(uncore, 18);
+ }
+
+ return err;
}
int snb_pcode_read_p(struct intel_uncore *uncore, u32 mbcmd, u32 p1, u32 p2,
u32 *val)
--
2.39.1
[Intel-gfx] [linux-next:master] BUILD REGRESSION 129af770823407ee115a56c69a04b440fd2fbe61
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 129af770823407ee115a56c69a04b440fd2fbe61 Add linux-next specific files for 20230206 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202301230743.xnut0zvc-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301300743.bp7dpazv-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301301801.y5o08tqx-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301302110.metnwkbd-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302011836.ka3bxqdy-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302061911.c7xvhx9v-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302062223.7f7gv80m-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302062224.byzetxh1-...@intel.com Error/Warning: (recently discovered and may have been fixed) Documentation/riscv/uabi.rst:24: WARNING: Enumerated list ends without a blank line; unexpected unindent. ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! FAILED: load BTF from vmlinux: No data available arch/arm64/kvm/arm.c:2207: warning: expecting prototype for Initialize Hyp(). Prototype was for kvm_arm_init() instead drivers/clk/qcom/gcc-sa8775p.c:313:32: warning: unused variable 'gcc_parent_map_10' [-Wunused-const-variable] drivers/clk/qcom/gcc-sa8775p.c:318:37: warning: unused variable 'gcc_parent_data_10' [-Wunused-const-variable] drivers/clk/qcom/gcc-sa8775p.c:333:32: warning: unused variable 'gcc_parent_map_12' [-Wunused-const-variable] drivers/clk/qcom/gcc-sa8775p.c:338:37: warning: unused variable 'gcc_parent_data_12' [-Wunused-const-variable] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.h:62:10: fatal error: mod_info_packet.h: No such file or directory drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_hubbub.c:1011:6: warning: no previous prototype for 'hubbub31_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_hubbub.c:948:6: warning: no previous prototype for 'hubbub32_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_hubp.c:158:6: warning: no previous prototype for 'hubp32_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_resource_helpers.c:62:18: warning: variable 'cursor_bpp' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:148:6: warning: no previous prototype for 'link_dp_trace_set_edp_power_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:158:10: warning: no previous prototype for 'link_dp_trace_get_edp_poweron_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:163:10: warning: no previous prototype for 'link_dp_trace_get_edp_poweroff_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:1295:32: warning: variable 'result_write_min_hblank' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:279:42: warning: variable 'ds_port' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training.c:1585:38: warning: variable 'result' set but not used [-Wunused-but-set-variable] libbpf: failed to find '.BTF' ELF section in vmlinux Unverified Error/Warning (likely false positive, please contact us if interested): drivers/thermal/qcom/tsens-v0_1.c:106:40: sparse: sparse: symbol 'tsens_9607_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:26:40: sparse: sparse: symbol 'tsens_8916_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:42:40: sparse: sparse: symbol 'tsens_8939_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:62:40: sparse: sparse: symbol 'tsens_8974_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:84:40: sparse: sparse: symbol 'tsens_8974_backup_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v1.c:24:40: sparse: sparse: symbol 'tsens_qcs404_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v1.c:45:40: sparse: sparse: symbol 'tsens_8976_nvmem' was not declared. Should it be static? Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-randconfig-r022-20230205 | `-- drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.h:fatal-error:mod_info_packet.h:No-such-file-or-directory |-- alpha-randc
Re: [Intel-gfx] [PATCH] drm/i915/gt: Fix sphinx warnings for workarounds documentation
On Mon, Feb 06, 2023 at 12:00:01PM -0500, Rodrigo Vivi wrote:
> On Tue, Jan 31, 2023 at 02:03:01PM +0100, Mauro Carvalho Chehab wrote:
> >
> > On 1/24/23 20:39, Rodrigo Vivi wrote:
> > > On Sat, Jan 21, 2023 at 04:08:53PM -0300, Gustavo Sousa wrote:
> > > > The wildchar ("*") used in the function name patterns in the
> > > > documentation was taken as a start of an "emphasis" inline markup. Wrap
> > > > the patterns with the inline literal markup and, for consistency, do the
> > > > same for the other function names mentioned.
> > > >
> > > > Fixes: 0c3064cf33fb ("drm/i915/doc: Document where to implement
> > > > register workarounds")
> > > > Reported-by: kernel test robot
> > > > Signed-off-by: Gustavo Sousa
> > > Cc: Mauro Carvalho Chehab
> > >
> > > just in case he sees some better alternative for the escaping the '*'
> > >
> > > My fear is that this ``*_fn_name()`` could create invalid links in the
> > > doc...
> >
> >
> > Seems OK to me. ``foo`` is literal inline. It won't try to generate
> > cross-references.
> >
> >
> > Reviewed-by: Mauro Carvalho Chehab
>
> Gustavo and Mauro, please accept my apologies here.
> I ended up pushing the patch from Bagas that had a escape \*
> instead of the `` wrapper.
>
> For some unexcused reason I had missed Mauro's response here
> and forgot about this. I'm really sorry.
>
> And the escape sounded more natural so I just pushed it immediately.
No worries! I'm glad the issue that I caused is fixed :-)
--
Gustavo Sousa
>
> >
> >
> > >
> > >
> > > > ---
> > > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 20 ++--
> > > > 1 file changed, 10 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > > index 918a271447e2..e849035d8dc5 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > > @@ -30,8 +30,8 @@
> > > >* creation to have a "primed golden context", i.e. a context image
> > > > that
> > > >* already contains the changes needed to all the registers.
> > > >*
> > > > - * Context workarounds should be implemented in the
> > > > *_ctx_workarounds_init()
> > > > - * variants respective to the targeted platforms.
> > > > + * Context workarounds should be implemented in the
> > > > + * ``*_ctx_workarounds_init()`` variants respective to the targeted
> > > > platforms.
> > > >*
> > > >* - Engine workarounds: the list of these WAs is applied whenever
> > > > the specific
> > > >* engine is reset. It's also possible that a set of engine classes
> > > > share a
> > > > @@ -46,16 +46,16 @@
> > > >* ``drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c`` for reference.
> > > >*
> > > >* Workarounds for registers specific to RCS and CCS should be
> > > > implemented in
> > > > - * rcs_engine_wa_init() and ccs_engine_wa_init(), respectively;
> > > > those for
> > > > - * registers belonging to BCS, VCS or VECS should be implemented in
> > > > - * xcs_engine_wa_init(). Workarounds for registers not belonging to
> > > > a specific
> > > > - * engine's MMIO range but that are part of of the common RCS/CCS
> > > > reset domain
> > > > - * should be implemented in general_render_compute_wa_init().
> > > > + * ``rcs_engine_wa_init()`` and ``ccs_engine_wa_init()``,
> > > > respectively; those
> > > > + * for registers belonging to BCS, VCS or VECS should be implemented
> > > > in
> > > > + * ``xcs_engine_wa_init()``. Workarounds for registers not belonging
> > > > to a
> > > > + * specific engine's MMIO range but that are part of of the common
> > > > RCS/CCS
> > > > + * reset domain should be implemented in
> > > > ``general_render_compute_wa_init()``.
> > > >*
> > > >* - GT workarounds: the list of these WAs is applied whenever these
> > > > registers
> > > >* revert to their default values: on GPU reset, suspend/resume
> > > > [1]_, etc.
> > > >*
> > > > - * GT workarounds should be implemented in the
> > > > *_gt_workarounds_init()
> > > > + * GT workarounds should be implemented in the
> > > > ``*_gt_workarounds_init()``
> > > >* variants respective to the targeted platforms.
> > > >*
> > > >* - Register whitelist: some workarounds need to be implemented in
> > > > userspace,
> > > > @@ -64,8 +64,8 @@
> > > >* this is just a special case of a MMIO workaround (as we write
> > > > the list of
> > > >* these to/be-whitelisted registers to some special HW registers).
> > > >*
> > > > - * Register whitelisting should be done in the *_whitelist_build()
> > > > variants
> > > > - * respective to the targeted platforms.
> > > > + * Register whitelisting should be done in the
> > > > ``*_whitelist_build()``
> > > > + * variants respective to the targeted platforms.
> > > >*
> > > >* - Workaround batchbuffers: b
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Remove unused/wrong INF_UNIT_LEVEL_CLKGATE
On Mon, Feb 06, 2023 at 08:54:10AM -0800, Lucas De Marchi wrote: > INF_UNIT_LEVEL_CLKGATE is not replicated, but since it's not actually > used it can just be removed. > > Signed-off-by: Lucas De Marchi Reviewed-by: Matt Roper Looks like the only reference to the register was removed in commit eee42141e498fa3df3ce524846d52f67a92b6845 Author: Matt Roper AuthorDate: Tue Jul 13 12:36:35 2021 -0700 Commit: Matt Roper CommitDate: Wed Jul 14 17:49:02 2021 -0700 drm/i915/icl: Drop workarounds that only apply to pre-production steppings > --- > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > index cc1539c7a6b6..7256f7e3fd11 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > @@ -769,9 +769,6 @@ > #define GEN10_DFR_RATIO_EN_AND_CHICKEN MCR_REG(0x9550) > #define DFR_DISABLE(1 << 9) > > -#define INF_UNIT_LEVEL_CLKGATE MCR_REG(0x9560) > -#define CGPSF_CLKGATE_DIS (1 << 3) > - > #define MICRO_BP0_0 _MMIO(0x9800) > #define MICRO_BP0_2 _MMIO(0x9804) > #define MICRO_BP0_1 _MMIO(0x9808) > -- > 2.39.0 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [Intel-gfx] [PATCH] drm/i915/gt: Fix sphinx warnings for workarounds documentation
On Tue, Jan 31, 2023 at 02:03:01PM +0100, Mauro Carvalho Chehab wrote:
>
> On 1/24/23 20:39, Rodrigo Vivi wrote:
> > On Sat, Jan 21, 2023 at 04:08:53PM -0300, Gustavo Sousa wrote:
> > > The wildchar ("*") used in the function name patterns in the
> > > documentation was taken as a start of an "emphasis" inline markup. Wrap
> > > the patterns with the inline literal markup and, for consistency, do the
> > > same for the other function names mentioned.
> > >
> > > Fixes: 0c3064cf33fb ("drm/i915/doc: Document where to implement register
> > > workarounds")
> > > Reported-by: kernel test robot
> > > Signed-off-by: Gustavo Sousa
> > Cc: Mauro Carvalho Chehab
> >
> > just in case he sees some better alternative for the escaping the '*'
> >
> > My fear is that this ``*_fn_name()`` could create invalid links in the
> > doc...
>
>
> Seems OK to me. ``foo`` is literal inline. It won't try to generate
> cross-references.
>
>
> Reviewed-by: Mauro Carvalho Chehab
Gustavo and Mauro, please accept my apologies here.
I ended up pushing the patch from Bagas that had a escape \*
instead of the `` wrapper.
For some unexcused reason I had missed Mauro's response here
and forgot about this. I'm really sorry.
And the escape sounded more natural so I just pushed it immediately.
>
>
> >
> >
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 20 ++--
> > > 1 file changed, 10 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > index 918a271447e2..e849035d8dc5 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > @@ -30,8 +30,8 @@
> > >* creation to have a "primed golden context", i.e. a context image
> > > that
> > >* already contains the changes needed to all the registers.
> > >*
> > > - * Context workarounds should be implemented in the
> > > *_ctx_workarounds_init()
> > > - * variants respective to the targeted platforms.
> > > + * Context workarounds should be implemented in the
> > > + * ``*_ctx_workarounds_init()`` variants respective to the targeted
> > > platforms.
> > >*
> > >* - Engine workarounds: the list of these WAs is applied whenever the
> > > specific
> > >* engine is reset. It's also possible that a set of engine classes
> > > share a
> > > @@ -46,16 +46,16 @@
> > >* ``drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c`` for reference.
> > >*
> > >* Workarounds for registers specific to RCS and CCS should be
> > > implemented in
> > > - * rcs_engine_wa_init() and ccs_engine_wa_init(), respectively; those
> > > for
> > > - * registers belonging to BCS, VCS or VECS should be implemented in
> > > - * xcs_engine_wa_init(). Workarounds for registers not belonging to a
> > > specific
> > > - * engine's MMIO range but that are part of of the common RCS/CCS
> > > reset domain
> > > - * should be implemented in general_render_compute_wa_init().
> > > + * ``rcs_engine_wa_init()`` and ``ccs_engine_wa_init()``,
> > > respectively; those
> > > + * for registers belonging to BCS, VCS or VECS should be implemented in
> > > + * ``xcs_engine_wa_init()``. Workarounds for registers not belonging
> > > to a
> > > + * specific engine's MMIO range but that are part of of the common
> > > RCS/CCS
> > > + * reset domain should be implemented in
> > > ``general_render_compute_wa_init()``.
> > >*
> > >* - GT workarounds: the list of these WAs is applied whenever these
> > > registers
> > >* revert to their default values: on GPU reset, suspend/resume [1]_,
> > > etc.
> > >*
> > > - * GT workarounds should be implemented in the *_gt_workarounds_init()
> > > + * GT workarounds should be implemented in the
> > > ``*_gt_workarounds_init()``
> > >* variants respective to the targeted platforms.
> > >*
> > >* - Register whitelist: some workarounds need to be implemented in
> > > userspace,
> > > @@ -64,8 +64,8 @@
> > >* this is just a special case of a MMIO workaround (as we write the
> > > list of
> > >* these to/be-whitelisted registers to some special HW registers).
> > >*
> > > - * Register whitelisting should be done in the *_whitelist_build()
> > > variants
> > > - * respective to the targeted platforms.
> > > + * Register whitelisting should be done in the ``*_whitelist_build()``
> > > + * variants respective to the targeted platforms.
> > >*
> > >* - Workaround batchbuffers: buffers that get executed automatically
> > > by the
> > >* hardware on every HW context restore. These buffers are created and
> > > --
> > > 2.39.0
> > >
Re: [Intel-gfx] [bug report] drm/i915: Allow compaction upto SWIOTLB max segment size
On 06/02/2023 14:19, Dan Carpenter wrote:
[ Ancient code but the warning showed up again because the function was
renamed or something? - dan ]
Hello Chris Wilson,
The patch 871dfbd67d4e: "drm/i915: Allow compaction upto SWIOTLB max
segment size" from Oct 11, 2016, leads to the following Smatch static
checker warning:
drivers/gpu/drm/i915/gem/i915_gem_shmem.c:164 shmem_sg_alloc_table()
warn: variable dereferenced before check 'sg' (see line 155)
Is smatch getting confused here? Not entirely sure but lets see below..
drivers/gpu/drm/i915/gem/i915_gem_shmem.c
58 int shmem_sg_alloc_table(struct drm_i915_private *i915, struct sg_table
*st,
59 size_t size, struct intel_memory_region *mr,
60 struct address_space *mapping,
61 unsigned int max_segment)
62 {
63 unsigned int page_count; /* restricted by sg_alloc_table */
64 unsigned long i;
65 struct scatterlist *sg;
66 struct page *page;
67 unsigned long last_pfn = 0;/* suppress gcc warning */
68 gfp_t noreclaim;
69 int ret;
70
71 if (overflows_type(size / PAGE_SIZE, page_count))
72 return -E2BIG;
73
74 page_count = size / PAGE_SIZE;
75 /*
76 * If there's no chance of allocating enough pages for the whole
77 * object, bail early.
78 */
79 if (size > resource_size(&mr->region))
80 return -ENOMEM;
81
82 if (sg_alloc_table(st, page_count, GFP_KERNEL | __GFP_NOWARN))
83 return -ENOMEM;
84
85 /*
86 * Get the list of pages out of our struct file. They'll be
pinned
87 * at this point until we release them.
88 *
89 * Fail silently without starting the shrinker
90 */
91 mapping_set_unevictable(mapping);
92 noreclaim = mapping_gfp_constraint(mapping, ~__GFP_RECLAIM);
93 noreclaim |= __GFP_NORETRY | __GFP_NOWARN;
94
95 sg = st->sgl;
"sg" set here.
It is guaranteed to be non-NULL since sg_alloc_table succeeded.
96 st->nents = 0;
97 for (i = 0; i < page_count; i++) {
98 const unsigned int shrink[] = {
99 I915_SHRINK_BOUND | I915_SHRINK_UNBOUND,
100 0,
101 }, *s = shrink;
102 gfp_t gfp = noreclaim;
103
104 do {
105 cond_resched();
106 page = shmem_read_mapping_page_gfp(mapping, i,
gfp);
107 if (!IS_ERR(page))
108 break;
This should probably break out of the outer loop instead of the inner
loop?
Don't think so, the loop has allocated a page and wants to break out the
inner loop so the page can be appended to the sg list.
109
110 if (!*s) {
111 ret = PTR_ERR(page);
112 goto err_sg;
113 }
114
115 i915_gem_shrink(NULL, i915, 2 * page_count,
NULL, *s++);
116
117 /*
118 * We've tried hard to allocate the memory by
reaping
119 * our own buffer, now let the real VM do its
job and
120 * go down in flames if truly OOM.
121 *
122 * However, since graphics tend to be
disposable,
123 * defer the oom here by reporting the ENOMEM
back
124 * to userspace.
125 */
126 if (!*s) {
127 /* reclaim and warn, but no oom */
128 gfp = mapping_gfp_mask(mapping);
129
130 /*
131 * Our bo are always dirty and so we
require
132 * kswapd to reclaim our pages (direct
reclaim
133 * does not effectively begin pageout
of our
134 * buffers on its own). However,
direct reclaim
135 * only waits for kswapd when under
allocation
136 * congestion. So as a result
__GFP_RECLAIM is
137 * unreliable and fails to actually
reclaim our
138 * dirty pages
Re: [Intel-gfx] [RFC 1/3] drm/i915/power: move dc state members to struct i915_power_domains
On Mon, Feb 06, 2023 at 06:21:11PM +0200, Jani Nikula wrote:
> On Fri, 03 Feb 2023, Imre Deak wrote:
> > On Thu, Feb 02, 2023 at 10:47:46PM +0200, Jani Nikula wrote:
> >> There's only one reference to the struct intel_dmc members dc_state,
> >> target_dc_state, and allowed_dc_mask within intel_dmc.c, begging the
> >> question why they are under struct intel_dmc to begin with.
> >>
> >> Moreover, the only references to i915->display.dmc outside of
> >> intel_dmc.c are to these members.
> >>
> >> They don't belong. Move them from struct intel_dmc to struct
> >> i915_power_domains, which seems like a more suitable place.
> >>
> >> Cc: Imre Deak
> >> Signed-off-by: Jani Nikula
> >> ---
> >> [...]
> >>
> >> @@ -481,7 +482,7 @@ void intel_dmc_load_program(struct drm_i915_private
> >> *dev_priv)
> >>}
> >>}
> >>
> >> - dev_priv->display.dmc.dc_state = 0;
> >> + power_domains->dc_state = 0;
> >
> > This could be dropped as well, as it's already inited by the time the
> > function is called.
>
> The whole dc_state thing originates to 832dba889e27 ("drm/i915/gen9:
> Check for DC state mismatch"), and it's all about detecting
> mismatches. I'm not sure how that works and if it's still useful.
On SKL writing the DC_STATE_EN register didn't take effect, so a
workaround was added to reread/verify the write. Yes, on newer platforms
we should probably revisit this and try to remove at least the part
rereading the register 5 times.
> > I agree with making struct intel_dmc internal to intel_dmc.c. Since DC
> > state is a functionality provided by the firmware (except of DC9), an
> > alternative would be to move/add get/set/assert etc. DC state functions
> > to intel_dmc.c instead and call these from intel_display_power*.c.
>
> That was actually the first patch I wrote but didn't send. There were a
> few reasons I switched to this one:
>
> First, it adds a dependency between power well and dmc initialization.
Do you mean the dependency that is there already?: taking some power ref
and keeping the whole runtime PM functionality disabled until the
firmware load completes. This is based on an earlier decision not to
support runtime PM w/o DMC.
> Second, it's a bunch of boilerplate, six get/set functions altogether,
> and all of them checking for dmc init in patch 3.
>
> Third, it still seems funny to have these members stored in intel_dmc,
> accessed via intel_dmc.c, but intel_dmc.c not actually using them for
> anything internally. It's only the power well code that uses
> them. Should more of the DC state handling be moved to intel_dmc.c then?
I thought that any functions accessing the DC_STATE_EN register would be
moved as well (besides the state checkers you refer to). I wasn't sure
if my suggestion makes sense without actually seeing the end result; I
think we can also regard the DC_STATE_EN register as a more general
display PM HW interface leaving that in intel_display_power* (since DC9
which isn't a DMC thing is also toggled via it) and leave only the
firmware loading/initialization in intel_dmc.c as in your RFC.
> BR,
> Jani.
>
> >>gen9_set_dc_state_debugmask(dev_priv);
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h
> >> b/drivers/gpu/drm/i915/display/intel_dmc.h
> >> index 88eae74dbcf2..da8ba246013e 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dmc.h
> >> +++ b/drivers/gpu/drm/i915/display/intel_dmc.h
> >> @@ -40,9 +40,6 @@ struct intel_dmc {
> >>bool present;
> >>} dmc_info[DMC_FW_MAX];
> >>
> >> - u32 dc_state;
> >> - u32 target_dc_state;
> >> - u32 allowed_dc_mask;
> >>intel_wakeref_t wakeref;
> >> };
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> >> b/drivers/gpu/drm/i915/display/intel_psr.c
> >> index 2954759e9d12..cf13580af34a 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> >> @@ -702,6 +702,7 @@ tgl_dc3co_exitline_compute_config(struct intel_dp
> >> *intel_dp,
> >> {
> >>const u32 crtc_vdisplay = crtc_state->uapi.adjusted_mode.crtc_vdisplay;
> >>struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> >> + struct i915_power_domains *power_domains =
> >> &dev_priv->display.power.domains;
> >>u32 exit_scanlines;
> >>
> >>/*
> >> @@ -718,7 +719,7 @@ tgl_dc3co_exitline_compute_config(struct intel_dp
> >> *intel_dp,
> >>if (crtc_state->enable_psr2_sel_fetch)
> >>return;
> >>
> >> - if (!(dev_priv->display.dmc.allowed_dc_mask & DC_STATE_EN_DC3CO))
> >> + if (!(power_domains->allowed_dc_mask & DC_STATE_EN_DC3CO))
> >>return;
> >>
> >>if (!dc3co_is_pipe_port_compatible(intel_dp, crtc_state))
> >> --
> >> 2.34.1
> >>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix memory leaks in scatterlist (rev2)
On Sun, Feb 05, 2023 at 11:20:36AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix memory leaks in scatterlist (rev2)
> URL : https://patchwork.freedesktop.org/series/113576/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12692_full -> Patchwork_113576v2_full
>
>
> Summary
> ---
>
> **SUCCESS**
Applied to drm-intel-next. Thanks for the patch and review.
Matt
>
> No regressions found.
>
> External URL:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v2/index.html
>
> Participating hosts (9 -> 10)
> --
>
> Additional (1): shard-rkl0
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_113576v2_full:
>
> ### IGT changes ###
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * {igt@v3d/v3d_submit_cl@multi-and-single-sync}:
> - {shard-dg1}:NOTRUN -> [SKIP][1] +6 similar issues
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v2/shard-dg1-16/igt@v3d/v3d_submit...@multi-and-single-sync.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_113576v2_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_exec_fair@basic-none@rcs0:
> - shard-glk: [PASS][2] -> [FAIL][3] ([i915#2842])
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12692/shard-glk5/igt@gem_exec_fair@basic-n...@rcs0.html
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v2/shard-glk7/igt@gem_exec_fair@basic-n...@rcs0.html
>
> * igt@gen7_exec_parse@basic-offset:
> - shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271]) +14 similar
> issues
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v2/shard-glk8/igt@gen7_exec_pa...@basic-offset.html
>
> * igt@gen9_exec_parse@allowed-single:
> - shard-glk: [PASS][5] -> [ABORT][6] ([i915#5566])
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12692/shard-glk5/igt@gen9_exec_pa...@allowed-single.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v2/shard-glk2/igt@gen9_exec_pa...@allowed-single.html
>
> * igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a2:
> - shard-glk: [PASS][7] -> [FAIL][8] ([i915#79])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12692/shard-glk5/igt@kms_flip@flip-vs-expired-vbl...@a-hdmi-a2.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v2/shard-glk7/igt@kms_flip@flip-vs-expired-vbl...@a-hdmi-a2.html
>
> * igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf:
> - shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#658])
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v2/shard-glk8/igt@kms_psr2...@cursor-plane-move-continuous-exceed-fully-sf.html
>
> * igt@kms_writeback@writeback-fb-id:
> - shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2437])
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v2/shard-glk8/igt@kms_writeb...@writeback-fb-id.html
>
>
> Possible fixes
>
> * igt@gem_ctx_persistence@legacy-engines-hang@blt:
> - {shard-rkl}:[SKIP][11] ([i915#6252]) -> [PASS][12]
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12692/shard-rkl-5/igt@gem_ctx_persistence@legacy-engines-h...@blt.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v2/shard-rkl-2/igt@gem_ctx_persistence@legacy-engines-h...@blt.html
>
> * igt@gem_exec_capture@pi@vcs0:
> - {shard-rkl}:[ABORT][13] -> [PASS][14]
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12692/shard-rkl-1/igt@gem_exec_capture@p...@vcs0.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v2/shard-rkl-2/igt@gem_exec_capture@p...@vcs0.html
>
> * igt@gem_exec_fair@basic-deadline:
> - shard-glk: [FAIL][15] ([i915#2846]) -> [PASS][16]
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12692/shard-glk1/igt@gem_exec_f...@basic-deadline.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v2/shard-glk3/igt@gem_exec_f...@basic-deadline.html
>
> * igt@gem_exec_fair@basic-none-vip@rcs0:
> - {shard-rkl}:[FAIL][17] ([i915#2842]) -> [PASS][18]
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12692/shard-rkl-3/igt@gem_exec_fair@basic-none-...@rcs0.html
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113576v2/shard-rkl-5/igt@gem_exec_fair@basic-none-...@rcs0.html
>
> * igt@gem_exec_reloc@basic-wc-read-noreloc:
> - {shard-rkl}:[SKIP][19] ([i915#3281]) -> [PASS][20] +10 similar
> issues
>[19]:
> https://intel-gfx-ci.
[Intel-gfx] [PATCH v2 2/2] drm/i915: Remove unused/wrong INF_UNIT_LEVEL_CLKGATE
INF_UNIT_LEVEL_CLKGATE is not replicated, but since it's not actually used it can just be removed. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index cc1539c7a6b6..7256f7e3fd11 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -769,9 +769,6 @@ #define GEN10_DFR_RATIO_EN_AND_CHICKEN MCR_REG(0x9550) #define DFR_DISABLE (1 << 9) -#define INF_UNIT_LEVEL_CLKGATE MCR_REG(0x9560) -#define CGPSF_CLKGATE_DIS(1 << 3) - #define MICRO_BP0_0_MMIO(0x9800) #define MICRO_BP0_2_MMIO(0x9804) #define MICRO_BP0_1_MMIO(0x9808) -- 2.39.0
[Intel-gfx] [PATCH v2 1/2] drm/i915: Fix GEN8_MISCCPCTL
Register 0x9424 is not replicated on any platform, so it shouldn't be
declared with REG_MCR(). Declaring it with _MMIO() is basically
duplicate of the GEN7 version, so just remove the GEN8 and change all
the callers to use the right functions.
Old versions of the gen8 bspec page used to contain a table with MCR
registers, apparently implying 0x9400 - 0x94ff registers were
replicated. However that table went away and there is no information
related to the ranges for gen8 anymore. Moreover the current behavior of
the driver wouldn't do anything special for 0x9424 since there is no
equivalent table in intel_gt_mcr.c: the driver would just fallback to
intel_uncore_{read,write}(). Therefore, do not care about the possible
special case for gen8 and just use the register as non-MCR for all the
platforms.
One place doing read + write is also converted to intel_uncore_rmw().
v2: Reword commit message adding the justification wrt gen8
Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly")
Cc: Balasubramani Vivekanandan
Cc: Rodrigo Vivi
Cc: Gustavo Sousa
Cc: Matt Atwood
Cc: Ashutosh Dixit
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 5 ++---
drivers/gpu/drm/i915/intel_pm.c | 10 +-
4 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 7fa18a3b3957..cc1539c7a6b6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -686,10 +686,7 @@
#define GEN6_RSTCTL_MMIO(0x9420)
#define GEN7_MISCCPCTL _MMIO(0x9424)
-#define GEN7_DOP_CLOCK_GATE_ENABLE (1 << 0)
-
-#define GEN8_MISCCPCTL MCR_REG(0x9424)
-#define GEN8_DOP_CLOCK_GATE_ENABLE REG_BIT(0)
+#define GEN7_DOP_CLOCK_GATE_ENABLE REG_BIT(0)
#define GEN12_DOP_CLOCK_GATE_RENDER_ENABLE REG_BIT(1)
#define GEN8_DOP_CLOCK_GATE_CFCLK_ENABLE (1 << 2)
#define GEN8_DOP_CLOCK_GATE_GUC_ENABLE (1 << 4)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 29718d0595f4..cfc122c17e28 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1645,7 +1645,7 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
/* Wa_14015795083 */
- wa_mcr_write_clr(wal, GEN8_MISCCPCTL,
GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
+ wa_write_clr(wal, GEN7_MISCCPCTL, GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
/* Wa_18018781329 */
wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
@@ -1664,7 +1664,7 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
pvc_init_mcr(gt, wal);
/* Wa_14015795083 */
- wa_mcr_write_clr(wal, GEN8_MISCCPCTL,
GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
+ wa_write_clr(wal, GEN7_MISCCPCTL, GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
/* Wa_18018781329 */
wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 3d2249bda368..69133420c78b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -39,9 +39,8 @@ static void guc_prepare_xfer(struct intel_gt *gt)
if (GRAPHICS_VER(uncore->i915) == 9) {
/* DOP Clock Gating Enable for GuC clocks */
- intel_gt_mcr_multicast_write(gt, GEN8_MISCCPCTL,
-GEN8_DOP_CLOCK_GATE_GUC_ENABLE |
-intel_gt_mcr_read_any(gt,
GEN8_MISCCPCTL));
+ intel_uncore_rmw(uncore, GEN7_MISCCPCTL, 0,
+GEN8_DOP_CLOCK_GATE_GUC_ENABLE);
/* allows for 5us (in 10ns units) before GT can go to RC6 */
intel_uncore_write(uncore, GUC_ARAT_C6DIS, 0x1FF);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e0364c4141b8..798607959458 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4300,8 +4300,8 @@ static void gen8_set_l3sqc_credits(struct
drm_i915_private *dev_priv,
u32 val;
/* WaTempDisableDOPClkGating:bdw */
- misccpctl = intel_gt_mcr_multicast_rmw(to_gt(dev_priv), GEN8_MISCCPCTL,
- GEN8_DOP_CLOCK_GATE_ENABLE, 0);
+ misccpctl = intel_uncore_rmw(&dev_priv->uncore, GEN7_MISCCPCTL,
+GEN7_DOP_CLOCK_GATE_ENABLE, 0);
val = intel_gt_mcr_read_any(to_gt(dev_priv), GEN8_L3SQCREG1);
val &=
Re: [Intel-gfx] [PATCH 1/3] drm/i915/doc: Escape wildcard in method names
On Fri, Feb 03, 2023 at 05:02:13PM +0700, Bagas Sanjaya wrote:
> Stephen Rothwell reported htmldocs warnings:
>
> Documentation/gpu/i915:64: drivers/gpu/drm/i915/gt/intel_workarounds.c:32:
> WARNING: Inline emphasis start-string without end-string.
> Documentation/gpu/i915:64: drivers/gpu/drm/i915/gt/intel_workarounds.c:57:
> WARNING: Inline emphasis start-string without end-string.
> Documentation/gpu/i915:64: drivers/gpu/drm/i915/gt/intel_workarounds.c:66:
> WARNING: Inline emphasis start-string without end-string.
>
> Escape wildcards in *_ctx_workarounds_init(), *_gt_workarounds_init(), and
> *_whitelist_build() to fix above warnings.
>
> Link:
> https://lore.kernel.org/linux-next/20230203134622.0b631...@canb.auug.org.au/
> Fixes: 0c3064cf33fbfa ("drm/i915/doc: Document where to implement register
> workarounds")
> Reported-by: Stephen Rothwell
> Signed-off-by: Bagas Sanjaya
Reviewed-by: Rodrigo Vivi
pushing this now.
thank you.
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 3111df350f5722..a00ec692d980c0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -30,7 +30,7 @@
> * creation to have a "primed golden context", i.e. a context image that
> * already contains the changes needed to all the registers.
> *
> - * Context workarounds should be implemented in the
> *_ctx_workarounds_init()
> + * Context workarounds should be implemented in the
> \*_ctx_workarounds_init()
> * variants respective to the targeted platforms.
> *
> * - Engine workarounds: the list of these WAs is applied whenever the
> specific
> @@ -55,7 +55,7 @@
> * - GT workarounds: the list of these WAs is applied whenever these
> registers
> * revert to their default values: on GPU reset, suspend/resume [1]_, etc.
> *
> - * GT workarounds should be implemented in the *_gt_workarounds_init()
> + * GT workarounds should be implemented in the \*_gt_workarounds_init()
> * variants respective to the targeted platforms.
> *
> * - Register whitelist: some workarounds need to be implemented in
> userspace,
> @@ -64,7 +64,7 @@
> * this is just a special case of a MMIO workaround (as we write the list
> of
> * these to/be-whitelisted registers to some special HW registers).
> *
> - * Register whitelisting should be done in the *_whitelist_build() variants
> + * Register whitelisting should be done in the \*_whitelist_build()
> variants
> * respective to the targeted platforms.
> *
> * - Workaround batchbuffers: buffers that get executed automatically by the
> --
> An old man doll... just what I always wanted! - Clara
>
[Intel-gfx] [PATCH 3/3] drm/i915: Factor out a function disabling fused-off display
Factor out a function used both on older and new platforms to disable
the display functionality if the display is fused-off.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_device_info.c | 34 +---
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 044ac552c9280..9d6d1fad9f1d9 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -369,6 +369,21 @@ void intel_device_info_runtime_init_early(struct
drm_i915_private *i915)
intel_device_info_subplatform_init(i915);
}
+static void disable_fused_off_display(struct drm_i915_private *i915)
+{
+ struct intel_runtime_info *runtime = RUNTIME_INFO(i915);
+
+ drm_info(&i915->drm, "Display fused off, disabling\n");
+
+ runtime->pipe_mask = 0;
+ runtime->cpu_transcoder_mask = 0;
+ runtime->fbc_mask = 0;
+ runtime->has_hdcp = 0;
+ runtime->fbc_mask = 0;
+ runtime->has_dmc = 0;
+ runtime->has_dsc = 0;
+}
+
/**
* intel_device_info_runtime_init - initialize runtime info
* @dev_priv: the i915 device
@@ -454,11 +469,7 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
sfuse_strap & SFUSE_STRAP_DISPLAY_DISABLED ||
(HAS_PCH_CPT(dev_priv) &&
!(sfuse_strap & SFUSE_STRAP_FUSE_LOCK))) {
- drm_info(&dev_priv->drm,
-"Display fused off, disabling\n");
- runtime->pipe_mask = 0;
- runtime->cpu_transcoder_mask = 0;
- runtime->fbc_mask = 0;
+ disable_fused_off_display(dev_priv);
} else if (fuse_strap & IVB_PIPE_C_DISABLE) {
drm_info(&dev_priv->drm, "PipeC fused off\n");
runtime->pipe_mask &= ~BIT(PIPE_C);
@@ -502,17 +513,8 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
}
if ((IS_DGFX(dev_priv) || DISPLAY_VER(dev_priv) >= 14) &&
- !(intel_de_read(dev_priv, GU_CNTL_PROTECTED) & DEPRESENT)) {
- drm_info(&dev_priv->drm, "Display fused off, disabling\n");
-
- runtime->pipe_mask = 0;
- runtime->cpu_transcoder_mask = 0;
- runtime->fbc_mask = 0;
- runtime->has_hdcp = 0;
- runtime->fbc_mask = 0;
- runtime->has_dmc = 0;
- runtime->has_dsc = 0;
- }
+ !(intel_de_read(dev_priv, GU_CNTL_PROTECTED) & DEPRESENT))
+ disable_fused_off_display(dev_priv);
if (GRAPHICS_VER(dev_priv) == 6 && i915_vtd_active(dev_priv)) {
drm_info(&dev_priv->drm,
--
2.37.1
[Intel-gfx] [PATCH 2/3] drm/i915/dgfx, mtl+: Disable display functionality if it's globally fused-off
DG1/DG2 and MTL+ has added a new display-present HW flag. Check this
flag and if cleared, disable the driver's display functionality.
So far the missing check resulted in running the display initialization
sequence, and the WARNs below, due to the display register accesses
timing out:
[3.902843] [ cut here ]
[3.902848] i915 :03:00.0: drm_WARN_ON(intel_de_wait_for_set(dev_priv,
((const i915_reg_t){ .reg = (0x42000) }), (1 << (27 - (pg))), 1))
[3.902879] WARNING: CPU: 6 PID: 462 at
drivers/gpu/drm/i915/display/intel_display_power_well.c:326
gen9_wait_for_power_well_fuses+0x71/0x80 [i915]
[3.903009] Modules linked in: hid_sensor_hub intel_ishtp_hid i915(+)
rtsx_pci_sdmmc drm_buddy mmc_core drm_display_helper crct10dif_pclmul nvme cec
crc32_pclmul intel_ish_ipc crc32c_intel ucsi_acpi hid_multitouch nvme_core
ghash_clmulni_intel typec_ucsi rtsx_pci ttm sha512_ssse3 serio_raw intel_ishtp
typec video i2c_hid_acpi i2c_hid wmi pinctrl_tigerlake ip6_tables ip_tables
x_tables fuse
[3.903021] CPU: 6 PID: 462 Comm: systemd-udevd Tainted: G U
6.2.0-rc6+ #50
[3.903023] Hardware name: LENOVO 82VB/LNVNB161216, BIOS KMCN09WW 04/26/2022
[3.903023] RIP: 0010:gen9_wait_for_power_well_fuses+0x71/0x80 [i915]
[3.903105] Code: 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 98 bb 0d e9 48 c7
c1 00 65 a1 c0 48 89 da 48 c7 c7 4b c5 a3 c0 48 89 c6 e8 e3 df 53 e9 <0f> 0b 5b
c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90
[3.903106] RSP: 0018:a7cec0b07a98 EFLAGS: 00010292
[3.903107] RAX: 0080 RBX: 9a05430eaaa0 RCX:
[3.903108] RDX: 0001 RSI: aa7ab69e RDI:
[3.903108] RBP: 9a0552ba2020 R08: ab062ce0 R09: abd3ffc2
[3.903109] R10: R11: 0081 R12:
[3.903109] R13: 9a05532a9cb0 R14: c09e1670 R15: 9a0543132000
[3.903110] FS: 7f24d0fe5b40() GS:9a0ccf78()
knlGS:
[3.903110] CS: 0010 DS: ES: CR0: 80050033
[3.903111] CR2: 5643d7a31a28 CR3: 000111614002 CR4: 00770ee0
[3.903112] PKRU: 5554
[3.903112] Call Trace:
[3.903113]
[3.903114] hsw_power_well_enable+0x12f/0x1a0 [i915]
[3.903191] intel_power_well_enable+0x21/0x70 [i915]
[3.903265] icl_display_core_init+0x92/0x6a0 [i915]
[3.903346] intel_power_domains_init_hw+0x1da/0x5b0 [i915]
[3.903422] intel_modeset_init_noirq+0x60/0x250 [i915]
[3.903497] i915_driver_probe+0x562/0xe10 [i915]
[3.903557] ? i915_pci_probe+0x87/0x180 [i915]
[3.903617] local_pci_probe+0x3e/0x80
[3.903621] pci_device_probe+0xb3/0x210
[3.903622] really_probe+0xdb/0x380
[3.903624] ? pm_runtime_barrier+0x50/0x90
[3.903626] __driver_probe_device+0x78/0x170
[3.903627] driver_probe_device+0x1f/0x90
[3.903628] __driver_attach+0xce/0x1c0
[3.903629] ? __pfx___driver_attach+0x10/0x10
[3.903630] bus_for_each_dev+0x5f/0x90
[3.903631] bus_add_driver+0x1ae/0x200
[3.903632] driver_register+0x89/0xe0
[3.903634] i915_init+0x1f/0x7f [i915]
[3.903695] ? __pfx_init_module+0x10/0x10 [i915]
[3.903751] do_one_initcall+0x43/0x220
[3.903753] ? kmalloc_trace+0x26/0x90
[3.903756] do_init_module+0x4a/0x200
[3.903758] __do_sys_init_module+0x157/0x180
[3.903760] do_syscall_64+0x58/0xc0
[3.903762] ? do_syscall_64+0x67/0xc0
[3.903762] ? exc_page_fault+0x70/0x170
[3.903764] entry_SYSCALL_64_after_hwframe+0x72/0xdc
Bspec: 49189, 53112
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8015
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_device_info.c | 13 +
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 596efc940ee70..a22a0fa299645 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -116,6 +116,9 @@
* #define GEN8_BAR_MMIO(0xb888)
*/
+#define GU_CNTL_PROTECTED _MMIO(0x10100C)
+#define DEPRESENTREG_BIT(9)
+
#define GU_CNTL_MMIO(0x101010)
#define LMEM_INITREG_BIT(7)
#define DRIVERFLRREG_BIT(31)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 98769e5f2c3d1..044ac552c9280 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -501,6 +501,19 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
runtime->has_dsc = 0;
}
+ if ((IS_DGFX(dev_priv) || DISPLAY_VER(dev_priv) >= 14) &&
+ !(intel_de_read(dev_priv, GU_CNTL_PROTECTED) & DEPRESENT)) {
+ drm_info(&dev_priv-
[Intel-gfx] [PATCH 1/3] drm/i915: Move display power initialization during driver probing later
Determining whether the display engine is fused-off on a platform happens only in intel_device_info_runtime_init(). Initializing the display power functionality depends on this condition, so move intel_power_domains_init() later after the runtime init function has been called. The next patch fixing platforms with the display fused-off, depends on this patch. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/display/intel_display.c | 5 + drivers/gpu/drm/i915/i915_driver.c | 7 --- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 12ade593c..b3e7ed3866cde 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -8634,6 +8634,10 @@ int intel_modeset_init_noirq(struct drm_i915_private *i915) goto cleanup_bios; /* FIXME: completely on the wrong abstraction layer */ + ret = intel_power_domains_init(i915); + if (ret < 0) + goto cleanup_vga; + intel_power_domains_init_hw(i915, false); if (!HAS_DISPLAY(i915)) @@ -8676,6 +8680,7 @@ int intel_modeset_init_noirq(struct drm_i915_private *i915) cleanup_vga_client_pw_domain_dmc: intel_dmc_ucode_fini(i915); intel_power_domains_driver_remove(i915); +cleanup_vga: intel_vga_unregister(i915); cleanup_bios: intel_bios_driver_remove(i915); diff --git a/drivers/gpu/drm/i915/i915_driver.c b/drivers/gpu/drm/i915/i915_driver.c index 13bf4fe52f9fe..fe2870a6ae631 100644 --- a/drivers/gpu/drm/i915/i915_driver.c +++ b/drivers/gpu/drm/i915/i915_driver.c @@ -251,9 +251,6 @@ static int i915_driver_early_probe(struct drm_i915_private *dev_priv) intel_detect_pch(dev_priv); intel_pm_setup(dev_priv); - ret = intel_power_domains_init(dev_priv); - if (ret < 0) - goto err_gem; intel_irq_init(dev_priv); intel_init_display_hooks(dev_priv); intel_init_clock_gating_hooks(dev_priv); @@ -262,10 +259,6 @@ static int i915_driver_early_probe(struct drm_i915_private *dev_priv) return 0; -err_gem: - i915_gem_cleanup_early(dev_priv); - intel_gt_driver_late_release_all(dev_priv); - i915_drm_clients_fini(&dev_priv->clients); err_rootgt: intel_region_ttm_device_fini(dev_priv); err_ttm: -- 2.37.1
Re: [Intel-gfx] [RFC 1/3] drm/i915/power: move dc state members to struct i915_power_domains
On Fri, 03 Feb 2023, Imre Deak wrote:
> On Thu, Feb 02, 2023 at 10:47:46PM +0200, Jani Nikula wrote:
>> There's only one reference to the struct intel_dmc members dc_state,
>> target_dc_state, and allowed_dc_mask within intel_dmc.c, begging the
>> question why they are under struct intel_dmc to begin with.
>>
>> Moreover, the only references to i915->display.dmc outside of
>> intel_dmc.c are to these members.
>>
>> They don't belong. Move them from struct intel_dmc to struct
>> i915_power_domains, which seems like a more suitable place.
>>
>> Cc: Imre Deak
>> Signed-off-by: Jani Nikula
>> ---
>> [...]
>>
>> @@ -481,7 +482,7 @@ void intel_dmc_load_program(struct drm_i915_private
>> *dev_priv)
>> }
>> }
>>
>> -dev_priv->display.dmc.dc_state = 0;
>> +power_domains->dc_state = 0;
>
> This could be dropped as well, as it's already inited by the time the
> function is called.
The whole dc_state thing originates to 832dba889e27 ("drm/i915/gen9:
Check for DC state mismatch"), and it's all about detecting
mismatches. I'm not sure how that works and if it's still useful.
> I agree with making struct intel_dmc internal to intel_dmc.c. Since DC
> state is a functionality provided by the firmware (except of DC9), an
> alternative would be to move/add get/set/assert etc. DC state functions
> to intel_dmc.c instead and call these from intel_display_power*.c.
That was actually the first patch I wrote but didn't send. There were a
few reasons I switched to this one:
First, it adds a dependency between power well and dmc initialization.
Second, it's a bunch of boilerplate, six get/set functions altogether,
and all of them checking for dmc init in patch 3.
Third, it still seems funny to have these members stored in intel_dmc,
accessed via intel_dmc.c, but intel_dmc.c not actually using them for
anything internally. It's only the power well code that uses
them. Should more of the DC state handling be moved to intel_dmc.c then?
BR,
Jani.
>
>>
>> gen9_set_dc_state_debugmask(dev_priv);
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h
>> b/drivers/gpu/drm/i915/display/intel_dmc.h
>> index 88eae74dbcf2..da8ba246013e 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dmc.h
>> +++ b/drivers/gpu/drm/i915/display/intel_dmc.h
>> @@ -40,9 +40,6 @@ struct intel_dmc {
>> bool present;
>> } dmc_info[DMC_FW_MAX];
>>
>> -u32 dc_state;
>> -u32 target_dc_state;
>> -u32 allowed_dc_mask;
>> intel_wakeref_t wakeref;
>> };
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
>> b/drivers/gpu/drm/i915/display/intel_psr.c
>> index 2954759e9d12..cf13580af34a 100644
>> --- a/drivers/gpu/drm/i915/display/intel_psr.c
>> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
>> @@ -702,6 +702,7 @@ tgl_dc3co_exitline_compute_config(struct intel_dp
>> *intel_dp,
>> {
>> const u32 crtc_vdisplay = crtc_state->uapi.adjusted_mode.crtc_vdisplay;
>> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>> +struct i915_power_domains *power_domains =
>> &dev_priv->display.power.domains;
>> u32 exit_scanlines;
>>
>> /*
>> @@ -718,7 +719,7 @@ tgl_dc3co_exitline_compute_config(struct intel_dp
>> *intel_dp,
>> if (crtc_state->enable_psr2_sel_fetch)
>> return;
>>
>> -if (!(dev_priv->display.dmc.allowed_dc_mask & DC_STATE_EN_DC3CO))
>> +if (!(power_domains->allowed_dc_mask & DC_STATE_EN_DC3CO))
>> return;
>>
>> if (!dc3co_is_pipe_port_compatible(intel_dp, crtc_state))
>> --
>> 2.34.1
>>
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/9] drm/i915/display/core: use intel_de_rmw if possible (rev4)
== Series Details ==
Series: series starting with [v2,1/9] drm/i915/display/core: use intel_de_rmw
if possible (rev4)
URL : https://patchwork.freedesktop.org/series/112438/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12701_full -> Patchwork_112438v4_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/index.html
Participating hosts (10 -> 11)
--
Additional (1): shard-rkl0
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_112438v4_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_pm_dc@dc5-dpms-negative}:
- {shard-tglu-9}: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/shard-tglu-9/igt@i915_pm...@dc5-dpms-negative.html
Known issues
Here are the changes found in Patchwork_112438v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: NOTRUN -> [FAIL][2] ([i915#2842])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/shard-glk7/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#3886])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/shard-glk7/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_chamelium_color@ctm-negative:
- shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271]) +22 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/shard-glk7/igt@kms_chamelium_co...@ctm-negative.html
* igt@kms_plane_alpha_blend@alpha-basic@pipe-c-hdmi-a-1:
- shard-glk: NOTRUN -> [FAIL][5] ([i915#7862]) +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/shard-glk7/igt@kms_plane_alpha_blend@alpha-ba...@pipe-c-hdmi-a-1.html
Possible fixes
* igt@api_intel_bb@object-reloc-keep-cache:
- {shard-rkl}:[SKIP][6] ([i915#3281]) -> [PASS][7] +3 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12701/shard-rkl-6/igt@api_intel...@object-reloc-keep-cache.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/shard-rkl-5/igt@api_intel...@object-reloc-keep-cache.html
* igt@fbdev@read:
- {shard-rkl}:[SKIP][8] ([i915#2582]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12701/shard-rkl-4/igt@fb...@read.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/shard-rkl-6/igt@fb...@read.html
* igt@gem_partial_pwrite_pread@write:
- {shard-rkl}:[SKIP][10] ([i915#3282]) -> [PASS][11] +2 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12701/shard-rkl-6/igt@gem_partial_pwrite_pr...@write.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/shard-rkl-5/igt@gem_partial_pwrite_pr...@write.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [ABORT][12] ([i915#5566]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12701/shard-glk6/igt@gen9_exec_pa...@allowed-single.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/shard-glk7/igt@gen9_exec_pa...@allowed-single.html
* igt@gen9_exec_parse@basic-rejected-ctx-param:
- {shard-rkl}:[SKIP][14] ([i915#2527]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12701/shard-rkl-6/igt@gen9_exec_pa...@basic-rejected-ctx-param.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/shard-rkl-5/igt@gen9_exec_pa...@basic-rejected-ctx-param.html
* igt@i915_hangman@engine-engine-error@bcs0:
- {shard-rkl}:[SKIP][16] ([i915#6258]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12701/shard-rkl-5/igt@i915_hangman@engine-engine-er...@bcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/shard-rkl-6/igt@i915_hangman@engine-engine-er...@bcs0.html
* igt@i915_pm_rpm@cursor-dpms:
- {shard-rkl}:[SKIP][18] ([i915#1849]) -> [PASS][19] +1 similar
issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12701/shard-rkl-4/igt@i915_pm_...@cursor-dpms.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/shard-rkl-6/igt@i915_pm_...@cursor-dpms.html
* igt@i915_pm_rpm@dpms-lpsp:
- {shard-tglu}: [SKIP][20] ([i915#1397]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12701/shard-tglu-6/igt@i915_pm_...@dpms-lpsp.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchw
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915/dp_mst: Add the MST topology state for modesetted CRTCs
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/dp_mst: Add the MST topology
state for modesetted CRTCs
URL : https://patchwork.freedesktop.org/series/113703/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12703 -> Patchwork_113703v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/index.html
Participating hosts (28 -> 26)
--
Missing(2): bat-atsm-1 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113703v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-kbl-soraka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/fi-kbl-soraka/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][3] -> [DMESG-FAIL][4] ([i915#5334])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- fi-kbl-soraka: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/fi-kbl-soraka/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/fi-kbl-soraka/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@requests:
- {bat-rplp-1}: [ABORT][7] ([i915#7913]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/bat-rplp-1/igt@i915_selftest@l...@requests.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/bat-rplp-1/igt@i915_selftest@l...@requests.html
Warnings
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: [INCOMPLETE][9] -> [INCOMPLETE][10] ([i915#7156])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12703/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
Build changes
-
* Linux: CI_DRM_12703 -> Patchwork_113703v1
CI-20190529: 20190529
CI_DRM_12703: 97082f638eab440cda538934bd208be714a32c3d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7150: 699a971852185d5e536f9cd1735dc0e255d79946 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113703v1: 97082f638eab440cda538934bd208be714a32c3d @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
f0d00d836cad drm/i915/dp_mst: Fix payload removal during output disabling
3556434a5c3e drm/display/dp_mst: Add drm_atomic_get_old_mst_topology_state()
37517f4499e9 drm/display/dp_mst: Handle old/new payload states in
drm_dp_remove_payload()
1bfbc960ac44 drm/i915/dp_mst: Add the MST topology state for modesetted CRTCs
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113703v1/index.html
Re: [Intel-gfx] [PATCH v4 2/2] vfio: no need to pass kvm pointer during device open
Tested-by: Tony Krowiak
On 2/3/23 4:50 PM, Matthew Rosato wrote:
Nothing uses this value during vfio_device_open anymore so it's safe
to remove it.
Signed-off-by: Matthew Rosato
---
drivers/vfio/group.c | 2 +-
drivers/vfio/vfio.h | 3 +--
drivers/vfio/vfio_main.c | 7 +++
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index 98621ac082f0..0e9036e2b9c4 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -187,7 +187,7 @@ static int vfio_device_group_open(struct vfio_device
*device)
if (device->open_count == 0)
vfio_device_group_get_kvm_safe(device);
- ret = vfio_device_open(device, device->group->iommufd, device->kvm);
+ ret = vfio_device_open(device, device->group->iommufd);
if (device->open_count == 0)
vfio_device_put_kvm(device);
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 24d6cd285945..4f39ab549a80 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -18,8 +18,7 @@ struct vfio_container;
void vfio_device_put_registration(struct vfio_device *device);
bool vfio_device_try_get_registration(struct vfio_device *device);
-int vfio_device_open(struct vfio_device *device,
-struct iommufd_ctx *iommufd, struct kvm *kvm);
+int vfio_device_open(struct vfio_device *device, struct iommufd_ctx *iommufd);
void vfio_device_close(struct vfio_device *device,
struct iommufd_ctx *iommufd);
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 28c47cd6a6b5..3a597e799918 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -397,7 +397,7 @@ static bool vfio_assert_device_open(struct vfio_device
*device)
}
static int vfio_device_first_open(struct vfio_device *device,
- struct iommufd_ctx *iommufd, struct kvm *kvm)
+ struct iommufd_ctx *iommufd)
{
int ret;
@@ -444,8 +444,7 @@ static void vfio_device_last_close(struct vfio_device *device,
module_put(device->dev->driver->owner);
}
-int vfio_device_open(struct vfio_device *device,
-struct iommufd_ctx *iommufd, struct kvm *kvm)
+int vfio_device_open(struct vfio_device *device, struct iommufd_ctx *iommufd)
{
int ret = 0;
@@ -453,7 +452,7 @@ int vfio_device_open(struct vfio_device *device,
device->open_count++;
if (device->open_count == 1) {
- ret = vfio_device_first_open(device, iommufd, kvm);
+ ret = vfio_device_first_open(device, iommufd);
if (ret)
device->open_count--;
}
Re: [Intel-gfx] [PATCH v4 1/2] vfio: fix deadlock between group lock and kvm lock
Tested-by: Tony Krowiak
On 2/3/23 4:50 PM, Matthew Rosato wrote:
After 51cdc8bc120e, we have another deadlock scenario between the
kvm->lock and the vfio group_lock with two different codepaths acquiring
the locks in different order. Specifically in vfio_open_device, vfio
holds the vfio group_lock when issuing device->ops->open_device but some
drivers (like vfio-ap) need to acquire kvm->lock during their open_device
routine; Meanwhile, kvm_vfio_release will acquire the kvm->lock first
before calling vfio_file_set_kvm which will acquire the vfio group_lock.
To resolve this, let's remove the need for the vfio group_lock from the
kvm_vfio_release codepath. This is done by introducing a new spinlock to
protect modifications to the vfio group kvm pointer, and acquiring a kvm
ref from within vfio while holding this spinlock, with the reference held
until the last close for the device in question.
Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio group_lock")
Reported-by: Anthony Krowiak
Suggested-by: Jason Gunthorpe
Signed-off-by: Matthew Rosato
---
drivers/vfio/group.c | 44 +++-
drivers/vfio/vfio.h | 15 ++
drivers/vfio/vfio_main.c | 63 +++-
include/linux/vfio.h | 2 +-
4 files changed, 109 insertions(+), 15 deletions(-)
diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index bb24b2f0271e..98621ac082f0 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -154,6 +154,18 @@ static int vfio_group_ioctl_set_container(struct
vfio_group *group,
return ret;
}
+static void vfio_device_group_get_kvm_safe(struct vfio_device *device)
+{
+ spin_lock(&device->group->kvm_ref_lock);
+ if (!device->group->kvm)
+ goto unlock;
+
+ _vfio_device_get_kvm_safe(device, device->group->kvm);
+
+unlock:
+ spin_unlock(&device->group->kvm_ref_lock);
+}
+
static int vfio_device_group_open(struct vfio_device *device)
{
int ret;
@@ -164,13 +176,23 @@ static int vfio_device_group_open(struct vfio_device
*device)
goto out_unlock;
}
+ mutex_lock(&device->dev_set->lock);
+
/*
-* Here we pass the KVM pointer with the group under the lock. If the
-* device driver will use it, it must obtain a reference and release it
-* during close_device.
+* Before the first device open, get the KVM pointer currently
+* associated with the group (if there is one) and obtain a reference
+* now that will be held until the open_count reaches 0 again. Save
+* the pointer in the device for use by drivers.
*/
- ret = vfio_device_open(device, device->group->iommufd,
- device->group->kvm);
+ if (device->open_count == 0)
+ vfio_device_group_get_kvm_safe(device);
+
+ ret = vfio_device_open(device, device->group->iommufd, device->kvm);
+
+ if (device->open_count == 0)
+ vfio_device_put_kvm(device);
+
+ mutex_unlock(&device->dev_set->lock);
out_unlock:
mutex_unlock(&device->group->group_lock);
@@ -180,7 +202,14 @@ static int vfio_device_group_open(struct vfio_device
*device)
void vfio_device_group_close(struct vfio_device *device)
{
mutex_lock(&device->group->group_lock);
+ mutex_lock(&device->dev_set->lock);
+
vfio_device_close(device, device->group->iommufd);
+
+ if (device->open_count == 0)
+ vfio_device_put_kvm(device);
+
+ mutex_unlock(&device->dev_set->lock);
mutex_unlock(&device->group->group_lock);
}
@@ -450,6 +479,7 @@ static struct vfio_group *vfio_group_alloc(struct iommu_group *iommu_group,
refcount_set(&group->drivers, 1);
mutex_init(&group->group_lock);
+ spin_lock_init(&group->kvm_ref_lock);
INIT_LIST_HEAD(&group->device_list);
mutex_init(&group->device_lock);
group->iommu_group = iommu_group;
@@ -803,9 +833,9 @@ void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
if (!vfio_file_is_group(file))
return;
- mutex_lock(&group->group_lock);
+ spin_lock(&group->kvm_ref_lock);
group->kvm = kvm;
- mutex_unlock(&group->group_lock);
+ spin_unlock(&group->kvm_ref_lock);
}
EXPORT_SYMBOL_GPL(vfio_file_set_kvm);
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index f8219a438bfb..24d6cd285945 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -74,6 +74,7 @@ struct vfio_group {
struct file *opened_file;
struct blocking_notifier_head notifier;
struct iommufd_ctx *iommufd;
+ spinlock_t kvm_ref_lock;
};
int vfio_device_set_group(struct vfio_device *device,
@@ -251,4 +252,18 @@ extern bool vfio_noiommu __read_mostly;
enum { vfio_noiommu = false };
#endif
+#ifdef CONFIG_HAVE_KVM
+void _vfi
[Intel-gfx] [bug report] drm/i915: Allow compaction upto SWIOTLB max segment size
[ Ancient code but the warning showed up again because the function was
renamed or something? - dan ]
Hello Chris Wilson,
The patch 871dfbd67d4e: "drm/i915: Allow compaction upto SWIOTLB max
segment size" from Oct 11, 2016, leads to the following Smatch static
checker warning:
drivers/gpu/drm/i915/gem/i915_gem_shmem.c:164 shmem_sg_alloc_table()
warn: variable dereferenced before check 'sg' (see line 155)
drivers/gpu/drm/i915/gem/i915_gem_shmem.c
58 int shmem_sg_alloc_table(struct drm_i915_private *i915, struct sg_table
*st,
59 size_t size, struct intel_memory_region *mr,
60 struct address_space *mapping,
61 unsigned int max_segment)
62 {
63 unsigned int page_count; /* restricted by sg_alloc_table */
64 unsigned long i;
65 struct scatterlist *sg;
66 struct page *page;
67 unsigned long last_pfn = 0;/* suppress gcc warning */
68 gfp_t noreclaim;
69 int ret;
70
71 if (overflows_type(size / PAGE_SIZE, page_count))
72 return -E2BIG;
73
74 page_count = size / PAGE_SIZE;
75 /*
76 * If there's no chance of allocating enough pages for the whole
77 * object, bail early.
78 */
79 if (size > resource_size(&mr->region))
80 return -ENOMEM;
81
82 if (sg_alloc_table(st, page_count, GFP_KERNEL | __GFP_NOWARN))
83 return -ENOMEM;
84
85 /*
86 * Get the list of pages out of our struct file. They'll be
pinned
87 * at this point until we release them.
88 *
89 * Fail silently without starting the shrinker
90 */
91 mapping_set_unevictable(mapping);
92 noreclaim = mapping_gfp_constraint(mapping, ~__GFP_RECLAIM);
93 noreclaim |= __GFP_NORETRY | __GFP_NOWARN;
94
95 sg = st->sgl;
"sg" set here.
96 st->nents = 0;
97 for (i = 0; i < page_count; i++) {
98 const unsigned int shrink[] = {
99 I915_SHRINK_BOUND | I915_SHRINK_UNBOUND,
100 0,
101 }, *s = shrink;
102 gfp_t gfp = noreclaim;
103
104 do {
105 cond_resched();
106 page = shmem_read_mapping_page_gfp(mapping, i,
gfp);
107 if (!IS_ERR(page))
108 break;
This should probably break out of the outer loop instead of the inner
loop?
109
110 if (!*s) {
111 ret = PTR_ERR(page);
112 goto err_sg;
113 }
114
115 i915_gem_shrink(NULL, i915, 2 * page_count,
NULL, *s++);
116
117 /*
118 * We've tried hard to allocate the memory by
reaping
119 * our own buffer, now let the real VM do its
job and
120 * go down in flames if truly OOM.
121 *
122 * However, since graphics tend to be
disposable,
123 * defer the oom here by reporting the ENOMEM
back
124 * to userspace.
125 */
126 if (!*s) {
127 /* reclaim and warn, but no oom */
128 gfp = mapping_gfp_mask(mapping);
129
130 /*
131 * Our bo are always dirty and so we
require
132 * kswapd to reclaim our pages (direct
reclaim
133 * does not effectively begin pageout
of our
134 * buffers on its own). However, direct
reclaim
135 * only waits for kswapd when under
allocation
136 * congestion. So as a result
__GFP_RECLAIM is
137 * unreliable and fails to actually
reclaim our
138 * dirty pages -- unless you try over
and over
139 * again with !__GFP_NORETRY. However,
we still
140 * want to fail this allocation rather
than
141 * trigger the out-of-memory killer and
for
142 * this we want __GFP_RETRY_MAYFAIL.
143
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add another EHL pci id
On Mon, 2023-02-06 at 08:59 +, Patchwork wrote:
> Patch Details
> Series: drm/i915: Add another EHL pci id
> URL: https://patchwork.freedesktop.org/series/113691/
> State: success
Pushed, thanks for the patch.
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113691v1/index.html
>
> CI Bug Log - changes from CI_DRM_12697_full ->
> Patchwork_113691v1_fullSummarySUCCESS
> No regressions found.
> External URL:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113691v1/index.html
> Participating hosts (9 -> 11)Additional (2): shard-rkl0 shard-tglu-9
> Known issuesHere are the changes found in Patchwork_113691v1_full that come
> from known issues:
> IGT changesIssues hit * igt@gen9_exec_parse@allowed-single:shard-glk: PASS ->
> ABORT (i915#5566)
> *
> igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:shard-glk:
> PASS -> FAIL (i915#2346)
> *
> igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ab-hdmi-a1-hdmi-a2:shard-glk:
> PASS -> FAIL (i915#79)
> Possible fixes * igt@drm_fdinfo@idle@rcs0:{shard-rkl}: FAIL (i915#7742) ->
> PASS
> * igt@gem_exec_fair@basic-none-rrul@rcs0:{shard-rkl}: FAIL (i915#2842) ->
> PASS
> * igt@gem_exec_fair@basic-pace-share@rcs0:shard-glk: FAIL (i915#2842) -> PASS
> * igt@gem_exec_reloc@basic-cpu-read-noreloc:{shard-rkl}: SKIP (i915#3281) ->
> PASS +5 similar issues
> * igt@gem_exec_schedule@semaphore-power:{shard-rkl}: SKIP (i915#7276) -> PASS
> * igt@gem_mmap_gtt@coherency:{shard-rkl}: SKIP (fdo#111656) -> PASS
> * igt@gem_partial_pwrite_pread@writes-after-reads:{shard-rkl}: SKIP
> (i915#3282) -> PASS +9 similar issues
> * igt@gen9_exec_parse@bb-start-param:{shard-rkl}: SKIP (i915#2527) -> PASS
> +4 similar issues
> * igt@i915_pm_rpm@modeset-lpsp:{shard-rkl}: SKIP (i915#1397) -> PASS
> * igt@i915_pm_sseu@full-enable:{shard-rkl}: SKIP (i915#4387) -> PASS
> * igt@kms_big_fb@x-tiled-32bpp-rotate-0:{shard-rkl}: SKIP (i915#1845 /
> i915#4098) -> PASS +26 similar issues
> * igt@kms_dp_aux_dev:{shard-rkl}: SKIP (i915#1257) -> PASS
> * igt@kms_fbcon_fbt@fbc:{shard-rkl}: SKIP (i915#4098) -> PASS
> * igt@kms_fbcon_fbt@psr-suspend:{shard-rkl}: SKIP (fdo#110189 / i915#3955)
> -> PASS
> *
> igt@kms_flip@2x-plain-flip-ts-check-interruptible@ab-hdmi-a1-hdmi-a2:shard-glk:
> FAIL (i915#2122) -> PASS
> * igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a1:shard-glk: FAIL (i915#79) ->
> PASS
> *
> igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:{shard-rkl}:
> SKIP (i915#1849 / i915#4098) -> PASS +20 similar issues
> * igt@kms_psr@cursor_blt:{shard-rkl}: SKIP (i915#1072) -> PASS +2 similar
> issues
> * igt@perf@gen8-unprivileged-single-ctx-counters:{shard-rkl}: SKIP
> (i915#2436) -> PASS
> * igt@perf@mi-rpc:{shard-rkl}: SKIP (i915#2434) -> PASS
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
> Build changes * Linux: CI_DRM_12697 -> Patchwork_113691v1
> CI-20190529: 20190529
> CI_DRM_12697: 36bc05063652a1bb1a8c00c19c39281dc7ecf015 @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_7149: 1c7ea154b625e1fb826f1519b816b4256dd10b62 @
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
> Patchwork_113691v1: 36bc05063652a1bb1a8c00c19c39281dc7ecf015 @
> git://anongit.freedesktop.org/gfx-ci/linux
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool
Hi Tvrtko, On 2023-02-06 at 09:19:02 +, Tvrtko Ursulin wrote: > > On 03/02/2023 16:42, Kamil Konieczny wrote: > > Hi Tvrtko, > > > > On 2023-01-31 at 11:32:37 +, Tvrtko Ursulin wrote: > > > From: Tvrtko Ursulin > > > > > > Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used > > > to display a sorted by card and usage list of processes using GPUs. > > > > > > Borrows a bit of code from intel_gpu_top but for now omits the fancy > > > features like interactive functionality, card selection, client > > > aggregation, sort modes, JSON output and pretty engine names. Also no > > > support for global GPU or system metrics. > > > > > > On the other hand it shows clients from all DRM cards which > > > intel_gpu_top does not do. > > > > > > Signed-off-by: Tvrtko Ursulin > > > Cc: Rob Clark > > > Cc: Christian König > > > Acked-by: Christian König > > > > I run it with: > > # ./gputop > > > > but it do not work on my Skylake card, I see no output, > > kernel 5.19.0-29-generic, ubuntu 22.10 > > Odd, 5.19 should have the support. Intel_gpu_top works - it is showing the > individual clients? There is no display nor any gpu app running, when I run some igt tests then it does sometimes prints some activity. Intel_gpu_top works and shows headers and zero activity so it mislead me. > > > > > # ./lsgpu > > card0Intel Skylake (Gen9) > > drm:/dev/dri/card0 > > └─renderD128 > > drm:/dev/dri/renderD128 > > > > Please add some options like debug, version, debug with high > > verbose level, help. It seems like q or Q do not exit. > > As the cover letter hints I was only set out to demonstrate an extremely > rudimentary vendor agnostic tool. To quote the cover letter more - "..It > also makes no effort to provide sorting modes, well any interactivity, or > any pretty names for GPUs or engines..". I have no scope presently to make > it better or nicer. > > The tool however can serve as a starting point and people had reported it > working as-is with a few other drivers, AMD, msm and most recently I believe > etnaviv. So perhaps a pool of people to further improve it will be found > there in the future. > > In summary I think it's worth reviewing so that the common code gets > extracted from intel_gpu_top into respective libraries. After that I was > hoping other people start contributing further improvements. > > Regards, > > Tvrtko I agree it is good starting point, it may have something like overall gpu activity, imho something which shows gpu % usage (mem % and power %) for all GPUs present. Regards, Kamil
Re: [Intel-gfx] [PATCH] drm/i915: Add another EHL pci id
On Mon, 2023-02-06 at 15:37 +1100, Jonathan Gray wrote: > described as "32 Execution Unit (EU) Super SKU" in: > Intel Atom x6000E Series, and Intel Pentium and Celeron N and > J Series Processors for IoT Applications > Datasheet, Volume 1 > Document Number: 636112-1.6 > Reviewed-by: José Roberto de Souza > Signed-off-by: Jonathan Gray > --- > include/drm/i915_pciids.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h > index 4a4c190f7698..92205054e542 100644 > --- a/include/drm/i915_pciids.h > +++ b/include/drm/i915_pciids.h > @@ -588,6 +588,7 @@ > INTEL_VGA_DEVICE(0x4551, info), \ > INTEL_VGA_DEVICE(0x4555, info), \ > INTEL_VGA_DEVICE(0x4557, info), \ > + INTEL_VGA_DEVICE(0x4570, info), \ > INTEL_VGA_DEVICE(0x4571, info) > > /* JSL */
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/9] drm/i915/display/core: use intel_de_rmw if possible (rev4)
== Series Details ==
Series: series starting with [v2,1/9] drm/i915/display/core: use intel_de_rmw
if possible (rev4)
URL : https://patchwork.freedesktop.org/series/112438/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12701 -> Patchwork_112438v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/index.html
Participating hosts (28 -> 27)
--
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_112438v4 that come from known issues:
### IGT changes ###
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7852]: https://gitlab.freedesktop.org/drm/intel/issues/7852
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12701 -> Patchwork_112438v4
CI-20190529: 20190529
CI_DRM_12701: 59f7ee248c81c7f9840eeabe3e8fac5e6f5a1a9f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7149: 1c7ea154b625e1fb826f1519b816b4256dd10b62 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_112438v4: 59f7ee248c81c7f9840eeabe3e8fac5e6f5a1a9f @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
ba76a25b3a17 drm/i915/display/misc: use intel_de_rmw if possible
0a886b169a45 drm/i915/display/interfaces: use intel_de_rmw if possible
f201f43e23f3 drm/i915/display/panel: use intel_de_rmw if possible in panel
related code
892c16c98118 drm/i915/display/hdmi: use intel_de_rmw if possible
36034e23e9b0 drm/i915/display/pch: use intel_de_rmw if possible
4318f3656785 drm/i915/display/phys: use intel_de_rmw if possible
439c49a6b297 drm/i915/display/dpll: use intel_de_rmw if possible
7ae9a61bd708 drm/i915/display/power: use intel_de_rmw if possible
453d69b389b8 drm/i915/display/core: use intel_de_rmw if possible
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v4/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: add guard page to ggtt->error_capture (rev4)
== Series Details ==
Series: drm/i915: add guard page to ggtt->error_capture (rev4)
URL : https://patchwork.freedesktop.org/series/113560/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12699_full -> Patchwork_113560v4_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/index.html
Participating hosts (11 -> 10)
--
Missing(1): shard-rkl0
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113560v4_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_schedule@wide@rcs0:
- {shard-tglu}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/shard-tglu-2/igt@gem_exec_schedule@w...@rcs0.html
Known issues
Here are the changes found in Patchwork_113560v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][2] -> [FAIL][3] ([i915#2846])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/shard-glk8/igt@gem_exec_f...@basic-deadline.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/shard-glk7/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][4] -> [FAIL][5] ([i915#2842]) +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][6] -> [ABORT][7] ([i915#5566])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/shard-glk3/igt@gen9_exec_pa...@allowed-single.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][8] ([i915#7742]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/shard-rkl-3/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/shard-rkl-3/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@fbdev@read:
- {shard-tglu}: [SKIP][10] ([i915#2582]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/shard-tglu-6/igt@fb...@read.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/shard-tglu-4/igt@fb...@read.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][12] ([i915#6252]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/shard-rkl-2/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_eio@reset-stress:
- {shard-dg1}:[FAIL][14] ([i915#5784]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/shard-dg1-13/igt@gem_...@reset-stress.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/shard-dg1-14/igt@gem_...@reset-stress.html
* igt@gem_eio@suspend:
- {shard-rkl}:[FAIL][16] ([i915#5115] / [i915#7052]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/shard-rkl-3/igt@gem_...@suspend.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/shard-rkl-1/igt@gem_...@suspend.html
* igt@gem_exec_balancer@fairslice:
- {shard-rkl}:[SKIP][18] ([i915#6259]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/shard-rkl-5/igt@gem_exec_balan...@fairslice.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/shard-rkl-4/igt@gem_exec_balan...@fairslice.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- {shard-rkl}:[FAIL][20] ([i915#2842]) -> [PASS][21] +1 similar
issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/shard-rkl-1/igt@gem_exec_fair@basic-none-r...@rcs0.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/shard-rkl-5/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_reloc@basic-cpu-gtt-noreloc:
- {shard-rkl}:[SKIP][22] ([i915#3281]) -> [PASS][23] +4 similar
issues
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/shard-rkl-1/igt@gem_exec_re...@basic-cpu-gtt-noreloc.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/shard-rkl-5/igt@gem_exec_re...@basic-cpu-gtt-nore
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add vfio_device cdev for iommufd support
== Series Details == Series: Add vfio_device cdev for iommufd support URL : https://patchwork.freedesktop.org/series/113696/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/113696/revisions/1/mbox/ not applied Applying: vfio: Allocate per device file structure Using index info to reconstruct a base tree... M drivers/vfio/group.c M drivers/vfio/vfio.h M drivers/vfio/vfio_main.c Falling back to patching base and 3-way merge... Auto-merging drivers/vfio/vfio_main.c Auto-merging drivers/vfio/vfio.h Auto-merging drivers/vfio/group.c Applying: vfio: Refine vfio file kAPIs error: sha1 information is lacking or useless (include/linux/vfio.h). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0002 vfio: Refine vfio file kAPIs When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] [CI 4/4] drm/i915/dp_mst: Fix payload removal during output disabling
Use the correct old/new topology and payload states in intel_mst_disable_dp(). So far drm_atomic_get_mst_topology_state() it used returned either the old state, in case the state was added already earlier during the atomic check phase or otherwise the new state (but the latter could fail, which can't be handled in the enable/disable hooks). After the first patch in the patchset, the state should always get added already during the check phase, so here we can get the old/new states without a failure. drm_dp_remove_payload() should use time_slots from the old payload state and vc_start_slot in the new one. It should update the new payload states to reflect the sink's current payload table after the payload is removed. Pass the new topology state and the old and new payload states accordingly. This also fixes a problem where the payload allocations for multiple MST streams on the same link got inconsistent after a few commits, as during payload removal the old instead of the new payload state got updated, so the subsequent enabling sequence and commits used a stale payload state. v2: Constify the old payload state pointer. (Ville) Cc: Lyude Paul Cc: Ville Syrjälä Cc: sta...@vger.kernel.org # 6.1 Reviewed-by: Ville Syrjälä Reviewed-by: Lyude Paul Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c index dc4e5ff1dbb31..054a009e800d7 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c @@ -524,10 +524,14 @@ static void intel_mst_disable_dp(struct intel_atomic_state *state, struct intel_dp *intel_dp = &dig_port->dp; struct intel_connector *connector = to_intel_connector(old_conn_state->connector); - struct drm_dp_mst_topology_state *mst_state = - drm_atomic_get_mst_topology_state(&state->base, &intel_dp->mst_mgr); - struct drm_dp_mst_atomic_payload *payload = - drm_atomic_get_mst_payload_state(mst_state, connector->port); + struct drm_dp_mst_topology_state *old_mst_state = + drm_atomic_get_old_mst_topology_state(&state->base, &intel_dp->mst_mgr); + struct drm_dp_mst_topology_state *new_mst_state = + drm_atomic_get_new_mst_topology_state(&state->base, &intel_dp->mst_mgr); + const struct drm_dp_mst_atomic_payload *old_payload = + drm_atomic_get_mst_payload_state(old_mst_state, connector->port); + struct drm_dp_mst_atomic_payload *new_payload = + drm_atomic_get_mst_payload_state(new_mst_state, connector->port); struct drm_i915_private *i915 = to_i915(connector->base.dev); drm_dbg_kms(&i915->drm, "active links %d\n", @@ -535,8 +539,8 @@ static void intel_mst_disable_dp(struct intel_atomic_state *state, intel_hdcp_disable(intel_mst->connector); - drm_dp_remove_payload(&intel_dp->mst_mgr, mst_state, - payload, payload); + drm_dp_remove_payload(&intel_dp->mst_mgr, new_mst_state, + old_payload, new_payload); intel_audio_codec_disable(encoder, old_crtc_state, old_conn_state); } -- 2.37.1
[Intel-gfx] [CI 3/4] drm/display/dp_mst: Add drm_atomic_get_old_mst_topology_state()
Add a function to get the old MST topology state, required by a
follow-up i915 patch.
While at it clarify the code comment of
drm_atomic_get_new_mst_topology_state() and add _new prefix
to the new state pointer to remind about its difference from the old
state.
v2: Use old_/new_ prefixes for the state pointers. (Ville)
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: sta...@vger.kernel.org # 6.1
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
Reviewed-by: Lyude Paul
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 33 ---
include/drm/display/drm_dp_mst_helper.h | 3 ++
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 1990ff5dc7ddd..38dab76ae69ea 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -5364,28 +5364,53 @@ struct drm_dp_mst_topology_state
*drm_atomic_get_mst_topology_state(struct drm_a
}
EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
+/**
+ * drm_atomic_get_old_mst_topology_state: get old MST topology state in atomic
state, if any
+ * @state: global atomic state
+ * @mgr: MST topology manager, also the private object in this case
+ *
+ * This function wraps drm_atomic_get_old_private_obj_state() passing in the
MST atomic
+ * state vtable so that the private object state returned is that of a MST
+ * topology object.
+ *
+ * Returns:
+ *
+ * The old MST topology state, or NULL if there's no topology state for this
MST mgr
+ * in the global atomic state
+ */
+struct drm_dp_mst_topology_state *
+drm_atomic_get_old_mst_topology_state(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr)
+{
+ struct drm_private_state *old_priv_state =
+ drm_atomic_get_old_private_obj_state(state, &mgr->base);
+
+ return old_priv_state ? to_dp_mst_topology_state(old_priv_state) : NULL;
+}
+EXPORT_SYMBOL(drm_atomic_get_old_mst_topology_state);
+
/**
* drm_atomic_get_new_mst_topology_state: get new MST topology state in atomic
state, if any
* @state: global atomic state
* @mgr: MST topology manager, also the private object in this case
*
- * This function wraps drm_atomic_get_priv_obj_state() passing in the MST
atomic
+ * This function wraps drm_atomic_get_new_private_obj_state() passing in the
MST atomic
* state vtable so that the private object state returned is that of a MST
* topology object.
*
* Returns:
*
- * The MST topology state, or NULL if there's no topology state for this MST
mgr
+ * The new MST topology state, or NULL if there's no topology state for this
MST mgr
* in the global atomic state
*/
struct drm_dp_mst_topology_state *
drm_atomic_get_new_mst_topology_state(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr)
{
- struct drm_private_state *priv_state =
+ struct drm_private_state *new_priv_state =
drm_atomic_get_new_private_obj_state(state, &mgr->base);
- return priv_state ? to_dp_mst_topology_state(priv_state) : NULL;
+ return new_priv_state ? to_dp_mst_topology_state(new_priv_state) : NULL;
}
EXPORT_SYMBOL(drm_atomic_get_new_mst_topology_state);
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index f5eb9aa152b14..32c764fb9cb56 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -868,6 +868,9 @@ struct drm_dp_mst_topology_state *
drm_atomic_get_mst_topology_state(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr);
struct drm_dp_mst_topology_state *
+drm_atomic_get_old_mst_topology_state(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr);
+struct drm_dp_mst_topology_state *
drm_atomic_get_new_mst_topology_state(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr);
struct drm_dp_mst_atomic_payload *
--
2.37.1
[Intel-gfx] [CI 2/4] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
Atm, drm_dp_remove_payload() uses the same payload state to both get the
vc_start_slot required for the payload removal DPCD message and to
deduct time_slots from vc_start_slot of all payloads after the one being
removed.
The above isn't always correct, as vc_start_slot must be the up-to-date
version contained in the new payload state, but time_slots must be the
one used when the payload was previously added, contained in the old
payload state. The new payload's time_slots can change vs. the old one
if the current atomic commit changes the corresponding mode.
This patch let's drivers pass the old and new payload states to
drm_dp_remove_payload(), but keeps these the same for now in all drivers
not to change the behavior. A follow-up i915 patch will pass in that
driver the correct old and new states to the function.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Harry Wentland
Cc: Alex Deucher
Cc: Wayne Lin
Cc: sta...@vger.kernel.org # 6.1
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
Reviewed-by: Lyude Paul
Signed-off-by: Imre Deak
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 ++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
include/drm/display/drm_dp_mst_helper.h | 3 ++-
5 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index a50319fc42b11..180d3893b68da 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -208,7 +208,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
if (enable)
drm_dp_add_payload_part1(mst_mgr, mst_state, payload);
else
- drm_dp_remove_payload(mst_mgr, mst_state, payload);
+ drm_dp_remove_payload(mst_mgr, mst_state, payload, payload);
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
* AUX message. The sequence is slot 1-63 allocated sequence for each
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 847c10aa2098c..1990ff5dc7ddd 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3342,7 +3342,8 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
* drm_dp_remove_payload() - Remove an MST payload
* @mgr: Manager to use.
* @mst_state: The MST atomic state
- * @payload: The payload to write
+ * @old_payload: The payload with its old state
+ * @new_payload: The payload to write
*
* Removes a payload from an MST topology if it was successfully assigned a
start slot. Also updates
* the starting time slots of all other payloads which would have been shifted
towards the start of
@@ -3350,36 +3351,37 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
*/
void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state *mst_state,
- struct drm_dp_mst_atomic_payload *payload)
+ const struct drm_dp_mst_atomic_payload *old_payload,
+ struct drm_dp_mst_atomic_payload *new_payload)
{
struct drm_dp_mst_atomic_payload *pos;
bool send_remove = false;
/* We failed to make the payload, so nothing to do */
- if (payload->vc_start_slot == -1)
+ if (new_payload->vc_start_slot == -1)
return;
mutex_lock(&mgr->lock);
- send_remove = drm_dp_mst_port_downstream_of_branch(payload->port,
mgr->mst_primary);
+ send_remove = drm_dp_mst_port_downstream_of_branch(new_payload->port,
mgr->mst_primary);
mutex_unlock(&mgr->lock);
if (send_remove)
- drm_dp_destroy_payload_step1(mgr, mst_state, payload);
+ drm_dp_destroy_payload_step1(mgr, mst_state, new_payload);
else
drm_dbg_kms(mgr->dev, "Payload for VCPI %d not in topology, not
sending remove\n",
- payload->vcpi);
+ new_payload->vcpi);
list_for_each_entry(pos, &mst_state->payloads, next) {
- if (pos != payload && pos->vc_start_slot >
payload->vc_start_slot)
- pos->vc_start_slot -= payload->time_slots;
+ if (pos != new_payload && pos->vc_start_slot >
new_payload->vc_start_slot)
+ pos->vc_start_slot -= old_payload->time_slots;
}
- payload->vc_start_slot = -1;
+ new_payload->vc_start_slot = -1;
mgr->payload_count--;
- mgr->next_start_slot -= payload->time_slots;
+ mgr->next_start_slot -= old_payload->time_slots;
- if (payload->delete)
- drm_dp_mst_put_
[Intel-gfx] [CI 1/4] drm/i915/dp_mst: Add the MST topology state for modesetted CRTCs
Add the MST topology for a CRTC to the atomic state if the driver
needs to force a modeset on the CRTC after the encoder compute config
functions are called.
Later the MST encoder's disable hook also adds the state, but that isn't
guaranteed to work (since in that hook getting the state may fail, which
can't be handled there). This should fix that, while a later patch fixes
the use of the MST state in the disable hook.
v2: Add missing forward struct declartions, caught by hdrtest.
v3: Factor out intel_dp_mst_add_topology_state_for_connector() used
later in the patchset.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: sta...@vger.kernel.org # 6.1
Reviewed-by: Ville Syrjälä # v2
Reviewed-by: Lyude Paul
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 61
drivers/gpu/drm/i915/display/intel_dp_mst.h | 4 ++
3 files changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 12ade593c..38106cf63b3b9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5936,6 +5936,10 @@ int intel_modeset_all_pipes(struct intel_atomic_state
*state,
if (ret)
return ret;
+ ret = intel_dp_mst_add_topology_state_for_crtc(state, crtc);
+ if (ret)
+ return ret;
+
ret = intel_atomic_add_affected_planes(state, crtc);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 8b0e4defa3f10..f3cb12dcfe0a7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -1223,3 +1223,64 @@ bool intel_dp_mst_is_slave_trans(const struct
intel_crtc_state *crtc_state)
return crtc_state->mst_master_transcoder != INVALID_TRANSCODER &&
crtc_state->mst_master_transcoder != crtc_state->cpu_transcoder;
}
+
+/**
+ * intel_dp_mst_add_topology_state_for_connector - add MST topology state for
a connector
+ * @state: atomic state
+ * @connector: connector to add the state for
+ * @crtc: the CRTC @connector is attached to
+ *
+ * Add the MST topology state for @connector to @state.
+ *
+ * Returns 0 on success, negative error code on failure.
+ */
+static int
+intel_dp_mst_add_topology_state_for_connector(struct intel_atomic_state *state,
+ struct intel_connector *connector,
+ struct intel_crtc *crtc)
+{
+ struct drm_dp_mst_topology_state *mst_state;
+
+ if (!connector->mst_port)
+ return 0;
+
+ mst_state = drm_atomic_get_mst_topology_state(&state->base,
+
&connector->mst_port->mst_mgr);
+ if (IS_ERR(mst_state))
+ return PTR_ERR(mst_state);
+
+ mst_state->pending_crtc_mask |= drm_crtc_mask(&crtc->base);
+
+ return 0;
+}
+
+/**
+ * intel_dp_mst_add_topology_state_for_crtc - add MST topology state for a CRTC
+ * @state: atomic state
+ * @crtc: CRTC to add the state for
+ *
+ * Add the MST topology state for @crtc to @state.
+ *
+ * Returns 0 on success, negative error code on failure.
+ */
+int intel_dp_mst_add_topology_state_for_crtc(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
+{
+ struct drm_connector *_connector;
+ struct drm_connector_state *conn_state;
+ int i;
+
+ for_each_new_connector_in_state(&state->base, _connector, conn_state,
i) {
+ struct intel_connector *connector =
to_intel_connector(_connector);
+ int ret;
+
+ if (conn_state->crtc != &crtc->base)
+ continue;
+
+ ret = intel_dp_mst_add_topology_state_for_connector(state,
connector, crtc);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.h
b/drivers/gpu/drm/i915/display/intel_dp_mst.h
index f7301de6cdfb3..f1815bb722672 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.h
@@ -8,6 +8,8 @@
#include
+struct intel_atomic_state;
+struct intel_crtc;
struct intel_crtc_state;
struct intel_digital_port;
struct intel_dp;
@@ -18,5 +20,7 @@ int intel_dp_mst_encoder_active_links(struct
intel_digital_port *dig_port);
bool intel_dp_mst_is_master_trans(const struct intel_crtc_state *crtc_state);
bool intel_dp_mst_is_slave_trans(const struct intel_crtc_state *crtc_state);
bool intel_dp_mst_source_support(struct intel_dp *intel_dp);
+int intel_dp_mst_add_topology_state_for_crtc(struct intel_atomic_state *state,
+
Re: [Intel-gfx] [PATCH] drm/i915/display/fdi: use intel_de_rmw if possible
On Mon, 06 Feb 2023, Andrzej Hajda wrote:
> Hi Rodrigo,
>
> On 30.01.2023 14:06, Jani Nikula wrote:
>> On Mon, 30 Jan 2023, Andrzej Hajda wrote:
>>> Hi all,
>>>
>>> Gently ping on merging this and all other intel_de_rmw patches.
>>> All patches reviewed.
>>> drm/i915/display/fdi: use intel_de_rmw if possible
>>> drm/i915/display/vlv: fix pixel overlap register update
>>> drm/i915/display/vlv: use intel_de_rmw if possible
>>> drm/i915/display/dsi: use intel_de_rmw if possible
>> Pushed the above, sorry for the delay.
>>
>> The below are R-b by Rodrigo in [1], I'll let him deal with them.
>
> Could you push below patches, risk of merge conflicts raises :)
Full IGT wasn't run on the last version, I hit retest. Let's see.
BR,
Jani
> Hopefully I will have commit rights soon, but today is not the case, yet.
>
> Regards
> Andrzej
>
>>
>> Andrzej, looks like you now meet the criteria for commit access
>> [2]. Please check the documentation and apply for drm-intel commit
>> access, so you can start pushing your own patches.
>>
>>
>> Thanks,
>> Jani.
>>
>> [1] https://patchwork.freedesktop.org/series/112438/
>> [2]
>> https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-intel
>>
>>> drm/i915/display/core: use intel_de_rmw if possible
>>> drm/i915/display/power: use intel_de_rmw if possible
>>> drm/i915/display/dpll: use intel_de_rmw if possible
>>> drm/i915/display/phys: use intel_de_rmw if possible
>>> drm/i915/display/pch: use intel_de_rmw if possible
>>> drm/i915/display/hdmi: use intel_de_rmw if possible
>>> drm/i915/display/panel: use intel_de_rmw if possible in panel related code
>>> drm/i915/display/interfaces: use intel_de_rmw if possible
>>> drm/i915/display/misc: use intel_de_rmw if possible
>>>
>>> Regards
>>> Andrzej
>>>
>>> On 15.12.2022 13:56, Andrzej Hajda wrote:
The helper makes the code more compact and readable.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/display/intel_fdi.c | 148 +++
1 file changed, 44 insertions(+), 104 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c
b/drivers/gpu/drm/i915/display/intel_fdi.c
index 063f1da4f229cf..f62d9a9313498c 100644
--- a/drivers/gpu/drm/i915/display/intel_fdi.c
+++ b/drivers/gpu/drm/i915/display/intel_fdi.c
@@ -439,19 +439,11 @@ static void ilk_fdi_link_train(struct intel_crtc
*crtc,
drm_err(&dev_priv->drm, "FDI train 1 fail!\n");
/* Train 2 */
- reg = FDI_TX_CTL(pipe);
- temp = intel_de_read(dev_priv, reg);
- temp &= ~FDI_LINK_TRAIN_NONE;
- temp |= FDI_LINK_TRAIN_PATTERN_2;
- intel_de_write(dev_priv, reg, temp);
-
- reg = FDI_RX_CTL(pipe);
- temp = intel_de_read(dev_priv, reg);
- temp &= ~FDI_LINK_TRAIN_NONE;
- temp |= FDI_LINK_TRAIN_PATTERN_2;
- intel_de_write(dev_priv, reg, temp);
-
- intel_de_posting_read(dev_priv, reg);
+ intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
+ FDI_LINK_TRAIN_NONE, FDI_LINK_TRAIN_PATTERN_2);
+ intel_de_rmw(dev_priv, FDI_RX_CTL(pipe),
+ FDI_LINK_TRAIN_NONE, FDI_LINK_TRAIN_PATTERN_2);
+ intel_de_posting_read(dev_priv, FDI_RX_CTL(pipe));
udelay(150);
reg = FDI_RX_IIR(pipe);
@@ -538,13 +530,9 @@ static void gen6_fdi_link_train(struct intel_crtc
*crtc,
udelay(150);
for (i = 0; i < 4; i++) {
- reg = FDI_TX_CTL(pipe);
- temp = intel_de_read(dev_priv, reg);
- temp &= ~FDI_LINK_TRAIN_VOL_EMP_MASK;
- temp |= snb_b_fdi_train_param[i];
- intel_de_write(dev_priv, reg, temp);
-
- intel_de_posting_read(dev_priv, reg);
+ intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
+ FDI_LINK_TRAIN_VOL_EMP_MASK,
snb_b_fdi_train_param[i]);
+ intel_de_posting_read(dev_priv, FDI_TX_CTL(pipe));
udelay(500);
for (retry = 0; retry < 5; retry++) {
@@ -593,13 +581,9 @@ static void gen6_fdi_link_train(struct intel_crtc
*crtc,
udelay(150);
for (i = 0; i < 4; i++) {
- reg = FDI_TX_CTL(pipe);
- temp = intel_de_read(dev_priv, reg);
- temp &= ~FDI_LINK_TRAIN_VOL_EMP_MASK;
- temp |= snb_b_fdi_train_param[i];
- intel_de_write(dev_priv, reg, temp);
-
- intel_de_posting_read(dev_priv, reg);
+ intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
+ FDI_LINK_TRAIN_VOL_EMP_MASK,
snb_b_fdi_train_param[i]);
+ intel_de_posting_read(dev_priv, FDI_TX_CTL(pipe));
udelay(500);
for (retry = 0; retry < 5; retry++) {
@@ -719,19 +
Re: [Intel-gfx] [PATCH v2] drm/i915: Initialize the obj flags for shmem objects
On 06-02-2023 15:21, Tvrtko Ursulin wrote:
>
>
> On 03/02/2023 13:52, Aravind Iddamsetty wrote:
>> Obj flags for shmem objects is not being set correctly. Fixes in setting
>> BO_ALLOC_USER flag which applies to shmem objs as well.
>>
>> Fixes: 13d29c823738 ("drm/i915/ehl: unconditionally flush the pages on
>> acquire")
>> Cc: # v5.15+
>
> These tags should have been grouped with the ones below in one block.
>
> I have tidied this while pushing, thanks for the fix and review!
Thanks Tvrtko.
Regards,
Aravind.
>
> Regards,
>
> Tvrtko
>
>> v2: Add fixes tag (Tvrtko, Matt A)
>>
>> Cc: Matthew Auld
>> Cc: Tvrtko Ursulin
>> Reviewed-by: Matthew Auld
>> Signed-off-by: Aravind Iddamsetty
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> index 114443096841..37d1efcd3ca6 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> @@ -596,7 +596,7 @@ static int shmem_object_init(struct
>> intel_memory_region *mem,
>> mapping_set_gfp_mask(mapping, mask);
>> GEM_BUG_ON(!(mapping_gfp_mask(mapping) & __GFP_RECLAIM));
>> - i915_gem_object_init(obj, &i915_gem_shmem_ops, &lock_class, 0);
>> + i915_gem_object_init(obj, &i915_gem_shmem_ops, &lock_class, flags);
>> obj->mem_flags |= I915_BO_FLAG_STRUCT_PAGE;
>> obj->write_domain = I915_GEM_DOMAIN_CPU;
>> obj->read_domains = I915_GEM_DOMAIN_CPU;
Re: [Intel-gfx] [PATCH] drm/i915/gt: Avoid redundant pointer validity check
On 06/02/2023 09:45, Tvrtko Ursulin wrote:
Hi,
Adding Matt & Thomas as potential candidates to review.
Regards,
Tvrtko
On 03/02/2023 19:30, Deepak R Varma wrote:
The macro definition of gen6_for_all_pdes() expands to a for loop such
that it breaks when the page table is null. Hence there is no need to
again test validity of the page table entry pointers in the pde list.
This change is identified using itnull.cocci semantic patch.
Signed-off-by: Deepak R Varma
---
Please note: Proposed change is compile tested only.
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index 5aaacc53fa4c..787b9e6d9f59 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -258,8 +258,7 @@ static void gen6_ppgtt_free_pd(struct gen6_ppgtt
*ppgtt)
u32 pde;
gen6_for_all_pdes(pt, pd, pde)
- if (pt)
- free_pt(&ppgtt->base.vm, pt);
+ free_pt(&ppgtt->base.vm, pt);
}
static void gen6_ppgtt_cleanup(struct i915_address_space *vm)
@@ -304,7 +303,7 @@ static void pd_vma_unbind(struct
i915_address_space *vm,
/* Free all no longer used page tables */
gen6_for_all_pdes(pt, ppgtt->base.pd, pde) {
- if (!pt || atomic_read(&pt->used))
+ if (atomic_read(&pt->used))
Wow, I was really confused trying to remember how this all works.
The gen6_for_all_pdes() does:
(pt = i915_pt_entry(pd, iter), true)
So NULL pt is expected, and does not 'break' here, since 'true' is
always the value that decides whether to terminate the loop. So this
patch would lead to NULL ptr deref, AFAICT.
continue;
free_pt(&ppgtt->base.vm, pt);
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add guard page to ggtt->error_capture (rev4)
== Series Details ==
Series: drm/i915: add guard page to ggtt->error_capture (rev4)
URL : https://patchwork.freedesktop.org/series/113560/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12699 -> Patchwork_113560v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/index.html
Participating hosts (28 -> 27)
--
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113560v4:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@reset:
- {bat-rpls-2}: [ABORT][1] ([i915#4983]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/bat-rpls-2/igt@i915_selftest@l...@reset.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/bat-rpls-2/igt@i915_selftest@l...@reset.html
Known issues
Here are the changes found in Patchwork_113560v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][3] ([i915#7156])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
Possible fixes
* igt@i915_pm_rpm@basic-rte:
- {bat-adlp-6}: [ABORT][4] ([i915#7977]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/bat-adlp-6/igt@i915_pm_...@basic-rte.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/bat-adlp-6/igt@i915_pm_...@basic-rte.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [DMESG-FAIL][6] ([i915#5334]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- fi-kbl-soraka: [INCOMPLETE][8] ([i915#7913]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/fi-kbl-soraka/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/fi-kbl-soraka/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@mman:
- {bat-rpls-1}: [TIMEOUT][10] ([i915#6794]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/bat-rpls-1/igt@i915_selftest@l...@mman.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/bat-rpls-1/igt@i915_selftest@l...@mman.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-apl-guc: [DMESG-WARN][12] ([i915#1982]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12699/fi-apl-guc/igt@i915_susp...@basic-s2idle-without-i915.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v4/fi-apl-guc/igt@i915_susp...@basic-s2idle-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
[i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
[i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
Build changes
-
* Linux: CI_DRM_12699 -> Patchwork_113560v4
CI-20190529: 20190529
CI_DRM_12699: 412c3ca0460a03d10ef8cd18a09417050edc85d9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7149: 1c7ea154b625e1fb826f1519b816b4256dd10b62 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113560v4: 412c3ca0460a03d10ef8cd18a09417050edc85d9 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
dcf943248993 drm/i915: add guard page to ggtt->error_capture
Re: [Intel-gfx] [PATCH v2] drm/i915: Initialize the obj flags for shmem objects
On 03/02/2023 13:52, Aravind Iddamsetty wrote:
Obj flags for shmem objects is not being set correctly. Fixes in setting
BO_ALLOC_USER flag which applies to shmem objs as well.
Fixes: 13d29c823738 ("drm/i915/ehl: unconditionally flush the pages on acquire")
Cc: # v5.15+
These tags should have been grouped with the ones below in one block.
I have tidied this while pushing, thanks for the fix and review!
Regards,
Tvrtko
v2: Add fixes tag (Tvrtko, Matt A)
Cc: Matthew Auld
Cc: Tvrtko Ursulin
Reviewed-by: Matthew Auld
Signed-off-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 114443096841..37d1efcd3ca6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -596,7 +596,7 @@ static int shmem_object_init(struct intel_memory_region
*mem,
mapping_set_gfp_mask(mapping, mask);
GEM_BUG_ON(!(mapping_gfp_mask(mapping) & __GFP_RECLAIM));
- i915_gem_object_init(obj, &i915_gem_shmem_ops, &lock_class, 0);
+ i915_gem_object_init(obj, &i915_gem_shmem_ops, &lock_class, flags);
obj->mem_flags |= I915_BO_FLAG_STRUCT_PAGE;
obj->write_domain = I915_GEM_DOMAIN_CPU;
obj->read_domains = I915_GEM_DOMAIN_CPU;
Re: [Intel-gfx] [PATCH] drm/i915/gt: Avoid redundant pointer validity check
Hi,
Adding Matt & Thomas as potential candidates to review.
Regards,
Tvrtko
On 03/02/2023 19:30, Deepak R Varma wrote:
The macro definition of gen6_for_all_pdes() expands to a for loop such
that it breaks when the page table is null. Hence there is no need to
again test validity of the page table entry pointers in the pde list.
This change is identified using itnull.cocci semantic patch.
Signed-off-by: Deepak R Varma
---
Please note: Proposed change is compile tested only.
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index 5aaacc53fa4c..787b9e6d9f59 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -258,8 +258,7 @@ static void gen6_ppgtt_free_pd(struct gen6_ppgtt *ppgtt)
u32 pde;
gen6_for_all_pdes(pt, pd, pde)
- if (pt)
- free_pt(&ppgtt->base.vm, pt);
+ free_pt(&ppgtt->base.vm, pt);
}
static void gen6_ppgtt_cleanup(struct i915_address_space *vm)
@@ -304,7 +303,7 @@ static void pd_vma_unbind(struct i915_address_space *vm,
/* Free all no longer used page tables */
gen6_for_all_pdes(pt, ppgtt->base.pd, pde) {
- if (!pt || atomic_read(&pt->used))
+ if (atomic_read(&pt->used))
continue;
free_pt(&ppgtt->base.vm, pt);
Re: [Intel-gfx] [PATCH] drm/i915: Move fd_install after last use of fence
On 03/02/2023 18:15, Rob Clark wrote:
On Fri, Feb 3, 2023 at 8:49 AM Rob Clark wrote:
From: Rob Clark
Because eb_composite_fence_create() drops the fence_array reference
after creation of the sync_file, only the sync_file holds a ref to the
fence. But fd_install() makes that reference visable to userspace, so
it must be the last thing we do with the fence.
Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)")
This is correct and the fix looks good to me.
Reviewed-by: Tvrtko Ursulin
CI is green so I will merge it, thanks again for a fix Rob!
Followup up question for Matthew Brost however is whether the composite
fence flow could be simplified. This block here comes late in
i915_gem_do_execbuffer and may mislead the user the composite fence is
held to the end of the function:
if (!out_fence && eb.composite_fence)
dma_fence_put(eb.composite_fence);
Question is would it work to remove the !out_fence condition from here,
and remove "consumption" of the reference from eb_composite_fence_create
success path.
Regards,
Tvrtko
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index f266b68cf012..0f2e056c02dd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -3476,38 +3476,38 @@ i915_gem_do_execbuffer(struct drm_device *dev,
err_request:
eb_requests_get(&eb);
err = eb_requests_add(&eb, err);
if (eb.fences)
signal_fence_array(&eb, eb.composite_fence ?
eb.composite_fence :
&eb.requests[0]->fence);
+ if (unlikely(eb.gem_context->syncobj)) {
+ drm_syncobj_replace_fence(eb.gem_context->syncobj,
+ eb.composite_fence ?
+ eb.composite_fence :
+ &eb.requests[0]->fence);
+ }
+
if (out_fence) {
if (err == 0) {
fd_install(out_fence_fd, out_fence->file);
args->rsvd2 &= GENMASK_ULL(31, 0); /* keep in-fence */
args->rsvd2 |= (u64)out_fence_fd << 32;
out_fence_fd = -1;
} else {
fput(out_fence->file);
}
}
- if (unlikely(eb.gem_context->syncobj)) {
- drm_syncobj_replace_fence(eb.gem_context->syncobj,
- eb.composite_fence ?
- eb.composite_fence :
- &eb.requests[0]->fence);
- }
-
if (!out_fence && eb.composite_fence)
dma_fence_put(eb.composite_fence);
eb_requests_put(&eb);
err_vma:
eb_release_vmas(&eb, true);
WARN_ON(err == -EDEADLK);
i915_gem_ww_ctx_fini(&eb.ww);
--
2.38.1
Re: [Intel-gfx] [PATCH] drm/i915/display/fdi: use intel_de_rmw if possible
Hi Rodrigo,
On 30.01.2023 14:06, Jani Nikula wrote:
On Mon, 30 Jan 2023, Andrzej Hajda wrote:
Hi all,
Gently ping on merging this and all other intel_de_rmw patches.
All patches reviewed.
drm/i915/display/fdi: use intel_de_rmw if possible
drm/i915/display/vlv: fix pixel overlap register update
drm/i915/display/vlv: use intel_de_rmw if possible
drm/i915/display/dsi: use intel_de_rmw if possible
Pushed the above, sorry for the delay.
The below are R-b by Rodrigo in [1], I'll let him deal with them.
Could you push below patches, risk of merge conflicts raises :)
Hopefully I will have commit rights soon, but today is not the case, yet.
Regards
Andrzej
Andrzej, looks like you now meet the criteria for commit access
[2]. Please check the documentation and apply for drm-intel commit
access, so you can start pushing your own patches.
Thanks,
Jani.
[1] https://patchwork.freedesktop.org/series/112438/
[2]
https://drm.pages.freedesktop.org/maintainer-tools/commit-access.html#drm-intel
drm/i915/display/core: use intel_de_rmw if possible
drm/i915/display/power: use intel_de_rmw if possible
drm/i915/display/dpll: use intel_de_rmw if possible
drm/i915/display/phys: use intel_de_rmw if possible
drm/i915/display/pch: use intel_de_rmw if possible
drm/i915/display/hdmi: use intel_de_rmw if possible
drm/i915/display/panel: use intel_de_rmw if possible in panel related code
drm/i915/display/interfaces: use intel_de_rmw if possible
drm/i915/display/misc: use intel_de_rmw if possible
Regards
Andrzej
On 15.12.2022 13:56, Andrzej Hajda wrote:
The helper makes the code more compact and readable.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/display/intel_fdi.c | 148 +++
1 file changed, 44 insertions(+), 104 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c
b/drivers/gpu/drm/i915/display/intel_fdi.c
index 063f1da4f229cf..f62d9a9313498c 100644
--- a/drivers/gpu/drm/i915/display/intel_fdi.c
+++ b/drivers/gpu/drm/i915/display/intel_fdi.c
@@ -439,19 +439,11 @@ static void ilk_fdi_link_train(struct intel_crtc *crtc,
drm_err(&dev_priv->drm, "FDI train 1 fail!\n");
/* Train 2 */
- reg = FDI_TX_CTL(pipe);
- temp = intel_de_read(dev_priv, reg);
- temp &= ~FDI_LINK_TRAIN_NONE;
- temp |= FDI_LINK_TRAIN_PATTERN_2;
- intel_de_write(dev_priv, reg, temp);
-
- reg = FDI_RX_CTL(pipe);
- temp = intel_de_read(dev_priv, reg);
- temp &= ~FDI_LINK_TRAIN_NONE;
- temp |= FDI_LINK_TRAIN_PATTERN_2;
- intel_de_write(dev_priv, reg, temp);
-
- intel_de_posting_read(dev_priv, reg);
+ intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
+FDI_LINK_TRAIN_NONE, FDI_LINK_TRAIN_PATTERN_2);
+ intel_de_rmw(dev_priv, FDI_RX_CTL(pipe),
+FDI_LINK_TRAIN_NONE, FDI_LINK_TRAIN_PATTERN_2);
+ intel_de_posting_read(dev_priv, FDI_RX_CTL(pipe));
udelay(150);
reg = FDI_RX_IIR(pipe);
@@ -538,13 +530,9 @@ static void gen6_fdi_link_train(struct intel_crtc *crtc,
udelay(150);
for (i = 0; i < 4; i++) {
- reg = FDI_TX_CTL(pipe);
- temp = intel_de_read(dev_priv, reg);
- temp &= ~FDI_LINK_TRAIN_VOL_EMP_MASK;
- temp |= snb_b_fdi_train_param[i];
- intel_de_write(dev_priv, reg, temp);
-
- intel_de_posting_read(dev_priv, reg);
+ intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
+FDI_LINK_TRAIN_VOL_EMP_MASK,
snb_b_fdi_train_param[i]);
+ intel_de_posting_read(dev_priv, FDI_TX_CTL(pipe));
udelay(500);
for (retry = 0; retry < 5; retry++) {
@@ -593,13 +581,9 @@ static void gen6_fdi_link_train(struct intel_crtc *crtc,
udelay(150);
for (i = 0; i < 4; i++) {
- reg = FDI_TX_CTL(pipe);
- temp = intel_de_read(dev_priv, reg);
- temp &= ~FDI_LINK_TRAIN_VOL_EMP_MASK;
- temp |= snb_b_fdi_train_param[i];
- intel_de_write(dev_priv, reg, temp);
-
- intel_de_posting_read(dev_priv, reg);
+ intel_de_rmw(dev_priv, FDI_TX_CTL(pipe),
+FDI_LINK_TRAIN_VOL_EMP_MASK,
snb_b_fdi_train_param[i]);
+ intel_de_posting_read(dev_priv, FDI_TX_CTL(pipe));
udelay(500);
for (retry = 0; retry < 5; retry++) {
@@ -719,19 +703,13 @@ static void ivb_manual_fdi_link_train(struct intel_crtc
*crtc,
}
/* Train 2 */
- reg = FDI_TX_CTL(pipe);
- temp = intel_de_read(dev_priv, reg);
- temp &= ~FDI_LINK_TRAIN_NONE_IVB;
- temp |= FDI_LINK_TRAIN_PATTERN_2_IVB;
- intel_de_write(dev_priv, reg, temp);
-
- reg = FDI_RX_CTL(pipe);
- temp = intel_de_read(dev_priv, reg);
- temp &= ~FDI_LINK_TRAIN_PATTERN_MASK_CPT;
- temp |= FD
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool
On 03/02/2023 16:42, Kamil Konieczny wrote: Hi Tvrtko, On 2023-01-31 at 11:32:37 +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used to display a sorted by card and usage list of processes using GPUs. Borrows a bit of code from intel_gpu_top but for now omits the fancy features like interactive functionality, card selection, client aggregation, sort modes, JSON output and pretty engine names. Also no support for global GPU or system metrics. On the other hand it shows clients from all DRM cards which intel_gpu_top does not do. Signed-off-by: Tvrtko Ursulin Cc: Rob Clark Cc: Christian König Acked-by: Christian König I run it with: # ./gputop but it do not work on my Skylake card, I see no output, kernel 5.19.0-29-generic, ubuntu 22.10 Odd, 5.19 should have the support. Intel_gpu_top works - it is showing the individual clients? # ./lsgpu card0Intel Skylake (Gen9) drm:/dev/dri/card0 └─renderD128 drm:/dev/dri/renderD128 Please add some options like debug, version, debug with high verbose level, help. It seems like q or Q do not exit. As the cover letter hints I was only set out to demonstrate an extremely rudimentary vendor agnostic tool. To quote the cover letter more - "..It also makes no effort to provide sorting modes, well any interactivity, or any pretty names for GPUs or engines..". I have no scope presently to make it better or nicer. The tool however can serve as a starting point and people had reported it working as-is with a few other drivers, AMD, msm and most recently I believe etnaviv. So perhaps a pool of people to further improve it will be found there in the future. In summary I think it's worth reviewing so that the common code gets extracted from intel_gpu_top into respective libraries. After that I was hoping other people start contributing further improvements. Regards, Tvrtko
[Intel-gfx] [PATCH v2 14/14] vfio: Compile group optionally
group code is not needed for vfio device cdev, so with vfio device cdev
introduced, the group infrastructures can be compiled out if only cdev
is needed.
Signed-off-by: Yi Liu
---
drivers/vfio/Kconfig | 18 +++
drivers/vfio/Makefile | 2 +-
drivers/vfio/vfio.h | 69 +++
include/linux/vfio.h | 11 +++
4 files changed, 99 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index 0476abf154f2..de0fedcdf4d6 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -15,6 +15,7 @@ if VFIO
config VFIO_DEVICE_CDEV
bool "Support for the VFIO cdev /dev/vfio/devices/vfioX"
depends on IOMMUFD
+ default !VFIO_GROUP
help
The VFIO device cdev is another way for userspace to get device
access. Userspace gets device fd by opening device cdev under
@@ -23,9 +24,26 @@ config VFIO_DEVICE_CDEV
If you don't know what to do here, say N.
+config VFIO_ENABLE_GROUP
+ bool
+ default !VFIO_DEVICE_CDEV
+
+config VFIO_GROUP
+ bool "Support for the VFIO group /dev/vfio/$group_id"
+ select VFIO_ENABLE_GROUP
+ default y
+ help
+ VFIO group is legacy interface for userspace. For userspaces
+ adapted to iommufd and vfio device cdev, this can be N. For
+ now, before iommufd is ready and userspace applications fully
+ converted to iommufd and vfio device cdev, this should be Y.
+
+ If you don't know what to do here, say Y.
+
config VFIO_CONTAINER
bool "Support for the VFIO container /dev/vfio/vfio"
select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
+ depends on VFIO_ENABLE_GROUP
default y
help
The VFIO container is the classic interface to VFIO for establishing
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 245394aeb94b..4e81c3bbed30 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -2,9 +2,9 @@
obj-$(CONFIG_VFIO) += vfio.o
vfio-y += vfio_main.o \
- group.o \
iova_bitmap.o
vfio-$(CONFIG_VFIO_DEVICE_CDEV) += device_cdev.o
+vfio-$(CONFIG_VFIO_ENABLE_GROUP) += group.o
vfio-$(CONFIG_IOMMUFD) += iommufd.o
vfio-$(CONFIG_VFIO_CONTAINER) += container.o
vfio-$(CONFIG_VFIO_VIRQFD) += virqfd.o
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 8a290c1455e1..9f823cfff7be 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -62,6 +62,7 @@ enum vfio_group_type {
VFIO_NO_IOMMU,
};
+#if IS_ENABLED(CONFIG_VFIO_ENABLE_GROUP)
struct vfio_group {
struct device dev;
struct cdev cdev;
@@ -105,6 +106,74 @@ bool vfio_group_has_dev(struct vfio_group *group, struct
vfio_device *device);
bool vfio_device_has_container(struct vfio_device *device);
int __init vfio_group_init(void);
void vfio_group_cleanup(void);
+#else
+struct vfio_group;
+
+static inline int vfio_device_set_group(struct vfio_device *device,
+ enum vfio_group_type type)
+{
+ return 0;
+}
+
+static inline void vfio_device_remove_group(struct vfio_device *device)
+{
+}
+
+static inline void vfio_device_group_register(struct vfio_device *device)
+{
+}
+
+static inline void vfio_device_group_unregister(struct vfio_device *device)
+{
+}
+
+static inline int vfio_device_group_use_iommu(struct vfio_device *device)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline void vfio_device_group_unuse_iommu(struct vfio_device *device)
+{
+}
+
+static inline void vfio_device_group_close(struct vfio_device_file *df)
+{
+}
+
+static inline struct vfio_group *vfio_group_from_file(struct file *file)
+{
+ return NULL;
+}
+
+static inline bool vfio_group_enforced_coherent(struct vfio_group *group)
+{
+ return true;
+}
+
+static inline void vfio_group_set_kvm(struct vfio_group *group, struct kvm
*kvm)
+{
+}
+
+static inline bool vfio_group_has_dev(struct vfio_group *group,
+ struct vfio_device *device)
+{
+ return false;
+}
+
+static inline bool vfio_device_has_container(struct vfio_device *device)
+{
+ return false;
+}
+
+static inline int __init vfio_group_init(void)
+{
+ return 0;
+}
+
+static inline void vfio_group_cleanup(void)
+{
+}
+#endif /* CONFIG_VFIO_ENABLE_GROUP */
#if IS_ENABLED(CONFIG_VFIO_CONTAINER)
/* events for the backend driver notify callback */
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index fd4bf9c21ffe..4c7666f8c5da 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -43,7 +43,9 @@ struct vfio_device {
*/
const struct vfio_migration_ops *mig_ops;
const struct vfio_log_ops *log_ops;
+#if IS_ENABLED(CONFIG_VFIO_ENABLE_GROUP)
struct vfio_group *group;
+#endif
struct vfio_device_set *dev_set;
struct list_head dev_set_list;
unsigned int migration_flags;
@@ -56,8 +58
[Intel-gfx] [PATCH v2 13/14] vfio: Add ioctls for device cdev using iommufd
This adds three vfio device ioctls for userspace using iommufd to set up
secure DMA context for device access.
VFIO_DEVICE_BIND_IOMMUFD: bind device to an iommufd, hence gain DMA
control provided by the iommufd. VFIO no
iommu mode is indicated by passing a minus
fd value.
VFIO_DEVICE_ATTACH_IOMMUFD_PT: attach device to IOAS, hw_pagetable
managed by iommufd. Attach can be
undo by VFIO_DEVICE_DETACH_IOMMUFD_PT
or device fd close.
VFIO_DEVICE_DETACH_IOMMUFD_PT: detach device from the current attached
IOAS or hw_pagetable managed by iommufd.
Signed-off-by: Yi Liu
---
drivers/vfio/device_cdev.c | 176 +
drivers/vfio/vfio.h| 33 ++-
drivers/vfio/vfio_main.c | 47 +-
include/linux/iommufd.h| 6 ++
include/uapi/linux/vfio.h | 86 ++
5 files changed, 343 insertions(+), 5 deletions(-)
diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
index f024833c9e2c..4105cc939b7b 100644
--- a/drivers/vfio/device_cdev.c
+++ b/drivers/vfio/device_cdev.c
@@ -3,6 +3,7 @@
* Copyright (c) 2023 Intel Corporation.
*/
#include
+#include
#include "vfio.h"
@@ -46,6 +47,181 @@ int vfio_device_fops_open(struct inode *inode, struct file
*filep)
return ret;
}
+void vfio_device_cdev_close(struct vfio_device_file *df)
+{
+ mutex_lock(&df->device->dev_set->lock);
+ vfio_device_close(df);
+ vfio_device_put_kvm(df->device);
+ mutex_unlock(&df->device->dev_set->lock);
+}
+
+static void vfio_device_get_kvm_safe(struct vfio_device_file *df)
+{
+ spin_lock(&df->kvm_ref_lock);
+ if (!df->kvm)
+ goto unlock;
+
+ _vfio_device_get_kvm_safe(df->device, df->kvm);
+
+unlock:
+ spin_unlock(&df->kvm_ref_lock);
+}
+
+long vfio_device_ioctl_bind_iommufd(struct vfio_device_file *df,
+ unsigned long arg)
+{
+ struct vfio_device *device = df->device;
+ struct vfio_device_bind_iommufd bind;
+ struct iommufd_ctx *iommufd = NULL;
+ unsigned long minsz;
+ struct fd f;
+ int ret;
+
+ minsz = offsetofend(struct vfio_device_bind_iommufd, iommufd);
+
+ if (copy_from_user(&bind, (void __user *)arg, minsz))
+ return -EFAULT;
+
+ if (bind.argsz < minsz || bind.flags)
+ return -EINVAL;
+
+ if (!device->ops->bind_iommufd)
+ return -ENODEV;
+
+ mutex_lock(&device->dev_set->lock);
+ /*
+* If already been bound to an iommufd, or already set noiommu
+* then fail it.
+*/
+ if (df->iommufd || df->noiommu) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
+ /* iommufd < 0 means noiommu mode */
+ if (bind.iommufd < 0) {
+ if (!capable(CAP_SYS_RAWIO)) {
+ ret = -EPERM;
+ goto out_unlock;
+ }
+ df->noiommu = true;
+ } else {
+ f = fdget(bind.iommufd);
+ if (!f.file) {
+ ret = -EBADF;
+ goto out_unlock;
+ }
+ iommufd = iommufd_ctx_from_file(f.file);
+ if (IS_ERR(iommufd)) {
+ ret = PTR_ERR(iommufd);
+ goto out_put_file;
+ }
+ }
+
+ /*
+* Before the first device open, get the KVM pointer currently
+* associated with the device file (if there is) and obtain a
+* reference. This reference is held until device closed. Save
+* the pointer in the device for use by drivers.
+*/
+ vfio_device_get_kvm_safe(df);
+
+ df->iommufd = iommufd;
+ ret = vfio_device_open(df, &bind.out_devid, NULL);
+ if (ret)
+ goto out_put_kvm;
+
+ ret = copy_to_user((void __user *)arg + minsz,
+ &bind.out_devid,
+ sizeof(bind.out_devid)) ? -EFAULT : 0;
+ if (ret)
+ goto out_close_device;
+
+ if (iommufd)
+ fdput(f);
+ else if (df->noiommu)
+ dev_warn(device->dev, "vfio-noiommu device used by user "
+"(%s:%d)\n", current->comm, task_pid_nr(current));
+ mutex_unlock(&device->dev_set->lock);
+ return 0;
+
+out_close_device:
+ vfio_device_close(df);
+out_put_kvm:
+ vfio_device_put_kvm(device);
+out_put_file:
+ if (iommufd)
+ fdput(f);
+out_unlock:
+ df->iommufd = NULL;
+ df->noiommu = false;
+ mutex_unlock(&device->dev_set->lock);
+ return ret;
+}
+
+int vfio_ioctl_device_attach(struct vfio_device_file *df,
+
[Intel-gfx] [PATCH v2 12/14] vfio: Add cdev for vfio_device
This allows user to directly open a vfio device w/o using the legacy
container/group interface, as a prerequisite for supporting new iommu
features like nested translation.
The device fd opened in this manner doesn't have the capability to access
the device as the fops open() doesn't open the device until the successful
BIND_IOMMUFD which be added in next patch.
With this patch, devices registered to vfio core have both group and device
interface created.
- group interface : /dev/vfio/$groupID
- device interface: /dev/vfio/devices/vfioX (X is the minor number and
is unique across devices)
Given a vfio device the user can identify the matching vfioX by checking
the sysfs path of the device. Take PCI device (:6a:01.0) for example,
/sys/bus/pci/devices/\:6a\:01.0/vfio-dev/vfio0/dev contains the
major:minor of the matching vfioX.
Userspace then opens the /dev/vfio/devices/vfioX and checks with fstat
that the major:minor matches.
The vfio_device cdev logic in this patch:
*) __vfio_register_dev() path ends up doing cdev_device_add() for each
vfio_device;
*) vfio_unregister_group_dev() path does cdev_device_del();
Signed-off-by: Yi Liu
Signed-off-by: Joao Martins
---
drivers/vfio/Kconfig | 11 +++
drivers/vfio/Makefile | 1 +
drivers/vfio/device_cdev.c | 64 ++
drivers/vfio/vfio.h| 26
drivers/vfio/vfio_main.c | 41 +---
include/linux/vfio.h | 2 ++
6 files changed, 141 insertions(+), 4 deletions(-)
create mode 100644 drivers/vfio/device_cdev.c
diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
index a8f544629467..0476abf154f2 100644
--- a/drivers/vfio/Kconfig
+++ b/drivers/vfio/Kconfig
@@ -12,6 +12,17 @@ menuconfig VFIO
If you don't know what to do here, say N.
if VFIO
+config VFIO_DEVICE_CDEV
+ bool "Support for the VFIO cdev /dev/vfio/devices/vfioX"
+ depends on IOMMUFD
+ help
+ The VFIO device cdev is another way for userspace to get device
+ access. Userspace gets device fd by opening device cdev under
+ /dev/vfio/devices/vfioX, and then bind the device fd with an iommufd
+ to set up secure context for device access.
+
+ If you don't know what to do here, say N.
+
config VFIO_CONTAINER
bool "Support for the VFIO container /dev/vfio/vfio"
select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM || ARM64)
diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
index 70e7dcb302ef..245394aeb94b 100644
--- a/drivers/vfio/Makefile
+++ b/drivers/vfio/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_VFIO) += vfio.o
vfio-y += vfio_main.o \
group.o \
iova_bitmap.o
+vfio-$(CONFIG_VFIO_DEVICE_CDEV) += device_cdev.o
vfio-$(CONFIG_IOMMUFD) += iommufd.o
vfio-$(CONFIG_VFIO_CONTAINER) += container.o
vfio-$(CONFIG_VFIO_VIRQFD) += virqfd.o
diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
new file mode 100644
index ..f024833c9e2c
--- /dev/null
+++ b/drivers/vfio/device_cdev.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Intel Corporation.
+ */
+#include
+
+#include "vfio.h"
+
+static struct vfio {
+ dev_t device_devt;
+} vfio;
+
+void vfio_init_device_cdev(struct vfio_device *device)
+{
+ device->device.devt = MKDEV(MAJOR(vfio.device_devt), device->index);
+ cdev_init(&device->cdev, &vfio_device_fops);
+ device->cdev.owner = THIS_MODULE;
+}
+
+int vfio_device_fops_open(struct inode *inode, struct file *filep)
+{
+ struct vfio_device *device = container_of(inode->i_cdev,
+ struct vfio_device, cdev);
+ struct vfio_device_file *df;
+ int ret;
+
+ if (!vfio_device_try_get_registration(device))
+ return -ENODEV;
+
+ /*
+* device access is blocked until .open_device() is called
+* in BIND_IOMMUFD.
+*/
+ df = vfio_allocate_device_file(device, true);
+ if (IS_ERR(df)) {
+ ret = PTR_ERR(df);
+ goto err_put_registration;
+ }
+
+ filep->private_data = df;
+
+ return 0;
+
+err_put_registration:
+ vfio_device_put_registration(device);
+ return ret;
+}
+
+static char *vfio_device_devnode(const struct device *dev, umode_t *mode)
+{
+ return kasprintf(GFP_KERNEL, "vfio/devices/%s", dev_name(dev));
+}
+
+int vfio_cdev_init(struct class *device_class)
+{
+ device_class->devnode = vfio_device_devnode;
+ return alloc_chrdev_region(&vfio.device_devt, 0,
+ MINORMASK + 1, "vfio-dev");
+}
+
+void vfio_cdev_cleanup(void)
+{
+ unregister_chrdev_region(vfio.device_devt, MINORMASK + 1);
+}
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 2debf0173861..c7c75865afec 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -250,6
[Intel-gfx] [PATCH v2 11/14] vfio: Make vfio_device_open() exclusive between group path and device cdev path
With the introduction of vfio device cdev, userspace can get device
access by either the legacy group path or the cdev path. For VFIO devices,
it can only be opened by one of the group path and the cdev path at one
time. e.g. when the device is opened via cdev path, the group path should
be failed. Both paths will call into vfio_device_open(), so the exclusion
is done in it.
VFIO group has historically allowed multi-open of the device FD. This
was made secure because the "open" was executed via an ioctl to the
group FD which is itself only single open.
However, no known use of multiple device FDs today. It is kind of a
strange thing to do because new device FDs can naturally be created
via dup().
When we implement the new device uAPI (only used in cdev path) there is
no natural way to allow the device itself from being multi-opened in a
secure manner. Without the group FD we cannot prove the security context
of the opener.
Thus, when moving to the new uAPI we block the ability to multi-open
the device. Old group path still allows it. This requires vfio_device_open()
exclusive between the cdev path with the group path.
The main logic is in the vfio_device_open(). It needs to sustain both
the legacy behavior i.e. multi-open in the group path and the new
behavior i.e. single-open in the cdev path. This mixture leads to the
introduction of a new is_cdev_device flag in struct vfio_device_file,
and a single_open flag in struct vfio_device.
- vfio_device_file::is_cdev_device is set per the vfio_device_file
allocation.
- vfio_device::single_open is set after open_device op is called
successfully if vfio_device_file::is_cdev_device is set.
Signed-off-by: Yi Liu
---
drivers/vfio/group.c | 2 +-
drivers/vfio/vfio.h | 4 +++-
drivers/vfio/vfio_main.c | 26 +++---
include/linux/vfio.h | 1 +
4 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index 9f3f6f0e4942..a90273aa77ec 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -237,7 +237,7 @@ static struct file *vfio_device_open_file(struct
vfio_device *device)
struct file *filep;
int ret;
- df = vfio_allocate_device_file(device);
+ df = vfio_allocate_device_file(device, false);
if (IS_ERR(df)) {
ret = PTR_ERR(df);
goto err_out;
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 9126500381f5..2debf0173861 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -18,6 +18,8 @@ struct vfio_container;
struct vfio_device_file {
struct vfio_device *device;
+ bool is_cdev_device;
+
bool access_granted;
spinlock_t kvm_ref_lock; /* protect kvm field */
struct kvm *kvm;
@@ -30,7 +32,7 @@ int vfio_device_open(struct vfio_device_file *df,
u32 *dev_id, u32 *pt_id);
void vfio_device_close(struct vfio_device_file *df);
struct vfio_device_file *
-vfio_allocate_device_file(struct vfio_device *device);
+vfio_allocate_device_file(struct vfio_device *device, bool is_cdev_device);
extern const struct file_operations vfio_device_fops;
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 05dd4b89e9d1..e07b185f9820 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -398,7 +398,7 @@ static bool vfio_assert_device_open(struct vfio_device
*device)
}
struct vfio_device_file *
-vfio_allocate_device_file(struct vfio_device *device)
+vfio_allocate_device_file(struct vfio_device *device, bool is_cdev_device)
{
struct vfio_device_file *df;
@@ -407,6 +407,7 @@ vfio_allocate_device_file(struct vfio_device *device)
return ERR_PTR(-ENOMEM);
df->device = device;
+ df->is_cdev_device = is_cdev_device;
spin_lock_init(&df->kvm_ref_lock);
return df;
@@ -472,11 +473,23 @@ int vfio_device_open(struct vfio_device_file *df,
lockdep_assert_held(&device->dev_set->lock);
+ /*
+* Device cdev path cannot support multiple device open since
+* it doesn't have a secure way for it. So a second device
+* open attempt should be failed if the caller is from a cdev
+* path or the device has already been opened by a cdev path.
+*/
+ if (device->open_count != 0 &&
+ (df->is_cdev_device || device->single_open))
+ return -EINVAL;
+
device->open_count++;
if (device->open_count == 1) {
ret = vfio_device_first_open(df, dev_id, pt_id);
if (ret)
device->open_count--;
+ else
+ device->single_open = df->is_cdev_device;
}
if (ret)
@@ -497,8 +510,10 @@ void vfio_device_close(struct vfio_device_file *df)
lockdep_assert_held(&device->dev_set->lock);
vfio_assert_device_open(device);
- if (device->open_count == 1)
+ if
[Intel-gfx] [PATCH v2 10/14] vfio-iommufd: Add detach_ioas for emulated VFIO devices
this prepares for adding DETACH ioctl for emulated VFIO devices.
Signed-off-by: Yi Liu
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
drivers/s390/cio/vfio_ccw_ops.c | 1 +
drivers/s390/crypto/vfio_ap_ops.c | 1 +
drivers/vfio/iommufd.c| 29 +
include/linux/vfio.h | 3 +++
5 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 8ae7039b3683..8a76a84bc3c1 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1474,6 +1474,7 @@ static const struct vfio_device_ops intel_vgpu_dev_ops = {
.bind_iommufd = vfio_iommufd_emulated_bind,
.unbind_iommufd = vfio_iommufd_emulated_unbind,
.attach_ioas= vfio_iommufd_emulated_attach_ioas,
+ .detach_ioas= vfio_iommufd_emulated_detach_ioas,
};
static int intel_vgpu_probe(struct mdev_device *mdev)
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 5b53b94f13c7..cba4971618ff 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -632,6 +632,7 @@ static const struct vfio_device_ops vfio_ccw_dev_ops = {
.bind_iommufd = vfio_iommufd_emulated_bind,
.unbind_iommufd = vfio_iommufd_emulated_unbind,
.attach_ioas = vfio_iommufd_emulated_attach_ioas,
+ .detach_ioas = vfio_iommufd_emulated_detach_ioas,
};
struct mdev_driver vfio_ccw_mdev_driver = {
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 9c01957e56b3..f99c69d40982 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -1802,6 +1802,7 @@ static const struct vfio_device_ops
vfio_ap_matrix_dev_ops = {
.bind_iommufd = vfio_iommufd_emulated_bind,
.unbind_iommufd = vfio_iommufd_emulated_unbind,
.attach_ioas = vfio_iommufd_emulated_attach_ioas,
+ .detach_ioas = vfio_iommufd_emulated_detach_ioas,
};
static struct mdev_driver vfio_ap_matrix_driver = {
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index 90df1f30b7fd..026f81a87dd7 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -149,14 +149,18 @@ int vfio_iommufd_emulated_bind(struct vfio_device *vdev,
}
EXPORT_SYMBOL_GPL(vfio_iommufd_emulated_bind);
+static void __vfio_iommufd_access_destroy(struct vfio_device *vdev)
+{
+ iommufd_access_destroy(vdev->iommufd_access);
+ vdev->iommufd_access = NULL;
+}
+
void vfio_iommufd_emulated_unbind(struct vfio_device *vdev)
{
lockdep_assert_held(&vdev->dev_set->lock);
- if (vdev->iommufd_access) {
- iommufd_access_destroy(vdev->iommufd_access);
- vdev->iommufd_access = NULL;
- }
+ if (vdev->iommufd_access)
+ __vfio_iommufd_access_destroy(vdev);
iommufd_ctx_put(vdev->iommufd_ictx);
vdev->iommufd_ictx = NULL;
}
@@ -168,6 +172,12 @@ int vfio_iommufd_emulated_attach_ioas(struct vfio_device
*vdev, u32 *pt_id)
lockdep_assert_held(&vdev->dev_set->lock);
+ if (!vdev->iommufd_ictx)
+ return -EINVAL;
+
+ if (vdev->iommufd_access)
+ return -EBUSY;
+
user = iommufd_access_create(vdev->iommufd_ictx, *pt_id, &vfio_user_ops,
vdev);
if (IS_ERR(user))
@@ -176,3 +186,14 @@ int vfio_iommufd_emulated_attach_ioas(struct vfio_device
*vdev, u32 *pt_id)
return 0;
}
EXPORT_SYMBOL_GPL(vfio_iommufd_emulated_attach_ioas);
+
+void vfio_iommufd_emulated_detach_ioas(struct vfio_device *vdev)
+{
+ lockdep_assert_held(&vdev->dev_set->lock);
+
+ if (!vdev->iommufd_ictx || !vdev->iommufd_access)
+ return;
+
+ __vfio_iommufd_access_destroy(vdev);
+}
+EXPORT_SYMBOL_GPL(vfio_iommufd_emulated_detach_ioas);
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 99a6a07e915c..70380d4955e1 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -125,6 +125,7 @@ int vfio_iommufd_emulated_bind(struct vfio_device *vdev,
struct iommufd_ctx *ictx, u32 *out_device_id);
void vfio_iommufd_emulated_unbind(struct vfio_device *vdev);
int vfio_iommufd_emulated_attach_ioas(struct vfio_device *vdev, u32 *pt_id);
+void vfio_iommufd_emulated_detach_ioas(struct vfio_device *vdev);
#else
#define vfio_iommufd_physical_bind \
((int (*)(struct vfio_device *vdev, struct iommufd_ctx *ictx, \
@@ -142,6 +143,8 @@ int vfio_iommufd_emulated_attach_ioas(struct vfio_device
*vdev, u32 *pt_id);
((void (*)(struct vfio_device *vdev)) NULL)
#define vfio_iommufd_emulated_attach_ioas \
((int (*)(struct vfio_device *vdev, u32 *pt_id)) NULL)
+#define vfio_iommufd_emulated_detach_ioas \
+ ((void (*)(struct vfio_device *vdev)) NULL)
#endif
/**
--
2.34.1
[Intel-gfx] [PATCH v2 08/14] vfio: Add infrastructure for bind_iommufd from userspace
For the device fd opened from cdev, userspace needs to bind it to an
iommufd and attach it to IOAS managed by iommufd. With such operations,
userspace can set up a secure DMA context and hence access device.
This changes the existing vfio_iommufd_bind() to accept a pt_id pointer
as an optional input, and also an dev_id pointer to selectively return
the dev_id to prepare for adding bind_iommufd ioctl, which does the bind
first and then attach IOAS.
Signed-off-by: Yi Liu
---
drivers/vfio/group.c | 17 ++---
drivers/vfio/iommufd.c | 21 +
drivers/vfio/vfio.h | 9 ++---
drivers/vfio/vfio_main.c | 10 ++
4 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index 2abf55c69281..9f3f6f0e4942 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -169,6 +169,7 @@ static void vfio_device_group_get_kvm_safe(struct
vfio_device *device)
static int vfio_device_group_open(struct vfio_device_file *df)
{
struct vfio_device *device = df->device;
+ u32 ioas_id;
int ret;
mutex_lock(&device->group->group_lock);
@@ -177,6 +178,13 @@ static int vfio_device_group_open(struct vfio_device_file
*df)
goto out_unlock;
}
+ if (device->group->iommufd) {
+ ret = iommufd_vfio_compat_ioas_id(device->group->iommufd,
+ &ioas_id);
+ if (ret)
+ goto out_unlock;
+ }
+
mutex_lock(&device->dev_set->lock);
/*
@@ -188,9 +196,12 @@ static int vfio_device_group_open(struct vfio_device_file
*df)
if (device->open_count == 0)
vfio_device_group_get_kvm_safe(device);
- df->iommufd = device->group->iommufd;
-
- ret = vfio_device_open(df);
+ if (device->group->iommufd) {
+ df->iommufd = device->group->iommufd;
+ ret = vfio_device_open(df, NULL, &ioas_id);
+ } else {
+ ret = vfio_device_open(df, NULL, NULL);
+ }
if (ret)
df->iommufd = NULL;
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index 4f82a6fa7c6c..beef6ca21107 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -10,9 +10,9 @@
MODULE_IMPORT_NS(IOMMUFD);
MODULE_IMPORT_NS(IOMMUFD_VFIO);
-int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
+int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx,
+ u32 *dev_id, u32 *pt_id)
{
- u32 ioas_id;
u32 device_id;
int ret;
@@ -29,17 +29,14 @@ int vfio_iommufd_bind(struct vfio_device *vdev, struct
iommufd_ctx *ictx)
if (ret)
return ret;
- ret = iommufd_vfio_compat_ioas_id(ictx, &ioas_id);
- if (ret)
- goto err_unbind;
- ret = vdev->ops->attach_ioas(vdev, &ioas_id);
- if (ret)
- goto err_unbind;
+ if (pt_id) {
+ ret = vdev->ops->attach_ioas(vdev, pt_id);
+ if (ret)
+ goto err_unbind;
+ }
- /*
-* The legacy path has no way to return the device id or the selected
-* pt_id
-*/
+ if (dev_id)
+ *dev_id = device_id;
return 0;
err_unbind:
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index 802e13f1256e..9126500381f5 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -26,7 +26,8 @@ struct vfio_device_file {
void vfio_device_put_registration(struct vfio_device *device);
bool vfio_device_try_get_registration(struct vfio_device *device);
-int vfio_device_open(struct vfio_device_file *df);
+int vfio_device_open(struct vfio_device_file *df,
+u32 *dev_id, u32 *pt_id);
void vfio_device_close(struct vfio_device_file *df);
struct vfio_device_file *
vfio_allocate_device_file(struct vfio_device *device);
@@ -231,11 +232,13 @@ static inline void vfio_container_cleanup(void)
#endif
#if IS_ENABLED(CONFIG_IOMMUFD)
-int vfio_iommufd_bind(struct vfio_device *device, struct iommufd_ctx *ictx);
+int vfio_iommufd_bind(struct vfio_device *device, struct iommufd_ctx *ictx,
+ u32 *dev_id, u32 *pt_id);
void vfio_iommufd_unbind(struct vfio_device *device);
#else
static inline int vfio_iommufd_bind(struct vfio_device *device,
- struct iommufd_ctx *ictx)
+ struct iommufd_ctx *ictx,
+ u32 *dev_id, u32 *pt_id)
{
return -EOPNOTSUPP;
}
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 2267057240bd..b40c2d95f693 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -411,7 +411,8 @@ vfio_allocate_device_file(struct vfio_device *device)
return df;
}
-static int vfio_device_first_open(struct vfio_device_file *df)
+static int vfi
[Intel-gfx] [PATCH v2 09/14] vfio-iommufd: Add detach_ioas support for physical VFIO devices
this prepares for adding DETACH ioctl for physical VFIO devices.
Signed-off-by: Yi Liu
---
Documentation/driver-api/vfio.rst | 8 +++--
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 1 +
drivers/vfio/iommufd.c| 31 ---
.../vfio/pci/hisilicon/hisi_acc_vfio_pci.c| 2 ++
drivers/vfio/pci/mlx5/main.c | 1 +
drivers/vfio/pci/vfio_pci.c | 1 +
drivers/vfio/platform/vfio_amba.c | 1 +
drivers/vfio/platform/vfio_platform.c | 1 +
drivers/vfio/vfio_main.c | 3 +-
include/linux/vfio.h | 5 +++
10 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/Documentation/driver-api/vfio.rst
b/Documentation/driver-api/vfio.rst
index 0bfa7261f991..bbc7934fd55d 100644
--- a/Documentation/driver-api/vfio.rst
+++ b/Documentation/driver-api/vfio.rst
@@ -279,6 +279,7 @@ similar to a file operations structure::
struct iommufd_ctx *ictx, u32
*out_device_id);
void(*unbind_iommufd)(struct vfio_device *vdev);
int (*attach_ioas)(struct vfio_device *vdev, u32 *pt_id);
+ void(*detach_ioas)(struct vfio_device *vdev);
int (*open_device)(struct vfio_device *vdev);
void(*close_device)(struct vfio_device *vdev);
ssize_t (*read)(struct vfio_device *vdev, char __user *buf,
@@ -314,9 +315,10 @@ container_of().
- The [un]bind_iommufd callbacks are issued when the device is bound to
and unbound from iommufd.
- - The attach_ioas callback is issued when the device is attached to an
- IOAS managed by the bound iommufd. The attached IOAS is automatically
- detached when the device is unbound from iommufd.
+ - The [de]attach_ioas callback is issued when the device is attached to
+ and detached from an IOAS managed by the bound iommufd. However, the
+ attached IOAS can also be automatically detached when the device is
+ unbound from iommufd.
- The read/write/mmap callbacks implement the device region access
defined
by the device's own VFIO_DEVICE_GET_REGION_INFO ioctl.
diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
index c89a047a4cd8..d540cf683d93 100644
--- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
+++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
@@ -594,6 +594,7 @@ static const struct vfio_device_ops vfio_fsl_mc_ops = {
.bind_iommufd = vfio_iommufd_physical_bind,
.unbind_iommufd = vfio_iommufd_physical_unbind,
.attach_ioas= vfio_iommufd_physical_attach_ioas,
+ .detach_ioas= vfio_iommufd_physical_detach_ioas,
};
static struct fsl_mc_driver vfio_fsl_mc_driver = {
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index beef6ca21107..90df1f30b7fd 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -71,14 +71,18 @@ int vfio_iommufd_physical_bind(struct vfio_device *vdev,
}
EXPORT_SYMBOL_GPL(vfio_iommufd_physical_bind);
+static void __vfio_iommufd_detach(struct vfio_device *vdev)
+{
+ iommufd_device_detach(vdev->iommufd_device);
+ vdev->iommufd_attached = false;
+}
+
void vfio_iommufd_physical_unbind(struct vfio_device *vdev)
{
lockdep_assert_held(&vdev->dev_set->lock);
- if (vdev->iommufd_attached) {
- iommufd_device_detach(vdev->iommufd_device);
- vdev->iommufd_attached = false;
- }
+ if (vdev->iommufd_attached)
+ __vfio_iommufd_detach(vdev);
iommufd_device_unbind(vdev->iommufd_device);
vdev->iommufd_device = NULL;
}
@@ -88,6 +92,14 @@ int vfio_iommufd_physical_attach_ioas(struct vfio_device
*vdev, u32 *pt_id)
{
int rc;
+ lockdep_assert_held(&vdev->dev_set->lock);
+
+ if (!vdev->iommufd_device)
+ return -EINVAL;
+
+ if (vdev->iommufd_attached)
+ return -EBUSY;
+
rc = iommufd_device_attach(vdev->iommufd_device, pt_id);
if (rc)
return rc;
@@ -96,6 +108,17 @@ int vfio_iommufd_physical_attach_ioas(struct vfio_device
*vdev, u32 *pt_id)
}
EXPORT_SYMBOL_GPL(vfio_iommufd_physical_attach_ioas);
+void vfio_iommufd_physical_detach_ioas(struct vfio_device *vdev)
+{
+ lockdep_assert_held(&vdev->dev_set->lock);
+
+ if (!vdev->iommufd_device || !vdev->iommufd_attached)
+ return;
+
+ __vfio_iommufd_detach(vdev);
+}
+EXPORT_SYMBOL_GPL(vfio_iommufd_physical_detach_ioas);
+
/*
* The emulated standard ops mean that vfio_device is going to use the
* "mdev path" and will call vfio_pin_pages()/vfio_dma_rw(). Drivers using this
diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
index a117eaf21c14..b2f9778c8366 100644
--- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
+++ b/dri
[Intel-gfx] [PATCH v2 07/14] vfio: Block device access via device fd until device is opened
Allow the vfio_device file to be in a state where the device FD is
opened but the device cannot be used by userspace (i.e. its .open_device()
hasn't been called). This inbetween state is not used when the device
FD is spawned from the group FD, however when we create the device FD
directly by opening a cdev it will be opened in the blocked state.
The reason for the inbetween state is userspace only gets a FD but
doesn't have the secure until binding the FD to an iommufd. So in the
blocked state, only the bind operation is allowed, other device accesses
are not allowed. Completing bind will allow user to further access the
device.
This is implemented by adding a flag in struct vfio_device_file to mark
the blocked state and using a simple smp_load_acquire() to obtain the
flag value and serialize all the device setup with the thread accessing
this device.
Following this lockless scheme, it can safely handle the device FD
unbound->bound but it cannot handle bound->unbound. To allow this we'd
need to add a lock on all the vfio ioctls which seems costly. So once
device FD is bound, it remains bound until the FD is closed.
Suggested-by: Jason Gunthorpe
Signed-off-by: Yi Liu
---
drivers/vfio/vfio.h | 1 +
drivers/vfio/vfio_main.c | 34 +-
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index d8275881c1f1..802e13f1256e 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -18,6 +18,7 @@ struct vfio_container;
struct vfio_device_file {
struct vfio_device *device;
+ bool access_granted;
spinlock_t kvm_ref_lock; /* protect kvm field */
struct kvm *kvm;
struct iommufd_ctx *iommufd; /* protected by struct
vfio_device_set::lock */
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index c517252aba19..2267057240bd 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -476,7 +476,15 @@ int vfio_device_open(struct vfio_device_file *df)
device->open_count--;
}
- return ret;
+ if (ret)
+ return ret;
+
+ /*
+* Paired with smp_load_acquire() in vfio_device_fops::ioctl/
+* read/write/mmap
+*/
+ smp_store_release(&df->access_granted, true);
+ return 0;
}
void vfio_device_close(struct vfio_device_file *df)
@@ -1104,8 +1112,14 @@ static long vfio_device_fops_unl_ioctl(struct file
*filep,
{
struct vfio_device_file *df = filep->private_data;
struct vfio_device *device = df->device;
+ bool access;
int ret;
+ /* Paired with smp_store_release() in vfio_device_open() */
+ access = smp_load_acquire(&df->access_granted);
+ if (!access)
+ return -EINVAL;
+
ret = vfio_device_pm_runtime_get(device);
if (ret)
return ret;
@@ -1132,6 +1146,12 @@ static ssize_t vfio_device_fops_read(struct file *filep,
char __user *buf,
{
struct vfio_device_file *df = filep->private_data;
struct vfio_device *device = df->device;
+ bool access;
+
+ /* Paired with smp_store_release() in vfio_device_open() */
+ access = smp_load_acquire(&df->access_granted);
+ if (!access)
+ return -EINVAL;
if (unlikely(!device->ops->read))
return -EINVAL;
@@ -1145,6 +1165,12 @@ static ssize_t vfio_device_fops_write(struct file *filep,
{
struct vfio_device_file *df = filep->private_data;
struct vfio_device *device = df->device;
+ bool access;
+
+ /* Paired with smp_store_release() in vfio_device_open() */
+ access = smp_load_acquire(&df->access_granted);
+ if (!access)
+ return -EINVAL;
if (unlikely(!device->ops->write))
return -EINVAL;
@@ -1156,6 +1182,12 @@ static int vfio_device_fops_mmap(struct file *filep,
struct vm_area_struct *vma)
{
struct vfio_device_file *df = filep->private_data;
struct vfio_device *device = df->device;
+ bool access;
+
+ /* Paired with smp_store_release() in vfio_device_open() */
+ access = smp_load_acquire(&df->access_granted);
+ if (!access)
+ return -EINVAL;
if (unlikely(!device->ops->mmap))
return -EINVAL;
--
2.34.1
