[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Handle dma fences in dirtyfb ioctl
== Series Details == Series: Handle dma fences in dirtyfb ioctl URL : https://patchwork.freedesktop.org/series/116620/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v9 02/10] drm/hdcp: Avoid changing crtc state in hdcp atomic check
>
> From: Sean Paul
>
> Instead of forcing a modeset in the hdcp atomic check, rename to
> drm_hdcp_has_changed and return true if the content protection value is
> changing and let the driver decide whether a modeset is required or not.
>
> Acked-by: Jani Nikula
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: Sean Paul
> Signed-off-by: Mark Yacoub
>
> ---
> Changes in v2:
> -None
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -None
> Changes in v6:
> -Rebase: modifications in drm_hdcp_helper.c instead of drm_hdcp.c
> Changes in v7:
> -Renamed the function from drm_hdcp_atomic_check to
> drm_hdcp_has_changed (Dmitry Baryshkov)
>
> drivers/gpu/drm/display/drm_hdcp_helper.c | 39 ++---
> drivers/gpu/drm/i915/display/intel_atomic.c | 6 ++--
> include/drm/display/drm_hdcp_helper.h | 2 +-
> 3 files changed, 30 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
> b/drivers/gpu/drm/display/drm_hdcp_helper.c
> index 7ca390b3ea106..34baf2b97cd87 100644
> --- a/drivers/gpu/drm/display/drm_hdcp_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
> @@ -422,18 +422,21 @@ void drm_hdcp_update_content_protection(struct
> drm_connector *connector,
> EXPORT_SYMBOL(drm_hdcp_update_content_protection);
>
> /**
> - * drm_hdcp_atomic_check - Helper for drivers to call during connector-
> >atomic_check
> + * drm_hdcp_has_changed - Helper for drivers to call during
> + connector->atomic_check
> *
> * @state: pointer to the atomic state being checked
> * @connector: drm_connector on which content protection state needs an
> update
> *
> * This function can be used by display drivers to perform an atomic check
> on the
> - * hdcp state elements. If hdcp state has changed, this function will set
> - * mode_changed on the crtc driving the connector so it can update its
> hardware
> - * to match the hdcp state.
> + * hdcp state elements. If hdcp state has changed in a manner which
> + requires the
> + * driver to enable or disable content protection, this function will
> + return
> + * true.
> + *
> + * Returns:
> + * true if the driver must enable/disable hdcp, false otherwise
> */
> -void drm_hdcp_atomic_check(struct drm_connector *connector,
> -struct drm_atomic_state *state)
> +bool drm_hdcp_has_changed(struct drm_connector *connector,
> + struct drm_atomic_state *state)
> {
> struct drm_connector_state *new_conn_state, *old_conn_state;
> struct drm_crtc_state *new_crtc_state; @@ -450,19 +453,31 @@
> void drm_hdcp_atomic_check(struct drm_connector *connector,
>* If the connector is being disabled with CP enabled, mark it
>* desired so it's re-enabled when the connector is brought
> back
>*/
> - if (old_hdcp ==
> DRM_MODE_CONTENT_PROTECTION_ENABLED)
> + if (old_hdcp ==
> DRM_MODE_CONTENT_PROTECTION_ENABLED) {
> new_conn_state->content_protection =
>
> DRM_MODE_CONTENT_PROTECTION_DESIRED;
> - return;
> + return true;
> + }
> + return false;
> }
>
> new_crtc_state =
> drm_atomic_get_new_crtc_state(state, new_conn_state-
> >crtc);
> if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
> (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> - new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
> + new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
> {
> new_conn_state->content_protection =
> DRM_MODE_CONTENT_PROTECTION_DESIRED;
> + return true;
> + }
> +
> + /*
> + * Coming back from UNDESIRED state, CRTC change or re-
> enablement requires
> + * the driver to try CP enable.
> + */
> + if (new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
> + new_conn_state->crtc != old_conn_state->crtc)
> + return true;
>
> /*
>* Nothing to do if content type is unchanged and one of:
> @@ -477,9 +492,9 @@ void drm_hdcp_atomic_check(struct drm_connector
> *connector,
>new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
> if (old_conn_state->hdcp_content_type ==
> new_conn_state->hdcp_content_type)
> - return;
> + return false;
> }
>
> - new_crtc_state->mode_changed = true;
> + return true;
> }
So previously in hdcp_atomic_check we decided if a mode change was required
only after going through two different checks
if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
(old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
and
if (old_hdcp == new_hdcp ||
(old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
Re: [Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Block waiting for GuC reset to complete
On Mon, Apr 10, 2023 at 03:35:09PM -0700, Ashutosh Dixit wrote:
> Instead of erroring out when GuC reset is in progress, block waiting for
> GuC reset to complete which is a more reasonable uapi behavior.
>
> v2: Avoid race between wake_up_all and waiting for wakeup (Rodrigo)
>
> Signed-off-by: Ashutosh Dixit
> ---
> drivers/gpu/drm/i915/i915_hwmon.c | 38 +++
> 1 file changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 9ab8971679fe3..8471a667dfc71 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -51,6 +51,7 @@ struct hwm_drvdata {
> char name[12];
> int gt_n;
> bool reset_in_progress;
> + wait_queue_head_t waitq;
> };
>
> struct i915_hwmon {
> @@ -395,16 +396,41 @@ hwm_power_max_read(struct hwm_drvdata *ddat, long *val)
> static int
> hwm_power_max_write(struct hwm_drvdata *ddat, long val)
> {
> +#define GUC_RESET_TIMEOUT msecs_to_jiffies(2000)
> +
> + int ret = 0, timeout = GUC_RESET_TIMEOUT;
> struct i915_hwmon *hwmon = ddat->hwmon;
> intel_wakeref_t wakeref;
> - int ret = 0;
> + DEFINE_WAIT(wait);
> u32 nval;
>
> - mutex_lock(>hwmon_lock);
> - if (hwmon->ddat.reset_in_progress) {
> - ret = -EAGAIN;
> - goto unlock;
> + /* Block waiting for GuC reset to complete when needed */
> + for (;;) {
> + mutex_lock(>hwmon_lock);
I'm really afraid of how this mutex is handled with the wait queue.
some initial thought it looks like it is trying to reimplement ww_mutex?
all other examples of the wait_queue usages like this or didn't use
locks or had it in a total different flow that I could not correlate.
> +
> + prepare_to_wait(>waitq, , TASK_INTERRUPTIBLE);
> +
> + if (!hwmon->ddat.reset_in_progress)
> + break;
If this breaks we never unlock it?
> +
> + if (signal_pending(current)) {
> + ret = -EINTR;
> + break;
> + }
> +
> + if (!timeout) {
> + ret = -ETIME;
> + break;
> + }
> +
> + mutex_unlock(>hwmon_lock);
do we need to lock the signal pending and timeout as well?
or only wrapping it around the hwmon->ddat access would be
enough?
> +
> + timeout = schedule_timeout(timeout);
> }
> + finish_wait(>waitq, );
> + if (ret)
> + goto unlock;
> +
> wakeref = intel_runtime_pm_get(ddat->uncore->rpm);
>
> /* Disable PL1 limit and verify, because the limit cannot be disabled
> on all platforms */
> @@ -508,6 +534,7 @@ void i915_hwmon_power_max_restore(struct drm_i915_private
> *i915, bool old)
> intel_uncore_rmw(hwmon->ddat.uncore, hwmon->rg.pkg_rapl_limit,
>PKG_PWR_LIM_1_EN, old ? PKG_PWR_LIM_1_EN : 0);
> hwmon->ddat.reset_in_progress = false;
> + wake_up_all(>ddat.waitq);
>
> mutex_unlock(>hwmon_lock);
> }
> @@ -784,6 +811,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> ddat->uncore = >uncore;
> snprintf(ddat->name, sizeof(ddat->name), "i915");
> ddat->gt_n = -1;
> + init_waitqueue_head(>waitq);
>
> for_each_gt(gt, i915, i) {
> ddat_gt = hwmon->ddat_gt + i;
> --
> 2.38.0
>
Re: [Intel-gfx] [PATCH v9 01/10] drm/hdcp: Add drm_hdcp_atomic_check()
Yacoub
> ; linux-ker...@vger.kernel.org
> Subject: [PATCH v9 01/10] drm/hdcp: Add drm_hdcp_atomic_check()
>
> From: Sean Paul
>
> Move the hdcp atomic check from i915 to drm_hdcp so other drivers can use
> it. No functional changes, just cleaned up some of the code when moving it
> over.
>
> Acked-by: Jani Nikula
> Reviewed-by: Rodrigo Vivi
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Sean Paul
> Signed-off-by: Mark Yacoub
>
> ---
> Changes in v2:
> -None
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -None
> Changes in v6:
> -Rebase: move helper from drm_hdcp.c to drm_hdcp_helper.c Changes in
> v7:
> -Removed links to patch from commit msg (Dmitry Baryshkov)
>
> drivers/gpu/drm/display/drm_hdcp_helper.c | 64
> +
> drivers/gpu/drm/i915/display/intel_atomic.c | 4 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 47 ---
> drivers/gpu/drm/i915/display/intel_hdcp.h | 3 -
> include/drm/display/drm_hdcp_helper.h | 3 +
> 5 files changed, 69 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_hdcp_helper.c
> b/drivers/gpu/drm/display/drm_hdcp_helper.c
> index e78999c72bd77..7ca390b3ea106 100644
> --- a/drivers/gpu/drm/display/drm_hdcp_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdcp_helper.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> static inline void drm_hdcp_print_ksv(const u8 *ksv) { @@ -419,3 +420,66
> @@ void drm_hdcp_update_content_protection(struct drm_connector
> *connector,
>dev-
> >mode_config.content_protection_property);
> }
> EXPORT_SYMBOL(drm_hdcp_update_content_protection);
> +
> +/**
> + * drm_hdcp_atomic_check - Helper for drivers to call during
> +connector->atomic_check
> + *
> + * @state: pointer to the atomic state being checked
> + * @connector: drm_connector on which content protection state needs an
> +update
> + *
> + * This function can be used by display drivers to perform an atomic
> +check on the
> + * hdcp state elements. If hdcp state has changed, this function will
> +set
> + * mode_changed on the crtc driving the connector so it can update its
> +hardware
> + * to match the hdcp state.
> + */
> +void drm_hdcp_atomic_check(struct drm_connector *connector,
> +struct drm_atomic_state *state)
> +{
> + struct drm_connector_state *new_conn_state, *old_conn_state;
> + struct drm_crtc_state *new_crtc_state;
> + u64 old_hdcp, new_hdcp;
> +
> + old_conn_state = drm_atomic_get_old_connector_state(state,
> connector);
> + old_hdcp = old_conn_state->content_protection;
> +
> + new_conn_state = drm_atomic_get_new_connector_state(state,
> connector);
> + new_hdcp = new_conn_state->content_protection;
> +
Nit: Why not assign these as right when they are declared we would end up using
less lines
> + if (!new_conn_state->crtc) {
> + /*
> + * If the connector is being disabled with CP enabled, mark it
> + * desired so it's re-enabled when the connector is brought
> back
> + */
> + if (old_hdcp ==
> DRM_MODE_CONTENT_PROTECTION_ENABLED)
> + new_conn_state->content_protection =
> +
> DRM_MODE_CONTENT_PROTECTION_DESIRED;
> + return;
> + }
> +
> + new_crtc_state =
> + drm_atomic_get_new_crtc_state(state, new_conn_state-
> >crtc);
> + if (drm_atomic_crtc_needs_modeset(new_crtc_state) &&
> + (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> + new_hdcp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED))
> + new_conn_state->content_protection =
> + DRM_MODE_CONTENT_PROTECTION_DESIRED;
> +
> + /*
> + * Nothing to do if content type is unchanged and one of:
> + * - state didn't change
> + * - HDCP was activated since the last commit
> + * - attempting to set to desired while already enabled
> + */
> + if (old_hdcp == new_hdcp ||
> + (old_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED &&
> + new_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED) ||
> + (old_hdcp == DRM_MODE_CONTENT_PROTECTION_ENABLED &&
> + new_hdcp == DRM_MODE_CONTENT_PROTECTION_DESIRED)) {
> + if (old_conn_state->hdcp_content_type ==
> + new_conn_state->hdcp_content_type)
> + return;
> + }
> +
> + new_crtc_state->mode_changed = true;
> +}
> +EXPORT_SYMBOL(drm_hdcp_atomic_check);
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index a9a3f3715279d..e9d00b6a63d39 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -32,6 +32,7 @@
> #include
> #include
> #include
> +#include
>
> #include "i915_drv.h"
> #include "i915_reg.h"
> @@ -39,7 +40,6 @@
> #include "intel_cdclk.h"
> #include
[Intel-gfx] [PATCH 0/2] Handle dma fences in dirtyfb ioctl
Currently i915 dirtyfb ioctl is not taking dma fences into account. This works with features like FBC, PSR, DRRS because our gem code is triggering flush again when rendering completes. We are targeting in getting rid of frontbuffer tracking code: Flusing hook from gem code will be removed as well. This patch set is adding dma fence handling into i915 dirtyfb ioctl. Cc: Ville Syrjälä Cc: Maarten Lankhorst Jouni Högander (2): drm/i915: Add new frontbuffer tracking interface to queue flush drm/i915: Handle dma fences in dirtyfb callback drivers/gpu/drm/i915/display/intel_fb.c | 54 +-- .../gpu/drm/i915/display/intel_frontbuffer.c | 33 .../gpu/drm/i915/display/intel_frontbuffer.h | 4 ++ 3 files changed, 88 insertions(+), 3 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH 2/2] drm/i915: Handle dma fences in dirtyfb callback
Take into account dma fences in dirtyfb callback. If there is no
unsignaled dma fences perform flush immediately. If there are
unsignaled dma fences perform invalidate and add callback which will
queue flush when the fence gets signaled.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_fb.c | 54 +++--
1 file changed, 51 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
b/drivers/gpu/drm/i915/display/intel_fb.c
index e5f637897b5e..c8707d331bf1 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -7,6 +7,9 @@
#include
#include
+#include
+#include
+
#include "i915_drv.h"
#include "intel_display.h"
#include "intel_display_types.h"
@@ -1854,6 +1857,20 @@ static int intel_user_framebuffer_create_handle(struct
drm_framebuffer *fb,
return drm_gem_handle_create(file, >base, handle);
}
+struct frontbuffer_fence_cb {
+ struct dma_fence_cb base;
+ struct intel_frontbuffer *front;
+};
+
+static void intel_user_framebuffer_fence_wake(struct dma_fence *dma,
+ struct dma_fence_cb *data)
+{
+ struct frontbuffer_fence_cb *cb = container_of(data, typeof(*cb), base);
+
+ intel_frontbuffer_queue_flush(cb->front);
+ kfree(cb);
+}
+
static int intel_user_framebuffer_dirty(struct drm_framebuffer *fb,
struct drm_file *file,
unsigned int flags, unsigned int color,
@@ -1861,11 +1878,42 @@ static int intel_user_framebuffer_dirty(struct
drm_framebuffer *fb,
unsigned int num_clips)
{
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct intel_frontbuffer *front = to_intel_frontbuffer(fb);
+ struct dma_resv_iter cursor;
+ struct dma_fence *fence;
+ int ret;
+
+ if (dma_resv_test_signaled(obj->base.resv, dma_resv_usage_rw(false))) {
+ i915_gem_object_flush_if_display(obj);
+ intel_frontbuffer_flush(front, ORIGIN_DIRTYFB);
+ return 0;
+ }
- i915_gem_object_flush_if_display(obj);
- intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
+ intel_frontbuffer_invalidate(front, ORIGIN_DIRTYFB);
- return 0;
+ dma_resv_iter_begin(, obj->base.resv, dma_resv_usage_rw(false));
+ dma_resv_for_each_fence_unlocked(, fence) {
+ struct frontbuffer_fence_cb *cb =
+ kmalloc(sizeof(struct frontbuffer_fence_cb),
GFP_KERNEL);
+ if (!cb) {
+ ret = -ENOMEM;
+ break;
+ }
+ cb->front = front;
+
+ ret = dma_fence_add_callback(fence, >base,
+intel_user_framebuffer_fence_wake);
+ if (ret) {
+ intel_user_framebuffer_fence_wake(fence, >base);
+ if (ret == -ENOENT)
+ ret = 0;
+ else
+ break;
+ }
+ }
+ dma_resv_iter_end();
+
+ return ret;
}
static const struct drm_framebuffer_funcs intel_fb_funcs = {
--
2.34.1
[Intel-gfx] [PATCH 1/2] drm/i915: Add new frontbuffer tracking interface to queue flush
We want to wait dma fences in dirtyfb ioctl. As we don't want to make
dirtyfb ioctl as blocking call we need to use
dma_fence_add_callback. Callback used for dma_fence_add_callback is
called from atomic context. Due to this we need to add a new
frontbuffer tracking interface to queue flush.
Signed-off-by: Jouni Högander
---
.../gpu/drm/i915/display/intel_frontbuffer.c | 33 +++
.../gpu/drm/i915/display/intel_frontbuffer.h | 4 +++
2 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 17a7aa8b28c2..799f3f8a5d85 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -202,6 +202,39 @@ void __intel_fb_flush(struct intel_frontbuffer *front,
frontbuffer_flush(i915, frontbuffer_bits, origin);
}
+static void intel_frontbuffer_flush_work(struct work_struct *work)
+{
+ struct intel_frontbuffer *front =
+ container_of(work, struct intel_frontbuffer, flush_work);
+
+ i915_gem_object_flush_if_display(front->obj);
+ intel_frontbuffer_flush(front, ORIGIN_DIRTYFB);
+ intel_frontbuffer_put(front);
+}
+
+/**
+ * intel_frontbuffer_queue_flush - queue flushing frontbuffer object
+ * @front: GEM object to flush
+ *
+ * This function is targeted for our dirty callback for queueing flush when
+ * dma fence is signales
+ */
+void intel_frontbuffer_queue_flush(struct intel_frontbuffer *front)
+{
+ unsigned int frontbuffer_bits;
+
+ if (!front)
+ return;
+
+ frontbuffer_bits = atomic_read(>bits);
+ if (!frontbuffer_bits)
+ return;
+
+ kref_get(>ref);
+ INIT_WORK(>flush_work, intel_frontbuffer_flush_work);
+ schedule_work(>flush_work);
+}
+
static int frontbuffer_active(struct i915_active *ref)
{
struct intel_frontbuffer *front =
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.h
b/drivers/gpu/drm/i915/display/intel_frontbuffer.h
index 3c474ed937fb..11760b5ce9fa 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.h
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.h
@@ -47,6 +47,8 @@ struct intel_frontbuffer {
struct i915_active write;
struct drm_i915_gem_object *obj;
struct rcu_head rcu;
+
+ struct work_struct flush_work;
};
/*
@@ -163,6 +165,8 @@ static inline void intel_frontbuffer_flush(struct
intel_frontbuffer *front,
__intel_fb_flush(front, origin, frontbuffer_bits);
}
+void intel_frontbuffer_queue_flush(struct intel_frontbuffer *front);
+
void intel_frontbuffer_track(struct intel_frontbuffer *old,
struct intel_frontbuffer *new,
unsigned int frontbuffer_bits);
--
2.34.1
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
> From: Alex Williamson
> Sent: Tuesday, April 18, 2023 12:11 PM
>
> On Tue, 18 Apr 2023 03:24:46 +
> "Tian, Kevin" wrote:
>
> > > From: Alex Williamson
> > > Sent: Tuesday, April 18, 2023 4:07 AM
> > >
> > > On Mon, 17 Apr 2023 16:31:56 -0300
> > > Jason Gunthorpe wrote:
> > >
> > > > On Mon, Apr 17, 2023 at 01:01:40PM -0600, Alex Williamson wrote:
> > > > > Yes, it's not trivial, but Jason is now proposing that we consider
> > > > > mixing groups, cdevs, and multiple iommufd_ctxs as invalid. I think
> > > > > this means that regardless of which device calls INFO, there's only
> > > > > one
> > > > > answer (assuming same set of devices opened, all cdev, all within
> same
> > > > > iommufd_ctx). Based on what I explained about my understanding of
> > > INFO2
> > > > > and Jason agreed to, I think the output would be:
> > > > >
> > > > > flags: NOT_RESETABLE | DEV_ID
> > > > > {
> > > > > { valid devA-id, devA-BDF },
> > > > > { valid devC-id, devC-BDF },
> > > > > { valid devD-id, devD-BDF },
> > > > > { invalid dev-id, devE-BDF },
> > > > > }
> > > > >
> > > > > Here devB gets dropped because the kernel understands that devB is
> > > > > unopened, affected, and owned. It's therefore not a blocker for
> > > > > hot-reset.
> > > >
> > > > I don't think we want to drop anything because it makes the API
> > > > ill suited for the debugging purpose.
> > > >
> > > > devb should be returned with an invalid dev_id if I understand your
> > > > example. Maybe it should return with -1 as the dev_id instead of 0, to
> > > > make the debugging a bit better.
> > > >
> > > > Userspace should look at only NOT_RESETTABLE to determine if it
> > > > proceeds or not, and it should use the valid dev_id list to iterate
> > > > over the devices it has open to do the config stuff.
> > >
> > > If an affected device is owned, not opened, and not interfering with
> > > the reset, what is it adding to the API to report it for debugging
> > > purposes? I'm afraid this leads into expanding "invalid dev-id" into an
> >
> > consistent output before and after devB is opened.
>
> In the case where devB is not opened including it only provides
> useless information. In the case where devB is opened it's necessary
> to be reported as an opened, affected device.
>
> > > errno or bitmap of error conditions that the user needs to parse.
> > >
> >
> > Not exactly.
> >
> > If RESETABLE invalid dev_id doesn't matter. The user only use the
> > valid dev_id list to iterate as Jason pointed out.
>
> Yes, but...
>
> > If NOT_RESETTABLE due to devE not assigned to the VM one can
> > easily figure out the fact by simply looking at the list of affected BDFs
> > and the configuration of assigned devices of the VM. Then invalid
> > dev_id also doesn't matter.
>
> Huh?
>
> Given:
>
> flags: NOT_RESETABLE | DEV_ID
> {
> { valid devA-id, devA-BDF },
> { invalid dev-id, devB-BDF },
> { valid devC-id, devC-BDF },
> { valid devD-id, devD-BDF },
> { invalid dev-id, devE-BDF },
> }
>
> How does the user determine that devE is to blame and not devB based on
> BDF? The user cannot rely on sysfs for help, they don't know the IOMMU
> grouping, nor do they know the BDF except as inferred by matching valid
> dev-ids in the above output.
emmm aren't we talking about the 'person' who does diagnostic? This guy
will look at the VM configuration file to know that devA/B/C/D have been
assigned to the VM but not devE.
>
> > If NOT_RESETTABLE while devE is already assigned to the VM then it's
> > indication of mixing groups, cdevs or multiple iommufd_ctxs. Then
> > people should debug with other means/hints to dig out the exact
> > culprit.
>
> I don't know what situation you're trying to explain here. If devE
> were opened within the same iommufd_ctx, this becomes:
It's about a scenario where the mgmt.. stack has assigned all affected
devices to Qemu but Qemu itself messed it up with mixed group/cdev
or multiple iommufd_ctx so hitting the NON_RESETTABLE situation.
>
> flags: RESETABLE | DEV_ID
> {
> { valid devA-id, devA-BDF },
> { invalid dev-id, devB-BDF },
> { valid devC-id, devC-BDF },
> { valid devD-id, devD-BDF },
> { valid devE-id, devE-BDF },
> }
>
> Yes, the user should only be looking at the flag to determine the
> availability of hot-reset, (here's the but) but how is it consistent to
> indicate both that hot-reset is available and include an invalid
> dev-id? The consistency as I propose is that an invalid dev-id is only
> presented with NOT_RESETTABLE for the device blocking hot-reset. In
> the previous case, devB is not blocking reset and reporting an invalid
> dev-id only serves to obfuscate determining the blocking device.
>
> For the cases of affected group-opened devices or separate
> iommufd_ctxs, the user gets invalid dev-ids for anything outside of
> the calling device's iommufd_ctx.
>
> We haven't discussed how it fails when called on a group-opened device
> in a mixed
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX timeout for Type-C
> On Mon, Apr 17, 2023 at 03:25:34PM +0300, Kandpal, Suraj wrote:
> > >
> > > On Mon, Apr 17, 2023 at 02:43:25PM +0300, Kandpal, Suraj wrote:
> > > > > [...]
> > > > > Adding a non-default enable_timeout to the power well descriptor
> > > > > would avoid adding more platform checks:
> > > > >
> > > > > diff --git
> > > > > a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > > > index 6645eb1911d85..8ca1f34be14c2 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > > > @@ -1378,13 +1378,18 @@ static const struct i915_power_well_desc
> xelpd_power_wells_main[] = {
> > > > > I915_PW("AUX_C", _pwdoms_aux_c, .hsw.idx =
> ICL_PW_CTL_IDX_AUX_C),
> > > > > I915_PW("AUX_D", _pwdoms_aux_d, .hsw.idx =
> XELPD_PW_CTL_IDX_AUX_D),
> > > > > I915_PW("AUX_E", _pwdoms_aux_e,
> > > > > .hsw.idx = XELPD_PW_CTL_IDX_AUX_E),
> > > > > + ),
> > > > > + .ops = _aux_power_well_ops,
> > > > > + .fixed_enable_delay = true,
> > > > > + }, {
> > > > > + .instances = _PW_INSTANCES(
> > > > > I915_PW("AUX_USBC1", _pwdoms_aux_usbc1,
> .hsw.idx = TGL_PW_CTL_IDX_AUX_TC1),
> > > > > I915_PW("AUX_USBC2", _pwdoms_aux_usbc2,
> .hsw.idx = TGL_PW_CTL_IDX_AUX_TC2),
> > > > > I915_PW("AUX_USBC3", _pwdoms_aux_usbc3,
> .hsw.idx = TGL_PW_CTL_IDX_AUX_TC3),
> > > > > I915_PW("AUX_USBC4", _pwdoms_aux_usbc4,
> .hsw.idx = TGL_PW_CTL_IDX_AUX_TC4),
> > > > > ),
> > > > > .ops = _aux_power_well_ops,
> > > > > - .fixed_enable_delay = true,
> > > > > + .enable_timeout = 500,
> > > > > }, {
> > > > > .instances = _PW_INSTANCES(
> > > > > I915_PW("AUX_TBT1", _pwdoms_aux_tbt1,
> > > > > .hsw.idx = TGL_PW_CTL_IDX_AUX_TBT1), diff --git
> > > > > a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > > > > index 62bafcbc7937c..930a42c825c36 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > > > > @@ -253,6 +253,7 @@ static void
> > > > > hsw_wait_for_power_well_enable(struct
> > > > > drm_i915_private *dev_priv, {
> > > > > const struct i915_power_well_regs *regs = power_well->desc-
> >ops->regs;
> > > > > int pw_idx =
> > > > > i915_power_well_instance(power_well)->hsw.idx;
> > > > > + int timeout = power_well->desc->enable_timeout ? : 1;
> > > > >
> > > > > /*
> > > > >* For some power wells we're not supposed to watch the
> > > > > status bit for @@ -266,7 +267,7 @@ static void
> > > > > hsw_wait_for_power_well_enable(struct drm_i915_private
> > > > > *dev_priv,
> > > > >
> > > > > /* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
> > > > > if (intel_de_wait_for_set(dev_priv, regs->driver,
> > > > > - HSW_PWR_WELL_CTL_STATE(pw_idx), 1)) {
> > > > > + HSW_PWR_WELL_CTL_STATE(pw_idx),
> > > > > + timeout)) {
> > > > > drm_dbg_kms(_priv->drm, "%s power well enable
> timeout\n",
> > > > > intel_power_well_name(power_well));
> > > > >
> > > > > diff --git
> > > > > a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > > > > b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > > > > index ba7cb977e7c7f..fd5acf68503e1 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > > > > @@ -110,6 +110,8 @@ struct i915_power_well_desc {
> > > > >* Thunderbolt mode.
> > > > >*/
> > > > > u16 is_tc_tbt:1;
> > > > > + /* Enable timeout if bigger than the default 1ms. */
> > > > > + u16 enable_timeout;
> > > > > };
> > > > >
> > > >
> > > > How would we make sure that this timeout only applies to ADLS in
> > > > that case as that's whom the workaround is for?
> > >
> > > The HSD is for display 13 ADL, that is ADL-P/M/N. The ADL-S power
> > > wells are described separately in adls_power_wells.
> >
> > Right sorry meant ADLP so how do we make sure this is enabled only for
> > the required Display version
>
> It is enabled only for those. xelpd_power_wells_main is used by display 13
> platforms.
>
Ohkay got it I can float this version of fix if Jani is okay with this.
Regards,
Suraj Kandpal
> > Regards,
> > Suraj Kandpal
> > >
> > > --Imre
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Tue, 18 Apr 2023 03:24:46 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Tuesday, April 18, 2023 4:07 AM
> >
> > On Mon, 17 Apr 2023 16:31:56 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Mon, Apr 17, 2023 at 01:01:40PM -0600, Alex Williamson wrote:
> > > > Yes, it's not trivial, but Jason is now proposing that we consider
> > > > mixing groups, cdevs, and multiple iommufd_ctxs as invalid. I think
> > > > this means that regardless of which device calls INFO, there's only one
> > > > answer (assuming same set of devices opened, all cdev, all within same
> > > > iommufd_ctx). Based on what I explained about my understanding of
> > INFO2
> > > > and Jason agreed to, I think the output would be:
> > > >
> > > > flags: NOT_RESETABLE | DEV_ID
> > > > {
> > > > { valid devA-id, devA-BDF },
> > > > { valid devC-id, devC-BDF },
> > > > { valid devD-id, devD-BDF },
> > > > { invalid dev-id, devE-BDF },
> > > > }
> > > >
> > > > Here devB gets dropped because the kernel understands that devB is
> > > > unopened, affected, and owned. It's therefore not a blocker for
> > > > hot-reset.
> > >
> > > I don't think we want to drop anything because it makes the API
> > > ill suited for the debugging purpose.
> > >
> > > devb should be returned with an invalid dev_id if I understand your
> > > example. Maybe it should return with -1 as the dev_id instead of 0, to
> > > make the debugging a bit better.
> > >
> > > Userspace should look at only NOT_RESETTABLE to determine if it
> > > proceeds or not, and it should use the valid dev_id list to iterate
> > > over the devices it has open to do the config stuff.
> >
> > If an affected device is owned, not opened, and not interfering with
> > the reset, what is it adding to the API to report it for debugging
> > purposes? I'm afraid this leads into expanding "invalid dev-id" into an
>
> consistent output before and after devB is opened.
In the case where devB is not opened including it only provides
useless information. In the case where devB is opened it's necessary
to be reported as an opened, affected device.
> > errno or bitmap of error conditions that the user needs to parse.
> >
>
> Not exactly.
>
> If RESETABLE invalid dev_id doesn't matter. The user only use the
> valid dev_id list to iterate as Jason pointed out.
Yes, but...
> If NOT_RESETTABLE due to devE not assigned to the VM one can
> easily figure out the fact by simply looking at the list of affected BDFs
> and the configuration of assigned devices of the VM. Then invalid
> dev_id also doesn't matter.
Huh?
Given:
flags: NOT_RESETABLE | DEV_ID
{
{ valid devA-id, devA-BDF },
{ invalid dev-id, devB-BDF },
{ valid devC-id, devC-BDF },
{ valid devD-id, devD-BDF },
{ invalid dev-id, devE-BDF },
}
How does the user determine that devE is to blame and not devB based on
BDF? The user cannot rely on sysfs for help, they don't know the IOMMU
grouping, nor do they know the BDF except as inferred by matching valid
dev-ids in the above output.
> If NOT_RESETTABLE while devE is already assigned to the VM then it's
> indication of mixing groups, cdevs or multiple iommufd_ctxs. Then
> people should debug with other means/hints to dig out the exact
> culprit.
I don't know what situation you're trying to explain here. If devE
were opened within the same iommufd_ctx, this becomes:
flags: RESETABLE | DEV_ID
{
{ valid devA-id, devA-BDF },
{ invalid dev-id, devB-BDF },
{ valid devC-id, devC-BDF },
{ valid devD-id, devD-BDF },
{ valid devE-id, devE-BDF },
}
Yes, the user should only be looking at the flag to determine the
availability of hot-reset, (here's the but) but how is it consistent to
indicate both that hot-reset is available and include an invalid
dev-id? The consistency as I propose is that an invalid dev-id is only
presented with NOT_RESETTABLE for the device blocking hot-reset. In
the previous case, devB is not blocking reset and reporting an invalid
dev-id only serves to obfuscate determining the blocking device.
For the cases of affected group-opened devices or separate
iommufd_ctxs, the user gets invalid dev-ids for anything outside of
the calling device's iommufd_ctx.
We haven't discussed how it fails when called on a group-opened device
in a mixed environment. I'd propose that the INFO ioctl behaves
exactly as it does today, reporting group-id and BDF for each affected
device. However, the hot-reset ioctl itself is not extended to accept
devicefd because there is no proof-of-ownership model for cdevs.
Therefore even if the user could map group-id to devicefd, they get
-EINVAL calling HOT_RESET with a devicefd when the ioctl is called from
a group-opened device. Thanks,
Alex
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
> From: Alex Williamson
> Sent: Tuesday, April 18, 2023 4:07 AM
>
> On Mon, 17 Apr 2023 16:31:56 -0300
> Jason Gunthorpe wrote:
>
> > On Mon, Apr 17, 2023 at 01:01:40PM -0600, Alex Williamson wrote:
> > > Yes, it's not trivial, but Jason is now proposing that we consider
> > > mixing groups, cdevs, and multiple iommufd_ctxs as invalid. I think
> > > this means that regardless of which device calls INFO, there's only one
> > > answer (assuming same set of devices opened, all cdev, all within same
> > > iommufd_ctx). Based on what I explained about my understanding of
> INFO2
> > > and Jason agreed to, I think the output would be:
> > >
> > > flags: NOT_RESETABLE | DEV_ID
> > > {
> > > { valid devA-id, devA-BDF },
> > > { valid devC-id, devC-BDF },
> > > { valid devD-id, devD-BDF },
> > > { invalid dev-id, devE-BDF },
> > > }
> > >
> > > Here devB gets dropped because the kernel understands that devB is
> > > unopened, affected, and owned. It's therefore not a blocker for
> > > hot-reset.
> >
> > I don't think we want to drop anything because it makes the API
> > ill suited for the debugging purpose.
> >
> > devb should be returned with an invalid dev_id if I understand your
> > example. Maybe it should return with -1 as the dev_id instead of 0, to
> > make the debugging a bit better.
> >
> > Userspace should look at only NOT_RESETTABLE to determine if it
> > proceeds or not, and it should use the valid dev_id list to iterate
> > over the devices it has open to do the config stuff.
>
> If an affected device is owned, not opened, and not interfering with
> the reset, what is it adding to the API to report it for debugging
> purposes? I'm afraid this leads into expanding "invalid dev-id" into an
consistent output before and after devB is opened.
> errno or bitmap of error conditions that the user needs to parse.
>
Not exactly.
If RESETABLE invalid dev_id doesn't matter. The user only use the
valid dev_id list to iterate as Jason pointed out.
If NOT_RESETTABLE due to devE not assigned to the VM one can
easily figure out the fact by simply looking at the list of affected BDFs
and the configuration of assigned devices of the VM. Then invalid
dev_id also doesn't matter.
If NOT_RESETTABLE while devE is already assigned to the VM then it's
indication of mixing groups, cdevs or multiple iommufd_ctxs. Then
people should debug with other means/hints to dig out the exact
culprit.
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Check HPD during eDP probe (rev6)
== Series Details ==
Series: drm/i915: Check HPD during eDP probe (rev6)
URL : https://patchwork.freedesktop.org/series/114577/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13021_full -> Patchwork_114577v6_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 8)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114577v6_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_mmap_offset@clear@smem0:
- {shard-dg1}:NOTRUN -> [FAIL][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/shard-dg1-14/igt@gem_mmap_offset@cl...@smem0.html
* igt@kms_vblank@pipe-b-wait-forked-hang:
- {shard-tglu}: [PASS][2] -> [INCOMPLETE][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/shard-tglu-5/igt@kms_vbl...@pipe-b-wait-forked-hang.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/shard-tglu-9/igt@kms_vbl...@pipe-b-wait-forked-hang.html
Known issues
Here are the changes found in Patchwork_114577v6_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][4] -> [FAIL][5] ([i915#2842])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/shard-apl3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/shard-apl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271]) +22 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/shard-glk5/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs.html
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3886])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/shard-glk5/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][8] -> [FAIL][9] ([i915#2346])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/shard-glk2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/shard-glk5/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#658])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/shard-glk5/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
Possible fixes
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-tglu}: [ABORT][11] ([i915#8211]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/shard-tglu-9/igt@gem_barrier_race@remote-requ...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/shard-tglu-8/igt@gem_barrier_race@remote-requ...@rcs0.html
- shard-glk: [ABORT][13] ([i915#8211]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/shard-glk2/igt@gem_barrier_race@remote-requ...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/shard-glk5/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][15] ([i915#6268]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/shard-tglu-2/igt@gem_ctx_e...@basic-nohangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/shard-tglu-7/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [FAIL][17] ([i915#2842]) -> [PASS][18] +1 similar
issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-none@vecs0:
- {shard-rkl}:[FAIL][19] ([i915#2842]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/shard-rkl-1/igt@gem_exec_fair@basic-n...@vecs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/shard-rkl-1/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-apl: [ABORT][21] ([i915#5566]) -> [PASS][22]
[21]:
Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: Provide sysfs for efficient freq
Hi Vinay,
Looks good, just few minor comments below,
[...]
> @@ -267,13 +267,11 @@ static int run_test(struct intel_gt *gt, int test_type)
> }
>
> /*
> - * Set min frequency to RPn so that we can test the whole
> - * range of RPn-RP0. This also turns off efficient freq
> - * usage and makes results more predictable.
> + * Turn off efficient freq so RPn/RP0 ranges are obeyed
>*/
> - err = slpc_set_min_freq(slpc, slpc->min_freq);
> + err = intel_guc_slpc_set_ignore_eff_freq(slpc, true);
> if (err) {
> - pr_err("Unable to update min freq!");
> + pr_err("Unable to turn off efficient freq!");
drm_err()? or gt_err()? As we are here we can use a proper
printing.
How is this change related to the scope of this patch?
> return err;
> }
>
> @@ -358,9 +356,10 @@ static int run_test(struct intel_gt *gt, int test_type)
> break;
> }
>
> - /* Restore min/max frequencies */
> - slpc_set_max_freq(slpc, slpc_max_freq);
> + /* Restore min/max frequencies and efficient flag */
> slpc_set_min_freq(slpc, slpc_min_freq);
> + slpc_set_max_freq(slpc, slpc_max_freq);
> + intel_guc_slpc_set_ignore_eff_freq(slpc, false);
mmhhh... do we care here about the return value?
>
> if (igt_flush_test(gt->i915))
> err = -EIO;
> 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 026d73855f36..b1b70ee3001b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
> @@ -277,6 +277,7 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
>
> slpc->max_freq_softlimit = 0;
> slpc->min_freq_softlimit = 0;
> + slpc->ignore_eff_freq = false;
> slpc->min_is_rpmax = false;
>
> slpc->boost_freq = 0;
> @@ -457,6 +458,31 @@ int intel_guc_slpc_get_max_freq(struct intel_guc_slpc
> *slpc, u32 *val)
> return ret;
> }
>
> +int intel_guc_slpc_set_ignore_eff_freq(struct intel_guc_slpc *slpc, bool val)
> +{
> + struct drm_i915_private *i915 = slpc_to_i915(slpc);
> + intel_wakeref_t wakeref;
> + int ret = 0;
no need to initialize ret here.
> +
> + mutex_lock(>lock);
> + wakeref = intel_runtime_pm_get(>runtime_pm);
> +
> + ret = slpc_set_param(slpc,
> + SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
> + val);
> + if (ret) {
> + guc_probe_error(slpc_to_guc(slpc), "Failed to set efficient
> freq(%d): %pe\n",
> + val, ERR_PTR(ret));
> + goto out;
> + }
> +
> + slpc->ignore_eff_freq = val;
nit that you can ignore: if you put this under else and save
brackets and a goto.
Andi
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
> From: Jason Gunthorpe > Sent: Monday, April 17, 2023 9:39 PM > > On Fri, Apr 14, 2023 at 09:11:30AM +, Tian, Kevin wrote: > > > The only corner case with this option is when a user mixes group > > and cdev usages. iirc you mentioned it's a valid usage to be supported. > > In that case the kernel doesn't have sufficient knowledge to judge > > 'resettable' as it doesn't know which groups are opened by this user. > > IMHO we don't need to support this combination. > > We can say that to use the hot reset API the user must put all their > devices into the same iommufd_ctx and cover 100% of the known use > cases for this. Make sense. > > There are already other situations, like nesting, that do force users > to put everything into one iommufd_ctx. > > No reason to make things harder and more complicated. > > I'm coming to the feeling that we should put no-iommu devices in > iommufd_ctx's as well. They would be an iommufd_access like > mdevs. That would clean up the complications they cause here. This certainly simplifies the matter a lot! > > I suppose we should have done that from the beginning - no-iommu is an > IOMMUFD access, it just uses a crazy /proc based way to learn the > PFNs. Making it a proper access and making a real VFIO ioctl that > calls iommufd_access_pin_pages() and returns the DMA mapped addresses > to userspace would go a long way to making no-iommu work in a logical, > usable, way. > Yes. This would provide a more reliable/clean way to learn PFNs for noiommufd case.
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3)
== Series Details == Series: drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3) URL : https://patchwork.freedesktop.org/series/116510/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13023 -> Patchwork_116510v3 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_116510v3 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_116510v3, 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_116510v3/index.html Participating hosts (38 -> 36) -- Missing(2): bat-mtlp-8 fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_116510v3: ### IGT changes ### Possible regressions * igt@i915_pm_rps@basic-api: - bat-adlp-9: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-adlp-9/igt@i915_pm_...@basic-api.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116510v3/bat-adlp-9/igt@i915_pm_...@basic-api.html - bat-adlp-6: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-adlp-6/igt@i915_pm_...@basic-api.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116510v3/bat-adlp-6/igt@i915_pm_...@basic-api.html - bat-atsm-1: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-atsm-1/igt@i915_pm_...@basic-api.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116510v3/bat-atsm-1/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@slpc: - bat-dg1-7: [PASS][7] -> [DMESG-FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-dg1-7/igt@i915_selftest@l...@slpc.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116510v3/bat-dg1-7/igt@i915_selftest@l...@slpc.html - bat-dg2-11: [PASS][9] -> [DMESG-WARN][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-dg2-11/igt@i915_selftest@l...@slpc.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116510v3/bat-dg2-11/igt@i915_selftest@l...@slpc.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-1: [DMESG-FAIL][11] ([i915#6367]) -> [DMESG-FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-rpls-1/igt@i915_selftest@l...@slpc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116510v3/bat-rpls-1/igt@i915_selftest@l...@slpc.html - bat-adln-1: [DMESG-FAIL][13] ([i915#6997]) -> [DMESG-FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-adln-1/igt@i915_selftest@l...@slpc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116510v3/bat-adln-1/igt@i915_selftest@l...@slpc.html Known issues Here are the changes found in Patchwork_116510v3 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rps@basic-api: - bat-dg1-7: [PASS][15] -> [FAIL][16] ([i915#8308]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-dg1-7/igt@i915_pm_...@basic-api.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116510v3/bat-dg1-7/igt@i915_pm_...@basic-api.html - bat-rpls-2: [PASS][17] -> [FAIL][18] ([i915#8308]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-rpls-2/igt@i915_pm_...@basic-api.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116510v3/bat-rpls-2/igt@i915_pm_...@basic-api.html - bat-rplp-1: [PASS][19] -> [FAIL][20] ([i915#8308]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-rplp-1/igt@i915_pm_...@basic-api.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116510v3/bat-rplp-1/igt@i915_pm_...@basic-api.html - bat-dg1-5: [PASS][21] -> [FAIL][22] ([i915#8308]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-dg1-5/igt@i915_pm_...@basic-api.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116510v3/bat-dg1-5/igt@i915_pm_...@basic-api.html - bat-dg2-9: [PASS][23] -> [FAIL][24] ([i915#8308]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-dg2-9/igt@i915_pm_...@basic-api.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116510v3/bat-dg2-9/igt@i915_pm_...@basic-api.html - bat-adln-1: [PASS][25] -> [FAIL][26] ([i915#8308]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-adln-1/igt@i915_pm_...@basic-api.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116510v3/bat-adln-1/igt@i915_pm_...@basic-api.html - bat-dg2-8:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3)
== Series Details == Series: drm/i915/guc/slpc: Provide sysfs for efficient freq (rev3) URL : https://patchwork.freedesktop.org/series/116510/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Make IRQ reset and postinstall multi-gt aware (rev7)
== Series Details ==
Series: drm/i915: Make IRQ reset and postinstall multi-gt aware (rev7)
URL : https://patchwork.freedesktop.org/series/115465/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13023 -> Patchwork_115465v7
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/index.html
Participating hosts (38 -> 36)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115465v7:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@debugfs_test@basic-hwmon:
- {bat-mtlp-8}: NOTRUN -> [SKIP][1] +40 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html
* igt@i915_selftest@live@gt_mocs:
- {bat-mtlp-8}: NOTRUN -> [ABORT][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
* igt@kms_frontbuffer_tracking@basic:
- {bat-mtlp-8}: NOTRUN -> [DMESG-FAIL][3] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/bat-mtlp-8/igt@kms_frontbuffer_track...@basic.html
* igt@kms_psr@sprite_plane_onoff:
- {bat-mtlp-8}: NOTRUN -> [DMESG-WARN][4] +2 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/bat-mtlp-8/igt@kms_psr@sprite_plane_onoff.html
* igt@prime_vgem@basic-userptr:
- {bat-mtlp-8}: NOTRUN -> [FAIL][5] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/bat-mtlp-8/igt@prime_v...@basic-userptr.html
Known issues
Here are the changes found in Patchwork_115465v7 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3@smem:
- bat-dg2-9: [PASS][6] -> [INCOMPLETE][7] ([i915#7793])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_pm:
- bat-rpls-2: [PASS][8] -> [DMESG-FAIL][9] ([i915#4258])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- bat-dg2-11: [PASS][10] -> [ABORT][11] ([i915#7913] / [i915#7979])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/bat-dg2-11/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@migrate:
- bat-adlp-6: [PASS][12] -> [DMESG-FAIL][13] ([i915#7699])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-adlp-6/igt@i915_selftest@l...@migrate.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/bat-adlp-6/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][14] -> [ABORT][15] ([i915#4983] / [i915#7981])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-rpls-1/igt@i915_selftest@l...@reset.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-apl-guc: [PASS][16] -> [DMESG-WARN][17] ([i915#1982])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/fi-apl-guc/igt@i915_susp...@basic-s2idle-without-i915.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/fi-apl-guc/igt@i915_susp...@basic-s2idle-without-i915.html
Possible fixes
* igt@i915_module_load@load:
- {bat-mtlp-8}: [ABORT][18] ([i915#8361]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-mtlp-8/igt@i915_module_l...@load.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/bat-mtlp-8/igt@i915_module_l...@load.html
Warnings
* igt@i915_selftest@live@slpc:
- bat-rpls-2: [DMESG-FAIL][20] ([i915#6997] / [i915#7913]) ->
[DMESG-FAIL][21] ([i915#6367] / [i915#7913] / [i915#7996])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-rpls-2/igt@i915_selftest@l...@slpc.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/bat-rpls-2/igt@i915_selftest@l...@slpc.html
{name}: This element is suppressed. This means it is ignored when computing
the status
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/4] lib: Make SLPC helper function per GT
On 4/14/2023 1:25 PM, Dixit, Ashutosh wrote:
On Fri, 14 Apr 2023 12:16:37 -0700, Vinay Belgaumkar wrote:
Hi Vinay,
Use default of 0 where GT id is not being used.
v2: Add a helper for GT 0 (Ashutosh)
Signed-off-by: Vinay Belgaumkar
---
lib/igt_pm.c | 36 ++--
lib/igt_pm.h | 3 ++-
2 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 704acf7d..8a30bb3b 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -1329,21 +1329,37 @@ void igt_pm_print_pci_card_runtime_status(void)
}
}
-bool i915_is_slpc_enabled(int fd)
+/**
+ * i915_is_slpc_enabled_gt:
+ * @drm_fd: DRM file descriptor
+ * @gt: GT id
+ * Check if SLPC is enabled on a GT
+ */
+bool i915_is_slpc_enabled_gt(int drm_fd, int gt)
{
- int debugfs_fd = igt_debugfs_dir(fd);
- char buf[4096] = {};
- int len;
+ int debugfs_fd;
+ char buf[256] = {};
Shouldn't this be 4096 as before?
ok.
- igt_require(debugfs_fd != -1);
+ debugfs_fd = igt_debugfs_gt_open(drm_fd, gt, "uc/guc_slpc_info",
O_RDONLY);
+
+ /* if guc_slpc_info not present then return false */
+ if (debugfs_fd < 0)
+ return false;
I think this should just be:
igt_require_fd(debugfs_fd);
Basically we cannot determine if SLPC is enabled or not if say debugfs is
not mounted, so it's not correct return false from here.
yup, makes sense.
+ read(debugfs_fd, buf, sizeof(buf)-1);
- len = igt_debugfs_simple_read(debugfs_fd, "gt/uc/guc_slpc_info", buf,
sizeof(buf));
close(debugfs_fd);
- if (len < 0)
- return false;
- else
- return strstr(buf, "SLPC state: running");
+ return strstr(buf, "SLPC state: running");
+}
+
+/**
+ * i915_is_slpc_enabled:
+ * @drm_fd: DRM file descriptor
+ * Check if SLPC is enabled on GT 0
Hmm, not sure why we are not using the i915_for_each_gt() loop here since
that is the correct way of doing it.
Didn't want to introduce another aggregation here. If SLPC is enabled on
GT0, it is obviously enabled on all other tiles on that device. There is
no per tile SLPC/GuC control.
At the min let's remove the GT 0 in the comment above. This function
doesn't check for GT0, it checks if "slpc is enabled for the device". We
can check only on GT0 if we are certain that checking on GT0 is sufficient,
that is if SLPC is disabled on GT0 it's disabled for the device. But then
someone can ask the question in that case why are we exposing slpc_enabled
for each gt from the kernel rather than at the device level.
In any case for now let's change the above comment to:
"Check if SLPC is enabled" or ""Check if SLPC is enabled for the i915
device".
ok.
With the above comments addressed this is:
Reviewed-by: Ashutosh Dixit
Also, why is igt@i915_pm_rps@basic-api still skipping on DG2/ATSM in
pre-merge CI even after this series?
basic-api is supposed to skip on GuC platforms. It wasn't due to the
test incorrectly reading the SLPC enabled status from debugfs (which is
being fixed here).
Thanks for the review,
Vinay.
Thanks.
--
Ashutosh
+ */
+bool i915_is_slpc_enabled(int drm_fd)
+{
+ return i915_is_slpc_enabled_gt(drm_fd, 0);
}
int igt_pm_get_runtime_suspended_time(struct pci_device *pci_dev)
diff --git a/lib/igt_pm.h b/lib/igt_pm.h
index d0d6d673..448cf42d 100644
--- a/lib/igt_pm.h
+++ b/lib/igt_pm.h
@@ -84,7 +84,8 @@ void igt_pm_set_d3cold_allowed(struct igt_device_card *card,
const char *val);
void igt_pm_setup_pci_card_runtime_pm(struct pci_device *pci_dev);
void igt_pm_restore_pci_card_runtime_pm(void);
void igt_pm_print_pci_card_runtime_status(void);
-bool i915_is_slpc_enabled(int fd);
+bool i915_is_slpc_enabled_gt(int drm_fd, int gt);
+bool i915_is_slpc_enabled(int drm_fd);
int igt_pm_get_runtime_suspended_time(struct pci_device *pci_dev);
int igt_pm_get_runtime_usage(struct pci_device *pci_dev);
--
2.38.1
[Intel-gfx] [PATCH] drm/i915/guc/slpc: Provide sysfs for efficient freq
SLPC enables use of efficient freq at init by default. It is
possible for GuC to request frequencies that are higher than
the 'software' max if user has set it lower than the efficient
level.
Scenarios/tests that require strict fixing of freq below the efficient
level will need to disable it through this interface.
v2: Keep just one interface to toggle sysfs. With this, user will
be completely responsible for toggling efficient frequency if need
be. There will be no implicit disabling when user sets min < RP1 (Ashutosh)
v3: Remove unused label, review comments (Ashutosh)
v4: Toggle efficient freq usage in SLPC selftest and checkpatch fixes
Fixes: 95ccf312a1e4 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency")
Signed-off-by: Vinay Belgaumkar
Reviewed-by: Rodrigo Vivi
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 35
drivers/gpu/drm/i915/gt/selftest_slpc.c | 13 +++---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 40 ++-
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h | 1 +
5 files changed, 72 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 28f27091cd3b..ee2b44f896a2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -451,6 +451,33 @@ static ssize_t punit_req_freq_mhz_show(struct kobject
*kobj,
return sysfs_emit(buff, "%u\n", preq);
}
+static ssize_t slpc_ignore_eff_freq_show(struct kobject *kobj,
+struct kobj_attribute *attr,
+char *buff)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+ struct intel_guc_slpc *slpc = >uc.guc.slpc;
+
+ return sysfs_emit(buff, "%u\n", slpc->ignore_eff_freq);
+}
+
+static ssize_t slpc_ignore_eff_freq_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buff, size_t count)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(kobj, attr->attr.name);
+ struct intel_guc_slpc *slpc = >uc.guc.slpc;
+ int err;
+ u32 val;
+
+ err = kstrtou32(buff, 0, );
+ if (err)
+ return err;
+
+ err = intel_guc_slpc_set_ignore_eff_freq(slpc, val);
+ return err ?: count;
+}
+
struct intel_gt_bool_throttle_attr {
struct attribute attr;
ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
@@ -663,6 +690,8 @@ static struct kobj_attribute attr_media_freq_factor_scale =
INTEL_GT_ATTR_RO(media_RP0_freq_mhz);
INTEL_GT_ATTR_RO(media_RPn_freq_mhz);
+INTEL_GT_ATTR_RW(slpc_ignore_eff_freq);
+
static const struct attribute *media_perf_power_attrs[] = {
_media_freq_factor.attr,
_media_freq_factor_scale.attr,
@@ -744,6 +773,12 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct
kobject *kobj)
if (ret)
gt_warn(gt, "failed to create punit_req_freq_mhz sysfs (%pe)",
ERR_PTR(ret));
+ if (intel_uc_uses_guc_slpc(>uc)) {
+ ret = sysfs_create_file(kobj, _slpc_ignore_eff_freq.attr);
+ if (ret)
+ gt_warn(gt, "failed to create ignore_eff_freq sysfs
(%pe)", ERR_PTR(ret));
+ }
+
if (i915_mmio_reg_valid(intel_gt_perf_limit_reasons_reg(gt))) {
ret = sysfs_create_files(kobj, throttle_reason_attrs);
if (ret)
diff --git a/drivers/gpu/drm/i915/gt/selftest_slpc.c
b/drivers/gpu/drm/i915/gt/selftest_slpc.c
index bd44ce73a504..0de44db34d27 100644
--- a/drivers/gpu/drm/i915/gt/selftest_slpc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_slpc.c
@@ -267,13 +267,11 @@ static int run_test(struct intel_gt *gt, int test_type)
}
/*
-* Set min frequency to RPn so that we can test the whole
-* range of RPn-RP0. This also turns off efficient freq
-* usage and makes results more predictable.
+* Turn off efficient freq so RPn/RP0 ranges are obeyed
*/
- err = slpc_set_min_freq(slpc, slpc->min_freq);
+ err = intel_guc_slpc_set_ignore_eff_freq(slpc, true);
if (err) {
- pr_err("Unable to update min freq!");
+ pr_err("Unable to turn off efficient freq!");
return err;
}
@@ -358,9 +356,10 @@ static int run_test(struct intel_gt *gt, int test_type)
break;
}
- /* Restore min/max frequencies */
- slpc_set_max_freq(slpc, slpc_max_freq);
+ /* Restore min/max frequencies and efficient flag */
slpc_set_min_freq(slpc, slpc_min_freq);
+ slpc_set_max_freq(slpc, slpc_max_freq);
+ intel_guc_slpc_set_ignore_eff_freq(slpc, false);
if (igt_flush_test(gt->i915))
err =
[Intel-gfx] [PATCH v5] drm/i915: Make IRQ reset and postinstall multi-gt aware
In multi-gt systems IRQs need to be reset and enabled per GT.
This might add some redundancy when handling interrupts for
engines that might not exist in every tile, but helps to keep the
code cleaner and more understandable.
Signed-off-by: Andi Shyti
Cc: Tvrtko Ursulin
Reviewed-by: Matt Roper
---
Hi,
thanks Matt for the review.
Andi
Changelog
=
v4 -> v5
- Another little cosmetic on the variable declaration. Go back
to v3 but using "_priv->uncore" instead of
"to_gt(dev_priv)->uncore", which is much cleaner.
- Add Matt's r-b.
v3 -> v4
- do not change the initial gt and uncore initialization in
order to gain a better understanding at a glance of the
purpose of all the local variables.
v2 -> v3
- keep GUnit irq initialization out of the for_each_gt() loop as
the media GT doesn't have a GUnit.
v1 -> v2
- improve description in the commit log.
drivers/gpu/drm/i915/i915_irq.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
drivers/gpu/drm/i915/i915_irq.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index dea1a117f3fa1..eead067f18c7a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2856,12 +2856,15 @@ static void gen11_irq_reset(struct drm_i915_private
*dev_priv)
static void dg1_irq_reset(struct drm_i915_private *dev_priv)
{
- struct intel_gt *gt = to_gt(dev_priv);
- struct intel_uncore *uncore = gt->uncore;
+ struct intel_uncore *uncore = _priv->uncore;
+ struct intel_gt *gt;
+ unsigned int i;
dg1_master_intr_disable(dev_priv->uncore.regs);
- gen11_gt_irq_reset(gt);
+ for_each_gt(gt, dev_priv, i)
+ gen11_gt_irq_reset(gt);
+
gen11_display_irq_reset(dev_priv);
GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
@@ -3643,11 +3646,13 @@ static void gen11_irq_postinstall(struct
drm_i915_private *dev_priv)
static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
{
- struct intel_gt *gt = to_gt(dev_priv);
- struct intel_uncore *uncore = gt->uncore;
+ struct intel_uncore *uncore = _priv->uncore;
u32 gu_misc_masked = GEN11_GU_MISC_GSE;
+ struct intel_gt *gt;
+ unsigned int i;
- gen11_gt_irq_postinstall(gt);
+ for_each_gt(gt, dev_priv, i)
+ gen11_gt_irq_postinstall(gt);
GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
--
2.39.2
Re: [Intel-gfx] [PATCH v3] drm/i915/guc/slpc: Provide sysfs for efficient freq
On 4/14/2023 4:49 PM, Dixit, Ashutosh wrote:
On Fri, 14 Apr 2023 15:34:15 -0700, Vinay Belgaumkar wrote:
@@ -457,6 +458,34 @@ int intel_guc_slpc_get_max_freq(struct intel_guc_slpc
*slpc, u32 *val)
return ret;
}
+int intel_guc_slpc_set_ignore_eff_freq(struct intel_guc_slpc *slpc, bool val)
+{
+ struct drm_i915_private *i915 = slpc_to_i915(slpc);
+ intel_wakeref_t wakeref;
+ int ret = 0;
+
+ /* Need a lock now since waitboost can be modifying min as well */
Delete comment.
ok.
+ mutex_lock(>lock);
Actually, don't need the lock itself now so delete the lock.
Or, maybe the lock prevents the race if userspace writes to the sysfs when
GuC reset is going on so let's retain the lock. But the comment is wrong.
yup, ok.
+ wakeref = intel_runtime_pm_get(>runtime_pm);
+
+ /* Ignore efficient freq if lower min freq is requested */
Delete comment, it's wrong.
ok.
+ ret = slpc_set_param(slpc,
+SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
+val);
+ if (ret) {
+ guc_probe_error(slpc_to_guc(slpc), "Failed to set efficient
freq(%d): %pe\n",
+ val, ERR_PTR(ret));
+ goto out;
+ }
+
+ slpc->ignore_eff_freq = val;
+
This extra line can also be deleted.
ok.
+out:
+ intel_runtime_pm_put(>runtime_pm, wakeref);
+ mutex_unlock(>lock);
+ return ret;
+}
+
/**
* intel_guc_slpc_set_min_freq() - Set min frequency limit for SLPC.
* @slpc: pointer to intel_guc_slpc.
@@ -482,16 +511,6 @@ int intel_guc_slpc_set_min_freq(struct intel_guc_slpc
*slpc, u32 val)
mutex_lock(>lock);
wakeref = intel_runtime_pm_get(>runtime_pm);
- /* Ignore efficient freq if lower min freq is requested */
- ret = slpc_set_param(slpc,
-SLPC_PARAM_IGNORE_EFFICIENT_FREQUENCY,
-val < slpc->rp1_freq);
- if (ret) {
- guc_probe_error(slpc_to_guc(slpc), "Failed to toggle efficient freq:
%pe\n",
- ERR_PTR(ret));
- goto out;
- }
-
Great, thanks!
After taking care of the above, and seems there are also a couple of
checkpatch errors, this is:
Reviewed-by: Ashutosh Dixit
Thanks,
Vinay.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Make IRQ reset and postinstall multi-gt aware (rev6)
== Series Details ==
Series: drm/i915: Make IRQ reset and postinstall multi-gt aware (rev6)
URL : https://patchwork.freedesktop.org/series/115465/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13023 -> Patchwork_115465v6
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/index.html
Participating hosts (38 -> 36)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115465v6:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@debugfs_test@basic-hwmon:
- {bat-mtlp-8}: NOTRUN -> [SKIP][1] +40 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html
* igt@i915_selftest@live@gt_mocs:
- {bat-mtlp-8}: NOTRUN -> [ABORT][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
* igt@kms_frontbuffer_tracking@basic:
- {bat-mtlp-8}: NOTRUN -> [DMESG-FAIL][3] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/bat-mtlp-8/igt@kms_frontbuffer_track...@basic.html
* igt@kms_psr@sprite_plane_onoff:
- {bat-mtlp-8}: NOTRUN -> [DMESG-WARN][4] +2 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/bat-mtlp-8/igt@kms_psr@sprite_plane_onoff.html
* igt@prime_vgem@basic-userptr:
- {bat-mtlp-8}: NOTRUN -> [FAIL][5] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/bat-mtlp-8/igt@prime_v...@basic-userptr.html
Known issues
Here are the changes found in Patchwork_115465v6 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_lrc:
- bat-rplp-1: [PASS][6] -> [INCOMPLETE][7] ([i915#4983] /
[i915#7609] / [i915#7913])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-rplp-1/igt@i915_selftest@live@gt_lrc.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/bat-rplp-1/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@gt_pm:
- bat-rpls-2: [PASS][8] -> [DMESG-FAIL][9] ([i915#4258])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][10] -> [DMESG-WARN][11] ([i915#7699])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/bat-dg2-11/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@reset:
- bat-rpls-2: [PASS][12] -> [ABORT][13] ([i915#4983] / [i915#7913])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-rpls-2/igt@i915_selftest@l...@reset.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/bat-rpls-2/igt@i915_selftest@l...@reset.html
- bat-rpls-1: [PASS][14] -> [ABORT][15] ([i915#4983])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-rpls-1/igt@i915_selftest@l...@reset.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-1:
- bat-dg2-8: [PASS][16] -> [FAIL][17] ([i915#7932])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html
* igt@kms_pipe_crc_basic@read-crc:
- bat-dg2-11: NOTRUN -> [SKIP][18] ([i915#5354]) +1 similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/bat-dg2-11/igt@kms_pipe_crc_ba...@read-crc.html
Possible fixes
* igt@i915_module_load@load:
- {bat-mtlp-8}: [ABORT][19] ([i915#8361]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-mtlp-8/igt@i915_module_l...@load.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v6/bat-mtlp-8/igt@i915_module_l...@load.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[i915#4983]:
Re: [Intel-gfx] [PATCH v4] drm/i915: Make IRQ reset and postinstall multi-gt aware
On Tue, Apr 18, 2023 at 12:34:43AM +0200, Andi Shyti wrote:
> In multi-gt systems IRQs need to be reset and enabled per GT.
>
> This might add some redundancy when handling interrupts for
> engines that might not exist in every tile, but helps to keep the
> code cleaner and more understandable.
>
> Signed-off-by: Andi Shyti
> Cc: Tvrtko Ursulin
> ---
> Hi,
>
> The rsults of this patch are more than promising as we are able
> to have MTL booting and executing basic tests.(*)
>
> Thank you Daniele and Matt for the valuable exchange of opinions.
>
> Amdo
>
> (*) https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/index.html?
>
> Changelog
> =
> v3 -> v4
> - do not change the initial gt and uncore initialization in
>order to gain a better understanding at a glance of the
>purpose of all the local variables.
I think I may not have explained myself well on the previous feedback
here. What I meant was that rather than doing
struct intel_uncore *uncore = to_gt(dev_priv)->uncore;
as you were in the previous rev, you can simply do
struct intel_uncore *uncore = dev_priv->uncore;
because gt0's uncore pointer is always the same as dev_priv's. Since
we're using the uncore variable to access display-specific gunit stuff I
figured that was slightly more clear to the reader to take the
device-level pointer rather than grabbing it from any of the GTs.
That said, using "uncore = gt->uncore" as you have in this version
doesn't cause any real problems since the actual registers being
accessed are sgunit registers and thus don't get translated by GSI
offset. You still wind up at the same sgunit register offsets on MTL no
matter which GT you grab an uncore from, and display/gunit isn't
something that PVC even needs to worry about. So
Reviewed-by: Matt Roper
> v2 -> v3
> - keep GUnit irq initialization out of the for_each_gt() loop as
>the media GT doesn't have a GUnit.
> v1 -> v2
> - improve description in the commit log.
>
> drivers/gpu/drm/i915/i915_irq.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index dea1a117f3fa1..c027fd5189b85 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2858,10 +2858,13 @@ static void dg1_irq_reset(struct drm_i915_private
> *dev_priv)
> {
> struct intel_gt *gt = to_gt(dev_priv);
> struct intel_uncore *uncore = gt->uncore;
> + unsigned int i;
>
> dg1_master_intr_disable(dev_priv->uncore.regs);
>
> - gen11_gt_irq_reset(gt);
> + for_each_gt(gt, dev_priv, i)
> + gen11_gt_irq_reset(gt);
> +
> gen11_display_irq_reset(dev_priv);
>
> GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
> @@ -3646,8 +3649,10 @@ static void dg1_irq_postinstall(struct
> drm_i915_private *dev_priv)
> struct intel_gt *gt = to_gt(dev_priv);
> struct intel_uncore *uncore = gt->uncore;
> u32 gu_misc_masked = GEN11_GU_MISC_GSE;
> + unsigned int i;
>
> - gen11_gt_irq_postinstall(gt);
> + for_each_gt(gt, dev_priv, i)
> + gen11_gt_irq_postinstall(gt);
>
> GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
>
> --
> 2.39.2
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Increase AUX timeout for Type-C (rev3)
== Series Details ==
Series: drm/i915/display: Increase AUX timeout for Type-C (rev3)
URL : https://patchwork.freedesktop.org/series/116010/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13020_full -> Patchwork_116010v3_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 8)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_116010v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2846])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-glk9/igt@gem_exec_f...@basic-deadline.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/shard-glk5/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-apl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-apl: [PASS][7] -> [DMESG-FAIL][8] ([i915#5334])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-apl7/igt@i915_selftest@live@gt_heartbeat.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/shard-apl7/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/shard-glk6/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices@smem:
- {shard-tglu}: [ABORT][10] ([i915#7975]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-tglu-10/igt@gem_exec_suspend@basic-s4-devi...@smem.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/shard-tglu-9/igt@gem_exec_suspend@basic-s4-devi...@smem.html
* igt@i915_pm_rpm@modeset-lpsp-stress-no-wait:
- {shard-rkl}:[SKIP][12] ([i915#1397]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-rkl-6/igt@i915_pm_...@modeset-lpsp-stress-no-wait.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/shard-rkl-7/igt@i915_pm_...@modeset-lpsp-stress-no-wait.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [FAIL][14] ([i915#2346]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-glk3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/shard-glk7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.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
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#110723]: https://bugs.freedesktop.org/show_bug.cgi?id=110723
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[fdo#112054]: https://bugs.freedesktop.org/show_bug.cgi?id=112054
[fdo#112283]: https://bugs.freedesktop.org/show_bug.cgi?id=112283
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1257]: https://gitlab.freedesktop.org/drm/intel/issues/1257
[i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
[i915#1825]: https://gitlab.freedesktop.org/drm/intel/issues/1825
[i915#1839]: https://gitlab.freedesktop.org/drm/intel/issues/1839
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#2434]:
Re: [Intel-gfx] [PATCH] drm/i915/display: Return correct err code for bpc < 0
Hi Ville, Could you suggest how to handle the intel_dp_link_compute_config() when the max_bpp is returned as 0, currently it just exits the loop and returns a -EINVAL and this triggers the DSC path. While we should be completely failing the modeset and encoder_config in this case instead of trying DSC, correct? Manasi On Thu, Apr 13, 2023 at 8:23 AM Manasi Navare wrote: > > On Tue, Apr 11, 2023 at 10:22 PM Ville Syrjälä > wrote: > > > > On Tue, Apr 11, 2023 at 05:07:01PM -0700, Manasi Navare wrote: > > > On Tue, Apr 11, 2023 at 10:42 AM Ville Syrjälä > > > wrote: > > > > > > > > On Tue, Apr 11, 2023 at 05:34:08PM +, Manasi Navare wrote: > > > > > In the function intel_dp_max_bpp(), currently if bpc < 0 in case of > > > > > error, > > > > > we return 0 instead of returning an err code of -EINVAL. > > > > > This throws off the logic in the calling function. > > > > > > > > What logic? The caller doesn't expect to get an error. > > > > > > If this returns a 0, we end up using limits.max_bpp = 0 and in > > > intel_dp_compute_link_config_wide(), > > > since max_bpp is 0, it exits this for loop: > > > > > > for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) and > > > returns > > > -EINVAL which then wrongly goes to enable DSC even when link BW is > > > sufficient without DSC. > > > > And how woud max_bpp<0 prevent that? > > > > The real problem seems to be that the DSC code totally > > ignores bpp limits. > > Hi Ville, > > So I see a few concerns/questions: > - Why is the Max bpp value 0 in intel_dp_max_bpp, is that a valid case > and how should our link configurations handle that case when max_bpp > is 0? > - This is happening in a bug I am looking at with HDMI PCON, @Ankit > Nautiyal have we ever seen something similar where max_bpp for HDMi > PCON > is returned 0? > - I dont think its a problem with DSC code, but rather > intel_dp_compute_link_config() outer for loop where we vary > from max_bpp to min_bpp and see if any bpp works with available link > bw, how should we handle this when max_bpp = 0 if you are saying thats > a valid case? > - In this patch if I return -EINVAL instead of 0, then atleast the > entire encoder_config will fail and that will fail the modeset, since > it assumes max_bpp cannot be 0 > > Could you please help answer above concerns and how to handle max bpp > = 0 case if that is valid? This patch is simply making that invalid > resulting into modeset failure > > Manasi > > > > -- > > Ville Syrjälä > > Intel
[Intel-gfx] [PATCH v4] drm/i915: Make IRQ reset and postinstall multi-gt aware
In multi-gt systems IRQs need to be reset and enabled per GT.
This might add some redundancy when handling interrupts for
engines that might not exist in every tile, but helps to keep the
code cleaner and more understandable.
Signed-off-by: Andi Shyti
Cc: Tvrtko Ursulin
---
Hi,
The rsults of this patch are more than promising as we are able
to have MTL booting and executing basic tests.(*)
Thank you Daniele and Matt for the valuable exchange of opinions.
Amdo
(*) https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/index.html?
Changelog
=
v3 -> v4
- do not change the initial gt and uncore initialization in
order to gain a better understanding at a glance of the
purpose of all the local variables.
v2 -> v3
- keep GUnit irq initialization out of the for_each_gt() loop as
the media GT doesn't have a GUnit.
v1 -> v2
- improve description in the commit log.
drivers/gpu/drm/i915/i915_irq.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index dea1a117f3fa1..c027fd5189b85 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2858,10 +2858,13 @@ static void dg1_irq_reset(struct drm_i915_private
*dev_priv)
{
struct intel_gt *gt = to_gt(dev_priv);
struct intel_uncore *uncore = gt->uncore;
+ unsigned int i;
dg1_master_intr_disable(dev_priv->uncore.regs);
- gen11_gt_irq_reset(gt);
+ for_each_gt(gt, dev_priv, i)
+ gen11_gt_irq_reset(gt);
+
gen11_display_irq_reset(dev_priv);
GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
@@ -3646,8 +3649,10 @@ static void dg1_irq_postinstall(struct drm_i915_private
*dev_priv)
struct intel_gt *gt = to_gt(dev_priv);
struct intel_uncore *uncore = gt->uncore;
u32 gu_misc_masked = GEN11_GU_MISC_GSE;
+ unsigned int i;
- gen11_gt_irq_postinstall(gt);
+ for_each_gt(gt, dev_priv, i)
+ gen11_gt_irq_postinstall(gt);
GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
--
2.39.2
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display/dp: 128/132b LT requirement (rev2)
== Series Details ==
Series: drm/i915/display/dp: 128/132b LT requirement (rev2)
URL : https://patchwork.freedesktop.org/series/116562/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13020_full -> Patchwork_116562v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 7)
--
Missing(1): shard-rkl0
Known issues
Here are the changes found in Patchwork_116562v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2846])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-glk9/igt@gem_exec_f...@basic-deadline.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/shard-glk9/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-apl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/shard-apl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [PASS][7] -> [ABORT][8] ([i915#5566])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-apl3/igt@gen9_exec_pa...@allowed-all.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/shard-apl3/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#2346])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices@smem:
- {shard-tglu}: [ABORT][11] ([i915#7975]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-tglu-10/igt@gem_exec_suspend@basic-s4-devi...@smem.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/shard-tglu-7/igt@gem_exec_suspend@basic-s4-devi...@smem.html
* igt@i915_pm_rpm@dpms-lpsp:
- {shard-rkl}:[SKIP][13] ([i915#1397]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-rkl-4/igt@i915_pm_...@dpms-lpsp.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/shard-rkl-7/igt@i915_pm_...@dpms-lpsp.html
* igt@i915_pm_rpm@modeset-non-lpsp-stress:
- {shard-dg1}:[SKIP][15] ([i915#1397]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-dg1-14/igt@i915_pm_...@modeset-non-lpsp-stress.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/shard-dg1-17/igt@i915_pm_...@modeset-non-lpsp-stress.html
* igt@kms_cursor_legacy@forked-bo@pipe-b:
- {shard-rkl}:[INCOMPLETE][17] ([i915#8011]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-rkl-7/igt@kms_cursor_legacy@forked...@pipe-b.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/shard-rkl-6/igt@kms_cursor_legacy@forked...@pipe-b.html
* igt@kms_cursor_legacy@single-move@pipe-b:
- {shard-dg1}:[INCOMPLETE][19] ([i915#8011] / [i915#8347]) ->
[PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-dg1-14/igt@kms_cursor_legacy@single-m...@pipe-b.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/shard-dg1-17/igt@kms_cursor_legacy@single-m...@pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#110723]: https://bugs.freedesktop.org/show_bug.cgi?id=110723
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#111827]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Replace kmap() with kmap_local_page() (rev3)
== Series Details ==
Series: drm/i915: Replace kmap() with kmap_local_page() (rev3)
URL : https://patchwork.freedesktop.org/series/107277/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13020_full -> Patchwork_107277v3_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 8)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_107277v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_barrier_race@remote-request@rcs0:
- shard-glk: [PASS][1] -> [ABORT][2] ([i915#8211])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-glk3/igt@gem_barrier_race@remote-requ...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/shard-glk9/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2846])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-glk9/igt@gem_exec_f...@basic-deadline.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/shard-glk6/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][7] -> [FAIL][8] ([i915#2346]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/shard-apl2/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/shard-glk5/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
* igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
- shard-apl: [PASS][10] -> [ABORT][11] ([i915#180])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-apl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/shard-apl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
* igt@sysfs_heartbeat_interval@mixed@vcs0:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#1731])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-glk2/igt@sysfs_heartbeat_interval@mi...@vcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/shard-glk2/igt@sysfs_heartbeat_interval@mi...@vcs0.html
Possible fixes
* igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][14] ([i915#2842]) -> [PASS][15] +1 similar
issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-rkl-2/igt@gem_exec_fair@basic-n...@vcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/shard-rkl-6/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_suspend@basic-s4-devices@smem:
- {shard-tglu}: [ABORT][16] ([i915#7975]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-tglu-10/igt@gem_exec_suspend@basic-s4-devi...@smem.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/shard-tglu-7/igt@gem_exec_suspend@basic-s4-devi...@smem.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [FAIL][18] ([i915#2346]) -> [PASS][19] +1 similar
issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-glk3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/shard-glk9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@forked-bo@pipe-b:
- {shard-rkl}:[INCOMPLETE][20] ([i915#8011]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-rkl-7/igt@kms_cursor_legacy@forked...@pipe-b.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/shard-rkl-2/igt@kms_cursor_legacy@forked...@pipe-b.html
* igt@kms_cursor_legacy@single-move@pipe-b:
- {shard-dg1}:[INCOMPLETE][22] ([i915#8011] / [i915#8347]) ->
[PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-dg1-14/igt@kms_cursor_legacy@single-m...@pipe-b.html
[23]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Initialize dkl_phy spin lock from display code path (rev2)
== Series Details == Series: drm/i915: Initialize dkl_phy spin lock from display code path (rev2) URL : https://patchwork.freedesktop.org/series/116325/ State : success == Summary == CI Bug Log - changes from CI_DRM_13022 -> Patchwork_116325v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/index.html Participating hosts (37 -> 37) -- Additional (1): fi-kbl-soraka Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116325v2 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][3] ([i915#1886]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@late_gt_pm: - fi-bsw-nick:[PASS][4] -> [ABORT][5] ([i915#6217]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/fi-bsw-nick/igt@i915_selftest@live@late_gt_pm.html * igt@i915_selftest@live@reset: - bat-rpls-1: NOTRUN -> [ABORT][6] ([i915#4983]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271]) +16 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html * igt@kms_pipe_crc_basic@read-crc: - bat-adlp-9: NOTRUN -> [SKIP][8] ([i915#3546]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [DMESG-FAIL][9] ([i915#5334]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_pm: - bat-rpls-2: [DMESG-FAIL][11] ([i915#4258]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/bat-rpls-2/igt@i915_selftest@live@gt_pm.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/bat-rpls-2/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@requests: - bat-rpls-1: [ABORT][13] ([i915#7911]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/bat-rpls-1/igt@i915_selftest@l...@requests.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/bat-rpls-1/igt@i915_selftest@l...@requests.html [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#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546 [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258 [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#6217]: https://gitlab.freedesktop.org/drm/intel/issues/6217 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 Build changes - * Linux: CI_DRM_13022 -> Patchwork_116325v2 CI-20190529: 20190529 CI_DRM_13022: acfc88011228f839fcd32798637e419e429304bd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7258: ad2eb276eda849b7a7985229009a816c7608186c @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116325v2: acfc88011228f839fcd32798637e419e429304bd @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 6bf77caf7c79 drm/i915: Initialize dkl_phy spin lock from display code path == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/index.html
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: Consider multi-gt at all places (rev3)
== Series Details == Series: drm/i915/gt: Consider multi-gt at all places (rev3) URL : https://patchwork.freedesktop.org/series/115302/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/115302/revisions/3/mbox/ not applied Applying: drm/i915/gt: Consider multi-gt at all places error: corrupt patch at line 83 error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915/gt: Consider multi-gt at all places 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". Build failed, no error log produced
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pps: use intel_de_rmw() for panel unlock
== Series Details ==
Series: drm/i915/pps: use intel_de_rmw() for panel unlock
URL : https://patchwork.freedesktop.org/series/116560/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13020_full -> Patchwork_116560v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 7)
--
Missing(1): shard-rkl0
Known issues
Here are the changes found in Patchwork_116560v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2846])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-glk9/igt@gem_exec_f...@basic-deadline.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/shard-glk5/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-apl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-apl: [PASS][7] -> [ABORT][8] ([i915#5566])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-apl2/igt@gen9_exec_pa...@allowed-single.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/shard-apl2/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_pm_rps@reset:
- shard-snb: [PASS][9] -> [DMESG-FAIL][10] ([i915#8319])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-snb4/igt@i915_pm_...@reset.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/shard-snb5/igt@i915_pm_...@reset.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl: [PASS][11] -> [FAIL][12] ([i915#2346])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/shard-apl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_dither@fb-8bpc-vs-panel-6bpc@pipe-a-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/shard-glk2/igt@kms_dither@fb-8bpc-vs-panel-6...@pipe-a-hdmi-a-1.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@c-dp1:
- shard-apl: [PASS][14] -> [FAIL][15] ([i915#79])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-apl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-dp1.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/shard-apl1/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-dp1.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- shard-snb: NOTRUN -> [SKIP][16] ([fdo#109271])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/shard-snb7/igt@kms_pipe_crc_ba...@suspend-read-crc.html
Possible fixes
* igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][17] ([i915#7742]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-rkl-3/igt@drm_fdinfo@most-busy-check-...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/shard-rkl-7/igt@drm_fdinfo@most-busy-check-...@rcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-apl: [FAIL][19] ([i915#2846]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-apl2/igt@gem_exec_f...@basic-deadline.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/shard-apl2/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: [FAIL][21] ([i915#2842]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-glk7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/shard-glk5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][23] ([i915#2842]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/shard-rkl-1/igt@gem_exec_fair@basic-p...@rcs0.html
[24]:
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Mon, 17 Apr 2023 16:31:56 -0300
Jason Gunthorpe wrote:
> On Mon, Apr 17, 2023 at 01:01:40PM -0600, Alex Williamson wrote:
> > Yes, it's not trivial, but Jason is now proposing that we consider
> > mixing groups, cdevs, and multiple iommufd_ctxs as invalid. I think
> > this means that regardless of which device calls INFO, there's only one
> > answer (assuming same set of devices opened, all cdev, all within same
> > iommufd_ctx). Based on what I explained about my understanding of INFO2
> > and Jason agreed to, I think the output would be:
> >
> > flags: NOT_RESETABLE | DEV_ID
> > {
> > { valid devA-id, devA-BDF },
> > { valid devC-id, devC-BDF },
> > { valid devD-id, devD-BDF },
> > { invalid dev-id, devE-BDF },
> > }
> >
> > Here devB gets dropped because the kernel understands that devB is
> > unopened, affected, and owned. It's therefore not a blocker for
> > hot-reset.
>
> I don't think we want to drop anything because it makes the API
> ill suited for the debugging purpose.
>
> devb should be returned with an invalid dev_id if I understand your
> example. Maybe it should return with -1 as the dev_id instead of 0, to
> make the debugging a bit better.
>
> Userspace should look at only NOT_RESETTABLE to determine if it
> proceeds or not, and it should use the valid dev_id list to iterate
> over the devices it has open to do the config stuff.
If an affected device is owned, not opened, and not interfering with
the reset, what is it adding to the API to report it for debugging
purposes? I'm afraid this leads into expanding "invalid dev-id" into an
errno or bitmap of error conditions that the user needs to parse.
> > OTOH, devE is unopened, affected, and un-owned, and we
> > previously agreed against the opportunistic un-opened/un-owned loophole.
>
> NOT_RESETABLE should be returned in this case, yes.
>
> If we want to enable userspace to use the loophole it should be an
> additional flag. RESETABLE_FOR_NOW or something
Ugh, please no. It's always a volatile result, but a volatile result
that relies on device state outside the scope or control of the user is
not even worthwhile imo. Thanks,
Alex
[Intel-gfx] ✓ Fi.CI.BAT: success for fdinfo alternative memory stats proposal
== Series Details == Series: fdinfo alternative memory stats proposal URL : https://patchwork.freedesktop.org/series/116581/ State : success == Summary == CI Bug Log - changes from CI_DRM_13022 -> Patchwork_116581v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/index.html Participating hosts (37 -> 36) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116581v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: NOTRUN -> [ABORT][1] ([i915#6687] / [i915#7978]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_pm_rps@basic-api: - bat-dg2-11: [PASS][2] -> [FAIL][3] ([i915#8308]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/bat-dg2-11/igt@i915_pm_...@basic-api.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/bat-dg2-11/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@reset: - bat-rpls-2: [PASS][4] -> [ABORT][5] ([i915#4983] / [i915#7913]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/bat-rpls-2/igt@i915_selftest@l...@reset.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/bat-rpls-2/igt@i915_selftest@l...@reset.html * igt@i915_selftest@live@slpc: - bat-rpls-1: NOTRUN -> [DMESG-FAIL][6] ([i915#6367] / [i915#7996]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@i915_suspend@basic-s3-without-i915: - fi-apl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/fi-apl-guc/igt@i915_susp...@basic-s3-without-i915.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/fi-apl-guc/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_pipe_crc_basic@read-crc: - bat-adlp-9: NOTRUN -> [SKIP][9] ([i915#3546]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [DMESG-FAIL][10] ([i915#5334]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@requests: - bat-rpls-1: [ABORT][12] ([i915#7911]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/bat-rpls-1/igt@i915_selftest@l...@requests.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/bat-rpls-1/igt@i915_selftest@l...@requests.html [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546 [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#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 [i915#8308]: https://gitlab.freedesktop.org/drm/intel/issues/8308 Build changes - * Linux: CI_DRM_13022 -> Patchwork_116581v1 CI-20190529: 20190529 CI_DRM_13022: acfc88011228f839fcd32798637e419e429304bd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7258: ad2eb276eda849b7a7985229009a816c7608186c @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116581v1: acfc88011228f839fcd32798637e419e429304bd @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 69b9be235707 drm/i915: Implement fdinfo memory stats printing f36f579a1ae5 drm/msm: Add basic memory stats 8eabef51ce99 drm: Add simple fdinfo memory helpers 972a11ccf5ad drm: Add fdinfo memory stats 67129cbc4c47 drm/i915: Use the fdinfo helper 3df872e57aca drm: Add common fdinfo helper == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for fdinfo alternative memory stats proposal
== Series Details == Series: fdinfo alternative memory stats proposal URL : https://patchwork.freedesktop.org/series/116581/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for fdinfo alternative memory stats proposal
== Series Details ==
Series: fdinfo alternative memory stats proposal
URL : https://patchwork.freedesktop.org/series/116581/
State : warning
== Summary ==
Error: dim checkpatch failed
92bb2d834df8 drm: Add common fdinfo helper
1e36b9258ec6 drm/i915: Use the fdinfo helper
368bec1f61d6 drm: Add fdinfo memory stats
-:59: WARNING:STATIC_CONST_CHAR_ARRAY: char * array declaration might be better
as static const
#59: FILE: drivers/gpu/drm/drm_file.c:878:
+ const char *units[] = {"", " KiB", " MiB"};
total: 0 errors, 1 warnings, 0 checks, 127 lines checked
31ff5fcacf6d drm: Add simple fdinfo memory helpers
-:40: WARNING:STATIC_CONST_CHAR_ARRAY: char * array declaration might be better
as static const
#40: FILE: drivers/gpu/drm/drm_file.c:896:
+ static char *region[] = {
-:80: CHECK:LINE_SPACING: Please don't use multiple blank lines
#80: FILE: include/drm/drm_file.h:391:
+
+
total: 0 errors, 1 warnings, 1 checks, 63 lines checked
6db9de4ab15b drm/msm: Add basic memory stats
dd1f311a52b7 drm/i915: Implement fdinfo memory stats printing
-:69: ERROR:CODE_INDENT: code indent should use tabs where possible
#69: FILE: drivers/gpu/drm/i915/i915_drm_client.c:138:
+struct intel_memory_region *mr;$
-:69: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#69: FILE: drivers/gpu/drm/i915/i915_drm_client.c:138:
+struct intel_memory_region *mr;$
-:71: ERROR:CODE_INDENT: code indent should use tabs where possible
#71: FILE: drivers/gpu/drm/i915/i915_drm_client.c:140:
+enum intel_region_id id;$
-:71: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#71: FILE: drivers/gpu/drm/i915/i915_drm_client.c:140:
+enum intel_region_id id;$
-:102: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#102: FILE: drivers/gpu/drm/i915/i915_drm_client.c:171:
+ else if (i915_gem_object_is_shrinkable(obj) &&
+ obj->mm.madv == I915_MADV_DONTNEED)
total: 2 errors, 2 warnings, 1 checks, 152 lines checked
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Add support to dump GEM stats to fdinfo.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> Documentation/gpu/drm-usage-stats.rst | 12 +++
> drivers/gpu/drm/drm_file.c| 52 +++
> include/drm/drm_drv.h | 7
> include/drm/drm_file.h| 8 +
> 4 files changed, 79 insertions(+)
>
> diff --git a/Documentation/gpu/drm-usage-stats.rst
> b/Documentation/gpu/drm-usage-stats.rst
> index 2ab32c40e93c..8273a41b2fb0 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -21,6 +21,7 @@ File format specification
>
> - File shall contain one key value pair per one line of text.
> - Colon character (`:`) must be used to delimit keys and values.
> +- Caret (`^`) is also a reserved character.
this doesn't solve the problem that led me to drm-$CATEGORY-memory... ;-)
(also, it is IMHO rather ugly)
BR,
-R
> - All keys shall be prefixed with `drm-`.
> - Whitespace between the delimiter and first non-whitespace character shall
> be
>ignored when parsing.
> @@ -105,6 +106,17 @@ object belong to this client, in the respective memory
> region.
> Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
> indicating kibi- or mebi-bytes.
>
> +- drm-memory-^size: [KiB|MiB]
> +- drm-memory-^shared: [KiB|MiB]
> +- drm-memory-^resident: [KiB|MiB]
> +- drm-memory-^purgeable: [KiB|MiB]
> +- drm-memory-^active: [KiB|MiB]
> +
> +Resident category is identical to the drm-memory- key and two should be
> +mutually exclusive.
> +
> +TODO more description text...
> +
> - drm-cycles-
>
> Engine identifier string must be the same as the one specified in the
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 37b4f76a5191..e202f79e816d 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -42,6 +42,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "drm_crtc_internal.h"
> @@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev, struct
> drm_pending_event *e)
> }
> EXPORT_SYMBOL(drm_send_event);
>
> +static void
> +print_stat(struct drm_printer *p, const char *stat, const char *region, u64
> sz)
> +{
> + const char *units[] = {"", " KiB", " MiB"};
> + unsigned int u;
> +
> + if (sz == ~0ull) /* Not supported by the driver. */
> + return;
> +
> + for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> + if (sz < SZ_1K)
> + break;
> + sz = div_u64(sz, SZ_1K);
> + }
> +
> + drm_printf(p, "drm-memory-%s^%s:\t%llu%s\n",
> + region, stat, sz, units[u]);
> +}
> +
> +static void print_memory_stats(struct drm_printer *p, struct drm_file *file)
> +{
> + struct drm_device *dev = file->minor->dev;
> + struct drm_fdinfo_memory_stat *stats;
> + unsigned int num, i;
> + char **regions;
> +
> + regions = dev->driver->query_fdinfo_memory_regions(dev, );
> +
> + stats = kcalloc(num, sizeof(*stats), GFP_KERNEL);
> + if (!stats)
> + return;
> +
> + dev->driver->query_fdinfo_memory_stats(file, stats);
> +
> + for (i = 0; i < num; i++) {
> + if (!regions[i]) /* Allow sparse name arrays. */
> + continue;
> +
> + print_stat(p, "size", regions[i], stats[i].size);
> + print_stat(p, "shared", regions[i], stats[i].shared);
> + print_stat(p, "resident", regions[i], stats[i].resident);
> + print_stat(p, "purgeable", regions[i], stats[i].purgeable);
> + print_stat(p, "active", regions[i], stats[i].active);
> + }
> +
> + kfree(stats);
> +}
> +
> /**
> * drm_show_fdinfo - helper for drm file fops
> * @seq_file: output stream
> @@ -900,6 +949,9 @@ void drm_show_fdinfo(struct seq_file *m, struct file *f)
>
> if (dev->driver->show_fdinfo)
> dev->driver->show_fdinfo(, file);
> +
> + if (dev->driver->query_fdinfo_memory_regions)
> + print_memory_stats(, file);
> }
> EXPORT_SYMBOL(drm_show_fdinfo);
>
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 89e2706cac56..ccc1cd98d2aa 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -35,6 +35,7 @@
> #include
>
> struct drm_file;
> +struct drm_fdinfo_memory_stat;
> struct drm_gem_object;
> struct drm_master;
> struct drm_minor;
> @@ -408,6 +409,12 @@ struct drm_driver {
> */
> void (*show_fdinfo)(struct drm_printer *p, struct drm_file *f);
>
> + char ** (*query_fdinfo_memory_regions)(struct drm_device *dev,
> + unsigned int *num);
> +
> + void (*query_fdinfo_memory_stats)(struct drm_file *f,
> +
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/display: split out load detect to a separate file
== Series Details == Series: series starting with [1/2] drm/i915/display: split out load detect to a separate file URL : https://patchwork.freedesktop.org/series/116579/ State : success == Summary == CI Bug Log - changes from CI_DRM_13022 -> Patchwork_116579v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116579v1/index.html Participating hosts (37 -> 37) -- Additional (1): fi-kbl-soraka Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116579v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: NOTRUN -> [ABORT][1] ([i915#6687] / [i915#7978]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116579v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116579v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116579v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][4] ([i915#1886]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116579v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@slpc: - bat-rpls-1: NOTRUN -> [DMESG-FAIL][5] ([i915#6367]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116579v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271]) +16 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116579v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html * igt@kms_pipe_crc_basic@read-crc: - bat-adlp-9: NOTRUN -> [SKIP][7] ([i915#3546]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116579v1/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [DMESG-FAIL][8] ([i915#5334]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116579v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@requests: - bat-rpls-1: [ABORT][10] ([i915#7911]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/bat-rpls-1/igt@i915_selftest@l...@requests.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116579v1/bat-rpls-1/igt@i915_selftest@l...@requests.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-2: [DMESG-FAIL][12] ([i915#6367] / [i915#7913] / [i915#7996]) -> [DMESG-FAIL][13] ([i915#6997] / [i915#7913]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/bat-rpls-2/igt@i915_selftest@l...@slpc.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116579v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html [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#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 Build changes - * Linux: CI_DRM_13022 -> Patchwork_116579v1 CI-20190529: 20190529 CI_DRM_13022: acfc88011228f839fcd32798637e419e429304bd @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7258: ad2eb276eda849b7a7985229009a816c7608186c @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116579v1: acfc88011228f839fcd32798637e419e429304bd @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 1eb227cc883a drm/i915/display: throw out struct intel_load_detect_pipe 373411cc96f3 drm/i915/display: split out load detect to a separate file == Logs == For more details see:
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Mon, Apr 17, 2023 at 01:01:40PM -0600, Alex Williamson wrote:
> Yes, it's not trivial, but Jason is now proposing that we consider
> mixing groups, cdevs, and multiple iommufd_ctxs as invalid. I think
> this means that regardless of which device calls INFO, there's only one
> answer (assuming same set of devices opened, all cdev, all within same
> iommufd_ctx). Based on what I explained about my understanding of INFO2
> and Jason agreed to, I think the output would be:
>
> flags: NOT_RESETABLE | DEV_ID
> {
> { valid devA-id, devA-BDF },
> { valid devC-id, devC-BDF },
> { valid devD-id, devD-BDF },
> { invalid dev-id, devE-BDF },
> }
>
> Here devB gets dropped because the kernel understands that devB is
> unopened, affected, and owned. It's therefore not a blocker for
> hot-reset.
I don't think we want to drop anything because it makes the API
ill suited for the debugging purpose.
devb should be returned with an invalid dev_id if I understand your
example. Maybe it should return with -1 as the dev_id instead of 0, to
make the debugging a bit better.
Userspace should look at only NOT_RESETTABLE to determine if it
proceeds or not, and it should use the valid dev_id list to iterate
over the devices it has open to do the config stuff.
> OTOH, devE is unopened, affected, and un-owned, and we
> previously agreed against the opportunistic un-opened/un-owned loophole.
NOT_RESETABLE should be returned in this case, yes.
If we want to enable userspace to use the loophole it should be an
additional flag. RESETABLE_FOR_NOW or something
> I think we're narrowing in on an interface that isn't as arbitrary. If
> we assume the restrictions that Jason proposes, then cdev is exclusively
> a kernel determined reset availability model
Yes, I think this is probably best looking forward.
> where I'd agree that
> passing device-fds as a proof of ownership is pointless. The group
> interface would therefore remain exclusively a proof-of-ownership
> model since we have no incentive to extend it to kernel-determined
> given the limited use case of all affected devices managed by the same
> vfio container.
Yes
> Moot, but there's actually enough information there to infer IOMMU
> groups for each device, but we probably can't prove that would always
> be the case. If we adopt Jason's proposal though, I don't see that we
> need either a group-id or BDF capability, the BDF is only for debug
> reporting. However, there is a new burden on the kernel to identify
> the affected, un-owned devices for that report.
Yes and yes
Jason
Re: [Intel-gfx] [PATCH v7 5/8] drm/i915/pxp: Add ARB session creation and cleanup
On Mon, 2023-04-17 at 12:15 -0700, Ceraolo Spurio, Daniele wrote:
> On 4/17/2023 11:21 AM, Teres Alexis, Alan Previn wrote:
> > On Mon, 2023-04-10 at 10:14 -0700, Ceraolo Spurio, Daniele wrote:
> > > > @@ -354,8 +368,14 @@ int intel_pxp_start(struct intel_pxp *pxp)
> > > > if (!intel_pxp_is_enabled(pxp))
> > > > return -ENODEV;
> > > >
> > > > - if (wait_for(pxp_component_bound(pxp), 250))
> > > > - return -ENXIO;
> > > > + if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
> > > > + /* Use a larger 1 second timeout considering all the
> > > > dependencies. */
> > > > + if
> > > > (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 1000))
> > > > + return -ENXIO;
> > > This needs a comment to explain that we expect userspace to retry later
> > > if we return -ENXIO and therefore the timeout is smaller that what would
> > > be required to guarantee that the init can complete. It also needs an
> > > ack from the userspace drivers for this behavior.
> > >
> > alan: I agree with a requirement to comment this down. However, i believe
> > its better
> > to put this int the UAPI header file comment-documentation since it applies
> > to both
> > current MTL as well as previous ADL cases (this is not new behavior being
> > introduced
> > in MTL but it is fixing of the spec of existing behavior).
> > That said, your feedback is already being addressed by patch #6 but i will
> > ammend
> > patch #6 to add the detail you highlighted WRT ~"timeout is not larger than
> > the completion-guarantee...".
>
> Can you move that comment update for the context getparam from the next
> patch to this one? that way it's all nicely self-contained in this patch.
alan: sounds good - will do
alan:snip
> > > >
> > > > -#define GSC_REPLY_LATENCY_MS 200
> > > > +#define GSC_REPLY_LATENCY_MS 210
> > > why move from 200 to 210? not a problem, I just want to understand why
> > > this is required.
> > >
> > > Daniele
> > alan: so 200 is based on the fw spec - and from real testing i observed the
> > occasional highs touching ~185ms.
> > However, the spec gives this number as the expected max time the firmware
> > is going to take to process the request
> > and post a reply. Therefore it doesn't include the additional overhead for
> > the request creation, emision,
> > submission via guc and the completion pipeline completion indication. All
> > of these contribute additional layers
> > of possible delay. Since arb-session creation and invalidation are not
> > common events,
> > I believe a slightly wider overhead of 10 milisec will not hurt.
>
> Agreed. Can you add a comment? something like "Max FW response time is
> 200ms, to which we add 10ms to account for overhead".
alan: will do and thanks for the conditional rb. will fix these accordingly.
> With those 2 nits addressed:
>
> Reviewed-by: Daniele Ceraolo Spurio
>
> Daniele
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/display: split out load detect to a separate file
== Series Details == Series: series starting with [1/2] drm/i915/display: split out load detect to a separate file URL : https://patchwork.freedesktop.org/series/116579/ 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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/display: split out load detect to a separate file
== Series Details == Series: series starting with [1/2] drm/i915/display: split out load detect to a separate file URL : https://patchwork.freedesktop.org/series/116579/ State : warning == Summary == Error: dim checkpatch failed 5ea7255afab9 drm/i915/display: split out load detect to a separate file Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:320: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #320: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 555 lines checked 708fc7707084 drm/i915/display: throw out struct intel_load_detect_pipe
Re: [Intel-gfx] [PATCH v7 5/8] drm/i915/pxp: Add ARB session creation and cleanup
On 4/17/2023 11:21 AM, Teres Alexis, Alan Previn wrote:
On Mon, 2023-04-10 at 10:14 -0700, Ceraolo Spurio, Daniele wrote:
alan:snip
@@ -354,8 +368,14 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
- if (wait_for(pxp_component_bound(pxp), 250))
- return -ENXIO;
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
+ /* Use a larger 1 second timeout considering all the
dependencies. */
+ if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 1000))
+ return -ENXIO;
This needs a comment to explain that we expect userspace to retry later
if we return -ENXIO and therefore the timeout is smaller that what would
be required to guarantee that the init can complete. It also needs an
ack from the userspace drivers for this behavior.
alan: I agree with a requirement to comment this down. However, i believe its
better
to put this int the UAPI header file comment-documentation since it applies to
both
current MTL as well as previous ADL cases (this is not new behavior being
introduced
in MTL but it is fixing of the spec of existing behavior).
That said, your feedback is already being addressed by patch #6 but i will
ammend
patch #6 to add the detail you highlighted WRT ~"timeout is not larger than the
completion-guarantee...".
Can you move that comment update for the context getparam from the next
patch to this one? that way it's all nicely self-contained in this patch.
alan:snip
+fw_err_to_string(u32 type)
+{
+ switch (type) {
+ case PXP_STATUS_ERROR_API_VERSION:
+ return "ERR_API_VERSION";
+ case PXP_STATUS_NOT_READY:
+ return "ERR_NOT_READY";
+ case PXP_STATUS_PLATFCONFIG_KF1_NOVERIF:
+ case PXP_STATUS_PLATFCONFIG_KF1_BAD:
+ return "ERR_PLATFORM_CONFIG";
+ default:
+ break;
+ }
+ return NULL;
+}
+
There is a lot of replication for this error handling, I'm wondering if
it's worth adding a common function to handle this. Something like:
intel_pxp_header_error(u32 header, const char *op, u32 id)
{
if (is_fw_err_platform_config(header.status)) {
drm_info_once(>drm,
"PXP %s-%d failed due to BIOS/SOC:0x%08x:%s\n",
op, id, header.status,
fw_err_to_string(header.status));
} else {
drm_dbg(>drm, "PXP %s-%d failed 0x%08x:%st:\n",
op, id, header.status,
fw_err_to_string(header.status));
drm_dbg(>drm, " cmd-detail:
ID=[0x%08x],API-Ver-[0x%08x]\n",
header.command_id, header.api_version);
}
}
Not a blocker.
alan: Thanks - i will have to address as a stand alone patch since i have to
think about moving this to a comment helper layer (common to both ADL-mei-comp
and MTL-gsccs)
while potentially have different set of error codes that can mean different
reporting levels
(i.e. notice once coz its a platform limit vs always err out if its runtime
related).
Once this series gets merged it will be easier to work on that patch (which
would require both
backends to be present in the baseline).
alan:snip
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
@@ -10,14 +10,18 @@
struct intel_pxp;
-#define GSC_REPLY_LATENCY_MS 200
+#define GSC_REPLY_LATENCY_MS 210
why move from 200 to 210? not a problem, I just want to understand why
this is required.
Daniele
alan: so 200 is based on the fw spec - and from real testing i observed the
occasional highs touching ~185ms.
However, the spec gives this number as the expected max time the firmware is
going to take to process the request
and post a reply. Therefore it doesn't include the additional overhead for the
request creation, emision,
submission via guc and the completion pipeline completion indication. All of
these contribute additional layers
of possible delay. Since arb-session creation and invalidation are not common
events,
I believe a slightly wider overhead of 10 milisec will not hurt.
Agreed. Can you add a comment? something like "Max FW response time is
200ms, to which we add 10ms to account for overhead".
With those 2 nits addressed:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Make IRQ reset and postinstall multi-gt aware (rev5)
== Series Details ==
Series: drm/i915: Make IRQ reset and postinstall multi-gt aware (rev5)
URL : https://patchwork.freedesktop.org/series/115465/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13022 -> Patchwork_115465v5
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/index.html
Participating hosts (37 -> 37)
--
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_115465v5:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@debugfs_test@basic-hwmon:
- {bat-mtlp-8}: NOTRUN -> [SKIP][1] +40 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html
* igt@i915_selftest@live@gt_mocs:
- {bat-mtlp-8}: NOTRUN -> [ABORT][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
* igt@kms_frontbuffer_tracking@basic:
- {bat-mtlp-8}: NOTRUN -> [DMESG-FAIL][3] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/bat-mtlp-8/igt@kms_frontbuffer_track...@basic.html
* igt@kms_psr@sprite_plane_onoff:
- {bat-mtlp-8}: NOTRUN -> [DMESG-WARN][4] +2 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/bat-mtlp-8/igt@kms_psr@sprite_plane_onoff.html
* igt@prime_vgem@basic-userptr:
- {bat-mtlp-8}: NOTRUN -> [FAIL][5] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/bat-mtlp-8/igt@prime_v...@basic-userptr.html
Known issues
Here are the changes found in Patchwork_115465v5 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_pm_rps@basic-api:
- bat-dg2-11: [PASS][8] -> [FAIL][9] ([i915#8308])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/bat-dg2-11/igt@i915_pm_...@basic-api.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/bat-dg2-11/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [PASS][10] -> [ABORT][11] ([i915#7913])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][12] ([i915#1886])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@reset:
- bat-rpls-1: NOTRUN -> [ABORT][13] ([i915#4983] / [i915#7981])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-cfl-8700k: [PASS][14] -> [ABORT][15] ([i915#8213] / [i915#8299])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/fi-cfl-8700k/igt@i915_susp...@basic-s2idle-without-i915.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/fi-cfl-8700k/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][16] ([fdo#109271]) +16 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-1:
- bat-dg2-8: [PASS][17] -> [FAIL][18] ([i915#7932])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v5/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
Possible fixes
* igt@i915_module_load@load:
- {bat-mtlp-8}: [ABORT][19] ([i915#8361]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/bat-mtlp-8/igt@i915_module_l...@load.html
[20]:
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Mon, 17 Apr 2023 04:20:27 + "Liu, Yi L" wrote: > > From: Alex Williamson > > Sent: Saturday, April 15, 2023 1:11 AM > > > > On Fri, 14 Apr 2023 11:38:24 + > > "Liu, Yi L" wrote: > > > > > > From: Tian, Kevin > > > > Sent: Friday, April 14, 2023 5:12 PM > > > > > > > > > From: Alex Williamson > > > > > Sent: Friday, April 14, 2023 2:07 AM > > > > > > > > > > We had already iterated a proposal where the group-id is replaced with > > > > > a dev-id in the existing ioctl and a flag indicates when the return > > > > > value is a dev-id vs group-id. This had a gap that userspace cannot > > > > > determine if a reset is available given this information since > > > > > un-owned > > > > > devices report an invalid dev-id and userspace can't know if it has > > > > > implicit ownership. > > > > > > > > > > > > > > It seems cleaner to me though that we would could still re-use INFO in > > > > > a similar way, simply defining a new flag bit which is valid only in > > > > > the case of returning dev-ids and indicates if the reset is available. > > > > > Therefore in one ioctl, userspace knows if hot-reset is available > > > > > (based on a kernel determination) and can pull valid dev-ids from the > > > > > > > > > > > Need to confirm the meaning of hot-reset available flag. I think it > > > should at least meet below two conditions to set this flag. Although > > > it may not mean hot-reset is for sure to succeed. (but should be > > > a high chance). > > > > > > 1) dev_set is resettable (all affected device are in dev_set) > > > 2) affected device are owned by the current user > > > > Per thread with Kevin, ownership can't always be known by the kernel. > > Beyond the group vs cdev discussion there, isn't it also possible > > (though perhaps not recommended) that a user can have multiple iommufd > > ctxs? So I think 2) becomes "ownership of the affected dev-set can be > > inferred from the iommufd_ctx of the calling device", iow, the > > null-array calling model is available and the flag is redefined to > > match. Reset may still be available via the proof-of-ownership model. > > Yes, if there are multiple iommufd ctxs, this shall fall back to use > the proof-of-ownership model. > > > > > > Also, we need to has assumption that below two cases are rare > > > if user encounters it, it just bad luck for them. I think the existing > > > _INFO and hot-reset already has such assumption. So cdev mode > > > can adopt it as well. > > > > > > a) physical topology change (e.g. new devices plugged to affected slot) > > > b) an affected device is unbound from vfio > > > > Yes, these are sufficiently rare that we can't do much about them. > > > > > > So the kernel needs to compare the group id between devices with > > > > valid dev-ids and devices with invalid dev-ids to decide the implicit > > > > ownership. For noiommu device which has no group_id when > > > > VFIO_GROUP is off then it's resettable only if having a valid dev_id. > > > > > > In cdev mode, noiommu device doesn't have dev_id as it is not > > > bound to valid iommufd. So if VFIO_GROUP is off, we may never > > > allow hot-reset for noiommu devices. But we don't want to have > > > regression with noiommu devices. Perhaps we may define the usage > > > of the resettable flag like this: > > > 1) if it is set, user does not need to own all the affected devices as > > > some of them may have been owned implicitly. Kernel should have > > > checked it. > > > 2) if the flag is not set, that means user needs to check ownership > > > by itself. It needs to own all the affected devices. If not, don't > > >do hot-reset. > > > > Exactly, the flag essentially indicates that the null-array approach is > > available, lack of the flag indicates proof-of-ownership is required. > > > > > This way we can still make noiommu devices support hot-reset > > > just like VFIO_GROUP is on. Because noiommu devices have fake > > > groups, such groups are all singleton. So checking all affected > > > devices are opened by user is just same as check all affected > > > groups. > > > > Yep. > > > > > > The only corner case with this option is when a user mixes group > > > > and cdev usages. iirc you mentioned it's a valid usage to be supported. > > > > In that case the kernel doesn't have sufficient knowledge to judge > > > > 'resettable' as it doesn't know which groups are opened by this user. > > > > > > > > Not sure whether we can leave it in a ugly way so INFO may not tell > > > > 'resettable' accurately in that weird scenario. > > > > > > This seems not easy to support. If above scenario is allowed there can be > > > three cases that returns invalid dev_id. > > > 1) devices not opened by user but owned implicitly > > > > The cdev approach has a hard time with this in general, it has no way to > > represent unopened devices. so any case where the nature of an unopened > > device block reset on the dev-set is rather
Re: [Intel-gfx] [PATCH v7 5/8] drm/i915/pxp: Add ARB session creation and cleanup
On Mon, 2023-04-10 at 10:14 -0700, Ceraolo Spurio, Daniele wrote:
>
>
>
alan:snip
> > @@ -354,8 +368,14 @@ int intel_pxp_start(struct intel_pxp *pxp)
> > if (!intel_pxp_is_enabled(pxp))
> > return -ENODEV;
> >
> > - if (wait_for(pxp_component_bound(pxp), 250))
> > - return -ENXIO;
> > + if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
> > + /* Use a larger 1 second timeout considering all the
> > dependencies. */
> > + if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 1000))
> > + return -ENXIO;
>
> This needs a comment to explain that we expect userspace to retry later
> if we return -ENXIO and therefore the timeout is smaller that what would
> be required to guarantee that the init can complete. It also needs an
> ack from the userspace drivers for this behavior.
>
alan: I agree with a requirement to comment this down. However, i believe its
better
to put this int the UAPI header file comment-documentation since it applies to
both
current MTL as well as previous ADL cases (this is not new behavior being
introduced
in MTL but it is fixing of the spec of existing behavior).
That said, your feedback is already being addressed by patch #6 but i will
ammend
patch #6 to add the detail you highlighted WRT ~"timeout is not larger than the
completion-guarantee...".
>
alan:snip
> > +fw_err_to_string(u32 type)
> > +{
> > + switch (type) {
> > + case PXP_STATUS_ERROR_API_VERSION:
> > + return "ERR_API_VERSION";
> > + case PXP_STATUS_NOT_READY:
> > + return "ERR_NOT_READY";
> > + case PXP_STATUS_PLATFCONFIG_KF1_NOVERIF:
> > + case PXP_STATUS_PLATFCONFIG_KF1_BAD:
> > + return "ERR_PLATFORM_CONFIG";
> > + default:
> > + break;
> > + }
> > + return NULL;
> > +}
> > +
>
> There is a lot of replication for this error handling, I'm wondering if
> it's worth adding a common function to handle this. Something like:
>
> intel_pxp_header_error(u32 header, const char *op, u32 id)
> {
> if (is_fw_err_platform_config(header.status)) {
> drm_info_once(>drm,
> "PXP %s-%d failed due to BIOS/SOC:0x%08x:%s\n",
> op, id, header.status,
> fw_err_to_string(header.status));
> } else {
> drm_dbg(>drm, "PXP %s-%d failed 0x%08x:%st:\n",
> op, id, header.status,
> fw_err_to_string(header.status));
> drm_dbg(>drm, " cmd-detail:
> ID=[0x%08x],API-Ver-[0x%08x]\n",
> header.command_id, header.api_version);
> }
> }
>
>
> Not a blocker.
alan: Thanks - i will have to address as a stand alone patch since i have to
think about moving this to a comment helper layer (common to both ADL-mei-comp
and MTL-gsccs)
while potentially have different set of error codes that can mean different
reporting levels
(i.e. notice once coz its a platform limit vs always err out if its runtime
related).
Once this series gets merged it will be easier to work on that patch (which
would require both
backends to be present in the baseline).
> >
alan:snip
> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
> > @@ -10,14 +10,18 @@
> >
> > struct intel_pxp;
> >
> > -#define GSC_REPLY_LATENCY_MS 200
> > +#define GSC_REPLY_LATENCY_MS 210
>
> why move from 200 to 210? not a problem, I just want to understand why
> this is required.
>
> Daniele
alan: so 200 is based on the fw spec - and from real testing i observed the
occasional highs touching ~185ms.
However, the spec gives this number as the expected max time the firmware is
going to take to process the request
and post a reply. Therefore it doesn't include the additional overhead for the
request creation, emision,
submission via guc and the completion pipeline completion indication. All of
these contribute additional layers
of possible delay. Since arb-session creation and invalidation are not common
events,
I believe a slightly wider overhead of 10 milisec will not hurt.
Re: [Intel-gfx] [PATCH] drm/i915/gt: Consider multi-gt at all places
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Wednesday, April 5, 2023 2:01 PM
> To: Upadhyay, Tejas ; Intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/gt: Consider multi-gt at all places
>
>
> On 05/04/2023 07:56, Upadhyay, Tejas wrote:
> >>> -int igt_live_test_end(struct igt_live_test *t)
> >>> +int igt_live_test_end(struct igt_live_test *t, struct intel_gt *gt)
> >>>{
> >>> - struct drm_i915_private *i915 = t->i915;
> >>> + struct drm_i915_private *i915 = gt->i915;
> >>> struct intel_engine_cs *engine;
> >>> enum intel_engine_id id;
> >>>
> >>> @@ -57,7 +57,7 @@ int igt_live_test_end(struct igt_live_test *t)
> >>> return -EIO;
> >>> }
> >>>
> >>> - for_each_engine(engine, to_gt(i915), id) {
> >>> + for_each_engine(engine, gt, id) {
> >>> if (t->reset_engine[id] ==
> >>> i915_reset_engine_count(>gpu_error, engine))
> >>> continue;
> >>> diff --git a/drivers/gpu/drm/i915/selftests/igt_live_test.h
> >>> b/drivers/gpu/drm/i915/selftests/igt_live_test.h
> >>> index 36ed42736c52..209b0548c603 100644
> >>> --- a/drivers/gpu/drm/i915/selftests/igt_live_test.h
> >>> +++ b/drivers/gpu/drm/i915/selftests/igt_live_test.h
> >>> @@ -27,9 +27,9 @@ struct igt_live_test {
> >>> * e.g. if the GPU was reset.
> >>> */
> >>>int igt_live_test_begin(struct igt_live_test *t,
> >>> - struct drm_i915_private *i915,
> >>> + struct intel_gt *gt,
> >>> const char *func,
> >>> const char *name);
> >>> -int igt_live_test_end(struct igt_live_test *t);
> >>> +int igt_live_test_end(struct igt_live_test *t, struct intel_gt
> >>> +*gt);
> >>
> >> Back in the day the plan was that live selftests are device focused
> >> and then we also have intel_gt_live_subtests, which are obviously GT
> >> focused. So in that sense adding a single GT parameter to
> >> igt_live_test_begin isn't something I immediately understand.
> >>
> >> Could you explain in one or two practical examples what is not
> >> working properly and how is this patch fixing it?
> >
> > For example you are running test "live_all_engines(void *arg)",
> >
> > -- Below test begin, will reset counters for primary GT - Tile0 -- err
> > = igt_live_test_begin(, to_gt(i915), __func__, "");
> > if (err)
> > goto out_free;
> >
> > --- Now we loop for all engines, note here for MTL vcs, vecs engines are not
> on primary GT or tile 0,
> > So counters did not reset on test begin does not cover them. ---
> >
> >In test_begin, below will not reset count for vcs, vecs engines on
> > MTL,
> > for_each_engine(engine, gt, id)
> > t->reset_engine[id] =
> > i915_reset_engine_count(>gpu_error,
> > engine);
> >
> > --- Then below will end test, again for primary GT where above
> > mentioned engines are not there --- err = igt_live_test_end(,
> > to_gt(i915));
> >
> > In short to me it looks like igt_live_test for device needs attention when
> > we
> have different engines on different GTs like MTL.
>
> If you either add for_each_gt to that for_each_engine in igt_live_test_begin
> and igt_live_test_end, or alternatively for_each_uabi_engine (maybe misses
> some internal engines?), everything works? That would be much smaller
> patch and wouldn't falsely associate live tests with a single gt.
>
Below would work, if you agree I will rearrange and send patch.
--- a/drivers/gpu/drm/i915/selftests/igt_live_test.c
+++ b/drivers/gpu/drm/i915/selftests/igt_live_test.c
@@ -16,28 +16,31 @@ int igt_live_test_begin(struct igt_live_test *t,
const char *func,
const char *name)
{
- struct intel_gt *gt = to_gt(i915);
+ struct intel_gt *gt;
struct intel_engine_cs *engine;
enum intel_engine_id id;
int err;
+ unsigned int i;
- t->i915 = i915;
- t->func = func;
- t->name = name;
+ for_each_gt(gt, i915, i) {
+ t->i915 = i915;
+ t->func = func;
+ t->name = name;
- err = intel_gt_wait_for_idle(gt, MAX_SCHEDULE_TIMEOUT);
- if (err) {
- pr_err("%s(%s): failed to idle before, with err=%d!",
- func, name, err);
- return err;
- }
+ err = intel_gt_wait_for_idle(gt, MAX_SCHEDULE_TIMEOUT);
+ if (err) {
+ pr_err("%s(%s): failed to idle before, with err=%d!",
+ func, name, err);
+ return err;
+ }
- t->reset_global = i915_reset_count(>gpu_error);
+ t->reset_global = i915_reset_count(>gpu_error);
- for_each_engine(engine, gt, id)
- t->reset_engine[id] =
+ for_each_engine(engine, gt, id)
+
Re: [Intel-gfx] [PATCH v7 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages
On Mon, 2023-04-10 at 09:28 -0700, Ceraolo Spurio, Daniele wrote: > alan:snip > > #define GSC_OUTFLAG_MSG_PENDING 1 > > +#define GSC_INFLAG_MSG_CLEANUP BIT(1) > > For consistency those should all be BIT() defines alan: will do. > > With the define fixed: > > Reviewed-by: Daniele Ceraolo Spurio > > Daniele > alan: thanks Daniele.
Re: [Intel-gfx] [PATCH v7 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
On Mon, 2023-04-10 at 09:10 -0700, Ceraolo Spurio, Daniele wrote:
>
alan:snip
> > +int
> > +intel_gsc_uc_heci_cmd_submit_nonpriv(struct intel_gsc_uc *gsc,
> > +struct intel_context *ce,
> > +struct intel_gsc_heci_non_priv_pkt *pkt,
> > +u32 *cmd, int timeout_ms)
> > +{
> > + struct intel_engine_cs *eng;
>
> We always use "engine" for engine_cs variables. IMO it's better to stick
> to that here as well for consistency across the code.
alan: will do
>
> > + struct i915_gem_ww_ctx ww;
> > + struct i915_request *rq;
> > + int err, trials = 0;
> > +
>
> Is the assumption that the caller is holding a wakeref already?
> Otherwise we're going to need and engine_pm_get() here (assuming it
> doesn't interfere with any locking, otherwise it has to be in the caller)
alan: right now the only places this can get called from is via
intel_pxp_gsccs_create_session or
intel_pxp_gsccs_end_arb_fw_session. These functions are either being called by
intel_pxp_start
or intel_pxp_end. intel_pxp_start calls intel_runtime_pm_get_if_in_use
indirectly from the
session-worker and while intel_pxp_end takes an explicit intel_runtime_pm_get
(since it is
for suspend/shutdown cleanup and doesn't use the worker). I'm assuming
runtime_pm works right?
we have a similar logic across the paths from ADL version where we dont take
explicit
engine_pm_get for the termination via VDBOX because its part of the same code
paths.
alan:snip
> > + err = i915_vma_move_to_active(pkt->bb_vma, rq, EXEC_OBJECT_WRITE);
>
> nit: I don't think we need EXEC_OBJECT_WRITE for the bb as we're not
> going to write it.
alan: yes - will remove. (had accidentally kept above flag from offline
debugging version of the code that had additional store dwords into bb).
>
> > + if (err)
> > + goto out_rq;
> > + err = i915_vma_move_to_active(pkt->heci_pkt_vma, rq, EXEC_OBJECT_WRITE);
> > + if (err)
> > + goto out_rq;
> > +
> > + eng = rq->context->engine;
> > + if (eng->emit_init_breadcrumb) {
> > + err = eng->emit_init_breadcrumb(rq);
> > + if (err)
> > + goto out_rq;
> > + }
> > +
> > + err = eng->emit_bb_start(rq, i915_vma_offset(pkt->bb_vma), PAGE_SIZE,
> > 0);
> > + if (err)
> > + goto out_rq;
> > +
> > + err = ce->engine->emit_flush(rq, 0);
> > + if (err)
> > + drm_err(_uc_to_gt(gsc)->i915->drm,
> > + "Failed emit-flush for gsc-heci-non-priv-pkterr=%d\n",
> > err);
> > +
> > +out_rq:
> > + i915_request_get(rq);
> > +
> > + if (unlikely(err))
> > + i915_request_set_error_once(rq, err);
> > +
> > + i915_request_add(rq);
> > +
> > + if (!err) {
> > + if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
> > + msecs_to_jiffies(timeout_ms)) < 0)
> > + err = -ETIME;
> > + }
> > +
> > + i915_request_put(rq);
> > +
> > +out_unpin_ce:
> > + intel_context_unpin(ce);
> > +out_ww:
> > + if (err == -EDEADLK) {
> > + err = i915_gem_ww_ctx_backoff();
> > + if (!err) {
> > + if (++trials < 10)
> > + goto retry;
> > + else
> > + err = EAGAIN;
> > + }
> > + }
> > + i915_gem_ww_ctx_fini();
> > +
> > + return err;
> > +}
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
> > index 3d56ae501991..3addce861854 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
> > @@ -8,7 +8,10 @@
> >
> > #include
> >
> > +struct i915_vma;
> > +struct intel_context;
> > struct intel_gsc_uc;
> > +
> > struct intel_gsc_mtl_header {
> > u32 validity_marker;
> > #define GSC_HECI_VALIDITY_MARKER 0xA578875A
> > @@ -47,7 +50,7 @@ struct intel_gsc_mtl_header {
> > * we distinguish the flags using OUTFLAG or INFLAG
> > */
> > u32 flags;
> > -#define GSC_OUTFLAG_MSG_PENDING1
> > +#define GSC_OUTFLAG_MSG_PENDING 1
>
> Nit: this change on the define is not really needed
sure - will fix.
>
> Daniele
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check HPD during eDP probe (rev6)
== Series Details == Series: drm/i915: Check HPD during eDP probe (rev6) URL : https://patchwork.freedesktop.org/series/114577/ State : success == Summary == CI Bug Log - changes from CI_DRM_13021 -> Patchwork_114577v6 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/index.html Participating hosts (38 -> 35) -- Missing(3): fi-kbl-soraka bat-mtlp-8 fi-snb-2520m Known issues Here are the changes found in Patchwork_114577v6 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][1] ([i915#6367] / [i915#7913]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/bat-rpls-2/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-2: NOTRUN -> [SKIP][2] ([i915#7828]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][3] ([i915#5354]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-2: NOTRUN -> [SKIP][4] ([i915#1845]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@i915_pm_rps@basic-api: - bat-dg2-11: [FAIL][5] ([i915#8308]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/bat-dg2-11/igt@i915_pm_...@basic-api.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/bat-dg2-11/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@migrate: - bat-atsm-1: [DMESG-FAIL][7] ([i915#7699]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/bat-atsm-1/igt@i915_selftest@l...@migrate.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/bat-atsm-1/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@requests: - bat-rpls-2: [ABORT][9] ([i915#4983] / [i915#7913]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/bat-rpls-2/igt@i915_selftest@l...@requests.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/bat-rpls-2/igt@i915_selftest@l...@requests.html * igt@i915_selftest@live@slpc: - bat-rpls-1: [DMESG-FAIL][11] ([i915#6367] / [i915#7996]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/bat-rpls-1/igt@i915_selftest@l...@slpc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-b-dp-1: - bat-dg2-8: [DMESG-WARN][13] ([i915#62]) -> [PASS][14] +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/bat-dg2-8/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-b-dp-1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/bat-dg2-8/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-b-dp-1.html * igt@kms_pipe_crc_basic@read-crc@pipe-b-dp-1: - bat-dg2-8: [DMESG-WARN][15] ([i915#7507]) -> [PASS][16] +5 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13021/bat-dg2-8/igt@kms_pipe_crc_basic@read-...@pipe-b-dp-1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v6/bat-dg2-8/igt@kms_pipe_crc_basic@read-...@pipe-b-dp-1.html [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#7507]: https://gitlab.freedesktop.org/drm/intel/issues/7507 [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#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 [i915#8308]: https://gitlab.freedesktop.org/drm/intel/issues/8308 Build changes - * Linux: CI_DRM_13021 -> Patchwork_114577v6 CI-20190529: 20190529 CI_DRM_13021: 495482f485451a5a0612de80df7de7309f0a12da @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7258: ad2eb276eda849b7a7985229009a816c7608186c @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114577v6: 495482f485451a5a0612de80df7de7309f0a12da @
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Check HPD during eDP probe (rev6)
== Series Details == Series: drm/i915: Check HPD during eDP probe (rev6) URL : https://patchwork.freedesktop.org/series/114577/ 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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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:117:1: warning: unreplaced symbol 'return' +./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: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:148: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:148: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:148: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:148: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:148: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:148: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:148: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:148: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:148: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: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'
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Check HPD during eDP probe (rev6)
== Series Details ==
Series: drm/i915: Check HPD during eDP probe (rev6)
URL : https://patchwork.freedesktop.org/series/114577/
State : warning
== Summary ==
Error: dim checkpatch failed
8c0b522203ba drm/i915: Introduce _hotplug_mask()
7131b5b152ca drm/i915: Introduce intel_hpd_enable_detection()
786171cf2e56 drm/i915: Check HPD live state during eDP probe
-:51: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 41e35ffb380b ("drm/i915: Favor
last VBT child device with conflicting AUX ch/DDC pin")'
#51:
Also the systems (Asrock B250M-HDV at least) fixed by commit
-:74: WARNING:COMMIT_LOG_USE_LINK: Unknown link reference 'References:', use
'Link:' instead
#74:
References: https://bugs.freedesktop.org/show_bug.cgi?id=111966
total: 1 errors, 1 warnings, 0 checks, 46 lines checked
9949d1b22953 drm/i915: Reuse _hotplug_mask() in .hpd_detection_setup()
-:15: WARNING:BAD_SIGN_OFF: Unexpected content after email: 'Vinod
Govindapillai a #v1', should be: 'Vinod
Govindapillai (a #v1)'
#15:
Reviewed-by: Vinod Govindapillai a #v1
total: 0 errors, 1 warnings, 0 checks, 140 lines checked
[Intel-gfx] Canceled event: XDC 2023 A Corunha Spain @ Tue Oct 17 - Thu Oct 19, 2023 (intel-gfx@lists.freedesktop.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:CANCEL BEGIN:VEVENT DTSTART;VALUE=DATE:20231017 DTEND;VALUE=DATE:20231020 DTSTAMP:20230417T170848Z ORGANIZER;CN=mario.kleiner...@gmail.com:mailto:mario.kleiner...@gmail.com UID:65qeuuc9e0gll25tq5r7e61...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=et na...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:etnaviv@lists.freedesktop .org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=xo rg-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:xorg-devel@lists.freed esktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=am d-gfx list;X-NUM-GUESTS=0:mailto:amd-...@lists.freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=in tel-gfx;X-NUM-GUESTS=0:mailto:intel-gfx@lists.freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=No uveau Dev;X-NUM-GUESTS=0:mailto:nouv...@lists.freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=mario. kleiner...@gmail.com;X-NUM-GUESTS=0:mailto:mario.kleiner...@gmail.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=bo a...@foundation.x.org;X-NUM-GUESTS=0:mailto:bo...@foundation.x.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=li bre-soc-...@lists.libre-soc.org;X-NUM-GUESTS=0:mailto:libre-soc-dev@lists.l ibre-soc.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ML mesa-dev;X-NUM-GUESTS=0:mailto:mesa-...@lists.freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=me mb...@x.org;X-NUM-GUESTS=0:mailto:memb...@x.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=fr eedr...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:freedreno@lists.freedes ktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=dr oidbit...@gmail.com;X-NUM-GUESTS=0:mailto:droidbit...@gmail.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=wa yland-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:wayland-devel@lists .freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=dr i-devel;X-NUM-GUESTS=0:mailto:dri-de...@lists.freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=si gles...@igalia.com;X-NUM-GUESTS=0:mailto:sigles...@igalia.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN=ev e...@lists.x.org;X-NUM-GUESTS=0:mailto:eve...@lists.x.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;X-NUM -GUESTS=0:mailto:bibby.hs...@mediatek.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;CN="G arg, Rohan";X-NUM-GUESTS=0:mailto:rohan.g...@intel.com X-GOOGLE-CONFERENCE:https://meet.google.com/azn-uwfp-pgw CREATED:20230417T170310Z DESCRIPTION:Hello!\n \nRegistration & Call for Proposals are now open for X DC 2023\, which will\ntake place on October 17-19\, 2023.\n\nhttps://xdc202 3.x.org\n \nAs usual\, the conference is free of charge and open to the gen eral\npublic. If you plan on attending\, please make sure to register as ea rly\nas possible!\n \nIn order to register as attendee\, you will therefore need to register\nvia the XDC website.\n \nhttps://indico.freedesktop.org/ event/4/registrations/\n \nIn addition to registration\, the CfP is now ope n for talks\, workshops\nand demos at XDC 2023. While ...\n\n-::~:~::~:~:~: ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\n Join with Google Meet: https://meet.google.com/azn-uwfp-pgw\n\nLearn more a bout Meet at: https://support.google.com/a/users/answer/9282720\n\nPlease d o not edit this section.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~ :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::- LAST-MODIFIED:20230417T170847Z LOCATION: SEQUENCE:1 STATUS:CANCELLED SUMMARY:XDC 2023 A Corunha Spain TRANSP:TRANSPARENT END:VEVENT END:VCALENDAR invite.ics Description: application/ics
[Intel-gfx] Invitation: XDC 2023 A Corunha Spain @ Tue Oct 17 - Thu Oct 19, 2023 (intel-gfx@lists.freedesktop.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART;VALUE=DATE:20231017 DTEND;VALUE=DATE:20231020 DTSTAMP:20230417T170311Z ORGANIZER;CN=mario.kleiner...@gmail.com:mailto:mario.kleiner...@gmail.com UID:65qeuuc9e0gll25tq5r7e61...@google.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=etna...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:etnaviv@lists.f reedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=xorg-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:xorg-devel@l ists.freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=amd-gfx list;X-NUM-GUESTS=0:mailto:amd-...@lists.freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=intel-gfx;X-NUM-GUESTS=0:mailto:intel-gfx@lists.freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Nouveau Dev;X-NUM-GUESTS=0:mailto:nouv...@lists.freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=mario.kleiner...@gmail.com;X-NUM-GUESTS=0:mailto:mario.kleiner.de@gmail .com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=bo...@foundation.x.org;X-NUM-GUESTS=0:mailto:bo...@foundation.x.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=libre-soc-...@lists.libre-soc.org;X-NUM-GUESTS=0:mailto:libre-soc-d e...@lists.libre-soc.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=ML mesa-dev;X-NUM-GUESTS=0:mailto:mesa-...@lists.freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=memb...@x.org;X-NUM-GUESTS=0:mailto:memb...@x.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=freedr...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:freedreno@lis ts.freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=droidbit...@gmail.com;X-NUM-GUESTS=0:mailto:droidbit...@gmail.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=wayland-de...@lists.freedesktop.org;X-NUM-GUESTS=0:mailto:wayland-d e...@lists.freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=dri-devel;X-NUM-GUESTS=0:mailto:dri-de...@lists.freedesktop.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=sigles...@igalia.com;X-NUM-GUESTS=0:mailto:sigles...@igalia.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=eve...@lists.x.org;X-NUM-GUESTS=0:mailto:eve...@lists.x.org X-GOOGLE-CONFERENCE:https://meet.google.com/azn-uwfp-pgw X-MICROSOFT-CDO-OWNERAPPTID:148915568 CREATED:20230417T170310Z DESCRIPTION:Hello!\n \nRegistration & Call for Proposals are now open for X DC 2023\, which will\ntake place on October 17-19\, 2023.\n\nhttps://xdc202 3.x.org\n \nAs usual\, the conference is free of charge and open to the gen eral\npublic. If you plan on attending\, please make sure to register as ea rly\nas possible!\n \nIn order to register as attendee\, you will therefore need to register\nvia the XDC website.\n \nhttps://indico.freedesktop.org/ event/4/registrations/\n \nIn addition to registration\, the CfP is now ope n for talks\, workshops\nand demos at XDC 2023. While ...\n\n-::~:~::~:~:~: ~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::-\n Join with Google Meet: https://meet.google.com/azn-uwfp-pgw\n\nLearn more a bout Meet at: https://support.google.com/a/users/answer/9282720\n\nPlease d o not edit this section.\n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~ :~:~:~:~:~:~:~:~:~:~:~:~:~:~:~::~:~::- LAST-MODIFIED:20230417T170310Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:XDC 2023 A Corunha Spain TRANSP:TRANSPARENT BEGIN:VALARM ACTION:EMAIL DESCRIPTION:This is an event reminder SUMMARY:Alarm notification ATTENDEE:mailto:intel-gfx@lists.freedesktop.org TRIGGER:-P0DT0H30M0S END:VALARM BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:This is an event reminder TRIGGER:-P0DT0H30M0S END:VALARM BEGIN:VALARM ACTION:EMAIL DESCRIPTION:This is an event reminder SUMMARY:Alarm notification ATTENDEE:mailto:intel-gfx@lists.freedesktop.org TRIGGER:-P0DT7H30M0S END:VALARM END:VEVENT END:VCALENDAR invite.ics Description: application/ics
Re: [Intel-gfx] [Nouveau] XDC 2023: Registration & Call for Proposals now open!
Signed up will only attend virtually Online however just fyi On Mon, Apr 17, 2023 at 1:41 PM Samuel Iglesias Gonsálvez wrote: > > Hello! > > Registration & Call for Proposals are now open for XDC 2023, which will > take place on October 17-19, 2023. > > https://xdc2023.x.org > > As usual, the conference is free of charge and open to the general > public. If you plan on attending, please make sure to register as early > as possible! > > In order to register as attendee, you will therefore need to register > via the XDC website. > > https://indico.freedesktop.org/event/4/registrations/ > > In addition to registration, the CfP is now open for talks, workshops > and demos at XDC 2023. While any serious proposal will be gratefully > considered, topics of interest to X.Org and freedesktop.org developers > are encouraged. The program focus is on new development, ongoing > challenges and anything else that will spark discussions among > attendees in the hallway track. > > We are open to talks across all layers of the graphics stack, from the > kernel to desktop environments / graphical applications and about how > to make things better for the developers who build them. Head to the > CfP page to learn more: > > https://indico.freedesktop.org/event/4/abstracts/ > > The deadline for submissions is Monday, 17 July 2023 (23:59 CEST) > > Check out our Reimbursement Policy to accept speaker expenses: > > https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ > > If you have any questions, please send me an email to > siglesias AT igalia.com, adding on Cc the X.org board (board > at foundation.x.org). > > And please keep in mind, you can follow us on Twitter for all the latest > updates and to stay connected: > > https://twitter.com/XOrgDevConf > > Best, > > Sam
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
Am 17.04.23 um 17:56 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Add support to dump GEM stats to fdinfo.
Signed-off-by: Tvrtko Ursulin
---
Documentation/gpu/drm-usage-stats.rst | 12 +++
drivers/gpu/drm/drm_file.c| 52 +++
include/drm/drm_drv.h | 7
include/drm/drm_file.h| 8 +
4 files changed, 79 insertions(+)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index 2ab32c40e93c..8273a41b2fb0 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -21,6 +21,7 @@ File format specification
- File shall contain one key value pair per one line of text.
- Colon character (`:`) must be used to delimit keys and values.
+- Caret (`^`) is also a reserved character.
- All keys shall be prefixed with `drm-`.
- Whitespace between the delimiter and first non-whitespace character shall be
ignored when parsing.
@@ -105,6 +106,17 @@ object belong to this client, in the respective memory
region.
Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
indicating kibi- or mebi-bytes.
+- drm-memory-^size: [KiB|MiB]
+- drm-memory-^shared: [KiB|MiB]
+- drm-memory-^resident: [KiB|MiB]
+- drm-memory-^purgeable: [KiB|MiB]
+- drm-memory-^active: [KiB|MiB]
What exactly does size/shared/active mean here?
If it means what I think it does I don't see how TTM based drivers
should track that in the first place.
Christian.
+
+Resident category is identical to the drm-memory- key and two should be
+mutually exclusive.
+
+TODO more description text...
+
- drm-cycles-
Engine identifier string must be the same as the one specified in the
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 37b4f76a5191..e202f79e816d 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include "drm_crtc_internal.h"
@@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev, struct
drm_pending_event *e)
}
EXPORT_SYMBOL(drm_send_event);
+static void
+print_stat(struct drm_printer *p, const char *stat, const char *region, u64 sz)
+{
+ const char *units[] = {"", " KiB", " MiB"};
+ unsigned int u;
+
+ if (sz == ~0ull) /* Not supported by the driver. */
+ return;
+
+ for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
+ if (sz < SZ_1K)
+ break;
+ sz = div_u64(sz, SZ_1K);
+ }
+
+ drm_printf(p, "drm-memory-%s^%s:\t%llu%s\n",
+ region, stat, sz, units[u]);
+}
+
+static void print_memory_stats(struct drm_printer *p, struct drm_file *file)
+{
+ struct drm_device *dev = file->minor->dev;
+ struct drm_fdinfo_memory_stat *stats;
+ unsigned int num, i;
+ char **regions;
+
+ regions = dev->driver->query_fdinfo_memory_regions(dev, );
+
+ stats = kcalloc(num, sizeof(*stats), GFP_KERNEL);
+ if (!stats)
+ return;
+
+ dev->driver->query_fdinfo_memory_stats(file, stats);
+
+ for (i = 0; i < num; i++) {
+ if (!regions[i]) /* Allow sparse name arrays. */
+ continue;
+
+ print_stat(p, "size", regions[i], stats[i].size);
+ print_stat(p, "shared", regions[i], stats[i].shared);
+ print_stat(p, "resident", regions[i], stats[i].resident);
+ print_stat(p, "purgeable", regions[i], stats[i].purgeable);
+ print_stat(p, "active", regions[i], stats[i].active);
+ }
+
+ kfree(stats);
+}
+
/**
* drm_show_fdinfo - helper for drm file fops
* @seq_file: output stream
@@ -900,6 +949,9 @@ void drm_show_fdinfo(struct seq_file *m, struct file *f)
if (dev->driver->show_fdinfo)
dev->driver->show_fdinfo(, file);
+
+ if (dev->driver->query_fdinfo_memory_regions)
+ print_memory_stats(, file);
}
EXPORT_SYMBOL(drm_show_fdinfo);
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 89e2706cac56..ccc1cd98d2aa 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -35,6 +35,7 @@
#include
struct drm_file;
+struct drm_fdinfo_memory_stat;
struct drm_gem_object;
struct drm_master;
struct drm_minor;
@@ -408,6 +409,12 @@ struct drm_driver {
*/
void (*show_fdinfo)(struct drm_printer *p, struct drm_file *f);
+ char ** (*query_fdinfo_memory_regions)(struct drm_device *dev,
+ unsigned int *num);
+
+ void (*query_fdinfo_memory_stats)(struct drm_file *f,
+ struct drm_fdinfo_memory_stat *stat);
+
/** @major: driver major number */
int major;
/** @minor: driver minor number */
diff --git a/include/drm/drm_file.h
[Intel-gfx] [PATCH v3] drm/i915: Initialize dkl_phy spin lock from display code path
Start to move the initialization of display locks from i915_driver_early_probe(), this way it is also executed when running Xe kmd. This will fix a warning in Xe kmd: [ 201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY A] failed to retrieve link info, disabling eDP [ 202.136336] xe :00:02.0: [drm] *ERROR* Failed to write source OUI [ 202.175346] INFO: trying to register non-static key. [ 202.175347] irq event stamp: 754060 [ 202.175359] hardirqs last enabled at (754059): [] tick_nohz_idle_enter+0x59/0x80 [ 202.180294] The code is fine but needs lockdep annotation, or maybe [ 202.183774] hardirqs last disabled at (754060): [] do_idle+0x99/0x230 [ 202.192734] you didn't initialize this object before use? [ 202.198951] softirqs last enabled at (753948): [] irq_exit_rcu+0xbe/0x130 [ 202.206882] turning off the locking correctness validator. [ 202.212236] softirqs last disabled at (753943): [] irq_exit_rcu+0xbe/0x130 [ 202.220592] CPU: 2 PID: 1415 Comm: modprobe Tainted: GW 6.3.0-rc4+zeh-xe+ #909 [ 202.243002] Hardware name: Intel Corporation Raptor Lake Client Platform/RaptorLake-P LP5 RVP, BIOS RPLPFWI1.R00.3361.A14.2211151548 11/15/2022 [ 202.255737] Call Trace: [ 202.258179] [ 202.260275] dump_stack_lvl+0x58/0xc0 [ 202.263922] register_lock_class+0x756/0x7d0 [ 202.268165] ? find_held_lock+0x2b/0x80 [ 202.271975] __lock_acquire+0x72/0x28b0 [ 202.275786] ? debug_object_free+0xb4/0x160 [ 202.279946] lock_acquire+0xd1/0x2d0 [ 202.283503] ? intel_dkl_phy_read+0x18/0x60 [xe] [ 202.288181] _raw_spin_lock+0x2a/0x40 [ 202.291825] ? intel_dkl_phy_read+0x18/0x60 [xe] [ 202.296475] intel_dkl_phy_read+0x18/0x60 [xe] [ 202.300949] icl_aux_power_well_enable+0x2bd/0x400 [xe] [ 202.306202] ? intel_display_power_grab_async_put_ref+0x75/0x120 [xe] [ 202.312649] intel_power_well_enable+0x1c/0x70 [xe] [ 202.317543] __intel_display_power_get_domain.part.0+0x4d/0x70 [xe] [ 202.323812] intel_display_power_get+0x43/0x70 [xe] [ 202.328708] intel_tc_port_init+0x199/0x2a0 [xe] [ 202.63] intel_ddi_init+0x6ad/0xb00 [xe] [ 202.337678] intel_modeset_init_nogem+0x536/0x6d0 [xe] [ 202.342838] xe_display_init_noaccel+0x19/0x40 [xe] [ 202.347743] xe_device_probe+0x1f5/0x2a0 [xe] [ 202.352127] xe_pci_probe+0x28c/0x480 [xe] [ 202.356260] pci_device_probe+0x9d/0x150 [ 202.360164] really_probe+0x19a/0x400 [ 202.363809] ? __pfx___driver_attach+0x10/0x10 [ 202.368226] __driver_probe_device+0x73/0x170 [ 202.372558] driver_probe_device+0x1a/0x90 [ 202.376632] __driver_attach+0xcd/0x1c0 [ 202.380442] bus_for_each_dev+0x72/0xc0 [ 202.384253] bus_add_driver+0x110/0x210 [ 202.388063] driver_register+0x50/0x100 [ 202.391873] ? __pfx_init_module+0x10/0x10 [xe] [ 202.396431] do_one_initcall+0x55/0x260 [ 202.400245] ? rcu_is_watching+0xd/0x40 [ 202.404058] ? kmalloc_trace+0xa0/0xb0 [ 202.407786] do_init_module+0x45/0x1e0 [ 202.411512] __do_sys_finit_module+0xac/0x120 [ 202.415838] do_syscall_64+0x37/0x90 [ 202.419397] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 202.424409] RIP: 0033:0x7fd11291ea3d [ 202.427967] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 a3 0f 00 f7 d8 64 89 01 48 [ 202.446530] RSP: 002b:7de11368 EFLAGS: 0246 ORIG_RAX: 0139 [ 202.454031] RAX: ffda RBX: 5616a617f210 RCX: 7fd11291ea3d [ 202.461106] RDX: RSI: 5616a617fe60 RDI: 000e [ 202.468182] RBP: 0004 R08: R09: 0002 [ 202.475250] R10: 000e R11: 0246 R12: 5616a617fe60 [ 202.482319] R13: 5616a617f340 R14: R15: 5616a6180650 [ 202.489396] v2: - added intel_display_locks_init() v3: - rebased Cc: intel-gfx@lists.freedesktop.org Cc: intel...@lists.freedesktop.org Cc: Rodrigo Vivi Cc: Ville Syrjälä Cc: Jani Nikula Cc: Maarten Lankhorst Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_display_driver.c | 8 drivers/gpu/drm/i915/display/intel_dkl_phy.c| 5 + drivers/gpu/drm/i915/display/intel_dkl_phy.h| 1 + drivers/gpu/drm/i915/i915_driver.c | 1 - 4 files changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c b/drivers/gpu/drm/i915/display/intel_display_driver.c index b3dbfe2a892e6..5e587b972ce0a 100644 --- a/drivers/gpu/drm/i915/display/intel_display_driver.c +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c @@ -30,6 +30,7 @@ #include "intel_display_driver.h" #include "intel_display_power.h" #include "intel_display_types.h" +#include "intel_dkl_phy.h" #include "intel_dmc.h" #include "intel_dp.h" #include "intel_dpll.h" @@ -170,11 +171,18 @@ static void intel_plane_possible_crtcs_init(struct drm_i915_private
[Intel-gfx] [RFC 6/6] drm/i915: Implement fdinfo memory stats printing
From: Tvrtko Ursulin
Show how more driver specific set of memory stats could be shown,
more specifically where object can reside in multiple regions, showing all
the supported stats, and where there is more to show than just user visible
objects.
WIP...
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_driver.c | 5 ++
drivers/gpu/drm/i915/i915_drm_client.c | 102 +
drivers/gpu/drm/i915/i915_drm_client.h | 8 ++
drivers/gpu/drm/i915/i915_drv.h| 2 +
4 files changed, 117 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 6493548c69bf..4c70206cbc27 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1806,6 +1806,11 @@ static const struct drm_driver i915_drm_driver = {
.dumb_create = i915_gem_dumb_create,
.dumb_map_offset = i915_gem_dumb_mmap_offset,
+#ifdef CONFIG_PROC_FS
+ .query_fdinfo_memory_regions = i915_query_fdinfo_memory_regions,
+ .query_fdinfo_memory_stats = i915_query_fdinfo_memory_stats,
+#endif
+
.ioctls = i915_ioctls,
.num_ioctls = ARRAY_SIZE(i915_ioctls),
.fops = _driver_fops,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index c654984189f7..65857c68bdb3 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -12,6 +12,7 @@
#include
#include "gem/i915_gem_context.h"
+#include "intel_memory_region.h"
#include "i915_drm_client.h"
#include "i915_file_private.h"
#include "i915_gem.h"
@@ -112,4 +113,105 @@ void i915_drm_client_fdinfo(struct drm_printer *p, struct
drm_file *file)
for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
show_client_class(p, i915, file_priv->client, i);
}
+
+char **
+i915_query_fdinfo_memory_regions(struct drm_device *dev, unsigned int *num)
+{
+ struct drm_i915_private *i915 = to_i915(dev);
+ struct intel_memory_region *mr;
+ enum intel_region_id id;
+
+ /* FIXME move to init */
+ for_each_memory_region(mr, i915, id) {
+ if (!i915->mm.region_names[id])
+ i915->mm.region_names[id] = mr->name;
+ }
+
+ *num = id;
+
+ return i915->mm.region_names;
+}
+
+static void
+add_obj(struct drm_i915_gem_object *obj, struct drm_fdinfo_memory_stat *stats)
+{
+struct intel_memory_region *mr;
+ u64 sz = obj->base.size;
+enum intel_region_id id;
+ unsigned int i;
+
+ if (!obj)
+ return;
+
+ /* Attribute size and shared to all possible memory regions. */
+ for (i = 0; i < obj->mm.n_placements; i++) {
+ mr = obj->mm.placements[i];
+ id = mr->id;
+
+ stats[id].size += sz;
+ if (obj->base.handle_count > 1)
+ stats[id].shared += sz;
+ }
+
+ /* Attribute other categories to only the current region. */
+ mr = obj->mm.region;
+ if (mr)
+ id = mr->id;
+ else
+ id = INTEL_REGION_SMEM;
+
+ if (!i915_gem_object_has_pages(obj))
+ return;
+
+ stats[id].resident += sz;
+
+ if (!dma_resv_test_signaled(obj->base.resv, dma_resv_usage_rw(true)))
+ stats[id].active += sz;
+ else if (i915_gem_object_is_shrinkable(obj) &&
+ obj->mm.madv == I915_MADV_DONTNEED)
+ stats[id].purgeable += sz;
+}
+
+void
+i915_query_fdinfo_memory_stats(struct drm_file *file,
+ struct drm_fdinfo_memory_stat *stats)
+{
+ struct drm_i915_file_private *file_priv = file->driver_priv;
+ struct i915_drm_client *client = file_priv->client;
+ struct drm_gem_object *drm_obj;
+ struct i915_gem_context *ctx;
+ int id;
+
+ /*
+* FIXME - we can do this better and in fewer passes if we are to start
+* exporting proper memory stats.
+*/
+
+ /* User created objects */
+ spin_lock(>table_lock);
+ idr_for_each_entry(>object_idr, drm_obj, id)
+ add_obj(to_intel_bo(drm_obj), stats);
+ spin_unlock(>table_lock);
+
+ /* Contexts, rings, timelines, page tables, ... */
+ rcu_read_lock();
+ list_for_each_entry_rcu(ctx, >ctx_list, client_link) {
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+
+ for_each_gem_engine(ce, rcu_dereference(ctx->engines), it) {
+ /* FIXME races?! */
+ if (ce->state)
+ add_obj(ce->state->obj, stats);
+ if (ce->timeline && ce->timeline->hwsp_ggtt)
+ add_obj(ce->timeline->hwsp_ggtt->obj, stats);
+ if (ce->ring && ce->ring->vma)
+ add_obj(ce->ring->vma->obj, stats);
+ }
[Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
From: Tvrtko Ursulin
Add support to dump GEM stats to fdinfo.
Signed-off-by: Tvrtko Ursulin
---
Documentation/gpu/drm-usage-stats.rst | 12 +++
drivers/gpu/drm/drm_file.c| 52 +++
include/drm/drm_drv.h | 7
include/drm/drm_file.h| 8 +
4 files changed, 79 insertions(+)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index 2ab32c40e93c..8273a41b2fb0 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -21,6 +21,7 @@ File format specification
- File shall contain one key value pair per one line of text.
- Colon character (`:`) must be used to delimit keys and values.
+- Caret (`^`) is also a reserved character.
- All keys shall be prefixed with `drm-`.
- Whitespace between the delimiter and first non-whitespace character shall be
ignored when parsing.
@@ -105,6 +106,17 @@ object belong to this client, in the respective memory
region.
Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
indicating kibi- or mebi-bytes.
+- drm-memory-^size: [KiB|MiB]
+- drm-memory-^shared: [KiB|MiB]
+- drm-memory-^resident: [KiB|MiB]
+- drm-memory-^purgeable: [KiB|MiB]
+- drm-memory-^active: [KiB|MiB]
+
+Resident category is identical to the drm-memory- key and two should be
+mutually exclusive.
+
+TODO more description text...
+
- drm-cycles-
Engine identifier string must be the same as the one specified in the
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 37b4f76a5191..e202f79e816d 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include "drm_crtc_internal.h"
@@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev, struct
drm_pending_event *e)
}
EXPORT_SYMBOL(drm_send_event);
+static void
+print_stat(struct drm_printer *p, const char *stat, const char *region, u64 sz)
+{
+ const char *units[] = {"", " KiB", " MiB"};
+ unsigned int u;
+
+ if (sz == ~0ull) /* Not supported by the driver. */
+ return;
+
+ for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
+ if (sz < SZ_1K)
+ break;
+ sz = div_u64(sz, SZ_1K);
+ }
+
+ drm_printf(p, "drm-memory-%s^%s:\t%llu%s\n",
+ region, stat, sz, units[u]);
+}
+
+static void print_memory_stats(struct drm_printer *p, struct drm_file *file)
+{
+ struct drm_device *dev = file->minor->dev;
+ struct drm_fdinfo_memory_stat *stats;
+ unsigned int num, i;
+ char **regions;
+
+ regions = dev->driver->query_fdinfo_memory_regions(dev, );
+
+ stats = kcalloc(num, sizeof(*stats), GFP_KERNEL);
+ if (!stats)
+ return;
+
+ dev->driver->query_fdinfo_memory_stats(file, stats);
+
+ for (i = 0; i < num; i++) {
+ if (!regions[i]) /* Allow sparse name arrays. */
+ continue;
+
+ print_stat(p, "size", regions[i], stats[i].size);
+ print_stat(p, "shared", regions[i], stats[i].shared);
+ print_stat(p, "resident", regions[i], stats[i].resident);
+ print_stat(p, "purgeable", regions[i], stats[i].purgeable);
+ print_stat(p, "active", regions[i], stats[i].active);
+ }
+
+ kfree(stats);
+}
+
/**
* drm_show_fdinfo - helper for drm file fops
* @seq_file: output stream
@@ -900,6 +949,9 @@ void drm_show_fdinfo(struct seq_file *m, struct file *f)
if (dev->driver->show_fdinfo)
dev->driver->show_fdinfo(, file);
+
+ if (dev->driver->query_fdinfo_memory_regions)
+ print_memory_stats(, file);
}
EXPORT_SYMBOL(drm_show_fdinfo);
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 89e2706cac56..ccc1cd98d2aa 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -35,6 +35,7 @@
#include
struct drm_file;
+struct drm_fdinfo_memory_stat;
struct drm_gem_object;
struct drm_master;
struct drm_minor;
@@ -408,6 +409,12 @@ struct drm_driver {
*/
void (*show_fdinfo)(struct drm_printer *p, struct drm_file *f);
+ char ** (*query_fdinfo_memory_regions)(struct drm_device *dev,
+ unsigned int *num);
+
+ void (*query_fdinfo_memory_stats)(struct drm_file *f,
+ struct drm_fdinfo_memory_stat *stat);
+
/** @major: driver major number */
int major;
/** @minor: driver minor number */
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 7d9b3c65cbc1..00d48beeac5c 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -375,6 +375,14 @@ struct drm_file {
#endif
};
+struct drm_fdinfo_memory_stat {
+ u64 size;
+ u64 shared;
+ u64
[Intel-gfx] [RFC 4/6] drm: Add simple fdinfo memory helpers
From: Tvrtko Ursulin
For drivers who only wish to show one memory region called 'system,
and only account the GEM buffer object handles under it.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_file.c | 45 ++
include/drm/drm_file.h | 6 +
2 files changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index e202f79e816d..1e70669dddf7 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -872,6 +872,51 @@ void drm_send_event(struct drm_device *dev, struct
drm_pending_event *e)
}
EXPORT_SYMBOL(drm_send_event);
+static void
+add_obj(struct drm_gem_object *obj, struct drm_fdinfo_memory_stat *stats)
+{
+ u64 sz = obj->size;
+
+ stats[0].size += sz;
+
+ if (obj->handle_count > 1)
+ stats[0].shared += sz;
+
+ if (!dma_resv_test_signaled(obj->resv, dma_resv_usage_rw(true)))
+ stats[0].active += sz;
+
+ /* Not supported. */
+ stats[0].resident = ~0ull;
+ stats[0].purgeable = ~0ull;
+}
+
+char **
+drm_query_fdinfo_system_region(struct drm_device *dev, unsigned int *num)
+{
+ static char *region[] = {
+ "system",
+ };
+
+ *num = 1;
+
+ return region;
+}
+EXPORT_SYMBOL(drm_query_fdinfo_system_region);
+
+void
+drm_query_fdinfo_system_memory(struct drm_file *file,
+ struct drm_fdinfo_memory_stat *stats)
+{
+ struct drm_gem_object *obj;
+ int id;
+
+ spin_lock(>table_lock);
+ idr_for_each_entry(>object_idr, obj, id)
+ add_obj(obj, stats);
+ spin_unlock(>table_lock);
+}
+EXPORT_SYMBOL(drm_query_fdinfo_system_memory);
+
static void
print_stat(struct drm_printer *p, const char *stat, const char *region, u64 sz)
{
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 00d48beeac5c..dd7c6fb2c975 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -383,6 +383,12 @@ struct drm_fdinfo_memory_stat {
u64 active;
};
+char **drm_query_fdinfo_system_region(struct drm_device *dev,
+ unsigned int *num);
+void drm_query_fdinfo_system_memory(struct drm_file *file,
+ struct drm_fdinfo_memory_stat *stats);
+
+
/**
* drm_is_primary_client - is this an open file of the primary node
* @file_priv: DRM file
--
2.37.2
[Intel-gfx] [RFC 2/6] drm/i915: Use the fdinfo helper
From: Tvrtko Ursulin
Use the common fdinfo helper for printing the basics. Remove now unused
client id allocation code.
Signed-off-by: Tvrtko Ursulin
Cc: Rob Clark
---
drivers/gpu/drm/i915/i915_driver.c | 6 +--
drivers/gpu/drm/i915/i915_drm_client.c | 65 --
drivers/gpu/drm/i915/i915_drm_client.h | 22 ++---
drivers/gpu/drm/i915/i915_drv.h| 2 -
drivers/gpu/drm/i915/i915_gem.c| 6 +--
5 files changed, 18 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index a52db8a80900..6493548c69bf 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -244,8 +244,6 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
if (ret < 0)
goto err_rootgt;
- i915_drm_clients_init(_priv->clients, dev_priv);
-
i915_gem_init_early(dev_priv);
/* This must be called before any calls to HAS_PCH_* */
@@ -279,7 +277,6 @@ static void i915_driver_late_release(struct
drm_i915_private *dev_priv)
intel_power_domains_cleanup(dev_priv);
i915_gem_cleanup_early(dev_priv);
intel_gt_driver_late_release_all(dev_priv);
- i915_drm_clients_fini(_priv->clients);
intel_region_ttm_device_fini(dev_priv);
vlv_suspend_cleanup(dev_priv);
i915_workqueues_cleanup(dev_priv);
@@ -1700,7 +1697,7 @@ static const struct file_operations i915_driver_fops = {
.compat_ioctl = i915_ioc32_compat_ioctl,
.llseek = noop_llseek,
#ifdef CONFIG_PROC_FS
- .show_fdinfo = i915_drm_client_fdinfo,
+ .show_fdinfo = drm_show_fdinfo,
#endif
};
@@ -1800,6 +1797,7 @@ static const struct drm_driver i915_drm_driver = {
.open = i915_driver_open,
.lastclose = i915_driver_lastclose,
.postclose = i915_driver_postclose,
+ .show_fdinfo = i915_drm_client_fdinfo,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index e8fa172ebe5e..c654984189f7 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -17,64 +17,29 @@
#include "i915_gem.h"
#include "i915_utils.h"
-void i915_drm_clients_init(struct i915_drm_clients *clients,
- struct drm_i915_private *i915)
-{
- clients->i915 = i915;
- clients->next_id = 0;
-
- xa_init_flags(>xarray, XA_FLAGS_ALLOC | XA_FLAGS_LOCK_IRQ);
-}
-
-struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients)
+struct i915_drm_client *i915_drm_client_alloc(void)
{
struct i915_drm_client *client;
- struct xarray *xa = >xarray;
- int ret;
client = kzalloc(sizeof(*client), GFP_KERNEL);
if (!client)
- return ERR_PTR(-ENOMEM);
-
- xa_lock_irq(xa);
- ret = __xa_alloc_cyclic(xa, >id, client, xa_limit_32b,
- >next_id, GFP_KERNEL);
- xa_unlock_irq(xa);
- if (ret < 0)
- goto err;
+ return NULL;
kref_init(>kref);
spin_lock_init(>ctx_lock);
INIT_LIST_HEAD(>ctx_list);
- client->clients = clients;
return client;
-
-err:
- kfree(client);
-
- return ERR_PTR(ret);
}
void __i915_drm_client_free(struct kref *kref)
{
struct i915_drm_client *client =
container_of(kref, typeof(*client), kref);
- struct xarray *xa = >clients->xarray;
- unsigned long flags;
- xa_lock_irqsave(xa, flags);
- __xa_erase(xa, client->id);
- xa_unlock_irqrestore(xa, flags);
kfree(client);
}
-void i915_drm_clients_fini(struct i915_drm_clients *clients)
-{
- GEM_BUG_ON(!xa_empty(>xarray));
- xa_destroy(>xarray);
-}
-
#ifdef CONFIG_PROC_FS
static const char * const uabi_class_names[] = {
[I915_ENGINE_CLASS_RENDER] = "render",
@@ -101,38 +66,34 @@ static u64 busy_add(struct i915_gem_context *ctx, unsigned
int class)
}
static void
-show_client_class(struct seq_file *m,
+show_client_class(struct drm_printer *p,
+ struct drm_i915_private *i915,
struct i915_drm_client *client,
unsigned int class)
{
- const struct list_head *list = >ctx_list;
+ const unsigned int capacity = i915->engine_uabi_class_count[class];
u64 total = atomic64_read(>past_runtime[class]);
- const unsigned int capacity =
- client->clients->i915->engine_uabi_class_count[class];
struct i915_gem_context *ctx;
rcu_read_lock();
- list_for_each_entry_rcu(ctx, list, client_link)
+ list_for_each_entry_rcu(ctx, >ctx_list, client_link)
total += busy_add(ctx, class);
rcu_read_unlock();
if (capacity)
-
[Intel-gfx] [RFC 5/6] drm/msm: Add basic memory stats
From: Tvrtko Ursulin
Use DRM helpers for implementing basic memory stats.
Signed-off-by: Tvrtko Ursulin
Cc: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 060c7689a739..7662103b5999 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -1090,6 +1090,10 @@ static const struct drm_driver msm_driver = {
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_import_sg_table = msm_gem_prime_import_sg_table,
.gem_prime_mmap = msm_gem_prime_mmap,
+#ifdef CONFIG_PROC_FS
+ .query_fdinfo_memory_regions = drm_query_fdinfo_system_region,
+ .query_fdinfo_memory_stats = drm_query_fdinfo_system_memory,
+#endif
#ifdef CONFIG_DEBUG_FS
.debugfs_init = msm_debugfs_init,
#endif
--
2.37.2
[Intel-gfx] [RFC 1/6] drm: Add common fdinfo helper
From: Rob Clark
Handle a bit of the boiler-plate in a single case, and make it easier to
add some core tracked stats.
v2: Update drm-usage-stats.rst, 64b client-id, rename drm_show_fdinfo
Reviewed-by: Daniel Vetter
Signed-off-by: Rob Clark
---
Documentation/gpu/drm-usage-stats.rst | 10 +++-
drivers/gpu/drm/drm_file.c| 35 +++
include/drm/drm_drv.h | 7 ++
include/drm/drm_file.h| 4 +++
4 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index b46327356e80..2ab32c40e93c 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -126,7 +126,15 @@ percentage utilization of the engine, whereas
drm-engine- only reflects
time active without considering what frequency the engine is operating as a
percentage of it's maximum frequency.
+Implementation Details
+==
+
+Drivers should use drm_show_fdinfo() in their `struct file_operations`, and
+implement _driver.show_fdinfo if they wish to provide any stats which
+are not provided by drm_show_fdinfo(). But even driver specific stats should
+be documented above and where possible, aligned with other drivers.
+
Driver specific implementations
-===
+---
:ref:`i915-usage-stats`
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index c1018c470047..37b4f76a5191 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -148,6 +148,7 @@ bool drm_dev_needs_global_mutex(struct drm_device *dev)
*/
struct drm_file *drm_file_alloc(struct drm_minor *minor)
{
+ static atomic64_t ident = ATOMIC_INIT(0);
struct drm_device *dev = minor->dev;
struct drm_file *file;
int ret;
@@ -156,6 +157,8 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
if (!file)
return ERR_PTR(-ENOMEM);
+ /* Get a unique identifier for fdinfo: */
+ file->client_id = atomic64_inc_return();
file->pid = get_pid(task_tgid(current));
file->minor = minor;
@@ -868,6 +871,38 @@ void drm_send_event(struct drm_device *dev, struct
drm_pending_event *e)
}
EXPORT_SYMBOL(drm_send_event);
+/**
+ * drm_show_fdinfo - helper for drm file fops
+ * @seq_file: output stream
+ * @f: the device file instance
+ *
+ * Helper to implement fdinfo, for userspace to query usage stats, etc, of a
+ * process using the GPU. See also _driver.show_fdinfo.
+ *
+ * For text output format description please see
Documentation/gpu/drm-usage-stats.rst
+ */
+void drm_show_fdinfo(struct seq_file *m, struct file *f)
+{
+ struct drm_file *file = f->private_data;
+ struct drm_device *dev = file->minor->dev;
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ drm_printf(, "drm-driver:\t%s\n", dev->driver->name);
+ drm_printf(, "drm-client-id:\t%llu\n", file->client_id);
+
+ if (dev_is_pci(dev->dev)) {
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
+
+ drm_printf(, "drm-pdev:\t%04x:%02x:%02x.%d\n",
+ pci_domain_nr(pdev->bus), pdev->bus->number,
+ PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
+ }
+
+ if (dev->driver->show_fdinfo)
+ dev->driver->show_fdinfo(, file);
+}
+EXPORT_SYMBOL(drm_show_fdinfo);
+
/**
* mock_drm_getfile - Create a new struct file for the drm device
* @minor: drm minor to wrap (e.g. #drm_device.primary)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index b419c59c4bef..89e2706cac56 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -401,6 +401,13 @@ struct drm_driver {
struct drm_device *dev, uint32_t handle,
uint64_t *offset);
+ /**
+* @show_fdinfo:
+*
+* Print device specific fdinfo. See
Documentation/gpu/drm-usage-stats.rst.
+*/
+ void (*show_fdinfo)(struct drm_printer *p, struct drm_file *f);
+
/** @major: driver major number */
int major;
/** @minor: driver minor number */
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index ecffe24e2b1b..7d9b3c65cbc1 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -258,6 +258,9 @@ struct drm_file {
/** @pid: Process that opened this file. */
struct pid *pid;
+ /** @client_id: A unique id for fdinfo */
+ u64 client_id;
+
/** @magic: Authentication magic, see @authenticated. */
drm_magic_t magic;
@@ -438,6 +441,7 @@ void drm_send_event(struct drm_device *dev, struct
drm_pending_event *e);
void drm_send_event_timestamp_locked(struct drm_device *dev,
struct drm_pending_event *e,
ktime_t timestamp);
+void
[Intel-gfx] [RFC 0/6] fdinfo alternative memory stats proposal
From: Tvrtko Ursulin
As discussed in the Rob's thread here is a slightly alternative idea on what to
expose and how.
DRM core is still defining a list of common memory categories but it is now up
to drivers to fill in the data and opt into the feature.
There is also no aggregated category and memory regions are always specified in
key names.
Two driver vfuncs are added where DRM core queries the number and names of
memory regions supported by the driver instance, and second where the driver
fills in the usage statistics for centrally defined memory categories.
I think this is a more future proof option since by moving the stat filling to
drivers they are able to show not only the GEM handles but all used memory. For
instance in case of i915 we have contexts, ring buffers, status pages and page
tables all backed by GEM objects too.
It also opens up a route for reporting sub-object size backing store granularity
and allows for not traversing under the file_table lock for drivers which are
able to do it in a more light-weight manner. For the former one example could be
simply adding TTM region helpers.
Not having aggregated counters means we do not need to add a second set of keys
as soon as the first driver wants to provide a more detailed view. And userspace
can trivially aggregate itself anyway.
At the same time two trivial helpers are provided who want to show just the
basic stats.
I have also tried to preserve the drm-memory-$region naming by reserving a
special character ('^') as a suffix ie. drm-memory-$region^$category. Unless I
am missing something this should be compatible with any existing parsers which
would just see more memory regions with more specific names. And they can be
updated to support the format extension.
Series is a bit rough so for discussion only.
Rob Clark (1):
drm: Add common fdinfo helper
Tvrtko Ursulin (5):
drm/i915: Use the fdinfo helper
drm: Add fdinfo memory stats
drm: Add simple fdinfo memory helpers
drm/msm: Add basic memory stats
drm/i915: Implement fdinfo memory stats printing
Documentation/gpu/drm-usage-stats.rst | 22 +++-
drivers/gpu/drm/drm_file.c | 132 +++
drivers/gpu/drm/i915/i915_driver.c | 11 +-
drivers/gpu/drm/i915/i915_drm_client.c | 167 +
drivers/gpu/drm/i915/i915_drm_client.h | 30 ++---
drivers/gpu/drm/i915/i915_drv.h| 4 +-
drivers/gpu/drm/i915/i915_gem.c| 6 +-
drivers/gpu/drm/msm/msm_drv.c | 4 +
include/drm/drm_drv.h | 14 +++
include/drm/drm_file.h | 18 +++
10 files changed, 324 insertions(+), 84 deletions(-)
--
2.37.2
[Intel-gfx] [PATCH 2/2] drm/i915/display: throw out struct intel_load_detect_pipe
An error-valued pointer can handle all in one without the wrapper
struct.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_crt.c | 18 -
.../gpu/drm/i915/display/intel_load_detect.c | 20 ---
.../gpu/drm/i915/display/intel_load_detect.h | 12 ---
drivers/gpu/drm/i915/display/intel_tv.c | 16 +++
4 files changed, 29 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
b/drivers/gpu/drm/i915/display/intel_crt.c
index 96acdf98a0c0..13519f78cf9f 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -822,9 +822,9 @@ intel_crt_detect(struct drm_connector *connector,
struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_crt *crt =
intel_attached_crt(to_intel_connector(connector));
struct intel_encoder *intel_encoder = >base;
+ struct drm_atomic_state *state;
intel_wakeref_t wakeref;
- int status, ret;
- struct intel_load_detect_pipe tmp;
+ int status;
drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s] force=%d\n",
connector->base.id, connector->name,
@@ -882,8 +882,12 @@ intel_crt_detect(struct drm_connector *connector,
}
/* for pre-945g platforms use load detect */
- ret = intel_load_detect_get_pipe(connector, , ctx);
- if (ret > 0) {
+ state = intel_load_detect_get_pipe(connector, ctx);
+ if (IS_ERR(state)) {
+ status = PTR_ERR(state);
+ } else if (!state) {
+ status = connector_status_unknown;
+ } else {
if (intel_crt_detect_ddc(connector))
status = connector_status_connected;
else if (DISPLAY_VER(dev_priv) < 4)
@@ -893,11 +897,7 @@ intel_crt_detect(struct drm_connector *connector,
status = connector_status_disconnected;
else
status = connector_status_unknown;
- intel_load_detect_release_pipe(connector, , ctx);
- } else if (ret == 0) {
- status = connector_status_unknown;
- } else {
- status = ret;
+ intel_load_detect_release_pipe(connector, state, ctx);
}
out:
diff --git a/drivers/gpu/drm/i915/display/intel_load_detect.c
b/drivers/gpu/drm/i915/display/intel_load_detect.c
index 5d6bb6d712bc..d5a0aecf3e8f 100644
--- a/drivers/gpu/drm/i915/display/intel_load_detect.c
+++ b/drivers/gpu/drm/i915/display/intel_load_detect.c
@@ -44,9 +44,9 @@ static int intel_modeset_disable_planes(struct
drm_atomic_state *state,
return 0;
}
-int intel_load_detect_get_pipe(struct drm_connector *connector,
- struct intel_load_detect_pipe *old,
- struct drm_modeset_acquire_ctx *ctx)
+struct drm_atomic_state *
+intel_load_detect_get_pipe(struct drm_connector *connector,
+ struct drm_modeset_acquire_ctx *ctx)
{
struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
@@ -64,8 +64,6 @@ int intel_load_detect_get_pipe(struct drm_connector
*connector,
connector->base.id, connector->name,
encoder->base.base.id, encoder->base.name);
- old->restore_state = NULL;
-
drm_WARN_ON(dev, !drm_modeset_is_locked(>connection_mutex));
/*
@@ -179,13 +177,12 @@ int intel_load_detect_get_pipe(struct drm_connector
*connector,
goto fail;
}
- old->restore_state = restore_state;
drm_atomic_state_put(state);
/* let the connector get through one full cycle before testing */
intel_crtc_wait_for_next_vblank(crtc);
- return true;
+ return restore_state;
fail:
if (state) {
@@ -198,27 +195,26 @@ int intel_load_detect_get_pipe(struct drm_connector
*connector,
}
if (ret == -EDEADLK)
- return ret;
+ return ERR_PTR(ret);
- return false;
+ return NULL;
}
void intel_load_detect_release_pipe(struct drm_connector *connector,
- struct intel_load_detect_pipe *old,
+ struct drm_atomic_state *state,
struct drm_modeset_acquire_ctx *ctx)
{
struct intel_encoder *intel_encoder =
intel_attached_encoder(to_intel_connector(connector));
struct drm_i915_private *i915 = to_i915(intel_encoder->base.dev);
struct drm_encoder *encoder = _encoder->base;
- struct drm_atomic_state *state = old->restore_state;
int ret;
drm_dbg_kms(>drm, "[CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
connector->base.id, connector->name,
encoder->base.id, encoder->name);
- if (!state)
+ if
[Intel-gfx] [PATCH 1/2] drm/i915/display: split out load detect to a separate file
Load detect is shared between tv and crt but otherwise isolated in
intel_display.c.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_crt.c | 5 +-
drivers/gpu/drm/i915/display/intel_display.c | 215
drivers/gpu/drm/i915/display/intel_display.h | 7 -
.../drm/i915/display/intel_display_types.h| 4 -
.../gpu/drm/i915/display/intel_load_detect.c | 229 ++
.../gpu/drm/i915/display/intel_load_detect.h | 24 ++
drivers/gpu/drm/i915/display/intel_tv.c | 5 +-
8 files changed, 260 insertions(+), 230 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_load_detect.c
create mode 100644 drivers/gpu/drm/i915/display/intel_load_detect.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 154986359169..9af76e376ca9 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -261,6 +261,7 @@ i915-y += \
display/intel_hdcp_gsc.o \
display/intel_hotplug.o \
display/intel_hti.o \
+ display/intel_load_detect.o \
display/intel_lpe_audio.o \
display/intel_modeset_verify.o \
display/intel_modeset_setup.o \
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
b/drivers/gpu/drm/i915/display/intel_crt.c
index 38e9c61c2344..96acdf98a0c0 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -48,6 +48,7 @@
#include "intel_fifo_underrun.h"
#include "intel_gmbus.h"
#include "intel_hotplug.h"
+#include "intel_load_detect.h"
#include "intel_pch_display.h"
#include "intel_pch_refclk.h"
@@ -881,7 +882,7 @@ intel_crt_detect(struct drm_connector *connector,
}
/* for pre-945g platforms use load detect */
- ret = intel_get_load_detect_pipe(connector, , ctx);
+ ret = intel_load_detect_get_pipe(connector, , ctx);
if (ret > 0) {
if (intel_crt_detect_ddc(connector))
status = connector_status_connected;
@@ -892,7 +893,7 @@ intel_crt_detect(struct drm_connector *connector,
status = connector_status_disconnected;
else
status = connector_status_unknown;
- intel_release_load_detect_pipe(connector, , ctx);
+ intel_load_detect_release_pipe(connector, , ctx);
} else if (ret == 0) {
status = connector_status_unknown;
} else {
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1c264c17b6e4..2d4a6936ab2b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3821,221 +3821,6 @@ bool intel_crtc_get_pipe_config(struct intel_crtc_state
*crtc_state)
return true;
}
-/* VESA 640x480x72Hz mode to set on the pipe */
-static const struct drm_display_mode load_detect_mode = {
- DRM_MODE("640x480", DRM_MODE_TYPE_DEFAULT, 31500, 640, 664,
-704, 832, 0, 480, 489, 491, 520, 0, DRM_MODE_FLAG_NHSYNC |
DRM_MODE_FLAG_NVSYNC),
-};
-
-static int intel_modeset_disable_planes(struct drm_atomic_state *state,
- struct drm_crtc *crtc)
-{
- struct drm_plane *plane;
- struct drm_plane_state *plane_state;
- int ret, i;
-
- ret = drm_atomic_add_affected_planes(state, crtc);
- if (ret)
- return ret;
-
- for_each_new_plane_in_state(state, plane, plane_state, i) {
- if (plane_state->crtc != crtc)
- continue;
-
- ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
- if (ret)
- return ret;
-
- drm_atomic_set_fb_for_plane(plane_state, NULL);
- }
-
- return 0;
-}
-
-int intel_get_load_detect_pipe(struct drm_connector *connector,
- struct intel_load_detect_pipe *old,
- struct drm_modeset_acquire_ctx *ctx)
-{
- struct intel_encoder *encoder =
- intel_attached_encoder(to_intel_connector(connector));
- struct intel_crtc *possible_crtc;
- struct intel_crtc *crtc = NULL;
- struct drm_device *dev = encoder->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct drm_mode_config *config = >mode_config;
- struct drm_atomic_state *state = NULL, *restore_state = NULL;
- struct drm_connector_state *connector_state;
- struct intel_crtc_state *crtc_state;
- int ret;
-
- drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
- connector->base.id, connector->name,
- encoder->base.base.id, encoder->base.name);
-
- old->restore_state = NULL;
-
- drm_WARN_ON(dev, !drm_modeset_is_locked(>connection_mutex));
-
- /*
-* Algorithm gets
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Increase AUX timeout for Type-C (rev3)
== Series Details == Series: drm/i915/display: Increase AUX timeout for Type-C (rev3) URL : https://patchwork.freedesktop.org/series/116010/ State : success == Summary == CI Bug Log - changes from CI_DRM_13020 -> Patchwork_116010v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/index.html Participating hosts (35 -> 37) -- Additional (3): fi-kbl-soraka fi-tgl-1115g4 bat-adls-5 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116010v3 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adls-5: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/bat-adls-5/igt@debugfs_t...@basic-hwmon.html - fi-tgl-1115g4: NOTRUN -> [SKIP][2] ([i915#7456]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: NOTRUN -> [ABORT][3] ([i915#6687] / [i915#7978]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][4] ([i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/fi-tgl-1115g4/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@random-engines: - bat-adls-5: NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/bat-adls-5/igt@gem_lmem_swapp...@random-engines.html * igt@gem_tiled_pread_basic: - bat-adls-5: NOTRUN -> [SKIP][9] ([i915#3282]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/bat-adls-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][10] ([i915#7561]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][11] ([i915#1886]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - bat-adls-5: NOTRUN -> [DMESG-WARN][12] ([i915#5591]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/bat-adls-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [PASS][13] -> [DMESG-WARN][14] ([i915#7699]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/bat-dg2-11/igt@i915_selftest@l...@migrate.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/bat-dg2-11/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@mman: - bat-rpls-1: [PASS][15] -> [TIMEOUT][16] ([i915#6794]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/bat-rpls-1/igt@i915_selftest@l...@mman.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/bat-rpls-1/igt@i915_selftest@l...@mman.html * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][17] ([i915#6367] / [i915#7913] / [i915#7996]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/bat-rpls-2/igt@i915_selftest@l...@slpc.html * igt@i915_suspend@basic-s3-without-i915: - fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][18] ([i915#7443]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium_edid@dp-edid-read: - fi-tgl-1115g4: NOTRUN -> [SKIP][19] ([i915#7828]) +7 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v3/fi-tgl-1115g4/igt@kms_chamelium_e...@dp-edid-read.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][20] ([fdo#109271]) +16 similar issues [20]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Increase AUX timeout for Type-C (rev3)
== Series Details ==
Series: drm/i915/display: Increase AUX timeout for Type-C (rev3)
URL : https://patchwork.freedesktop.org/series/116010/
State : warning
== Summary ==
Error: dim checkpatch failed
d7a532aae02a drm/i915/display: Increase AUX timeout for Type-C
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#13:
> >> Subject: RE: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX timeout
-:193: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#193: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:1385:
+ .instances = _PW_INSTANCES(
-:238: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 1 warnings, 1 checks, 42 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display/dp: 128/132b LT requirement (rev2)
== Series Details == Series: drm/i915/display/dp: 128/132b LT requirement (rev2) URL : https://patchwork.freedesktop.org/series/116562/ State : success == Summary == CI Bug Log - changes from CI_DRM_13020 -> Patchwork_116562v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/index.html Participating hosts (35 -> 37) -- Additional (3): fi-kbl-soraka fi-tgl-1115g4 bat-adls-5 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116562v2 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adls-5: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/bat-adls-5/igt@debugfs_t...@basic-hwmon.html - fi-tgl-1115g4: NOTRUN -> [SKIP][2] ([i915#7456]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html * igt@gem_exec_suspend@basic-s0@smem: - bat-rpls-2: NOTRUN -> [ABORT][3] ([i915#6687]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: NOTRUN -> [ABORT][4] ([i915#6687] / [i915#7978]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][5] ([i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-tgl-1115g4: NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/fi-tgl-1115g4/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@random-engines: - bat-adls-5: NOTRUN -> [SKIP][9] ([i915#4613]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/bat-adls-5/igt@gem_lmem_swapp...@random-engines.html * igt@gem_tiled_pread_basic: - bat-adls-5: NOTRUN -> [SKIP][10] ([i915#3282]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/bat-adls-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][11] ([i915#7561]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_heartbeat: - fi-cfl-8109u: [PASS][12] -> [DMESG-FAIL][13] ([i915#5334]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/fi-cfl-8109u/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][14] ([i915#1886]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - bat-adls-5: NOTRUN -> [DMESG-WARN][15] ([i915#5591]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/bat-adls-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@mman: - bat-rpls-1: [PASS][16] -> [TIMEOUT][17] ([i915#6794]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/bat-rpls-1/igt@i915_selftest@l...@mman.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/bat-rpls-1/igt@i915_selftest@l...@mman.html * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][18] ([i915#6367] / [i915#7913] / [i915#7996]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/bat-rpls-2/igt@i915_selftest@l...@slpc.html * igt@i915_suspend@basic-s3-without-i915: - fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][19] ([i915#7443]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116562v2/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium_edid@dp-edid-read: - fi-tgl-1115g4: NOTRUN -> [SKIP][20] ([i915#7828]) +7 similar issues [20]:
Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c
On Mon, Apr 17, 2023 at 12:24:45PM +0100, Tvrtko Ursulin wrote:
>
> On 14/04/2023 11:45, Zhao Liu wrote:
> > Hi Tvrtko,
> >
> > On Wed, Apr 12, 2023 at 04:45:13PM +0100, Tvrtko Ursulin wrote:
> >
> > [snip]
> >
> > > >
> > > > [snip]
> > > > > However I am unsure if disabling pagefaulting is needed or not.
> > > > > Thomas,
> > > > > Matt, being the last to touch this area, perhaps you could have a
> > > > > look?
> > > > > Because I notice we have a fallback iomap path which still uses
> > > > > io_mapping_map_atomic_wc. So if kmap_atomic to kmap_local conversion
> > > > > is
> > > > > safe, does the iomap side also needs converting to
> > > > > io_mapping_map_local_wc? Or they have separate requirements?
> > > >
> > > > AFAIK, the requirements for io_mapping_map_local_wc() are the same as
> > > > for
> > > > kmap_local_page(): the kernel virtual address is _only_ valid in the
> > > > caller
> > > > context, and map/unmap nesting must be done in stack-based ordering
> > > > (LIFO).
> > > >
> > > > I think a follow up patch could safely switch to
> > > > io_mapping_map_local_wc() /
> > > > io_mapping_unmap_local_wc since the address is local to context.
> > > >
> > > > However, not being an expert, reading your note now I suspect that I'm
> > > > missing
> > > > something. Can I ask why you think that page-faults disabling might be
> > > > necessary?
> > >
> > > I am not saying it is, was just unsure and wanted some people who worked
> > > on this code most recently to take a look and confirm.
> > >
> > > I guess it will work since the copying is done like this anyway:
> > >
> > > /*
> > >* This is the fast path and we cannot handle a pagefault
> > >* whilst holding the struct mutex lest the user pass in the
> > >* relocations contained within a mmaped bo. For in such a case
> > >* we, the page fault handler would call i915_gem_fault() and
> > >* we would try to acquire the struct mutex again. Obviously
> > >* this is bad and so lockdep complains vehemently.
> > >*/
> > > pagefault_disable();
> > > copied = __copy_from_user_inatomic(r, urelocs, count *
> > > sizeof(r[0]));
> > > pagefault_enable();
> > > if (unlikely(copied)) {
> > > remain = -EFAULT;
> > > goto out;
> > > }
> > >
> > > Comment is a bit outdated since we don't use that global "struct mutex"
> > > any longer, but in any case, if there is a page fault on the mapping
> > > where we need to recurse into i915 again to satisfy if, we seem to have
> > > code already to handle it. So kmap_local conversion I *think* can't
> > > regress anything.
> >
> > Thanks for your explanation!
> >
> > >
> > > Patch to convert the io_mapping_map_atomic_wc can indeed come later.
> >
> > Okay, I will also look at this.
> >
> > >
> > > In terms of logistics - if we landed this series to out branch it would
> > > be queued only for 6.5. Would that work for you?
> >
> > Yeah, it's ok for me. But could I ask, did I miss the 6.4 merge time?
>
> Yes, but just because we failed to review and merge in time, not because you
> did not provide patches in time.
It is worth mentioning that under drm we close the merge window earlier.
Around -rc5.
So, Linus' merge window for 6.4 didn't happen yet. But our drm-next that
is going to be sent there is already closed.
>
> Regards,
>
> Tvrtko
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Replace kmap() with kmap_local_page() (rev3)
== Series Details == Series: drm/i915: Replace kmap() with kmap_local_page() (rev3) URL : https://patchwork.freedesktop.org/series/107277/ State : success == Summary == CI Bug Log - changes from CI_DRM_13020 -> Patchwork_107277v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/index.html Participating hosts (35 -> 37) -- Additional (3): fi-kbl-soraka fi-tgl-1115g4 bat-adls-5 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_107277v3 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adls-5: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/bat-adls-5/igt@debugfs_t...@basic-hwmon.html - fi-tgl-1115g4: NOTRUN -> [SKIP][2] ([i915#7456]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-tgl-1115g4: NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/fi-tgl-1115g4/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@random-engines: - bat-adls-5: NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/bat-adls-5/igt@gem_lmem_swapp...@random-engines.html * igt@gem_tiled_pread_basic: - bat-adls-5: NOTRUN -> [SKIP][8] ([i915#3282]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/bat-adls-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][9] ([i915#7561]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-dg2-11: [PASS][10] -> [FAIL][11] ([i915#8308]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/bat-dg2-11/igt@i915_pm_...@basic-api.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/bat-dg2-11/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][12] ([i915#1886]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - bat-adls-5: NOTRUN -> [DMESG-WARN][13] ([i915#5591]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/bat-adls-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@requests: - bat-rpls-2: [PASS][14] -> [ABORT][15] ([i915#7913] / [i915#7982]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/bat-rpls-2/igt@i915_selftest@l...@requests.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/bat-rpls-2/igt@i915_selftest@l...@requests.html * igt@i915_selftest@live@workarounds: - bat-adlp-9: [PASS][16] -> [INCOMPLETE][17] ([i915#4983] / [i915#7677] / [i915#7913]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/bat-adlp-9/igt@i915_selftest@l...@workarounds.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/bat-adlp-9/igt@i915_selftest@l...@workarounds.html * igt@i915_suspend@basic-s3-without-i915: - fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][18] ([i915#7443]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium_edid@dp-edid-read: - fi-tgl-1115g4: NOTRUN -> [SKIP][19] ([i915#7828]) +7 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/fi-tgl-1115g4/igt@kms_chamelium_e...@dp-edid-read.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][20] ([fdo#109271]) +16 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107277v3/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: -
Re: [Intel-gfx] [PATCH] drm/i915/pps: use intel_de_rmw() for panel unlock
On 17.04.2023 10:57, Jani Nikula wrote:
Use rmw where needed.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_pps.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
b/drivers/gpu/drm/i915/display/intel_pps.c
index 7f9926672a6a..4f0b0cca03cc 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -1653,12 +1653,9 @@ void intel_pps_unlock_regs_wa(struct drm_i915_private
*dev_priv)
*/
pps_num = intel_num_pps(dev_priv);
- for (pps_idx = 0; pps_idx < pps_num; pps_idx++) {
- u32 val = intel_de_read(dev_priv, PP_CONTROL(pps_idx));
-
- val = (val & ~PANEL_UNLOCK_MASK) | PANEL_UNLOCK_REGS;
- intel_de_write(dev_priv, PP_CONTROL(pps_idx), val);
- }
+ for (pps_idx = 0; pps_idx < pps_num; pps_idx++)
+ intel_de_rmw(dev_priv, PP_CONTROL(pps_idx),
+PANEL_UNLOCK_MASK, PANEL_UNLOCK_REGS);
}
void intel_pps_setup(struct drm_i915_private *i915)
Still some leftovers.
Reviewed-by: Andrzej Hajda
Regards
Andrzej
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Replace kmap() with kmap_local_page() (rev3)
== Series Details == Series: drm/i915: Replace kmap() with kmap_local_page() (rev3) URL : https://patchwork.freedesktop.org/series/107277/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v9 10/10] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers
Hi Mark, kernel test robot noticed the following build errors: [auto build test ERROR on drm-intel/for-linux-next-fixes] [also build test ERROR on linus/master v6.3-rc7] [cannot apply to drm-tip/drm-tip drm-misc/drm-misc-next drm-intel/for-linux-next drm/drm-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Mark-Yacoub/drm-hdcp-Add-drm_hdcp_atomic_check/20230412-032412 base: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes patch link: https://lore.kernel.org/r/20230411192134.508113-11-markyacoub%40google.com patch subject: [Intel-gfx] [PATCH v9 10/10] drm/msm: Implement HDCP 1.x using the new drm HDCP helpers config: loongarch-randconfig-r015-20230417 (https://download.01.org/0day-ci/archive/20230417/202304172130.pxi8pggx-...@intel.com/config) compiler: loongarch64-linux-gcc (GCC) 12.1.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/93651da28f1a578d2edab2d2b47d9935145d675f git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Mark-Yacoub/drm-hdcp-Add-drm_hdcp_atomic_check/20230412-032412 git checkout 93651da28f1a578d2edab2d2b47d9935145d675f # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=loongarch olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=loongarch SHELL=/bin/bash drivers/gpu/drm/msm/ If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot | Link: https://lore.kernel.org/oe-kbuild-all/202304172130.pxi8pggx-...@intel.com/ All errors (new ones prefixed by >>): >> drivers/gpu/drm/msm/msm_atomic.c:12:10: fatal error: dp_drm.h: No such file >> or directory 12 | #include "dp_drm.h" | ^~ compilation terminated. vim +12 drivers/gpu/drm/msm/msm_atomic.c 11 > 12 #include "dp_drm.h" 13 #include "msm_atomic_trace.h" 14 #include "msm_drv.h" 15 #include "msm_gem.h" 16 #include "msm_kms.h" 17 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Thu, Apr 13, 2023 at 12:07:12PM -0600, Alex Williamson wrote: > IIUC, the semantics we're proposing is that an INFO2 ioctl would return > success or failure indicating whether the user has sufficient ownership > of the affected devices, Or a flag, but yes > and in the success case returns an array of > affected dev-ids within the user's iommufd_ctx. Unopened, affected > devices, are not reported via INFO2, and unopened, affected devices > outside the user's scope of ownership (ie. outside the owned IOMMU > group) will generate a failure condition. Yes > As for the INFO ioctl, it's described as unchanged, which does raise > the question of what is reported for IOMMU groups and how does the > value there coherently relate to anything else in the cdev-exclusive > vfio API... For cdev mode the value of the group_id has no functional purpose. INFO has no functional purpose beyond debugging. The cdev enabled userspace should print the BDFs from the INFO in a debug message and ignore the group_id. Kernel will still fill the group_id using the iommu_get_group() stuff, and set -1 for no-iommu. > We had already iterated a proposal where the group-id is replaced with > a dev-id in the existing ioctl and a flag indicates when the return > value is a dev-id vs group-id. This had a gap that userspace cannot > determine if a reset is available given this information since un-owned > devices report an invalid dev-id and userspace can't know if it has > implicit ownership. IIRC, yes. > It seems cleaner to me though that we would could still re-use INFO in > a similar way, simply defining a new flag bit which is valid only in > the case of returning dev-ids and indicates if the reset is > available. Yes, it could be done like this as well. INFO2 is more a discussion object, how we encode it in the uAPI matters a lot less. The point is that INFO2, as an idea, returns information that no other existing API returns: the "ownership passed flag" and "dev_id list" Then as I said in the other mail we roll no-iommu into an iommufd_ctx object and just follow the design that userspace must have a single iommufd_ctx containing all the devices to use the hot reset feature. Jason
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pps: use intel_de_rmw() for panel unlock
== Series Details == Series: drm/i915/pps: use intel_de_rmw() for panel unlock URL : https://patchwork.freedesktop.org/series/116560/ State : success == Summary == CI Bug Log - changes from CI_DRM_13020 -> Patchwork_116560v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/index.html Participating hosts (35 -> 35) -- Additional (2): fi-tgl-1115g4 bat-adls-5 Missing(2): fi-apl-guc fi-snb-2520m Known issues Here are the changes found in Patchwork_116560v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adls-5: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/bat-adls-5/igt@debugfs_t...@basic-hwmon.html - fi-tgl-1115g4: NOTRUN -> [SKIP][2] ([i915#7456]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-tgl-1115g4: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/fi-tgl-1115g4/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@random-engines: - bat-adls-5: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/bat-adls-5/igt@gem_lmem_swapp...@random-engines.html * igt@gem_tiled_pread_basic: - bat-adls-5: NOTRUN -> [SKIP][6] ([i915#3282]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/bat-adls-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][7] ([i915#7561]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@hangcheck: - bat-adls-5: NOTRUN -> [DMESG-WARN][8] ([i915#5591]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/bat-adls-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][9] ([i915#6997] / [i915#7913]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html * igt@i915_suspend@basic-s3-without-i915: - fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][10] ([i915#7443]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/fi-tgl-1115g4/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium_edid@dp-edid-read: - fi-tgl-1115g4: NOTRUN -> [SKIP][11] ([i915#7828]) +7 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/fi-tgl-1115g4/igt@kms_chamelium_e...@dp-edid-read.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-2: NOTRUN -> [SKIP][12] ([i915#7828]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-dg2-11: NOTRUN -> [SKIP][13] ([i915#7828]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_chamelium_hpd@vga-hpd-fast: - bat-adls-5: NOTRUN -> [SKIP][14] ([i915#7828]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/bat-adls-5/igt@kms_chamelium_...@vga-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-tgl-1115g4: NOTRUN -> [SKIP][15] ([i915#4103]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/fi-tgl-1115g4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-adls-5: NOTRUN -> [SKIP][16] ([i915#4103]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/bat-adls-5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - fi-tgl-1115g4: NOTRUN -> [SKIP][17] ([fdo#109285]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/fi-tgl-1115g4/igt@kms_force_connector_ba...@force-load-detect.html - bat-adls-5: NOTRUN -> [SKIP][18] ([fdo#109285]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116560v1/bat-adls-5/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@read-crc: - bat-adlp-9: NOTRUN -> [SKIP][19]
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Fri, Apr 14, 2023 at 09:11:30AM +, Tian, Kevin wrote: > The only corner case with this option is when a user mixes group > and cdev usages. iirc you mentioned it's a valid usage to be supported. > In that case the kernel doesn't have sufficient knowledge to judge > 'resettable' as it doesn't know which groups are opened by this user. IMHO we don't need to support this combination. We can say that to use the hot reset API the user must put all their devices into the same iommufd_ctx and cover 100% of the known use cases for this. There are already other situations, like nesting, that do force users to put everything into one iommufd_ctx. No reason to make things harder and more complicated. I'm coming to the feeling that we should put no-iommu devices in iommufd_ctx's as well. They would be an iommufd_access like mdevs. That would clean up the complications they cause here. I suppose we should have done that from the beginning - no-iommu is an IOMMUFD access, it just uses a crazy /proc based way to learn the PFNs. Making it a proper access and making a real VFIO ioctl that calls iommufd_access_pin_pages() and returns the DMA mapped addresses to userspace would go a long way to making no-iommu work in a logical, usable, way. Jason
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Make IRQ reset and postinstall multi-gt aware (rev4)
== Series Details ==
Series: drm/i915: Make IRQ reset and postinstall multi-gt aware (rev4)
URL : https://patchwork.freedesktop.org/series/115465/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13020 -> Patchwork_115465v4
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_115465v4 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_115465v4, 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_115465v4/index.html
Participating hosts (35 -> 36)
--
Additional (2): fi-tgl-1115g4 bat-adls-5
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115465v4:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gtt:
- bat-atsm-1: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/bat-atsm-1/igt@i915_selftest@l...@gtt.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/bat-atsm-1/igt@i915_selftest@l...@gtt.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@debugfs_test@basic-hwmon:
- {bat-mtlp-8}: NOTRUN -> [SKIP][3] +40 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html
* igt@i915_selftest@live@gt_mocs:
- {bat-mtlp-8}: NOTRUN -> [ABORT][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
* igt@kms_frontbuffer_tracking@basic:
- {bat-mtlp-8}: NOTRUN -> [DMESG-FAIL][5] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/bat-mtlp-8/igt@kms_frontbuffer_track...@basic.html
* igt@kms_psr@sprite_plane_onoff:
- {bat-mtlp-8}: NOTRUN -> [DMESG-WARN][6] +2 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/bat-mtlp-8/igt@kms_psr@sprite_plane_onoff.html
* igt@prime_vgem@basic-userptr:
- {bat-mtlp-8}: NOTRUN -> [FAIL][7] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/bat-mtlp-8/igt@prime_v...@basic-userptr.html
Known issues
Here are the changes found in Patchwork_115465v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- bat-adls-5: NOTRUN -> [SKIP][8] ([i915#7456])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/bat-adls-5/igt@debugfs_t...@basic-hwmon.html
- fi-tgl-1115g4: NOTRUN -> [SKIP][9] ([i915#7456])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html
* igt@gem_huc_copy@huc-copy:
- fi-tgl-1115g4: NOTRUN -> [SKIP][10] ([i915#2190])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-tgl-1115g4: NOTRUN -> [SKIP][11] ([i915#4613]) +3 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/fi-tgl-1115g4/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_lmem_swapping@random-engines:
- bat-adls-5: NOTRUN -> [SKIP][12] ([i915#4613]) +3 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/bat-adls-5/igt@gem_lmem_swapp...@random-engines.html
* igt@gem_tiled_pread_basic:
- bat-adls-5: NOTRUN -> [SKIP][13] ([i915#3282])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/bat-adls-5/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-tgl-1115g4: NOTRUN -> [SKIP][14] ([i915#7561])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@hangcheck:
- bat-adls-5: NOTRUN -> [DMESG-WARN][15] ([i915#5591])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/bat-adls-5/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@migrate:
- bat-dg2-11: [PASS][16] -> [DMESG-WARN][17] ([i915#7699])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v4/bat-dg2-11/igt@i915_selftest@l...@migrate.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-tgl-1115g4: NOTRUN -> [INCOMPLETE][18] ([i915#7443])
[18]:
[Intel-gfx] [PATCH v2 4/4] drm/i915: Reuse _hotplug_mask() in .hpd_detection_setup()
From: Ville Syrjälä
Replace the hardcoded masks with just a loop over all hpd
pins using the _hotplug_mask() functions.
v2: Deal with mtp
Reviewed-by: Vinod Govindapillai a #v1
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 65 -
1 file changed, 24 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3505fafcfb7b..4345931c6596 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -83,6 +83,7 @@ static inline void pmu_irq_stats(struct drm_i915_private
*i915,
typedef bool (*long_pulse_detect_func)(enum hpd_pin pin, u32 val);
typedef u32 (*hotplug_enables_func)(struct intel_encoder *encoder);
+typedef u32 (*hotplug_mask_func)(enum hpd_pin pin);
static const u32 hpd_ilk[HPD_NUM_PINS] = {
[HPD_PORT_A] = DE_DP_A_HOTPLUG,
@@ -899,6 +900,18 @@ static u32 intel_hpd_hotplug_irqs(struct drm_i915_private
*dev_priv,
return hotplug_irqs;
}
+static u32 intel_hpd_hotplug_mask(struct drm_i915_private *i915,
+ hotplug_mask_func hotplug_mask)
+{
+ enum hpd_pin pin;
+ u32 hotplug = 0;
+
+ for_each_hpd_pin(pin)
+ hotplug |= hotplug_mask(pin);
+
+ return hotplug;
+}
+
static u32 intel_hpd_hotplug_enables(struct drm_i915_private *i915,
hotplug_enables_func hotplug_enables)
{
@@ -2981,10 +2994,7 @@ static void ibx_hpd_detection_setup(struct
drm_i915_private *dev_priv)
* The pulse duration bits are reserved on LPT+.
*/
intel_uncore_rmw(_priv->uncore, PCH_PORT_HOTPLUG,
-ibx_hotplug_mask(HPD_PORT_A) |
-ibx_hotplug_mask(HPD_PORT_B) |
-ibx_hotplug_mask(HPD_PORT_C) |
-ibx_hotplug_mask(HPD_PORT_D),
+intel_hpd_hotplug_mask(dev_priv, ibx_hotplug_mask),
intel_hpd_hotplug_enables(dev_priv,
ibx_hotplug_enables));
}
@@ -3050,10 +3060,7 @@ static u32 icp_tc_hotplug_enables(struct intel_encoder
*encoder)
static void icp_ddi_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, SHOTPLUG_CTL_DDI,
-icp_ddi_hotplug_mask(HPD_PORT_A) |
-icp_ddi_hotplug_mask(HPD_PORT_B) |
-icp_ddi_hotplug_mask(HPD_PORT_C) |
-icp_ddi_hotplug_mask(HPD_PORT_D),
+intel_hpd_hotplug_mask(dev_priv, icp_ddi_hotplug_mask),
intel_hpd_hotplug_enables(dev_priv,
icp_ddi_hotplug_enables));
}
@@ -3069,12 +3076,7 @@ static void icp_ddi_hpd_enable_detection(struct
intel_encoder *encoder)
static void icp_tc_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, SHOTPLUG_CTL_TC,
-icp_tc_hotplug_mask(HPD_PORT_TC1) |
-icp_tc_hotplug_mask(HPD_PORT_TC2) |
-icp_tc_hotplug_mask(HPD_PORT_TC3) |
-icp_tc_hotplug_mask(HPD_PORT_TC4) |
-icp_tc_hotplug_mask(HPD_PORT_TC5) |
-icp_tc_hotplug_mask(HPD_PORT_TC6),
+intel_hpd_hotplug_mask(dev_priv, icp_tc_hotplug_mask),
intel_hpd_hotplug_enables(dev_priv,
icp_tc_hotplug_enables));
}
@@ -3155,12 +3157,7 @@ static void dg1_hpd_irq_setup(struct drm_i915_private
*dev_priv)
static void gen11_tc_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, GEN11_TC_HOTPLUG_CTL,
-gen11_hotplug_mask(HPD_PORT_TC1) |
-gen11_hotplug_mask(HPD_PORT_TC2) |
-gen11_hotplug_mask(HPD_PORT_TC3) |
-gen11_hotplug_mask(HPD_PORT_TC4) |
-gen11_hotplug_mask(HPD_PORT_TC5) |
-gen11_hotplug_mask(HPD_PORT_TC6),
+intel_hpd_hotplug_mask(dev_priv, gen11_hotplug_mask),
intel_hpd_hotplug_enables(dev_priv,
gen11_hotplug_enables));
}
@@ -3176,12 +3173,7 @@ static void gen11_tc_hpd_enable_detection(struct
intel_encoder *encoder)
static void gen11_tbt_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, GEN11_TBT_HOTPLUG_CTL,
-gen11_hotplug_mask(HPD_PORT_TC1) |
-gen11_hotplug_mask(HPD_PORT_TC2) |
-gen11_hotplug_mask(HPD_PORT_TC3) |
-gen11_hotplug_mask(HPD_PORT_TC4) |
-gen11_hotplug_mask(HPD_PORT_TC5) |
-gen11_hotplug_mask(HPD_PORT_TC6),
+intel_hpd_hotplug_mask(dev_priv, gen11_hotplug_mask),
intel_hpd_hotplug_enables(dev_priv,
[Intel-gfx] [PATCH v2 3/4] drm/i915: Check HPD live state during eDP probe
From: Ville Syrjälä
We need to untangle the mess where some SKL machines (at least)
declare both DDI A and DDI E to be present in their VBT, and
both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a
real DP->VGA converter.
Currently that is handled by checking the VBT child devices
for conflicts before output probing. But that kind of solution
will not work for the ADL phantom dual eDP VBTs. I think on
those we just have to probe the eDP first. And would be nice
to use the same probe scheme for everything.
On these SKL systems if we probe DDI A first (which is only
natural given it's declared by VBT first) we will get an answer
via AUX, but it came from the DP->VGA converter hooked to the
DDI E, not DDI A. Thus we mistakenly register eDP on DDI A
and screw up the real DP device in DDI E.
To fix this let's check the HPD live state during the eDP probe.
If we got an answer via DPCD but HPD is still down let's assume
we got the answer from someone else.
Smoke tested on all my eDP machines (ilk,hsw-ult,tgl,adl) and
I also tested turning off all HPD hardware prior to loading
i915 to make sure it all comes up properly. And I simulated
the failure path too by not turning on HPD sense and that
correctly gave up on eDP.
I *think* Windows might just fully depend on HPD here. I
couldn't really find any other way they probe displays. And
I did find code where they also check the live state prior
to AUX transfers (something Imre and I have also talked
about perhaps doing). That would also solve this as we'd
not succeed in the eDP probe DPCD reads.
Other solutions I've considered:
- Reintrduce DDI strap checks on SKL. Unfortunately we just
don't have any idea how reliable they are on real production
hardware, and commit 5a2376d1360b ("drm/i915/skl: WaIgnoreDDIAStrap
is forever, always init DDI A") does suggest that not very.
Sadly that commit is very poor in details :/
Also the systems (Asrock B250M-HDV at least) fixed by commit
41e35ffb380b ("drm/i915: Favor last VBT child device with
conflicting AUX ch/DDC pin") might still not work since we
don't know what their straps indicate. Stupid me for not
asking the reporter to check those at the time :(
We have currently two CI machines (fi-cfl-guc,fi-cfl-8700k
both MS-7B54/Z370M) that also declare both DDI A and DDI E
in VBT to use AUX A, and on these the DDI A strap is also
set. There doesn't seem to be anything hooked up to either
DDI however. But given the DDI A strap is wrong on these it
might well be wrong on the Asrock too.
Most other CI machines seem to have straps that generally
match the VBT. fi-kbl-soraka is an exception though as DDI D
strap is not set, but it is declared in VBT as a DP++ port.
No idea if there's a real physical port to go with it or not.
- Some kind of quirk just for the cases where both DDI A and DDI E
are present in VBT. Might be feasible given we've ignored
DDI A in these cases up to now successfully. But feels rather
unsatisfactory, and not very future proof against funny VBTs.
References: https://bugs.freedesktop.org/show_bug.cgi?id=111966
Reviewed-by: Vinod Govindapillai
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 28 +
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index db7b6eaf8c85..1d28a2560ae0 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -45,6 +45,7 @@
#include "g4x_dp.h"
#include "i915_drv.h"
+#include "i915_irq.h"
#include "i915_reg.h"
#include "intel_atomic.h"
#include "intel_audio.h"
@@ -5377,6 +5378,15 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
goto out_vdd_off;
}
+ /*
+* Enable HPD sense for live status check.
+* intel_hpd_irq_setup() will turn it off again
+* if it's no longer needed later.
+*
+* The DPCD probe below will make sure VDD is on.
+*/
+ intel_hpd_enable_detection(encoder);
+
/* Cache DPCD and EDID for edp. */
has_dpcd = intel_edp_init_dpcd(intel_dp);
@@ -5388,6 +5398,24 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
goto out_vdd_off;
}
+ /*
+* VBT and straps are liars. Also check HPD as that seems
+* to be the most reliable piece of information available.
+*/
+ if (!intel_digital_port_connected(encoder)) {
+ /*
+* If this fails, presume the DPCD answer came
+* from some other port using the same AUX CH.
+*
+* FIXME maybe cleaner to check this before the
+* DPCD read? Would need sort out the VDD handling...
+*/
+ drm_info(_priv->drm,
+"[ENCODER:%d:%s] HPD is down, disabling eDP\n",
+
[Intel-gfx] [PATCH v2 2/4] drm/i915: Introduce intel_hpd_enable_detection()
From: Ville Syrjälä
Add a mechanism by which we can enable the HPD sense for
individual encoders.
This will be used during eDP probing to figure out if
anything is actually connected. The normal intel_hpd_irq_setup()
thing doesn't work since we only do that after probing the
outputs, and we only enable HPD sense for encoders that were
successfully probed.
The other idea that crossed my minds was to just turn on
HPD sense for all pins before output probing and let hpd_irq_setup()
clean it up afterwards. But that doesn't work for BXT/GLK where
the HPD invert information comes from the VBT child device.
So looks like this really needs to be per-encoder.
v2: Give it a better name (Jani)
v3: Deal with mtl
Reviewed-by: Vinod Govindapillai #v2
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 199 ++--
drivers/gpu/drm/i915/i915_irq.h | 2 +
2 files changed, 193 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 273ffce9807a..3505fafcfb7b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2988,6 +2988,15 @@ static void ibx_hpd_detection_setup(struct
drm_i915_private *dev_priv)
intel_hpd_hotplug_enables(dev_priv,
ibx_hotplug_enables));
}
+static void ibx_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ intel_uncore_rmw(>uncore, PCH_PORT_HOTPLUG,
+ibx_hotplug_mask(encoder->hpd_pin),
+ibx_hotplug_enables(encoder));
+}
+
static void ibx_hpd_irq_setup(struct drm_i915_private *dev_priv)
{
u32 hotplug_irqs, enabled_irqs;
@@ -3048,6 +3057,15 @@ static void icp_ddi_hpd_detection_setup(struct
drm_i915_private *dev_priv)
intel_hpd_hotplug_enables(dev_priv,
icp_ddi_hotplug_enables));
}
+static void icp_ddi_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ intel_uncore_rmw(>uncore, SHOTPLUG_CTL_DDI,
+icp_ddi_hotplug_mask(encoder->hpd_pin),
+icp_ddi_hotplug_enables(encoder));
+}
+
static void icp_tc_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, SHOTPLUG_CTL_TC,
@@ -3060,6 +3078,21 @@ static void icp_tc_hpd_detection_setup(struct
drm_i915_private *dev_priv)
intel_hpd_hotplug_enables(dev_priv,
icp_tc_hotplug_enables));
}
+static void icp_tc_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ intel_uncore_rmw(>uncore, SHOTPLUG_CTL_TC,
+icp_tc_hotplug_mask(encoder->hpd_pin),
+icp_tc_hotplug_enables(encoder));
+}
+
+static void icp_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ icp_ddi_hpd_enable_detection(encoder);
+ icp_tc_hpd_enable_detection(encoder);
+}
+
static void icp_hpd_irq_setup(struct drm_i915_private *dev_priv)
{
u32 hotplug_irqs, enabled_irqs;
@@ -3105,6 +3138,14 @@ static void dg1_hpd_invert(struct drm_i915_private *i915)
intel_uncore_rmw(>uncore, SOUTH_CHICKEN1, 0, val);
}
+static void dg1_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ dg1_hpd_invert(i915);
+ icp_hpd_enable_detection(encoder);
+}
+
static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
{
dg1_hpd_invert(dev_priv);
@@ -3123,6 +3164,15 @@ static void gen11_tc_hpd_detection_setup(struct
drm_i915_private *dev_priv)
intel_hpd_hotplug_enables(dev_priv,
gen11_hotplug_enables));
}
+static void gen11_tc_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ intel_uncore_rmw(>uncore, GEN11_TC_HOTPLUG_CTL,
+gen11_hotplug_mask(encoder->hpd_pin),
+gen11_hotplug_enables(encoder));
+}
+
static void gen11_tbt_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, GEN11_TBT_HOTPLUG_CTL,
@@ -3135,6 +3185,26 @@ static void gen11_tbt_hpd_detection_setup(struct
drm_i915_private *dev_priv)
intel_hpd_hotplug_enables(dev_priv,
gen11_hotplug_enables));
}
+static void gen11_tbt_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ intel_uncore_rmw(>uncore, GEN11_TBT_HOTPLUG_CTL,
+gen11_hotplug_mask(encoder->hpd_pin),
+gen11_hotplug_enables(encoder));
+}
+
+static void gen11_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 =
[Intel-gfx] [PATCH v2 1/4] drm/i915: Introduce _hotplug_mask()
From: Ville Syrjälä
Pair each _hotplug_enables() function with
a corresponding _hotplug_mask() function so that
we can determine right bits to clear on a per hpd_pin basis.
We'll need this for turning on HPD sense for a specific
encoder rather than just all of them.
v2: Drop the unused 'i915' param (Jani)
v3: Drop the _foo_hotplug_enables() redirection too
v4: Deal with mtp
Cc: Jani Nikula
Reviewed-by: Vinod Govindapillai #v3
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 201 ++--
1 file changed, 137 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index dea1a117f3fa..273ffce9807a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2931,6 +2931,22 @@ static void cherryview_irq_reset(struct drm_i915_private
*dev_priv)
spin_unlock_irq(_priv->irq_lock);
}
+static u32 ibx_hotplug_mask(enum hpd_pin hpd_pin)
+{
+ switch (hpd_pin) {
+ case HPD_PORT_A:
+ return PORTA_HOTPLUG_ENABLE;
+ case HPD_PORT_B:
+ return PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_MASK;
+ case HPD_PORT_C:
+ return PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_MASK;
+ case HPD_PORT_D:
+ return PORTD_HOTPLUG_ENABLE | PORTD_PULSE_DURATION_MASK;
+ default:
+ return 0;
+ }
+}
+
static u32 ibx_hotplug_enables(struct intel_encoder *encoder)
{
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
@@ -2965,13 +2981,10 @@ static void ibx_hpd_detection_setup(struct
drm_i915_private *dev_priv)
* The pulse duration bits are reserved on LPT+.
*/
intel_uncore_rmw(_priv->uncore, PCH_PORT_HOTPLUG,
-PORTA_HOTPLUG_ENABLE |
-PORTB_HOTPLUG_ENABLE |
-PORTC_HOTPLUG_ENABLE |
-PORTD_HOTPLUG_ENABLE |
-PORTB_PULSE_DURATION_MASK |
-PORTC_PULSE_DURATION_MASK |
-PORTD_PULSE_DURATION_MASK,
+ibx_hotplug_mask(HPD_PORT_A) |
+ibx_hotplug_mask(HPD_PORT_B) |
+ibx_hotplug_mask(HPD_PORT_C) |
+ibx_hotplug_mask(HPD_PORT_D),
intel_hpd_hotplug_enables(dev_priv,
ibx_hotplug_enables));
}
@@ -2987,53 +3000,63 @@ static void ibx_hpd_irq_setup(struct drm_i915_private
*dev_priv)
ibx_hpd_detection_setup(dev_priv);
}
-static u32 icp_ddi_hotplug_enables(struct intel_encoder *encoder)
+static u32 icp_ddi_hotplug_mask(enum hpd_pin hpd_pin)
{
- switch (encoder->hpd_pin) {
+ switch (hpd_pin) {
case HPD_PORT_A:
case HPD_PORT_B:
case HPD_PORT_C:
case HPD_PORT_D:
- return SHOTPLUG_CTL_DDI_HPD_ENABLE(encoder->hpd_pin);
+ return SHOTPLUG_CTL_DDI_HPD_ENABLE(hpd_pin);
default:
return 0;
}
}
-static u32 icp_tc_hotplug_enables(struct intel_encoder *encoder)
+static u32 icp_ddi_hotplug_enables(struct intel_encoder *encoder)
{
- switch (encoder->hpd_pin) {
+ return icp_ddi_hotplug_mask(encoder->hpd_pin);
+}
+
+static u32 icp_tc_hotplug_mask(enum hpd_pin hpd_pin)
+{
+ switch (hpd_pin) {
case HPD_PORT_TC1:
case HPD_PORT_TC2:
case HPD_PORT_TC3:
case HPD_PORT_TC4:
case HPD_PORT_TC5:
case HPD_PORT_TC6:
- return ICP_TC_HPD_ENABLE(encoder->hpd_pin);
+ return ICP_TC_HPD_ENABLE(hpd_pin);
default:
return 0;
}
}
+static u32 icp_tc_hotplug_enables(struct intel_encoder *encoder)
+{
+ return icp_tc_hotplug_mask(encoder->hpd_pin);
+}
+
static void icp_ddi_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, SHOTPLUG_CTL_DDI,
-SHOTPLUG_CTL_DDI_HPD_ENABLE(HPD_PORT_A) |
-SHOTPLUG_CTL_DDI_HPD_ENABLE(HPD_PORT_B) |
-SHOTPLUG_CTL_DDI_HPD_ENABLE(HPD_PORT_C) |
-SHOTPLUG_CTL_DDI_HPD_ENABLE(HPD_PORT_D),
+icp_ddi_hotplug_mask(HPD_PORT_A) |
+icp_ddi_hotplug_mask(HPD_PORT_B) |
+icp_ddi_hotplug_mask(HPD_PORT_C) |
+icp_ddi_hotplug_mask(HPD_PORT_D),
intel_hpd_hotplug_enables(dev_priv,
icp_ddi_hotplug_enables));
}
static void icp_tc_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, SHOTPLUG_CTL_TC,
-ICP_TC_HPD_ENABLE(HPD_PORT_TC1) |
-ICP_TC_HPD_ENABLE(HPD_PORT_TC2) |
-ICP_TC_HPD_ENABLE(HPD_PORT_TC3) |
-ICP_TC_HPD_ENABLE(HPD_PORT_TC4) |
-
[Intel-gfx] [PATCH v2 0/4] drm/i915: Check HPD during eDP probe
From: Ville Syrjälä Remainder of the eDP HPD check series, now rebased on top of MTL HPD stuff. Ville Syrjälä (4): drm/i915: Introduce _hotplug_mask() drm/i915: Introduce intel_hpd_enable_detection() drm/i915: Check HPD live state during eDP probe drm/i915: Reuse _hotplug_mask() in .hpd_detection_setup() drivers/gpu/drm/i915/display/intel_dp.c | 28 ++ drivers/gpu/drm/i915/i915_irq.c | 383 +++- drivers/gpu/drm/i915/i915_irq.h | 2 + 3 files changed, 341 insertions(+), 72 deletions(-) -- 2.39.2
Re: [Intel-gfx] 2023 X.Org Foundation Membership deadline for voting in the election
Hi Ricardo, On Mon, Mar 13, 2023 at 04:22:54PM +0100, Ricardo Garcia wrote: > This is a reminder that the deadline for new memberships and renewals > finishes in a couple of weeks. Original email follows. > > Thanks for your attention. I don't know if I'm the only one affected by this issue, but I've just received today two months of e-mails from x.org, including all the reminders aboud membership renewal and election nomination period. This isn't the first time this happens, and the last time I was told there was no automated process to quick the mail queues when errors happen, making mails pile up forever on x.org's side until someone handles it manually. This is something you really want to automate, or at least monitored. > On Wed, 2023-02-15 at 16:58 +0100, Ricardo Garcia wrote: > > The 2023 X.Org Foundation elections are rapidly approaching. We will be > > forwarding the election schedule and nominating process to the > > membership shortly. > > > > Please note that only current members can vote in the upcoming election, > > and that the deadline for new memberships or renewals to vote in the > > upcoming election is 26 March 2023 at 23:59 UTC. > > > > If you are interested in joining the X.Org Foundation or in renewing > > your membership, please visit the membership system site at: > > https://members.x.org/ > > > > Ricardo Garcia, on behalf of the X.Org elections committee -- Regards, Laurent Pinchart
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX timeout for Type-C
On Mon, Apr 17, 2023 at 03:25:34PM +0300, Kandpal, Suraj wrote:
> >
> > On Mon, Apr 17, 2023 at 02:43:25PM +0300, Kandpal, Suraj wrote:
> > > > [...]
> > > > Adding a non-default enable_timeout to the power well descriptor
> > > > would avoid adding more platform checks:
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > > b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > > index 6645eb1911d85..8ca1f34be14c2 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > > @@ -1378,13 +1378,18 @@ static const struct i915_power_well_desc
> > > > xelpd_power_wells_main[] = {
> > > > I915_PW("AUX_C", _pwdoms_aux_c, .hsw.idx =
> > > > ICL_PW_CTL_IDX_AUX_C),
> > > > I915_PW("AUX_D", _pwdoms_aux_d, .hsw.idx =
> > > > XELPD_PW_CTL_IDX_AUX_D),
> > > > I915_PW("AUX_E", _pwdoms_aux_e, .hsw.idx =
> > > > XELPD_PW_CTL_IDX_AUX_E),
> > > > + ),
> > > > + .ops = _aux_power_well_ops,
> > > > + .fixed_enable_delay = true,
> > > > + }, {
> > > > + .instances = _PW_INSTANCES(
> > > > I915_PW("AUX_USBC1", _pwdoms_aux_usbc1,
> > > > .hsw.idx = TGL_PW_CTL_IDX_AUX_TC1),
> > > > I915_PW("AUX_USBC2", _pwdoms_aux_usbc2,
> > > > .hsw.idx = TGL_PW_CTL_IDX_AUX_TC2),
> > > > I915_PW("AUX_USBC3", _pwdoms_aux_usbc3,
> > > > .hsw.idx = TGL_PW_CTL_IDX_AUX_TC3),
> > > > I915_PW("AUX_USBC4", _pwdoms_aux_usbc4,
> > > > .hsw.idx = TGL_PW_CTL_IDX_AUX_TC4),
> > > > ),
> > > > .ops = _aux_power_well_ops,
> > > > - .fixed_enable_delay = true,
> > > > + .enable_timeout = 500,
> > > > }, {
> > > > .instances = _PW_INSTANCES(
> > > > I915_PW("AUX_TBT1", _pwdoms_aux_tbt1,
> > > > .hsw.idx = TGL_PW_CTL_IDX_AUX_TBT1), diff --git
> > > > a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > > > b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > > > index 62bafcbc7937c..930a42c825c36 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > > > @@ -253,6 +253,7 @@ static void
> > > > hsw_wait_for_power_well_enable(struct
> > > > drm_i915_private *dev_priv, {
> > > > const struct i915_power_well_regs *regs =
> > > > power_well->desc->ops->regs;
> > > > int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
> > > > + int timeout = power_well->desc->enable_timeout ? : 1;
> > > >
> > > > /*
> > > >* For some power wells we're not supposed to watch the status
> > > > bit for @@ -266,7 +267,7 @@ static void
> > > > hsw_wait_for_power_well_enable(struct drm_i915_private *dev_priv,
> > > >
> > > > /* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
> > > > if (intel_de_wait_for_set(dev_priv, regs->driver,
> > > > - HSW_PWR_WELL_CTL_STATE(pw_idx), 1)) {
> > > > + HSW_PWR_WELL_CTL_STATE(pw_idx),
> > > > timeout)) {
> > > > drm_dbg_kms(_priv->drm, "%s power well enable
> > > > timeout\n",
> > > > intel_power_well_name(power_well));
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > > > b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > > > index ba7cb977e7c7f..fd5acf68503e1 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > > > @@ -110,6 +110,8 @@ struct i915_power_well_desc {
> > > >* Thunderbolt mode.
> > > >*/
> > > > u16 is_tc_tbt:1;
> > > > + /* Enable timeout if bigger than the default 1ms. */
> > > > + u16 enable_timeout;
> > > > };
> > > >
> > >
> > > How would we make sure that this timeout only applies to ADLS in that
> > > case as that's whom the workaround is for?
> >
> > The HSD is for display 13 ADL, that is ADL-P/M/N. The ADL-S power wells are
> > described separately in adls_power_wells.
>
> Right sorry meant ADLP so how do we make sure this is enabled only for the
> required
> Display version
It is enabled only for those. xelpd_power_wells_main is used by display 13
platforms.
> Regards,
> Suraj Kandpal
> >
> > --Imre
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX timeout for Type-C
>
> On Mon, Apr 17, 2023 at 02:43:25PM +0300, Kandpal, Suraj wrote:
> > > [...]
> > > Adding a non-default enable_timeout to the power well descriptor
> > > would avoid adding more platform checks:
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > index 6645eb1911d85..8ca1f34be14c2 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > @@ -1378,13 +1378,18 @@ static const struct i915_power_well_desc
> > > xelpd_power_wells_main[] = {
> > > I915_PW("AUX_C", _pwdoms_aux_c, .hsw.idx =
> ICL_PW_CTL_IDX_AUX_C),
> > > I915_PW("AUX_D", _pwdoms_aux_d, .hsw.idx =
> XELPD_PW_CTL_IDX_AUX_D),
> > > I915_PW("AUX_E", _pwdoms_aux_e, .hsw.idx =
> > > XELPD_PW_CTL_IDX_AUX_E),
> > > + ),
> > > + .ops = _aux_power_well_ops,
> > > + .fixed_enable_delay = true,
> > > + }, {
> > > + .instances = _PW_INSTANCES(
> > > I915_PW("AUX_USBC1", _pwdoms_aux_usbc1,
> > > .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC1),
> > > I915_PW("AUX_USBC2", _pwdoms_aux_usbc2,
> > > .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC2),
> > > I915_PW("AUX_USBC3", _pwdoms_aux_usbc3,
> > > .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC3),
> > > I915_PW("AUX_USBC4", _pwdoms_aux_usbc4,
> > > .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC4),
> > > ),
> > > .ops = _aux_power_well_ops,
> > > - .fixed_enable_delay = true,
> > > + .enable_timeout = 500,
> > > }, {
> > > .instances = _PW_INSTANCES(
> > > I915_PW("AUX_TBT1", _pwdoms_aux_tbt1,
> > > .hsw.idx = TGL_PW_CTL_IDX_AUX_TBT1), diff --git
> > > a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > > b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > > index 62bafcbc7937c..930a42c825c36 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > > @@ -253,6 +253,7 @@ static void
> > > hsw_wait_for_power_well_enable(struct
> > > drm_i915_private *dev_priv, {
> > > const struct i915_power_well_regs *regs = power_well->desc->ops-
> >regs;
> > > int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
> > > + int timeout = power_well->desc->enable_timeout ? : 1;
> > >
> > > /*
> > >* For some power wells we're not supposed to watch the status
> > > bit for @@ -266,7 +267,7 @@ static void
> > > hsw_wait_for_power_well_enable(struct drm_i915_private *dev_priv,
> > >
> > > /* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
> > > if (intel_de_wait_for_set(dev_priv, regs->driver,
> > > - HSW_PWR_WELL_CTL_STATE(pw_idx), 1)) {
> > > + HSW_PWR_WELL_CTL_STATE(pw_idx),
> > > + timeout)) {
> > > drm_dbg_kms(_priv->drm, "%s power well enable
> timeout\n",
> > > intel_power_well_name(power_well));
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > > b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > > index ba7cb977e7c7f..fd5acf68503e1 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > > @@ -110,6 +110,8 @@ struct i915_power_well_desc {
> > >* Thunderbolt mode.
> > >*/
> > > u16 is_tc_tbt:1;
> > > + /* Enable timeout if bigger than the default 1ms. */
> > > + u16 enable_timeout;
> > > };
> > >
> >
> > How would we make sure that this timeout only applies to ADLS in that
> > case as that's whom the workaround is for?
>
> The HSD is for display 13 ADL, that is ADL-P/M/N. The ADL-S power wells are
> described separately in adls_power_wells.
Right sorry meant ADLP so how do we make sure this is enabled only for the
required
Display version
Regards,
Suraj Kandpal
>
> --Imre
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mtl: Define MOCS and PAT tables for MTL (rev5)
== Series Details == Series: drm/i915/mtl: Define MOCS and PAT tables for MTL (rev5) URL : https://patchwork.freedesktop.org/series/115980/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13020 -> Patchwork_115980v5 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_115980v5 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_115980v5, 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_115980v5/index.html Participating hosts (35 -> 36) -- Additional (2): fi-tgl-1115g4 bat-adls-5 Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_115980v5: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-apl-guc: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/fi-apl-guc/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/fi-apl-guc/igt@i915_selftest@l...@execlists.html - fi-glk-j4005: [PASS][3] -> [ABORT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/fi-glk-j4005/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/fi-glk-j4005/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_engines: - fi-glk-j4005: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/fi-glk-j4005/igt@i915_selftest@live@gt_engines.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/fi-glk-j4005/igt@i915_selftest@live@gt_engines.html * igt@i915_selftest@live@gt_mocs: - fi-glk-j4005: [PASS][7] -> [DMESG-FAIL][8] +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/fi-glk-j4005/igt@i915_selftest@live@gt_mocs.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/fi-glk-j4005/igt@i915_selftest@live@gt_mocs.html * igt@i915_selftest@live@workarounds: - fi-apl-guc: [PASS][9] -> [DMESG-FAIL][10] +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/fi-apl-guc/igt@i915_selftest@l...@workarounds.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/fi-apl-guc/igt@i915_selftest@l...@workarounds.html Known issues Here are the changes found in Patchwork_115980v5 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adls-5: NOTRUN -> [SKIP][11] ([i915#7456]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/bat-adls-5/igt@debugfs_t...@basic-hwmon.html - fi-tgl-1115g4: NOTRUN -> [SKIP][12] ([i915#7456]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: NOTRUN -> [ABORT][13] ([i915#6687] / [i915#7978]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - fi-tgl-1115g4: NOTRUN -> [SKIP][14] ([i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-tgl-1115g4: NOTRUN -> [SKIP][15] ([i915#4613]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/fi-tgl-1115g4/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@random-engines: - bat-adls-5: NOTRUN -> [SKIP][16] ([i915#4613]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/bat-adls-5/igt@gem_lmem_swapp...@random-engines.html * igt@gem_ringfill@basic-all: - bat-rpls-2: [PASS][17] -> [TIMEOUT][18] ([i915#7937]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13020/bat-rpls-2/igt@gem_ringf...@basic-all.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/bat-rpls-2/igt@gem_ringf...@basic-all.html * igt@gem_tiled_pread_basic: - bat-adls-5: NOTRUN -> [SKIP][19] ([i915#3282]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/bat-adls-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-tgl-1115g4: NOTRUN -> [SKIP][20] ([i915#7561]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115980v5/fi-tgl-1115g4/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-dg2-11:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Define MOCS and PAT tables for MTL (rev5)
== Series Details == Series: drm/i915/mtl: Define MOCS and PAT tables for MTL (rev5) URL : https://patchwork.freedesktop.org/series/115980/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/mtl: Define MOCS and PAT tables for MTL (rev5)
== Series Details == Series: drm/i915/mtl: Define MOCS and PAT tables for MTL (rev5) URL : https://patchwork.freedesktop.org/series/115980/ State : warning == Summary == Error: dim checkpatch failed 04d4f946f5f0 drm/i915/mtl: Set has_llc=0 f44a8a034a83 drm/i915/mtl: Define MOCS and PAT tables for MTL -:63: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #63: FILE: drivers/gpu/drm/i915/gt/intel_gtt.c:486: + +} total: 0 errors, 0 warnings, 1 checks, 247 lines checked 5496af3927f8 drm/i915/mtl: Add PTE encode function -:151: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #151: FILE: drivers/gpu/drm/i915/gt/intel_ggtt.c:229: + GEM_BUG_ON(addr & ~GEN12_GGTT_PTE_ADDR_MASK); total: 0 errors, 1 warnings, 0 checks, 164 lines checked 72e4d658a8e9 drm/i915/mtl: workaround coherency issue for Media b9a188850588 drm/i915/mtl: end support for set caching ioctl eaa559214e8c drm/i915: preparation for using PAT index -:422: CHECK:LINE_SPACING: Please don't use multiple blank lines #422: FILE: drivers/gpu/drm/i915/selftests/mock_gem_device.c:186: + + total: 0 errors, 0 warnings, 1 checks, 335 lines checked 932e5c4abaa6 drm/i915: use pat_index instead of cache_level -:22: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #22: cached, uncached, or writethrough. For these simple cases, using cache_level -:651: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #651: FILE: drivers/gpu/drm/i915/gt/gen8_ppgtt.c:873: + i915_gem_get_pat_index(vm->i915, + I915_CACHE_NONE)); -:921: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #921: FILE: drivers/gpu/drm/i915/gt/intel_ggtt.c:1303: +i915_gem_get_pat_index(vm->i915, + I915_CACHE_NONE), -:1619: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #1619: FILE: drivers/gpu/drm/i915/i915_gem.c:424: + i915_gem_object_get_dma_address(obj, + offset >> PAGE_SHIFT), -:1634: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #1634: FILE: drivers/gpu/drm/i915/i915_gem.c:606: + i915_gem_object_get_dma_address(obj, + offset >> PAGE_SHIFT), -:1652: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #1652: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:1121: + i915_gem_get_pat_index(gt->i915, + I915_CACHE_NONE), -:1658: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #1658: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:1126: + i915_gem_get_pat_index(gt->i915, + I915_CACHE_NONE), -:1776: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #1776: FILE: drivers/gpu/drm/i915/selftests/i915_gem.c:62: +i915_gem_get_pat_index(i915, + I915_CACHE_NONE), -:1822: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #1822: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:363: +i915_gem_get_pat_index(vm->i915, +I915_CACHE_NONE), -:1834: ERROR:CODE_INDENT: code indent should use tabs where possible #1834: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:1384: +^I^I^I^I^II915_CACHE_NONE),$ -:1834: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #1834: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:1384: +i915_gem_get_pat_index(i915, + I915_CACHE_NONE), -:1868: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #1868: FILE: drivers/gpu/drm/i915/selftests/intel_memory_region.c:1075: + i915_gem_get_pat_index(i915, + I915_CACHE_NONE), total: 1 errors, 1 warnings, 10 checks, 1599 lines checked e50cbe9097b5 drm/i915: Allow user to set cache at BO creation
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX timeout for Type-C
On Mon, Apr 17, 2023 at 02:43:25PM +0300, Kandpal, Suraj wrote:
> > [...]
> > Adding a non-default enable_timeout to the power well descriptor would
> > avoid adding more platform checks:
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > index 6645eb1911d85..8ca1f34be14c2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > @@ -1378,13 +1378,18 @@ static const struct i915_power_well_desc
> > xelpd_power_wells_main[] = {
> > I915_PW("AUX_C", _pwdoms_aux_c, .hsw.idx =
> > ICL_PW_CTL_IDX_AUX_C),
> > I915_PW("AUX_D", _pwdoms_aux_d, .hsw.idx =
> > XELPD_PW_CTL_IDX_AUX_D),
> > I915_PW("AUX_E", _pwdoms_aux_e, .hsw.idx =
> > XELPD_PW_CTL_IDX_AUX_E),
> > + ),
> > + .ops = _aux_power_well_ops,
> > + .fixed_enable_delay = true,
> > + }, {
> > + .instances = _PW_INSTANCES(
> > I915_PW("AUX_USBC1", _pwdoms_aux_usbc1, .hsw.idx
> > = TGL_PW_CTL_IDX_AUX_TC1),
> > I915_PW("AUX_USBC2", _pwdoms_aux_usbc2, .hsw.idx
> > = TGL_PW_CTL_IDX_AUX_TC2),
> > I915_PW("AUX_USBC3", _pwdoms_aux_usbc3, .hsw.idx
> > = TGL_PW_CTL_IDX_AUX_TC3),
> > I915_PW("AUX_USBC4", _pwdoms_aux_usbc4, .hsw.idx
> > = TGL_PW_CTL_IDX_AUX_TC4),
> > ),
> > .ops = _aux_power_well_ops,
> > - .fixed_enable_delay = true,
> > + .enable_timeout = 500,
> > }, {
> > .instances = _PW_INSTANCES(
> > I915_PW("AUX_TBT1", _pwdoms_aux_tbt1,
> > .hsw.idx = TGL_PW_CTL_IDX_AUX_TBT1), diff --git
> > a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > index 62bafcbc7937c..930a42c825c36 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > @@ -253,6 +253,7 @@ static void hsw_wait_for_power_well_enable(struct
> > drm_i915_private *dev_priv, {
> > const struct i915_power_well_regs *regs = power_well->desc->ops->regs;
> > int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
> > + int timeout = power_well->desc->enable_timeout ? : 1;
> >
> > /*
> >* For some power wells we're not supposed to watch the status bit
> > for @@ -266,7 +267,7 @@ static void
> > hsw_wait_for_power_well_enable(struct drm_i915_private *dev_priv,
> >
> > /* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
> > if (intel_de_wait_for_set(dev_priv, regs->driver,
> > - HSW_PWR_WELL_CTL_STATE(pw_idx), 1)) {
> > + HSW_PWR_WELL_CTL_STATE(pw_idx), timeout)) {
> > drm_dbg_kms(_priv->drm, "%s power well enable timeout\n",
> > intel_power_well_name(power_well));
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > index ba7cb977e7c7f..fd5acf68503e1 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> > @@ -110,6 +110,8 @@ struct i915_power_well_desc {
> >* Thunderbolt mode.
> >*/
> > u16 is_tc_tbt:1;
> > + /* Enable timeout if bigger than the default 1ms. */
> > + u16 enable_timeout;
> > };
> >
>
> How would we make sure that this timeout only applies to ADLS in that
> case as that's whom the workaround is for?
The HSD is for display 13 ADL, that is ADL-P/M/N. The ADL-S power wells
are described separately in adls_power_wells.
--Imre
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX timeout for Type-C
> -Original Message-
> From: Deak, Imre
> Sent: Monday, April 17, 2023 4:58 PM
> To: Jani Nikula
> Cc: Kandpal, Suraj ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX timeout
> for Type-C
>
> On Mon, Apr 17, 2023 at 01:56:12PM +0300, Jani Nikula wrote:
> > On Mon, 17 Apr 2023, "Kandpal, Suraj" wrote:
> > >> -Original Message-
> > >> From: Jani Nikula
> > >> Sent: Monday, April 17, 2023 4:04 PM
> > >> To: Kandpal, Suraj ; intel-
> > >> g...@lists.freedesktop.org
> > >> Subject: RE: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX
> > >> timeout for Type-C
> > >>
> > >> On Mon, 17 Apr 2023, "Kandpal, Suraj"
> wrote:
> > >> >> On Wed, 05 Apr 2023, Suraj Kandpal
> wrote:
> > >> >> > Type-C PHYs are taking longer than expected for Aux IO Power
> Enabling.
> > >> >> > Workaround: Increase the timeout.
> > >> >> >
> > >> >> > WA_14017248603: adlp
> > >> >> > Bspec: 55480
> > >> >> >
> > >> >> > ---v2
> > >> >> > -change style on how we mention WA [Ankit] -fix bat error
> > >> >> >
> > >> >> > Signed-off-by: Suraj Kandpal
> > >> >> > ---
> > >> >> > .../i915/display/intel_display_power_well.c | 30
> ++-
> > >> >> > 1 file changed, 29 insertions(+), 1 deletion(-)
> > >> >> >
> > >> >> > diff --git
> > >> >> > a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > >> >> > b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > >> >> > index 62bafcbc7937..52f595929a18 100644
> > >> >> > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > >> >> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > >> >> > @@ -489,6 +489,34 @@ static void icl_tc_cold_exit(struct
> > >> >> drm_i915_private *i915)
> > >> >> > "succeeded");
> > >> >> > }
> > >> >> >
> > >> >> > +static void
> > >> >> > +adl_aux_wait_for_power_well_enable(struct drm_i915_private
> *i915,
> > >> >> > + struct i915_power_well
> *power_well,
> > >> >> > + bool timeout_expected) {
> > >> >> > + const struct i915_power_well_regs *regs =
> > >> >> > +power_well->desc->ops-
> > >> >> >regs;
> > >> >> > + enum phy phy = icl_aux_pw_to_phy(i915, power_well);
> > >> >> > + int pw_idx = i915_power_well_instance(power_well)-
> >hsw.idx;
> > >> >> > +
> > >> >> > + /*
> > >> >> > +* WA_14017248603: adlp
> > >> >> > +* Type-C Phy are taking longer than expected for AUX IO
> > >> >> > +Power
> > >> >> Enabling.
> > >> >> > +* Increase timeout to 500ms.
> > >> >> > +*/
> > >> >> > + if (IS_ALDERLAKE_P(i915) && intel_phy_is_tc(i915, phy)) {
> > >> >> > + if (intel_de_wait_for_set(i915, regs->driver,
> > >> >> > +
> > >> >> HSW_PWR_WELL_CTL_STATE(pw_idx), 500)) {
> > >> >> > + drm_dbg_kms(>drm, "%s power well
> enable
> > >> >> timeout\n",
> > >> >> > +
> intel_power_well_name(power_well));
> > >> >> > +
> > >> >> > + drm_WARN_ON(>drm,
> !timeout_expected);
> > >> >> > + }
> > >> >> > + return;
> > >> >> > + }
> > >> >> > +
> > >> >> > + hsw_wait_for_power_well_enable(i915, power_well,
> > >> >> timeout_expected);
> > >> >> > +}
> > >> >>
> > >> >> Please don't duplicate the function and the wait like this.
> > >> >>
> > >> >> Something like this is sufficient:
> > >> >>
> > >> >>
> > >> >> @@ -252,7 +252,9 @@ static void
> > >> hsw_wait_for_power_well_enable(struct
> > >> >> drm_i915_private *dev_priv,
> > >> >> bool timeout_expected)
> > >> >> {
> > >> >> const struct i915_power_well_regs *regs =
> > >> >> power_well->desc->ops-
> > >> >> >regs;
> > >> >> + enum phy phy = icl_aux_pw_to_phy(i915, power_well);
> > >> >> int pw_idx = i915_power_well_instance(power_well)-
> >hsw.idx;
> > >> >> + int timeout = 1;
> > >> >>
> > >> >> /*
> > >> >>* For some power wells we're not supposed to watch the
> status
> > >> >> bit for @@ -264,9 +266,13 @@ static void
> > >> >> hsw_wait_for_power_well_enable(struct drm_i915_private
> *dev_priv,
> > >> >> return;
> > >> >> }
> > >> >>
> > >> >> + /* WA_14017248603: adlp */
> > >> >> + if (IS_ALDERLAKE_P(i915) && intel_phy_is_tc(i915, phy))
> > >> >
> > >> > I did try this but it ends up throwing a kernel null pointer
> > >> > error at intel_phy_is_tc which made me float the version of code I did.
> > >>
> > >> Please explain what causes it, and how your version avoids it.
> > >>
> > >
> > > icl_aux_pw_to_phy is called is hsw_wait_for_power_well is called
> > > everywhere where its not possible for aux_pw to phy conversion is not
> possible with this change we only get the phy for adls version.
> > > Will address this is next version.
> >
> > Cc: Imre for input
> >
> > Maybe pass the timeout to hsw_wait_for_power_well_enable() as
> parameter?
> > Other ideas?
>
> Adding a non-default enable_timeout to the power well
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX timeout for Type-C
>
> On Mon, Apr 17, 2023 at 01:56:12PM +0300, Jani Nikula wrote:
> > On Mon, 17 Apr 2023, "Kandpal, Suraj" wrote:
> > >> -Original Message-
> > >> From: Jani Nikula
> > >> Sent: Monday, April 17, 2023 4:04 PM
> > >> To: Kandpal, Suraj ; intel-
> > >> g...@lists.freedesktop.org
> > >> Subject: RE: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX
> > >> timeout for Type-C
> > >>
> > >> On Mon, 17 Apr 2023, "Kandpal, Suraj"
> wrote:
> > >> >> On Wed, 05 Apr 2023, Suraj Kandpal
> wrote:
> > >> >> > Type-C PHYs are taking longer than expected for Aux IO Power
> Enabling.
> > >> >> > Workaround: Increase the timeout.
> > >> >> >
> > >> >> > WA_14017248603: adlp
> > >> >> > Bspec: 55480
> > >> >> >
> > >> >> > ---v2
> > >> >> > -change style on how we mention WA [Ankit] -fix bat error
> > >> >> >
> > >> >> > Signed-off-by: Suraj Kandpal
> > >> >> > ---
> > >> >> > .../i915/display/intel_display_power_well.c | 30
> ++-
> > >> >> > 1 file changed, 29 insertions(+), 1 deletion(-)
> > >> >> >
> > >> >> > diff --git
> > >> >> > a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > >> >> > b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > >> >> > index 62bafcbc7937..52f595929a18 100644
> > >> >> > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > >> >> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > >> >> > @@ -489,6 +489,34 @@ static void icl_tc_cold_exit(struct
> > >> >> drm_i915_private *i915)
> > >> >> > "succeeded");
> > >> >> > }
> > >> >> >
> > >> >> > +static void
> > >> >> > +adl_aux_wait_for_power_well_enable(struct drm_i915_private
> *i915,
> > >> >> > + struct i915_power_well
> *power_well,
> > >> >> > + bool timeout_expected) {
> > >> >> > + const struct i915_power_well_regs *regs =
> > >> >> > +power_well->desc->ops-
> > >> >> >regs;
> > >> >> > + enum phy phy = icl_aux_pw_to_phy(i915, power_well);
> > >> >> > + int pw_idx = i915_power_well_instance(power_well)-
> >hsw.idx;
> > >> >> > +
> > >> >> > + /*
> > >> >> > +* WA_14017248603: adlp
> > >> >> > +* Type-C Phy are taking longer than expected for AUX IO
> > >> >> > +Power
> > >> >> Enabling.
> > >> >> > +* Increase timeout to 500ms.
> > >> >> > +*/
> > >> >> > + if (IS_ALDERLAKE_P(i915) && intel_phy_is_tc(i915, phy)) {
> > >> >> > + if (intel_de_wait_for_set(i915, regs->driver,
> > >> >> > +
> > >> >> HSW_PWR_WELL_CTL_STATE(pw_idx), 500)) {
> > >> >> > + drm_dbg_kms(>drm, "%s power well
> enable
> > >> >> timeout\n",
> > >> >> > +
> intel_power_well_name(power_well));
> > >> >> > +
> > >> >> > + drm_WARN_ON(>drm,
> !timeout_expected);
> > >> >> > + }
> > >> >> > + return;
> > >> >> > + }
> > >> >> > +
> > >> >> > + hsw_wait_for_power_well_enable(i915, power_well,
> > >> >> timeout_expected);
> > >> >> > +}
> > >> >>
> > >> >> Please don't duplicate the function and the wait like this.
> > >> >>
> > >> >> Something like this is sufficient:
> > >> >>
> > >> >>
> > >> >> @@ -252,7 +252,9 @@ static void
> > >> hsw_wait_for_power_well_enable(struct
> > >> >> drm_i915_private *dev_priv,
> > >> >> bool timeout_expected)
> > >> >> {
> > >> >> const struct i915_power_well_regs *regs =
> > >> >> power_well->desc->ops-
> > >> >> >regs;
> > >> >> + enum phy phy = icl_aux_pw_to_phy(i915, power_well);
> > >> >> int pw_idx = i915_power_well_instance(power_well)-
> >hsw.idx;
> > >> >> + int timeout = 1;
> > >> >>
> > >> >> /*
> > >> >>* For some power wells we're not supposed to watch the
> status
> > >> >> bit for @@ -264,9 +266,13 @@ static void
> > >> >> hsw_wait_for_power_well_enable(struct drm_i915_private
> *dev_priv,
> > >> >> return;
> > >> >> }
> > >> >>
> > >> >> + /* WA_14017248603: adlp */
> > >> >> + if (IS_ALDERLAKE_P(i915) && intel_phy_is_tc(i915, phy))
> > >> >
> > >> > I did try this but it ends up throwing a kernel null pointer
> > >> > error at intel_phy_is_tc which made me float the version of code I did.
> > >>
> > >> Please explain what causes it, and how your version avoids it.
> > >>
> > >
> > > icl_aux_pw_to_phy is called is hsw_wait_for_power_well is called
> > > everywhere where its not possible for aux_pw to phy conversion is not
> possible with this change we only get the phy for adls version.
> > > Will address this is next version.
> >
> > Cc: Imre for input
> >
> > Maybe pass the timeout to hsw_wait_for_power_well_enable() as
> parameter?
> > Other ideas?
>
> Adding a non-default enable_timeout to the power well descriptor would
> avoid adding more platform checks:
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> index 6645eb1911d85..8ca1f34be14c2 100644
> ---
Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with the mm-stable tree
On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote: > Note there was a ppc compile fail, which is why we pushed the ttm revert. > That /should/ be fixed now, but would be good if you can confirm? I don't have any PowerPC toolchains set up - I guess one of the community builders might have checked? signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX timeout for Type-C
On Mon, Apr 17, 2023 at 01:56:12PM +0300, Jani Nikula wrote:
> On Mon, 17 Apr 2023, "Kandpal, Suraj" wrote:
> >> -Original Message-
> >> From: Jani Nikula
> >> Sent: Monday, April 17, 2023 4:04 PM
> >> To: Kandpal, Suraj ; intel-
> >> g...@lists.freedesktop.org
> >> Subject: RE: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX timeout
> >> for Type-C
> >>
> >> On Mon, 17 Apr 2023, "Kandpal, Suraj" wrote:
> >> >> On Wed, 05 Apr 2023, Suraj Kandpal wrote:
> >> >> > Type-C PHYs are taking longer than expected for Aux IO Power Enabling.
> >> >> > Workaround: Increase the timeout.
> >> >> >
> >> >> > WA_14017248603: adlp
> >> >> > Bspec: 55480
> >> >> >
> >> >> > ---v2
> >> >> > -change style on how we mention WA [Ankit] -fix bat error
> >> >> >
> >> >> > Signed-off-by: Suraj Kandpal
> >> >> > ---
> >> >> > .../i915/display/intel_display_power_well.c | 30
> >> >> > ++-
> >> >> > 1 file changed, 29 insertions(+), 1 deletion(-)
> >> >> >
> >> >> > diff --git
> >> >> > a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> >> >> > b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> >> >> > index 62bafcbc7937..52f595929a18 100644
> >> >> > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> >> >> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> >> >> > @@ -489,6 +489,34 @@ static void icl_tc_cold_exit(struct
> >> >> drm_i915_private *i915)
> >> >> > "succeeded");
> >> >> > }
> >> >> >
> >> >> > +static void
> >> >> > +adl_aux_wait_for_power_well_enable(struct drm_i915_private *i915,
> >> >> > +struct i915_power_well *power_well,
> >> >> > +bool timeout_expected)
> >> >> > +{
> >> >> > + const struct i915_power_well_regs *regs = power_well->desc->ops-
> >> >> >regs;
> >> >> > + enum phy phy = icl_aux_pw_to_phy(i915, power_well);
> >> >> > + int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
> >> >> > +
> >> >> > + /*
> >> >> > + * WA_14017248603: adlp
> >> >> > + * Type-C Phy are taking longer than expected for AUX IO Power
> >> >> Enabling.
> >> >> > + * Increase timeout to 500ms.
> >> >> > + */
> >> >> > + if (IS_ALDERLAKE_P(i915) && intel_phy_is_tc(i915, phy)) {
> >> >> > + if (intel_de_wait_for_set(i915, regs->driver,
> >> >> > +
> >> >> HSW_PWR_WELL_CTL_STATE(pw_idx), 500)) {
> >> >> > + drm_dbg_kms(>drm, "%s power well enable
> >> >> timeout\n",
> >> >> > + intel_power_well_name(power_well));
> >> >> > +
> >> >> > + drm_WARN_ON(>drm, !timeout_expected);
> >> >> > + }
> >> >> > + return;
> >> >> > + }
> >> >> > +
> >> >> > + hsw_wait_for_power_well_enable(i915, power_well,
> >> >> timeout_expected);
> >> >> > +}
> >> >>
> >> >> Please don't duplicate the function and the wait like this.
> >> >>
> >> >> Something like this is sufficient:
> >> >>
> >> >>
> >> >> @@ -252,7 +252,9 @@ static void
> >> hsw_wait_for_power_well_enable(struct
> >> >> drm_i915_private *dev_priv,
> >> >>bool timeout_expected)
> >> >> {
> >> >> const struct i915_power_well_regs *regs = power_well->desc->ops-
> >> >> >regs;
> >> >> + enum phy phy = icl_aux_pw_to_phy(i915, power_well);
> >> >> int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
> >> >> + int timeout = 1;
> >> >>
> >> >> /*
> >> >> * For some power wells we're not supposed to watch the status
> >> >> bit
> >> >> for @@ -264,9 +266,13 @@ static void
> >> >> hsw_wait_for_power_well_enable(struct drm_i915_private *dev_priv,
> >> >> return;
> >> >> }
> >> >>
> >> >> + /* WA_14017248603: adlp */
> >> >> + if (IS_ALDERLAKE_P(i915) && intel_phy_is_tc(i915, phy))
> >> >
> >> > I did try this but it ends up throwing a kernel null pointer error at
> >> > intel_phy_is_tc which made me float the version of code I did.
> >>
> >> Please explain what causes it, and how your version avoids it.
> >>
> >
> > icl_aux_pw_to_phy is called is hsw_wait_for_power_well is called everywhere
> > where its not possible for aux_pw to phy
> > conversion is not possible with this change we only get the phy for adls
> > version.
> > Will address this is next version.
>
> Cc: Imre for input
>
> Maybe pass the timeout to hsw_wait_for_power_well_enable() as parameter?
> Other ideas?
Adding a non-default enable_timeout to the power well descriptor would
avoid adding more platform checks:
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 6645eb1911d85..8ca1f34be14c2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1378,13 +1378,18 @@ static const struct i915_power_well_desc
Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c
On 14/04/2023 11:45, Zhao Liu wrote:
Hi Tvrtko,
On Wed, Apr 12, 2023 at 04:45:13PM +0100, Tvrtko Ursulin wrote:
[snip]
[snip]
However I am unsure if disabling pagefaulting is needed or not. Thomas,
Matt, being the last to touch this area, perhaps you could have a look?
Because I notice we have a fallback iomap path which still uses
io_mapping_map_atomic_wc. So if kmap_atomic to kmap_local conversion is
safe, does the iomap side also needs converting to
io_mapping_map_local_wc? Or they have separate requirements?
AFAIK, the requirements for io_mapping_map_local_wc() are the same as for
kmap_local_page(): the kernel virtual address is _only_ valid in the caller
context, and map/unmap nesting must be done in stack-based ordering (LIFO).
I think a follow up patch could safely switch to io_mapping_map_local_wc() /
io_mapping_unmap_local_wc since the address is local to context.
However, not being an expert, reading your note now I suspect that I'm missing
something. Can I ask why you think that page-faults disabling might be
necessary?
I am not saying it is, was just unsure and wanted some people who worked on
this code most recently to take a look and confirm.
I guess it will work since the copying is done like this anyway:
/*
* This is the fast path and we cannot handle a pagefault
* whilst holding the struct mutex lest the user pass in the
* relocations contained within a mmaped bo. For in such a case
* we, the page fault handler would call i915_gem_fault() and
* we would try to acquire the struct mutex again. Obviously
* this is bad and so lockdep complains vehemently.
*/
pagefault_disable();
copied = __copy_from_user_inatomic(r, urelocs, count *
sizeof(r[0]));
pagefault_enable();
if (unlikely(copied)) {
remain = -EFAULT;
goto out;
}
Comment is a bit outdated since we don't use that global "struct mutex" any
longer, but in any case, if there is a page fault on the mapping where we need to recurse
into i915 again to satisfy if, we seem to have code already to handle it. So kmap_local
conversion I *think* can't regress anything.
Thanks for your explanation!
Patch to convert the io_mapping_map_atomic_wc can indeed come later.
Okay, I will also look at this.
In terms of logistics - if we landed this series to out branch it would be
queued only for 6.5. Would that work for you?
Yeah, it's ok for me. But could I ask, did I miss the 6.4 merge time?
Yes, but just because we failed to review and merge in time, not because
you did not provide patches in time.
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX timeout for Type-C
On Mon, 17 Apr 2023, "Kandpal, Suraj" wrote:
> drm/i915/display: Increase AUX timeout
>> for Type-C
>>
>> On Mon, 17 Apr 2023, "Kandpal, Suraj" wrote:
>> >> -Original Message-
>> >> From: Jani Nikula
>> >> Sent: Monday, April 17, 2023 4:04 PM
>> >> To: Kandpal, Suraj ; intel-
>> >> g...@lists.freedesktop.org
>> >> Subject: RE: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX
>> >> timeout for Type-C
>> >>
>> >> On Mon, 17 Apr 2023, "Kandpal, Suraj" wrote:
>> >> >> On Wed, 05 Apr 2023, Suraj Kandpal
>> wrote:
>> >> >> > Type-C PHYs are taking longer than expected for Aux IO Power
>> Enabling.
>> >> >> > Workaround: Increase the timeout.
>> >> >> >
>> >> >> > WA_14017248603: adlp
>> >> >> > Bspec: 55480
>> >> >> >
>> >> >> > ---v2
>> >> >> > -change style on how we mention WA [Ankit] -fix bat error
>> >> >> >
>> >> >> > Signed-off-by: Suraj Kandpal
>> >> >> > ---
>> >> >> > .../i915/display/intel_display_power_well.c | 30
>> ++-
>> >> >> > 1 file changed, 29 insertions(+), 1 deletion(-)
>> >> >> >
>> >> >> > diff --git
>> >> >> > a/drivers/gpu/drm/i915/display/intel_display_power_well.c
>> >> >> > b/drivers/gpu/drm/i915/display/intel_display_power_well.c
>> >> >> > index 62bafcbc7937..52f595929a18 100644
>> >> >> > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
>> >> >> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
>> >> >> > @@ -489,6 +489,34 @@ static void icl_tc_cold_exit(struct
>> >> >> drm_i915_private *i915)
>> >> >> > "succeeded");
>> >> >> > }
>> >> >> >
>> >> >> > +static void
>> >> >> > +adl_aux_wait_for_power_well_enable(struct drm_i915_private
>> *i915,
>> >> >> > + struct i915_power_well
>> *power_well,
>> >> >> > + bool timeout_expected)
>> >> >> > +{
>> >> >> > +const struct i915_power_well_regs *regs =
>> >> >> > +power_well->desc->ops-
>> >> >> >regs;
>> >> >> > +enum phy phy = icl_aux_pw_to_phy(i915, power_well);
>> >> >> > +int pw_idx = i915_power_well_instance(power_well)-
>> >hsw.idx;
>> >> >> > +
>> >> >> > +/*
>> >> >> > + * WA_14017248603: adlp
>> >> >> > + * Type-C Phy are taking longer than expected for AUX IO
>> Power
>> >> >> Enabling.
>> >> >> > + * Increase timeout to 500ms.
>> >> >> > + */
>> >> >> > +if (IS_ALDERLAKE_P(i915) && intel_phy_is_tc(i915, phy)) {
>> >> >> > +if (intel_de_wait_for_set(i915, regs->driver,
>> >> >> > +
>> >> >> HSW_PWR_WELL_CTL_STATE(pw_idx), 500)) {
>> >> >> > +drm_dbg_kms(>drm, "%s power well
>> enable
>> >> >> timeout\n",
>> >> >> > +
>> intel_power_well_name(power_well));
>> >> >> > +
>> >> >> > +drm_WARN_ON(>drm,
>> !timeout_expected);
>> >> >> > +}
>> >> >> > +return;
>> >> >> > +}
>> >> >> > +
>> >> >> > +hsw_wait_for_power_well_enable(i915, power_well,
>> >> >> timeout_expected);
>> >> >> > +}
>> >> >>
>> >> >> Please don't duplicate the function and the wait like this.
>> >> >>
>> >> >> Something like this is sufficient:
>> >> >>
>> >> >>
>> >> >> @@ -252,7 +252,9 @@ static void
>> >> hsw_wait_for_power_well_enable(struct
>> >> >> drm_i915_private *dev_priv,
>> >> >> bool timeout_expected)
>> >> >> {
>> >> >>const struct i915_power_well_regs *regs = power_well->desc->ops-
>> >> >> >regs;
>> >> >> + enum phy phy = icl_aux_pw_to_phy(i915, power_well);
>> >> >>int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
>> >> >> + int timeout = 1;
>> >> >>
>> >> >>/*
>> >> >> * For some power wells we're not supposed to watch the status
>> >> >> bit for @@ -264,9 +266,13 @@ static void
>> >> >> hsw_wait_for_power_well_enable(struct drm_i915_private *dev_priv,
>> >> >>return;
>> >> >>}
>> >> >>
>> >> >> + /* WA_14017248603: adlp */
>> >> >> + if (IS_ALDERLAKE_P(i915) && intel_phy_is_tc(i915, phy))
>> >> >
>> >> > I did try this but it ends up throwing a kernel null pointer error
>> >> > at intel_phy_is_tc which made me float the version of code I did.
>> >>
>> >> Please explain what causes it, and how your version avoids it.
>> >>
>> >
>> > icl_aux_pw_to_phy is called is hsw_wait_for_power_well is called
>> > everywhere where its not possible for aux_pw to phy conversion is not
>> possible with this change we only get the phy for adls version.
>> > Will address this is next version.
>>
>> Cc: Imre for input
>>
>> Maybe pass the timeout to hsw_wait_for_power_well_enable() as
>> parameter?
>> Other ideas?
>
> I did think of that but the idea of disturbing other functions stopped me.
> If that doesn't seem like an issue I could do that.
Please let Imre chime in first.
But in general we don't shy away from changes touching other places if
it makes sense, and keeps the code clean.
BR,
Jani.
>
> Regards,
> Suraj Kandpal
>>
>> BR,
>> Jani.
>>
>> >
>> > Regards,
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX timeout for Type-C
drm/i915/display: Increase AUX timeout
> for Type-C
>
> On Mon, 17 Apr 2023, "Kandpal, Suraj" wrote:
> >> -Original Message-
> >> From: Jani Nikula
> >> Sent: Monday, April 17, 2023 4:04 PM
> >> To: Kandpal, Suraj ; intel-
> >> g...@lists.freedesktop.org
> >> Subject: RE: [Intel-gfx] [PATCH v2] drm/i915/display: Increase AUX
> >> timeout for Type-C
> >>
> >> On Mon, 17 Apr 2023, "Kandpal, Suraj" wrote:
> >> >> On Wed, 05 Apr 2023, Suraj Kandpal
> wrote:
> >> >> > Type-C PHYs are taking longer than expected for Aux IO Power
> Enabling.
> >> >> > Workaround: Increase the timeout.
> >> >> >
> >> >> > WA_14017248603: adlp
> >> >> > Bspec: 55480
> >> >> >
> >> >> > ---v2
> >> >> > -change style on how we mention WA [Ankit] -fix bat error
> >> >> >
> >> >> > Signed-off-by: Suraj Kandpal
> >> >> > ---
> >> >> > .../i915/display/intel_display_power_well.c | 30
> ++-
> >> >> > 1 file changed, 29 insertions(+), 1 deletion(-)
> >> >> >
> >> >> > diff --git
> >> >> > a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> >> >> > b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> >> >> > index 62bafcbc7937..52f595929a18 100644
> >> >> > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> >> >> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> >> >> > @@ -489,6 +489,34 @@ static void icl_tc_cold_exit(struct
> >> >> drm_i915_private *i915)
> >> >> > "succeeded");
> >> >> > }
> >> >> >
> >> >> > +static void
> >> >> > +adl_aux_wait_for_power_well_enable(struct drm_i915_private
> *i915,
> >> >> > +struct i915_power_well
> *power_well,
> >> >> > +bool timeout_expected)
> >> >> > +{
> >> >> > + const struct i915_power_well_regs *regs =
> >> >> > +power_well->desc->ops-
> >> >> >regs;
> >> >> > + enum phy phy = icl_aux_pw_to_phy(i915, power_well);
> >> >> > + int pw_idx = i915_power_well_instance(power_well)-
> >hsw.idx;
> >> >> > +
> >> >> > + /*
> >> >> > + * WA_14017248603: adlp
> >> >> > + * Type-C Phy are taking longer than expected for AUX IO
> Power
> >> >> Enabling.
> >> >> > + * Increase timeout to 500ms.
> >> >> > + */
> >> >> > + if (IS_ALDERLAKE_P(i915) && intel_phy_is_tc(i915, phy)) {
> >> >> > + if (intel_de_wait_for_set(i915, regs->driver,
> >> >> > +
> >> >> HSW_PWR_WELL_CTL_STATE(pw_idx), 500)) {
> >> >> > + drm_dbg_kms(>drm, "%s power well
> enable
> >> >> timeout\n",
> >> >> > +
> intel_power_well_name(power_well));
> >> >> > +
> >> >> > + drm_WARN_ON(>drm,
> !timeout_expected);
> >> >> > + }
> >> >> > + return;
> >> >> > + }
> >> >> > +
> >> >> > + hsw_wait_for_power_well_enable(i915, power_well,
> >> >> timeout_expected);
> >> >> > +}
> >> >>
> >> >> Please don't duplicate the function and the wait like this.
> >> >>
> >> >> Something like this is sufficient:
> >> >>
> >> >>
> >> >> @@ -252,7 +252,9 @@ static void
> >> hsw_wait_for_power_well_enable(struct
> >> >> drm_i915_private *dev_priv,
> >> >>bool timeout_expected)
> >> >> {
> >> >> const struct i915_power_well_regs *regs = power_well->desc->ops-
> >> >> >regs;
> >> >> + enum phy phy = icl_aux_pw_to_phy(i915, power_well);
> >> >> int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
> >> >> + int timeout = 1;
> >> >>
> >> >> /*
> >> >> * For some power wells we're not supposed to watch the status
> >> >> bit for @@ -264,9 +266,13 @@ static void
> >> >> hsw_wait_for_power_well_enable(struct drm_i915_private *dev_priv,
> >> >> return;
> >> >> }
> >> >>
> >> >> + /* WA_14017248603: adlp */
> >> >> + if (IS_ALDERLAKE_P(i915) && intel_phy_is_tc(i915, phy))
> >> >
> >> > I did try this but it ends up throwing a kernel null pointer error
> >> > at intel_phy_is_tc which made me float the version of code I did.
> >>
> >> Please explain what causes it, and how your version avoids it.
> >>
> >
> > icl_aux_pw_to_phy is called is hsw_wait_for_power_well is called
> > everywhere where its not possible for aux_pw to phy conversion is not
> possible with this change we only get the phy for adls version.
> > Will address this is next version.
>
> Cc: Imre for input
>
> Maybe pass the timeout to hsw_wait_for_power_well_enable() as
> parameter?
> Other ideas?
I did think of that but the idea of disturbing other functions stopped me.
If that doesn't seem like an issue I could do that.
Regards,
Suraj Kandpal
>
> BR,
> Jani.
>
> >
> > Regards,
> > Suraj Kandpal
> >> BR,
> >> Jani.
> >>
> >>
> >> >
> >> > Regards,
> >> > Suraj Kandpal
> >> >> + timeout = 500;
> >> >> +
> >> >> /* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
> >> >> if (intel_de_wait_for_set(dev_priv, regs->driver,
> >> >> -
Re: [Intel-gfx] [PATCH i-g-t 3/3] intel_gpu_top: Show non-normalized client usage in numeric mode
Hi Kamil,
On 14/04/2023 16:28, Kamil Konieczny wrote:
On 2023-03-28 at 13:54:29 +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When numeric display is selected in the interactive mode it is more
descriptive to show client's non-normalized (by number of engines per
class) usage. Rendering of the visual representation (bar) is kept the
same.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Kamil Konieczny
Thanks for reviewing all three and merging them too!
Regards,
Tvrtko
---
tools/intel_gpu_top.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 36da016c3df0..b6827b3de9bd 100644
--- a/tools/intel_gpu_top.c
+++ b/tools/intel_gpu_top.c
@@ -1275,14 +1275,14 @@ static void n_spaces(const unsigned int n)
}
static void
-print_percentage_bar(double percent, int max_len, bool numeric)
+print_percentage_bar(double percent, double max, int max_len, bool numeric)
{
int bar_len, i, len = max_len - 2;
const int w = 8;
assert(max_len > 0);
- bar_len = ceil(w * percent * len / 100.0);
+ bar_len = ceil(w * percent * len / max);
if (bar_len > w * len)
bar_len = w * len;
@@ -2010,7 +2010,8 @@ print_engine(struct engines *engines, unsigned int i, double t,
engine->display_name, engine_items[0].buf);
val = pmu_calc(>busy.val, 1e9, t, 100);
- print_percentage_bar(val, con_w > len ? con_w - len : 0, false);
+ print_percentage_bar(val, 100.0, con_w > len ? con_w - len : 0,
+false);
printf("%s\n", buf);
@@ -2292,23 +2293,24 @@ print_client(struct client *c, struct engines *engines, double t, int lines,
clients->max_name_len, c->print_name);
for (i = 0; c->samples > 1 && i < clients->num_classes; i++) {
- double pct;
+ double pct, max;
if (!clients->class[i].num_engines)
continue; /* Assert in the ideal world. */
- pct = (double)c->val[i] / period_us / 1e3 * 100 /
- clients->class[i].num_engines;
+ pct = (double)c->val[i] / period_us / 1e3 * 100;
/*
* Guard against possible time-drift between sampling
* client data and time we obtained our time-delta from
* PMU.
*/
- if (pct > 100.0)
- pct = 100.0;
+ max = 100.0 * clients->class[i].num_engines;
+ if (pct > max)
+ pct = max;
- print_percentage_bar(pct, *class_w, numeric_clients);
+ print_percentage_bar(pct, max, *class_w,
+numeric_clients);
}
putchar('\n');
--
2.37.2
[Intel-gfx] [PATCH i-g-t 5/8] lib/igt_drm_fdinfo: Track largest engine index
From: Tvrtko Ursulin
Prep code for incoming work.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_fdinfo.c | 2 ++
lib/igt_drm_fdinfo.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/lib/igt_drm_fdinfo.c b/lib/igt_drm_fdinfo.c
index 3f4f0e88b0d8..b5f8a8679a71 100644
--- a/lib/igt_drm_fdinfo.c
+++ b/lib/igt_drm_fdinfo.c
@@ -162,6 +162,8 @@ __igt_parse_drm_fdinfo(int dir, const char *fd, struct
drm_client_fdinfo *info,
info->capacity[idx] = 1;
info->busy[idx] = val;
info->num_engines++;
+ if (idx > info->last_engine_index)
+ info->last_engine_index = idx;
}
} else if (!strncmp(l, "drm-engine-capacity-", 20)) {
idx = parse_engine(l, info,
diff --git a/lib/igt_drm_fdinfo.h b/lib/igt_drm_fdinfo.h
index fa4982f4030e..6284e05e868a 100644
--- a/lib/igt_drm_fdinfo.h
+++ b/lib/igt_drm_fdinfo.h
@@ -38,6 +38,7 @@ struct drm_client_fdinfo {
unsigned long id;
unsigned int num_engines;
+ unsigned int last_engine_index;
unsigned int capacity[DRM_CLIENT_FDINFO_MAX_ENGINES];
char names[DRM_CLIENT_FDINFO_MAX_ENGINES][256];
uint64_t busy[DRM_CLIENT_FDINFO_MAX_ENGINES];
--
2.37.2
[Intel-gfx] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool
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
Reviewed-by: Rob Clark
---
tools/gputop.c| 266 ++
tools/meson.build | 5 +
2 files changed, 271 insertions(+)
create mode 100644 tools/gputop.c
diff --git a/tools/gputop.c b/tools/gputop.c
new file mode 100644
index ..4fb5ce63e07c
--- /dev/null
+++ b/tools/gputop.c
@@ -0,0 +1,266 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "igt_drm_clients.h"
+#include "igt_drm_fdinfo.h"
+
+static const char *bars[] = { " ", "▏", "▎", "▍", "▌", "▋", "▊", "▉", "█" };
+
+static void n_spaces(const unsigned int n)
+{
+ unsigned int i;
+
+ for (i = 0; i < n; i++)
+ putchar(' ');
+}
+
+static void print_percentage_bar(double percent, int max_len)
+{
+ int bar_len, i, len = max_len - 2;
+ const int w = 8;
+
+ assert(max_len > 0);
+
+ bar_len = ceil(w * percent * len / 100.0);
+ if (bar_len > w * len)
+ bar_len = w * len;
+
+ putchar('|');
+
+ for (i = bar_len; i >= w; i -= w)
+ printf("%s", bars[w]);
+ if (i)
+ printf("%s", bars[i]);
+
+ len -= (bar_len + (w - 1)) / w;
+ n_spaces(len);
+
+ putchar('|');
+}
+
+static int
+print_client_header(struct igt_drm_client *c, int lines, int con_w, int con_h,
+ int *engine_w)
+{
+ int ret, len;
+
+ if (lines++ >= con_h)
+ return lines;
+
+ printf("\033[7m");
+ ret = printf("DRM minor %u", c->drm_minor);
+ n_spaces(con_w - ret);
+
+ if (lines++ >= con_h)
+ return lines;
+
+ putchar('\n');
+ len = printf("%*s %*s ",
+c->clients->max_pid_len, "PID",
+c->clients->max_name_len, "NAME");
+
+ if (c->engines->num_engines) {
+ unsigned int i;
+ int width;
+
+ *engine_w = width = (con_w - len) / c->engines->num_engines;
+
+ for (i = 0; i <= c->engines->max_engine_id; i++) {
+ const char *name = c->engines->names[i];
+ int name_len = strlen(name);
+ int pad = (width - name_len) / 2;
+ int spaces = width - pad - name_len;
+
+ if (!name)
+ continue;
+
+ if (pad < 0 || spaces < 0)
+ continue;
+
+ n_spaces(pad);
+ printf("%s", name);
+ n_spaces(spaces);
+ len += pad + name_len + spaces;
+ }
+ }
+
+ n_spaces(con_w - len);
+ printf("\033[0m\n");
+
+ return lines;
+}
+
+
+static bool
+newheader(const struct igt_drm_client *c, const struct igt_drm_client *pc)
+{
+ return !pc || c->drm_minor != pc->drm_minor;
+}
+
+static int
+print_client(struct igt_drm_client *c, struct igt_drm_client **prevc,
+double t, int lines, int con_w, int con_h,
+unsigned int period_us, int *engine_w)
+{
+ unsigned int i;
+
+ /* Filter out idle clients. */
+ if (!c->total_runtime || c->samples < 2)
+ return lines;
+
+ /* Print header when moving to a different DRM card. */
+ if (newheader(c, *prevc)) {
+ lines = print_client_header(c, lines, con_w, con_h, engine_w);
+ if (lines >= con_h)
+ return lines;
+ }
+
+ *prevc = c;
+
+ printf("%*s %*s ",
+ c->clients->max_pid_len, c->pid_str,
+ c->clients->max_name_len, c->print_name);
+ lines++;
+
+ for (i = 0; c->samples > 1 && i <= c->engines->max_engine_id; i++) {
+ double pct;
+
+ if (!c->engines->capacity[i])
+ continue;
+
+ pct = (double)c->val[i] / period_us / 1e3 * 100 /
+ c->engines->capacity[i];
+
+ /*
+* Guard against fluctuations between our scanning period and
+* GPU times as exported by the
[Intel-gfx] [PATCH i-g-t 6/8] lib/igt_drm_clients: Decouple hardcoded engine assumptions
From: Tvrtko Ursulin
Intel_gpu_top gets it's main engine configuration data via PMU probe and
uses that for per client view as well. Furthemore code so far assumed only
clients belonging from a single DRM card would be tracked in a single
clients list.
Break this inter-dependency by moving the engine data to be per client and
also have libdrmclient probe the engine configuration independently using
the previously added libdrmfdinfo facilities.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_drm_clients.c | 38 +++--
lib/igt_drm_clients.h | 14 ++---
tools/intel_gpu_top.c | 127 +++---
3 files changed, 134 insertions(+), 45 deletions(-)
diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c
index 06b66fe95b62..5d06337db70e 100644
--- a/lib/igt_drm_clients.c
+++ b/lib/igt_drm_clients.c
@@ -106,7 +106,7 @@ igt_drm_client_update(struct igt_drm_client *c, unsigned
int pid, char *name,
c->last_runtime = 0;
c->total_runtime = 0;
- for (i = 0; i < c->clients->num_classes; i++) {
+ for (i = 0; i <= c->engines->max_engine_id; i++) {
assert(i < ARRAY_SIZE(info->busy));
if (info->busy[i] < c->last[i])
@@ -128,6 +128,7 @@ igt_drm_client_add(struct igt_drm_clients *clients,
unsigned int pid, char *name, unsigned int drm_minor)
{
struct igt_drm_client *c;
+ unsigned int i;
assert(!igt_drm_clients_find(clients, IGT_DRM_CLIENT_ALIVE,
drm_minor, info->id));
@@ -153,8 +154,28 @@ igt_drm_client_add(struct igt_drm_clients *clients,
c->id = info->id;
c->drm_minor = drm_minor;
c->clients = clients;
- c->val = calloc(clients->num_classes, sizeof(c->val));
- c->last = calloc(clients->num_classes, sizeof(c->last));
+ c->engines = malloc(sizeof(*c->engines));
+ assert(c->engines);
+ memset(c->engines, 0, sizeof(*c->engines));
+ c->engines->capacity = calloc(info->last_engine_index + 1,
+ sizeof(*c->engines->capacity));
+ assert(c->engines->capacity);
+ c->engines->names = calloc(info->last_engine_index + 1,
+ sizeof(*c->engines->names));
+ assert(c->engines->names);
+
+ for (i = 0; i <= info->last_engine_index; i++) {
+ if (!info->capacity[i])
+ continue;
+
+ c->engines->capacity[i] = info->capacity[i];
+ c->engines->names[i] = strdup(info->names[i]);
+ assert(c->engines->names[i]);
+ c->engines->num_engines++;
+ c->engines->max_engine_id = i;
+ }
+ c->val = calloc(c->engines->max_engine_id + 1, sizeof(c->val));
+ c->last = calloc(c->engines->max_engine_id + 1, sizeof(c->last));
assert(c->val && c->last);
igt_drm_client_update(c, pid, name, info);
@@ -163,6 +184,15 @@ igt_drm_client_add(struct igt_drm_clients *clients,
static
void igt_drm_client_free(struct igt_drm_client *c, bool clear)
{
+ unsigned int i;
+
+ if (c->engines) {
+ for (i = 0; i <= c->engines->max_engine_id; i++)
+ free(c->engines->names[i]);
+ free(c->engines->capacity);
+ free(c->engines->names);
+ }
+ free(c->engines);
free(c->val);
free(c->last);
@@ -356,7 +386,7 @@ static void clients_update_max_lengths(struct
igt_drm_clients *clients)
*
* If @name_map is not provided engine names will be auto-detected (this is
* less performant) and indices will correspond with auto-detected names as
- * listed int clients->engine_class[].
+ * listed int clients->engines->names[].
*/
struct igt_drm_clients *
igt_drm_clients_scan(struct igt_drm_clients *clients,
diff --git a/lib/igt_drm_clients.h b/lib/igt_drm_clients.h
index 591725b8c059..36a1547a37e5 100644
--- a/lib/igt_drm_clients.h
+++ b/lib/igt_drm_clients.h
@@ -31,10 +31,12 @@ enum igt_drm_client_status {
IGT_DRM_CLIENT_PROBE
};
-struct igt_drm_client_engine_class {
- unsigned int engine_class;
- const char *name;
- unsigned int num_engines;
+struct igt_drm_client_engines {
+ unsigned int num_engines; /* Number of discovered active engines. */
+ unsigned int max_engine_id; /* Largest engine index discovered.
+ (Can differ from num_engines - 1 when
using the engine map facility.) */
+ unsigned int *capacity; /* Array of engine capacities as parsed from
fdinfo. */
+ char **names; /* Array of engine names, either auto-detected or from
the passed in engine map. */
};
struct igt_drm_clients;
@@ -43,6 +45,7 @@ struct igt_drm_client {
struct igt_drm_clients *clients; /* Owning list. */
enum igt_drm_client_status status;
+ struct igt_drm_client_engines *engines; /* Engines used by this client,
to map with
