Re: [Intel-gfx] [RFC PATCH 2/7] drm/i915/gvt: Use meta fbs to stand for vGPU's planes
On 2018.12.03 15:35:17 +0800, Tina Zhang wrote:
> Create and initialize vGPU meta framebuffers during vGPU's creation.
> Each meta framebuffer is an intel_framebuffer. Userspace can get the
> userspace visible identifier of that meta framebuffer by accessing
> plane_id_index attribute.
>
> For example:
> In "/sys/bus/pci/devices/\:00\:02.0/$vGPU_id/intel_vgpu/" directory,
>
>/* plane_id_index: pipe#(bit16:8) and plane#(bit7:0)*/
>echo "0x10" > plane_index_id //Set the index to the plane 0 of pipe 1
>
>/*
> * Dump userspace visible identifier of the meta framebuffer
> * standing for the primary plane of the vGPU's pipe one
> */
>cat plane_index_id //dump the id for plane 0 of pipe 1
>
> Then userspace can use this id with the exsting KMS IOCTL, e.g.
> drmModeSetPlane, to assign a physical plane to this virtual plane.
How does user know which plane/pipe is active for vGPU? Looks from
current code it has no way to know that. I think for guest display
assignment, we need to know the display state of vGPU and it looks
there's no state tracking, e.g what if guest driver switches to
another plane for display? How could user know that then adjust for
assignment?
And really don't like sysfs to r/w file for id, even if doesn't use
vfio gfx dmabuf interface for guest display object presentation, a
vendor specific vfio device ioctl if possible is better.
>
> Signed-off-by: Tina Zhang
> Cc: Zhenyu Wang
> Cc: Zhi Wang
> ---
> drivers/gpu/drm/i915/gvt/display.c | 150
> +
> drivers/gpu/drm/i915/gvt/gvt.h | 16
> drivers/gpu/drm/i915/gvt/kvmgt.c | 46
> 3 files changed, 212 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gvt/display.c
> b/drivers/gpu/drm/i915/gvt/display.c
> index df1e141..a9176a1 100644
> --- a/drivers/gpu/drm/i915/gvt/display.c
> +++ b/drivers/gpu/drm/i915/gvt/display.c
> @@ -442,6 +442,152 @@ void intel_gvt_emulate_vblank(struct intel_gvt *gvt)
> mutex_unlock(&gvt->lock);
> }
>
> +struct intel_vgpu_fb_meta_data {
> + u32 vgpu_plane_id; /* vgpu_id(23:16):vgpu_pipe(15:8):vgpu_plane(7:0)*/
> + struct intel_vgpu *vgpu; // the vGPU this meta_fb belongs to
> +};
> +
> +static void meta_fb_destroy(struct drm_framebuffer *fb)
> +{
> + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> +
> + if (intel_fb->meta_fb.type_id != INTEL_META_FB_VGPU)
> + return;
> +
> + kfree(intel_fb->meta_fb.private);
> + intel_fb->meta_fb.private = NULL;
> +
> + drm_framebuffer_cleanup(fb);
> + kfree(intel_fb);
> +}
> +
> +static void clean_meta_fb(struct intel_vgpu *vgpu)
> +{
> + enum pipe pipe;
> + enum plane_id plane_id;
> + struct intel_framebuffer *intel_fb;
> +
> + for (pipe = 0; pipe < I915_MAX_PIPES; pipe++) {
> + for (plane_id = 0; plane_id < I915_MAX_PLANES; plane_id++) {
> + intel_fb =
> vgpu->display.meta_fbs.meta_fb[pipe][plane_id];
> + if (!intel_fb)
> + drm_framebuffer_put(&intel_fb->base);
> +
> + intel_fb = NULL;
> + }
> + }
> +}
> +
> +static int meta_fb_create_handle(struct drm_framebuffer *fb,
> + struct drm_file *file,
> + unsigned int *handle)
> +{
> + return -ENODEV;
> +}
> +
> +static int meta_fb_dirty(struct drm_framebuffer *fb,
> + struct drm_file *file,
> + unsigned int flags,
> + unsigned int color,
> + struct drm_clip_rect *clips,
> + unsigned int num_clips)
> +{
> + return 0;
> +}
> +
> +static const struct drm_framebuffer_funcs meta_fb_funcs = {
> + .destroy = meta_fb_destroy,
> + .create_handle = meta_fb_create_handle,
> + .dirty = meta_fb_dirty,
> +};
> +
> +static void meta_fb_update(struct intel_framebuffer *intel_fb,
> +enum pipe pipe, enum plane_id plane_id)
> +{
> + struct intel_vgpu_fb_meta_data *meta_data;
> + struct intel_gvt *gvt;
> +
> + if (!intel_fb || intel_fb->meta_fb.type_id != INTEL_META_FB_VGPU)
> + return;
> +
> + meta_data = intel_fb->meta_fb.private;
> + gvt = meta_data->vgpu->gvt;
> +
> + if (gvt->assigned_plane[pipe][plane_id].vgpu_plane_id !=
> + meta_data->vgpu_plane_id) {
> + gvt->assigned_plane[pipe][plane_id].vgpu_plane_id =
> + meta_data->vgpu_plane_id;
> + gvt->assigned_plane[pipe][plane_id].framebuffer_id =
> + intel_fb->base.base.id;
> + intel_fb->meta_fb.ggtt_offset = 0;
> + intel_fb->meta_fb.should_be_offscreen = true;
> + } else if (!intel_fb->meta_fb.ggtt_offset) {
> + intel_fb->meta_fb.should_be_offscreen = true;
> + } el
Re: [Intel-gfx] [RFC PATCH 2/7] drm/i915/gvt: Use meta fbs to stand for vGPU's planes
On 2018.12.03 16:21:04 +0800, Zhenyu Wang wrote: > On 2018.12.03 15:35:17 +0800, Tina Zhang wrote: > > Create and initialize vGPU meta framebuffers during vGPU's creation. > > Each meta framebuffer is an intel_framebuffer. Userspace can get the > > userspace visible identifier of that meta framebuffer by accessing > > plane_id_index attribute. > > > > For example: > > In "/sys/bus/pci/devices/\:00\:02.0/$vGPU_id/intel_vgpu/" directory, > > > >/* plane_id_index: pipe#(bit16:8) and plane#(bit7:0)*/ > >echo "0x10" > plane_index_id //Set the index to the plane 0 of pipe 1 > > > >/* > > * Dump userspace visible identifier of the meta framebuffer > > * standing for the primary plane of the vGPU's pipe one > > */ > >cat plane_index_id //dump the id for plane 0 of pipe 1 > > > > Then userspace can use this id with the exsting KMS IOCTL, e.g. > > drmModeSetPlane, to assign a physical plane to this virtual plane. > > How does user know which plane/pipe is active for vGPU? Looks from > current code it has no way to know that. I think for guest display > assignment, we need to know the display state of vGPU and it looks > there's no state tracking, e.g what if guest driver switches to > another plane for display? How could user know that then adjust for > assignment? > > And really don't like sysfs to r/w file for id, even if doesn't use > vfio gfx dmabuf interface for guest display object presentation, a > vendor specific vfio device ioctl if possible is better. > And add that this device specific info sysfs is created when mdev device created before it's opened for vGPU instance. So I don't think it's proper place to put display config info. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 2/7] drm/i915/gvt: Use meta fbs to stand for vGPU's planes
> -Original Message-
> From: Zhenyu Wang [mailto:zhen...@linux.intel.com]
> Sent: Monday, December 3, 2018 4:21 PM
> To: Zhang, Tina
> Cc: intel-gfx@lists.freedesktop.org; Kondapally, Kalyan
> ; intel-gvt-...@lists.freedesktop.org; Wang, Zhi
> A
> Subject: Re: [RFC PATCH 2/7] drm/i915/gvt: Use meta fbs to stand for vGPU's
> planes
>
> On 2018.12.03 15:35:17 +0800, Tina Zhang wrote:
> > Create and initialize vGPU meta framebuffers during vGPU's creation.
> > Each meta framebuffer is an intel_framebuffer. Userspace can get the
> > userspace visible identifier of that meta framebuffer by accessing
> > plane_id_index attribute.
> >
> > For example:
> > In "/sys/bus/pci/devices/\:00\:02.0/$vGPU_id/intel_vgpu/"
> > directory,
> >
> >/* plane_id_index: pipe#(bit16:8) and plane#(bit7:0)*/
> >echo "0x10" > plane_index_id //Set the index to the plane 0 of pipe
> > 1
> >
> >/*
> > * Dump userspace visible identifier of the meta framebuffer
> > * standing for the primary plane of the vGPU's pipe one
> > */
> >cat plane_index_id //dump the id for plane 0 of pipe 1
> >
> > Then userspace can use this id with the exsting KMS IOCTL, e.g.
> > drmModeSetPlane, to assign a physical plane to this virtual plane.
>
> How does user know which plane/pipe is active for vGPU? Looks from current
> code it has no way to know that. I think for guest display assignment, we need
> to know the display state of vGPU and it looks there's no state tracking, e.g
> what
> if guest driver switches to another plane for display? How could user know
> that
> then adjust for assignment?
So far, GVT-g has supported multi-heads. In another word, there is only one
priramy
plane for each vGPU.
GVT-g only provides the EDID for one fixed display port and in the guest point
of view, there is only one pipe having a connected monitor, a.k.a only the
planes on
one pipe can be used by guest OS.
>
> And really don't like sysfs to r/w file for id, even if doesn't use vfio gfx
> dmabuf
> interface for guest display object presentation, a vendor specific vfio
> device ioctl
> if possible is better.
Yeah, we could consider about that.
Thanks.
BR,
Tina
>
> >
> > Signed-off-by: Tina Zhang
> > Cc: Zhenyu Wang
> > Cc: Zhi Wang
> > ---
> > drivers/gpu/drm/i915/gvt/display.c | 150
> +
> > drivers/gpu/drm/i915/gvt/gvt.h | 16
> > drivers/gpu/drm/i915/gvt/kvmgt.c | 46
> > 3 files changed, 212 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/display.c
> > b/drivers/gpu/drm/i915/gvt/display.c
> > index df1e141..a9176a1 100644
> > --- a/drivers/gpu/drm/i915/gvt/display.c
> > +++ b/drivers/gpu/drm/i915/gvt/display.c
> > @@ -442,6 +442,152 @@ void intel_gvt_emulate_vblank(struct intel_gvt
> *gvt)
> > mutex_unlock(&gvt->lock);
> > }
> >
> > +struct intel_vgpu_fb_meta_data {
> > + u32 vgpu_plane_id; /*
> vgpu_id(23:16):vgpu_pipe(15:8):vgpu_plane(7:0)*/
> > + struct intel_vgpu *vgpu; // the vGPU this meta_fb belongs to };
> > +
> > +static void meta_fb_destroy(struct drm_framebuffer *fb) {
> > + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> > +
> > + if (intel_fb->meta_fb.type_id != INTEL_META_FB_VGPU)
> > + return;
> > +
> > + kfree(intel_fb->meta_fb.private);
> > + intel_fb->meta_fb.private = NULL;
> > +
> > + drm_framebuffer_cleanup(fb);
> > + kfree(intel_fb);
> > +}
> > +
> > +static void clean_meta_fb(struct intel_vgpu *vgpu) {
> > + enum pipe pipe;
> > + enum plane_id plane_id;
> > + struct intel_framebuffer *intel_fb;
> > +
> > + for (pipe = 0; pipe < I915_MAX_PIPES; pipe++) {
> > + for (plane_id = 0; plane_id < I915_MAX_PLANES; plane_id++) {
> > + intel_fb = vgpu-
> >display.meta_fbs.meta_fb[pipe][plane_id];
> > + if (!intel_fb)
> > + drm_framebuffer_put(&intel_fb->base);
> > +
> > + intel_fb = NULL;
> > + }
> > + }
> > +}
> > +
> > +static int meta_fb_create_handle(struct drm_framebuffer *fb,
> > +struct drm_file *file,
> > +unsigned int *handle)
> > +{
> > + return -ENODEV;
> > +}
> > +
> > +static int meta_fb_dirty(struct drm_framebuffer *fb,
> > +struct drm_file *file,
> > +unsigned int flags,
> > +unsigned int color,
> > +struct drm_clip_rect *clips,
> > +unsigned int num_clips)
> > +{
> > + return 0;
> > +}
> > +
> > +static const struct drm_framebuffer_funcs meta_fb_funcs = {
> > + .destroy = meta_fb_destroy,
> > + .create_handle = meta_fb_create_handle,
> > + .dirty = meta_fb_dirty,
> > +};
> > +
> > +static void meta_fb_update(struct intel_framebuffer *intel_fb,
> > + enum pipe pipe, enum plane_id plane_id) {
> > + struct intel_vgpu_fb_meta_data *meta_data;
> > + struct intel_gvt *gvt
Re: [Intel-gfx] [RFC PATCH 2/7] drm/i915/gvt: Use meta fbs to stand for vGPU's planes
> -Original Message-
> From: Zhang, Tina
> Sent: Monday, December 3, 2018 4:53 PM
> To: 'Zhenyu Wang'
> Cc: intel-gfx@lists.freedesktop.org; Kondapally, Kalyan
> ; intel-gvt-...@lists.freedesktop.org; Wang, Zhi
> A
> Subject: RE: [RFC PATCH 2/7] drm/i915/gvt: Use meta fbs to stand for vGPU's
> planes
>
>
>
> > -Original Message-
> > From: Zhenyu Wang [mailto:zhen...@linux.intel.com]
> > Sent: Monday, December 3, 2018 4:21 PM
> > To: Zhang, Tina
> > Cc: intel-gfx@lists.freedesktop.org; Kondapally, Kalyan
> > ; intel-gvt-...@lists.freedesktop.org;
> > Wang, Zhi A
> > Subject: Re: [RFC PATCH 2/7] drm/i915/gvt: Use meta fbs to stand for
> > vGPU's planes
> >
> > On 2018.12.03 15:35:17 +0800, Tina Zhang wrote:
> > > Create and initialize vGPU meta framebuffers during vGPU's creation.
> > > Each meta framebuffer is an intel_framebuffer. Userspace can get the
> > > userspace visible identifier of that meta framebuffer by accessing
> > > plane_id_index attribute.
> > >
> > > For example:
> > > In "/sys/bus/pci/devices/\:00\:02.0/$vGPU_id/intel_vgpu/"
> > > directory,
> > >
> > >/* plane_id_index: pipe#(bit16:8) and plane#(bit7:0)*/
> > >echo "0x10" > plane_index_id //Set the index to the plane 0 of
> > > pipe
> > > 1
> > >
> > >/*
> > > * Dump userspace visible identifier of the meta framebuffer
> > > * standing for the primary plane of the vGPU's pipe one
> > > */
> > >cat plane_index_id //dump the id for plane 0 of pipe 1
> > >
> > > Then userspace can use this id with the exsting KMS IOCTL, e.g.
> > > drmModeSetPlane, to assign a physical plane to this virtual plane.
> >
> > How does user know which plane/pipe is active for vGPU? Looks from
> > current code it has no way to know that. I think for guest display
> > assignment, we need to know the display state of vGPU and it looks
> > there's no state tracking, e.g what if guest driver switches to
> > another plane for display? How could user know that then adjust for
> assignment?
> So far, GVT-g has supported multi-heads. In another word, there is only one
> priramy plane for each vGPU.
The "has" here was actually "hasn't". Sorry for this typo.
BR,
Tina
>
> GVT-g only provides the EDID for one fixed display port and in the guest
> point of
> view, there is only one pipe having a connected monitor, a.k.a only the planes
> on one pipe can be used by guest OS.
>
> >
> > And really don't like sysfs to r/w file for id, even if doesn't use
> > vfio gfx dmabuf interface for guest display object presentation, a
> > vendor specific vfio device ioctl if possible is better.
> Yeah, we could consider about that.
> Thanks.
>
> BR,
> Tina
> >
> > >
> > > Signed-off-by: Tina Zhang
> > > Cc: Zhenyu Wang
> > > Cc: Zhi Wang
> > > ---
> > > drivers/gpu/drm/i915/gvt/display.c | 150
> > +
> > > drivers/gpu/drm/i915/gvt/gvt.h | 16
> > > drivers/gpu/drm/i915/gvt/kvmgt.c | 46
> > > 3 files changed, 212 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gvt/display.c
> > > b/drivers/gpu/drm/i915/gvt/display.c
> > > index df1e141..a9176a1 100644
> > > --- a/drivers/gpu/drm/i915/gvt/display.c
> > > +++ b/drivers/gpu/drm/i915/gvt/display.c
> > > @@ -442,6 +442,152 @@ void intel_gvt_emulate_vblank(struct intel_gvt
> > *gvt)
> > > mutex_unlock(&gvt->lock);
> > > }
> > >
> > > +struct intel_vgpu_fb_meta_data {
> > > + u32 vgpu_plane_id; /*
> > vgpu_id(23:16):vgpu_pipe(15:8):vgpu_plane(7:0)*/
> > > + struct intel_vgpu *vgpu; // the vGPU this meta_fb belongs to };
> > > +
> > > +static void meta_fb_destroy(struct drm_framebuffer *fb) {
> > > + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> > > +
> > > + if (intel_fb->meta_fb.type_id != INTEL_META_FB_VGPU)
> > > + return;
> > > +
> > > + kfree(intel_fb->meta_fb.private);
> > > + intel_fb->meta_fb.private = NULL;
> > > +
> > > + drm_framebuffer_cleanup(fb);
> > > + kfree(intel_fb);
> > > +}
> > > +
> > > +static void clean_meta_fb(struct intel_vgpu *vgpu) {
> > > + enum pipe pipe;
> > > + enum plane_id plane_id;
> > > + struct intel_framebuffer *intel_fb;
> > > +
> > > + for (pipe = 0; pipe < I915_MAX_PIPES; pipe++) {
> > > + for (plane_id = 0; plane_id < I915_MAX_PLANES; plane_id++) {
> > > + intel_fb = vgpu-
> > >display.meta_fbs.meta_fb[pipe][plane_id];
> > > + if (!intel_fb)
> > > + drm_framebuffer_put(&intel_fb->base);
> > > +
> > > + intel_fb = NULL;
> > > + }
> > > + }
> > > +}
> > > +
> > > +static int meta_fb_create_handle(struct drm_framebuffer *fb,
> > > + struct drm_file *file,
> > > + unsigned int *handle)
> > > +{
> > > + return -ENODEV;
> > > +}
> > > +
> > > +static int meta_fb_dirty(struct drm_framebuffer *fb,
> > > + struct drm_file *file,
> > > + unsigned int flags,
> > > +
Re: [Intel-gfx] [RFC PATCH 2/7] drm/i915/gvt: Use meta fbs to stand for vGPU's planes
> -Original Message- > From: Zhenyu Wang [mailto:zhen...@linux.intel.com] > Sent: Monday, December 3, 2018 4:36 PM > To: Zhang, Tina > Cc: intel-gfx@lists.freedesktop.org; Kondapally, Kalyan > ; intel-gvt-...@lists.freedesktop.org; Wang, Zhi > A > Subject: Re: [RFC PATCH 2/7] drm/i915/gvt: Use meta fbs to stand for vGPU's > planes > > On 2018.12.03 16:21:04 +0800, Zhenyu Wang wrote: > > On 2018.12.03 15:35:17 +0800, Tina Zhang wrote: > > > Create and initialize vGPU meta framebuffers during vGPU's creation. > > > Each meta framebuffer is an intel_framebuffer. Userspace can get the > > > userspace visible identifier of that meta framebuffer by accessing > > > plane_id_index attribute. > > > > > > For example: > > > In "/sys/bus/pci/devices/\:00\:02.0/$vGPU_id/intel_vgpu/" > > > directory, > > > > > >/* plane_id_index: pipe#(bit16:8) and plane#(bit7:0)*/ > > >echo "0x10" > plane_index_id //Set the index to the plane 0 of > > > pipe 1 > > > > > >/* > > > * Dump userspace visible identifier of the meta framebuffer > > > * standing for the primary plane of the vGPU's pipe one > > > */ > > >cat plane_index_id //dump the id for plane 0 of pipe 1 > > > > > > Then userspace can use this id with the exsting KMS IOCTL, e.g. > > > drmModeSetPlane, to assign a physical plane to this virtual plane. > > > > How does user know which plane/pipe is active for vGPU? Looks from > > current code it has no way to know that. I think for guest display > > assignment, we need to know the display state of vGPU and it looks > > there's no state tracking, e.g what if guest driver switches to > > another plane for display? How could user know that then adjust for > > assignment? > > > > And really don't like sysfs to r/w file for id, even if doesn't use > > vfio gfx dmabuf interface for guest display object presentation, a > > vendor specific vfio device ioctl if possible is better. > > > > And add that this device specific info sysfs is created when mdev device > created > before it's opened for vGPU instance. So I don't think it's proper place to > put > display config info. It's actually one of the intel_vgpu attributes. And it's created during vGPU being created. Thanks. BR, Tina > > -- > Open Source Technology Center, Intel ltd. > > $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/23] drm/i915/icl: add pll mapping for DSI
Add encoder specific pll mapping for DSI. The differences with the DDI
version are big enough to warrant a separate function.
v2: add posting read (Madhav)
Cc: Madhav Chauhan
Cc: Vandita Kulkarni
Reviewed-by: Madhav Chauhan
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/icl_dsi.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index e3aa9d3d2291..4dd793b78996 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -570,6 +570,28 @@ static void gen11_dsi_ungate_clocks(struct intel_encoder
*encoder)
mutex_unlock(&dev_priv->dpll_lock);
}
+static void gen11_dsi_map_pll(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ struct intel_shared_dpll *pll = crtc_state->shared_dpll;
+ enum port port;
+ u32 val;
+
+ mutex_lock(&dev_priv->dpll_lock);
+
+ val = I915_READ(DPCLKA_CFGCR0_ICL);
+ for_each_dsi_port(port, intel_dsi->ports) {
+ val &= ~DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
+ val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, port);
+ }
+ I915_WRITE(DPCLKA_CFGCR0_ICL, val);
+ POSTING_READ(DPCLKA_CFGCR0_ICL);
+
+ mutex_unlock(&dev_priv->dpll_lock);
+}
+
static void
gen11_dsi_configure_transcoder(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config)
@@ -978,6 +1000,9 @@ static void gen11_dsi_pre_enable(struct intel_encoder
*encoder,
{
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ /* step3b */
+ gen11_dsi_map_pll(encoder, pipe_config);
+
/* step4: enable DSI port and DPHY */
gen11_dsi_enable_port_and_phy(encoder, pipe_config);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RFC 2/5] cgroup: Add mechanism to register vendor specific DRM devices
Hey Matt, On Fri, Nov 30, 2018 at 5:22 PM Matt Roper wrote: > I think Joonas is describing something closer in > design to the cgroup-v2 "cpu" controller, which partitions the general > time/usage allocated to via cgroup; afaiu, "cpu" doesn't really care > which specific core the tasks run on, just the relative weights that > determine how much time they get to run on any of the cores. Depending on the level of optimization one wants to do, I think people care about which cpu core a task runs on. Modern processors are no longer a monolithic 'thing'. At least for AMD, there are multiple cpus on a core complex (CCX), multiple CCX on a die, and multiple dies on a processor. A task running on cpu 0 and cpu 1 on die 0 will behave very differently from a task running on core 0s on die 0 and die 1 on the same socket. (https://en.wikichip.org/wiki/amd/microarchitectures/zen#Die-die_memory_latencies) It's not just an AMD thing either. Here is an open issue on Intel's architecture: https://github.com/kubernetes/kubernetes/issues/67355 and a proposed solution using cpu affinity https://github.com/kubernetes/community/blob/630acc487c80e4981a232cdd8400eb8207119788/keps/sig-node/0030-qos-class-cpu-affinity.md#proposal (by one of your colleagues.) The time-based sharing below is also something we are thinking about, but it's personally not as exciting as the resource-based sharing for me because the time-share use case has already been addressed by our SRIOV/virtualization products. We can potentially have different level of time sharing using cgroup though (in addition to SRIOV), potentially trading efficiency against isolation. That said, I think the time-based approach maybe orthogonal to the resource-based approach (orthogonal in the sense that both are needed depending on the usage.) Regards, Kenny > It sounds like with your hardware, your kernel driver is able to specify > exactly which subset of GPU EU's a specific GPU context winds up running > on. However I think there are a lot of platforms that don't allow that > kind of low-level control. E.g., I don't think we can do that on Intel > hardware; we have a handful of high-level GPU engines that we can submit > different types of batchbuffers to (render, blitter, media, etc.). What > we can do is use GPU preemption to limit how much time specific GPU > contexts get to run on the render engine before the engine is reclaimed > for use by a different context. > > Using a %gputime approach like Joonas is suggesting could be handled in > a driver by reserving specific subsets of EU's on hardware like yours > that's capable of doing that, whereas it could be mostly handled on > other types of hardware via GPU engine preemption. > > I think either approach "gpu_euset" or "%gputime" should map well to a > cgroup controller implementation. Granted, neither one solves the > specific use case I was working on earlier this year where we need > unfair (starvation-okay) scheduling that will run contexts strictly > according to priority (i.e., lower priority contexts will never run at > all unless all higher priority contexts have completed all of their > submitted work), but that's a pretty specialized use case that we'll > probably need to handle in a different manner anyway. > > > Matt > > > > Regards, > > Kennny > > > > > > > > > That combined with the "GPU memory usable" property should be a good > > > > > starting point to start subdividing the GPU resources for multiple > > > > > users. > > > > > > > > > > Regards, Joonas > > > > > > > > > > > > > > > > > Your feedback is highly appreciated. > > > > > > > > > > > > Best Regards, > > > > > > Harish > > > > > > > > > > > > > > > > > > > > > > > > From: amd-gfx on behalf of > > > > > > Tejun Heo > > > > > > Sent: Tuesday, November 20, 2018 5:30 PM > > > > > > To: Ho, Kenny > > > > > > Cc: cgro...@vger.kernel.org; intel-gfx@lists.freedesktop.org; > > > > > > y2ke...@gmail.com; amd-...@lists.freedesktop.org; > > > > > > dri-de...@lists.freedesktop.org > > > > > > Subject: Re: [PATCH RFC 2/5] cgroup: Add mechanism to register > > > > > > vendor specific DRM devices > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > On Tue, Nov 20, 2018 at 10:21:14PM +, Ho, Kenny wrote: > > > > > > > By this reply, are you suggesting that vendor specific resources > > > > > > > will never be acceptable to be managed under cgroup? Let say a > > > > > > > user > > > > > > > > > > > > I wouldn't say never but whatever which gets included as a cgroup > > > > > > controller should have clearly defined resource abstractions and the > > > > > > control schemes around them including support for delegation. > > > > > > AFAICS, > > > > > > gpu side still seems to have a long way to go (and it's not clear > > > > > > whether that's somewhere it will or needs to end up). > > > > > > > > > > > > > want to have similar functionality as what cgroup is offering but > > > > > > > to > > > > > >
Re: [Intel-gfx] [PATCH 0/4] HDCP1.4 fixes
Sean and Daniel, Could you please help me with the review these changes? --Ram On 11/27/2018 7:32 PM, Ramalingam C wrote: Couple of more HDCP1.4 fixes on - Key load process for CFL - Encryption status change time - debug log addition - active platform coverage Ramalingam C (4): drm/i915: Fix GEN9 HDCP1.4 key load process drm/i915: Fix platform coverage for HDCP1.4 drm/i915: debug log for REPLY_ACK missing drm/i915: Increase timeout for Encrypt status change drivers/gpu/drm/i915/intel_dp.c | 6 +- drivers/gpu/drm/i915/intel_hdcp.c | 17 ++--- 2 files changed, 15 insertions(+), 8 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Fuse per-context workaround handling with the common framework
On 30/11/2018 21:22, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-11-30 17:44:11)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 91a750e90dc4..8f985c35ec92 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -452,6 +452,7 @@ struct intel_engine_cs {
struct intel_hw_status_page status_page;
struct i915_ctx_workarounds wa_ctx;
+ struct i915_wa_list ctx_wa_list;
struct i915_wa_list wa_list;
struct i915_wa_list whitelist;
Hmm. I think I would suggest we use
ctx_wa_list
mmio_wa_list ???
whitelist
It is implied workarounds are about mmio one way or the other via struct
i915_wa itself so not sure.
-int intel_ctx_workarounds_init(struct drm_i915_private *dev_priv)
+void intel_ctx_workarounds_init(struct drm_i915_private *dev_priv)
{
- int err = 0;
+ struct i915_wa_list *wal = &dev_priv->engine[RCS]->ctx_wa_list;
And here,
intel_engine_init_ctx_wa(intel_engine_cs *engine)
or something to match the other engine wa_list.
I don't have any better ideas so shout quickly or else I am changing it
to intel_engine_init_ctx_wa.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix the HDMI hot plug disconnection failure (v4)
On Fri, Nov 30, 2018 at 1:15 AM Guang Bai wrote: > > On Thu, 29 Nov 2018 10:17:49 +0200 > Jani Nikula wrote: > > > On Wed, 28 Nov 2018, Guang Bai wrote: > > > On some GEN9 platforms, slowly unplugging (wiggling) the HDMI cable > > > makes the kernel to believe the HDMI display is still connected. > > > This is because the HDMI DDC lines are disconnected a little bit > > > later after the hot-plug interrupt triggered thus an immediate edid > > > fetch can be made. This problem has been identified by more than > > > one customer recently. Use digital port live states to authorize > > > the edid read at HDMI detection point will ensure most of the > > > display related software states updated and rest of them will be > > > renewed accordingly when the port is connected. > > > > > > v2: Fix the formatting issue > > > v3: Use digital port states to authorize the edid read > > > v4: Add comments on issue histories and rationale of the fix (Chris > > > W) > > > > You're not answering Chris Wilson's question. > > > > Why do you think the problems we've historically had with live status > > are no longer a problem? We've tried and reverted live status checks > > at least twice before because of regressions. Why do you think this > > time there won't be regressions? Why do you think this patch makes > > forward progress? > Jani, > I'm still new to kernel developments compared with all of you working > in this area for many years - Haven't got any feedbacks on how > exactly the HDMI live statue *not* fit for HDMI hot-plug related port > status checking, neither had time to track all upstream bugzilla, plus > not working directly with Intel OTC teams > - What are those failing cases/regressions you mentioned above? > - what were the kernel versions related with those developments? > - Given the fact i915 architecture and implementation are constantly > evolving - Should we re-visit those issues with current kernel > implementation? > - Fundamentally, do you think the edid fetch is still *valid* when the > HDMI is unplugged (status either from PCH or DE)? Or other platform > configurations may present more complexities such as kvm switches are > used along with HDMI? > Again, if you could provide me more historical issue details, I'd like > to have some reviews/re-investigation for those cases with current 4.20 > kernel. > Thanks, > -Guang Hi Jani, I don't know the history and what kind of painful regression that you had run into. Could you maybe provide a test plan or some test cases for the regression verification? I can follow steps to try to verify whether if the patch can work on all cases. Chris > > > > I've *repeatedly* said from the beginning that I am very sceptical of > > using live status because we've been burned by it so many times > > before. I don't much care to repeat this anymore. > > > > > > BR, > > Jani. > > > > > > > > > > Cc: Jani Nikula > > > Cc: Chris Chiu > > > Cc: Chris Wilson > > > Signed-off-by: Guang Bai > > > --- > > > drivers/gpu/drm/i915/intel_hdmi.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > > > b/drivers/gpu/drm/i915/intel_hdmi.c index e2c6a2b..8cf7c78 100644 > > > --- a/drivers/gpu/drm/i915/intel_hdmi.c > > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > > > @@ -1929,7 +1929,7 @@ intel_hdmi_detect(struct drm_connector > > > *connector, bool force) > > > intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS); > > > > > > - if (IS_ICELAKE(dev_priv) && > > > + if ((IS_ICELAKE(dev_priv) || IS_GEN9_BC(dev_priv)) && > > > !intel_digital_port_connected(encoder)) > > > goto out; > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Trim unused workaround list entries
On 30/11/2018 21:58, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-11-30 17:44:12)
From: Tvrtko Ursulin
The new workaround list allocator grows the list in chunks so will end up
with some unused space. Trim it when the initialization phase is done to
free up a tiny bit of slab.
v2:
* Simplify with kmemdup. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_workarounds.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 3e6b388ea022..9d876d554e57 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -55,6 +55,19 @@ static void wa_init_start(struct i915_wa_list *wal, const
char *name)
static void wa_init_finish(struct i915_wa_list *wal)
{
+ /* Trim unused entries. */
+ if (wal->count < wal->__size) {
+ struct i915_wa *list = kmemdup(wal->list,
+ wal->count * sizeof(*list),
+ GFP_KERNEL);
+
+ if (list) {
+ kfree(wal->list);
+ wal->list = list;
+ wal->__size = wal->count;
Hmm. We could kill __size entirely if you reallocated on
is_power_of_two(wal->count).
You mean allocate to next power of two is is_power_of_two(wal->count) ?
In that case I could also allocate to next ALIGN(wal->count, CHUNK_SIZE)
if IS_ALIGNED which looks more appropriate for this particular use case.
Can't decide whether it is worth it though. Why not..
Regards,
Tvrtko
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: dsi enabling (rev7)
== Series Details == Series: drm/i915/icl: dsi enabling (rev7) URL : https://patchwork.freedesktop.org/series/51011/ State : warning == Summary == $ dim checkpatch origin/drm-tip 96d02a19d096 drm/i915/icl: push pll to port mapping/unmapping to ddi encoder hooks a3c740ce09ea drm/i915/icl: Sanitize DDI port clock gating for DSI ports 87b45256f131 drm/i915/icl: Calculate DPLL params for DSI -:22: WARNING:BAD_SIGN_OFF: Non-standard signature: Co-developed-by: #22: Co-developed-by: Vandita Kulkarni total: 0 errors, 1 warnings, 0 checks, 22 lines checked fbb01f92a65c drm/i915/icl: Allocate DSI encoder/connector -:137: CHECK:CAMELCASE: Avoid CamelCase: #137: FILE: drivers/gpu/drm/i915/icl_dsi.c:1043: + connector->display_info.subpixel_order = SubPixelHorizontalRGB; total: 0 errors, 0 warnings, 1 checks, 145 lines checked 028d3c2eb0e4 drm/i915/icl: Use the same pll functions for dsi 50773017b12a drm/i915/icl: Fill DSI ports info 62513a8970ed drm/i915/icl: Allocate DSI hosts and imlement host transfer -:187: CHECK:LINE_SPACING: Please don't use multiple blank lines #187: FILE: drivers/gpu/drm/i915/icl_dsi.c:1213: + total: 0 errors, 0 warnings, 1 checks, 171 lines checked 33521ef27138 drm/i915/icl: Add get config functionality for DSI -:16: WARNING:BAD_SIGN_OFF: Non-standard signature: Co-developed-by: #16: Co-developed-by: Madhav Chauhan total: 0 errors, 1 warnings, 0 checks, 45 lines checked 3f22982ec59a drm/i915/icl: Get HW state for DSI encoder 7d6ef2834195 drm/i915/icl: Add DSI encoder compute config hook -:23: WARNING:BAD_SIGN_OFF: Non-standard signature: Co-developed-by: #23: Co-developed-by: Vandita Kulkarni total: 0 errors, 1 warnings, 0 checks, 43 lines checked 532aa53e71c8 drm/i915/icl: Configure DSI Dual link mode 978f80d3edf2 drm/i915/icl: Consider DSI for getting transcoder state 8463e98e1a20 drm/i915/icl: Get pipe timings for DSI 24945f1aac4a drm/i915/icl: Define missing bitfield for shortplug reg 1027ae61ad4a drm/i915/icl: Define Panel power ctrl register 70438b447157 drm/i915/icl: Define display GPIO pins for DSI b2fffaad2d0f drm/i915/icl: add dummy DSI GPIO element execution function c3483c42f102 drm/i915/icl: Gate clocks for DSI 8f5d87749941 drm/i915/icl: Ungate DSI clocks 079bbc7aeea6 drm/i915/icl: add pll mapping for DSI 061f3e41e0c7 HACK: drm/i915/icl: Add changes to program DSI panel GPIOs 48813c1d2c3a HACK: drm/i915/icl: Configure backlight functions for DSI 0de32c2896a1 HACK: drm/i915/bios: ignore VBT not overflowing the mailbox ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/icl: dsi enabling (rev7)
== Series Details == Series: drm/i915/icl: dsi enabling (rev7) URL : https://patchwork.freedesktop.org/series/51011/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/icl: push pll to port mapping/unmapping to ddi encoder hooks Okay! Commit: drm/i915/icl: Sanitize DDI port clock gating for DSI ports Okay! Commit: drm/i915/icl: Calculate DPLL params for DSI Okay! Commit: drm/i915/icl: Allocate DSI encoder/connector +./include/linux/slab.h:332:43: warning: dubious: x & !y Commit: drm/i915/icl: Use the same pll functions for dsi Okay! Commit: drm/i915/icl: Fill DSI ports info Okay! Commit: drm/i915/icl: Allocate DSI hosts and imlement host transfer +drivers/gpu/drm/i915/icl_dsi.c:129:33: warning: expression using sizeof(void) Commit: drm/i915/icl: Add get config functionality for DSI Okay! Commit: drm/i915/icl: Get HW state for DSI encoder Okay! Commit: drm/i915/icl: Add DSI encoder compute config hook Okay! Commit: drm/i915/icl: Configure DSI Dual link mode Okay! Commit: drm/i915/icl: Consider DSI for getting transcoder state Okay! Commit: drm/i915/icl: Get pipe timings for DSI Okay! Commit: drm/i915/icl: Define missing bitfield for shortplug reg Okay! Commit: drm/i915/icl: Define Panel power ctrl register Okay! Commit: drm/i915/icl: Define display GPIO pins for DSI Okay! Commit: drm/i915/icl: add dummy DSI GPIO element execution function Okay! Commit: drm/i915/icl: Gate clocks for DSI Okay! Commit: drm/i915/icl: Ungate DSI clocks Okay! Commit: drm/i915/icl: add pll mapping for DSI Okay! Commit: HACK: drm/i915/icl: Add changes to program DSI panel GPIOs Okay! Commit: HACK: drm/i915/icl: Configure backlight functions for DSI Okay! Commit: HACK: drm/i915/bios: ignore VBT not overflowing the mailbox Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane
On 30.11.2018 15:48, Hans Verkuil wrote: > On 11/30/18 15:29, Ville Syrjälä wrote: >> On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote: >>> Hi Ville, >>> >>> As Christoph cannot respond till middle next week I can try to respond >>> in his absence, as I am familiar with the subject. >>> >>> On 30.11.2018 14:25, Ville Syrjälä wrote: On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote: > Hi, > > I am looking for a way to export the color encoding and range selection > to user space. I came across those properties and am wondering, why > they are meant only for non RGB color encodings. Would it be okay, to > modify them and use with RGB formats as well? What you trying to do? Input limited range RGB data and expand to full range? >>> >>> For example. But there are two more general questions, which >>> surprisingly we have not found answer for. >>> >>> 1. What color encoding and range drm should expect on its input RGB >>> buffers by default? >> RGB is just RGB. There is no encoding. OK, Now I see I have confused encoding with colorspace, Hans thanks for the documentation. As I understand drm by default should expect sRGB colorspace, also for Y'CbCr buffers, and currently there are no standard ways to specify buffer colorspace. Looking at current users of drm_plane_create_color_properties for Y'CbCr buffers it seems default range should be LIMITED. But default encoding is different: mali, armada, nouveau use DRM_COLOR_YCBCR_BT601, i915 uses DRM_COLOR_YCBCR_BT709 - shouldn't this be somehow standardized? What I still do not understand is colorspace conversion(not encoding!) - between pipeline input (framebuffers) and output (HDMI connector for example): 1. Since sRGB, SMPTE170M/BT.601, BT.709 colorspaces are 'almost identical in coverage' (according to wikipedia[1]) no colorspace conversion is performed at all. 2. It is performed somewhere by HW, just my IP documentation is not clear about it. Another thing which still bothers me is RGB range in case of HDMI - CEA-861 expects than on CEA modes limited RGB range should be sent, but the pipeline on the particular hardware I have do not perform any conversion of input buffers. So only limited range RGB buffers are displayed correctly. In such case property describing plane with limited RGB would be useful. [1]: https://en.wikipedia.org/wiki/Rec._709#Primary_chromaticities > It's assumed to be full range >> because no one really uses anything else. > For simple desktop usage that's true. When dealing with video inputs, > this becomes much more complicated. As I said earlier there are cases where output stream should be limited RGB, and no conversion in pipeline - thus framebuffers also should be 'limited RGB'. Regards Andrzej > >>> 2. How userspace should inform drm that given buffer has specified >>> non-default color encoding and range? >>> >>> >>> Hopefully this patch introduces such properties but only for YCbCr >>> formats, the question is what should be the best way to expand it to RGB >>> formats: >>> >>> A. Add another enums: DRM_COLOR_RGB_BT601 and friends. >> BT.601 specifies how to encoder RGB data as YCbCr. So without >> YCbCr BT.601 does not mean anything. Well, the standard does >> contain other things as well I suppose, but for the purposes >> of the color encoding prop only that one part is relevant. > Ah, I misunderstood the meaning of DRM_COLOR_RGB_BT601. > This is the equivalent of V4L2_YCBCR_ENC_601, and that's indeed > only defined for Y'CbCr. But it is often (ab)used as an alias for > the SMPTE170M colorspace (used by SDTV). > > V4L2 has the following defines for colorspaces, transfer functions, > Y'CbCr (and HSV) encodings and quantization ranges: > > https://hverkuil.home.xs4all.nl/spec/uapi/v4l/colorspaces-defs.html > > Missing in this list is the color encoding (RGB vs YCbCr vs HSV) which > is set through the pixelformat fourcc. > > And indeed, we don't have an RGB encoding define since RGB is just RGB :-) > > Regards, > > Hans > >>> B. Reuse current enums, but remove format information from them: >>> DRM_COLOR_YCBCR_BT601 => DRM_COLOR_BT601. >>> >>> >>> Regards >>> >>> Andrzej >>> ... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm/i915: Allocate a common scratch page
Currently we allocate a scratch page for each engine, but since we only
ever write into it for post-sync operations, it is not exposed to
userspace nor do we care for coherency. As we then do not care about its
contents, we can use one page for all, reducing our allocations and
avoid complications by not assuming per-engine isolation.
For later use, it simplifies engine initialisation (by removing the
allocation that required struct_mutex!) and means that we can always rely
on there being a scratch page.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 7
drivers/gpu/drm/i915/i915_gem.c | 50 -
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/intel_engine_cs.c | 42 -
drivers/gpu/drm/i915/intel_lrc.c| 17 +++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 33 +---
drivers/gpu/drm/i915/intel_ringbuffer.h | 5 ---
7 files changed, 71 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d45475287130..0ec65cc48b5a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1996,6 +1996,8 @@ struct drm_i915_private {
struct delayed_work idle_work;
ktime_t last_init_time;
+
+ struct i915_vma *scratch;
} gt;
/* perform PHY state sanity checks? */
@@ -3724,4 +3726,9 @@ static inline int intel_hws_csb_write_index(struct
drm_i915_private *i915)
return I915_HWS_CSB_WRITE_INDEX;
}
+static inline u32 i915_scratch_offset(const struct drm_i915_private *i915)
+{
+ return i915_ggtt_offset(i915->gt.scratch);
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 834240a9b262..cca4285e3329 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5495,6 +5495,44 @@ static int __intel_engines_record_defaults(struct
drm_i915_private *i915)
goto out_ctx;
}
+static int
+i915_gem_init_scratch(struct drm_i915_private *i915, unsigned int size)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ int ret;
+
+ obj = i915_gem_object_create_stolen(i915, size);
+ if (!obj)
+ obj = i915_gem_object_create_internal(i915, size);
+ if (IS_ERR(obj)) {
+ DRM_ERROR("Failed to allocate scratch page\n");
+ return PTR_ERR(obj);
+ }
+
+ vma = i915_vma_instance(obj, &i915->ggtt.vm, NULL);
+ if (IS_ERR(vma)) {
+ ret = PTR_ERR(vma);
+ goto err_unref;
+ }
+
+ ret = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
+ if (ret)
+ goto err_unref;
+
+ i915->gt.scratch = vma;
+ return 0;
+
+err_unref:
+ i915_gem_object_put(obj);
+ return ret;
+}
+
+static void i915_gem_fini_scratch(struct drm_i915_private *i915)
+{
+ i915_vma_unpin_and_release(&i915->gt.scratch, 0);
+}
+
int i915_gem_init(struct drm_i915_private *dev_priv)
{
int ret;
@@ -5541,12 +5579,19 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
goto err_unlock;
}
- ret = i915_gem_contexts_init(dev_priv);
+ ret = i915_gem_init_scratch(dev_priv,
+ IS_GEN2(dev_priv) ? SZ_256K : PAGE_SIZE);
if (ret) {
GEM_BUG_ON(ret == -EIO);
goto err_ggtt;
}
+ ret = i915_gem_contexts_init(dev_priv);
+ if (ret) {
+ GEM_BUG_ON(ret == -EIO);
+ goto err_scratch;
+ }
+
ret = intel_engines_init(dev_priv);
if (ret) {
GEM_BUG_ON(ret == -EIO);
@@ -5619,6 +5664,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
err_context:
if (ret != -EIO)
i915_gem_contexts_fini(dev_priv);
+err_scratch:
+ i915_gem_fini_scratch(dev_priv);
err_ggtt:
err_unlock:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
@@ -5670,6 +5717,7 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
intel_uc_fini(dev_priv);
i915_gem_cleanup_engines(dev_priv);
i915_gem_contexts_fini(dev_priv);
+ i915_gem_fini_scratch(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
intel_cleanup_gt_powersave(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index a6885a59568b..07465123c166 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1571,7 +1571,7 @@ static void gem_record_rings(struct i915_gpu_state *error)
if (HAS_BROKEN_CS_TLB(i915))
ee->wa_batchbuffer =
i915_error_object_create(i915,
-
engine->scr
[Intel-gfx] [PATCH 5/8] drm/i915: Flush GPU relocs harder for gen3
Adding an extra MI_STORE_DWORD_IMM to the gpu relocation path for gen3
was good, but still not good enough. To survive 24+ hours under test we
needed to perform not one, not two but three extra store-dw. Doing so
for each GPU relocation was a little unsightly and since we need to
worry about userspace hitting the same issues, we should apply the dummy
store-dw into the EMIT_FLUSH.
Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing")
References: 7fa28e146994 ("drm/i915: Write GPU relocs harder with gen3")
Testcase: igt/gem_tiled_fence_blits # blb/pnv
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 7 +--
drivers/gpu/drm/i915/intel_ringbuffer.c| 15 ---
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index d4fac09095f8..1aaccbe7e1de 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1268,7 +1268,7 @@ relocate_entry(struct i915_vma *vma,
else if (gen >= 4)
len = 4;
else
- len = 6;
+ len = 3;
batch = reloc_gpu(eb, vma, len);
if (IS_ERR(batch))
@@ -1309,11 +1309,6 @@ relocate_entry(struct i915_vma *vma,
*batch++ = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;
*batch++ = addr;
*batch++ = target_offset;
-
- /* And again for good measure (blb/pnv) */
- *batch++ = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;
- *batch++ = addr;
- *batch++ = target_offset;
}
goto out;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index a3d3126a3938..37bd05cef0e9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -69,19 +69,28 @@ unsigned int intel_ring_update_space(struct intel_ring
*ring)
static int
gen2_render_ring_flush(struct i915_request *rq, u32 mode)
{
+ unsigned int num_store_dw;
u32 cmd, *cs;
cmd = MI_FLUSH;
-
+ num_store_dw = 0;
if (mode & EMIT_INVALIDATE)
cmd |= MI_READ_FLUSH;
+ if (mode & EMIT_FLUSH)
+ num_store_dw = 4;
- cs = intel_ring_begin(rq, 2);
+ cs = intel_ring_begin(rq, 2 + 3 * num_store_dw);
if (IS_ERR(cs))
return PTR_ERR(cs);
*cs++ = cmd;
- *cs++ = MI_NOOP;
+ while (num_store_dw--) {
+ *cs++ = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;
+ *cs++ = i915_scratch_offset(rq->i915);
+ *cs++ = 0;
+ }
+ *cs++ = MI_FLUSH | MI_NO_WRITE_FLUSH;
+
intel_ring_advance(rq, cs);
return 0;
--
2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915/ringbuffer: Clear semaphore sync registers on ring init
Ensure that the sync registers are cleared every time we restart the
ring to avoid stale values from creeping in from random neutrinos.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 992889f9e0ff..81b10d85b738 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -529,6 +529,13 @@ static int init_ring_common(struct intel_engine_cs *engine)
intel_engine_reset_breadcrumbs(engine);
+ if (HAS_LEGACY_SEMAPHORES(engine->i915)) {
+ I915_WRITE(RING_SYNC_0(engine->mmio_base), 0);
+ I915_WRITE(RING_SYNC_1(engine->mmio_base), 0);
+ if (HAS_VEBOX(dev_priv))
+ I915_WRITE(RING_SYNC_2(engine->mmio_base), 0);
+ }
+
/* Enforce ordering by reading HEAD register back */
I915_READ_HEAD(engine);
--
2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915/selftests: Reorder request allocation vs vma pinning
Impose a restraint that we have all vma pinned for a request prior to
its allocation. This is to simplify request construction, and should
facilitate unravelling the lock interdependencies later.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/huge_pages.c | 31 +++--
drivers/gpu/drm/i915/selftests/igt_spinner.c | 86 ++--
.../gpu/drm/i915/selftests/intel_hangcheck.c | 123 +-
3 files changed, 119 insertions(+), 121 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/huge_pages.c
b/drivers/gpu/drm/i915/selftests/huge_pages.c
index 26c065c8d2c0..a0c7cbc212ba 100644
--- a/drivers/gpu/drm/i915/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/selftests/huge_pages.c
@@ -972,7 +972,6 @@ static int gpu_write(struct i915_vma *vma,
{
struct i915_request *rq;
struct i915_vma *batch;
- int flags = 0;
int err;
GEM_BUG_ON(!intel_engine_can_store_dword(engine));
@@ -981,14 +980,14 @@ static int gpu_write(struct i915_vma *vma,
if (err)
return err;
- rq = i915_request_alloc(engine, ctx);
- if (IS_ERR(rq))
- return PTR_ERR(rq);
-
batch = gpu_write_dw(vma, dword * sizeof(u32), value);
- if (IS_ERR(batch)) {
- err = PTR_ERR(batch);
- goto err_request;
+ if (IS_ERR(batch))
+ return PTR_ERR(batch);
+
+ rq = i915_request_alloc(engine, ctx);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto err_batch;
}
err = i915_vma_move_to_active(batch, rq, 0);
@@ -996,21 +995,21 @@ static int gpu_write(struct i915_vma *vma,
goto err_request;
i915_gem_object_set_active_reference(batch->obj);
- i915_vma_unpin(batch);
- i915_vma_close(batch);
- err = engine->emit_bb_start(rq,
- batch->node.start, batch->node.size,
- flags);
+ err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
if (err)
goto err_request;
- err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
+ err = engine->emit_bb_start(rq,
+ batch->node.start, batch->node.size,
+ 0);
+err_request:
if (err)
i915_request_skip(rq, err);
-
-err_request:
i915_request_add(rq);
+err_batch:
+ i915_vma_unpin(batch);
+ i915_vma_close(batch);
return err;
}
diff --git a/drivers/gpu/drm/i915/selftests/igt_spinner.c
b/drivers/gpu/drm/i915/selftests/igt_spinner.c
index 8cd34f6e6859..0e70df0230b8 100644
--- a/drivers/gpu/drm/i915/selftests/igt_spinner.c
+++ b/drivers/gpu/drm/i915/selftests/igt_spinner.c
@@ -68,48 +68,65 @@ static u64 hws_address(const struct i915_vma *hws,
return hws->node.start + seqno_offset(rq->fence.context);
}
-static int emit_recurse_batch(struct igt_spinner *spin,
- struct i915_request *rq,
- u32 arbitration_command)
+static int move_to_active(struct i915_vma *vma,
+ struct i915_request *rq,
+ unsigned int flags)
{
- struct i915_address_space *vm = &rq->gem_context->ppgtt->vm;
+ int err;
+
+ err = i915_vma_move_to_active(vma, rq, flags);
+ if (err)
+ return err;
+
+ if (!i915_gem_object_has_active_reference(vma->obj)) {
+ i915_gem_object_get(vma->obj);
+ i915_gem_object_set_active_reference(vma->obj);
+ }
+
+ return 0;
+}
+
+struct i915_request *
+igt_spinner_create_request(struct igt_spinner *spin,
+ struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ u32 arbitration_command)
+{
+ struct i915_address_space *vm = &ctx->ppgtt->vm;
+ struct i915_request *rq = NULL;
struct i915_vma *hws, *vma;
u32 *batch;
int err;
vma = i915_vma_instance(spin->obj, vm, NULL);
if (IS_ERR(vma))
- return PTR_ERR(vma);
+ return ERR_CAST(vma);
hws = i915_vma_instance(spin->hws, vm, NULL);
if (IS_ERR(hws))
- return PTR_ERR(hws);
+ return ERR_CAST(hws);
err = i915_vma_pin(vma, 0, 0, PIN_USER);
if (err)
- return err;
+ return ERR_PTR(err);
err = i915_vma_pin(hws, 0, 0, PIN_USER);
if (err)
goto unpin_vma;
- err = i915_vma_move_to_active(vma, rq, 0);
- if (err)
+ rq = i915_request_alloc(engine, ctx);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
goto unpin_hws;
-
- if (!i915_gem_object_has_active_reference(vma->obj)) {
- i915_gem_object_get(vma->obj);
- i915_gem_object_set_active_reference(vma
[Intel-gfx] [PATCH 8/8] drm/i915: Pipeline PDP updates for Braswell
Currently we face a severe problem on Braswell that manifests as invalid
ppGTT accesses. The code tries to maintain the PDP (page directory
pointers) inside the context in two ways, direct write into the context
and a pipelined LRI update. The direct write into the context is
fundamentally racy as it is unserialised with any access (read or write)
the GPU is doing. By asserting that Braswell is not used with vGPU
(currently an unsupported platform) we can eliminate the dangerous
direct write into the context image and solely use the pipelined update.
However, the LRI of the PDP fouls up the GPU, causing it to freeze and
take out the machine with "forcewake ack timeouts". This seems possible
to workaround by preventing the GPU from sleeping (via means of
disabling the power-state management interface, i.e. forcing each ring
to remain awake) around the update.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108656
References: https://bugs.freedesktop.org/show_bug.cgi?id=108714
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 -
drivers/gpu/drm/i915/i915_request.c | 5 -
drivers/gpu/drm/i915/intel_lrc.c| 137 +++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 5 +-
4 files changed, 68 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index add1fe7aeb93..62bde517d383 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1423,8 +1423,6 @@ static int gen8_ppgtt_alloc_pdp(struct i915_address_space
*vm,
gen8_initialize_pd(vm, pd);
gen8_ppgtt_set_pdpe(vm, pdp, pd, pdpe);
GEM_BUG_ON(pdp->used_pdpes > i915_pdpes_per_pdp(vm));
-
- mark_tlbs_dirty(i915_vm_to_ppgtt(vm));
}
ret = gen8_ppgtt_alloc_pd(vm, pd, start, length);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index ca95ab2f4cfa..8ab8e8e6a086 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -719,11 +719,6 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
*/
rq->head = rq->ring->emit;
- /* Unconditionally invalidate GPU caches and TLBs. */
- ret = engine->emit_flush(rq, EMIT_INVALIDATE);
- if (ret)
- goto err_unwind;
-
ret = engine->request_alloc(rq);
if (ret)
goto err_unwind;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index de070dca4033..1ec3f80a4472 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -363,31 +363,12 @@ execlists_context_schedule_out(struct i915_request *rq,
unsigned long status)
trace_i915_request_out(rq);
}
-static void
-execlists_update_context_pdps(struct i915_hw_ppgtt *ppgtt, u32 *reg_state)
-{
- ASSIGN_CTX_PDP(ppgtt, reg_state, 3);
- ASSIGN_CTX_PDP(ppgtt, reg_state, 2);
- ASSIGN_CTX_PDP(ppgtt, reg_state, 1);
- ASSIGN_CTX_PDP(ppgtt, reg_state, 0);
-}
-
static u64 execlists_update_context(struct i915_request *rq)
{
- struct i915_hw_ppgtt *ppgtt = rq->gem_context->ppgtt;
struct intel_context *ce = rq->hw_context;
- u32 *reg_state = ce->lrc_reg_state;
-
- reg_state[CTX_RING_TAIL+1] = intel_ring_set_tail(rq->ring, rq->tail);
- /*
-* True 32b PPGTT with dynamic page allocation: update PDP
-* registers and point the unallocated PDPs to scratch page.
-* PML4 is allocated during ppgtt init, so this is not needed
-* in 48-bit mode.
-*/
- if (!i915_vm_is_48bit(&ppgtt->vm))
- execlists_update_context_pdps(ppgtt, reg_state);
+ ce->lrc_reg_state[CTX_RING_TAIL + 1] =
+ intel_ring_set_tail(rq->ring, rq->tail);
/*
* Make sure the context image is complete before we submit it to HW.
@@ -1240,29 +1221,80 @@ execlists_context_pin(struct intel_engine_cs *engine,
return __execlists_context_pin(engine, ctx, ce);
}
+static int emit_pdps(struct i915_request *rq)
+{
+ const struct intel_engine_cs * const engine = rq->engine;
+ struct i915_hw_ppgtt * const ppgtt = rq->gem_context->ppgtt;
+ int err, i;
+ u32 *cs;
+
+ err = engine->emit_flush(rq, EMIT_INVALIDATE);
+ if (err)
+ return err;
+
+ cs = intel_ring_begin(rq, 4 * GEN8_3LVL_PDPES + 2);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ /*
+* Force the GPU (not just the local engine/powerwell!) to remain awake,
+* or else we may kill the machine with "timed out waiting for
+* forcewake ack request".
+*/
+
+ *cs++ = MI_LOAD_REGISTER_IMM(2 * GEN8_3LVL_PDPES) | MI_LRI_FORCE_POSTED;
+ for (i = GEN8_3LVL_PDPES; i--; ) {
+
[Intel-gfx] [PATCH 1/8] drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate
Change the on-cpu check to on-runqueue to catch if the waiter has been
woken (and reset its current_state back to TASK_UNINTERRUPTIBLE to
perform the seqno check) but is sleeping due to being preempted off the
cpu.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 84bf8d827136..447c5256f63a 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -27,11 +27,7 @@
#include "i915_drv.h"
-#ifdef CONFIG_SMP
-#define task_asleep(tsk) ((tsk)->state & TASK_NORMAL && !(tsk)->on_cpu)
-#else
-#define task_asleep(tsk) ((tsk)->state & TASK_NORMAL)
-#endif
+#define task_asleep(tsk) ((tsk)->state & TASK_NORMAL && !(tsk)->on_rq)
static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs *b)
{
--
2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915: Complete the fences as they are cancelled due to wedging
We inspect the requests under the assumption that they will be marked as
completed when they are removed from the queue. Currently however, in the
process of wedging the requests will be removed from the queue before they
are completed, so rearrange the code to complete the fences before the
locks are dropped.
<1>[ 354.473346] BUG: unable to handle kernel NULL pointer dereference at
0250
<6>[ 354.473363] PGD 0 P4D 0
<4>[ 354.473370] Oops: [#1] PREEMPT SMP PTI
<4>[ 354.473380] CPU: 0 PID: 4470 Comm: gem_eio Tainted: G U
4.20.0-rc4-CI-CI_DRM_5216+ #1
<4>[ 354.473393] Hardware name: Intel Corporation NUC7CJYH/NUC7JYB, BIOS
JYGLKCPX.86A.0027.2018.0125.1347 01/25/2018
<4>[ 354.473480] RIP: 0010:__i915_schedule+0x311/0x5e0 [i915]
<4>[ 354.473490] Code: 49 89 44 24 20 4d 89 4c 24 28 4d 89 29 44 39 b3 a0 04
00 00 7d 3a 41 8b 44 24 78 85 c0 74 13 48 8b 93 78 04 00 00 48 83 e2 fc <39> 82
50 02 00 00 79 1e 44 89 b3 a0 04 00 00 48 8d bb d0 03 00 00
<4>[ 354.473515] RSP: 0018:c91bba90 EFLAGS: 00010046
<4>[ 354.473524] RAX: 0003 RBX: 8882624c8008 RCX:
f34a7378
<4>[ 354.473535] RDX: RSI: RDI:
8882624c8048
<4>[ 354.473545] RBP: c91bbab0 R08: 5963f1f1 R09:
<4>[ 354.473556] R10: c91bba10 R11: 8882624c8060 R12:
88824fdd7b98
<4>[ 354.473567] R13: 88824fdd7bb8 R14: 0001 R15:
88824fdd7750
<4>[ 354.473578] FS: 7f44b4b5b980() GS:888277e0()
knlGS:
<4>[ 354.473590] CS: 0010 DS: ES: CR0: 80050033
<4>[ 354.473599] CR2: 0250 CR3: 00026976e000 CR4:
00340ef0
<4>[ 354.473611] Call Trace:
<4>[ 354.473622] ? lock_acquire+0xa6/0x1c0
<4>[ 354.473677] ? i915_schedule_bump_priority+0x57/0xd0 [i915]
<4>[ 354.473736] i915_schedule_bump_priority+0x72/0xd0 [i915]
<4>[ 354.473792] i915_request_wait+0x4db/0x840 [i915]
<4>[ 354.473804] ? get_pwq.isra.4+0x2c/0x50
<4>[ 354.473813] ? ___preempt_schedule+0x16/0x18
<4>[ 354.473824] ? wake_up_q+0x70/0x70
<4>[ 354.473831] ? wake_up_q+0x70/0x70
<4>[ 354.473882] ? gen6_rps_boost+0x118/0x120 [i915]
<4>[ 354.473936] i915_gem_object_wait_fence+0x8a/0x110 [i915]
<4>[ 354.473991] i915_gem_object_wait+0x113/0x500 [i915]
<4>[ 354.474047] i915_gem_wait_ioctl+0x11c/0x2f0 [i915]
<4>[ 354.474101] ? i915_gem_unset_wedged+0x210/0x210 [i915]
<4>[ 354.474113] drm_ioctl_kernel+0x81/0xf0
<4>[ 354.474123] drm_ioctl+0x2de/0x390
<4>[ 354.474175] ? i915_gem_unset_wedged+0x210/0x210 [i915]
<4>[ 354.474187] ? finish_task_switch+0x95/0x260
<4>[ 354.474197] ? lock_acquire+0xa6/0x1c0
<4>[ 354.474207] do_vfs_ioctl+0xa0/0x6e0
<4>[ 354.474217] ? __fget+0xfc/0x1e0
<4>[ 354.474225] ksys_ioctl+0x35/0x60
<4>[ 354.474233] __x64_sys_ioctl+0x11/0x20
<4>[ 354.474241] do_syscall_64+0x55/0x190
<4>[ 354.474251] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 354.474260] RIP: 0033:0x7f44b3de65d7
<4>[ 354.474267] Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48
c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48
<4>[ 354.474293] RSP: 002b:7fff974948e8 EFLAGS: 0246 ORIG_RAX:
0010
<4>[ 354.474305] RAX: ffda RBX: RCX:
7f44b3de65d7
<4>[ 354.474316] RDX: 7fff97494940 RSI: c010646c RDI:
0007
<4>[ 354.474327] RBP: 7fff97494940 R08: R09:
7f44b40bbc40
<4>[ 354.474337] R10: R11: 0246 R12:
c010646c
<4>[ 354.474348] R13: 0007 R14: R15:
v2: Avoid floating requests.
v3: Can't call dma_fence_signal() under the timeline lock!
v4: Can't call dma_fence_signal() from inside another fence either.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 54 +
drivers/gpu/drm/i915/intel_lrc.c| 13 --
drivers/gpu/drm/i915/intel_ringbuffer.c | 13 +-
3 files changed, 31 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c55b1f75c980..834240a9b262 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3308,16 +3308,6 @@ void i915_gem_reset_finish(struct drm_i915_private
*dev_priv)
}
static void nop_submit_request(struct i915_request *request)
-{
- GEM_TRACE("%s fence %llx:%d -> -EIO\n",
- request->engine->name,
- request->fence.context, request->fence.seqno);
- dma_fence_set_error(&request->fence, -EIO);
-
- i915_request_submit(request);
-}
-
-static void nop_complete_submit_request(struct i915_request *request)
{
unsigned long flags;
@@ -3354,57 +3344,33 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
* rolling the glo
[Intel-gfx] [PATCH 6/8] drm/i915/selftests: Terminate hangcheck sanitycheck forcibly
If all else fails and we are stuck eternally waiting for the undying
request, abandon all hope.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index defe671130ab..a48fbe2557ea 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -308,6 +308,7 @@ static int igt_hang_sanitycheck(void *arg)
goto unlock;
for_each_engine(engine, i915, id) {
+ struct igt_wedge_me w;
long timeout;
if (!intel_engine_can_store_dword(engine))
@@ -328,9 +329,14 @@ static int igt_hang_sanitycheck(void *arg)
i915_request_add(rq);
- timeout = i915_request_wait(rq,
- I915_WAIT_LOCKED,
- MAX_SCHEDULE_TIMEOUT);
+ timeout = 0;
+ igt_wedge_on_timeout(&w, i915, HZ / 10 /* 100ms timeout*/)
+ timeout = i915_request_wait(rq,
+ I915_WAIT_LOCKED,
+ MAX_SCHEDULE_TIMEOUT);
+ if (i915_terminally_wedged(&i915->gpu_error))
+ timeout = -EIO;
+
i915_request_put(rq);
if (timeout < 0) {
--
2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: dsi enabling (rev7)
== Series Details ==
Series: drm/i915/icl: dsi enabling (rev7)
URL : https://patchwork.freedesktop.org/series/51011/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5239 -> Patchwork_10995
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/51011/revisions/7/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_10995:
### IGT changes ###
Possible regressions
* igt@kms_flip@basic-flip-vs-dpms:
- {fi-icl-u3}:PASS -> DMESG-WARN
* {igt@runner@aborted}:
- {fi-icl-u3}:NOTRUN -> FAIL
Known issues
Here are the changes found in Patchwork_10995 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-ivb-3520m: PASS -> FAIL [fdo#108880]
* igt@i915_selftest@live_coherency:
- fi-gdg-551: PASS -> DMESG-FAIL [fdo#107164]
* {igt@runner@aborted}:
- {fi-icl-y}: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#108622] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107164]: https://bugs.freedesktop.org/show_bug.cgi?id=107164
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108880]: https://bugs.freedesktop.org/show_bug.cgi?id=108880
Participating hosts (47 -> 42)
--
Additional (1): fi-icl-y
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-pnv-d510
Build changes
-
* Linux: CI_DRM_5239 -> Patchwork_10995
CI_DRM_5239: 6b82ae50cbf9b70fb3884937a221f69261c4c41c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4736: 285ebfb3b7adc56586031afa5150c4e5ad40c229 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10995: 0de32c2896a1ff7e0d9f7663bf3c52dff55cf8f4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0de32c2896a1 HACK: drm/i915/bios: ignore VBT not overflowing the mailbox
48813c1d2c3a HACK: drm/i915/icl: Configure backlight functions for DSI
061f3e41e0c7 HACK: drm/i915/icl: Add changes to program DSI panel GPIOs
079bbc7aeea6 drm/i915/icl: add pll mapping for DSI
8f5d87749941 drm/i915/icl: Ungate DSI clocks
c3483c42f102 drm/i915/icl: Gate clocks for DSI
b2fffaad2d0f drm/i915/icl: add dummy DSI GPIO element execution function
70438b447157 drm/i915/icl: Define display GPIO pins for DSI
1027ae61ad4a drm/i915/icl: Define Panel power ctrl register
24945f1aac4a drm/i915/icl: Define missing bitfield for shortplug reg
8463e98e1a20 drm/i915/icl: Get pipe timings for DSI
978f80d3edf2 drm/i915/icl: Consider DSI for getting transcoder state
532aa53e71c8 drm/i915/icl: Configure DSI Dual link mode
7d6ef2834195 drm/i915/icl: Add DSI encoder compute config hook
3f22982ec59a drm/i915/icl: Get HW state for DSI encoder
33521ef27138 drm/i915/icl: Add get config functionality for DSI
62513a8970ed drm/i915/icl: Allocate DSI hosts and imlement host transfer
50773017b12a drm/i915/icl: Fill DSI ports info
028d3c2eb0e4 drm/i915/icl: Use the same pll functions for dsi
fbb01f92a65c drm/i915/icl: Allocate DSI encoder/connector
87b45256f131 drm/i915/icl: Calculate DPLL params for DSI
a3c740ce09ea drm/i915/icl: Sanitize DDI port clock gating for DSI ports
96d02a19d096 drm/i915/icl: push pll to port mapping/unmapping to ddi encoder
hooks
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10995/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915: Introduce per-engine workarounds
From: Tvrtko Ursulin
We stopped re-applying the GT workarounds after engine reset since commit
59b449d5c82a ("drm/i915: Split out functions for different kinds of
workarounds").
Issue with this is that some of the GT workarounds live in the MMIO space
which gets lost during engine resets. So far the registers in 0x2xxx and
0xbxxx address range have been identified to be affected.
This losing of applied workarounds has obvious negative effects and can
even lead to hard system hangs (see the linked Bugzilla).
Rather than just restoring this re-application, because we have also
observed that it is not safe to just re-write all GT workarounds after
engine resets (GPU might be live and weird hardware states can happen),
we introduce a new class of per-engine workarounds and move only the
affected GT workarounds over.
Using the framework introduced in the previous patch, we therefore after
engine reset, re-apply only the workarounds living in the affected MMIO
address ranges.
v2:
* Move Wa_1406609255:icl to engine workarounds as well.
* Rename API. (Chris Wilson)
* Drop redundant IS_KABYLAKE. (Chris Wilson)
* Re-order engine wa/ init so latest platforms are first. (Rodrigo Vivi)
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=107945
Fixes: 59b449d5c82a ("drm/i915: Split out functions for different kinds of
workarounds")
Cc: Mika Kuoppala
Cc: Ville Syrjälä
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Acked-by: Rodrigo Vivi
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 2 +
drivers/gpu/drm/i915/intel_lrc.c | 4 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +
drivers/gpu/drm/i915/intel_workarounds.c | 261 ---
drivers/gpu/drm/i915/intel_workarounds.h | 3 +
5 files changed, 153 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 759c0fd58f8c..ef5d202e9d45 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -723,6 +723,8 @@ void intel_engine_cleanup_common(struct intel_engine_cs
*engine)
__intel_context_unpin(i915->kernel_context, engine);
i915_timeline_fini(&engine->timeline);
+
+ intel_wa_list_free(&engine->wa_list);
}
u64 intel_engine_get_active_head(const struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 11f4e6148557..7a7787cbafee 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1617,6 +1617,8 @@ static bool unexpected_starting_state(struct
intel_engine_cs *engine)
static int gen8_init_common_ring(struct intel_engine_cs *engine)
{
+ intel_engine_apply_workarounds(engine);
+
intel_mocs_init_engine(engine);
intel_engine_reset_breadcrumbs(engine);
@@ -2314,6 +2316,8 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
ret);
}
+ intel_engine_init_workarounds(engine);
+
return 0;
err_cleanup_common:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 8a2270b209b0..c5ff3d31cab7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -15,6 +15,7 @@
#include "i915_selftest.h"
#include "i915_timeline.h"
#include "intel_gpu_commands.h"
+#include "intel_workarounds.h"
struct drm_printer;
struct i915_sched_attr;
@@ -451,6 +452,7 @@ struct intel_engine_cs {
struct intel_hw_status_page status_page;
struct i915_ctx_workarounds wa_ctx;
+ struct i915_wa_list wa_list;
struct i915_vma *scratch;
u32 irq_keep_mask; /* always keep these interrupts */
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index f05f13547034..d5d5ca7f8f17 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -655,17 +655,6 @@ static void gen9_gt_workarounds_init(struct
drm_i915_private *i915)
{
struct i915_wa_list *wal = &i915->gt_wa_list;
- /* WaContextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl,glk,cfl */
- wa_masked_en(wal,
-GEN9_CSFE_CHICKEN1_RCS,
-GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE);
-
-
- /* WaEnableLbsSlaRetryTimerDecrement:skl,bxt,kbl,glk,cfl */
- wa_write_or(wal,
- BDW_SCRATCH1,
- GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE);
-
/* WaDisableKillLogic:bxt,skl,kbl */
if (!IS_COFFEELAKE(i915))
wa_write_or(wal,
@@ -687,24 +676,6 @@ static void gen9_gt_workarounds_init(struct
drm_i915_private *i915)
wa_write_or(wal,
GAM_ECOCHK,
BDW_DISABLE_HDC_INVALIDATION);
-
- /*
[Intel-gfx] [PATCH v3 0/7] Restore workarounds after engine reset and unify their handling
From: Tvrtko Ursulin
First two patches in this series fix losing of workarounds after engine reset
(https://bugzilla.freedesktop.org/show_bug.cgi?id=107945) which started
happening after 59b449d5c82a ("drm/i915: Split out functions for different kinds
of workarounds").
But since it was discovered to be unsafe to simply re-apply all of them, against
a possibly active GPU, and potentially from IRQ context, the approach taken was
to split GT workarounds and per-engine workarounds. Latter so far contain the
ones living in the 0x2xxx and 0xbxxx range, which were empirically shown to be
lost after RCS reset.
This way only a smaller set of affected workarounds can be applied after engine
resetm, which is done with irq safe read-modify-write cycle.
The series is structured like this so first two patches are as standalone as
possible so it is easy (easier) to backport them. The rest of the series
cleans up the whole workaround handling by moving all four classes of them to a
common framework.
v2:
* One patch less due removing verification after engine reset.
* See patch change logs.
v3:
* Further review comments as per individual change logs.
Tvrtko Ursulin (7):
drm/i915: Record GT workarounds in a list
drm/i915: Introduce per-engine workarounds
drm/i915: Verify GT workaround state after GPU init
drm/i915/selftests: Add tests for GT and engine workaround
verification
drm/i915: Move register white-listing to the common workaround
framework
drm/i915: Fuse per-context workaround handling with the common
framework
drm/i915: Trim unused workaround list entries
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_debugfs.c | 12 +-
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 17 +-
drivers/gpu/drm/i915/i915_gem.c | 7 +-
drivers/gpu/drm/i915/i915_gem_context.c | 6 +-
drivers/gpu/drm/i915/intel_engine_cs.c| 4 +
drivers/gpu/drm/i915/intel_lrc.c | 11 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
drivers/gpu/drm/i915/intel_workarounds.c | 987 +++---
drivers/gpu/drm/i915/intel_workarounds.h | 36 +-
drivers/gpu/drm/i915/selftests/igt_reset.c| 44 +
drivers/gpu/drm/i915/selftests/igt_reset.h| 15 +
.../gpu/drm/i915/selftests/intel_hangcheck.c | 51 +-
.../drm/i915/selftests/intel_workarounds.c| 182 +++-
16 files changed, 882 insertions(+), 499 deletions(-)
create mode 100644 drivers/gpu/drm/i915/selftests/igt_reset.c
create mode 100644 drivers/gpu/drm/i915/selftests/igt_reset.h
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915: Move register white-listing to the common workaround framework
From: Tvrtko Ursulin
Instead of having a separate list of white-listed registers we can
trivially move this to the common workarounds framework.
This brings us one step closer to the goal of driving all workaround
classes using the same code.
v2:
* Use GEM_DEBUG_WARN_ON for the sanity check. (Chris Wilson)
v3:
* API rename. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c| 1 +
drivers/gpu/drm/i915/intel_lrc.c | 5 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
drivers/gpu/drm/i915/intel_workarounds.c | 83 ---
drivers/gpu/drm/i915/intel_workarounds.h | 3 +-
.../drm/i915/selftests/intel_workarounds.c| 40 -
6 files changed, 60 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index ef5d202e9d45..496462d77ebc 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -725,6 +725,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs
*engine)
i915_timeline_fini(&engine->timeline);
intel_wa_list_free(&engine->wa_list);
+ intel_wa_list_free(&engine->whitelist);
}
u64 intel_engine_get_active_head(const struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 7a7787cbafee..af61a3cf9cb8 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1643,7 +1643,7 @@ static int gen8_init_render_ring(struct intel_engine_cs
*engine)
if (ret)
return ret;
- intel_whitelist_workarounds_apply(engine);
+ intel_engine_apply_whitelist(engine);
/* We need to disable the AsyncFlip performance optimisations in order
* to use MI_WAIT_FOR_EVENT within the CS. It should already be
@@ -1666,7 +1666,7 @@ static int gen9_init_render_ring(struct intel_engine_cs
*engine)
if (ret)
return ret;
- intel_whitelist_workarounds_apply(engine);
+ intel_engine_apply_whitelist(engine);
return 0;
}
@@ -2316,6 +2316,7 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
ret);
}
+ intel_engine_init_whitelist(engine);
intel_engine_init_workarounds(engine);
return 0;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index c5ff3d31cab7..91a750e90dc4 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -453,6 +453,7 @@ struct intel_engine_cs {
struct intel_hw_status_page status_page;
struct i915_ctx_workarounds wa_ctx;
struct i915_wa_list wa_list;
+ struct i915_wa_list whitelist;
struct i915_vma *scratch;
u32 irq_keep_mask; /* always keep these interrupts */
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index e7b0c6b98d94..0350513bf7f7 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1010,29 +1010,20 @@ bool intel_gt_verify_workarounds(struct
drm_i915_private *dev_priv,
return wa_list_verify(dev_priv, &dev_priv->gt_wa_list, from);
}
-struct whitelist {
- i915_reg_t reg[RING_MAX_NONPRIV_SLOTS];
- unsigned int count;
- u32 nopid;
-};
-
-static void whitelist_reg(struct whitelist *w, i915_reg_t reg)
+static void
+whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
{
- if (GEM_DEBUG_WARN_ON(w->count >= RING_MAX_NONPRIV_SLOTS))
- return;
-
- w->reg[w->count++] = reg;
-}
+ struct i915_wa wa = {
+ .reg = reg
+ };
-static void bdw_whitelist_build(struct whitelist *w)
-{
-}
+ if (GEM_DEBUG_WARN_ON(wal->count >= RING_MAX_NONPRIV_SLOTS))
+ return;
-static void chv_whitelist_build(struct whitelist *w)
-{
+ wal_add(wal, &wa);
}
-static void gen9_whitelist_build(struct whitelist *w)
+static void gen9_whitelist_build(struct i915_wa_list *w)
{
/* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
whitelist_reg(w, GEN9_CTX_PREEMPT_REG);
@@ -1044,7 +1035,7 @@ static void gen9_whitelist_build(struct whitelist *w)
whitelist_reg(w, GEN8_HDC_CHICKEN1);
}
-static void skl_whitelist_build(struct whitelist *w)
+static void skl_whitelist_build(struct i915_wa_list *w)
{
gen9_whitelist_build(w);
@@ -1052,12 +1043,12 @@ static void skl_whitelist_build(struct whitelist *w)
whitelist_reg(w, GEN8_L3SQCREG4);
}
-static void bxt_whitelist_build(struct whitelist *w)
+static void bxt_whitelist_build(struct i915_wa_list *w)
{
gen9_whitelist_build(w);
}
-static void kbl_whitelist_build(struct whitelist *w)
+static void kbl_whitelist_build(struct i915_wa_list *w)
{
gen9_wh
[Intel-gfx] [PATCH 6/7] drm/i915: Fuse per-context workaround handling with the common framework
From: Tvrtko Ursulin
Convert the per context workaround handling code to run against the newly
introduced common workaround framework and fuse the two to use the
existing smarter list add helper, the one which does the sorted insert and
merges registers where possible.
This completes migration of all four classes of workarounds onto the
common framework.
Existing macros are kept untouched for smaller code churn.
v2:
* Rename to list name ctx_wa_list and move from dev_priv to engine.
v3:
* API rename and parameters tweaking. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 +-
drivers/gpu/drm/i915/i915_drv.h | 15 -
drivers/gpu/drm/i915/i915_gem_context.c | 6 +-
drivers/gpu/drm/i915/intel_engine_cs.c | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
drivers/gpu/drm/i915/intel_workarounds.c | 334 +++
drivers/gpu/drm/i915/intel_workarounds.h | 5 +-
9 files changed, 168 insertions(+), 210 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 129b9a6f8309..38dcee1ca062 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3375,13 +3375,15 @@ static int i915_shared_dplls_info(struct seq_file *m,
void *unused)
static int i915_wa_registers(struct seq_file *m, void *unused)
{
- struct i915_workarounds *wa = &node_to_i915(m->private)->workarounds;
- int i;
+ struct drm_i915_private *i915 = node_to_i915(m->private);
+ const struct i915_wa_list *wal = &i915->engine[RCS]->ctx_wa_list;
+ struct i915_wa *wa;
+ unsigned int i;
- seq_printf(m, "Workarounds applied: %d\n", wa->count);
- for (i = 0; i < wa->count; ++i)
+ seq_printf(m, "Workarounds applied: %u\n", wal->count);
+ for (i = 0, wa = wal->list; i < wal->count; i++, wa++)
seq_printf(m, "0x%X: 0x%08X, mask: 0x%08X\n",
- wa->reg[i].addr, wa->reg[i].value, wa->reg[i].mask);
+ i915_mmio_reg_offset(wa->reg), wa->val, wa->mask);
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9ddbcc1f3554..443e08f4736a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1189,20 +1189,6 @@ struct i915_frontbuffer_tracking {
unsigned flip_bits;
};
-struct i915_wa_reg {
- u32 addr;
- u32 value;
- /* bitmask representing WA bits */
- u32 mask;
-};
-
-#define I915_MAX_WA_REGS 16
-
-struct i915_workarounds {
- struct i915_wa_reg reg[I915_MAX_WA_REGS];
- u32 count;
-};
-
struct i915_virtual_gpu {
bool active;
u32 caps;
@@ -1652,7 +1638,6 @@ struct drm_i915_private {
int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
- struct i915_workarounds workarounds;
struct i915_wa_list gt_wa_list;
struct i915_frontbuffer_tracking fb_tracking;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b97963db0287..371c07087095 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -535,16 +535,12 @@ static bool needs_preempt_context(struct drm_i915_private
*i915)
int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
{
struct i915_gem_context *ctx;
- int ret;
/* Reassure ourselves we are only called once */
GEM_BUG_ON(dev_priv->kernel_context);
GEM_BUG_ON(dev_priv->preempt_context);
- ret = intel_ctx_workarounds_init(dev_priv);
- if (ret)
- return ret;
-
+ intel_engine_init_ctx_wa(dev_priv->engine[RCS]);
init_contexts(dev_priv);
/* lowest priority; idle task */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 496462d77ebc..6b427bc52f78 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -724,6 +724,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs
*engine)
i915_timeline_fini(&engine->timeline);
+ intel_wa_list_free(&engine->ctx_wa_list);
intel_wa_list_free(&engine->wa_list);
intel_wa_list_free(&engine->whitelist);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index af61a3cf9cb8..7de7aa4715fc 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2078,7 +2078,7 @@ static int gen8_init_rcs_context(struct i915_request *rq)
{
int ret;
- ret = intel_ctx_workarounds_emit(rq);
+ ret = intel_engine_emit_ctx_wa(rq);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 28ae1e436ea6..026
[Intel-gfx] [PATCH 4/7] drm/i915/selftests: Add tests for GT and engine workaround verification
From: Tvrtko Ursulin
Two simple selftests which test that both GT and engine workarounds are
not lost after either a full GPU reset, or after the per-engine ones.
(Including checks that one engine reset is not affecting workarounds not
belonging to itself.)
v2:
* Rebase for series refactoring.
* Add spinner for actual engine reset!
* Add idle reset test as well. (Chris Wilson)
* Share existing global_reset_lock. (Chris Wilson)
v3:
* intel_engine_verify_workarounds can be static.
* API rename. (Chris Wilson)
* Move global reset lock out of the loop. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/intel_workarounds.c | 6 +
drivers/gpu/drm/i915/selftests/igt_reset.c| 44 ++
drivers/gpu/drm/i915/selftests/igt_reset.h| 15 ++
.../gpu/drm/i915/selftests/intel_hangcheck.c | 51 ++-
.../drm/i915/selftests/intel_workarounds.c| 142 +-
6 files changed, 212 insertions(+), 47 deletions(-)
create mode 100644 drivers/gpu/drm/i915/selftests/igt_reset.c
create mode 100644 drivers/gpu/drm/i915/selftests/igt_reset.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 50a8fa8fce64..19b5fe5016bf 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -166,6 +166,7 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
selftests/i915_random.o \
selftests/i915_selftest.o \
selftests/igt_flush_test.o \
+ selftests/igt_reset.o \
selftests/igt_spinner.o
# virtual gpu code
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 161ac61058a8..e7b0c6b98d94 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1302,5 +1302,11 @@ void intel_engine_apply_workarounds(struct
intel_engine_cs *engine)
}
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+static bool intel_engine_verify_workarounds(struct intel_engine_cs *engine,
+ const char *from)
+{
+ return wa_list_verify(engine->i915, &engine->wa_list, from);
+}
+
#include "selftests/intel_workarounds.c"
#endif
diff --git a/drivers/gpu/drm/i915/selftests/igt_reset.c
b/drivers/gpu/drm/i915/selftests/igt_reset.c
new file mode 100644
index ..208a966da8ca
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/igt_reset.c
@@ -0,0 +1,44 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#include "igt_reset.h"
+
+#include "../i915_drv.h"
+#include "../intel_ringbuffer.h"
+
+void igt_global_reset_lock(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ pr_debug("%s: current gpu_error=%08lx\n",
+__func__, i915->gpu_error.flags);
+
+ while (test_and_set_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags))
+ wait_event(i915->gpu_error.reset_queue,
+ !test_bit(I915_RESET_BACKOFF,
+&i915->gpu_error.flags));
+
+ for_each_engine(engine, i915, id) {
+ while (test_and_set_bit(I915_RESET_ENGINE + id,
+ &i915->gpu_error.flags))
+ wait_on_bit(&i915->gpu_error.flags,
+ I915_RESET_ENGINE + id,
+ TASK_UNINTERRUPTIBLE);
+ }
+}
+
+void igt_global_reset_unlock(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, i915, id)
+ clear_bit(I915_RESET_ENGINE + id, &i915->gpu_error.flags);
+
+ clear_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
+ wake_up_all(&i915->gpu_error.reset_queue);
+}
diff --git a/drivers/gpu/drm/i915/selftests/igt_reset.h
b/drivers/gpu/drm/i915/selftests/igt_reset.h
new file mode 100644
index ..5f0234d045d5
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/igt_reset.h
@@ -0,0 +1,15 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef __I915_SELFTESTS_IGT_RESET_H__
+#define __I915_SELFTESTS_IGT_RESET_H__
+
+#include "../i915_drv.h"
+
+void igt_global_reset_lock(struct drm_i915_private *i915);
+void igt_global_reset_unlock(struct drm_i915_private *i915);
+
+#endif
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index defe671130ab..3ac53496127b 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -27,6 +27,7 @@
#include "../i915_selftest.h"
#include "i915_random.h"
#include "igt_flush_test.h"
+#include "igt_reset.h"
#include "igt_wedge_me.h"
#include "mock_context.h"
@@ -348,40 +349,6 @@ static int igt_hang_sanitycheck(void *arg)
return
[Intel-gfx] [PATCH 3/7] drm/i915: Verify GT workaround state after GPU init
From: Tvrtko Ursulin
Since we now have all the GT workarounds in a table, by adding a simple
shared helper function we can now verify that their values are still
applied after some interesting events in the lifetime of the driver.
Initially we only do this after GPU initialization.
v2:
Chris Wilson:
* Simplify verification by realizing it's a simple xor and and.
* Remove verification from engine reset path.
* Return bool straight away from the verify API.
v3:
* API rename. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_gem.c | 3 +++
drivers/gpu/drm/i915/intel_workarounds.c | 34
drivers/gpu/drm/i915/intel_workarounds.h | 2 ++
4 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ee5116b62cd2..1ab6ba5771a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -53,6 +53,7 @@
#include "i915_vgpu.h"
#include "intel_drv.h"
#include "intel_uc.h"
+#include "intel_workarounds.h"
static struct drm_driver driver;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6333a7d6af5a..298f79c137eb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5334,7 +5334,10 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
I915_WRITE(MI_PREDICATE_RESULT_2, IS_HSW_GT3(dev_priv) ?
LOWER_SLICE_ENABLED : LOWER_SLICE_DISABLED);
+ /* Apply the GT workarounds... */
intel_gt_apply_workarounds(dev_priv);
+ /* ...and determine whether they are sticking. */
+ intel_gt_verify_workarounds(dev_priv, "init");
i915_gem_init_swizzling(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index d5d5ca7f8f17..161ac61058a8 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -976,6 +976,40 @@ void intel_gt_apply_workarounds(struct drm_i915_private
*dev_priv)
wa_list_apply(dev_priv, &dev_priv->gt_wa_list);
}
+static bool
+wa_verify(const struct i915_wa *wa, u32 cur, const char *name, const char
*from)
+{
+ if ((cur ^ wa->val) & wa->mask) {
+ DRM_ERROR("%s workaround lost on %s! (%x=%x/%x, expected %x,
mask=%x)\n",
+ name, from, i915_mmio_reg_offset(wa->reg), cur,
+ cur & wa->mask, wa->val, wa->mask);
+
+ return false;
+ }
+
+ return true;
+}
+
+static bool wa_list_verify(struct drm_i915_private *dev_priv,
+ const struct i915_wa_list *wal,
+ const char *from)
+{
+ struct i915_wa *wa;
+ unsigned int i;
+ bool ok = true;
+
+ for (i = 0, wa = wal->list; i < wal->count; i++, wa++)
+ ok &= wa_verify(wa, I915_READ(wa->reg), wal->name, from);
+
+ return ok;
+}
+
+bool intel_gt_verify_workarounds(struct drm_i915_private *dev_priv,
+const char *from)
+{
+ return wa_list_verify(dev_priv, &dev_priv->gt_wa_list, from);
+}
+
struct whitelist {
i915_reg_t reg[RING_MAX_NONPRIV_SLOTS];
unsigned int count;
diff --git a/drivers/gpu/drm/i915/intel_workarounds.h
b/drivers/gpu/drm/i915/intel_workarounds.h
index f960bd9ce5e9..2506db0380f1 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.h
+++ b/drivers/gpu/drm/i915/intel_workarounds.h
@@ -32,6 +32,8 @@ int intel_ctx_workarounds_emit(struct i915_request *rq);
void intel_gt_init_workarounds(struct drm_i915_private *dev_priv);
void intel_gt_apply_workarounds(struct drm_i915_private *dev_priv);
+bool intel_gt_verify_workarounds(struct drm_i915_private *dev_priv,
+const char *from);
void intel_whitelist_workarounds_apply(struct intel_engine_cs *engine);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915: Trim unused workaround list entries
From: Tvrtko Ursulin
The new workaround list allocator grows the list in chunks so will end up
with some unused space. Trim it when the initialization phase is done to
free up a tiny bit of slab.
v2:
* Simplify with kmemdup. (Chris Wilson)
v3:
* Refactor for __size removal.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v2
---
drivers/gpu/drm/i915/intel_workarounds.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index ee220a031741..0c6da9e6d370 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -53,8 +53,22 @@ static void wa_init_start(struct i915_wa_list *wal, const
char *name)
wal->name = name;
}
+#define WA_LIST_CHUNK (1 << 4)
+
static void wa_init_finish(struct i915_wa_list *wal)
{
+ /* Trim unused entries. */
+ if (!IS_ALIGNED(wal->count, WA_LIST_CHUNK)) {
+ struct i915_wa *list = kmemdup(wal->list,
+ wal->count * sizeof(*list),
+ GFP_KERNEL);
+
+ if (list) {
+ kfree(wal->list);
+ wal->list = list;
+ }
+ }
+
if (wal->count)
DRM_DEBUG_DRIVER("Initialized %u %s workarounds\n",
wal->wa_count, wal->name);
@@ -64,7 +78,7 @@ static void _wa_add(struct i915_wa_list *wal, const struct
i915_wa *wa)
{
unsigned int addr = i915_mmio_reg_offset(wa->reg);
unsigned int start = 0, end = wal->count;
- const unsigned int grow = 1 << 4;
+ const unsigned int grow = WA_LIST_CHUNK;
struct i915_wa *wa_;
GEM_BUG_ON(!is_power_of_2(grow));
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915: Record GT workarounds in a list
From: Tvrtko Ursulin
To enable later verification of GT workaround state at various stages of
driver lifetime, we record the list of applicable ones per platforms to a
list, from which they are also applied.
The added data structure is a simple array of register, mask and value
items, which is allocated on demand as workarounds are added to the list.
This is a temporary implementation which later in the series gets fused
with the existing per context workaround list handling. It is separated at
this stage since the following patch fixes a bug which needs to be as easy
to backport as possible.
Also, since in the following patch we will be adding a new class of
workarounds (per engine) which can be applied from interrupt context, we
straight away make the provision for safe read-modify-write cycle.
v2:
* Change dev_priv to i915 along the init path. (Chris Wilson)
* API rename. (Chris Wilson)
v3:
* Remove explicit list size tracking in favour of growing the allocation
in power of two chunks. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v2
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/intel_workarounds.c | 491 +++
drivers/gpu/drm/i915/intel_workarounds.h | 23 +-
5 files changed, 353 insertions(+), 168 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e39016713464..ee5116b62cd2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1453,6 +1453,7 @@ static int i915_driver_init_hw(struct drm_i915_private
*dev_priv)
intel_uncore_sanitize(dev_priv);
+ intel_gt_init_workarounds(dev_priv);
i915_gem_load_init_fences(dev_priv);
/* On the 945G/GM, the chipset reports the MSI capability on the
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 43ac6873a2bb..9ddbcc1f3554 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -69,6 +69,7 @@
#include "intel_ringbuffer.h"
#include "intel_uncore.h"
#include "intel_wopcm.h"
+#include "intel_workarounds.h"
#include "intel_uc.h"
#include "i915_gem.h"
@@ -1652,6 +1653,7 @@ struct drm_i915_private {
int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
struct i915_workarounds workarounds;
+ struct i915_wa_list gt_wa_list;
struct i915_frontbuffer_tracking fb_tracking;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c55b1f75c980..6333a7d6af5a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5334,7 +5334,7 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
I915_WRITE(MI_PREDICATE_RESULT_2, IS_HSW_GT3(dev_priv) ?
LOWER_SLICE_ENABLED : LOWER_SLICE_DISABLED);
- intel_gt_workarounds_apply(dev_priv);
+ intel_gt_apply_workarounds(dev_priv);
i915_gem_init_swizzling(dev_priv);
@@ -5706,6 +5706,8 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
i915_gem_contexts_fini(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
+ intel_wa_list_free(&dev_priv->gt_wa_list);
+
intel_cleanup_gt_powersave(dev_priv);
intel_uc_fini_misc(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index e5cd6c6c66c3..f05f13547034 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -48,6 +48,18 @@
* - Public functions to init or apply the given workaround type.
*/
+static void wa_init_start(struct i915_wa_list *wal, const char *name)
+{
+ wal->name = name;
+}
+
+static void wa_init_finish(struct i915_wa_list *wal)
+{
+ if (wal->count)
+ DRM_DEBUG_DRIVER("Initialized %u %s workarounds\n",
+wal->count, wal->name);
+}
+
static void wa_add(struct drm_i915_private *i915,
i915_reg_t reg, const u32 mask, const u32 val)
{
@@ -575,160 +587,240 @@ int intel_ctx_workarounds_emit(struct i915_request *rq)
return 0;
}
-static void bdw_gt_workarounds_apply(struct drm_i915_private *dev_priv)
+static void
+wal_add(struct i915_wa_list *wal, const struct i915_wa *wa)
+{
+ const unsigned int grow = 1 << 4;
+
+ GEM_BUG_ON(!is_power_of_2(grow));
+
+ if (IS_ALIGNED(wal->count, grow)) { /* Either uninitialized or full. */
+ struct i915_wa *list;
+
+ list = kcalloc(ALIGN(wal->count + 1, grow), sizeof(*wa),
+ GFP_KERNEL);
+ if (!list) {
+ DRM_ERROR("No space for workaround init!\n");
+ return;
+ }
+
+ if (wal->list)
+ memcpy(list, wal->list, sizeof(*wa) * wal
Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane
On 12/03/2018 12:23 PM, Andrzej Hajda wrote: > On 30.11.2018 15:48, Hans Verkuil wrote: >> On 11/30/18 15:29, Ville Syrjälä wrote: >>> On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote: Hi Ville, As Christoph cannot respond till middle next week I can try to respond in his absence, as I am familiar with the subject. On 30.11.2018 14:25, Ville Syrjälä wrote: > On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote: >> Hi, >> >> I am looking for a way to export the color encoding and range selection >> to user space. I came across those properties and am wondering, why >> they are meant only for non RGB color encodings. Would it be okay, to >> modify them and use with RGB formats as well? > What you trying to do? Input limited range RGB data and expand to full > range? For example. But there are two more general questions, which surprisingly we have not found answer for. 1. What color encoding and range drm should expect on its input RGB buffers by default? >>> RGB is just RGB. There is no encoding. > > > OK, Now I see I have confused encoding with colorspace, Hans thanks for > the documentation. > > As I understand drm by default should expect sRGB colorspace, also for > Y'CbCr buffers, and currently there are no standard ways to specify > buffer colorspace. > > Looking at current users of drm_plane_create_color_properties for Y'CbCr > buffers it seems default range should be LIMITED. Right. There is support for YCbCr quantization range signaling in HDMI, but that is for all intents and purposes broken in the standard. Don't use it, just output limited range YCbCr. On the other hand, RGB Quantization range signaling should *always* be used if the EDID signals support for it. I believe that's what drm does today already (this certainly works for i915). > > But default encoding is different: mali, armada, nouveau use > DRM_COLOR_YCBCR_BT601, i915 uses DRM_COLOR_YCBCR_BT709 - shouldn't this > be somehow standardized? According to CEA-861 bt.601 should be used for SDTV (PAL/NTSC), 709 for everything else. So this is resolution dependent. Although strictly speaking it is only userspace that knows the right encoding, since it depends on the source material. You can have SDTV video encoded with 709, or HDTV encoded with 601. But in the absence of any information, the default rule above is what should be used. > > > What I still do not understand is colorspace conversion(not encoding!) - > between pipeline input (framebuffers) and output (HDMI connector for > example): > > 1. Since sRGB, SMPTE170M/BT.601, BT.709 colorspaces are 'almost > identical in coverage' (according to wikipedia[1]) no colorspace > conversion is performed at all. That's correct. There is a slight difference between SMPTE170M and sRGB/Rec709, but basically invisible to the naked eye unless you see it side-by-side, and even then it's is hard to detect. However, sRGB uses a different transfer function compared to SMPTE170M and Rec709, and that difference *is* quite visible. Not all hardware (certainly not video capture hardware) is capable of converting between different transfer functions, though. I gather that this is more common for HDMI output hardware. > > 2. It is performed somewhere by HW, just my IP documentation is not > clear about it. > > > Another thing which still bothers me is RGB range in case of HDMI - > CEA-861 expects than on CEA modes limited RGB range should be sent, but > the pipeline on the particular hardware I have do not perform any > conversion of input buffers. So only limited range RGB buffers are > displayed correctly. In such case property describing plane with limited > RGB would be useful. Are you sure? Usually the same block that does YCbCr encoding conversion (601 to 709 or vice versa), also deals with limited/full range conversion. It is typically a 3x3 matrix + a vector adding the needed offsets. It is dead cheap to implement in hardware, so it would be very unusual if there is no support for this. > > > [1]: https://en.wikipedia.org/wiki/Rec._709#Primary_chromaticities > > >> It's assumed to be full range >>> because no one really uses anything else. >> For simple desktop usage that's true. When dealing with video inputs, >> this becomes much more complicated. > > > As I said earlier there are cases where output stream should be limited > RGB, and no conversion in pipeline - thus framebuffers also should be > 'limited RGB'. Whether RGB output should be full or limited range depends entirely on the resolution and the EDID. I have tested i915 w.r.t. RGB quantization range, and that does it right. The reality with RGB Quantization Range handling is that 50% of all devices do this wrong. So if the EDID signals selectable quantization range support, then use it and signal full range RGB. If it is not available, then the i915 implementation is one I can point to
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Record GT workarounds in a list
Quoting Tvrtko Ursulin (2018-12-03 11:46:11)
> From: Tvrtko Ursulin
>
> To enable later verification of GT workaround state at various stages of
> driver lifetime, we record the list of applicable ones per platforms to a
> list, from which they are also applied.
>
> The added data structure is a simple array of register, mask and value
> items, which is allocated on demand as workarounds are added to the list.
>
> This is a temporary implementation which later in the series gets fused
> with the existing per context workaround list handling. It is separated at
> this stage since the following patch fixes a bug which needs to be as easy
> to backport as possible.
>
> Also, since in the following patch we will be adding a new class of
> workarounds (per engine) which can be applied from interrupt context, we
> straight away make the provision for safe read-modify-write cycle.
>
> v2:
> * Change dev_priv to i915 along the init path. (Chris Wilson)
> * API rename. (Chris Wilson)
>
> v3:
> * Remove explicit list size tracking in favour of growing the allocation
>in power of two chunks. (Chris Wilson)
>
> Signed-off-by: Tvrtko Ursulin
> Reviewed-by: Chris Wilson # v2
> ---
> drivers/gpu/drm/i915/i915_drv.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_gem.c | 4 +-
> drivers/gpu/drm/i915/intel_workarounds.c | 491 +++
> drivers/gpu/drm/i915/intel_workarounds.h | 23 +-
> 5 files changed, 353 insertions(+), 168 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e39016713464..ee5116b62cd2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1453,6 +1453,7 @@ static int i915_driver_init_hw(struct drm_i915_private
> *dev_priv)
>
> intel_uncore_sanitize(dev_priv);
>
> + intel_gt_init_workarounds(dev_priv);
> i915_gem_load_init_fences(dev_priv);
>
> /* On the 945G/GM, the chipset reports the MSI capability on the
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 43ac6873a2bb..9ddbcc1f3554 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -69,6 +69,7 @@
> #include "intel_ringbuffer.h"
> #include "intel_uncore.h"
> #include "intel_wopcm.h"
> +#include "intel_workarounds.h"
> #include "intel_uc.h"
>
> #include "i915_gem.h"
> @@ -1652,6 +1653,7 @@ struct drm_i915_private {
> int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
>
> struct i915_workarounds workarounds;
> + struct i915_wa_list gt_wa_list;
>
> struct i915_frontbuffer_tracking fb_tracking;
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c55b1f75c980..6333a7d6af5a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5334,7 +5334,7 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
> I915_WRITE(MI_PREDICATE_RESULT_2, IS_HSW_GT3(dev_priv) ?
>LOWER_SLICE_ENABLED : LOWER_SLICE_DISABLED);
>
> - intel_gt_workarounds_apply(dev_priv);
> + intel_gt_apply_workarounds(dev_priv);
>
> i915_gem_init_swizzling(dev_priv);
>
> @@ -5706,6 +5706,8 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
> i915_gem_contexts_fini(dev_priv);
> mutex_unlock(&dev_priv->drm.struct_mutex);
>
> + intel_wa_list_free(&dev_priv->gt_wa_list);
> +
> intel_cleanup_gt_powersave(dev_priv);
>
> intel_uc_fini_misc(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index e5cd6c6c66c3..f05f13547034 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
> @@ -48,6 +48,18 @@
> * - Public functions to init or apply the given workaround type.
> */
>
> +static void wa_init_start(struct i915_wa_list *wal, const char *name)
> +{
> + wal->name = name;
> +}
> +
> +static void wa_init_finish(struct i915_wa_list *wal)
> +{
> + if (wal->count)
> + DRM_DEBUG_DRIVER("Initialized %u %s workarounds\n",
> +wal->count, wal->name);
Does this become if (!wal->count) return; later?
> +}
> +
> static void wa_add(struct drm_i915_private *i915,
>i915_reg_t reg, const u32 mask, const u32 val)
> {
> @@ -575,160 +587,240 @@ int intel_ctx_workarounds_emit(struct i915_request
> *rq)
> return 0;
> }
>
> -static void bdw_gt_workarounds_apply(struct drm_i915_private *dev_priv)
> +static void
> +wal_add(struct i915_wa_list *wal, const struct i915_wa *wa)
> +{
> + const unsigned int grow = 1 << 4;
> +
> + GEM_BUG_ON(!is_power_of_2(grow));
> +
> + if (IS_ALIGNED(wal->count, grow)) { /* Either uninitialized or full.
> */
Neat.
> + struct i915_wa *list
Re: [Intel-gfx] [PATCH 4/7] drm/i915/selftests: Add tests for GT and engine workaround verification
Quoting Tvrtko Ursulin (2018-12-03 11:46:14)
> +static int
> +live_engine_reset_gt_engine_workarounds(void *arg)
> +{
...
> + ok = verify_gt_engine_wa(i915, "after idle reset");
> + if (!ok) {
> + ret = -ESRCH;
> + goto err;
> + }
> +
> + ret = igt_spinner_init(&spin, i915);
> + if (ret)
> + goto err;
> +
> + intel_runtime_pm_get(i915);
> +
> + rq = igt_spinner_create_request(&spin, ctx, engine, MI_NOOP);
> + if (IS_ERR(rq)) {
> + ret = PTR_ERR(rq);
> + igt_spinner_fini(&spin);
Missing rpm_put
> + goto err;
> + }
> +
> + i915_request_add(rq);
> +
> + if (!igt_wait_for_spinner(&spin, rq)) {
> + pr_err("Spinner failed to start\n");
> + igt_spinner_fini(&spin);
> + ret = -ETIMEDOUT;
Missing rpm_put
I need to convince people to take the wakeref tracking to make these
leaks more obvious :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: push pll to port mapping/unmapping to ddi encoder hooks
On Thu, Nov 29, 2018 at 01:57:15PM +0200, Jani Nikula wrote:
> Unclutter the haswell_crtc_enable() and haswell_crtc_disable() functions
> a bit by moving the pll to port mapping and unmapping functions to the
> ddi encoder hooks. This allows removal of a bunch of boilerplate code
> from the functions.
>
> Additionally, the ICL DSI encoder needs to do the clock gating and
> ungating slightly differently, and this allows its own handling in a
> clean fashion.
>
> Cc: Madhav Chauhan
> Cc: Paulo Zanoni
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 84
> +++-
> drivers/gpu/drm/i915/intel_display.c | 6 ---
> drivers/gpu/drm/i915/intel_drv.h | 6 ---
> 3 files changed, 34 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ad11540ac436..7bad6c857b81 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2785,69 +2785,45 @@ uint32_t icl_dpclka_cfgcr0_clk_off(struct
> drm_i915_private *dev_priv,
> return 0;
> }
>
> -void icl_map_plls_to_ports(struct drm_crtc *crtc,
> -struct intel_crtc_state *crtc_state,
> -struct drm_atomic_state *old_state)
> +static void icl_map_plls_to_ports(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state)
> {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct intel_shared_dpll *pll = crtc_state->shared_dpll;
> - struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> - struct drm_connector_state *conn_state;
> - struct drm_connector *conn;
> - int i;
> -
> - for_each_new_connector_in_state(old_state, conn, conn_state, i) {
> - struct intel_encoder *encoder =
> - to_intel_encoder(conn_state->best_encoder);
> - enum port port;
> - uint32_t val;
> -
> - if (conn_state->crtc != crtc)
> - continue;
> -
> - port = encoder->port;
> - mutex_lock(&dev_priv->dpll_lock);
> + enum port port = encoder->port;
> + u32 val;
>
> - val = I915_READ(DPCLKA_CFGCR0_ICL);
> - WARN_ON((val & icl_dpclka_cfgcr0_clk_off(dev_priv, port)) == 0);
> + mutex_lock(&dev_priv->dpll_lock);
>
> - if (intel_port_is_combophy(dev_priv, port)) {
> - val &= ~DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
> - val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, port);
> - I915_WRITE(DPCLKA_CFGCR0_ICL, val);
> - POSTING_READ(DPCLKA_CFGCR0_ICL);
> - }
> + val = I915_READ(DPCLKA_CFGCR0_ICL);
> + WARN_ON((val & icl_dpclka_cfgcr0_clk_off(dev_priv, port)) == 0);
>
> - val &= ~icl_dpclka_cfgcr0_clk_off(dev_priv, port);
> + if (intel_port_is_combophy(dev_priv, port)) {
> + val &= ~DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
> + val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, port);
> I915_WRITE(DPCLKA_CFGCR0_ICL, val);
> -
> - mutex_unlock(&dev_priv->dpll_lock);
> + POSTING_READ(DPCLKA_CFGCR0_ICL);
> }
> +
> + val &= ~icl_dpclka_cfgcr0_clk_off(dev_priv, port);
> + I915_WRITE(DPCLKA_CFGCR0_ICL, val);
> +
> + mutex_unlock(&dev_priv->dpll_lock);
> }
>
> -void icl_unmap_plls_to_ports(struct drm_crtc *crtc,
> - struct intel_crtc_state *crtc_state,
> - struct drm_atomic_state *old_state)
> +static void icl_unmap_plls_to_ports(struct intel_encoder *encoder)
> {
> - struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> - struct drm_connector_state *old_conn_state;
> - struct drm_connector *conn;
> - int i;
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum port port = encoder->port;
> + u32 val;
>
> - for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
> - struct intel_encoder *encoder =
> - to_intel_encoder(old_conn_state->best_encoder);
> - enum port port;
> + mutex_lock(&dev_priv->dpll_lock);
>
> - if (old_conn_state->crtc != crtc)
> - continue;
> + val = I915_READ(DPCLKA_CFGCR0_ICL);
> + val |= icl_dpclka_cfgcr0_clk_off(dev_priv, port);
> + I915_WRITE(DPCLKA_CFGCR0_ICL, val);
>
> - port = encoder->port;
> - mutex_lock(&dev_priv->dpll_lock);
> - I915_WRITE(DPCLKA_CFGCR0_ICL,
> -I915_READ(DPCLKA_CFGCR0_ICL) |
> -icl_dpclka_cfgcr0_clk_off(dev_priv, port));
> - mutex_unlock(&dev_priv->dpll_lock);
> - }
> + mutex_unlock(&dev_priv->dpll_lock);
> }
>
> void icl_sanitize_enco
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/8] drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate
== Series Details ==
Series: series starting with [1/8] drm/i915/breadcrumbs: Reduce
missed-breadcrumb false positive rate
URL : https://patchwork.freedesktop.org/series/53396/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
766ea4f65bdf drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate
-:28: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'tsk' - possible side-effects?
#28: FILE: drivers/gpu/drm/i915/intel_breadcrumbs.c:30:
+#define task_asleep(tsk) ((tsk)->state & TASK_NORMAL && !(tsk)->on_rq)
total: 0 errors, 0 warnings, 1 checks, 12 lines checked
fa8bf690be7f drm/i915: Complete the fences as they are cancelled due to wedging
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#13:
<1>[ 354.473346] BUG: unable to handle kernel NULL pointer dereference at
0250
total: 0 errors, 1 warnings, 0 checks, 135 lines checked
1053059305d7 drm/i915/ringbuffer: Clear semaphore sync registers on ring init
977ecf89aa55 drm/i915: Allocate a common scratch page
3e6b3d9e45c9 drm/i915: Flush GPU relocs harder for gen3
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 7fa28e146994 ("drm/i915: Write
GPU relocs harder with gen3")'
#14:
References: 7fa28e146994 ("drm/i915: Write GPU relocs harder with gen3")
total: 1 errors, 0 warnings, 0 checks, 50 lines checked
c43dcef30f43 drm/i915/selftests: Terminate hangcheck sanitycheck forcibly
6ab551e4569e drm/i915/selftests: Reorder request allocation vs vma pinning
258c6cca41c7 drm/i915: Pipeline PDP updates for Braswell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Fuse per-context workaround handling with the common framework
Quoting Tvrtko Ursulin (2018-12-03 11:46:16)
> From: Tvrtko Ursulin
>
> Convert the per context workaround handling code to run against the newly
> introduced common workaround framework and fuse the two to use the
> existing smarter list add helper, the one which does the sorted insert and
> merges registers where possible.
>
> This completes migration of all four classes of workarounds onto the
> common framework.
>
> Existing macros are kept untouched for smaller code churn.
>
> v2:
> * Rename to list name ctx_wa_list and move from dev_priv to engine.
>
> v3:
> * API rename and parameters tweaking. (Chris Wilson)
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 12 +-
> drivers/gpu/drm/i915/i915_drv.h | 15 -
> drivers/gpu/drm/i915/i915_gem_context.c | 6 +-
> drivers/gpu/drm/i915/intel_engine_cs.c | 1 +
> drivers/gpu/drm/i915/intel_lrc.c | 2 +-
> drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
> drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
> drivers/gpu/drm/i915/intel_workarounds.c | 334 +++
> drivers/gpu/drm/i915/intel_workarounds.h | 5 +-
> 9 files changed, 168 insertions(+), 210 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 129b9a6f8309..38dcee1ca062 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3375,13 +3375,15 @@ static int i915_shared_dplls_info(struct seq_file *m,
> void *unused)
>
> static int i915_wa_registers(struct seq_file *m, void *unused)
> {
> - struct i915_workarounds *wa = &node_to_i915(m->private)->workarounds;
> - int i;
> + struct drm_i915_private *i915 = node_to_i915(m->private);
> + const struct i915_wa_list *wal = &i915->engine[RCS]->ctx_wa_list;
> + struct i915_wa *wa;
> + unsigned int i;
You keep telling me to be defensive around the existence of RCS :)
>
> - seq_printf(m, "Workarounds applied: %d\n", wa->count);
> - for (i = 0; i < wa->count; ++i)
> + seq_printf(m, "Workarounds applied: %u\n", wal->count);
> + for (i = 0, wa = wal->list; i < wal->count; i++, wa++)
> seq_printf(m, "0x%X: 0x%08X, mask: 0x%08X\n",
> - wa->reg[i].addr, wa->reg[i].value,
> wa->reg[i].mask);
> + i915_mmio_reg_offset(wa->reg), wa->val, wa->mask);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
> b/drivers/gpu/drm/i915/intel_workarounds.c
> index 0350513bf7f7..ee220a031741 100644
> --- a/drivers/gpu/drm/i915/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/intel_workarounds.c
Lgtm,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/8] drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate
== Series Details == Series: series starting with [1/8] drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate URL : https://patchwork.freedesktop.org/series/53396/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate Okay! Commit: drm/i915: Complete the fences as they are cancelled due to wedging Okay! Commit: drm/i915/ringbuffer: Clear semaphore sync registers on ring init Okay! Commit: drm/i915: Allocate a common scratch page -drivers/gpu/drm/i915/selftests/../i915_drv.h:3571:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3573:16: warning: expression using sizeof(void) Commit: drm/i915: Flush GPU relocs harder for gen3 Okay! Commit: drm/i915/selftests: Terminate hangcheck sanitycheck forcibly Okay! Commit: drm/i915/selftests: Reorder request allocation vs vma pinning Okay! Commit: drm/i915: Pipeline PDP updates for Braswell Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Trim unused workaround list entries
Quoting Tvrtko Ursulin (2018-12-03 11:46:17) > From: Tvrtko Ursulin > > The new workaround list allocator grows the list in chunks so will end up > with some unused space. Trim it when the initialization phase is done to > free up a tiny bit of slab. > > v2: > * Simplify with kmemdup. (Chris Wilson) > > v3: > * Refactor for __size removal. > > Signed-off-by: Tvrtko Ursulin > Reviewed-by: Chris Wilson # v2 I'd jiggle the if (!wal->count) return around, r-b will remain. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 01/11] drm/i915: Disable PSR in Apple panels
On Thu, 29 Nov 2018, José Roberto de Souza wrote:
> i915 yet don't support PSR in Apple panels, so lets keep it disabled
> while we work on that.
>
> v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to
> DP_DPCD_QUIRK_NO_PSR (Ville)
>
> Fixes: 598c6cfe0690 (drm/i915/psr: Enable PSR1 on gen-9+ HW)
> Cc: Ville Syrjälä
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/drm_dp_helper.c | 2 ++
> drivers/gpu/drm/i915/intel_psr.c | 6 ++
> include/drm/drm_dp_helper.h | 1 +
> 3 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 2d6c491a0542..b00fd5ced0a0 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1273,6 +1273,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
> { OUI(0x00, 0x22, 0xb9), DEVICE_ID_ANY, true,
> BIT(DP_DPCD_QUIRK_CONSTANT_N) },
> /* LG LP140WF6-SPM1 eDP panel */
> { OUI(0x00, 0x22, 0xb9), DEVICE_ID('s', 'i', 'v', 'a', 'r', 'T'),
> false, BIT(DP_DPCD_QUIRK_CONSTANT_N) },
> + /* Apple panels needs some additional handling to support PSR */
nitpick "panels needs"
> + { OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false,
> BIT(DP_DPCD_QUIRK_NO_PSR) }
> };
>
> #undef OUI
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2084784f320d..40ca6cc43cc4 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -278,6 +278,12 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> DRM_DEBUG_KMS("Panel lacks power state control, PSR cannot be
> enabled\n");
> return;
> }
> +
> + if (drm_dp_has_quirk(&intel_dp->desc, DP_DPCD_QUIRK_NO_PSR)) {
> + DRM_DEBUG_KMS("PSR support not currently available for this
> panel\n");
> + return;
> + }
> +
> dev_priv->psr.sink_support = true;
> dev_priv->psr.sink_sync_latency =
> intel_dp_get_sink_sync_latency(intel_dp);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 5736c942c85b..047314ce25d6 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1365,6 +1365,7 @@ enum drm_dp_quirk {
>* to 16 bits. So will give a constant value (0x8000) for compatability.
>*/
> DP_DPCD_QUIRK_CONSTANT_N,
Please add a proper comment here, similar to above
DP_DPCD_QUIRK_CONSTANT_N.
BR,
Jani.
> + DP_DPCD_QUIRK_NO_PSR,
> };
>
> /**
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix link compute m_n calc for DSC
On Fri, Nov 30, 2018 at 05:04:12PM -0800, Manasi Navare wrote:
> Fix the intel_link_compute_m_n in case of display stream
> compression. This patch passes the compressed_bpp to
> intel_link_compute_m_n if compression is enabled.
>
> Fixes: a4a15c80 ("drm/i915/dp: Compute DSC pipe config in atomic check")
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 38a6e82153fd..a6907a1761ab 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2173,7 +2173,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> &pipe_config->dp_m_n,
> constant_n);
> else
> -
> intel_link_compute_m_n(pipe_config->dsc_params.compression_enable,
> + intel_link_compute_m_n(pipe_config->dsc_params.compressed_bpp,
> pipe_config->lane_count,
> adjusted_mode->crtc_clock,
> pipe_config->port_clock,
> --
> 2.19.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915/ringbuffer: Clear semaphore sync registers on ring init
Chris Wilson writes:
> Ensure that the sync registers are cleared every time we restart the
> ring to avoid stale values from creeping in from random neutrinos.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 992889f9e0ff..81b10d85b738 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -529,6 +529,13 @@ static int init_ring_common(struct intel_engine_cs
> *engine)
>
> intel_engine_reset_breadcrumbs(engine);
>
> + if (HAS_LEGACY_SEMAPHORES(engine->i915)) {
> + I915_WRITE(RING_SYNC_0(engine->mmio_base), 0);
> + I915_WRITE(RING_SYNC_1(engine->mmio_base), 0);
> + if (HAS_VEBOX(dev_priv))
Minor nitpick: mixed i915 and dev_priv usage.
Reviewed-by: Mika Kuoppala
> + I915_WRITE(RING_SYNC_2(engine->mmio_base), 0);
> + }
> +
> /* Enforce ordering by reading HEAD register back */
> I915_READ_HEAD(engine);
>
> --
> 2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915/selftests: Terminate hangcheck sanitycheck forcibly
Chris Wilson writes:
> If all else fails and we are stuck eternally waiting for the undying
> request, abandon all hope.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> index defe671130ab..a48fbe2557ea 100644
> --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> @@ -308,6 +308,7 @@ static int igt_hang_sanitycheck(void *arg)
> goto unlock;
>
> for_each_engine(engine, i915, id) {
> + struct igt_wedge_me w;
> long timeout;
>
> if (!intel_engine_can_store_dword(engine))
> @@ -328,9 +329,14 @@ static int igt_hang_sanitycheck(void *arg)
>
> i915_request_add(rq);
>
> - timeout = i915_request_wait(rq,
> - I915_WAIT_LOCKED,
> - MAX_SCHEDULE_TIMEOUT);
> + timeout = 0;
> + igt_wedge_on_timeout(&w, i915, HZ / 10 /* 100ms timeout*/)
100ms? We are emitting a hanging batch here, so there is something
I am missing here.
-Mika
> + timeout = i915_request_wait(rq,
> + I915_WAIT_LOCKED,
> + MAX_SCHEDULE_TIMEOUT);
> + if (i915_terminally_wedged(&i915->gpu_error))
> + timeout = -EIO;
> +
> i915_request_put(rq);
>
> if (timeout < 0) {
> --
> 2.20.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915/ringbuffer: Clear semaphore sync registers on ring init
Quoting Mika Kuoppala (2018-12-03 12:05:25)
> Chris Wilson writes:
>
> > Ensure that the sync registers are cleared every time we restart the
> > ring to avoid stale values from creeping in from random neutrinos.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 992889f9e0ff..81b10d85b738 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -529,6 +529,13 @@ static int init_ring_common(struct intel_engine_cs
> > *engine)
> >
> > intel_engine_reset_breadcrumbs(engine);
> >
> > + if (HAS_LEGACY_SEMAPHORES(engine->i915)) {
> > + I915_WRITE(RING_SYNC_0(engine->mmio_base), 0);
> > + I915_WRITE(RING_SYNC_1(engine->mmio_base), 0);
> > + if (HAS_VEBOX(dev_priv))
>
> Minor nitpick: mixed i915 and dev_priv usage.
I don't think you are ready yet for i915_write32(i915, reg, value). :-p
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/8] drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate
== Series Details ==
Series: series starting with [1/8] drm/i915/breadcrumbs: Reduce
missed-breadcrumb false positive rate
URL : https://patchwork.freedesktop.org/series/53396/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5239 -> Patchwork_10996
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53396/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_10996 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-ivb-3520m: PASS -> FAIL [fdo#108880]
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-skl-6700k2: PASS -> INCOMPLETE [fdo#104108] / [fdo#105524] /
[k.org#199541]
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#108622] -> PASS
Warnings
* igt@i915_selftest@live_contexts:
- {fi-icl-u3}:INCOMPLETE [fdo#108315] -> DMESG-FAIL [fdo#108569]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#105524]: https://bugs.freedesktop.org/show_bug.cgi?id=105524
[fdo#108315]: https://bugs.freedesktop.org/show_bug.cgi?id=108315
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108880]: https://bugs.freedesktop.org/show_bug.cgi?id=108880
[k.org#199541]: https://bugzilla.kernel.org/show_bug.cgi?id=199541
Participating hosts (47 -> 42)
--
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5239 -> Patchwork_10996
CI_DRM_5239: 6b82ae50cbf9b70fb3884937a221f69261c4c41c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4736: 285ebfb3b7adc56586031afa5150c4e5ad40c229 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10996: 258c6cca41c715c7b29ff8f320a5d578774724a1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
258c6cca41c7 drm/i915: Pipeline PDP updates for Braswell
6ab551e4569e drm/i915/selftests: Reorder request allocation vs vma pinning
c43dcef30f43 drm/i915/selftests: Terminate hangcheck sanitycheck forcibly
3e6b3d9e45c9 drm/i915: Flush GPU relocs harder for gen3
977ecf89aa55 drm/i915: Allocate a common scratch page
1053059305d7 drm/i915/ringbuffer: Clear semaphore sync registers on ring init
fa8bf690be7f drm/i915: Complete the fences as they are cancelled due to wedging
766ea4f65bdf drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10996/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915/selftests: Terminate hangcheck sanitycheck forcibly
Quoting Mika Kuoppala (2018-12-03 12:09:39)
> Chris Wilson writes:
>
> > If all else fails and we are stuck eternally waiting for the undying
> > request, abandon all hope.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 12 +---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > index defe671130ab..a48fbe2557ea 100644
> > --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > @@ -308,6 +308,7 @@ static int igt_hang_sanitycheck(void *arg)
> > goto unlock;
> >
> > for_each_engine(engine, i915, id) {
> > + struct igt_wedge_me w;
> > long timeout;
> >
> > if (!intel_engine_can_store_dword(engine))
> > @@ -328,9 +329,14 @@ static int igt_hang_sanitycheck(void *arg)
> >
> > i915_request_add(rq);
> >
> > - timeout = i915_request_wait(rq,
> > - I915_WAIT_LOCKED,
> > - MAX_SCHEDULE_TIMEOUT);
> > + timeout = 0;
> > + igt_wedge_on_timeout(&w, i915, HZ / 10 /* 100ms timeout*/)
>
> 100ms? We are emitting a hanging batch here, so there is something
> I am missing here.
It's not a hanging batch, anymore due to the terminator applied a couple
of lines above.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: combo port vswing programming changes per BSPEC
On Fri, Nov 30, 2018 at 02:58:01PM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> In August 2018 the BSPEC changed the ICL port programming sequence to
> closely resemble earlier gen programming sequence.
>
> BSpec: 21257
> Cc: Ville Syrjälä
> Cc: Imre Deak
> Cc: Rodrigo Vivi
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4 +
> drivers/gpu/drm/i915/intel_ddi.c | 223
> +--
> drivers/gpu/drm/i915/intel_display.c | 3 -
> 3 files changed, 86 insertions(+), 144 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d3ef979..e632e99 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1866,6 +1866,10 @@ enum i915_power_well_id {
>
> #define CNL_PORT_TX_DW7_GRP(port)_MMIO(_CNL_PORT_TX_DW_GRP((port), 7))
> #define CNL_PORT_TX_DW7_LN0(port)_MMIO(_CNL_PORT_TX_DW_LN0((port), 7))
> +#define ICL_PORT_TX_DW7_AUX(port)_MMIO(_ICL_PORT_TX_DW_AUX(7, port))
> +#define ICL_PORT_TX_DW7_GRP(port)_MMIO(_ICL_PORT_TX_DW_GRP(7, port))
> +#define ICL_PORT_TX_DW7_LN0(port)_MMIO(_ICL_PORT_TX_DW_LN(7, 0, port))
> +#define ICL_PORT_TX_DW7_LN(port, ln) _MMIO(_ICL_PORT_TX_DW_LN(7, ln, port))
> #define N_SCALAR(x)((x) << 24)
> #define N_SCALAR_MASK (0x7F << 24)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 61d7145..219464e9 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -493,103 +493,63 @@ struct cnl_ddi_buf_trans {
> { 0x2, 0x7F, 0x3F, 0x00, 0x00 },/* 400 400 0.0 */
> };
>
> -struct icl_combo_phy_ddi_buf_trans {
> - u32 dw2_swing_select;
> - u32 dw2_swing_scalar;
> - u32 dw4_scaling;
> -};
> -
> -/* Voltage Swing Programming for VccIO 0.85V for DP */
> -static const struct icl_combo_phy_ddi_buf_trans
> icl_combo_phy_ddi_translations_dp_hdmi_0_85V[] = {
> - /* Voltage mV db*/
> - { 0x2, 0x98, 0x0018 }, /* 400 0.0 */
> - { 0x2, 0x98, 0x3015 }, /* 400 3.5 */
> - { 0x2, 0x98, 0x6012 }, /* 400 6.0 */
> - { 0x2, 0x98, 0x900F }, /* 400 9.5 */
> - { 0xB, 0x70, 0x0018 }, /* 600 0.0 */
> - { 0xB, 0x70, 0x3015 }, /* 600 3.5 */
> - { 0xB, 0x70, 0x6012 }, /* 600 6.0 */
> - { 0x5, 0x00, 0x0018 }, /* 800 0.0 */
> - { 0x5, 0x00, 0x3015 }, /* 800 3.5 */
> - { 0x6, 0x98, 0x0018 }, /* 12000.0 */
> -};
> -
> -/* FIXME - After table is updated in Bspec */
> -/* Voltage Swing Programming for VccIO 0.85V for eDP */
> -static const struct icl_combo_phy_ddi_buf_trans
> icl_combo_phy_ddi_translations_edp_0_85V[] = {
> - /* Voltage mV db*/
> - { 0x0, 0x00, 0x00 },/* 200 0.0 */
> - { 0x0, 0x00, 0x00 },/* 200 1.5 */
> - { 0x0, 0x00, 0x00 },/* 200 4.0 */
> - { 0x0, 0x00, 0x00 },/* 200 6.0 */
> - { 0x0, 0x00, 0x00 },/* 250 0.0 */
> - { 0x0, 0x00, 0x00 },/* 250 1.5 */
> - { 0x0, 0x00, 0x00 },/* 250 4.0 */
> - { 0x0, 0x00, 0x00 },/* 300 0.0 */
> - { 0x0, 0x00, 0x00 },/* 300 1.5 */
> - { 0x0, 0x00, 0x00 },/* 350 0.0 */
> +/* icl_combo_phy_ddi_translations */
> +static const struct cnl_ddi_buf_trans icl_combo_phy_ddi_translations_dp[] = {
> + /* NT mV Trans mV db*/
> + { 0xA, 0x35, 0x3F, 0x00, 0x00 },/* 350 350 0.0 */
> + { 0xA, 0x4F, 0x37, 0x00, 0x08 },/* 350 500 3.1 */
> + { 0xC, 0x71, 0x2F, 0x00, 0x10 },/* 350 700 6.0 */
> + { 0x6, 0x7F, 0x2B, 0x00, 0x14 },/* 350 900 8.2 */
> + { 0xA, 0x4C, 0x3F, 0x00, 0x00 },/* 500 500 0.0 */
> + { 0xC, 0x73, 0x34, 0x00, 0x0B },/* 500 700 2.9 */
> + { 0x6, 0x7F, 0x2F, 0x00, 0x10 },/* 500 900 5.1 */
> + { 0xC, 0x6C, 0x3C, 0x00, 0x03 },/* 650 705 0.6 */
> + { 0x6, 0x7F, 0x35, 0x00, 0x0A },/* 600 900 3.5 */
> + { 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
> };
>
> -/* Voltage Swing Programming for VccIO 0.95V for DP */
> -static const struct icl_combo_phy_ddi_buf_trans
> icl_combo_phy_ddi_translations_dp_hdmi_0_95V[] = {
> - /* Voltage mV db*/
> - { 0x2, 0x98, 0x0018 }, /* 400 0.0 */
> - { 0x2, 0x98, 0x3015 }, /* 400 3.5 */
> - { 0x2, 0x98, 0x6012 }, /* 400 6.0 */
> - { 0x2, 0x98, 0x900F }, /* 400 9.5 */
> - { 0x4, 0x98, 0x0018 }, /* 600 0.0 */
> - { 0x4, 0x98, 0x3015 }, /* 600
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Restore workarounds after engine reset and unify their handling (rev3)
== Series Details ==
Series: Restore workarounds after engine reset and unify their handling (rev3)
URL : https://patchwork.freedesktop.org/series/53313/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ed91418aaeec drm/i915: Record GT workarounds in a list
-:492: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#492: FILE: drivers/gpu/drm/i915/intel_workarounds.c:914:
+ wa_masked_en(wal,
+ _3D_CHICKEN3,
-:768: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#768: FILE: drivers/gpu/drm/i915/intel_workarounds.h:20:
+^Iunsigned int ^Icount;$
total: 0 errors, 1 warnings, 1 checks, 724 lines checked
ccb6a2c1f539 drm/i915: Introduce per-engine workarounds
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 59b449d5c82a ("drm/i915: Split
out functions for different kinds of workarounds")'
#10:
59b449d5c82a ("drm/i915: Split out functions for different kinds of
total: 1 errors, 0 warnings, 0 checks, 389 lines checked
8d055232d8d8 drm/i915: Verify GT workaround state after GPU init
e779d6bfdfef drm/i915/selftests: Add tests for GT and engine workaround
verification
-:56: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#56:
new file mode 100644
-:61: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#61: FILE: drivers/gpu/drm/i915/selftests/igt_reset.c:1:
+/*
-:111: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#111: FILE: drivers/gpu/drm/i915/selftests/igt_reset.h:1:
+/*
total: 0 errors, 3 warnings, 0 checks, 361 lines checked
d695d6e32eb8 drm/i915: Move register white-listing to the common workaround
framework
ea620326b3cb drm/i915: Fuse per-context workaround handling with the common
framework
dc515637f6ec drm/i915: Trim unused workaround list entries
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/i915/selftests: Terminate hangcheck sanitycheck forcibly
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-12-03 12:09:39)
>> Chris Wilson writes:
>>
>> > If all else fails and we are stuck eternally waiting for the undying
>> > request, abandon all hope.
>> >
>> > Signed-off-by: Chris Wilson
>> > ---
>> > drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 12 +---
>> > 1 file changed, 9 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
>> > b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
>> > index defe671130ab..a48fbe2557ea 100644
>> > --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
>> > +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
>> > @@ -308,6 +308,7 @@ static int igt_hang_sanitycheck(void *arg)
>> > goto unlock;
>> >
>> > for_each_engine(engine, i915, id) {
>> > + struct igt_wedge_me w;
>> > long timeout;
>> >
>> > if (!intel_engine_can_store_dword(engine))
>> > @@ -328,9 +329,14 @@ static int igt_hang_sanitycheck(void *arg)
>> >
>> > i915_request_add(rq);
>> >
>> > - timeout = i915_request_wait(rq,
>> > - I915_WAIT_LOCKED,
>> > - MAX_SCHEDULE_TIMEOUT);
>> > + timeout = 0;
>> > + igt_wedge_on_timeout(&w, i915, HZ / 10 /* 100ms timeout*/)
>>
>> 100ms? We are emitting a hanging batch here, so there is something
>> I am missing here.
>
> It's not a hanging batch, anymore due to the terminator applied a couple
> of lines above.
There it is. I did read the code, I did have coffee. It is Monday.
Reviewed-by: Mika Kuoppala
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Restore workarounds after engine reset and unify their handling (rev3)
== Series Details == Series: Restore workarounds after engine reset and unify their handling (rev3) URL : https://patchwork.freedesktop.org/series/53313/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Record GT workarounds in a list -drivers/gpu/drm/i915/selftests/../i915_drv.h:3571:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3573:16: warning: expression using sizeof(void) +./include/linux/slab.h:665:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/slab.h:665:13: warning: call with no type! Commit: drm/i915: Introduce per-engine workarounds Okay! Commit: drm/i915: Verify GT workaround state after GPU init Okay! Commit: drm/i915/selftests: Add tests for GT and engine workaround verification +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) Commit: drm/i915: Move register white-listing to the common workaround framework Okay! Commit: drm/i915: Fuse per-context workaround handling with the common framework -drivers/gpu/drm/i915/selftests/../i915_drv.h:3573:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3558:16: warning: expression using sizeof(void) Commit: drm/i915: Trim unused workaround list entries Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: Get pipe id following atomic guidelines (rev2)
On 30/11/2018 19:27, Vivi, Rodrigo wrote:
> On Fri, Nov 30, 2018 at 03:04:40PM +0200, Martin Peres wrote:
>>
>>
>> On 29/11/2018 19:36, Rodrigo Vivi wrote:
>>> On Wed, Nov 28, 2018 at 11:52:49PM -0800, Saarinen, Jani wrote:
Hi,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> Behalf Of
> Rodrigo Vivi
> Sent: torstai 29. marraskuuta 2018 8.18
> To: Souza, Jose
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: Get pipe
> id
> following atomic guidelines (rev2)
>
> On Wed, Nov 28, 2018 at 02:13:12PM -0800, Souza, Jose wrote:
>> On Wed, 2018-11-28 at 21:02 +, Patchwork wrote:
>>> == Series Details ==
>>>
>>> Series: drm/i915/psr: Get pipe id following atomic guidelines (rev2)
>>> URL : https://patchwork.freedesktop.org/series/53132/
>>> State : failure
>>>
>>> == Summary ==
>>>
>>> CI Bug Log - changes from CI_DRM_5216 -> Patchwork_10934
>>>
>>>
>>> Summary
>>> ---
>>>
>>> **FAILURE**
>>>
>>> Serious unknown changes coming with Patchwork_10934 absolutely
>>> need to be
>>> verified manually.
>>>
>>> If you think the reported changes have nothing to do with the
>>> changes
>>> introduced in Patchwork_10934, please notify your bug team to
>>> allow them
>>> to document this new failure mode, which will reduce false
>>> positives in CI.
>>>
>>> External URL:
>>> https://patchwork.freedesktop.org/api/1.0/series/53132/revisions/2/m
>>> box/
>>>
>>> Possible new issues
>>> ---
>>>
>>> Here are the unknown changes that may have been introduced in
>>> Patchwork_10934:
>>>
>>> ### IGT changes ###
>>>
>>> Possible regressions
>>>
>>> * igt@i915_selftest@live_sanitycheck:
>>> - fi-apl-guc: PASS -> DMESG-WARN
>>>
>>> * {igt@runner@aborted}:
>>> - fi-apl-guc: NOTRUN -> FAIL
>>
>> Both are pretty much non related with display, what do you think
>> Rodrigo? It is a merge blocker?
>
> I got addicted to see all green on CI. So I always prefer to trigger a
> retest. So
> anyone following the link that is merged with the patch doens't have to
> understand and analyze why it was merged with BAT failure.
>
> I just triggered the re-test for this patch.
Martin, Arek, fyi, not preferred?
>>>
>>> Yes, I'd like to hear their opinion.
>>>
>>> On this case a simple BAT would be enough because we don't have PSR monitors
>>> on shrd ones.
>>> However most of the times trigger the retest is unavoidable because we need
>>> to make it to pass BAT and go for the full run.
>>>
>>> Besides the green-report-link reason I exposed above.
>>
>> I agree that we should only push stuff when CI is green.
>>
>> However, using the re-try button is the wrong way as it requires more
>> machine time, and it may hide low-probably issues introduced by the patch.
>>
>> Instead, we should file/edit bugs and then ask cibuglog to re-send the
>> report. I have been doing this ofr a couple of people already, but we
>> need to advertise this more!
>
> This makes total sense for me. But I wonder if we don't need at least
> one re-run.
>
> My feeling is that if we tell people to file bugs and regenerate
> reports they might just end up accidentally ignoring regressions that
> was caused by their own patches.
Yeah, I get your point... but machine time is also problematic...
In most cases, it is just that I need to extend a filter, which does not
warrant a new run.
If something is new or odd, we could use a re-run ;)
In any case, if I file the bug and we land a regression, it will not
affect CI. So that's just an additional workload for bug tracking and
fixing. But we'll have a documented trail leading back to the developer,
so we can assign him more easily!
>
> But anyway is there a doc with step-by-step instructions anywhere that
> we could learn from and start doing this without overwhelming a single
> person?
Not yet. I need to send this information... and you are absolutely right
on the bottleneck here: I do not scale ... and I do not have time to
make my work less labor-intensive because I don't have time to work on
it. Nice isn't it?
In any case, the current process is just to forward me the result email,
then I will look at the filing and re-report.
Martin
>
> Thanks a lot!
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Record GT workarounds in a list
On 03/12/2018 11:54, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-12-03 11:46:11)
From: Tvrtko Ursulin
To enable later verification of GT workaround state at various stages of
driver lifetime, we record the list of applicable ones per platforms to a
list, from which they are also applied.
The added data structure is a simple array of register, mask and value
items, which is allocated on demand as workarounds are added to the list.
This is a temporary implementation which later in the series gets fused
with the existing per context workaround list handling. It is separated at
this stage since the following patch fixes a bug which needs to be as easy
to backport as possible.
Also, since in the following patch we will be adding a new class of
workarounds (per engine) which can be applied from interrupt context, we
straight away make the provision for safe read-modify-write cycle.
v2:
* Change dev_priv to i915 along the init path. (Chris Wilson)
* API rename. (Chris Wilson)
v3:
* Remove explicit list size tracking in favour of growing the allocation
in power of two chunks. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v2
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/intel_workarounds.c | 491 +++
drivers/gpu/drm/i915/intel_workarounds.h | 23 +-
5 files changed, 353 insertions(+), 168 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e39016713464..ee5116b62cd2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1453,6 +1453,7 @@ static int i915_driver_init_hw(struct drm_i915_private
*dev_priv)
intel_uncore_sanitize(dev_priv);
+ intel_gt_init_workarounds(dev_priv);
i915_gem_load_init_fences(dev_priv);
/* On the 945G/GM, the chipset reports the MSI capability on the
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 43ac6873a2bb..9ddbcc1f3554 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -69,6 +69,7 @@
#include "intel_ringbuffer.h"
#include "intel_uncore.h"
#include "intel_wopcm.h"
+#include "intel_workarounds.h"
#include "intel_uc.h"
#include "i915_gem.h"
@@ -1652,6 +1653,7 @@ struct drm_i915_private {
int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
struct i915_workarounds workarounds;
+ struct i915_wa_list gt_wa_list;
struct i915_frontbuffer_tracking fb_tracking;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c55b1f75c980..6333a7d6af5a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5334,7 +5334,7 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
I915_WRITE(MI_PREDICATE_RESULT_2, IS_HSW_GT3(dev_priv) ?
LOWER_SLICE_ENABLED : LOWER_SLICE_DISABLED);
- intel_gt_workarounds_apply(dev_priv);
+ intel_gt_apply_workarounds(dev_priv);
i915_gem_init_swizzling(dev_priv);
@@ -5706,6 +5706,8 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
i915_gem_contexts_fini(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
+ intel_wa_list_free(&dev_priv->gt_wa_list);
+
intel_cleanup_gt_powersave(dev_priv);
intel_uc_fini_misc(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index e5cd6c6c66c3..f05f13547034 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -48,6 +48,18 @@
* - Public functions to init or apply the given workaround type.
*/
+static void wa_init_start(struct i915_wa_list *wal, const char *name)
+{
+ wal->name = name;
+}
+
+static void wa_init_finish(struct i915_wa_list *wal)
+{
+ if (wal->count)
+ DRM_DEBUG_DRIVER("Initialized %u %s workarounds\n",
+wal->count, wal->name);
Does this become if (!wal->count) return; later?
Done.
+}
+
static void wa_add(struct drm_i915_private *i915,
i915_reg_t reg, const u32 mask, const u32 val)
{
@@ -575,160 +587,240 @@ int intel_ctx_workarounds_emit(struct i915_request *rq)
return 0;
}
-static void bdw_gt_workarounds_apply(struct drm_i915_private *dev_priv)
+static void
+wal_add(struct i915_wa_list *wal, const struct i915_wa *wa)
+{
+ const unsigned int grow = 1 << 4;
+
+ GEM_BUG_ON(!is_power_of_2(grow));
+
+ if (IS_ALIGNED(wal->count, grow)) { /* Either uninitialized or full. */
Neat.
+ struct i915_wa *list;
+
+ list = kcalloc(ALIGN(wal->count + 1, grow), sizeof(*wa),
+ GFP_KERNEL);
(Quietly comments on the
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Record GT workarounds in a list
Quoting Tvrtko Ursulin (2018-12-03 12:34:24)
>
> On 03/12/2018 11:54, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-12-03 11:46:11)
> >> From: Tvrtko Ursulin
> >> @@ -575,160 +587,240 @@ int intel_ctx_workarounds_emit(struct i915_request
> >> *rq)
> >> return 0;
> >> }
> >>
> >> -static void bdw_gt_workarounds_apply(struct drm_i915_private *dev_priv)
> >> +static void
> >> +wal_add(struct i915_wa_list *wal, const struct i915_wa *wa)
> >> +{
> >> + const unsigned int grow = 1 << 4;
> >> +
> >> + GEM_BUG_ON(!is_power_of_2(grow));
> >> +
> >> + if (IS_ALIGNED(wal->count, grow)) { /* Either uninitialized or
> >> full. */
> >
> > Neat.
> >
> >> + struct i915_wa *list;
> >> +
> >> + list = kcalloc(ALIGN(wal->count + 1, grow), sizeof(*wa),
> >> + GFP_KERNEL);
> >
> > (Quietly comments on the calloc here ;)
>
> Oh I don't want to complicate things with zeroing the tail. Or you
> wouldn't bother with zeroing at all since I always copy over used
> entries? So unused, who cares about them?
Exactly, nothing after wal->count is accessed, so no need to zero it as
it will always be initialised by wal_add().
> >> +struct i915_wa_list {
> >> + const char *name;
> >> + unsigned intcount;
> >> + struct i915_wa *list;
> >
> > Oh well, didn't save anything after all.
>
> How nothing, one unsigned int per wa_list instance! :)
struct is padded to 8 bytes for the pointer. There's a hole after count,
even if we place it at the end. :|
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Restore workarounds after engine reset and unify their handling (rev3)
== Series Details ==
Series: Restore workarounds after engine reset and unify their handling (rev3)
URL : https://patchwork.freedesktop.org/series/53313/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5239 -> Patchwork_10997
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53313/revisions/3/mbox/
Known issues
Here are the changes found in Patchwork_10997 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-bsw-n3050: PASS -> FAIL [fdo#108656]
* igt@gem_exec_reloc@basic-gtt:
- fi-skl-6770hq: PASS -> DMESG-WARN [fdo#105541]
* {igt@runner@aborted}:
- {fi-icl-y}: NOTRUN -> FAIL [fdo#108070]
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] / [fdo#108622] -> PASS
Warnings
* igt@i915_selftest@live_contexts:
- {fi-icl-u3}:INCOMPLETE [fdo#108315] -> DMESG-FAIL [fdo#108569]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
[fdo#108070]: https://bugs.freedesktop.org/show_bug.cgi?id=108070
[fdo#108315]: https://bugs.freedesktop.org/show_bug.cgi?id=108315
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108656]: https://bugs.freedesktop.org/show_bug.cgi?id=108656
Participating hosts (47 -> 42)
--
Additional (1): fi-icl-y
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-pnv-d510
Build changes
-
* Linux: CI_DRM_5239 -> Patchwork_10997
CI_DRM_5239: 6b82ae50cbf9b70fb3884937a221f69261c4c41c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4736: 285ebfb3b7adc56586031afa5150c4e5ad40c229 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10997: dc515637f6ecad20b108197a91ecbdd6046b7e31 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
dc515637f6ec drm/i915: Trim unused workaround list entries
ea620326b3cb drm/i915: Fuse per-context workaround handling with the common
framework
d695d6e32eb8 drm/i915: Move register white-listing to the common workaround
framework
e779d6bfdfef drm/i915/selftests: Add tests for GT and engine workaround
verification
8d055232d8d8 drm/i915: Verify GT workaround state after GPU init
ccb6a2c1f539 drm/i915: Introduce per-engine workarounds
ed91418aaeec drm/i915: Record GT workarounds in a list
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10997/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Record GT workarounds in a list
On 03/12/2018 12:38, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-12-03 12:34:24)
On 03/12/2018 11:54, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-12-03 11:46:11)
From: Tvrtko Ursulin
@@ -575,160 +587,240 @@ int intel_ctx_workarounds_emit(struct i915_request *rq)
return 0;
}
-static void bdw_gt_workarounds_apply(struct drm_i915_private *dev_priv)
+static void
+wal_add(struct i915_wa_list *wal, const struct i915_wa *wa)
+{
+ const unsigned int grow = 1 << 4;
+
+ GEM_BUG_ON(!is_power_of_2(grow));
+
+ if (IS_ALIGNED(wal->count, grow)) { /* Either uninitialized or full. */
Neat.
+ struct i915_wa *list;
+
+ list = kcalloc(ALIGN(wal->count + 1, grow), sizeof(*wa),
+ GFP_KERNEL);
(Quietly comments on the calloc here ;)
Oh I don't want to complicate things with zeroing the tail. Or you
wouldn't bother with zeroing at all since I always copy over used
entries? So unused, who cares about them?
Exactly, nothing after wal->count is accessed, so no need to zero it as
it will always be initialised by wal_add().
Ok.
+struct i915_wa_list {
+ const char *name;
+ unsigned intcount;
+ struct i915_wa *list;
Oh well, didn't save anything after all.
How nothing, one unsigned int per wa_list instance! :)
struct is padded to 8 bytes for the pointer. There's a hole after count,
even if we place it at the end. :|
Another unsigned int gets in there later in the series - for the benefit
of being able to log the exact, and not merged, number of workarounds.
But it makes sense to move the count at the end anyway so I'll do that.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915/selftests: Add tests for GT and engine workaround verification
From: Tvrtko Ursulin
Two simple selftests which test that both GT and engine workarounds are
not lost after either a full GPU reset, or after the per-engine ones.
(Including checks that one engine reset is not affecting workarounds not
belonging to itself.)
v2:
* Rebase for series refactoring.
* Add spinner for actual engine reset!
* Add idle reset test as well. (Chris Wilson)
* Share existing global_reset_lock. (Chris Wilson)
v3:
* intel_engine_verify_workarounds can be static.
* API rename. (Chris Wilson)
* Move global reset lock out of the loop. (Chris Wilson)
v4:
* Add missing rpm puts. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/intel_workarounds.c | 6 +
drivers/gpu/drm/i915/selftests/igt_reset.c| 44 ++
drivers/gpu/drm/i915/selftests/igt_reset.h| 15 ++
.../gpu/drm/i915/selftests/intel_hangcheck.c | 51 ++-
.../drm/i915/selftests/intel_workarounds.c| 144 +-
6 files changed, 214 insertions(+), 47 deletions(-)
create mode 100644 drivers/gpu/drm/i915/selftests/igt_reset.c
create mode 100644 drivers/gpu/drm/i915/selftests/igt_reset.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 50a8fa8fce64..19b5fe5016bf 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -166,6 +166,7 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
selftests/i915_random.o \
selftests/i915_selftest.o \
selftests/igt_flush_test.o \
+ selftests/igt_reset.o \
selftests/igt_spinner.o
# virtual gpu code
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 1fc4964528a7..bb49a5504c9a 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1304,5 +1304,11 @@ void intel_engine_apply_workarounds(struct
intel_engine_cs *engine)
}
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
+static bool intel_engine_verify_workarounds(struct intel_engine_cs *engine,
+ const char *from)
+{
+ return wa_list_verify(engine->i915, &engine->wa_list, from);
+}
+
#include "selftests/intel_workarounds.c"
#endif
diff --git a/drivers/gpu/drm/i915/selftests/igt_reset.c
b/drivers/gpu/drm/i915/selftests/igt_reset.c
new file mode 100644
index ..208a966da8ca
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/igt_reset.c
@@ -0,0 +1,44 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#include "igt_reset.h"
+
+#include "../i915_drv.h"
+#include "../intel_ringbuffer.h"
+
+void igt_global_reset_lock(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ pr_debug("%s: current gpu_error=%08lx\n",
+__func__, i915->gpu_error.flags);
+
+ while (test_and_set_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags))
+ wait_event(i915->gpu_error.reset_queue,
+ !test_bit(I915_RESET_BACKOFF,
+&i915->gpu_error.flags));
+
+ for_each_engine(engine, i915, id) {
+ while (test_and_set_bit(I915_RESET_ENGINE + id,
+ &i915->gpu_error.flags))
+ wait_on_bit(&i915->gpu_error.flags,
+ I915_RESET_ENGINE + id,
+ TASK_UNINTERRUPTIBLE);
+ }
+}
+
+void igt_global_reset_unlock(struct drm_i915_private *i915)
+{
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ for_each_engine(engine, i915, id)
+ clear_bit(I915_RESET_ENGINE + id, &i915->gpu_error.flags);
+
+ clear_bit(I915_RESET_BACKOFF, &i915->gpu_error.flags);
+ wake_up_all(&i915->gpu_error.reset_queue);
+}
diff --git a/drivers/gpu/drm/i915/selftests/igt_reset.h
b/drivers/gpu/drm/i915/selftests/igt_reset.h
new file mode 100644
index ..5f0234d045d5
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/igt_reset.h
@@ -0,0 +1,15 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#ifndef __I915_SELFTESTS_IGT_RESET_H__
+#define __I915_SELFTESTS_IGT_RESET_H__
+
+#include "../i915_drv.h"
+
+void igt_global_reset_lock(struct drm_i915_private *i915);
+void igt_global_reset_unlock(struct drm_i915_private *i915);
+
+#endif
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index defe671130ab..3ac53496127b 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -27,6 +27,7 @@
#include "../i915_selftest.h"
#include "i915_random.h"
#include "igt_flush_test.h"
+#include "igt_reset.h"
#include "igt_wedge_me.h"
#include "mock_context.h"
@@ -348,40 +349,6 @@ static int ig
[Intel-gfx] [PATCH 5/7] drm/i915: Move register white-listing to the common workaround framework
From: Tvrtko Ursulin
Instead of having a separate list of white-listed registers we can
trivially move this to the common workarounds framework.
This brings us one step closer to the goal of driving all workaround
classes using the same code.
v2:
* Use GEM_DEBUG_WARN_ON for the sanity check. (Chris Wilson)
v3:
* API rename. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c| 1 +
drivers/gpu/drm/i915/intel_lrc.c | 5 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
drivers/gpu/drm/i915/intel_workarounds.c | 83 ---
drivers/gpu/drm/i915/intel_workarounds.h | 3 +-
.../drm/i915/selftests/intel_workarounds.c| 40 -
6 files changed, 60 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index ef5d202e9d45..496462d77ebc 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -725,6 +725,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs
*engine)
i915_timeline_fini(&engine->timeline);
intel_wa_list_free(&engine->wa_list);
+ intel_wa_list_free(&engine->whitelist);
}
u64 intel_engine_get_active_head(const struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 7a7787cbafee..af61a3cf9cb8 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1643,7 +1643,7 @@ static int gen8_init_render_ring(struct intel_engine_cs
*engine)
if (ret)
return ret;
- intel_whitelist_workarounds_apply(engine);
+ intel_engine_apply_whitelist(engine);
/* We need to disable the AsyncFlip performance optimisations in order
* to use MI_WAIT_FOR_EVENT within the CS. It should already be
@@ -1666,7 +1666,7 @@ static int gen9_init_render_ring(struct intel_engine_cs
*engine)
if (ret)
return ret;
- intel_whitelist_workarounds_apply(engine);
+ intel_engine_apply_whitelist(engine);
return 0;
}
@@ -2316,6 +2316,7 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
ret);
}
+ intel_engine_init_whitelist(engine);
intel_engine_init_workarounds(engine);
return 0;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index c5ff3d31cab7..91a750e90dc4 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -453,6 +453,7 @@ struct intel_engine_cs {
struct intel_hw_status_page status_page;
struct i915_ctx_workarounds wa_ctx;
struct i915_wa_list wa_list;
+ struct i915_wa_list whitelist;
struct i915_vma *scratch;
u32 irq_keep_mask; /* always keep these interrupts */
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index bb49a5504c9a..56907311349e 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -1012,29 +1012,20 @@ bool intel_gt_verify_workarounds(struct
drm_i915_private *dev_priv,
return wa_list_verify(dev_priv, &dev_priv->gt_wa_list, from);
}
-struct whitelist {
- i915_reg_t reg[RING_MAX_NONPRIV_SLOTS];
- unsigned int count;
- u32 nopid;
-};
-
-static void whitelist_reg(struct whitelist *w, i915_reg_t reg)
+static void
+whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
{
- if (GEM_DEBUG_WARN_ON(w->count >= RING_MAX_NONPRIV_SLOTS))
- return;
-
- w->reg[w->count++] = reg;
-}
+ struct i915_wa wa = {
+ .reg = reg
+ };
-static void bdw_whitelist_build(struct whitelist *w)
-{
-}
+ if (GEM_DEBUG_WARN_ON(wal->count >= RING_MAX_NONPRIV_SLOTS))
+ return;
-static void chv_whitelist_build(struct whitelist *w)
-{
+ wal_add(wal, &wa);
}
-static void gen9_whitelist_build(struct whitelist *w)
+static void gen9_whitelist_build(struct i915_wa_list *w)
{
/* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
whitelist_reg(w, GEN9_CTX_PREEMPT_REG);
@@ -1046,7 +1037,7 @@ static void gen9_whitelist_build(struct whitelist *w)
whitelist_reg(w, GEN8_HDC_CHICKEN1);
}
-static void skl_whitelist_build(struct whitelist *w)
+static void skl_whitelist_build(struct i915_wa_list *w)
{
gen9_whitelist_build(w);
@@ -1054,12 +1045,12 @@ static void skl_whitelist_build(struct whitelist *w)
whitelist_reg(w, GEN8_L3SQCREG4);
}
-static void bxt_whitelist_build(struct whitelist *w)
+static void bxt_whitelist_build(struct i915_wa_list *w)
{
gen9_whitelist_build(w);
}
-static void kbl_whitelist_build(struct whitelist *w)
+static void kbl_whitelist_build(struct i915_wa_list *w)
{
gen9_wh
[Intel-gfx] [PATCH v4 0/7] Restore workarounds after engine reset and unify their handling
From: Tvrtko Ursulin
First two patches in this series fix losing of workarounds after engine reset
(https://bugzilla.freedesktop.org/show_bug.cgi?id=107945) which started
happening after 59b449d5c82a ("drm/i915: Split out functions for different kinds
of workarounds").
But since it was discovered to be unsafe to simply re-apply all of them, against
a possibly active GPU, and potentially from IRQ context, the approach taken was
to split GT workarounds and per-engine workarounds. Latter so far contain the
ones living in the 0x2xxx and 0xbxxx range, which were empirically shown to be
lost after RCS reset.
This way only a smaller set of affected workarounds can be applied after engine
resetm, which is done with irq safe read-modify-write cycle.
The series is structured like this so first two patches are as standalone as
possible so it is easy (easier) to backport them. The rest of the series
cleans up the whole workaround handling by moving all four classes of them to a
common framework.
v2:
* One patch less due removing verification after engine reset.
* See patch change logs.
v3:
* Further review comments as per individual change logs.
v4:
* Further review comment tweaks.
Tvrtko Ursulin (7):
drm/i915: Record GT workarounds in a list
drm/i915: Introduce per-engine workarounds
drm/i915: Verify GT workaround state after GPU init
drm/i915/selftests: Add tests for GT and engine workaround
verification
drm/i915: Move register white-listing to the common workaround
framework
drm/i915: Fuse per-context workaround handling with the common
framework
drm/i915: Trim unused workaround list entries
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_debugfs.c | 12 +-
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 17 +-
drivers/gpu/drm/i915/i915_gem.c | 7 +-
drivers/gpu/drm/i915/i915_gem_context.c | 6 +-
drivers/gpu/drm/i915/intel_engine_cs.c| 4 +
drivers/gpu/drm/i915/intel_lrc.c | 11 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +
drivers/gpu/drm/i915/intel_workarounds.c | 989 +++---
drivers/gpu/drm/i915/intel_workarounds.h | 36 +-
drivers/gpu/drm/i915/selftests/igt_reset.c| 44 +
drivers/gpu/drm/i915/selftests/igt_reset.h| 15 +
.../gpu/drm/i915/selftests/intel_hangcheck.c | 51 +-
.../drm/i915/selftests/intel_workarounds.c| 184 +++-
16 files changed, 886 insertions(+), 499 deletions(-)
create mode 100644 drivers/gpu/drm/i915/selftests/igt_reset.c
create mode 100644 drivers/gpu/drm/i915/selftests/igt_reset.h
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915: Trim unused workaround list entries
From: Tvrtko Ursulin
The new workaround list allocator grows the list in chunks so will end up
with some unused space. Trim it when the initialization phase is done to
free up a tiny bit of slab.
v2:
* Simplify with kmemdup. (Chris Wilson)
v3:
* Refactor for __size removal.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v2
---
drivers/gpu/drm/i915/intel_workarounds.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 53a6d6327020..5917b760a3ae 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -53,8 +53,22 @@ static void wa_init_start(struct i915_wa_list *wal, const
char *name)
wal->name = name;
}
+#define WA_LIST_CHUNK (1 << 4)
+
static void wa_init_finish(struct i915_wa_list *wal)
{
+ /* Trim unused entries. */
+ if (!IS_ALIGNED(wal->count, WA_LIST_CHUNK)) {
+ struct i915_wa *list = kmemdup(wal->list,
+ wal->count * sizeof(*list),
+ GFP_KERNEL);
+
+ if (list) {
+ kfree(wal->list);
+ wal->list = list;
+ }
+ }
+
if (!wal->count)
return;
@@ -66,7 +80,7 @@ static void _wa_add(struct i915_wa_list *wal, const struct
i915_wa *wa)
{
unsigned int addr = i915_mmio_reg_offset(wa->reg);
unsigned int start = 0, end = wal->count;
- const unsigned int grow = 1 << 4;
+ const unsigned int grow = WA_LIST_CHUNK;
struct i915_wa *wa_;
GEM_BUG_ON(!is_power_of_2(grow));
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915: Verify GT workaround state after GPU init
From: Tvrtko Ursulin
Since we now have all the GT workarounds in a table, by adding a simple
shared helper function we can now verify that their values are still
applied after some interesting events in the lifetime of the driver.
Initially we only do this after GPU initialization.
v2:
Chris Wilson:
* Simplify verification by realizing it's a simple xor and and.
* Remove verification from engine reset path.
* Return bool straight away from the verify API.
v3:
* API rename. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_gem.c | 3 +++
drivers/gpu/drm/i915/intel_workarounds.c | 34
drivers/gpu/drm/i915/intel_workarounds.h | 2 ++
4 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ee5116b62cd2..1ab6ba5771a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -53,6 +53,7 @@
#include "i915_vgpu.h"
#include "intel_drv.h"
#include "intel_uc.h"
+#include "intel_workarounds.h"
static struct drm_driver driver;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6333a7d6af5a..298f79c137eb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5334,7 +5334,10 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
I915_WRITE(MI_PREDICATE_RESULT_2, IS_HSW_GT3(dev_priv) ?
LOWER_SLICE_ENABLED : LOWER_SLICE_DISABLED);
+ /* Apply the GT workarounds... */
intel_gt_apply_workarounds(dev_priv);
+ /* ...and determine whether they are sticking. */
+ intel_gt_verify_workarounds(dev_priv, "init");
i915_gem_init_swizzling(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 4ef0dd09bff9..1fc4964528a7 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -978,6 +978,40 @@ void intel_gt_apply_workarounds(struct drm_i915_private
*dev_priv)
wa_list_apply(dev_priv, &dev_priv->gt_wa_list);
}
+static bool
+wa_verify(const struct i915_wa *wa, u32 cur, const char *name, const char
*from)
+{
+ if ((cur ^ wa->val) & wa->mask) {
+ DRM_ERROR("%s workaround lost on %s! (%x=%x/%x, expected %x,
mask=%x)\n",
+ name, from, i915_mmio_reg_offset(wa->reg), cur,
+ cur & wa->mask, wa->val, wa->mask);
+
+ return false;
+ }
+
+ return true;
+}
+
+static bool wa_list_verify(struct drm_i915_private *dev_priv,
+ const struct i915_wa_list *wal,
+ const char *from)
+{
+ struct i915_wa *wa;
+ unsigned int i;
+ bool ok = true;
+
+ for (i = 0, wa = wal->list; i < wal->count; i++, wa++)
+ ok &= wa_verify(wa, I915_READ(wa->reg), wal->name, from);
+
+ return ok;
+}
+
+bool intel_gt_verify_workarounds(struct drm_i915_private *dev_priv,
+const char *from)
+{
+ return wa_list_verify(dev_priv, &dev_priv->gt_wa_list, from);
+}
+
struct whitelist {
i915_reg_t reg[RING_MAX_NONPRIV_SLOTS];
unsigned int count;
diff --git a/drivers/gpu/drm/i915/intel_workarounds.h
b/drivers/gpu/drm/i915/intel_workarounds.h
index 979695a53964..8822e6035f8d 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.h
+++ b/drivers/gpu/drm/i915/intel_workarounds.h
@@ -32,6 +32,8 @@ int intel_ctx_workarounds_emit(struct i915_request *rq);
void intel_gt_init_workarounds(struct drm_i915_private *dev_priv);
void intel_gt_apply_workarounds(struct drm_i915_private *dev_priv);
+bool intel_gt_verify_workarounds(struct drm_i915_private *dev_priv,
+const char *from);
void intel_whitelist_workarounds_apply(struct intel_engine_cs *engine);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915: Record GT workarounds in a list
From: Tvrtko Ursulin
To enable later verification of GT workaround state at various stages of
driver lifetime, we record the list of applicable ones per platforms to a
list, from which they are also applied.
The added data structure is a simple array of register, mask and value
items, which is allocated on demand as workarounds are added to the list.
This is a temporary implementation which later in the series gets fused
with the existing per context workaround list handling. It is separated at
this stage since the following patch fixes a bug which needs to be as easy
to backport as possible.
Also, since in the following patch we will be adding a new class of
workarounds (per engine) which can be applied from interrupt context, we
straight away make the provision for safe read-modify-write cycle.
v2:
* Change dev_priv to i915 along the init path. (Chris Wilson)
* API rename. (Chris Wilson)
v3:
* Remove explicit list size tracking in favour of growing the allocation
in power of two chunks. (Chris Wilson)
v4:
Chris Wilson:
* Change wa_list_finish to early return.
* Copy workarounds using the compiler for static checking.
* Do not bother zeroing unused entries.
* Re-order struct i915_wa_list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson # v2
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/intel_workarounds.c | 493 +++
drivers/gpu/drm/i915/intel_workarounds.h | 23 +-
5 files changed, 355 insertions(+), 168 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e39016713464..ee5116b62cd2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1453,6 +1453,7 @@ static int i915_driver_init_hw(struct drm_i915_private
*dev_priv)
intel_uncore_sanitize(dev_priv);
+ intel_gt_init_workarounds(dev_priv);
i915_gem_load_init_fences(dev_priv);
/* On the 945G/GM, the chipset reports the MSI capability on the
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 43ac6873a2bb..9ddbcc1f3554 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -69,6 +69,7 @@
#include "intel_ringbuffer.h"
#include "intel_uncore.h"
#include "intel_wopcm.h"
+#include "intel_workarounds.h"
#include "intel_uc.h"
#include "i915_gem.h"
@@ -1652,6 +1653,7 @@ struct drm_i915_private {
int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
struct i915_workarounds workarounds;
+ struct i915_wa_list gt_wa_list;
struct i915_frontbuffer_tracking fb_tracking;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c55b1f75c980..6333a7d6af5a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5334,7 +5334,7 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
I915_WRITE(MI_PREDICATE_RESULT_2, IS_HSW_GT3(dev_priv) ?
LOWER_SLICE_ENABLED : LOWER_SLICE_DISABLED);
- intel_gt_workarounds_apply(dev_priv);
+ intel_gt_apply_workarounds(dev_priv);
i915_gem_init_swizzling(dev_priv);
@@ -5706,6 +5706,8 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
i915_gem_contexts_fini(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
+ intel_wa_list_free(&dev_priv->gt_wa_list);
+
intel_cleanup_gt_powersave(dev_priv);
intel_uc_fini_misc(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index e5cd6c6c66c3..1e8bfb9a2034 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -48,6 +48,20 @@
* - Public functions to init or apply the given workaround type.
*/
+static void wa_init_start(struct i915_wa_list *wal, const char *name)
+{
+ wal->name = name;
+}
+
+static void wa_init_finish(struct i915_wa_list *wal)
+{
+ if (!wal->count)
+ return;
+
+ DRM_DEBUG_DRIVER("Initialized %u %s workarounds\n",
+wal->count, wal->name);
+}
+
static void wa_add(struct drm_i915_private *i915,
i915_reg_t reg, const u32 mask, const u32 val)
{
@@ -575,160 +589,240 @@ int intel_ctx_workarounds_emit(struct i915_request *rq)
return 0;
}
-static void bdw_gt_workarounds_apply(struct drm_i915_private *dev_priv)
+static void
+wal_add(struct i915_wa_list *wal, const struct i915_wa *wa)
+{
+ const unsigned int grow = 1 << 4;
+
+ GEM_BUG_ON(!is_power_of_2(grow));
+
+ if (IS_ALIGNED(wal->count, grow)) { /* Either uninitialized or full. */
+ struct i915_wa *list;
+
+ list = kmalloc(ALIGN(wal->count + 1, grow) * sizeof(*wa),
+ GFP_KERNEL);
+ if (!list) {
+
[Intel-gfx] [PATCH 6/7] drm/i915: Fuse per-context workaround handling with the common framework
From: Tvrtko Ursulin
Convert the per context workaround handling code to run against the newly
introduced common workaround framework and fuse the two to use the
existing smarter list add helper, the one which does the sorted insert and
merges registers where possible.
This completes migration of all four classes of workarounds onto the
common framework.
Existing macros are kept untouched for smaller code churn.
v2:
* Rename to list name ctx_wa_list and move from dev_priv to engine.
v3:
* API rename and parameters tweaking. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 +-
drivers/gpu/drm/i915/i915_drv.h | 15 -
drivers/gpu/drm/i915/i915_gem_context.c | 6 +-
drivers/gpu/drm/i915/intel_engine_cs.c | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
drivers/gpu/drm/i915/intel_workarounds.c | 334 +++
drivers/gpu/drm/i915/intel_workarounds.h | 5 +-
9 files changed, 168 insertions(+), 210 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 129b9a6f8309..38dcee1ca062 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3375,13 +3375,15 @@ static int i915_shared_dplls_info(struct seq_file *m,
void *unused)
static int i915_wa_registers(struct seq_file *m, void *unused)
{
- struct i915_workarounds *wa = &node_to_i915(m->private)->workarounds;
- int i;
+ struct drm_i915_private *i915 = node_to_i915(m->private);
+ const struct i915_wa_list *wal = &i915->engine[RCS]->ctx_wa_list;
+ struct i915_wa *wa;
+ unsigned int i;
- seq_printf(m, "Workarounds applied: %d\n", wa->count);
- for (i = 0; i < wa->count; ++i)
+ seq_printf(m, "Workarounds applied: %u\n", wal->count);
+ for (i = 0, wa = wal->list; i < wal->count; i++, wa++)
seq_printf(m, "0x%X: 0x%08X, mask: 0x%08X\n",
- wa->reg[i].addr, wa->reg[i].value, wa->reg[i].mask);
+ i915_mmio_reg_offset(wa->reg), wa->val, wa->mask);
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9ddbcc1f3554..443e08f4736a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1189,20 +1189,6 @@ struct i915_frontbuffer_tracking {
unsigned flip_bits;
};
-struct i915_wa_reg {
- u32 addr;
- u32 value;
- /* bitmask representing WA bits */
- u32 mask;
-};
-
-#define I915_MAX_WA_REGS 16
-
-struct i915_workarounds {
- struct i915_wa_reg reg[I915_MAX_WA_REGS];
- u32 count;
-};
-
struct i915_virtual_gpu {
bool active;
u32 caps;
@@ -1652,7 +1638,6 @@ struct drm_i915_private {
int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
- struct i915_workarounds workarounds;
struct i915_wa_list gt_wa_list;
struct i915_frontbuffer_tracking fb_tracking;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b97963db0287..371c07087095 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -535,16 +535,12 @@ static bool needs_preempt_context(struct drm_i915_private
*i915)
int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
{
struct i915_gem_context *ctx;
- int ret;
/* Reassure ourselves we are only called once */
GEM_BUG_ON(dev_priv->kernel_context);
GEM_BUG_ON(dev_priv->preempt_context);
- ret = intel_ctx_workarounds_init(dev_priv);
- if (ret)
- return ret;
-
+ intel_engine_init_ctx_wa(dev_priv->engine[RCS]);
init_contexts(dev_priv);
/* lowest priority; idle task */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 496462d77ebc..6b427bc52f78 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -724,6 +724,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs
*engine)
i915_timeline_fini(&engine->timeline);
+ intel_wa_list_free(&engine->ctx_wa_list);
intel_wa_list_free(&engine->wa_list);
intel_wa_list_free(&engine->whitelist);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index af61a3cf9cb8..7de7aa4715fc 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2078,7 +2078,7 @@ static int gen8_init_rcs_context(struct i915_request *rq)
{
int ret;
- ret = intel_ctx_workarounds_emit(rq);
+ ret = intel_engine_emit_ctx_wa(rq);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffe
[Intel-gfx] [PATCH 2/7] drm/i915: Introduce per-engine workarounds
From: Tvrtko Ursulin
We stopped re-applying the GT workarounds after engine reset since commit
59b449d5c82a ("drm/i915: Split out functions for different kinds of
workarounds").
Issue with this is that some of the GT workarounds live in the MMIO space
which gets lost during engine resets. So far the registers in 0x2xxx and
0xbxxx address range have been identified to be affected.
This losing of applied workarounds has obvious negative effects and can
even lead to hard system hangs (see the linked Bugzilla).
Rather than just restoring this re-application, because we have also
observed that it is not safe to just re-write all GT workarounds after
engine resets (GPU might be live and weird hardware states can happen),
we introduce a new class of per-engine workarounds and move only the
affected GT workarounds over.
Using the framework introduced in the previous patch, we therefore after
engine reset, re-apply only the workarounds living in the affected MMIO
address ranges.
v2:
* Move Wa_1406609255:icl to engine workarounds as well.
* Rename API. (Chris Wilson)
* Drop redundant IS_KABYLAKE. (Chris Wilson)
* Re-order engine wa/ init so latest platforms are first. (Rodrigo Vivi)
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=107945
Fixes: 59b449d5c82a ("drm/i915: Split out functions for different kinds of
workarounds")
Cc: Mika Kuoppala
Cc: Ville Syrjälä
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Acked-by: Rodrigo Vivi
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 2 +
drivers/gpu/drm/i915/intel_lrc.c | 4 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +
drivers/gpu/drm/i915/intel_workarounds.c | 261 ---
drivers/gpu/drm/i915/intel_workarounds.h | 3 +
5 files changed, 153 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 759c0fd58f8c..ef5d202e9d45 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -723,6 +723,8 @@ void intel_engine_cleanup_common(struct intel_engine_cs
*engine)
__intel_context_unpin(i915->kernel_context, engine);
i915_timeline_fini(&engine->timeline);
+
+ intel_wa_list_free(&engine->wa_list);
}
u64 intel_engine_get_active_head(const struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 11f4e6148557..7a7787cbafee 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1617,6 +1617,8 @@ static bool unexpected_starting_state(struct
intel_engine_cs *engine)
static int gen8_init_common_ring(struct intel_engine_cs *engine)
{
+ intel_engine_apply_workarounds(engine);
+
intel_mocs_init_engine(engine);
intel_engine_reset_breadcrumbs(engine);
@@ -2314,6 +2316,8 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
ret);
}
+ intel_engine_init_workarounds(engine);
+
return 0;
err_cleanup_common:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 8a2270b209b0..c5ff3d31cab7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -15,6 +15,7 @@
#include "i915_selftest.h"
#include "i915_timeline.h"
#include "intel_gpu_commands.h"
+#include "intel_workarounds.h"
struct drm_printer;
struct i915_sched_attr;
@@ -451,6 +452,7 @@ struct intel_engine_cs {
struct intel_hw_status_page status_page;
struct i915_ctx_workarounds wa_ctx;
+ struct i915_wa_list wa_list;
struct i915_vma *scratch;
u32 irq_keep_mask; /* always keep these interrupts */
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index 1e8bfb9a2034..4ef0dd09bff9 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -657,17 +657,6 @@ static void gen9_gt_workarounds_init(struct
drm_i915_private *i915)
{
struct i915_wa_list *wal = &i915->gt_wa_list;
- /* WaContextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl,glk,cfl */
- wa_masked_en(wal,
-GEN9_CSFE_CHICKEN1_RCS,
-GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE);
-
-
- /* WaEnableLbsSlaRetryTimerDecrement:skl,bxt,kbl,glk,cfl */
- wa_write_or(wal,
- BDW_SCRATCH1,
- GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE);
-
/* WaDisableKillLogic:bxt,skl,kbl */
if (!IS_COFFEELAKE(i915))
wa_write_or(wal,
@@ -689,24 +678,6 @@ static void gen9_gt_workarounds_init(struct
drm_i915_private *i915)
wa_write_or(wal,
GAM_ECOCHK,
BDW_DISABLE_HDC_INVALIDATION);
-
- /*
Re: [Intel-gfx] [v2, 1/8] drm: Add optional COLOR_ENCODING and COLOR_RANGE properties to drm_plane
On 03.12.2018 12:52, Hans Verkuil wrote: > On 12/03/2018 12:23 PM, Andrzej Hajda wrote: >> On 30.11.2018 15:48, Hans Verkuil wrote: >>> On 11/30/18 15:29, Ville Syrjälä wrote: On Fri, Nov 30, 2018 at 03:20:59PM +0100, Andrzej Hajda wrote: > Hi Ville, > > As Christoph cannot respond till middle next week I can try to respond > in his absence, as I am familiar with the subject. > > On 30.11.2018 14:25, Ville Syrjälä wrote: >> On Fri, Nov 30, 2018 at 02:08:11PM +0100, Christoph Manszewski wrote: >>> Hi, >>> >>> I am looking for a way to export the color encoding and range selection >>> to user space. I came across those properties and am wondering, why >>> they are meant only for non RGB color encodings. Would it be okay, to >>> modify them and use with RGB formats as well? >> What you trying to do? Input limited range RGB data and expand to full >> range? > For example. But there are two more general questions, which > surprisingly we have not found answer for. > > 1. What color encoding and range drm should expect on its input RGB > buffers by default? RGB is just RGB. There is no encoding. >> >> OK, Now I see I have confused encoding with colorspace, Hans thanks for >> the documentation. >> >> As I understand drm by default should expect sRGB colorspace, also for >> Y'CbCr buffers, and currently there are no standard ways to specify >> buffer colorspace. >> >> Looking at current users of drm_plane_create_color_properties for Y'CbCr >> buffers it seems default range should be LIMITED. > Right. There is support for YCbCr quantization range signaling in HDMI, > but that is for all intents and purposes broken in the standard. Don't > use it, just output limited range YCbCr. > > On the other hand, RGB Quantization range signaling should *always* be > used if the EDID signals support for it. I believe that's what drm does > today already (this certainly works for i915). > >> But default encoding is different: mali, armada, nouveau use >> DRM_COLOR_YCBCR_BT601, i915 uses DRM_COLOR_YCBCR_BT709 - shouldn't this >> be somehow standardized? > According to CEA-861 bt.601 should be used for SDTV (PAL/NTSC), 709 for > everything else. So this is resolution dependent. > > Although strictly speaking it is only userspace that knows the right > encoding, since it depends on the source material. You can have SDTV > video encoded with 709, or HDTV encoded with 601. But in the absence > of any information, the default rule above is what should be used. Since drm plane is not tied to specific crtc default encoding will not be always known prior to setting mode on crtc and attaching plane to crtc, probably DRM_COLOR_YCBCR_DEFAULT or similar would solve the issue. > >> >> What I still do not understand is colorspace conversion(not encoding!) - >> between pipeline input (framebuffers) and output (HDMI connector for >> example): >> >> 1. Since sRGB, SMPTE170M/BT.601, BT.709 colorspaces are 'almost >> identical in coverage' (according to wikipedia[1]) no colorspace >> conversion is performed at all. > That's correct. There is a slight difference between SMPTE170M and > sRGB/Rec709, but basically invisible to the naked eye unless you see > it side-by-side, and even then it's is hard to detect. > > However, sRGB uses a different transfer function compared to SMPTE170M > and Rec709, and that difference *is* quite visible. Not all hardware > (certainly not video capture hardware) is capable of converting between > different transfer functions, though. I gather that this is more common > for HDMI output hardware. > >> 2. It is performed somewhere by HW, just my IP documentation is not >> clear about it. >> >> >> Another thing which still bothers me is RGB range in case of HDMI - >> CEA-861 expects than on CEA modes limited RGB range should be sent, but >> the pipeline on the particular hardware I have do not perform any >> conversion of input buffers. So only limited range RGB buffers are >> displayed correctly. In such case property describing plane with limited >> RGB would be useful. > Are you sure? Usually the same block that does YCbCr encoding conversion > (601 to 709 or vice versa), also deals with limited/full range conversion. > > It is typically a 3x3 matrix + a vector adding the needed offsets. It is > dead cheap to implement in hardware, so it would be very unusual if there > is no support for this. Yay, I have unusual hardware :) There is register in HDMI output block for RGB->YCbCr conversion and I can specify there input RGB range and encoding, but it is only for cases where output is YCbCr4:4:4, In case RGB -> RGB no conversion is performed. Regards Andrzej >> >> [1]: https://en.wikipedia.org/wiki/Rec._709#Primary_chromaticities >> >> >>> It's assumed to be full range because no one really uses anything else. >>> For simple desktop usage that's true. When dealing with video inputs, >>> this becomes much more compli
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Trim unused workaround list entries
Quoting Tvrtko Ursulin (2018-12-03 12:50:14) > From: Tvrtko Ursulin > > The new workaround list allocator grows the list in chunks so will end up > with some unused space. Trim it when the initialization phase is done to > free up a tiny bit of slab. > > v2: > * Simplify with kmemdup. (Chris Wilson) > > v3: > * Refactor for __size removal. > > Signed-off-by: Tvrtko Ursulin > Reviewed-by: Chris Wilson # v2 > Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Record GT workarounds in a list
Quoting Tvrtko Ursulin (2018-12-03 12:50:08) > From: Tvrtko Ursulin > > To enable later verification of GT workaround state at various stages of > driver lifetime, we record the list of applicable ones per platforms to a > list, from which they are also applied. > > The added data structure is a simple array of register, mask and value > items, which is allocated on demand as workarounds are added to the list. > > This is a temporary implementation which later in the series gets fused > with the existing per context workaround list handling. It is separated at > this stage since the following patch fixes a bug which needs to be as easy > to backport as possible. > > Also, since in the following patch we will be adding a new class of > workarounds (per engine) which can be applied from interrupt context, we > straight away make the provision for safe read-modify-write cycle. > > v2: > * Change dev_priv to i915 along the init path. (Chris Wilson) > * API rename. (Chris Wilson) > > v3: > * Remove explicit list size tracking in favour of growing the allocation >in power of two chunks. (Chris Wilson) > > v4: > Chris Wilson: > * Change wa_list_finish to early return. > * Copy workarounds using the compiler for static checking. > * Do not bother zeroing unused entries. > * Re-order struct i915_wa_list. > > Signed-off-by: Tvrtko Ursulin > Reviewed-by: Chris Wilson # v2 Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Restore workarounds after engine reset and unify their handling (rev4)
== Series Details ==
Series: Restore workarounds after engine reset and unify their handling (rev4)
URL : https://patchwork.freedesktop.org/series/53313/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2c7ee2141088 drm/i915: Record GT workarounds in a list
-:135: WARNING:ALLOC_WITH_MULTIPLY: Prefer kmalloc_array over kmalloc with
multiply
#135: FILE: drivers/gpu/drm/i915/intel_workarounds.c:602:
+ list = kmalloc(ALIGN(wal->count + 1, grow) * sizeof(*wa),
+ GFP_KERNEL);
-:148: CHECK:LINE_SPACING: Please don't use multiple blank lines
#148: FILE: drivers/gpu/drm/i915/intel_workarounds.c:615:
+
+
-:502: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#502: FILE: drivers/gpu/drm/i915/intel_workarounds.c:916:
+ wa_masked_en(wal,
+ _3D_CHICKEN3,
total: 0 errors, 1 warnings, 2 checks, 726 lines checked
a814929884ca drm/i915: Introduce per-engine workarounds
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 59b449d5c82a ("drm/i915: Split
out functions for different kinds of workarounds")'
#10:
59b449d5c82a ("drm/i915: Split out functions for different kinds of
total: 1 errors, 0 warnings, 0 checks, 389 lines checked
21f44a8d57a8 drm/i915: Verify GT workaround state after GPU init
5e2506a706bf drm/i915/selftests: Add tests for GT and engine workaround
verification
-:59: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#59:
new file mode 100644
-:64: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#64: FILE: drivers/gpu/drm/i915/selftests/igt_reset.c:1:
+/*
-:114: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#114: FILE: drivers/gpu/drm/i915/selftests/igt_reset.h:1:
+/*
total: 0 errors, 3 warnings, 0 checks, 363 lines checked
5118aae39798 drm/i915: Move register white-listing to the common workaround
framework
dea19ac0666f drm/i915: Fuse per-context workaround handling with the common
framework
-:186: WARNING:ALLOC_WITH_MULTIPLY: Prefer kmalloc_array over kmalloc with
multiply
#186: FILE: drivers/gpu/drm/i915/intel_workarounds.c:77:
+ list = kmalloc(ALIGN(wal->count + 1, grow) * sizeof(*wa),
+ GFP_KERNEL);
total: 0 errors, 1 warnings, 0 checks, 682 lines checked
b6aae830b133 drm/i915: Trim unused workaround list entries
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Restore workarounds after engine reset and unify their handling (rev4)
== Series Details == Series: Restore workarounds after engine reset and unify their handling (rev4) URL : https://patchwork.freedesktop.org/series/53313/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Record GT workarounds in a list -drivers/gpu/drm/i915/selftests/../i915_drv.h:3571:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3573:16: warning: expression using sizeof(void) +./include/linux/slab.h:332:43: warning: dubious: x & !y Commit: drm/i915: Introduce per-engine workarounds Okay! Commit: drm/i915: Verify GT workaround state after GPU init Okay! Commit: drm/i915/selftests: Add tests for GT and engine workaround verification +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) Commit: drm/i915: Move register white-listing to the common workaround framework Okay! Commit: drm/i915: Fuse per-context workaround handling with the common framework -drivers/gpu/drm/i915/selftests/../i915_drv.h:3573:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3558:16: warning: expression using sizeof(void) Commit: drm/i915: Trim unused workaround list entries Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915: Record GT workarounds in a list
From: Tvrtko Ursulin
To enable later verification of GT workaround state at various stages of
driver lifetime, we record the list of applicable ones per platforms to a
list, from which they are also applied.
The added data structure is a simple array of register, mask and value
items, which is allocated on demand as workarounds are added to the list.
This is a temporary implementation which later in the series gets fused
with the existing per context workaround list handling. It is separated at
this stage since the following patch fixes a bug which needs to be as easy
to backport as possible.
Also, since in the following patch we will be adding a new class of
workarounds (per engine) which can be applied from interrupt context, we
straight away make the provision for safe read-modify-write cycle.
v2:
* Change dev_priv to i915 along the init path. (Chris Wilson)
* API rename. (Chris Wilson)
v3:
* Remove explicit list size tracking in favour of growing the allocation
in power of two chunks. (Chris Wilson)
v4:
Chris Wilson:
* Change wa_list_finish to early return.
* Copy workarounds using the compiler for static checking.
* Do not bother zeroing unused entries.
* Re-order struct i915_wa_list.
v5:
* kmalloc_array.
* Whitespace cleanup.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/intel_workarounds.c | 492 +++
drivers/gpu/drm/i915/intel_workarounds.h | 23 +-
5 files changed, 354 insertions(+), 168 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e39016713464..ee5116b62cd2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1453,6 +1453,7 @@ static int i915_driver_init_hw(struct drm_i915_private
*dev_priv)
intel_uncore_sanitize(dev_priv);
+ intel_gt_init_workarounds(dev_priv);
i915_gem_load_init_fences(dev_priv);
/* On the 945G/GM, the chipset reports the MSI capability on the
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 43ac6873a2bb..9ddbcc1f3554 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -69,6 +69,7 @@
#include "intel_ringbuffer.h"
#include "intel_uncore.h"
#include "intel_wopcm.h"
+#include "intel_workarounds.h"
#include "intel_uc.h"
#include "i915_gem.h"
@@ -1652,6 +1653,7 @@ struct drm_i915_private {
int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
struct i915_workarounds workarounds;
+ struct i915_wa_list gt_wa_list;
struct i915_frontbuffer_tracking fb_tracking;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c55b1f75c980..6333a7d6af5a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5334,7 +5334,7 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
I915_WRITE(MI_PREDICATE_RESULT_2, IS_HSW_GT3(dev_priv) ?
LOWER_SLICE_ENABLED : LOWER_SLICE_DISABLED);
- intel_gt_workarounds_apply(dev_priv);
+ intel_gt_apply_workarounds(dev_priv);
i915_gem_init_swizzling(dev_priv);
@@ -5706,6 +5706,8 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
i915_gem_contexts_fini(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
+ intel_wa_list_free(&dev_priv->gt_wa_list);
+
intel_cleanup_gt_powersave(dev_priv);
intel_uc_fini_misc(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index e5cd6c6c66c3..c3256ab2c411 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -48,6 +48,20 @@
* - Public functions to init or apply the given workaround type.
*/
+static void wa_init_start(struct i915_wa_list *wal, const char *name)
+{
+ wal->name = name;
+}
+
+static void wa_init_finish(struct i915_wa_list *wal)
+{
+ if (!wal->count)
+ return;
+
+ DRM_DEBUG_DRIVER("Initialized %u %s workarounds\n",
+wal->count, wal->name);
+}
+
static void wa_add(struct drm_i915_private *i915,
i915_reg_t reg, const u32 mask, const u32 val)
{
@@ -575,160 +589,239 @@ int intel_ctx_workarounds_emit(struct i915_request *rq)
return 0;
}
-static void bdw_gt_workarounds_apply(struct drm_i915_private *dev_priv)
+static void
+wal_add(struct i915_wa_list *wal, const struct i915_wa *wa)
+{
+ const unsigned int grow = 1 << 4;
+
+ GEM_BUG_ON(!is_power_of_2(grow));
+
+ if (IS_ALIGNED(wal->count, grow)) { /* Either uninitialized or full. */
+ struct i915_wa *list;
+
+ list = kmalloc_array(ALIGN(wal->count + 1, grow), sizeof(*wa),
+
[Intel-gfx] [PATCH 2/7] drm/i915: Introduce per-engine workarounds
From: Tvrtko Ursulin
We stopped re-applying the GT workarounds after engine reset since commit
59b449d5c82a ("drm/i915: Split out functions for different kinds of
workarounds").
Issue with this is that some of the GT workarounds live in the MMIO space
which gets lost during engine resets. So far the registers in 0x2xxx and
0xbxxx address range have been identified to be affected.
This losing of applied workarounds has obvious negative effects and can
even lead to hard system hangs (see the linked Bugzilla).
Rather than just restoring this re-application, because we have also
observed that it is not safe to just re-write all GT workarounds after
engine resets (GPU might be live and weird hardware states can happen),
we introduce a new class of per-engine workarounds and move only the
affected GT workarounds over.
Using the framework introduced in the previous patch, we therefore after
engine reset, re-apply only the workarounds living in the affected MMIO
address ranges.
v2:
* Move Wa_1406609255:icl to engine workarounds as well.
* Rename API. (Chris Wilson)
* Drop redundant IS_KABYLAKE. (Chris Wilson)
* Re-order engine wa/ init so latest platforms are first. (Rodrigo Vivi)
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=107945
Fixes: 59b449d5c82a ("drm/i915: Split out functions for different kinds of
workarounds")
Cc: Mika Kuoppala
Cc: Ville Syrjälä
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Acked-by: Rodrigo Vivi
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 2 +
drivers/gpu/drm/i915/intel_lrc.c | 4 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +
drivers/gpu/drm/i915/intel_workarounds.c | 261 ---
drivers/gpu/drm/i915/intel_workarounds.h | 3 +
5 files changed, 153 insertions(+), 119 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 759c0fd58f8c..ef5d202e9d45 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -723,6 +723,8 @@ void intel_engine_cleanup_common(struct intel_engine_cs
*engine)
__intel_context_unpin(i915->kernel_context, engine);
i915_timeline_fini(&engine->timeline);
+
+ intel_wa_list_free(&engine->wa_list);
}
u64 intel_engine_get_active_head(const struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 11f4e6148557..7a7787cbafee 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1617,6 +1617,8 @@ static bool unexpected_starting_state(struct
intel_engine_cs *engine)
static int gen8_init_common_ring(struct intel_engine_cs *engine)
{
+ intel_engine_apply_workarounds(engine);
+
intel_mocs_init_engine(engine);
intel_engine_reset_breadcrumbs(engine);
@@ -2314,6 +2316,8 @@ int logical_render_ring_init(struct intel_engine_cs
*engine)
ret);
}
+ intel_engine_init_workarounds(engine);
+
return 0;
err_cleanup_common:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 8a2270b209b0..c5ff3d31cab7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -15,6 +15,7 @@
#include "i915_selftest.h"
#include "i915_timeline.h"
#include "intel_gpu_commands.h"
+#include "intel_workarounds.h"
struct drm_printer;
struct i915_sched_attr;
@@ -451,6 +452,7 @@ struct intel_engine_cs {
struct intel_hw_status_page status_page;
struct i915_ctx_workarounds wa_ctx;
+ struct i915_wa_list wa_list;
struct i915_vma *scratch;
u32 irq_keep_mask; /* always keep these interrupts */
diff --git a/drivers/gpu/drm/i915/intel_workarounds.c
b/drivers/gpu/drm/i915/intel_workarounds.c
index c3256ab2c411..847988d15e8a 100644
--- a/drivers/gpu/drm/i915/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/intel_workarounds.c
@@ -656,17 +656,6 @@ static void gen9_gt_workarounds_init(struct
drm_i915_private *i915)
{
struct i915_wa_list *wal = &i915->gt_wa_list;
- /* WaContextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl,glk,cfl */
- wa_masked_en(wal,
-GEN9_CSFE_CHICKEN1_RCS,
-GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE);
-
-
- /* WaEnableLbsSlaRetryTimerDecrement:skl,bxt,kbl,glk,cfl */
- wa_write_or(wal,
- BDW_SCRATCH1,
- GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE);
-
/* WaDisableKillLogic:bxt,skl,kbl */
if (!IS_COFFEELAKE(i915))
wa_write_or(wal,
@@ -688,24 +677,6 @@ static void gen9_gt_workarounds_init(struct
drm_i915_private *i915)
wa_write_or(wal,
GAM_ECOCHK,
BDW_DISABLE_HDC_INVALIDATION);
-
- /*
[Intel-gfx] [PATCH 6/7] drm/i915: Fuse per-context workaround handling with the common framework
From: Tvrtko Ursulin
Convert the per context workaround handling code to run against the newly
introduced common workaround framework and fuse the two to use the
existing smarter list add helper, the one which does the sorted insert and
merges registers where possible.
This completes migration of all four classes of workarounds onto the
common framework.
Existing macros are kept untouched for smaller code churn.
v2:
* Rename to list name ctx_wa_list and move from dev_priv to engine.
v3:
* API rename and parameters tweaking. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 +-
drivers/gpu/drm/i915/i915_drv.h | 15 -
drivers/gpu/drm/i915/i915_gem_context.c | 6 +-
drivers/gpu/drm/i915/intel_engine_cs.c | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
drivers/gpu/drm/i915/intel_workarounds.c | 333 +++
drivers/gpu/drm/i915/intel_workarounds.h | 5 +-
9 files changed, 168 insertions(+), 209 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 129b9a6f8309..38dcee1ca062 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3375,13 +3375,15 @@ static int i915_shared_dplls_info(struct seq_file *m,
void *unused)
static int i915_wa_registers(struct seq_file *m, void *unused)
{
- struct i915_workarounds *wa = &node_to_i915(m->private)->workarounds;
- int i;
+ struct drm_i915_private *i915 = node_to_i915(m->private);
+ const struct i915_wa_list *wal = &i915->engine[RCS]->ctx_wa_list;
+ struct i915_wa *wa;
+ unsigned int i;
- seq_printf(m, "Workarounds applied: %d\n", wa->count);
- for (i = 0; i < wa->count; ++i)
+ seq_printf(m, "Workarounds applied: %u\n", wal->count);
+ for (i = 0, wa = wal->list; i < wal->count; i++, wa++)
seq_printf(m, "0x%X: 0x%08X, mask: 0x%08X\n",
- wa->reg[i].addr, wa->reg[i].value, wa->reg[i].mask);
+ i915_mmio_reg_offset(wa->reg), wa->val, wa->mask);
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9ddbcc1f3554..443e08f4736a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1189,20 +1189,6 @@ struct i915_frontbuffer_tracking {
unsigned flip_bits;
};
-struct i915_wa_reg {
- u32 addr;
- u32 value;
- /* bitmask representing WA bits */
- u32 mask;
-};
-
-#define I915_MAX_WA_REGS 16
-
-struct i915_workarounds {
- struct i915_wa_reg reg[I915_MAX_WA_REGS];
- u32 count;
-};
-
struct i915_virtual_gpu {
bool active;
u32 caps;
@@ -1652,7 +1638,6 @@ struct drm_i915_private {
int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
- struct i915_workarounds workarounds;
struct i915_wa_list gt_wa_list;
struct i915_frontbuffer_tracking fb_tracking;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index b97963db0287..371c07087095 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -535,16 +535,12 @@ static bool needs_preempt_context(struct drm_i915_private
*i915)
int i915_gem_contexts_init(struct drm_i915_private *dev_priv)
{
struct i915_gem_context *ctx;
- int ret;
/* Reassure ourselves we are only called once */
GEM_BUG_ON(dev_priv->kernel_context);
GEM_BUG_ON(dev_priv->preempt_context);
- ret = intel_ctx_workarounds_init(dev_priv);
- if (ret)
- return ret;
-
+ intel_engine_init_ctx_wa(dev_priv->engine[RCS]);
init_contexts(dev_priv);
/* lowest priority; idle task */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 496462d77ebc..6b427bc52f78 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -724,6 +724,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs
*engine)
i915_timeline_fini(&engine->timeline);
+ intel_wa_list_free(&engine->ctx_wa_list);
intel_wa_list_free(&engine->wa_list);
intel_wa_list_free(&engine->whitelist);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index af61a3cf9cb8..7de7aa4715fc 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2078,7 +2078,7 @@ static int gen8_init_rcs_context(struct i915_request *rq)
{
int ret;
- ret = intel_ctx_workarounds_emit(rq);
+ ret = intel_engine_emit_ctx_wa(rq);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffe
[Intel-gfx] ✓ Fi.CI.BAT: success for Restore workarounds after engine reset and unify their handling (rev4)
== Series Details ==
Series: Restore workarounds after engine reset and unify their handling (rev4)
URL : https://patchwork.freedesktop.org/series/53313/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5240 -> Patchwork_10998
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53313/revisions/4/mbox/
Known issues
Here are the changes found in Patchwork_10998 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-ivb-3520m: PASS -> FAIL [fdo#108880]
Warnings
* igt@i915_selftest@live_contexts:
- {fi-icl-u3}:INCOMPLETE [fdo#108315] -> DMESG-FAIL [fdo#108569]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108315]: https://bugs.freedesktop.org/show_bug.cgi?id=108315
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108880]: https://bugs.freedesktop.org/show_bug.cgi?id=108880
Participating hosts (47 -> 43)
--
Additional (1): fi-pnv-d510
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600
Build changes
-
* Linux: CI_DRM_5240 -> Patchwork_10998
CI_DRM_5240: bc2afe004b92ad969d5fd89de9ccefbc3fcda688 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4736: 285ebfb3b7adc56586031afa5150c4e5ad40c229 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10998: b6aae830b133fd829597a12caffe760e6c08ff44 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b6aae830b133 drm/i915: Trim unused workaround list entries
dea19ac0666f drm/i915: Fuse per-context workaround handling with the common
framework
5118aae39798 drm/i915: Move register white-listing to the common workaround
framework
5e2506a706bf drm/i915/selftests: Add tests for GT and engine workaround
verification
21f44a8d57a8 drm/i915: Verify GT workaround state after GPU init
a814929884ca drm/i915: Introduce per-engine workarounds
2c7ee2141088 drm/i915: Record GT workarounds in a list
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10998/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/vgpu: Disallow loading on old vGPU hosts
Chris Wilson writes:
> Since commit fd8526e50902 ("drm/i915/execlists: Trust the CSB") we
> actually broke the force-mmio mode for our execlists implementation. No
> one noticed, so ergo no one is actually using an old vGPU host (where we
> required the older method) and so can simply remove the broken support.
>
> v2: csb_read can go as well (Mika)
>
> Reported-by: Mika Kuoppala
> Fixes: fd8526e50902 ("drm/i915/execlists: Trust the CSB")
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> Cc: Mika Kuoppala
> Cc: Daniele Ceraolo Spurio
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_drv.c | 14 +++
> drivers/gpu/drm/i915/intel_lrc.c| 32 +++--
> drivers/gpu/drm/i915/intel_ringbuffer.h | 16 -
> 3 files changed, 22 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e39016713464..3e5e2efce670 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1384,6 +1384,20 @@ static int i915_driver_init_hw(struct drm_i915_private
> *dev_priv)
> }
> }
>
> + if (HAS_EXECLISTS(dev_priv)) {
> + /*
> + * Older GVT emulation depends upon intercepting CSB mmio,
> + * which we no longer use, preferring to use the HWSP cache
> + * instead.
> + */
> + if (intel_vgpu_active(dev_priv) &&
> + !intel_vgpu_has_hwsp_emulation(dev_priv)) {
> + i915_report_error(dev_priv,
> + "old vGPU host found, support for
> HWSP emulation required\n");
> + return -ENXIO;
> + }
> + }
> +
> intel_sanitize_options(dev_priv);
>
> i915_perf_init(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 0a690c557113..bb5abd4f7516 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -748,6 +748,8 @@ execlists_cancel_port_requests(struct
> intel_engine_execlists * const execlists)
>
> static void reset_csb_pointers(struct intel_engine_execlists *execlists)
> {
> + const unsigned int reset_value = GEN8_CSB_ENTRIES - 1;
> +
> /*
>* After a reset, the HW starts writing into CSB entry [0]. We
>* therefore have to set our HEAD pointer back one entry so that
> @@ -757,8 +759,8 @@ static void reset_csb_pointers(struct
> intel_engine_execlists *execlists)
>* inline comparison of our cached head position against the last HW
>* write works even before the first interrupt.
>*/
> - execlists->csb_head = execlists->csb_write_reset;
> - WRITE_ONCE(*execlists->csb_write, execlists->csb_write_reset);
> + execlists->csb_head = reset_value;
> + WRITE_ONCE(*execlists->csb_write, reset_value);
> }
>
> static void nop_submission_tasklet(unsigned long data)
> @@ -2213,12 +2215,6 @@ logical_ring_setup(struct intel_engine_cs *engine)
> logical_ring_default_irqs(engine);
> }
>
> -static bool csb_force_mmio(struct drm_i915_private *i915)
> -{
> - /* Older GVT emulation depends upon intercepting CSB mmio */
> - return intel_vgpu_active(i915) && !intel_vgpu_has_hwsp_emulation(i915);
> -}
> -
> static int logical_ring_init(struct intel_engine_cs *engine)
> {
> struct drm_i915_private *i915 = engine->i915;
> @@ -2248,24 +2244,12 @@ static int logical_ring_init(struct intel_engine_cs
> *engine)
> upper_32_bits(ce->lrc_desc);
> }
>
> - execlists->csb_read =
> - i915->regs +
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine));
> - if (csb_force_mmio(i915)) {
> - execlists->csb_status = (u32 __force *)
> - (i915->regs +
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_BUF_LO(engine, 0)));
> + execlists->csb_status =
> + &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
>
> - execlists->csb_write = (u32 __force *)execlists->csb_read;
> - execlists->csb_write_reset =
> - _MASKED_FIELD(GEN8_CSB_WRITE_PTR_MASK,
> - GEN8_CSB_ENTRIES - 1);
> - } else {
> - execlists->csb_status =
> - &engine->status_page.page_addr[I915_HWS_CSB_BUF0_INDEX];
> + execlists->csb_write =
> + &engine->status_page.page_addr[intel_hws_csb_write_index(i915)];
>
> - execlists->csb_write =
> -
> &engine->status_page.page_addr[intel_hws_csb_write_index(i915)];
> - execlists->csb_write_reset = GEN8_CSB_ENTRIES - 1;
> - }
> reset_csb_pointers(execlists);
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 970fb5c05c36..096043b784f0 100644
> --
Re: [Intel-gfx] [PATCH 1/8] drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate
On 03/12/2018 11:36, Chris Wilson wrote:
Change the on-cpu check to on-runqueue to catch if the waiter has been
woken (and reset its current_state back to TASK_UNINTERRUPTIBLE to
perform the seqno check) but is sleeping due to being preempted off the
cpu.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 84bf8d827136..447c5256f63a 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -27,11 +27,7 @@
#include "i915_drv.h"
-#ifdef CONFIG_SMP
-#define task_asleep(tsk) ((tsk)->state & TASK_NORMAL && !(tsk)->on_cpu)
-#else
-#define task_asleep(tsk) ((tsk)->state & TASK_NORMAL)
-#endif
+#define task_asleep(tsk) ((tsk)->state & TASK_NORMAL && !(tsk)->on_rq)
static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs *b)
{
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v11 00/23] drm/i915/icl: dsi enabling
On Thu, 29 Nov 2018, Jani Nikula wrote: > v11 of [1], incorporating DSI PLL work [2] from Vandita as well as PLL > mapping and gating patches [3] from me and [4] from Imre. > > It made sense to squash some patches in [1] and [2] together, I've tried > to set authorship and co-developed-by tags fairly. > > The series is also available in icl-dsi-2018-11-29 branch of my fdo git > repo [5]. Pushed the series to dinq except for the three HACK patches at the end. They'll still need to be addressed one way or another. Thanks everyone for your contributions in writing the patches, reviewing, testing, etc. It's been a long ride! BR, Jani. > > > BR, > Jani. > > > [1] https://patchwork.freedesktop.org/series/51011/ > [2] https://patchwork.freedesktop.org/series/51373/ > [3] > http://patchwork.freedesktop.org/patch/msgid/20181129115715.9152-1-jani.nik...@intel.com > [4] > http://patchwork.freedesktop.org/patch/msgid/20181127163606.28841-1-imre.d...@intel.com > [5] https://cgit.freedesktop.org/~jani/drm/ > > > Imre Deak (1): > drm/i915/icl: Sanitize DDI port clock gating for DSI ports > > Jani Nikula (4): > drm/i915/icl: push pll to port mapping/unmapping to ddi encoder hooks > drm/i915/icl: add dummy DSI GPIO element execution function > drm/i915/icl: add pll mapping for DSI > HACK: drm/i915/bios: ignore VBT not overflowing the mailbox > > Madhav Chauhan (16): > drm/i915/icl: Calculate DPLL params for DSI > drm/i915/icl: Allocate DSI encoder/connector > drm/i915/icl: Fill DSI ports info > drm/i915/icl: Allocate DSI hosts and imlement host transfer > drm/i915/icl: Get HW state for DSI encoder > drm/i915/icl: Add DSI encoder compute config hook > drm/i915/icl: Configure DSI Dual link mode > drm/i915/icl: Consider DSI for getting transcoder state > drm/i915/icl: Get pipe timings for DSI > drm/i915/icl: Define missing bitfield for shortplug reg > drm/i915/icl: Define Panel power ctrl register > drm/i915/icl: Define display GPIO pins for DSI > drm/i915/icl: Gate clocks for DSI > drm/i915/icl: Ungate DSI clocks > HACK: drm/i915/icl: Add changes to program DSI panel GPIOs > HACK: drm/i915/icl: Configure backlight functions for DSI > > Vandita Kulkarni (2): > drm/i915/icl: Use the same pll functions for dsi > drm/i915/icl: Add get config functionality for DSI > > drivers/gpu/drm/i915/i915_reg.h | 12 + > drivers/gpu/drm/i915/icl_dsi.c| 492 > +- > drivers/gpu/drm/i915/intel_bios.c | 1 - > drivers/gpu/drm/i915/intel_ddi.c | 153 ++- > drivers/gpu/drm/i915/intel_display.c | 44 +-- > drivers/gpu/drm/i915/intel_dpll_mgr.c | 3 +- > drivers/gpu/drm/i915/intel_drv.h | 8 +- > drivers/gpu/drm/i915/intel_dsi.h | 5 + > drivers/gpu/drm/i915/intel_dsi_vbt.c | 58 +++- > drivers/gpu/drm/i915/intel_panel.c| 3 +- > 10 files changed, 674 insertions(+), 105 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: dsi enabling (rev7)
== Series Details ==
Series: drm/i915/icl: dsi enabling (rev7)
URL : https://patchwork.freedesktop.org/series/51011/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5239_full -> Patchwork_10995_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_10995_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10995_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_10995_full:
### IGT changes ###
Possible regressions
* igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels:
- {shard-iclb}: PASS -> DMESG-WARN +28
* igt@kms_flip@plain-flip-fb-recreate-interruptible:
- {shard-iclb}: NOTRUN -> DMESG-WARN
* {igt@runner@aborted}:
- {shard-iclb}: NOTRUN -> ( 35 FAIL ) [fdo#105702]
Warnings
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic:
- {shard-iclb}: FAIL [fdo#107725] -> DMESG-FAIL
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- {shard-iclb}: FAIL [fdo#103166] -> DMESG-WARN
* igt@kms_vblank@pipe-a-wait-busy:
- shard-snb: SKIP -> PASS +1
Known issues
Here are the changes found in Patchwork_10995_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@reset-stress:
- shard-glk: PASS -> FAIL [fdo#107799]
* igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-skl: PASS -> TIMEOUT [fdo#108039]
* igt@gem_userptr_blits@readonly-unsync:
- shard-skl: PASS -> TIMEOUT [fdo#108887]
- shard-kbl: PASS -> TIMEOUT [fdo#108887]
* igt@gem_userptr_blits@stress-mm-invalidate-close-overlap:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-snb: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_color@pipe-a-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-skl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-onscreen:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_fbcon_fbt@psr:
- shard-skl: NOTRUN -> FAIL [fdo#107882]
* igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-hsw: PASS -> FAIL [fdo#102887]
* igt@kms_flip@flip-vs-expired-vblank:
- shard-skl: PASS -> FAIL [fdo#105363]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-glk: PASS -> FAIL [fdo#103167] +2
* igt@kms_frontbuffer_tracking@psr-suspend:
- shard-skl: PASS -> INCOMPLETE [fdo#104108] / [fdo#106978]
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-yf:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-x:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_properties@connector-properties-atomic:
- shard-skl: NOTRUN -> FAIL [fdo#108642]
* igt@pm_backlight@basic-brightness:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724]
Possible fixes
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-glk: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_cursor_crc@cursor-128x128-offscreen:
- shard-skl: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-64x64-onscreen:
- shard-apl: FAIL [fdo#103232] -> PASS +2
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw: FAIL [fdo#105767] -> PASS
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-cpu-untiled:
- shard-skl: FAIL [fdo#103184] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: FAIL [fdo#103167] -> PASS
* igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-glk: FAIL [fdo#103166] -> PASS +2
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl:
Re: [Intel-gfx] [PATCH] drm/i915/icl: push pll to port mapping/unmapping to ddi encoder hooks
On Mon, 03 Dec 2018, Ville Syrjälä wrote:
> On Thu, Nov 29, 2018 at 01:57:15PM +0200, Jani Nikula wrote:
>> Unclutter the haswell_crtc_enable() and haswell_crtc_disable() functions
>> a bit by moving the pll to port mapping and unmapping functions to the
>> ddi encoder hooks. This allows removal of a bunch of boilerplate code
>> from the functions.
>>
>> Additionally, the ICL DSI encoder needs to do the clock gating and
>> ungating slightly differently, and this allows its own handling in a
>> clean fashion.
>>
>> Cc: Madhav Chauhan
>> Cc: Paulo Zanoni
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Thanks, pushed to dinq as part of [1].
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/51011/
>
>> ---
>> drivers/gpu/drm/i915/intel_ddi.c | 84
>> +++-
>> drivers/gpu/drm/i915/intel_display.c | 6 ---
>> drivers/gpu/drm/i915/intel_drv.h | 6 ---
>> 3 files changed, 34 insertions(+), 62 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index ad11540ac436..7bad6c857b81 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -2785,69 +2785,45 @@ uint32_t icl_dpclka_cfgcr0_clk_off(struct
>> drm_i915_private *dev_priv,
>> return 0;
>> }
>>
>> -void icl_map_plls_to_ports(struct drm_crtc *crtc,
>> - struct intel_crtc_state *crtc_state,
>> - struct drm_atomic_state *old_state)
>> +static void icl_map_plls_to_ports(struct intel_encoder *encoder,
>> + const struct intel_crtc_state *crtc_state)
>> {
>> +struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>> struct intel_shared_dpll *pll = crtc_state->shared_dpll;
>> -struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>> -struct drm_connector_state *conn_state;
>> -struct drm_connector *conn;
>> -int i;
>> -
>> -for_each_new_connector_in_state(old_state, conn, conn_state, i) {
>> -struct intel_encoder *encoder =
>> -to_intel_encoder(conn_state->best_encoder);
>> -enum port port;
>> -uint32_t val;
>> -
>> -if (conn_state->crtc != crtc)
>> -continue;
>> -
>> -port = encoder->port;
>> -mutex_lock(&dev_priv->dpll_lock);
>> +enum port port = encoder->port;
>> +u32 val;
>>
>> -val = I915_READ(DPCLKA_CFGCR0_ICL);
>> -WARN_ON((val & icl_dpclka_cfgcr0_clk_off(dev_priv, port)) == 0);
>> +mutex_lock(&dev_priv->dpll_lock);
>>
>> -if (intel_port_is_combophy(dev_priv, port)) {
>> -val &= ~DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
>> -val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, port);
>> -I915_WRITE(DPCLKA_CFGCR0_ICL, val);
>> -POSTING_READ(DPCLKA_CFGCR0_ICL);
>> -}
>> +val = I915_READ(DPCLKA_CFGCR0_ICL);
>> +WARN_ON((val & icl_dpclka_cfgcr0_clk_off(dev_priv, port)) == 0);
>>
>> -val &= ~icl_dpclka_cfgcr0_clk_off(dev_priv, port);
>> +if (intel_port_is_combophy(dev_priv, port)) {
>> +val &= ~DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
>> +val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, port);
>> I915_WRITE(DPCLKA_CFGCR0_ICL, val);
>> -
>> -mutex_unlock(&dev_priv->dpll_lock);
>> +POSTING_READ(DPCLKA_CFGCR0_ICL);
>> }
>> +
>> +val &= ~icl_dpclka_cfgcr0_clk_off(dev_priv, port);
>> +I915_WRITE(DPCLKA_CFGCR0_ICL, val);
>> +
>> +mutex_unlock(&dev_priv->dpll_lock);
>> }
>>
>> -void icl_unmap_plls_to_ports(struct drm_crtc *crtc,
>> - struct intel_crtc_state *crtc_state,
>> - struct drm_atomic_state *old_state)
>> +static void icl_unmap_plls_to_ports(struct intel_encoder *encoder)
>> {
>> -struct drm_i915_private *dev_priv = to_i915(crtc->dev);
>> -struct drm_connector_state *old_conn_state;
>> -struct drm_connector *conn;
>> -int i;
>> +struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>> +enum port port = encoder->port;
>> +u32 val;
>>
>> -for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
>> -struct intel_encoder *encoder =
>> -to_intel_encoder(old_conn_state->best_encoder);
>> -enum port port;
>> +mutex_lock(&dev_priv->dpll_lock);
>>
>> -if (old_conn_state->crtc != crtc)
>> -continue;
>> +val = I915_READ(DPCLKA_CFGCR0_ICL);
>> +val |= icl_dpclka_cfgcr0_clk_off(dev_priv, port);
>> +I915_WRITE(DPCLKA_CFGCR0_ICL, val);
>>
>> -port = encoder->port;
>> -mutex_lock(&dev_priv->dpll_lock);
>> -I915_WRITE(DPCLKA_CFGCR0_ICL,
>> - I915_READ(DPCLKA_CFGCR0_ICL) |
>> -
Re: [Intel-gfx] [PATCH] drm/i915/icl: Sanitize DDI port clock gating for DSI ports
On Thu, 29 Nov 2018, Jani Nikula wrote:
> On Tue, 27 Nov 2018, Imre Deak wrote:
>> The requirement for the DDI port clock gating for a port in DSI mode is
>> the opposite wrt. the case when the port is in DDI mode: the clock
>> should be gated when the port is active and ungated when the port is
>> inactive. Note that we cannot simply keep the DDI clock gated when the
>> port will be only used in DSI mode: it must be gated/ungated at a
>> specific spot in the DSI enable/disable sequence.
>>
>> Ensure the above for all ports of a DSI encoder, also adding a sanity
>> check that we haven't registered another encoder using the same port
>> (VBT should never allow this to happen).
>>
>> Cc: Madhav Chauhan
>> Cc: Vandita Kulkarni
>> Cc: Jani Nikula
>> Cc: Ville Syrjälä
>> Cc: Clint Taylor
>> Signed-off-by: Imre Deak
>
> Reviewed-by: Jani Nikula
Thanks for the patch, pushed to dinq as part of [1].
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/51011/
>
>> ---
>> drivers/gpu/drm/i915/intel_ddi.c | 65
>> +---
>> drivers/gpu/drm/i915/intel_dsi.h | 5
>> 2 files changed, 53 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index ad11540ac436..6d032a6be16c 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -28,6 +28,7 @@
>> #include
>> #include "i915_drv.h"
>> #include "intel_drv.h"
>> +#include "intel_dsi.h"
>>
>> struct ddi_buf_trans {
>> u32 trans1; /* balance leg enable, de-emph level */
>> @@ -2854,8 +2855,9 @@ void icl_sanitize_encoder_pll_mapping(struct
>> intel_encoder *encoder)
>> {
>> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>> u32 val;
>> -enum port port = encoder->port;
>> -bool clk_enabled;
>> +enum port port;
>> +u32 port_mask;
>> +bool ddi_clk_needed;
>>
>> /*
>> * In case of DP MST, we sanitize the primary encoder only, not the
>> @@ -2864,9 +2866,6 @@ void icl_sanitize_encoder_pll_mapping(struct
>> intel_encoder *encoder)
>> if (encoder->type == INTEL_OUTPUT_DP_MST)
>> return;
>>
>> -val = I915_READ(DPCLKA_CFGCR0_ICL);
>> -clk_enabled = !(val & icl_dpclka_cfgcr0_clk_off(dev_priv, port));
>> -
>> if (!encoder->base.crtc && intel_encoder_is_dp(encoder)) {
>> u8 pipe_mask;
>> bool is_mst;
>> @@ -2880,20 +2879,52 @@ void icl_sanitize_encoder_pll_mapping(struct
>> intel_encoder *encoder)
>> return;
>> }
>>
>> -if (clk_enabled == !!encoder->base.crtc)
>> -return;
>> +port_mask = BIT(encoder->port);
>> +ddi_clk_needed = encoder->base.crtc;
>>
>> -/*
>> - * Punt on the case now where clock is disabled, but the encoder is
>> - * enabled, something else is really broken then.
>> - */
>> -if (WARN_ON(!clk_enabled))
>> -return;
>> +if (encoder->type == INTEL_OUTPUT_DSI) {
>> +struct intel_encoder *other_encoder;
>>
>> -DRM_NOTE("Port %c is disabled but it has a mapped PLL, unmap it\n",
>> - port_name(port));
>> -val |= icl_dpclka_cfgcr0_clk_off(dev_priv, port);
>> -I915_WRITE(DPCLKA_CFGCR0_ICL, val);
>> +port_mask = intel_dsi_encoder_ports(encoder);
>> +/*
>> + * Sanity check that we haven't incorrectly registered another
>> + * encoder using any of the ports of this DSI encoder.
>> + */
>> +for_each_intel_encoder(&dev_priv->drm, other_encoder) {
>> +if (other_encoder == encoder)
>> +continue;
>> +
>> +if (WARN_ON(port_mask & BIT(other_encoder->port)))
>> +return;
>> +}
>> +/*
>> + * DSI ports should have their DDI clock ungated when disabled
>> + * and gated when enabled.
>> + */
>> +ddi_clk_needed = !encoder->base.crtc;
>> +}
>> +
>> +val = I915_READ(DPCLKA_CFGCR0_ICL);
>> +for_each_port_masked(port, port_mask) {
>> +bool ddi_clk_ungated = !(val &
>> + icl_dpclka_cfgcr0_clk_off(dev_priv,
>> + port));
>> +
>> +if (ddi_clk_needed == ddi_clk_ungated)
>> +continue;
>> +
>> +/*
>> + * Punt on the case now where clock is gated, but it would
>> + * be needed by the port. Something else is really broken then.
>> + */
>> +if (WARN_ON(ddi_clk_needed))
>> +continue;
>> +
>> +DRM_NOTE("Port %c is disabled/in DSI mode with an ungated DDI
>> clock, gate it\n",
>> + port_name(port));
>> +val |= icl_dpclka_cfgcr0_clk_off(dev_priv, port);
>> +I915_WRITE(
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Fix GEN9 HDCP1.4 key load process
On Tue, Nov 27, 2018 at 07:32:56PM +0530, Ramalingam C wrote:
> HDCP1.4 key load process varies between Intel platform to platform.
>
> For Gen9 platforms except BXT and GLK, HDCP1.4 key is loaded using
> the GT Driver Mailbox interface. Instead of listing all the platforms
> for this method, adopted this method for all Gen9 platforms with
> exceptions. In this way we need not extent check for new GEN9 platforms
> like CFL.
>
> Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 1bf487f94254..beacfbb6e5e1 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -157,10 +157,12 @@ static int intel_hdcp_load_keys(struct drm_i915_private
> *dev_priv)
> /*
>* Initiate loading the HDCP key from fuses.
>*
> - * BXT+ platforms, HDCP key needs to be loaded by SW. Only SKL and KBL
> - * differ in the key load trigger process from other platforms.
> + * BXT+ platforms, HDCP key needs to be loaded by SW. Only Gen 9
> + * platforms except BXT and GLK, differ in the key load trigger process
> + * from other platforms.
>*/
> - if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
> + if (IS_GEN9(dev_priv) &&
> + (!IS_BROXTON(dev_priv) && !IS_GEMINILAKE(dev_priv))) {
> mutex_lock(&dev_priv->pcu_lock);
> ret = sandybridge_pcode_write(dev_priv,
> SKL_PCODE_LOAD_HDCP_KEYS, 1);
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Fix platform coverage for HDCP1.4
On Tue, Nov 27, 2018 at 07:32:57PM +0530, Ramalingam C wrote:
> HDCP1.4 is enabled and validated only on GEN9+ platforms.
>
> Signed-off-by: Ramalingam C
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index beacfbb6e5e1..bd60d0e7bbfa 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -770,8 +770,7 @@ static void intel_hdcp_prop_work(struct work_struct *work)
> bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port)
> {
> /* PORT E doesn't have HDCP, and PORT F is disabled */
> - return ((INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) &&
> - !IS_CHERRYVIEW(dev_priv) && port < PORT_E);
> + return ((INTEL_GEN(dev_priv) >= 9) && port < PORT_E);
> }
>
> int intel_hdcp_init(struct intel_connector *connector,
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: debug log for REPLY_ACK missing
On Tue, Nov 27, 2018 at 07:32:58PM +0530, Ramalingam C wrote:
> Adding a debug log when the DP_AUX_NATIVE_REPLY_ACK is missing
> for aksv write. This helps to locate the possible non responding
> DP HDCP sinks.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_dp.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 70ae3d57316b..18e3a5a3d873 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5390,7 +5390,11 @@ int intel_dp_hdcp_write_an_aksv(struct
> intel_digital_port *intel_dig_port,
> }
>
> reply = (rxbuf[0] >> 4) & DP_AUX_NATIVE_REPLY_MASK;
> - return reply == DP_AUX_NATIVE_REPLY_ACK ? 0 : -EIO;
> + ret = reply == DP_AUX_NATIVE_REPLY_ACK ? 0 : -EIO;
> + if (ret)
> + DRM_DEBUG_KMS("Aksv write: DP_AUX_NATIVE_REPLY_ACK missing\n");
This is pretty hard to read. Could you please change to:
if (reply != DP_AUX_NATIVE_REPLY_ACK) {
DRM_DEBUG_KMS("Aksv write: no DP_AUX_NATIVE_REPLY_ACK %x\n",
reply);
return -EIO
}
return 0;
With this change,
Reviewed-by: Sean Paul
> +
> + return ret;
> }
>
> static int intel_dp_hdcp_read_bksv(struct intel_digital_port *intel_dig_port,
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Increase timeout for Encrypt status change
On Tue, Nov 27, 2018 at 07:32:59PM +0530, Ramalingam C wrote:
> At enable/disable of the HDCP encryption, for encryption status change
> we need minimum one frame duration. And we might program this bit any
> point(start/End) in the previous frame.
>
> With 20mSec, observed the timeout for change in encryption status.
> Since this is not time critical operation and we need to hold on
> until the status is changed, fixing the timeout to 50mSec. (Based on
> trial and error method!)
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index bd60d0e7bbfa..156b14d19e09 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -15,6 +15,7 @@
> #include "i915_reg.h"
>
> #define KEY_LOAD_TRIES 5
> +#define TIME_FOR_ENCRYPT_STATUS_CHANGE 50
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS please
with that fixed,
Reviewed-by: Sean Paul
>
> static
> bool intel_hdcp_is_ksv_valid(u8 *ksv)
> @@ -638,7 +639,8 @@ static int intel_hdcp_auth(struct intel_digital_port
> *intel_dig_port,
>
> /* Wait for encryption confirmation */
> if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port),
> - HDCP_STATUS_ENC, HDCP_STATUS_ENC, 20)) {
> + HDCP_STATUS_ENC, HDCP_STATUS_ENC,
> + TIME_FOR_ENCRYPT_STATUS_CHANGE)) {
> DRM_ERROR("Timed out waiting for encryption\n");
> return -ETIMEDOUT;
> }
> @@ -668,7 +670,7 @@ static int _intel_hdcp_disable(struct intel_connector
> *connector)
>
> I915_WRITE(PORT_HDCP_CONF(port), 0);
> if (intel_wait_for_register(dev_priv, PORT_HDCP_STATUS(port), ~0, 0,
> - 20)) {
> + TIME_FOR_ENCRYPT_STATUS_CHANGE)) {
> DRM_ERROR("Failed to disable HDCP, timeout clearing status\n");
> return -ETIMEDOUT;
> }
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Restore workarounds after engine reset and unify their handling (rev7)
== Series Details ==
Series: Restore workarounds after engine reset and unify their handling (rev7)
URL : https://patchwork.freedesktop.org/series/53313/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0d8922bbcea9 drm/i915: Record GT workarounds in a list
5f4bdd949a82 drm/i915: Introduce per-engine workarounds
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 59b449d5c82a ("drm/i915: Split
out functions for different kinds of workarounds")'
#10:
59b449d5c82a ("drm/i915: Split out functions for different kinds of
total: 1 errors, 0 warnings, 0 checks, 389 lines checked
a5adea0e9978 drm/i915: Verify GT workaround state after GPU init
c872addcf55b drm/i915/selftests: Add tests for GT and engine workaround
verification
-:59: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#59:
new file mode 100644
-:64: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#64: FILE: drivers/gpu/drm/i915/selftests/igt_reset.c:1:
+/*
-:114: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#114: FILE: drivers/gpu/drm/i915/selftests/igt_reset.h:1:
+/*
total: 0 errors, 3 warnings, 0 checks, 363 lines checked
bc8c485122bc drm/i915: Move register white-listing to the common workaround
framework
d0c549c8e91b drm/i915: Fuse per-context workaround handling with the common
framework
c66049dd5e5b drm/i915: Trim unused workaround list entries
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Restore workarounds after engine reset and unify their handling (rev7)
== Series Details == Series: Restore workarounds after engine reset and unify their handling (rev7) URL : https://patchwork.freedesktop.org/series/53313/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Record GT workarounds in a list -drivers/gpu/drm/i915/selftests/../i915_drv.h:3571:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3573:16: warning: expression using sizeof(void) +./include/linux/slab.h:665:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/slab.h:665:13: warning: call with no type! Commit: drm/i915: Introduce per-engine workarounds Okay! Commit: drm/i915: Verify GT workaround state after GPU init Okay! Commit: drm/i915/selftests: Add tests for GT and engine workaround verification +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) Commit: drm/i915: Move register white-listing to the common workaround framework Okay! Commit: drm/i915: Fuse per-context workaround handling with the common framework -drivers/gpu/drm/i915/selftests/../i915_drv.h:3573:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3558:16: warning: expression using sizeof(void) Commit: drm/i915: Trim unused workaround list entries Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Restore workarounds after engine reset and unify their handling (rev7)
== Series Details == Series: Restore workarounds after engine reset and unify their handling (rev7) URL : https://patchwork.freedesktop.org/series/53313/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5243 -> Patchwork_10999 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_10999 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10999, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/53313/revisions/7/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_10999: ### IGT changes ### Possible regressions * igt@i915_selftest@live_hangcheck: - fi-bsw-kefka: PASS -> DMESG-FAIL Known issues Here are the changes found in Patchwork_10999 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - fi-ivb-3520m: PASS -> FAIL [fdo#108880] * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - fi-cfl-8109u: PASS -> INCOMPLETE [fdo#106070] / [fdo#108126] [fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070 [fdo#108126]: https://bugs.freedesktop.org/show_bug.cgi?id=108126 [fdo#108880]: https://bugs.freedesktop.org/show_bug.cgi?id=108880 Participating hosts (47 -> 42) -- Additional (1): fi-apl-guc Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 Build changes - * Linux: CI_DRM_5243 -> Patchwork_10999 CI_DRM_5243: 30124676e6a86dcb2271b10357331e09c4c75448 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4736: 285ebfb3b7adc56586031afa5150c4e5ad40c229 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10999: c66049dd5e5babefedb9b68630f9e6e7b9ce947e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c66049dd5e5b drm/i915: Trim unused workaround list entries d0c549c8e91b drm/i915: Fuse per-context workaround handling with the common framework bc8c485122bc drm/i915: Move register white-listing to the common workaround framework c872addcf55b drm/i915/selftests: Add tests for GT and engine workaround verification a5adea0e9978 drm/i915: Verify GT workaround state after GPU init 5f4bdd949a82 drm/i915: Introduce per-engine workarounds 0d8922bbcea9 drm/i915: Record GT workarounds in a list == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10999/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/8] drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate
== Series Details ==
Series: series starting with [1/8] drm/i915/breadcrumbs: Reduce
missed-breadcrumb false positive rate
URL : https://patchwork.freedesktop.org/series/53396/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5239_full -> Patchwork_10996_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_10996_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10996_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_10996_full:
### IGT changes ###
Warnings
* igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-snb: PASS -> SKIP
* igt@kms_vblank@pipe-a-wait-busy:
- shard-snb: SKIP -> PASS +2
Known issues
Here are the changes found in Patchwork_10996_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-skl: PASS -> TIMEOUT [fdo#108039]
* igt@gem_userptr_blits@readonly-unsync:
- shard-skl: PASS -> TIMEOUT [fdo#108887]
* igt@kms_atomic_transition@plane-toggle-modeset-transition:
- {shard-iclb}: NOTRUN -> DMESG-WARN [fdo#107724] +8
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-snb: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_chv_cursor_fail@pipe-a-128x128-top-edge:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] / [fdo#108336] +1
* igt@kms_color@pipe-a-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-skl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x21-random:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-xtiled:
- {shard-iclb}: NOTRUN -> WARN [fdo#108336]
* igt@kms_fbcon_fbt@psr:
- shard-skl: NOTRUN -> FAIL [fdo#107882]
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: PASS -> FAIL [fdo#105363]
* igt@kms_flip@modeset-vs-vblank-race-interruptible:
- shard-glk: PASS -> FAIL [fdo#103060]
* igt@kms_flip@wf_vblank-ts-check-interruptible:
- shard-skl: NOTRUN -> FAIL [fdo#100368]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen:
- shard-glk: PASS -> FAIL [fdo#103167] +2
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-gtt:
- {shard-iclb}: NOTRUN -> DMESG-FAIL [fdo#107724] +1
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-pwrite:
- {shard-iclb}: PASS -> FAIL [fdo#103167] +3
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: PASS -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- {shard-iclb}: NOTRUN -> DMESG-WARN [fdo#107724] / [fdo#108336] +3
* igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- {shard-iclb}: PASS -> DMESG-FAIL [fdo#107724] +2
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-yf:
- shard-glk: PASS -> FAIL [fdo#103166]
- shard-apl: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_multiple@atomic-pipe-c-tiling-x:
- {shard-iclb}: PASS -> FAIL [fdo#103166]
* igt@kms_properties@connector-properties-atomic:
- shard-skl: NOTRUN -> FAIL [fdo#108642]
* igt@kms_psr@no_drrs:
- {shard-iclb}: PASS -> FAIL [fdo#108341]
* igt@pm_rpm@reg-read-ioctl:
- {shard-iclb}: PASS -> DMESG-WARN [fdo#107724] +11
Possible fixes
* igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-kbl: INCOMPLETE [fdo#103665] / [fdo#106023] / [fdo#106887]
-> PASS
* igt@kms_busy@extended-modeset-hang-newfb-render-a:
- shard-snb: DMESG-WARN [fdo#107956] -> SKIP
* igt@kms_busy@extended-modeset-hang-newfb-render-c:
- {shard-iclb}: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
- shard-glk: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_cursor_crc@cursor-128x128-offscreen:
- shard-skl:
Re: [Intel-gfx] [PATCH 4/8] drm/i915: Allocate a common scratch page
Chris Wilson writes:
> Currently we allocate a scratch page for each engine, but since we only
> ever write into it for post-sync operations, it is not exposed to
> userspace nor do we care for coherency. As we then do not care about its
> contents, we can use one page for all, reducing our allocations and
> avoid complications by not assuming per-engine isolation.
>
> For later use, it simplifies engine initialisation (by removing the
> allocation that required struct_mutex!) and means that we can always rely
> on there being a scratch page.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_drv.h | 7
> drivers/gpu/drm/i915/i915_gem.c | 50 -
> drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
> drivers/gpu/drm/i915/intel_engine_cs.c | 42 -
> drivers/gpu/drm/i915/intel_lrc.c| 17 +++--
> drivers/gpu/drm/i915/intel_ringbuffer.c | 33 +---
> drivers/gpu/drm/i915/intel_ringbuffer.h | 5 ---
> 7 files changed, 71 insertions(+), 85 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d45475287130..0ec65cc48b5a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1996,6 +1996,8 @@ struct drm_i915_private {
> struct delayed_work idle_work;
>
> ktime_t last_init_time;
> +
> + struct i915_vma *scratch;
> } gt;
>
> /* perform PHY state sanity checks? */
> @@ -3724,4 +3726,9 @@ static inline int intel_hws_csb_write_index(struct
> drm_i915_private *i915)
> return I915_HWS_CSB_WRITE_INDEX;
> }
>
> +static inline u32 i915_scratch_offset(const struct drm_i915_private *i915)
> +{
> + return i915_ggtt_offset(i915->gt.scratch);
> +}
> +
> #endif
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 834240a9b262..cca4285e3329 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5495,6 +5495,44 @@ static int __intel_engines_record_defaults(struct
> drm_i915_private *i915)
> goto out_ctx;
> }
>
> +static int
> +i915_gem_init_scratch(struct drm_i915_private *i915, unsigned int size)
> +{
> + struct drm_i915_gem_object *obj;
> + struct i915_vma *vma;
> + int ret;
> +
> + obj = i915_gem_object_create_stolen(i915, size);
> + if (!obj)
> + obj = i915_gem_object_create_internal(i915, size);
> + if (IS_ERR(obj)) {
> + DRM_ERROR("Failed to allocate scratch page\n");
> + return PTR_ERR(obj);
> + }
> +
> + vma = i915_vma_instance(obj, &i915->ggtt.vm, NULL);
> + if (IS_ERR(vma)) {
> + ret = PTR_ERR(vma);
> + goto err_unref;
> + }
> +
> + ret = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
> + if (ret)
> + goto err_unref;
> +
> + i915->gt.scratch = vma;
> + return 0;
> +
> +err_unref:
> + i915_gem_object_put(obj);
> + return ret;
> +}
> +
> +static void i915_gem_fini_scratch(struct drm_i915_private *i915)
> +{
> + i915_vma_unpin_and_release(&i915->gt.scratch, 0);
> +}
> +
> int i915_gem_init(struct drm_i915_private *dev_priv)
> {
> int ret;
> @@ -5541,12 +5579,19 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
> goto err_unlock;
> }
>
> - ret = i915_gem_contexts_init(dev_priv);
> + ret = i915_gem_init_scratch(dev_priv,
> + IS_GEN2(dev_priv) ? SZ_256K : PAGE_SIZE);
> if (ret) {
> GEM_BUG_ON(ret == -EIO);
> goto err_ggtt;
> }
>
> + ret = i915_gem_contexts_init(dev_priv);
> + if (ret) {
> + GEM_BUG_ON(ret == -EIO);
> + goto err_scratch;
> + }
> +
> ret = intel_engines_init(dev_priv);
> if (ret) {
> GEM_BUG_ON(ret == -EIO);
> @@ -5619,6 +5664,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
> err_context:
> if (ret != -EIO)
> i915_gem_contexts_fini(dev_priv);
> +err_scratch:
> + i915_gem_fini_scratch(dev_priv);
> err_ggtt:
> err_unlock:
> intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> @@ -5670,6 +5717,7 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
> intel_uc_fini(dev_priv);
> i915_gem_cleanup_engines(dev_priv);
> i915_gem_contexts_fini(dev_priv);
> + i915_gem_fini_scratch(dev_priv);
> mutex_unlock(&dev_priv->drm.struct_mutex);
>
> intel_cleanup_gt_powersave(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index a6885a59568b..07465123c166 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1571,7 +1571,7 @@ static void gem_record_rings(struct i915_gpu_state
> *error)
> if (HAS_BROKEN_CS_TLB(i915))
>
Re: [Intel-gfx] [PATCH v2] drm/i915/vgpu: Disallow loading on old vGPU hosts
Quoting Mika Kuoppala (2018-12-03 13:40:26)
> Chris Wilson writes:
>
> > Since commit fd8526e50902 ("drm/i915/execlists: Trust the CSB") we
> > actually broke the force-mmio mode for our execlists implementation. No
> > one noticed, so ergo no one is actually using an old vGPU host (where we
> > required the older method) and so can simply remove the broken support.
> >
> > v2: csb_read can go as well (Mika)
> >
> > Reported-by: Mika Kuoppala
> > Fixes: fd8526e50902 ("drm/i915/execlists: Trust the CSB")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: Joonas Lahtinen
> > Cc: Mika Kuoppala
> > Cc: Daniele Ceraolo Spurio
>
> Reviewed-by: Mika Kuoppala
Pushed, thanks. That should make your extended CSB patches for icl that
much more straightforward, right?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/vgpu: Disallow loading on old vGPU hosts
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-12-03 13:40:26)
>> Chris Wilson writes:
>>
>> > Since commit fd8526e50902 ("drm/i915/execlists: Trust the CSB") we
>> > actually broke the force-mmio mode for our execlists implementation. No
>> > one noticed, so ergo no one is actually using an old vGPU host (where we
>> > required the older method) and so can simply remove the broken support.
>> >
>> > v2: csb_read can go as well (Mika)
>> >
>> > Reported-by: Mika Kuoppala
>> > Fixes: fd8526e50902 ("drm/i915/execlists: Trust the CSB")
>> > Signed-off-by: Chris Wilson
>> > Cc: Tvrtko Ursulin
>> > Cc: Joonas Lahtinen
>> > Cc: Mika Kuoppala
>> > Cc: Daniele Ceraolo Spurio
>>
>> Reviewed-by: Mika Kuoppala
>
> Pushed, thanks. That should make your extended CSB patches for icl that
> much more straightforward, right?
Very much so. Now just have to figure out how to make the
cpu/gpu dance together. The extended CSB is not enough
by itself :(
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/8] drm/i915: Allocate a common scratch page
Quoting Mika Kuoppala (2018-12-03 15:28:22) > Chris Wilson writes: > > > Currently we allocate a scratch page for each engine, but since we only > > ever write into it for post-sync operations, it is not exposed to > > userspace nor do we care for coherency. As we then do not care about its > > contents, we can use one page for all, reducing our allocations and > > avoid complications by not assuming per-engine isolation. > > > > For later use, it simplifies engine initialisation (by removing the > > allocation that required struct_mutex!) and means that we can always rely > > on there being a scratch page. > > > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > --- > > - ret = i915_gem_contexts_init(dev_priv); > > + ret = i915_gem_init_scratch(dev_priv, > > + IS_GEN2(dev_priv) ? SZ_256K : PAGE_SIZE); > > @@ -1484,21 +1478,12 @@ static int intel_init_ring_buffer(struct > > intel_engine_cs *engine) > > GEM_BUG_ON(engine->buffer); > > engine->buffer = ring; > > > > - size = PAGE_SIZE; > > - if (HAS_BROKEN_CS_TLB(engine->i915)) > > - size = I830_WA_SIZE; > > Hmm, this disappeared. I don't know this wa details > but apparently we do need 2 pages for this kind of > machines. 2 pages? More like 64 pages. See above. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/8] drm/i915: Complete the fences as they are cancelled due to wedging
On 03/12/2018 11:36, Chris Wilson wrote: We inspect the requests under the assumption that they will be marked as completed when they are removed from the queue. Currently however, in the process of wedging the requests will be removed from the queue before they are completed, so rearrange the code to complete the fences before the locks are dropped. <1>[ 354.473346] BUG: unable to handle kernel NULL pointer dereference at 0250 <6>[ 354.473363] PGD 0 P4D 0 <4>[ 354.473370] Oops: [#1] PREEMPT SMP PTI <4>[ 354.473380] CPU: 0 PID: 4470 Comm: gem_eio Tainted: G U 4.20.0-rc4-CI-CI_DRM_5216+ #1 <4>[ 354.473393] Hardware name: Intel Corporation NUC7CJYH/NUC7JYB, BIOS JYGLKCPX.86A.0027.2018.0125.1347 01/25/2018 <4>[ 354.473480] RIP: 0010:__i915_schedule+0x311/0x5e0 [i915] <4>[ 354.473490] Code: 49 89 44 24 20 4d 89 4c 24 28 4d 89 29 44 39 b3 a0 04 00 00 7d 3a 41 8b 44 24 78 85 c0 74 13 48 8b 93 78 04 00 00 48 83 e2 fc <39> 82 50 02 00 00 79 1e 44 89 b3 a0 04 00 00 48 8d bb d0 03 00 00 This confuses me, isn't the code segment usually at the end? And then you have another after the call trace which doesn't match __i915_scheduel.. anyways, _this_ code seems to be this part: if (node_to_request(node)->global_seqno && 90d: 8b 43 78moveax,DWORD PTR [rbx+0x78] 910: 85 c0 test eax,eax 912: 74 13 je 927 <__i915_schedule+0x317> i915_seqno_passed(port_request(engine->execlists.port)->global_seqno, 914: 49 8b 97 c0 04 00 00movrdx,QWORD PTR [r15+0x4c0] 91b: 48 83 e2 fc andrdx,0xfffc if (node_to_request(node)->global_seqno && 91f: 39 82 50 02 00 00 cmpDWORD PTR [rdx+0x250],eax 925: 79 1e jns945 <__i915_schedule+0x335> <4>[ 354.473515] RSP: 0018:c91bba90 EFLAGS: 00010046 <4>[ 354.473524] RAX: 0003 RBX: 8882624c8008 RCX: f34a7378 <4>[ 354.473535] RDX: RSI: RDI: 8882624c8048 <4>[ 354.473545] RBP: c91bbab0 R08: 5963f1f1 R09: <4>[ 354.473556] R10: c91bba10 R11: 8882624c8060 R12: 88824fdd7b98 <4>[ 354.473567] R13: 88824fdd7bb8 R14: 0001 R15: 88824fdd7750 <4>[ 354.473578] FS: 7f44b4b5b980() GS:888277e0() knlGS: <4>[ 354.473590] CS: 0010 DS: ES: CR0: 80050033 <4>[ 354.473599] CR2: 0250 CR3: 00026976e000 CR4: 00340ef0 Given the registers above, I think it means this - eax is global_seqno of the node rq. rdx is is port_request so NULL and bang. No request in port, but why would there always be one at the point we are scheduling in a new request to the runnable queue? Regards, Tvrtko <4>[ 354.473611] Call Trace: <4>[ 354.473622] ? lock_acquire+0xa6/0x1c0 <4>[ 354.473677] ? i915_schedule_bump_priority+0x57/0xd0 [i915] <4>[ 354.473736] i915_schedule_bump_priority+0x72/0xd0 [i915] <4>[ 354.473792] i915_request_wait+0x4db/0x840 [i915] <4>[ 354.473804] ? get_pwq.isra.4+0x2c/0x50 <4>[ 354.473813] ? ___preempt_schedule+0x16/0x18 <4>[ 354.473824] ? wake_up_q+0x70/0x70 <4>[ 354.473831] ? wake_up_q+0x70/0x70 <4>[ 354.473882] ? gen6_rps_boost+0x118/0x120 [i915] <4>[ 354.473936] i915_gem_object_wait_fence+0x8a/0x110 [i915] <4>[ 354.473991] i915_gem_object_wait+0x113/0x500 [i915] <4>[ 354.474047] i915_gem_wait_ioctl+0x11c/0x2f0 [i915] <4>[ 354.474101] ? i915_gem_unset_wedged+0x210/0x210 [i915] <4>[ 354.474113] drm_ioctl_kernel+0x81/0xf0 <4>[ 354.474123] drm_ioctl+0x2de/0x390 <4>[ 354.474175] ? i915_gem_unset_wedged+0x210/0x210 [i915] <4>[ 354.474187] ? finish_task_switch+0x95/0x260 <4>[ 354.474197] ? lock_acquire+0xa6/0x1c0 <4>[ 354.474207] do_vfs_ioctl+0xa0/0x6e0 <4>[ 354.474217] ? __fget+0xfc/0x1e0 <4>[ 354.474225] ksys_ioctl+0x35/0x60 <4>[ 354.474233] __x64_sys_ioctl+0x11/0x20 <4>[ 354.474241] do_syscall_64+0x55/0x190 <4>[ 354.474251] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 354.474260] RIP: 0033:0x7f44b3de65d7 <4>[ 354.474267] Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48 <4>[ 354.474293] RSP: 002b:7fff974948e8 EFLAGS: 0246 ORIG_RAX: 0010 <4>[ 354.474305] RAX: ffda RBX: RCX: 7f44b3de65d7 <4>[ 354.474316] RDX: 7fff97494940 RSI: c010646c RDI: 0007 <4>[ 354.474327] RBP: 7fff97494940 R08: R09: 7f44b40bbc40 <4>[ 354.474337] R10: R11: 0246 R12: c010646c <4>[ 354.474348] R13: 0007 R14: R15: v2: Avoid floating requests. v3: Can't call dma_fence_signal() under the timeline lock!
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Restore workarounds after engine reset and unify their handling (rev8)
== Series Details ==
Series: Restore workarounds after engine reset and unify their handling (rev8)
URL : https://patchwork.freedesktop.org/series/53313/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e2c45229710e drm/i915: Record GT workarounds in a list
68a4800dce59 drm/i915: Introduce per-engine workarounds
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 59b449d5c82a ("drm/i915: Split
out functions for different kinds of workarounds")'
#10:
59b449d5c82a ("drm/i915: Split out functions for different kinds of
total: 1 errors, 0 warnings, 0 checks, 389 lines checked
b48dab8be432 drm/i915: Verify GT workaround state after GPU init
5eb7b5ed728b drm/i915/selftests: Add tests for GT and engine workaround
verification
-:59: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#59:
new file mode 100644
-:64: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#64: FILE: drivers/gpu/drm/i915/selftests/igt_reset.c:1:
+/*
-:114: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#114: FILE: drivers/gpu/drm/i915/selftests/igt_reset.h:1:
+/*
total: 0 errors, 3 warnings, 0 checks, 363 lines checked
6997332fc8d8 drm/i915: Move register white-listing to the common workaround
framework
3a2e4194081e drm/i915: Fuse per-context workaround handling with the common
framework
d4c5c1e46f44 drm/i915: Trim unused workaround list entries
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Restore workarounds after engine reset and unify their handling (rev8)
== Series Details == Series: Restore workarounds after engine reset and unify their handling (rev8) URL : https://patchwork.freedesktop.org/series/53313/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Record GT workarounds in a list -drivers/gpu/drm/i915/selftests/../i915_drv.h:3571:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3573:16: warning: expression using sizeof(void) +./include/linux/slab.h:665:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/slab.h:665:13: warning: call with no type! Commit: drm/i915: Introduce per-engine workarounds Okay! Commit: drm/i915: Verify GT workaround state after GPU init Okay! Commit: drm/i915/selftests: Add tests for GT and engine workaround verification +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) Commit: drm/i915: Move register white-listing to the common workaround framework Okay! Commit: drm/i915: Fuse per-context workaround handling with the common framework -drivers/gpu/drm/i915/selftests/../i915_drv.h:3573:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3558:16: warning: expression using sizeof(void) Commit: drm/i915: Trim unused workaround list entries Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Allocate a common scratch page
Currently we allocate a scratch page for each engine, but since we only
ever write into it for post-sync operations, it is not exposed to
userspace nor do we care for coherency. As we then do not care about its
contents, we can use one page for all, reducing our allocations and
avoid complications by not assuming per-engine isolation.
For later use, it simplifies engine initialisation (by removing the
allocation that required struct_mutex!) and means that we can always rely
on there being a scratch page.
v2: Check that we allocated a large enough scratch for I830 w/a
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 7
drivers/gpu/drm/i915/i915_gem.c | 50 -
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/intel_engine_cs.c | 42 -
drivers/gpu/drm/i915/intel_lrc.c| 17 +++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 37 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 5 ---
7 files changed, 74 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d45475287130..0ec65cc48b5a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1996,6 +1996,8 @@ struct drm_i915_private {
struct delayed_work idle_work;
ktime_t last_init_time;
+
+ struct i915_vma *scratch;
} gt;
/* perform PHY state sanity checks? */
@@ -3724,4 +3726,9 @@ static inline int intel_hws_csb_write_index(struct
drm_i915_private *i915)
return I915_HWS_CSB_WRITE_INDEX;
}
+static inline u32 i915_scratch_offset(const struct drm_i915_private *i915)
+{
+ return i915_ggtt_offset(i915->gt.scratch);
+}
+
#endif
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 834240a9b262..cca4285e3329 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5495,6 +5495,44 @@ static int __intel_engines_record_defaults(struct
drm_i915_private *i915)
goto out_ctx;
}
+static int
+i915_gem_init_scratch(struct drm_i915_private *i915, unsigned int size)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ int ret;
+
+ obj = i915_gem_object_create_stolen(i915, size);
+ if (!obj)
+ obj = i915_gem_object_create_internal(i915, size);
+ if (IS_ERR(obj)) {
+ DRM_ERROR("Failed to allocate scratch page\n");
+ return PTR_ERR(obj);
+ }
+
+ vma = i915_vma_instance(obj, &i915->ggtt.vm, NULL);
+ if (IS_ERR(vma)) {
+ ret = PTR_ERR(vma);
+ goto err_unref;
+ }
+
+ ret = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
+ if (ret)
+ goto err_unref;
+
+ i915->gt.scratch = vma;
+ return 0;
+
+err_unref:
+ i915_gem_object_put(obj);
+ return ret;
+}
+
+static void i915_gem_fini_scratch(struct drm_i915_private *i915)
+{
+ i915_vma_unpin_and_release(&i915->gt.scratch, 0);
+}
+
int i915_gem_init(struct drm_i915_private *dev_priv)
{
int ret;
@@ -5541,12 +5579,19 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
goto err_unlock;
}
- ret = i915_gem_contexts_init(dev_priv);
+ ret = i915_gem_init_scratch(dev_priv,
+ IS_GEN2(dev_priv) ? SZ_256K : PAGE_SIZE);
if (ret) {
GEM_BUG_ON(ret == -EIO);
goto err_ggtt;
}
+ ret = i915_gem_contexts_init(dev_priv);
+ if (ret) {
+ GEM_BUG_ON(ret == -EIO);
+ goto err_scratch;
+ }
+
ret = intel_engines_init(dev_priv);
if (ret) {
GEM_BUG_ON(ret == -EIO);
@@ -5619,6 +5664,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
err_context:
if (ret != -EIO)
i915_gem_contexts_fini(dev_priv);
+err_scratch:
+ i915_gem_fini_scratch(dev_priv);
err_ggtt:
err_unlock:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
@@ -5670,6 +5717,7 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
intel_uc_fini(dev_priv);
i915_gem_cleanup_engines(dev_priv);
i915_gem_contexts_fini(dev_priv);
+ i915_gem_fini_scratch(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
intel_cleanup_gt_powersave(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index a6885a59568b..07465123c166 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1571,7 +1571,7 @@ static void gem_record_rings(struct i915_gpu_state *error)
if (HAS_BROKEN_CS_TLB(i915))
ee->wa_batchbuffer =
i915_error_object_crea
Re: [Intel-gfx] [PATCH 2/8] drm/i915: Complete the fences as they are cancelled due to wedging
Quoting Tvrtko Ursulin (2018-12-03 17:11:59) > > On 03/12/2018 11:36, Chris Wilson wrote: > > We inspect the requests under the assumption that they will be marked as > > completed when they are removed from the queue. Currently however, in the > > process of wedging the requests will be removed from the queue before they > > are completed, so rearrange the code to complete the fences before the > > locks are dropped. > > > > <1>[ 354.473346] BUG: unable to handle kernel NULL pointer dereference at > > 0250 > > <6>[ 354.473363] PGD 0 P4D 0 > > <4>[ 354.473370] Oops: [#1] PREEMPT SMP PTI > > <4>[ 354.473380] CPU: 0 PID: 4470 Comm: gem_eio Tainted: G U > > 4.20.0-rc4-CI-CI_DRM_5216+ #1 > > <4>[ 354.473393] Hardware name: Intel Corporation NUC7CJYH/NUC7JYB, BIOS > > JYGLKCPX.86A.0027.2018.0125.1347 01/25/2018 > > <4>[ 354.473480] RIP: 0010:__i915_schedule+0x311/0x5e0 [i915] > > <4>[ 354.473490] Code: 49 89 44 24 20 4d 89 4c 24 28 4d 89 29 44 39 b3 a0 > > 04 00 00 7d 3a 41 8b 44 24 78 85 c0 74 13 48 8b 93 78 04 00 00 48 83 e2 fc > > <39> 82 50 02 00 00 79 1e 44 89 b3 a0 04 00 00 48 8d bb d0 03 00 00 > > This confuses me, isn't the code segment usually at the end? *shrug* It was cut and paste. > And then > you have another after the call trace which doesn't match > __i915_scheduel.. anyways, _this_ code seems to be this part: > > if (node_to_request(node)->global_seqno && > 90d: 8b 43 78moveax,DWORD PTR [rbx+0x78] > 910: 85 c0 test eax,eax > 912: 74 13 je 927 <__i915_schedule+0x317> > > i915_seqno_passed(port_request(engine->execlists.port)->global_seqno, > 914: 49 8b 97 c0 04 00 00movrdx,QWORD PTR [r15+0x4c0] > 91b: 48 83 e2 fc andrdx,0xfffc > if (node_to_request(node)->global_seqno && > 91f: 39 82 50 02 00 00 cmpDWORD PTR [rdx+0x250],eax > 925: 79 1e jns945 <__i915_schedule+0x335> > > > <4>[ 354.473515] RSP: 0018:c91bba90 EFLAGS: 00010046 > > <4>[ 354.473524] RAX: 0003 RBX: 8882624c8008 RCX: > > f34a7378 > > <4>[ 354.473535] RDX: RSI: RDI: > > 8882624c8048 > > <4>[ 354.473545] RBP: c91bbab0 R08: 5963f1f1 R09: > > > > <4>[ 354.473556] R10: c91bba10 R11: 8882624c8060 R12: > > 88824fdd7b98 > > <4>[ 354.473567] R13: 88824fdd7bb8 R14: 0001 R15: > > 88824fdd7750 > > <4>[ 354.473578] FS: 7f44b4b5b980() GS:888277e0() > > knlGS: > > <4>[ 354.473590] CS: 0010 DS: ES: CR0: 80050033 > > <4>[ 354.473599] CR2: 0250 CR3: 00026976e000 CR4: > > 00340ef0 > > Given the registers above, I think it means this - eax is global_seqno > of the node rq. rdx is is port_request so NULL and bang. No request in > port, but why would there always be one at the point we are scheduling > in a new request to the runnable queue? Correct. The answer, as I chose to interpret it, is because of the incomplete submitted+dequeued requests during cancellation which this patch attempts to address. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/8] drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate (rev2)
== Series Details ==
Series: series starting with [1/8] drm/i915/breadcrumbs: Reduce
missed-breadcrumb false positive rate (rev2)
URL : https://patchwork.freedesktop.org/series/53396/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0c7799b14282 drm/i915: Complete the fences as they are cancelled due to wedging
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#13:
<1>[ 354.473346] BUG: unable to handle kernel NULL pointer dereference at
0250
total: 0 errors, 1 warnings, 0 checks, 135 lines checked
69375fb8c710 drm/i915: Allocate a common scratch page
005a997a8239 drm/i915: Flush GPU relocs harder for gen3
-:14: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 7fa28e146994 ("drm/i915: Write
GPU relocs harder with gen3")'
#14:
References: 7fa28e146994 ("drm/i915: Write GPU relocs harder with gen3")
total: 1 errors, 0 warnings, 0 checks, 50 lines checked
b469bbe67ddb drm/i915/selftests: Reorder request allocation vs vma pinning
768429adcb4b drm/i915: Pipeline PDP updates for Braswell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/8] drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate (rev2)
== Series Details == Series: series starting with [1/8] drm/i915/breadcrumbs: Reduce missed-breadcrumb false positive rate (rev2) URL : https://patchwork.freedesktop.org/series/53396/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Complete the fences as they are cancelled due to wedging Okay! Commit: drm/i915: Allocate a common scratch page -drivers/gpu/drm/i915/selftests/../i915_drv.h:3571:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3573:16: warning: expression using sizeof(void) Commit: drm/i915: Flush GPU relocs harder for gen3 Okay! Commit: drm/i915/selftests: Reorder request allocation vs vma pinning Okay! Commit: drm/i915: Pipeline PDP updates for Braswell Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/2] drm/i915: Add HAS_DISPLAY() and use it (rev2)
== Series Details == Series: series starting with [v3,1/2] drm/i915: Add HAS_DISPLAY() and use it (rev2) URL : https://patchwork.freedesktop.org/series/53341/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2ea25bb8bc83 drm/i915: Add HAS_DISPLAY() and use it b7a8a1adc388 drm/i915: Move display device info capabilities to its own struct -:397: WARNING:TRAILING_SEMICOLON: macros should not use a trailing semicolon #397: FILE: drivers/gpu/drm/i915/intel_device_info.c:81: +#define PRINT_FLAG(name) drm_printf(p, "%s: %s\n", #name, yesno(info->display.name)); -:437: ERROR:MULTISTATEMENT_MACRO_USE_DO_WHILE: Macros with multiple statements should be enclosed in a do - while loop #437: FILE: drivers/gpu/drm/i915/intel_device_info.h:110: +#define DEV_INFO_DISPLAY_FOR_EACH_FLAG(func) \ + /* Keep in alphabetical order */ \ func(cursor_needs_physical); \ + func(has_csr); \ + func(has_ddi); \ + func(has_dp_mst); \ + func(has_fbc); \ + func(has_gmch_display); \ + func(has_hotplug); \ + func(has_ipc); \ + func(has_overlay); \ + func(has_psr); \ func(overlay_needs_physical); \ + func(supports_tv); -:437: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'func' - possible side-effects? #437: FILE: drivers/gpu/drm/i915/intel_device_info.h:110: +#define DEV_INFO_DISPLAY_FOR_EACH_FLAG(func) \ + /* Keep in alphabetical order */ \ func(cursor_needs_physical); \ + func(has_csr); \ + func(has_ddi); \ + func(has_dp_mst); \ + func(has_fbc); \ + func(has_gmch_display); \ + func(has_hotplug); \ + func(has_ipc); \ + func(has_overlay); \ + func(has_psr); \ func(overlay_needs_physical); \ + func(supports_tv); -:437: WARNING:TRAILING_SEMICOLON: macros should not use a trailing semicolon #437: FILE: drivers/gpu/drm/i915/intel_device_info.h:110: +#define DEV_INFO_DISPLAY_FOR_EACH_FLAG(func) \ + /* Keep in alphabetical order */ \ func(cursor_needs_physical); \ + func(has_csr); \ + func(has_ddi); \ + func(has_dp_mst); \ + func(has_fbc); \ + func(has_gmch_display); \ + func(has_hotplug); \ + func(has_ipc); \ + func(has_overlay); \ + func(has_psr); \ func(overlay_needs_physical); \ + func(supports_tv); total: 1 errors, 2 warnings, 1 checks, 433 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/2] drm/i915: Add HAS_DISPLAY() and use it (rev2)
== Series Details == Series: series starting with [v3,1/2] drm/i915: Add HAS_DISPLAY() and use it (rev2) URL : https://patchwork.freedesktop.org/series/53341/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Add HAS_DISPLAY() and use it -drivers/gpu/drm/i915/selftests/../i915_drv.h:3571:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3573:16: warning: expression using sizeof(void) Commit: drm/i915: Move display device info capabilities to its own struct Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RFC 2/5] cgroup: Add mechanism to register vendor specific DRM devices
On Mon, Dec 03, 2018 at 06:46:01AM +, Ho, Kenny wrote: > Hey Matt, > > On Fri, Nov 30, 2018 at 5:22 PM Matt Roper wrote: > > I think Joonas is describing something closer in > > design to the cgroup-v2 "cpu" controller, which partitions the general > > time/usage allocated to via cgroup; afaiu, "cpu" doesn't really care > > which specific core the tasks run on, just the relative weights that > > determine how much time they get to run on any of the cores. > > Depending on the level of optimization one wants to do, I think people > care about which cpu core a task runs on. Modern processors are no > longer a monolithic 'thing'. At least for AMD, there are multiple > cpus on a core complex (CCX), multiple CCX on a die, and multiple dies > on a processor. A task running on cpu 0 and cpu 1 on die 0 will > behave very differently from a task running on core 0s on die 0 and > die 1 on the same socket. > (https://en.wikichip.org/wiki/amd/microarchitectures/zen#Die-die_memory_latencies) > > It's not just an AMD thing either. Here is an open issue on Intel's > architecture: > https://github.com/kubernetes/kubernetes/issues/67355 > > and a proposed solution using cpu affinity > https://github.com/kubernetes/community/blob/630acc487c80e4981a232cdd8400eb8207119788/keps/sig-node/0030-qos-class-cpu-affinity.md#proposal > (by one of your colleagues.) Right, I didn't mean to imply that the use case wasn't valid, I was just referring to how I believe the cgroup-v2 'cpu' controller (i.e., cpu_cgrp_subsys) currently behaves, as a contrast to the behavior of the cgroup-v1 'cpuset' controller. I can definitely understand your motivation for wanting something along the lines of a "gpuset" controller, but as far as I know, that just isn't something that's possible to implement on a lot of GPU's. > > The time-based sharing below is also something we are thinking about, > but it's personally not as exciting as the resource-based sharing for > me because the time-share use case has already been addressed by our > SRIOV/virtualization products. We can potentially have different > level of time sharing using cgroup though (in addition to SRIOV), > potentially trading efficiency against isolation. That said, I think > the time-based approach maybe orthogonal to the resource-based > approach (orthogonal in the sense that both are needed depending on > the usage.) Makes sense. Matt > > Regards, > Kenny > > > > It sounds like with your hardware, your kernel driver is able to specify > > exactly which subset of GPU EU's a specific GPU context winds up running > > on. However I think there are a lot of platforms that don't allow that > > kind of low-level control. E.g., I don't think we can do that on Intel > > hardware; we have a handful of high-level GPU engines that we can submit > > different types of batchbuffers to (render, blitter, media, etc.). What > > we can do is use GPU preemption to limit how much time specific GPU > > contexts get to run on the render engine before the engine is reclaimed > > for use by a different context. > > > > Using a %gputime approach like Joonas is suggesting could be handled in > > a driver by reserving specific subsets of EU's on hardware like yours > > that's capable of doing that, whereas it could be mostly handled on > > other types of hardware via GPU engine preemption. > > > > I think either approach "gpu_euset" or "%gputime" should map well to a > > cgroup controller implementation. Granted, neither one solves the > > specific use case I was working on earlier this year where we need > > unfair (starvation-okay) scheduling that will run contexts strictly > > according to priority (i.e., lower priority contexts will never run at > > all unless all higher priority contexts have completed all of their > > submitted work), but that's a pretty specialized use case that we'll > > probably need to handle in a different manner anyway. > > > > > > Matt > > > > > > > Regards, > > > Kennny > > > > > > > > > > > > That combined with the "GPU memory usable" property should be a good > > > > > > starting point to start subdividing the GPU resources for multiple > > > > > > users. > > > > > > > > > > > > Regards, Joonas > > > > > > > > > > > > > > > > > > > > Your feedback is highly appreciated. > > > > > > > > > > > > > > Best Regards, > > > > > > > Harish > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: amd-gfx on behalf > > > > > > > of Tejun Heo > > > > > > > Sent: Tuesday, November 20, 2018 5:30 PM > > > > > > > To: Ho, Kenny > > > > > > > Cc: cgro...@vger.kernel.org; intel-gfx@lists.freedesktop.org; > > > > > > > y2ke...@gmail.com; amd-...@lists.freedesktop.org; > > > > > > > dri-de...@lists.freedesktop.org > > > > > > > Subject: Re: [PATCH RFC 2/5] cgroup: Add mechanism to register > > > > > > > vendor specific DRM devices > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > On Tue, Nov 20, 2018 at 10:21:14PM +, Ho, Kenny wr
