[PATCH 3/8] drm/i915: Pimp display fault reporting
Ville Syrjälä
ville.syrjala at linux.intel.com
Mon Jan 20 14:48:25 UTC 2025
On Mon, Jan 20, 2025 at 02:50:50PM +0100, Maarten Lankhorst wrote:
>
>
> Den 2025-01-16 kl. 18:47, skrev Ville Syrjala:
> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >
> > Decode the display faults a bit more extensively so that one
> > doesn't have translate the bitmask to planes/etc. manually.
> > Also for plane faults we can read out a bit of state from the
> > relevant plane(s) and dump that out.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > ---
> > .../gpu/drm/i915/display/intel_atomic_plane.c | 2 +-
> > .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
> > .../gpu/drm/i915/display/intel_display_irq.c | 156 +++++++++++++++++-
> > 3 files changed, 155 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > index 612e9b0ec14a..0aeb5f00d9c4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -663,7 +663,7 @@ int intel_plane_atomic_check_with_state(const struct intel_crtc_state *old_crtc_
> > old_plane_state, new_plane_state);
> > }
> >
> > -static struct intel_plane *
> > +struct intel_plane *
> > intel_crtc_get_plane(struct intel_crtc *crtc, enum plane_id plane_id)
> > {
> > struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> > index 0f982f452ff3..298bb97b37a4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> > @@ -19,6 +19,8 @@ struct intel_plane;
> > struct intel_plane_state;
> > enum plane_id;
> >
> > +struct intel_plane *
> > +intel_crtc_get_plane(struct intel_crtc *crtc, enum plane_id plane_id);
> > unsigned int intel_adjusted_rate(const struct drm_rect *src,
> > const struct drm_rect *dst,
> > unsigned int rate);
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_irq.c b/drivers/gpu/drm/i915/display/intel_display_irq.c
> > index f06273d9bc8c..1b3b6b8bc794 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_irq.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_irq.c
> > @@ -10,6 +10,7 @@
> > #include "i915_irq.h"
> > #include "i915_reg.h"
> > #include "icl_dsi_regs.h"
> > +#include "intel_atomic_plane.h"
> > #include "intel_crtc.h"
> > #include "intel_de.h"
> > #include "intel_display_irq.h"
> > @@ -26,6 +27,52 @@
> > #include "intel_psr.h"
> > #include "intel_psr_regs.h"
> >
> > +struct pipe_fault_handler {
> > + bool (*handle)(struct intel_crtc *crtc, enum plane_id plane_id);
> > + u32 fault;
> > + enum plane_id plane_id;
> > +};
> > +
> > +static bool handle_plane_fault(struct intel_crtc *crtc, enum plane_id plane_id)
> > +{
> > + struct intel_display *display = to_intel_display(crtc);
> > + struct intel_plane_error error = {};
> > + struct intel_plane *plane;
> > +
> > + plane = intel_crtc_get_plane(crtc, plane_id);
> > + if (!plane || !plane->capture_error)
> > + return false;
> > +
> > + plane->capture_error(crtc, plane, &error);
> > +
> > + drm_err_ratelimited(display->drm,
> > + "[CRTC:%d:%s][PLANE:%d:%s] fault (CTL=0x%x, SURF=0x%x, SURFLIVE=0x%x)\n",
> > + crtc->base.base.id, crtc->base.name,
> > + plane->base.base.id, plane->base.name,
> > + error.ctl, error.surf, error.surflive);
>
> Could we drop the CRTC here?
> <3> [264.586596] xe 0000:00:02.0: [drm] *ERROR* [CRTC:82:pipe
> A][PLANE:32:plane 1A] fault (CTL=0x94001002, SURF=0x1800000,
> SURFLIVE=0x1800000)
>
> Looks to be a bit redundant to print CRTC and plane here. Most likely
> PLANE is good enough. :-)
It's helpful with cases where the plane name isn't very descriptive,
which will mainly be VLV/CHV sprites.
Would also help with gen2/3 where we swap the plane<->pipe mapping
around for FBC purposes, but as FBC seems to trigger spurious
faults on those platforms we probably can't hook this up there.
--
Ville Syrjälä
Intel
More information about the Intel-xe
mailing list