[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/hwmon: Enable PL1 power limit (rev3)
== Series Details ==
Series: drm/i915/hwmon: Enable PL1 power limit (rev3)
URL : https://patchwork.freedesktop.org/series/113578/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12686_full -> Patchwork_113578v3_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_113578v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/shard-glk3/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#3886]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/shard-glk8/igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_hpd@vga-hpd:
- shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271]) +26 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/shard-glk8/igt@kms_chamelium_...@vga-hpd.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2346])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/shard-glk5/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/shard-glk3/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
* igt@kms_flip@2x-flip-vs-expired-vblank@bc-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#79])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#658])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/shard-glk8/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][10] ([i915#7742]) -> [PASS][11] +1 similar
issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/shard-rkl-3/igt@drm_fdi...@virtual-idle.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/shard-rkl-5/igt@drm_fdi...@virtual-idle.html
* igt@gem_eio@kms:
- {shard-tglu}: [SKIP][12] ([i915#7651]) -> [PASS][13] +7 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/shard-tglu-6/igt@gem_...@kms.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/shard-tglu-7/igt@gem_...@kms.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][14] ([i915#6247]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/shard-rkl-4/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [FAIL][16] ([i915#2846]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/shard-glk2/igt@gem_exec_f...@basic-deadline.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/shard-glk6/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: [FAIL][18] ([i915#2842]) -> [PASS][19] +1 similar
issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/shard-glk7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/shard-glk5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_readwrite@beyond-eob:
- {shard-rkl}:[SKIP][20] ([i915#3282]) -> [PASS][21] +1 similar
issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/shard-rkl-2/igt@gem_readwr...@beyond-eob.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/shard-rkl-5/igt@gem_readwr...@beyond-eob.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [ABORT][22] ([i915#5566]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/shard-glk9/igt@gen9_exec_pa...@allowed-single.html
[23]:
Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Implement wrappers for callbacks used by fbcon
On Tue, 2023-01-24 at 13:27 +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 24.01.23 um 10:10 schrieb Jouni Högander:
> > After disconnecting damage worker from update logic our dirty
> > callback
> > is not called on fbcon events. This is causing problems to features
> > (PSR, FBC, DRRS) relying on dirty callback getting called and
> > breaking
> > fb console when these features are in use.
> >
> > Implement wrappers for callbacks used by fbcon and call our dirty
> > callback in those.
> >
> > Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from
> > update logic")
> > Cc: Ville Syrjälä
> > Cc: Thomas Zimmermann
> > Cc: Jani Nikula
> > Signed-off-by: Jouni Högander
>
> This is the better solution wrt what fbdev wants.
There was a failure from testing robot. drivers/tty/vt/vt.c is using
spinlock and in our dirty callback we are taking mutex.
Do you have any suggestions? Shall we fallback to original fix which
was setting the dirty callback where call is made from workqueue?
>
> Acked-by: Thomas Zimmermann
>
> Best regards
> Thomas
>
> > ---
> > drivers/gpu/drm/i915/display/intel_fbdev.c | 53
> > --
> > 1 file changed, 49 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> > b/drivers/gpu/drm/i915/display/intel_fbdev.c
> > index 19f3b5d92a55..b1653624552e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> > @@ -77,6 +77,18 @@ static void intel_fbdev_invalidate(struct
> > intel_fbdev *ifbdev)
> > intel_frontbuffer_invalidate(to_frontbuffer(ifbdev),
> > ORIGIN_CPU);
> > }
> >
> > +static void intel_fbdev_dirty(struct fb_info *info)
> > +{
> > + struct drm_fb_helper *helper = info->par;
> > +
> > + /*
> > + * Intel_fb dirty implementation doesn't use damage clips -
> > >
> > + * no need to pass them here
> > + */
> > + if (helper->fb->funcs->dirty)
> > + helper->fb->funcs->dirty(helper->fb, NULL, 0, 0,
> > NULL, 0);
> > +}
> > +
> > static int intel_fbdev_set_par(struct fb_info *info)
> > {
> > struct drm_fb_helper *fb_helper = info->par;
> > @@ -91,6 +103,39 @@ static int intel_fbdev_set_par(struct fb_info
> > *info)
> > return ret;
> > }
> >
> > +static ssize_t intel_fbdev_write(struct fb_info *info, const char
> > __user *buf,
> > + size_t count, loff_t *ppos)
> > +{
> > + int ret;
> > +
> > + ret = drm_fb_helper_cfb_write(info, buf, count, ppos);
> > + if (ret > 0)
> > + intel_fbdev_dirty(info);
> > +
> > + return ret;
> > +}
> > +
> > +static void intel_fbdev_fillrect(struct fb_info *info,
> > + const struct fb_fillrect *rect)
> > +{
> > + drm_fb_helper_cfb_fillrect(info, rect);
> > + intel_fbdev_dirty(info);
> > +}
> > +
> > +static void intel_fbdev_copyarea(struct fb_info *info,
> > + const struct fb_copyarea *area)
> > +{
> > + drm_fb_helper_cfb_copyarea(info, area);
> > + intel_fbdev_dirty(info);
> > +}
> > +
> > +static void intel_fbdev_imageblit(struct fb_info *info,
> > + const struct fb_image *image)
> > +{
> > + drm_fb_helper_cfb_imageblit(info, image);
> > + intel_fbdev_dirty(info);
> > +}
> > +
> > static int intel_fbdev_blank(int blank, struct fb_info *info)
> > {
> > struct drm_fb_helper *fb_helper = info->par;
> > @@ -125,10 +170,10 @@ static const struct fb_ops intelfb_ops = {
> > DRM_FB_HELPER_DEFAULT_OPS,
> > .fb_set_par = intel_fbdev_set_par,
> > .fb_read = drm_fb_helper_cfb_read,
> > - .fb_write = drm_fb_helper_cfb_write,
> > - .fb_fillrect = drm_fb_helper_cfb_fillrect,
> > - .fb_copyarea = drm_fb_helper_cfb_copyarea,
> > - .fb_imageblit = drm_fb_helper_cfb_imageblit,
> > + .fb_write = intel_fbdev_write,
> > + .fb_fillrect = intel_fbdev_fillrect,
> > + .fb_copyarea = intel_fbdev_copyarea,
> > + .fb_imageblit = intel_fbdev_imageblit,
> > .fb_pan_display = intel_fbdev_pan_display,
> > .fb_blank = intel_fbdev_blank,
> > };
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
Re: [Intel-gfx] [PATCH 1/1] drm/i915/dp: Fix logic to fetch slice_height
>
> On Thu, 02 Feb 2023, "Kandpal, Suraj" wrote:
> >>
> >> On Thu, 02 Feb 2023, Suraj Kandpal wrote:
> >> > According to Bpec: 49259 VDSC spec implies that 108 lines is an
> >> > optimal slice height, but any size can be used as long as vertical
> >> > active integer multiple and maximum vertical slice count
> >> > requirements are
> >> met.
> >>
> >> The commit message and subject should really indicate that this
> >> increases the slice height considerably. It's a 13.5x increase at a
> >> minimum, could be much more. Seems misleading to call it "fix logic",
> >> as if there's a small issue somewhere.
> >>
> >> Bspec references should be here:
> >>
> >> Bspec: 49259
> >> > Cc: Ankit Nautiyal
> >> > Cc: Swati Sharma
> >> > Signed-off-by: Suraj Kandpal
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> >> > b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > index 62cbab7402e9..7bd2e56ef0fa 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > @@ -1415,6 +1415,22 @@ static int
> >> intel_dp_sink_dsc_version_minor(struct intel_dp *intel_dp)
> >> > DP_DSC_MINOR_SHIFT;
> >> > }
> >> >
> >> > +static int intel_dp_get_slice_height(int vactive)
> >>
> >> intel_dp_dsc_get_slice_height
> >>
> >> > +{
> >> > +int slice_height;
> >> > +
> >> > +/*
> >> > + * VDSC spec implies that 108 lines is an optimal slice height,
> >>
> >> Please be more specific with spec references than vague "VSDC spec".
> >> Spec version is required at a minimum. Section and section title are a nice
> bonus.
> >>
> >> > + * but any size can be used as long as vertical active integer
> >> > + * multiple and maximum vertical slice count requirements are
> >> > met.
> >> > + */
> >> > +for (slice_height = 108; slice_height <= vactive; slice_height
> >> > +=
> >> > +2)
> >>
> >> Where does it say 108 is a minimum, and you should go up only...?
> >
> > So in VDSC 1.2a section 3.8 option for slices it says "a slice height
> > of 108 lines typically provides better performance than a slice height
> > of 8 lines."
> > It also states the following
> > "Also it says There is no cost associated with slice height because
> > there is no additional buffering or any other additional resources required"
> > that's why I decided to move up from slice height of 108
> >
> >>
> >> > +if (!(vactive % slice_height))
> >>
> >> Matter of taste, but please use (vactive % slice_height == 0) for
> >> clarity on computations like this.
> >>
> >> > +return slice_height;
> >> > +
> >> > +return 0;
> >>
> >> I guess it's unlikely we ever hit here, but you could have the old
> >> code as fallback and never return 0. Because you don't check for 0 in
> >> the caller anyway.
> >
> > I will do this
> >
> >>
> >> Also makes me wonder why we have intel_hdmi_dsc_get_slice_height()
> >> separately, with almost identical implementation. Maybe we should
> >> consolidate.
> >
> > That's separate because the minimum there starts from slice_height of
> > 96 as indicated in HDMI spec
>
> Do you think it's fine to duplicate a whole function if their sole difference
> is
> the starting point of a for loop?
>
Well that wont be the only difference after I add the code to fallback to the
older dp code going forward
Instead of returning 0 as pointed out by you earlier. If I consolidate this
function just for dp and hdmi
There will be a connector type check for those two as dsi and edp have
slice_height filled by vbt and this could
look bad by placing it in intel_vdsc.c where I assume we want to keep things
agnostic.
Regards,
Suraj Kandpal
> BR,
> Jani.
>
> >
> > Regards,
> > Suraj Kandpal
> >>
> >> > +}
> >> > +
> >> > static int intel_dp_dsc_compute_params(struct intel_encoder *encoder,
> >> > struct intel_crtc_state
> >> > *crtc_state) { @@
> >> -1433,17
> >> > +1449,7 @@ static int intel_dp_dsc_compute_params(struct
> >> > +intel_encoder
> >> *encoder,
> >> > vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
> >> > vdsc_cfg->pic_height =
> >> > crtc_state->hw.adjusted_mode.crtc_vdisplay;
> >> >
> >> > -/*
> >> > - * Slice Height of 8 works for all currently available panels.
> >> > So start
> >> > - * with that if pic_height is an integral multiple of 8.
> >> > Eventually add
> >> > - * logic to try multiple slice heights.
> >> > - */
> >> > -if (vdsc_cfg->pic_height % 8 == 0)
> >> > -vdsc_cfg->slice_height = 8;
> >> > -else if (vdsc_cfg->pic_height % 4 == 0)
> >> > -vdsc_cfg->slice_height = 4;
> >> > -else
> >> > -vdsc_cfg->slice_height = 2;
> >> > +vdsc_cfg->slice_height =
> >> > +intel_dp_get_slice_height(vdsc_cfg->pic_height);
> >> >
> >> > ret =
[Intel-gfx] ✓ Fi.CI.IGT: success for Fix logic to get slice_height for dp (rev2)
== Series Details ==
Series: Fix logic to get slice_height for dp (rev2)
URL : https://patchwork.freedesktop.org/series/113594/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12685_full -> Patchwork_113594v2_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113594v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
- {shard-rkl}:[SKIP][1] ([i915#4098]) -> [TIMEOUT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12685/shard-rkl-4/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/shard-rkl-3/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
* igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-64bpp-4tile-downscaling:
- {shard-rkl}:[SKIP][3] ([i915#3555]) -> [TIMEOUT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12685/shard-rkl-4/igt@kms_flip_scaled_...@flip-32bpp-4tile-to-64bpp-4tile-downscaling.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/shard-rkl-3/igt@kms_flip_scaled_...@flip-32bpp-4tile-to-64bpp-4tile-downscaling.html
* igt@prime_vgem@basic-userptr:
- {shard-rkl}:[SKIP][5] ([fdo#109295] / [i915#3301] / [i915#3708])
-> [TIMEOUT][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12685/shard-rkl-4/igt@prime_v...@basic-userptr.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/shard-rkl-3/igt@prime_v...@basic-userptr.html
* igt@syncobj_timeline@wait-all-delayed-signal:
- {shard-rkl}:[PASS][7] -> [TIMEOUT][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12685/shard-rkl-4/igt@syncobj_timel...@wait-all-delayed-signal.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/shard-rkl-3/igt@syncobj_timel...@wait-all-delayed-signal.html
Known issues
Here are the changes found in Patchwork_113594v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none@vcs0:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12685/shard-glk3/igt@gem_exec_fair@basic-n...@vcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/shard-glk3/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#3886]) +3
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/shard-glk6/igt@kms_ccs@pipe-c-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_hpd@vga-hpd:
- shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271]) +26 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/shard-glk6/igt@kms_chamelium_...@vga-hpd.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@ac-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#79])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12685/shard-glk4/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/shard-glk8/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@ac-hdmi-a1-hdmi-a2.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#658])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/shard-glk6/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
Possible fixes
* igt@api_intel_bb@object-reloc-keep-cache:
- {shard-rkl}:[SKIP][16] ([i915#3281]) -> [PASS][17] +4 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12685/shard-rkl-3/igt@api_intel...@object-reloc-keep-cache.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/shard-rkl-5/igt@api_intel...@object-reloc-keep-cache.html
* igt@fbdev@eof:
- {shard-tglu}: [SKIP][18] ([i915#2582]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12685/shard-tglu-6/igt@fb...@eof.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/shard-tglu-1/igt@fb...@eof.html
* igt@fbdev@pan:
- {shard-rkl}:[SKIP][20] ([i915#2582]) -> [PASS][21]
[20]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for More error capture improvements
== Series Details == Series: More error capture improvements URL : https://patchwork.freedesktop.org/series/113628/ State : warning == Summary == Error: dim checkpatch failed eb15e24f1a93 drm/i915/guc: Fix missing ecodes -:15: WARNING:REPEATED_WORD: Possible repeated word: 'if' #15: v2: if else if instead of if if (Alan) total: 0 errors, 1 warnings, 0 checks, 34 lines checked f07c6bd31dbd drm/i915/guc: Clean up of register capture search b9a5e35feee9 drm/i915: Include timelines in error capture
Re: [Intel-gfx] [PATCH v3] vfio: fix deadlock between group lock and kvm lock
> From: Alex Williamson > Sent: Friday, February 3, 2023 7:13 AM > > On Thu, 2 Feb 2023 23:04:10 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson > > > Sent: Friday, February 3, 2023 3:42 AM > > > > > > > > > LGTM. I'm not sure moving the functions to vfio_main really buys us > > > anything since we're making so much use of group fields. The cdev > > > approach will necessarily be different, so the bulk of the get code will > > > likely need to move back to group.c anyway. > > > > > > > well my last comment was based on Matthew's v2 where the get code > > gets a kvm passed in instead of implicitly retrieving group ref_lock > > internally. In that case the get/put helpers only contain device logic > > thus fit in vfio_main.c. > > > > with v3 then they have to be in group.c since we don't want to use > > group fields in vfio_main.c. > > > > but I still think v2 of the helpers is slightly better. The only difference > > between cdev and group when handling this race is using different > > ref_lock. the symbol get/put part is exactly same. So even if we > > merge v3 like this, very likely Yi has to change it back to v2 style > > to share the get/put helpers while just leaving the ref_lock part > > handled differently between the two path. > > I'm not really a fan of the asymmetry of the v2 version where the get > helper needs to be called under the new kvm_ref_lock, but the put > helper does not. Having the get helper handle that makes the caller > much cleaner. Thanks, > What about passing the lock pointer into the helper? it's still slightly asymmetry as the put helper doesn't carry the lock pointer but it could also be interpreted as if the pointer has been saved in the get then if it needs to be referenced by the put there is no need to pass it in again.
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for More drm_dbg to guc_dbg changes
== Series Details == Series: More drm_dbg to guc_dbg changes URL : https://patchwork.freedesktop.org/series/113624/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return'
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix GEN8_MISCCPCTL
On Thu, Feb 02, 2023 at 04:57:08PM -0800, Lucas De Marchi wrote:
> Register 0x9424 is not replicated on any platform, so it shouldn't be
> declared with REG_MCR(). Declaring it with _MMIO() is basically
> duplicate of the GEN7 version, so just remove the GEN8 and change all
> the callers to use the right functions.
According to an old copy of bspec page 13991, 0x9400-0x97FF was an MCR
range on gen8 platforms. Newer copies of that bspec page forgot to even
include the register range table, so it's not obvious unless you dig
through the history and look at a version from before Aug 2020.
However bspec page 66673 indicates that this range went back to being a
singleton range in gen9 (and the other forcewake pages for newer
platforms indicate it stayed that way), so that means BDW and CHV are
the _only_ platforms that should treat it as MCR. Usage for other
platforms should either add a new "GEN9" definition, or just go back to
using the GEN7 definition.
Matt
>
> Also use intel_uncore_rmw() rather than a read + write where possible.
>
> Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly")
> Cc: Matt Roper
> Cc: Balasubramani Vivekanandan
> Cc: Rodrigo Vivi
> Cc: Gustavo Sousa
> Cc: Matt Atwood
> Cc: Ashutosh Dixit
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
> drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 5 ++---
> drivers/gpu/drm/i915/intel_pm.c | 10 +-
> 4 files changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 7fa18a3b3957..cc1539c7a6b6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -686,10 +686,7 @@
> #define GEN6_RSTCTL _MMIO(0x9420)
>
> #define GEN7_MISCCPCTL _MMIO(0x9424)
> -#define GEN7_DOP_CLOCK_GATE_ENABLE (1 << 0)
> -
> -#define GEN8_MISCCPCTL MCR_REG(0x9424)
> -#define GEN8_DOP_CLOCK_GATE_ENABLE REG_BIT(0)
> +#define GEN7_DOP_CLOCK_GATE_ENABLE REG_BIT(0)
> #define GEN12_DOP_CLOCK_GATE_RENDER_ENABLE REG_BIT(1)
> #define GEN8_DOP_CLOCK_GATE_CFCLK_ENABLE (1 << 2)
> #define GEN8_DOP_CLOCK_GATE_GUC_ENABLE (1 << 4)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 29718d0595f4..cfc122c17e28 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1645,7 +1645,7 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
>
> /* Wa_14015795083 */
> - wa_mcr_write_clr(wal, GEN8_MISCCPCTL,
> GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
> + wa_write_clr(wal, GEN7_MISCCPCTL, GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
>
> /* Wa_18018781329 */
> wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
> @@ -1664,7 +1664,7 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct
> i915_wa_list *wal)
> pvc_init_mcr(gt, wal);
>
> /* Wa_14015795083 */
> - wa_mcr_write_clr(wal, GEN8_MISCCPCTL,
> GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
> + wa_write_clr(wal, GEN7_MISCCPCTL, GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
>
> /* Wa_18018781329 */
> wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
> index 3d2249bda368..69133420c78b 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
> @@ -39,9 +39,8 @@ static void guc_prepare_xfer(struct intel_gt *gt)
>
> if (GRAPHICS_VER(uncore->i915) == 9) {
> /* DOP Clock Gating Enable for GuC clocks */
> - intel_gt_mcr_multicast_write(gt, GEN8_MISCCPCTL,
> - GEN8_DOP_CLOCK_GATE_GUC_ENABLE |
> - intel_gt_mcr_read_any(gt,
> GEN8_MISCCPCTL));
> + intel_uncore_rmw(uncore, GEN7_MISCCPCTL, 0,
> + GEN8_DOP_CLOCK_GATE_GUC_ENABLE);
>
> /* allows for 5us (in 10ns units) before GT can go to RC6 */
> intel_uncore_write(uncore, GUC_ARAT_C6DIS, 0x1FF);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index e0364c4141b8..798607959458 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4300,8 +4300,8 @@ static void gen8_set_l3sqc_credits(struct
> drm_i915_private *dev_priv,
> u32 val;
>
> /* WaTempDisableDOPClkGating:bdw */
> - misccpctl = intel_gt_mcr_multicast_rmw(to_gt(dev_priv), GEN8_MISCCPCTL,
> -GEN8_DOP_CLOCK_GATE_ENABLE,
[Intel-gfx] [PATCH 3/3] drm/i915: Include timelines in error capture
From: John Harrison The seqno value actually written out to memory is no longer in the regular HWSP and therefore no longer visible in an error capture. Instead, it is now in its own private timeline buffer. So include that buffer in the capture too. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/i915_gpu_error.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 904f21e1380cd..66bd4c1162f79 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -1550,6 +1550,7 @@ engine_coredump_add_context(struct intel_engine_coredump *ee, */ vma = capture_vma(vma, ce->ring->vma, "ring", gfp); vma = capture_vma(vma, ce->state, "HW context", gfp); + vma = capture_vma(vma, ce->timeline->hwsp_ggtt, "ctxt timeline HWSP", gfp); return vma; } @@ -1572,6 +1573,8 @@ intel_engine_coredump_add_request(struct intel_engine_coredump *ee, */ vma = capture_vma_snapshot(vma, rq->batch_res, gfp, "batch"); vma = capture_user(vma, rq, gfp); + if (rq->timeline != rq->context->timeline) + vma = capture_vma(vma, rq->timeline->hwsp_ggtt, "rq timeline HWSP", gfp); ee->rq_head = rq->head; ee->rq_post = rq->postfix; -- 2.39.1
[Intel-gfx] [PATCH 2/3] drm/i915/guc: Clean up of register capture search
From: John Harrison
The comparison in the search for a matching register capture node was
not the most readable. So remove two redundant terms and re-format to
keep each term on a single line, and only one term per line.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index 710999d7189ee..87b080dd6bead 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1627,9 +1627,8 @@ void intel_guc_capture_get_matching_node(struct intel_gt
*gt,
list_for_each_entry_safe(n, ntmp, >capture->outlist, link) {
if (n->eng_inst ==
GUC_ID_TO_ENGINE_INSTANCE(ee->engine->guc_id) &&
n->eng_class == GUC_ID_TO_ENGINE_CLASS(ee->engine->guc_id)
&&
- n->guc_id && n->guc_id == ce->guc_id.id &&
- (n->lrca & CTX_GTT_ADDRESS_MASK) && (n->lrca &
CTX_GTT_ADDRESS_MASK) ==
- (ce->lrc.lrca & CTX_GTT_ADDRESS_MASK)) {
+ n->guc_id == ce->guc_id.id &&
+ (n->lrca & CTX_GTT_ADDRESS_MASK) == (ce->lrc.lrca &
CTX_GTT_ADDRESS_MASK)) {
list_del(>link);
ee->guc_capture_node = n;
ee->guc_capture = guc->capture;
--
2.39.1
[Intel-gfx] [PATCH 1/3] drm/i915/guc: Fix missing ecodes
From: John Harrison
Error captures are tagged with an 'ecode'. This is a pseduo-unique magic
number that is meant to distinguish similar seeming bugs with
different underlying signatures. It is a combination of two ring state
registers. Unfortunately, the register state being used is only valid
in execlist mode. In GuC mode, the register state exists in a separate
list of arbitrary register address/value pairs rather than the named
entry structure. So, search through that list to find the two exciting
registers and copy them over to the structure's named members.
v2: if else if instead of if if (Alan)
Signed-off-by: John Harrison
Fixes: a6f0f9cf330a ("drm/i915/guc: Plumb GuC-capture into gpu_coredump")
Cc: Alan Previn
Cc: Umesh Nerlige Ramappa
Cc: Lucas De Marchi
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Matt Roper
Cc: Aravind Iddamsetty
Cc: Michael Cheng
Cc: Matthew Brost
Cc: Bruce Chang
Cc: Daniele Ceraolo Spurio
Cc: Matthew Auld
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 22 +++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index fc3b994626a4f..710999d7189ee 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -1571,6 +1571,27 @@ int intel_guc_capture_print_engine_node(struct
drm_i915_error_state_buf *ebuf,
#endif //CONFIG_DRM_I915_CAPTURE_ERROR
+static void guc_capture_find_ecode(struct intel_engine_coredump *ee)
+{
+ struct gcap_reg_list_info *reginfo;
+ struct guc_mmio_reg *regs;
+ i915_reg_t reg_ipehr = RING_IPEHR(0);
+ i915_reg_t reg_instdone = RING_INSTDONE(0);
+ int i;
+
+ if (!ee->guc_capture_node)
+ return;
+
+ reginfo = ee->guc_capture_node->reginfo +
GUC_CAPTURE_LIST_TYPE_ENGINE_INSTANCE;
+ regs = reginfo->regs;
+ for (i = 0; i < reginfo->num_regs; i++) {
+ if (regs[i].offset == reg_ipehr.reg)
+ ee->ipehr = regs[i].value;
+ else if (regs[i].offset == reg_instdone.reg)
+ ee->instdone.instdone = regs[i].value;
+ }
+}
+
void intel_guc_capture_free_node(struct intel_engine_coredump *ee)
{
if (!ee || !ee->guc_capture_node)
@@ -1612,6 +1633,7 @@ void intel_guc_capture_get_matching_node(struct intel_gt
*gt,
list_del(>link);
ee->guc_capture_node = n;
ee->guc_capture = guc->capture;
+ guc_capture_find_ecode(ee);
return;
}
}
--
2.39.1
[Intel-gfx] [PATCH 0/3] More error capture improvements
From: John Harrison Ecodes got lost with the switch to GuC based register lists. Put them back. Seqno values got lost with the switch to per context timelines. Put hose back too. Signed-off-by: John Harrison John Harrison (3): drm/i915/guc: Fix missing ecodes drm/i915/guc: Clean up of register capture search drm/i915: Include timelines in error capture .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 27 --- drivers/gpu/drm/i915/i915_gpu_error.c | 3 +++ 2 files changed, 27 insertions(+), 3 deletions(-) -- 2.39.1
[Intel-gfx] [PATCH 2/2] drm/i915: Remove unused/wrong INF_UNIT_LEVEL_CLKGATE
INF_UNIT_LEVEL_CLKGATE is not replicated, but since it's not actually used it can just be removed. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index cc1539c7a6b6..7256f7e3fd11 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -769,9 +769,6 @@ #define GEN10_DFR_RATIO_EN_AND_CHICKEN MCR_REG(0x9550) #define DFR_DISABLE (1 << 9) -#define INF_UNIT_LEVEL_CLKGATE MCR_REG(0x9560) -#define CGPSF_CLKGATE_DIS(1 << 3) - #define MICRO_BP0_0_MMIO(0x9800) #define MICRO_BP0_2_MMIO(0x9804) #define MICRO_BP0_1_MMIO(0x9808) -- 2.39.0
[Intel-gfx] [PATCH 1/2] drm/i915: Fix GEN8_MISCCPCTL
Register 0x9424 is not replicated on any platform, so it shouldn't be
declared with REG_MCR(). Declaring it with _MMIO() is basically
duplicate of the GEN7 version, so just remove the GEN8 and change all
the callers to use the right functions.
Also use intel_uncore_rmw() rather than a read + write where possible.
Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly")
Cc: Matt Roper
Cc: Balasubramani Vivekanandan
Cc: Rodrigo Vivi
Cc: Gustavo Sousa
Cc: Matt Atwood
Cc: Ashutosh Dixit
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 5 ++---
drivers/gpu/drm/i915/intel_pm.c | 10 +-
4 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 7fa18a3b3957..cc1539c7a6b6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -686,10 +686,7 @@
#define GEN6_RSTCTL_MMIO(0x9420)
#define GEN7_MISCCPCTL _MMIO(0x9424)
-#define GEN7_DOP_CLOCK_GATE_ENABLE (1 << 0)
-
-#define GEN8_MISCCPCTL MCR_REG(0x9424)
-#define GEN8_DOP_CLOCK_GATE_ENABLE REG_BIT(0)
+#define GEN7_DOP_CLOCK_GATE_ENABLE REG_BIT(0)
#define GEN12_DOP_CLOCK_GATE_RENDER_ENABLE REG_BIT(1)
#define GEN8_DOP_CLOCK_GATE_CFCLK_ENABLE (1 << 2)
#define GEN8_DOP_CLOCK_GATE_GUC_ENABLE (1 << 4)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 29718d0595f4..cfc122c17e28 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1645,7 +1645,7 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
wa_mcr_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
/* Wa_14015795083 */
- wa_mcr_write_clr(wal, GEN8_MISCCPCTL,
GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
+ wa_write_clr(wal, GEN7_MISCCPCTL, GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
/* Wa_18018781329 */
wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
@@ -1664,7 +1664,7 @@ pvc_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
pvc_init_mcr(gt, wal);
/* Wa_14015795083 */
- wa_mcr_write_clr(wal, GEN8_MISCCPCTL,
GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
+ wa_write_clr(wal, GEN7_MISCCPCTL, GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
/* Wa_18018781329 */
wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 3d2249bda368..69133420c78b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -39,9 +39,8 @@ static void guc_prepare_xfer(struct intel_gt *gt)
if (GRAPHICS_VER(uncore->i915) == 9) {
/* DOP Clock Gating Enable for GuC clocks */
- intel_gt_mcr_multicast_write(gt, GEN8_MISCCPCTL,
-GEN8_DOP_CLOCK_GATE_GUC_ENABLE |
-intel_gt_mcr_read_any(gt,
GEN8_MISCCPCTL));
+ intel_uncore_rmw(uncore, GEN7_MISCCPCTL, 0,
+GEN8_DOP_CLOCK_GATE_GUC_ENABLE);
/* allows for 5us (in 10ns units) before GT can go to RC6 */
intel_uncore_write(uncore, GUC_ARAT_C6DIS, 0x1FF);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e0364c4141b8..798607959458 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4300,8 +4300,8 @@ static void gen8_set_l3sqc_credits(struct
drm_i915_private *dev_priv,
u32 val;
/* WaTempDisableDOPClkGating:bdw */
- misccpctl = intel_gt_mcr_multicast_rmw(to_gt(dev_priv), GEN8_MISCCPCTL,
- GEN8_DOP_CLOCK_GATE_ENABLE, 0);
+ misccpctl = intel_uncore_rmw(_priv->uncore, GEN7_MISCCPCTL,
+GEN7_DOP_CLOCK_GATE_ENABLE, 0);
val = intel_gt_mcr_read_any(to_gt(dev_priv), GEN8_L3SQCREG1);
val &= ~L3_PRIO_CREDITS_MASK;
@@ -4315,7 +4315,7 @@ static void gen8_set_l3sqc_credits(struct
drm_i915_private *dev_priv,
*/
intel_gt_mcr_read_any(to_gt(dev_priv), GEN8_L3SQCREG1);
udelay(1);
- intel_gt_mcr_multicast_write(to_gt(dev_priv), GEN8_MISCCPCTL,
misccpctl);
+ intel_uncore_write(_priv->uncore, GEN7_MISCCPCTL, misccpctl);
}
static void icl_init_clock_gating(struct drm_i915_private *dev_priv)
@@ -4453,8 +4453,8 @@ static void skl_init_clock_gating(struct drm_i915_private
*dev_priv)
gen9_init_clock_gating(dev_priv);
/* WaDisableDopClockGating:skl */
-
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Make sure dsm_size has correct granularity (rev2)
== Series Details ==
Series: drm/i915: Make sure dsm_size has correct granularity (rev2)
URL : https://patchwork.freedesktop.org/series/113282/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12684_full -> Patchwork_113282v2_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113282v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_isolation@preservation-s3@rcs0:
- {shard-tglu}: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-tglu-2/igt@gem_ctx_isolation@preservation...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/shard-tglu-6/igt@gem_ctx_isolation@preservation...@rcs0.html
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- {shard-rkl}:[PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-4/igt@gem_ctx_isolation@preservation...@vcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/shard-rkl-3/igt@gem_ctx_isolation@preservation...@vcs0.html
Known issues
Here are the changes found in Patchwork_113282v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2846])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-glk1/igt@gem_exec_f...@basic-deadline.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/shard-glk7/igt@gem_exec_f...@basic-deadline.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2346])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-glk2/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/shard-glk7/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
* igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a1:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#79])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-glk5/igt@kms_flip@flip-vs-expired-vbl...@a-hdmi-a1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/shard-glk7/igt@kms_flip@flip-vs-expired-vbl...@a-hdmi-a1.html
Possible fixes
* igt@fbdev@pan:
- {shard-rkl}:[SKIP][11] ([i915#2582]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-4/igt@fb...@pan.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/shard-rkl-6/igt@fb...@pan.html
* igt@gem_ctx_persistence@many-contexts:
- {shard-rkl}:[INCOMPLETE][13] -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-3/igt@gem_ctx_persiste...@many-contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/shard-rkl-5/igt@gem_ctx_persiste...@many-contexts.html
* igt@gem_eio@suspend:
- {shard-rkl}:[FAIL][15] ([i915#5115] / [i915#7052]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-3/igt@gem_...@suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/shard-rkl-6/igt@gem_...@suspend.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][17] ([i915#2842]) -> [PASS][18] +2 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-3/igt@gem_exec_fair@basic-p...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/shard-rkl-5/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_reloc@basic-gtt-read-noreloc:
- {shard-rkl}:[SKIP][19] ([i915#3281]) -> [PASS][20] +14 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-4/igt@gem_exec_re...@basic-gtt-read-noreloc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/shard-rkl-5/igt@gem_exec_re...@basic-gtt-read-noreloc.html
* igt@gem_exec_schedule@wide@rcs0:
- shard-glk: [FAIL][21] ([i915#6659]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-glk6/igt@gem_exec_schedule@w...@rcs0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/shard-glk8/igt@gem_exec_schedule@w...@rcs0.html
* igt@gem_mmap_gtt@coherency:
- {shard-rkl}:[SKIP][23] ([fdo#111656]) -> [PASS][24]
[23]:
[Intel-gfx] [PATCH 2/6] drm/i915/guc: More debug print updates - GSC firmware
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 8 +++-
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 7 +++
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index e73d4440c5e82..8e0c736fa4e94 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -6,6 +6,7 @@
#include "gt/intel_engine_pm.h"
#include "gt/intel_gpu_commands.h"
#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
#include "gt/intel_ring.h"
#include "intel_gsc_fw.h"
@@ -88,9 +89,7 @@ static int gsc_fw_load(struct intel_gsc_uc *gsc)
i915_request_put(rq);
if (err)
- drm_err(_uc_to_gt(gsc)->i915->drm,
- "Request submission for GSC load failed (%d)\n",
- err);
+ gt_err(gsc_uc_to_gt(gsc), "Request submission for GSC load
failed (%d)\n", err);
return err;
}
@@ -200,8 +199,7 @@ int intel_gsc_uc_fw_upload(struct intel_gsc_uc *gsc)
/* FW is not fully operational until we enable SW proxy */
intel_uc_fw_change_status(gsc_fw, INTEL_UC_FIRMWARE_TRANSFERRED);
- drm_info(>i915->drm, "Loaded GSC firmware %s\n",
-gsc_fw->file_selected.path);
+ gt_info(gt, "Loaded GSC firmware %s\n", gsc_fw->file_selected.path);
return 0;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
index fd21dbd2663be..6e7d5aa4dcf5e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -6,6 +6,7 @@
#include
#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
#include "intel_gsc_uc.h"
#include "intel_gsc_fw.h"
#include "i915_drv.h"
@@ -59,7 +60,6 @@ int intel_gsc_uc_init(struct intel_gsc_uc *gsc)
{
static struct lock_class_key gsc_lock;
struct intel_gt *gt = gsc_uc_to_gt(gsc);
- struct drm_i915_private *i915 = gt->i915;
struct intel_engine_cs *engine = gt->engine[GSC0];
struct intel_context *ce;
struct i915_vma *vma;
@@ -81,8 +81,7 @@ int intel_gsc_uc_init(struct intel_gsc_uc *gsc)
I915_GEM_HWS_GSC_ADDR,
_lock, "gsc_context");
if (IS_ERR(ce)) {
- drm_err(>i915->drm,
- "failed to create GSC CS ctx for FW communication\n");
+ gt_err(gt, "failed to create GSC CS ctx for FW
communication\n");
err = PTR_ERR(ce);
goto out_vma;
}
@@ -98,7 +97,7 @@ int intel_gsc_uc_init(struct intel_gsc_uc *gsc)
out_fw:
intel_uc_fw_fini(>fw);
out:
- i915_probe_error(i915, "failed with %d\n", err);
+ gt_probe_error(gt, "GSC init failed with %d\n", err);
return err;
}
--
2.39.1
[Intel-gfx] [PATCH 6/6] drm/i915/guc: More debug print updates - GuC logging
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_gt_print.h | 3 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 3 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_print.h | 3 +++
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_print.h
b/drivers/gpu/drm/i915/gt/intel_gt_print.h
index 5d9da355ce242..55a336a9ff061 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_print.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_print.h
@@ -28,6 +28,9 @@
#define gt_err_ratelimited(_gt, _fmt, ...) \
drm_err_ratelimited(&(_gt)->i915->drm, "GT%u: " _fmt, (_gt)->info.id,
##__VA_ARGS__)
+#define gt_notice_ratelimited(_gt, _fmt, ...) \
+ dev_notice_ratelimited((_gt)->i915->drm.dev, "GT%u: " _fmt,
(_gt)->info.id, ##__VA_ARGS__)
+
#define gt_probe_error(_gt, _fmt, ...) \
do { \
if (i915_error_injected()) \
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index c3792ddeec802..818e9e0e66a83 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -333,8 +333,7 @@ bool intel_guc_check_log_buf_overflow(struct intel_guc_log
*log,
log->stats[type].sampled_overflow += 16;
}
-
dev_notice_ratelimited(guc_to_gt(log_to_guc(log))->i915->drm.dev,
- "GuC log buffer overflow\n");
+ guc_notice_ratelimited(log_to_guc(log), "log buffer
overflow\n");
}
return overflow;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
index e75989d4ba067..2465d05638b40 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_print.h
@@ -30,6 +30,9 @@
#define guc_err_ratelimited(_guc, _fmt, ...) \
guc_printk((_guc), err_ratelimited, _fmt, ##__VA_ARGS__)
+#define guc_notice_ratelimited(_guc, _fmt, ...) \
+ guc_printk((_guc), notice_ratelimited, _fmt, ##__VA_ARGS__)
+
#define guc_probe_error(_guc, _fmt, ...) \
guc_printk((_guc), probe_error, _fmt, ##__VA_ARGS__)
--
2.39.1
[Intel-gfx] [PATCH 5/6] drm/i915/guc: More debug print updates - GuC SLPC
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 8 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 60 -
2 files changed, 26 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
index b5855091cf6a9..23b287cefb943 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
@@ -6,6 +6,7 @@
#include
#include "intel_guc_rc.h"
+#include "intel_guc_print.h"
#include "gt/intel_gt.h"
#include "i915_drv.h"
@@ -70,13 +71,12 @@ static int __guc_rc_control(struct intel_guc *guc, bool
enable)
ret = guc_action_control_gucrc(guc, enable);
if (ret) {
- i915_probe_error(guc_to_gt(guc)->i915, "Failed to %s GuC RC
(%pe)\n",
-str_enable_disable(enable), ERR_PTR(ret));
+ guc_probe_error(guc, "Failed to %s RC (%pe)\n",
+ str_enable_disable(enable), ERR_PTR(ret));
return ret;
}
- drm_info(>i915->drm, "GuC RC: %s\n",
-str_enabled_disabled(enable));
+ guc_info(guc, "RC: %s\n", str_enabled_disabled(enable));
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index 63464933cbceb..91f4fa499cec4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -9,6 +9,7 @@
#include "i915_drv.h"
#include "i915_reg.h"
#include "intel_guc_slpc.h"
+#include "intel_guc_print.h"
#include "intel_mchbar_regs.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_regs.h"
@@ -171,14 +172,13 @@ static int guc_action_slpc_query(struct intel_guc *guc,
u32 offset)
static int slpc_query_task_state(struct intel_guc_slpc *slpc)
{
struct intel_guc *guc = slpc_to_guc(slpc);
- struct drm_i915_private *i915 = slpc_to_i915(slpc);
u32 offset = intel_guc_ggtt_offset(guc, slpc->vma);
int ret;
ret = guc_action_slpc_query(guc, offset);
if (unlikely(ret))
- i915_probe_error(i915, "Failed to query task state (%pe)\n",
-ERR_PTR(ret));
+ guc_probe_error(guc, "Failed to query task state (%pe)\n",
+ ERR_PTR(ret));
drm_clflush_virt_range(slpc->vaddr, SLPC_PAGE_SIZE_BYTES);
@@ -188,15 +188,14 @@ static int slpc_query_task_state(struct intel_guc_slpc
*slpc)
static int slpc_set_param(struct intel_guc_slpc *slpc, u8 id, u32 value)
{
struct intel_guc *guc = slpc_to_guc(slpc);
- struct drm_i915_private *i915 = slpc_to_i915(slpc);
int ret;
GEM_BUG_ON(id >= SLPC_MAX_PARAM);
ret = guc_action_slpc_set_param(guc, id, value);
if (ret)
- i915_probe_error(i915, "Failed to set param %d to %u (%pe)\n",
-id, value, ERR_PTR(ret));
+ guc_probe_error(guc, "Failed to set param %d to %u (%pe)\n",
+ id, value, ERR_PTR(ret));
return ret;
}
@@ -212,8 +211,8 @@ static int slpc_unset_param(struct intel_guc_slpc *slpc, u8
id)
static int slpc_force_min_freq(struct intel_guc_slpc *slpc, u32 freq)
{
- struct drm_i915_private *i915 = slpc_to_i915(slpc);
struct intel_guc *guc = slpc_to_guc(slpc);
+ struct drm_i915_private *i915 = slpc_to_i915(slpc);
intel_wakeref_t wakeref;
int ret = 0;
@@ -236,8 +235,7 @@ static int slpc_force_min_freq(struct intel_guc_slpc *slpc,
u32 freq)
SLPC_PARAM_GLOBAL_MIN_GT_UNSLICE_FREQ_MHZ,
freq);
if (ret)
- drm_notice(>drm,
- "Failed to send set_param for min freq(%d):
(%d)\n",
+ guc_notice(guc, "Failed to send set_param for min
freq(%d): (%d)\n",
freq, ret);
}
@@ -267,7 +265,6 @@ static void slpc_boost_work(struct work_struct *work)
int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
{
struct intel_guc *guc = slpc_to_guc(slpc);
- struct drm_i915_private *i915 = slpc_to_i915(slpc);
u32 size = PAGE_ALIGN(sizeof(struct slpc_shared_data));
int err;
@@ -275,9 +272,7 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
err = intel_guc_allocate_and_map_vma(guc, size, >vma, (void
**)>vaddr);
if (unlikely(err)) {
- i915_probe_error(i915,
-"Failed to allocate SLPC struct (err=%pe)\n",
-ERR_PTR(err));
+ guc_probe_error(guc, "Failed to allocate SLPC struct
(err=%pe)\n", ERR_PTR(err));
return err;
}
[Intel-gfx] [PATCH 4/6] drm/i915/guc: More debug print updates - GuC selftests
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 35 ++-
.../drm/i915/gt/uc/selftest_guc_hangcheck.c | 23 ++--
.../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 11 +++---
3 files changed, 36 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
index e28518fe8b908..6cc1e9c7a47d6 100644
--- a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
@@ -3,6 +3,7 @@
* Copyright �� 2021 Intel Corporation
*/
+#include "intel_guc_print.h"
#include "selftests/igt_spinner.h"
#include "selftests/intel_scheduler_helpers.h"
@@ -65,7 +66,7 @@ static int intel_guc_scrub_ctbs(void *arg)
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
ret = PTR_ERR(ce);
- drm_err(>i915->drm, "Failed to create context, %d:
%d\n", i, ret);
+ gt_err(gt, "Failed to create context, %d: %d\n", i,
ret);
goto err;
}
@@ -86,7 +87,7 @@ static int intel_guc_scrub_ctbs(void *arg)
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
- drm_err(>i915->drm, "Failed to create request, %d:
%d\n", i, ret);
+ gt_err(gt, "Failed to create request, %d: %d\n", i,
ret);
goto err;
}
@@ -96,7 +97,7 @@ static int intel_guc_scrub_ctbs(void *arg)
for (i = 0; i < 3; ++i) {
ret = i915_request_wait(last[i], 0, HZ);
if (ret < 0) {
- drm_err(>i915->drm, "Last request failed to
complete: %d\n", ret);
+ gt_err(gt, "Last request failed to complete: %d\n",
ret);
goto err;
}
i915_request_put(last[i]);
@@ -113,7 +114,7 @@ static int intel_guc_scrub_ctbs(void *arg)
/* GT will not idle if G2H are lost */
ret = intel_gt_wait_for_idle(gt, HZ);
if (ret < 0) {
- drm_err(>i915->drm, "GT failed to idle: %d\n", ret);
+ gt_err(gt, "GT failed to idle: %d\n", ret);
goto err;
}
@@ -153,7 +154,7 @@ static int intel_guc_steal_guc_ids(void *arg)
ce = kcalloc(GUC_MAX_CONTEXT_ID, sizeof(*ce), GFP_KERNEL);
if (!ce) {
- drm_err(>i915->drm, "Context array allocation failed\n");
+ guc_err(guc, "Context array allocation failed\n");
return -ENOMEM;
}
@@ -167,24 +168,24 @@ static int intel_guc_steal_guc_ids(void *arg)
if (IS_ERR(ce[context_index])) {
ret = PTR_ERR(ce[context_index]);
ce[context_index] = NULL;
- drm_err(>i915->drm, "Failed to create context: %d\n", ret);
+ guc_err(guc, "Failed to create context: %d\n", ret);
goto err_wakeref;
}
ret = igt_spinner_init(, engine->gt);
if (ret) {
- drm_err(>i915->drm, "Failed to create spinner: %d\n", ret);
+ guc_err(guc, "Failed to create spinner: %d\n", ret);
goto err_contexts;
}
spin_rq = igt_spinner_create_request(, ce[context_index],
MI_ARB_CHECK);
if (IS_ERR(spin_rq)) {
ret = PTR_ERR(spin_rq);
- drm_err(>i915->drm, "Failed to create spinner request:
%d\n", ret);
+ guc_err(guc, "Failed to create spinner request: %d\n", ret);
goto err_contexts;
}
ret = request_add_spin(spin_rq, );
if (ret) {
- drm_err(>i915->drm, "Failed to add Spinner request: %d\n",
ret);
+ guc_err(guc, "Failed to add Spinner request: %d\n", ret);
goto err_spin_rq;
}
@@ -194,7 +195,7 @@ static int intel_guc_steal_guc_ids(void *arg)
if (IS_ERR(ce[context_index])) {
ret = PTR_ERR(ce[context_index--]);
ce[context_index] = NULL;
- drm_err(>i915->drm, "Failed to create context:
%d\n", ret);
+ guc_err(guc, "Failed to create context: %d\n", ret);
goto err_spin_rq;
}
@@ -203,7 +204,7 @@ static int intel_guc_steal_guc_ids(void *arg)
ret = PTR_ERR(rq);
rq = NULL;
if (ret != -EAGAIN) {
- drm_err(>i915->drm, "Failed to create
request, %d: %d\n",
+ guc_err(guc, "Failed to create request, %d:
%d\n",
context_index, ret);
goto err_spin_rq;
}
@@ -218,7 +219,7 @@
[Intel-gfx] [PATCH 0/6] More drm_dbg to guc_dbg changes
From: John Harrison Update more print messages to the new scheme. Signed-off-by: John Harrison John Harrison (6): drm/i915/guc: More debug print updates - UC firmware drm/i915/guc: More debug print updates - GSC firmware drm/i915/guc: More debug print updates - GuC reg capture drm/i915/guc: More debug print updates - GuC selftests drm/i915/guc: More debug print updates - GuC SLPC drm/i915/guc: More debug print updates - GuC logging drivers/gpu/drm/i915/gt/intel_gt_print.h | 3 + drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 8 +- drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 7 +- .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 51 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 3 +- drivers/gpu/drm/i915/gt/uc/intel_guc_print.h | 3 + drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 8 +- drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 60 - drivers/gpu/drm/i915/gt/uc/intel_uc.c | 42 +++ drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 116 +- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 35 +++--- .../drm/i915/gt/uc/selftest_guc_hangcheck.c | 23 ++-- .../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 11 +- 13 files changed, 169 insertions(+), 201 deletions(-) -- 2.39.1
[Intel-gfx] [PATCH 3/6] drm/i915/guc: More debug print updates - GuC reg capture
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 51 ---
1 file changed, 21 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
index fc3b994626a4f..5f6e3594dda62 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
@@ -15,6 +15,7 @@
#include "guc_capture_fwif.h"
#include "intel_guc_capture.h"
#include "intel_guc_fwif.h"
+#include "intel_guc_print.h"
#include "i915_drv.h"
#include "i915_gpu_error.h"
#include "i915_irq.h"
@@ -353,7 +354,6 @@ guc_capture_alloc_steered_lists_xe_hpg(struct intel_guc
*guc,
u32 ipver)
{
struct intel_gt *gt = guc_to_gt(guc);
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct sseu_dev_info *sseu;
int slice, subslice, i, iter, num_steer_regs, num_tot_regs = 0;
const struct __guc_mmio_reg_descr_group *list;
@@ -402,7 +402,7 @@ guc_capture_alloc_steered_lists_xe_hpg(struct intel_guc
*guc,
}
}
- drm_dbg(>drm, "GuC-capture found %d-ext-regs.\n", num_tot_regs);
+ guc_dbg(guc, "capture found %d ext-regs.\n", num_tot_regs);
guc->capture->extlists = extlists;
}
@@ -477,7 +477,6 @@ guc_capture_list_init(struct intel_guc *guc, u32 owner, u32
type, u32 classid,
struct guc_mmio_reg *ptr, u16 num_entries)
{
u32 i = 0, j = 0;
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
const struct __guc_mmio_reg_descr_group *reglists =
guc->capture->reglists;
struct __guc_mmio_reg_descr_group *extlists = guc->capture->extlists;
const struct __guc_mmio_reg_descr_group *match;
@@ -509,8 +508,7 @@ guc_capture_list_init(struct intel_guc *guc, u32 owner, u32
type, u32 classid,
}
}
if (i < num_entries)
- drm_dbg(>drm, "GuC-capture: Init reglist short %d out
%d.\n",
- (int)i, (int)num_entries);
+ guc_dbg(guc, "Got short capture reglist init: %d out %d.\n", i,
num_entries);
return 0;
}
@@ -540,12 +538,11 @@ guc_capture_getlistsize(struct intel_guc *guc, u32 owner,
u32 type, u32 classid,
size_t *size, bool is_purpose_est)
{
struct intel_guc_state_capture *gc = guc->capture;
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct __guc_capture_ads_cache *cache =
>ads_cache[owner][type][classid];
int num_regs;
if (!gc->reglists) {
- drm_warn(>drm, "GuC-capture: No reglist on this
device\n");
+ guc_warn(guc, "No capture reglist for this device\n");
return -ENODEV;
}
@@ -557,9 +554,9 @@ guc_capture_getlistsize(struct intel_guc *guc, u32 owner,
u32 type, u32 classid,
if (!is_purpose_est && owner == GUC_CAPTURE_LIST_INDEX_PF &&
!guc_capture_get_one_list(gc->reglists, owner, type, classid)) {
if (type == GUC_CAPTURE_LIST_TYPE_GLOBAL)
- drm_warn(>drm, "Missing GuC-Err-Cap reglist
Global!\n");
+ guc_warn(guc, "Missing capture reglist: global!\n");
else
- drm_warn(>drm, "Missing GuC-Err-Cap reglist
%s(%u):%s(%u)!\n",
+ guc_warn(guc, "Missing capture reglist:
%s(%u):%s(%u)!\n",
__stringify_type(type), type,
__stringify_engclass(classid), classid);
return -ENODATA;
@@ -592,7 +589,6 @@ intel_guc_capture_getlist(struct intel_guc *guc, u32 owner,
u32 type, u32 classi
{
struct intel_guc_state_capture *gc = guc->capture;
struct __guc_capture_ads_cache *cache =
>ads_cache[owner][type][classid];
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
struct guc_debug_capture_list *listnode;
int ret, num_regs;
u8 *caplist, *tmp;
@@ -623,7 +619,7 @@ intel_guc_capture_getlist(struct intel_guc *guc, u32 owner,
u32 type, u32 classi
caplist = kzalloc(size, GFP_KERNEL);
if (!caplist) {
- drm_dbg(>drm, "GuC-capture: failed to alloc cached
caplist");
+ guc_dbg(guc, "Failed to alloc cached register capture list");
return -ENOMEM;
}
@@ -653,7 +649,6 @@ intel_guc_capture_getnullheader(struct intel_guc *guc,
void **outptr, size_t *size)
{
struct intel_guc_state_capture *gc = guc->capture;
- struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
int tmp = sizeof(u32) * 4;
void *null_header;
@@ -665,7 +660,7 @@ intel_guc_capture_getnullheader(struct intel_guc *guc,
null_header = kzalloc(tmp, GFP_KERNEL);
if
[Intel-gfx] [PATCH 1/6] drm/i915/guc: More debug print updates - UC firmware
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 42
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 116 +++
2 files changed, 73 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index de7f987cf6111..6648691bd6450 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -83,15 +83,15 @@ static int __intel_uc_reset_hw(struct intel_uc *uc)
static void __confirm_options(struct intel_uc *uc)
{
- struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
+ struct intel_gt *gt = uc_to_gt(uc);
+ struct drm_i915_private *i915 = gt->i915;
- drm_dbg(>drm,
- "enable_guc=%d (guc:%s submission:%s huc:%s slpc:%s)\n",
- i915->params.enable_guc,
- str_yes_no(intel_uc_wants_guc(uc)),
- str_yes_no(intel_uc_wants_guc_submission(uc)),
- str_yes_no(intel_uc_wants_huc(uc)),
- str_yes_no(intel_uc_wants_guc_slpc(uc)));
+ gt_dbg(gt, "enable_guc=%d (guc:%s submission:%s huc:%s slpc:%s)\n",
+ i915->params.enable_guc,
+ str_yes_no(intel_uc_wants_guc(uc)),
+ str_yes_no(intel_uc_wants_guc_submission(uc)),
+ str_yes_no(intel_uc_wants_huc(uc)),
+ str_yes_no(intel_uc_wants_guc_slpc(uc)));
if (i915->params.enable_guc == 0) {
GEM_BUG_ON(intel_uc_wants_guc(uc));
@@ -102,26 +102,22 @@ static void __confirm_options(struct intel_uc *uc)
}
if (!intel_uc_supports_guc(uc))
- drm_info(>drm,
-"Incompatible option enable_guc=%d - %s\n",
-i915->params.enable_guc, "GuC is not supported!");
+ gt_info(gt, "Incompatible option enable_guc=%d - %s\n",
+ i915->params.enable_guc, "GuC is not supported!");
if (i915->params.enable_guc & ENABLE_GUC_LOAD_HUC &&
!intel_uc_supports_huc(uc))
- drm_info(>drm,
-"Incompatible option enable_guc=%d - %s\n",
-i915->params.enable_guc, "HuC is not supported!");
+ gt_info(gt, "Incompatible option enable_guc=%d - %s\n",
+ i915->params.enable_guc, "HuC is not supported!");
if (i915->params.enable_guc & ENABLE_GUC_SUBMISSION &&
!intel_uc_supports_guc_submission(uc))
- drm_info(>drm,
-"Incompatible option enable_guc=%d - %s\n",
-i915->params.enable_guc, "GuC submission is N/A");
+ gt_info(gt, "Incompatible option enable_guc=%d - %s\n",
+ i915->params.enable_guc, "GuC submission is N/A");
if (i915->params.enable_guc & ~ENABLE_GUC_MASK)
- drm_info(>drm,
-"Incompatible option enable_guc=%d - %s\n",
-i915->params.enable_guc, "undocumented flag");
+ gt_info(gt, "Incompatible option enable_guc=%d - %s\n",
+ i915->params.enable_guc, "undocumented flag");
}
void intel_uc_init_early(struct intel_uc *uc)
@@ -549,10 +545,8 @@ static int __uc_init_hw(struct intel_uc *uc)
intel_gsc_uc_load_start(>gsc);
- gt_info(gt, "GuC submission %s\n",
- str_enabled_disabled(intel_uc_uses_guc_submission(uc)));
- gt_info(gt, "GuC SLPC %s\n",
- str_enabled_disabled(intel_uc_uses_guc_slpc(uc)));
+ guc_info(guc, "submission %s\n",
str_enabled_disabled(intel_uc_uses_guc_submission(uc)));
+ guc_info(guc, "SLPC %s\n",
str_enabled_disabled(intel_uc_uses_guc_slpc(uc)));
return 0;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 65672ff826054..7d2558d53e972 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -11,6 +11,7 @@
#include
#include "gem/i915_gem_lmem.h"
+#include "gt/intel_gt_print.h"
#include "intel_uc_fw.h"
#include "intel_uc_fw_abi.h"
#include "i915_drv.h"
@@ -44,11 +45,10 @@ void intel_uc_fw_change_status(struct intel_uc_fw *uc_fw,
enum intel_uc_fw_status status)
{
uc_fw->__status = status;
- drm_dbg(&__uc_fw_to_gt(uc_fw)->i915->drm,
- "%s firmware -> %s\n",
- intel_uc_fw_type_repr(uc_fw->type),
- status == INTEL_UC_FIRMWARE_SELECTED ?
- uc_fw->file_selected.path : intel_uc_fw_status_repr(status));
+ gt_dbg(__uc_fw_to_gt(uc_fw), "%s firmware -> %s\n",
+ intel_uc_fw_type_repr(uc_fw->type),
+ status == INTEL_UC_FIRMWARE_SELECTED ?
+ uc_fw->file_selected.path : intel_uc_fw_status_repr(status));
}
#endif
Re: [Intel-gfx] [PATCH] drm/i915/huc: Add and use HuC oriented print macros
On 1/31/2023 2:28 PM, Michal Wajdeczko wrote:
Like we did it for GuC, introduce some helper print macros for
HuC to have unified format of messages that also include GT#.
While around improve some messages and use %pe if possible.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 44 ++
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 410905da8e97..834e3b5b8f4b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,6 +6,7 @@
#include
#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
#include "intel_guc_reg.h"
#include "intel_huc.h"
#include "i915_drv.h"
@@ -13,6 +14,15 @@
#include
#include
+#define huc_printk(_huc, _level, _fmt, ...) \
+ gt_##_level(huc_to_gt(_huc), "HuC: " _fmt, ##__VA_ARGS__)
+#define huc_err(_huc, _fmt, ...) huc_printk((_huc), err, _fmt,
##__VA_ARGS__)
+#define huc_warn(_huc, _fmt, ...) huc_printk((_huc), warn, _fmt,
##__VA_ARGS__)
+#define huc_notice(_huc, _fmt, ...)huc_printk((_huc), notice, _fmt,
##__VA_ARGS__)
+#define huc_info(_huc, _fmt, ...) huc_printk((_huc), info, _fmt,
##__VA_ARGS__)
+#define huc_dbg(_huc, _fmt, ...) huc_printk((_huc), dbg, _fmt,
##__VA_ARGS__)
+#define huc_probe_error(_huc, _fmt, ...) huc_printk((_huc), probe_error, _fmt,
##__VA_ARGS__)
+
/**
* DOC: HuC
*
@@ -107,11 +117,9 @@ static enum hrtimer_restart
huc_delayed_load_timer_callback(struct hrtimer *hrti
if (!intel_huc_is_authenticated(huc)) {
if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_GSC)
- drm_notice(_to_gt(huc)->i915->drm,
- "timed out waiting for MEI GSC init to load
HuC\n");
+ huc_notice(huc, "load timed out waiting for MEI GSC\n");
I think this rewording makes the error message less clear. We didn't
time out loading HuC, we timed out waiting for the required components
to be ready before we even started the load process. Same for the one below.
Apart from this the patch LGTM.
Daniele
else if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_PXP)
- drm_notice(_to_gt(huc)->i915->drm,
- "timed out waiting for MEI PXP init to load
HuC\n");
+ huc_notice(huc, "load timed out waiting for MEI PXP\n");
else
MISSING_CASE(huc->delayed_load.status);
@@ -174,8 +182,7 @@ static int gsc_notifier(struct notifier_block *nb, unsigned long action, void *d
case BUS_NOTIFY_DRIVER_NOT_BOUND: /* mei driver fails to be bound */
case BUS_NOTIFY_UNBIND_DRIVER: /* mei driver about to be unbound */
- drm_info(_to_gt(huc)->i915->drm,
-"mei driver not bound, disabling HuC load\n");
+ huc_info(huc, "MEI driver not bound, disabling load\n");
gsc_init_error(huc);
break;
}
@@ -193,8 +200,7 @@ void intel_huc_register_gsc_notifier(struct intel_huc *huc,
struct bus_type *bus
huc->delayed_load.nb.notifier_call = gsc_notifier;
ret = bus_register_notifier(bus, >delayed_load.nb);
if (ret) {
- drm_err(_to_gt(huc)->i915->drm,
- "failed to register GSC notifier\n");
+ huc_err(huc, "failed to register GSC notifier %pe\n",
ERR_PTR(ret));
huc->delayed_load.nb.notifier_call = NULL;
gsc_init_error(huc);
}
@@ -306,29 +312,25 @@ static int check_huc_loading_mode(struct intel_huc *huc)
GSC_LOADS_HUC;
if (fw_needs_gsc != hw_uses_gsc) {
- drm_err(>i915->drm,
- "mismatch between HuC FW (%s) and HW (%s) load modes\n",
- HUC_LOAD_MODE_STRING(fw_needs_gsc),
- HUC_LOAD_MODE_STRING(hw_uses_gsc));
+ huc_err(huc, "mismatch between FW (%s) and HW (%s) load
modes\n",
+ HUC_LOAD_MODE_STRING(fw_needs_gsc),
HUC_LOAD_MODE_STRING(hw_uses_gsc));
return -ENOEXEC;
}
/* make sure we can access the GSC via the mei driver if we need it */
if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) && IS_ENABLED(CONFIG_INTEL_MEI_GSC))
&&
fw_needs_gsc) {
- drm_info(>i915->drm,
-"Can't load HuC due to missing MEI modules\n");
+ huc_info(huc, "can't load due to missing MEI modules\n");
return -EIO;
}
- drm_dbg(>i915->drm, "GSC loads huc=%s\n", str_yes_no(fw_needs_gsc));
+ huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(fw_needs_gsc));
return 0;
}
int intel_huc_init(struct intel_huc *huc)
{
- struct drm_i915_private
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hwmon: Enable PL1 power limit (rev3)
== Series Details ==
Series: drm/i915/hwmon: Enable PL1 power limit (rev3)
URL : https://patchwork.freedesktop.org/series/113578/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12686 -> Patchwork_113578v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/index.html
Participating hosts (26 -> 26)
--
Additional (1): fi-kbl-soraka
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113578v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][3] ([i915#7156])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][4] ([i915#1886])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271]) +15 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-n3050: [PASS][6] -> [FAIL][7] ([i915#6298])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
Possible fixes
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][8] ([i915#6367]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/bat-rpls-1/igt@i915_selftest@l...@slpc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7156]: https://gitlab.freedesktop.org/drm/intel/issues/7156
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
Build changes
-
* Linux: CI_DRM_12686 -> Patchwork_113578v3
CI-20190529: 20190529
CI_DRM_12686: 0b50be56bb4863e926efa2d89754d654fad828b9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7144: cda71bf809b981a646270963d6b1ccee4fd4643b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113578v3: 0b50be56bb4863e926efa2d89754d654fad828b9 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
e4e5673771f0 drm/i915/hwmon: Enable PL1 power limit
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v3/index.html
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: add guard page to ggtt->error_capture (rev2)
== Series Details ==
Series: drm/i915: add guard page to ggtt->error_capture (rev2)
URL : https://patchwork.freedesktop.org/series/113560/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12686 -> Patchwork_113560v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_113560v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_113560v2, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v2/index.html
Participating hosts (26 -> 25)
--
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113560v2:
### IGT changes ###
Possible regressions
* igt@i915_module_load@load:
- fi-blb-e6850: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/fi-blb-e6850/igt@i915_module_l...@load.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v2/fi-blb-e6850/igt@i915_module_l...@load.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@requests:
- {bat-rpls-1}: [PASS][3] -> [ABORT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-rpls-1/igt@i915_selftest@l...@requests.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v2/bat-rpls-1/igt@i915_selftest@l...@requests.html
Known issues
Here are the changes found in Patchwork_113560v2 that come from known issues:
### IGT changes ###
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
Build changes
-
* Linux: CI_DRM_12686 -> Patchwork_113560v2
CI-20190529: 20190529
CI_DRM_12686: 0b50be56bb4863e926efa2d89754d654fad828b9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7144: cda71bf809b981a646270963d6b1ccee4fd4643b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113560v2: 0b50be56bb4863e926efa2d89754d654fad828b9 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
4686bf2d3d9f drm/i915: add guard page to ggtt->error_capture
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113560v2/index.html
Re: [Intel-gfx] [PATCH v3] vfio: fix deadlock between group lock and kvm lock
On Thu, 2 Feb 2023 23:04:10 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Friday, February 3, 2023 3:42 AM
> >
> > On Thu, 2 Feb 2023 11:24:42 -0500
> > Matthew Rosato wrote:
> >
> > > After 51cdc8bc120e, we have another deadlock scenario between the
> > > kvm->lock and the vfio group_lock with two different codepaths acquiring
> > > the locks in different order. Specifically in vfio_open_device, vfio
> > > holds the vfio group_lock when issuing device->ops->open_device but
> > some
> > > drivers (like vfio-ap) need to acquire kvm->lock during their open_device
> > > routine; Meanwhile, kvm_vfio_release will acquire the kvm->lock first
> > > before calling vfio_file_set_kvm which will acquire the vfio group_lock.
> > >
> > > To resolve this, let's remove the need for the vfio group_lock from the
> > > kvm_vfio_release codepath. This is done by introducing a new spinlock to
> > > protect modifications to the vfio group kvm pointer, and acquiring a kvm
> > > ref from within vfio while holding this spinlock, with the reference held
> > > until the last close for the device in question.
> > >
> > > Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio
> > > group_lock")
> > > Reported-by: Anthony Krowiak
> > > Suggested-by: Jason Gunthorpe
> > > Signed-off-by: Matthew Rosato
> > > ---
> > > Changes from v2:
> > > * Relocate the new functions back to vfio_main and externalize to call
> > > from group (Kevin) since cdev will need this too
> > > * s/vfio_kvm_*_kvm/vfio_device_*_kvm/ and only pass device as input.
> > > Handle new kvm_ref_lock directly inside vfio_device_get_kvm (Alex)
> > > * Add assert_lockdep_held for dev_set lock (Alex)
> > > * Internalize error paths for vfio_device_get_kvm_safe and now return
> > > void - either device->kvm is set with a ref taken or is NULL (Alex)
> > > * Other flow suggestions to make the call path cleaner - Thanks! (Alex)
> > > * Can't pass group->kvm to vfio_device_open, as it references the value
> > > outside of new lock. Pass device->kvm to minimize changes in this
> > > fix (Alex, Yi)
> > > Changes from v1:
> > > * use spin_lock instead of spin_lock_irqsave (Jason)
> > > * clear device->kvm_put as part of vfio_kvm_put_kvm (Yi)
> > > * Re-arrange code to avoid referencing the group contents from within
> > > vfio_main (Kevin) which meant moving most of the code in this patch
> > > to group.c along with getting/dropping of the dev_set lock
> > > ---
> > > drivers/vfio/group.c | 32 ++
> > > drivers/vfio/vfio.h | 14
> > > drivers/vfio/vfio_main.c | 70 --
> > --
> > > include/linux/vfio.h | 2 +-
> > > 4 files changed, 103 insertions(+), 15 deletions(-)
> >
> > LGTM. I'm not sure moving the functions to vfio_main really buys us
> > anything since we're making so much use of group fields. The cdev
> > approach will necessarily be different, so the bulk of the get code will
> > likely need to move back to group.c anyway.
> >
>
> well my last comment was based on Matthew's v2 where the get code
> gets a kvm passed in instead of implicitly retrieving group ref_lock
> internally. In that case the get/put helpers only contain device logic
> thus fit in vfio_main.c.
>
> with v3 then they have to be in group.c since we don't want to use
> group fields in vfio_main.c.
>
> but I still think v2 of the helpers is slightly better. The only difference
> between cdev and group when handling this race is using different
> ref_lock. the symbol get/put part is exactly same. So even if we
> merge v3 like this, very likely Yi has to change it back to v2 style
> to share the get/put helpers while just leaving the ref_lock part
> handled differently between the two path.
I'm not really a fan of the asymmetry of the v2 version where the get
helper needs to be called under the new kvm_ref_lock, but the put
helper does not. Having the get helper handle that makes the caller
much cleaner. Thanks,
Alex
Re: [Intel-gfx] [PATCH v3] vfio: fix deadlock between group lock and kvm lock
> From: Alex Williamson
> Sent: Friday, February 3, 2023 3:42 AM
>
> On Thu, 2 Feb 2023 11:24:42 -0500
> Matthew Rosato wrote:
>
> > After 51cdc8bc120e, we have another deadlock scenario between the
> > kvm->lock and the vfio group_lock with two different codepaths acquiring
> > the locks in different order. Specifically in vfio_open_device, vfio
> > holds the vfio group_lock when issuing device->ops->open_device but
> some
> > drivers (like vfio-ap) need to acquire kvm->lock during their open_device
> > routine; Meanwhile, kvm_vfio_release will acquire the kvm->lock first
> > before calling vfio_file_set_kvm which will acquire the vfio group_lock.
> >
> > To resolve this, let's remove the need for the vfio group_lock from the
> > kvm_vfio_release codepath. This is done by introducing a new spinlock to
> > protect modifications to the vfio group kvm pointer, and acquiring a kvm
> > ref from within vfio while holding this spinlock, with the reference held
> > until the last close for the device in question.
> >
> > Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio group_lock")
> > Reported-by: Anthony Krowiak
> > Suggested-by: Jason Gunthorpe
> > Signed-off-by: Matthew Rosato
> > ---
> > Changes from v2:
> > * Relocate the new functions back to vfio_main and externalize to call
> > from group (Kevin) since cdev will need this too
> > * s/vfio_kvm_*_kvm/vfio_device_*_kvm/ and only pass device as input.
> > Handle new kvm_ref_lock directly inside vfio_device_get_kvm (Alex)
> > * Add assert_lockdep_held for dev_set lock (Alex)
> > * Internalize error paths for vfio_device_get_kvm_safe and now return
> > void - either device->kvm is set with a ref taken or is NULL (Alex)
> > * Other flow suggestions to make the call path cleaner - Thanks! (Alex)
> > * Can't pass group->kvm to vfio_device_open, as it references the value
> > outside of new lock. Pass device->kvm to minimize changes in this
> > fix (Alex, Yi)
> > Changes from v1:
> > * use spin_lock instead of spin_lock_irqsave (Jason)
> > * clear device->kvm_put as part of vfio_kvm_put_kvm (Yi)
> > * Re-arrange code to avoid referencing the group contents from within
> > vfio_main (Kevin) which meant moving most of the code in this patch
> > to group.c along with getting/dropping of the dev_set lock
> > ---
> > drivers/vfio/group.c | 32 ++
> > drivers/vfio/vfio.h | 14
> > drivers/vfio/vfio_main.c | 70 --
> --
> > include/linux/vfio.h | 2 +-
> > 4 files changed, 103 insertions(+), 15 deletions(-)
>
> LGTM. I'm not sure moving the functions to vfio_main really buys us
> anything since we're making so much use of group fields. The cdev
> approach will necessarily be different, so the bulk of the get code will
> likely need to move back to group.c anyway.
>
well my last comment was based on Matthew's v2 where the get code
gets a kvm passed in instead of implicitly retrieving group ref_lock
internally. In that case the get/put helpers only contain device logic
thus fit in vfio_main.c.
with v3 then they have to be in group.c since we don't want to use
group fields in vfio_main.c.
but I still think v2 of the helpers is slightly better. The only difference
between cdev and group when handling this race is using different
ref_lock. the symbol get/put part is exactly same. So even if we
merge v3 like this, very likely Yi has to change it back to v2 style
to share the get/put helpers while just leaving the ref_lock part
handled differently between the two path.
Thanks
Kevin
[Intel-gfx] ✓ Fi.CI.IGT: success for vfio: fix deadlock between group lock and kvm lock (rev5)
== Series Details ==
Series: vfio: fix deadlock between group lock and kvm lock (rev5)
URL : https://patchwork.freedesktop.org/series/113535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12684_full -> Patchwork_113535v5_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113535v5_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@gem-execbuf@smem0:
- {shard-tglu}: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-tglu-7/igt@i915_pm_rpm@gem-exec...@smem0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/shard-tglu-8/igt@i915_pm_rpm@gem-exec...@smem0.html
* igt@perf_pmu@module-unload:
- {shard-tglu}: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-tglu-7/igt@perf_...@module-unload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/shard-tglu-8/igt@perf_...@module-unload.html
Known issues
Here are the changes found in Patchwork_113535v5_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2846])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-glk1/igt@gem_exec_f...@basic-deadline.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/shard-glk9/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][9] -> [ABORT][10] ([i915#5566])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-glk6/igt@gen9_exec_pa...@allowed-single.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/shard-glk3/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#2346])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-glk2/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/shard-glk6/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
Possible fixes
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- {shard-rkl}:[DMESG-WARN][13] ([i915#5122]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-4/igt@gem_ctx_isolation@preservation...@bcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/shard-rkl-1/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_ctx_isolation@preservation-s3@rcs0:
- {shard-rkl}:[ABORT][15] -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-4/igt@gem_ctx_isolation@preservation...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/shard-rkl-1/igt@gem_ctx_isolation@preservation...@rcs0.html
* igt@gem_ctx_persistence@many-contexts:
- {shard-rkl}:[INCOMPLETE][17] -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-3/igt@gem_ctx_persiste...@many-contexts.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/shard-rkl-4/igt@gem_ctx_persiste...@many-contexts.html
* igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][19] ([i915#2842]) -> [PASS][20] +3 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-1/igt@gem_exec_fair@basic-n...@vcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/shard-rkl-5/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_reloc@basic-wc-gtt:
- {shard-rkl}:[SKIP][21] ([i915#3281]) -> [PASS][22] +4 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-3/igt@gem_exec_re...@basic-wc-gtt.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/shard-rkl-5/igt@gem_exec_re...@basic-wc-gtt.html
* igt@gem_set_tiling_vs_pwrite:
- {shard-rkl}:[SKIP][23] ([i915#3282]) -> [PASS][24] +2 similar
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dmc: allocate dmc struct dynamically
== Series Details ==
Series: drm/i915/dmc: allocate dmc struct dynamically
URL : https://patchwork.freedesktop.org/series/113622/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12686 -> Patchwork_113622v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_113622v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_113622v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113622v1/index.html
Participating hosts (26 -> 25)
--
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113622v1:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@basic-pci-d3-state:
- bat-dg1-6: [PASS][1] -> [SKIP][2] +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-dg1-6/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113622v1/bat-dg1-6/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- bat-dg1-5: [PASS][3] -> [SKIP][4] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-dg1-5/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113622v1/bat-dg1-5/igt@i915_pm_...@module-reload.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@dmabuf@all-tests@dma_fence:
- {bat-adln-1}: [PASS][5] -> [DMESG-FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113622v1/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html
* igt@dmabuf@all-tests@sanitycheck:
- {bat-adln-1}: [PASS][7] -> [ABORT][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113622v1/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {bat-adlm-1}: [PASS][9] -> [SKIP][10] +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-adlm-1/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113622v1/bat-adlm-1/igt@i915_pm_...@basic-pci-d3-state.html
- {bat-jsl-1}:[PASS][11] -> [SKIP][12] +2 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-jsl-1/igt@i915_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113622v1/bat-jsl-1/igt@i915_pm_...@basic-pci-d3-state.html
- {bat-rpls-1}: [PASS][13] -> [SKIP][14] +2 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-rpls-1/igt@i915_pm_...@basic-pci-d3-state.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113622v1/bat-rpls-1/igt@i915_pm_...@basic-pci-d3-state.html
- {bat-adlp-9}: [PASS][15] -> [SKIP][16] +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-adlp-9/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113622v1/bat-adlp-9/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@basic-rte:
- {bat-rplp-1}: [PASS][17] -> [SKIP][18] +2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-rplp-1/igt@i915_pm_...@basic-rte.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113622v1/bat-rplp-1/igt@i915_pm_...@basic-rte.html
- {bat-jsl-3}:[PASS][19] -> [SKIP][20] +2 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-jsl-3/igt@i915_pm_...@basic-rte.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113622v1/bat-jsl-3/igt@i915_pm_...@basic-rte.html
- {bat-rpls-2}: [PASS][21] -> [SKIP][22] +2 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-rpls-2/igt@i915_pm_...@basic-rte.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113622v1/bat-rpls-2/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- {bat-adlp-6}: [PASS][23] -> [SKIP][24] +2 similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12686/bat-adlp-6/igt@i915_pm_...@module-reload.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113622v1/bat-adlp-6/igt@i915_pm_...@module-reload.html
- {bat-dg1-7}:[PASS][25] -> [SKIP][26] +2 similar issues
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dmc: allocate dmc struct dynamically
== Series Details == Series: drm/i915/dmc: allocate dmc struct dynamically URL : https://patchwork.freedesktop.org/series/113622/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [RFC 3/3] drm/i915/dmc: allocate dmc structure dynamically
sizeof(struct intel_dmc) > 1024 bytes, allocated on all platforms as
part of struct drm_i915_private, whether they have DMC or not.
Allocate struct intel_dmc dynamically, and hide all the dmc details
behind an opaque pointer in intel_dmc.c.
Care must be taken to take into account all cases: DMC not supported on
the platform, DMC supported but not initialized, and DMC initialized but
not loaded. For the second case, we need to move the wakeref out of
struct intel_dmc.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_display_core.h | 8 +-
drivers/gpu/drm/i915/display/intel_dmc.c | 136 +-
drivers/gpu/drm/i915/display/intel_dmc.h | 33 +
.../drm/i915/display/intel_modeset_setup.c| 1 +
4 files changed, 105 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index fb8670aa2932..e517e06d76a0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -19,7 +19,6 @@
#include "intel_cdclk.h"
#include "intel_display_limits.h"
#include "intel_display_power.h"
-#include "intel_dmc.h"
#include "intel_dpll_mgr.h"
#include "intel_fbc.h"
#include "intel_global_state.h"
@@ -40,6 +39,7 @@ struct intel_cdclk_vals;
struct intel_color_funcs;
struct intel_crtc;
struct intel_crtc_state;
+struct intel_dmc;
struct intel_dpll_funcs;
struct intel_dpll_mgr;
struct intel_fbdev;
@@ -339,6 +339,11 @@ struct intel_display {
spinlock_t phy_lock;
} dkl;
+ struct {
+ struct intel_dmc *dmc;
+ intel_wakeref_t wakeref;
+ } dmc;
+
struct {
/* VLV/CHV/BXT/GLK DSI MMIO register base address */
u32 mmio_base;
@@ -466,7 +471,6 @@ struct intel_display {
/* Grouping using named structs. Keep sorted. */
struct intel_audio audio;
- struct intel_dmc dmc;
struct intel_dpll dpll;
struct intel_fbc *fbc[I915_MAX_FBCS];
struct intel_frontbuffer_tracking fb_tracking;
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index ab4fdedd4c5f..8428d08e0c3d 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -38,6 +38,39 @@
* low-power state and comes back to normal.
*/
+enum intel_dmc_id {
+ DMC_FW_MAIN = 0,
+ DMC_FW_PIPEA,
+ DMC_FW_PIPEB,
+ DMC_FW_PIPEC,
+ DMC_FW_PIPED,
+ DMC_FW_MAX
+};
+
+struct intel_dmc {
+ struct drm_i915_private *i915;
+ struct work_struct work;
+ const char *fw_path;
+ u32 max_fw_size; /* bytes */
+ u32 version;
+ struct dmc_fw_info {
+ u32 mmio_count;
+ i915_reg_t mmioaddr[20];
+ u32 mmiodata[20];
+ u32 dmc_offset;
+ u32 start_mmioaddr;
+ u32 dmc_fw_size; /*dwords */
+ u32 *payload;
+ bool present;
+ } dmc_info[DMC_FW_MAX];
+};
+
+/* Note: This may be NULL. */
+static struct intel_dmc *i915_to_dmc(struct drm_i915_private *i915)
+{
+ return i915->display.dmc.dmc;
+}
+
#define DMC_VERSION(major, minor) ((major) << 16 | (minor))
#define DMC_VERSION_MAJOR(version) ((version) >> 16)
#define DMC_VERSION_MINOR(version) ((version) & 0x)
@@ -259,7 +292,9 @@ static bool is_valid_dmc_id(enum intel_dmc_id dmc_id)
static bool has_dmc_id_fw(struct drm_i915_private *i915, enum intel_dmc_id
dmc_id)
{
- return i915->display.dmc.dmc_info[dmc_id].payload;
+ struct intel_dmc *dmc = i915_to_dmc(i915);
+
+ return dmc && dmc->dmc_info[dmc_id].payload;
}
bool intel_dmc_has_payload(struct drm_i915_private *i915)
@@ -450,7 +485,7 @@ void intel_dmc_disable_pipe(struct drm_i915_private *i915,
enum pipe pipe)
void intel_dmc_load_program(struct drm_i915_private *dev_priv)
{
struct i915_power_domains *power_domains =
_priv->display.power.domains;
- struct intel_dmc *dmc = _priv->display.dmc;
+ struct intel_dmc *dmc = i915_to_dmc(dev_priv);
enum intel_dmc_id dmc_id;
u32 i;
@@ -515,8 +550,11 @@ void intel_dmc_disable_program(struct drm_i915_private
*i915)
void assert_dmc_loaded(struct drm_i915_private *i915)
{
- drm_WARN_ONCE(>drm,
- !intel_de_read(i915,
DMC_PROGRAM(i915->display.dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),
+ struct intel_dmc *dmc = i915_to_dmc(i915);
+
+ drm_WARN_ONCE(>drm, !dmc, "DMC not initialized\n");
+ drm_WARN_ONCE(>drm, dmc &&
+ !intel_de_read(i915,
DMC_PROGRAM(dmc->dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),
"DMC program storage start is NULL\n");
drm_WARN_ONCE(>drm, !intel_de_read(i915, DMC_SSP_BASE),
"DMC SSP Base Not fine\n");
@@ -551,11 +589,10 @@
[Intel-gfx] [RFC 2/3] drm/i915/dmc: drop "ucode" from function names
The ucode part in the init, fini, suspend and resume function names is
just unnecessary. Drop it.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
drivers/gpu/drm/i915/display/intel_dmc.c | 20 ++--
drivers/gpu/drm/i915/display/intel_dmc.h | 8
drivers/gpu/drm/i915/i915_driver.c | 6 +++---
4 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 12ade593..a8c91fda40a8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8639,7 +8639,7 @@ int intel_modeset_init_noirq(struct drm_i915_private
*i915)
if (!HAS_DISPLAY(i915))
return 0;
- intel_dmc_ucode_init(i915);
+ intel_dmc_init(i915);
i915->display.wq.modeset = alloc_ordered_workqueue("i915_modeset", 0);
i915->display.wq.flip = alloc_workqueue("i915_flip", WQ_HIGHPRI |
@@ -8674,7 +8674,7 @@ int intel_modeset_init_noirq(struct drm_i915_private
*i915)
return 0;
cleanup_vga_client_pw_domain_dmc:
- intel_dmc_ucode_fini(i915);
+ intel_dmc_fini(i915);
intel_power_domains_driver_remove(i915);
intel_vga_unregister(i915);
cleanup_bios:
@@ -9000,7 +9000,7 @@ void intel_modeset_driver_remove_noirq(struct
drm_i915_private *i915)
/* part #3: call after gem init */
void intel_modeset_driver_remove_nogem(struct drm_i915_private *i915)
{
- intel_dmc_ucode_fini(i915);
+ intel_dmc_fini(i915);
intel_power_domains_driver_remove(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 30a2d0e677d3..ab4fdedd4c5f 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -919,13 +919,13 @@ static void dmc_load_work_fn(struct work_struct *work)
}
/**
- * intel_dmc_ucode_init() - initialize the firmware loading.
+ * intel_dmc_init() - initialize the firmware loading.
* @dev_priv: i915 drm device.
*
* This function is called at the time of loading the display driver to read
* firmware from a .bin file and copied into a internal memory.
*/
-void intel_dmc_ucode_init(struct drm_i915_private *dev_priv)
+void intel_dmc_init(struct drm_i915_private *dev_priv)
{
struct intel_dmc *dmc = _priv->display.dmc;
@@ -1003,14 +1003,14 @@ void intel_dmc_ucode_init(struct drm_i915_private
*dev_priv)
}
/**
- * intel_dmc_ucode_suspend() - prepare DMC firmware before system suspend
+ * intel_dmc_suspend() - prepare DMC firmware before system suspend
* @dev_priv: i915 drm device
*
* Prepare the DMC firmware before entering system suspend. This includes
* flushing pending work items and releasing any resources acquired during
* init.
*/
-void intel_dmc_ucode_suspend(struct drm_i915_private *dev_priv)
+void intel_dmc_suspend(struct drm_i915_private *dev_priv)
{
if (!HAS_DMC(dev_priv))
return;
@@ -1023,13 +1023,13 @@ void intel_dmc_ucode_suspend(struct drm_i915_private
*dev_priv)
}
/**
- * intel_dmc_ucode_resume() - init DMC firmware during system resume
+ * intel_dmc_resume() - init DMC firmware during system resume
* @dev_priv: i915 drm device
*
* Reinitialize the DMC firmware during system resume, reacquiring any
- * resources released in intel_dmc_ucode_suspend().
+ * resources released in intel_dmc_suspend().
*/
-void intel_dmc_ucode_resume(struct drm_i915_private *dev_priv)
+void intel_dmc_resume(struct drm_i915_private *dev_priv)
{
if (!HAS_DMC(dev_priv))
return;
@@ -1043,20 +1043,20 @@ void intel_dmc_ucode_resume(struct drm_i915_private
*dev_priv)
}
/**
- * intel_dmc_ucode_fini() - unload the DMC firmware.
+ * intel_dmc_fini() - unload the DMC firmware.
* @dev_priv: i915 drm device.
*
* Firmmware unloading includes freeing the internal memory and reset the
* firmware loading status.
*/
-void intel_dmc_ucode_fini(struct drm_i915_private *dev_priv)
+void intel_dmc_fini(struct drm_i915_private *dev_priv)
{
enum intel_dmc_id dmc_id;
if (!HAS_DMC(dev_priv))
return;
- intel_dmc_ucode_suspend(dev_priv);
+ intel_dmc_suspend(dev_priv);
drm_WARN_ON(_priv->drm, dev_priv->display.dmc.wakeref);
for_each_dmc_id(dmc_id)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h
b/drivers/gpu/drm/i915/display/intel_dmc.h
index da8ba246013e..90910cecc2f6 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
@@ -43,14 +43,14 @@ struct intel_dmc {
intel_wakeref_t wakeref;
};
-void intel_dmc_ucode_init(struct drm_i915_private *i915);
+void intel_dmc_init(struct drm_i915_private *i915);
void intel_dmc_load_program(struct drm_i915_private *i915);
void intel_dmc_disable_program(struct
[Intel-gfx] [RFC 1/3] drm/i915/power: move dc state members to struct i915_power_domains
There's only one reference to the struct intel_dmc members dc_state,
target_dc_state, and allowed_dc_mask within intel_dmc.c, begging the
question why they are under struct intel_dmc to begin with.
Moreover, the only references to i915->display.dmc outside of
intel_dmc.c are to these members.
They don't belong. Move them from struct intel_dmc to struct
i915_power_domains, which seems like a more suitable place.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_power.c| 25 ---
.../drm/i915/display/intel_display_power.h| 4 +++
.../i915/display/intel_display_power_well.c | 31 +++
drivers/gpu/drm/i915/display/intel_dmc.c | 3 +-
drivers/gpu/drm/i915/display/intel_dmc.h | 3 --
drivers/gpu/drm/i915/display/intel_psr.c | 3 +-
6 files changed, 39 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 7222502a760c..4ed7e50e1c21 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -264,9 +264,10 @@ bool intel_display_power_is_enabled(struct
drm_i915_private *dev_priv,
}
static u32
-sanitize_target_dc_state(struct drm_i915_private *dev_priv,
+sanitize_target_dc_state(struct drm_i915_private *i915,
u32 target_dc_state)
{
+ struct i915_power_domains *power_domains = >display.power.domains;
static const u32 states[] = {
DC_STATE_EN_UPTO_DC6,
DC_STATE_EN_UPTO_DC5,
@@ -279,7 +280,7 @@ sanitize_target_dc_state(struct drm_i915_private *dev_priv,
if (target_dc_state != states[i])
continue;
- if (dev_priv->display.dmc.allowed_dc_mask & target_dc_state)
+ if (power_domains->allowed_dc_mask & target_dc_state)
break;
target_dc_state = states[i + 1];
@@ -312,7 +313,7 @@ void intel_display_power_set_target_dc_state(struct
drm_i915_private *dev_priv,
state = sanitize_target_dc_state(dev_priv, state);
- if (state == dev_priv->display.dmc.target_dc_state)
+ if (state == power_domains->target_dc_state)
goto unlock;
dc_off_enabled = intel_power_well_is_enabled(dev_priv, power_well);
@@ -323,7 +324,7 @@ void intel_display_power_set_target_dc_state(struct
drm_i915_private *dev_priv,
if (!dc_off_enabled)
intel_power_well_enable(dev_priv, power_well);
- dev_priv->display.dmc.target_dc_state = state;
+ power_domains->target_dc_state = state;
if (!dc_off_enabled)
intel_power_well_disable(dev_priv, power_well);
@@ -992,10 +993,10 @@ int intel_power_domains_init(struct drm_i915_private
*dev_priv)
dev_priv->params.disable_power_well =
sanitize_disable_power_well_option(dev_priv,
dev_priv->params.disable_power_well);
- dev_priv->display.dmc.allowed_dc_mask =
+ power_domains->allowed_dc_mask =
get_allowed_dc_mask(dev_priv, dev_priv->params.enable_dc);
- dev_priv->display.dmc.target_dc_state =
+ power_domains->target_dc_state =
sanitize_target_dc_state(dev_priv, DC_STATE_EN_UPTO_DC6);
mutex_init(_domains->lock);
@@ -2053,7 +2054,7 @@ void intel_power_domains_suspend(struct drm_i915_private
*i915,
* resources as required and also enable deeper system power states
* that would be blocked if the firmware was inactive.
*/
- if (!(i915->display.dmc.allowed_dc_mask & DC_STATE_EN_DC9) &&
+ if (!(power_domains->allowed_dc_mask & DC_STATE_EN_DC9) &&
suspend_mode == I915_DRM_SUSPEND_IDLE &&
intel_dmc_has_payload(i915)) {
intel_display_power_flush_work(i915);
@@ -2242,22 +2243,22 @@ void intel_display_power_suspend(struct
drm_i915_private *i915)
void intel_display_power_resume(struct drm_i915_private *i915)
{
+ struct i915_power_domains *power_domains = >display.power.domains;
+
if (DISPLAY_VER(i915) >= 11) {
bxt_disable_dc9(i915);
icl_display_core_init(i915, true);
if (intel_dmc_has_payload(i915)) {
- if (i915->display.dmc.allowed_dc_mask &
- DC_STATE_EN_UPTO_DC6)
+ if (power_domains->allowed_dc_mask &
DC_STATE_EN_UPTO_DC6)
skl_enable_dc6(i915);
- else if (i915->display.dmc.allowed_dc_mask &
-DC_STATE_EN_UPTO_DC5)
+ else if (power_domains->allowed_dc_mask &
DC_STATE_EN_UPTO_DC5)
gen9_enable_dc5(i915);
}
} else if (IS_GEMINILAKE(i915) || IS_BROXTON(i915)) {
[Intel-gfx] [RFC 0/3] drm/i915/dmc: allocate dmc struct dynamically
Allocate the >1k dmc struct dynamically, only for platforms that need it. Jani Nikula (3): drm/i915/power: move dc state members to struct i915_power_domains drm/i915/dmc: drop "ucode" from function names drm/i915/dmc: allocate dmc structure dynamically drivers/gpu/drm/i915/display/intel_display.c | 6 +- .../gpu/drm/i915/display/intel_display_core.h | 8 +- .../drm/i915/display/intel_display_power.c| 25 +-- .../drm/i915/display/intel_display_power.h| 4 + .../i915/display/intel_display_power_well.c | 31 ++-- drivers/gpu/drm/i915/display/intel_dmc.c | 159 -- drivers/gpu/drm/i915/display/intel_dmc.h | 44 + .../drm/i915/display/intel_modeset_setup.c| 1 + drivers/gpu/drm/i915/display/intel_psr.c | 3 +- drivers/gpu/drm/i915/i915_driver.c| 6 +- 10 files changed, 164 insertions(+), 123 deletions(-) -- 2.34.1
[Intel-gfx] ✓ Fi.CI.BAT: success for Fix logic to get slice_height for dp (rev2)
== Series Details ==
Series: Fix logic to get slice_height for dp (rev2)
URL : https://patchwork.freedesktop.org/series/113594/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12685 -> Patchwork_113594v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/index.html
Participating hosts (26 -> 25)
--
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113594v2 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- {bat-adlp-9}: [INCOMPLETE][1] ([i915#4983]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12685/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
Build changes
-
* Linux: CI_DRM_12685 -> Patchwork_113594v2
CI-20190529: 20190529
CI_DRM_12685: 7112630bb80387792d4ba842a690bd18d0d881ee @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7144: cda71bf809b981a646270963d6b1ccee4fd4643b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113594v2: 7112630bb80387792d4ba842a690bd18d0d881ee @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
4a434173b901 drm/i915/dp: Increase slice_height for DP
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v2/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv (rev2)
== Series Details ==
Series: drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv (rev2)
URL : https://patchwork.freedesktop.org/series/113568/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12684_full -> Patchwork_113568v2_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113568v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_isolation@preservation-s3@rcs0:
- {shard-tglu}: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-tglu-2/igt@gem_ctx_isolation@preservation...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/shard-tglu-6/igt@gem_ctx_isolation@preservation...@rcs0.html
* igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs_cc:
- {shard-dg1}:[PASS][3] -> [DMESG-WARN][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-dg1-13/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/shard-dg1-17/igt@kms_ccs@pipe-c-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html
Known issues
Here are the changes found in Patchwork_113568v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
Possible fixes
* igt@fbdev@nullptr:
- {shard-rkl}:[SKIP][7] ([i915#2582]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-1/igt@fb...@nullptr.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/shard-rkl-6/igt@fb...@nullptr.html
* igt@feature_discovery@psr1:
- {shard-rkl}:[SKIP][9] ([i915#658]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-1/igt@feature_discov...@psr1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/shard-rkl-6/igt@feature_discov...@psr1.html
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- {shard-rkl}:[DMESG-WARN][11] ([i915#5122]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-4/igt@gem_ctx_isolation@preservation...@bcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/shard-rkl-1/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_ctx_isolation@preservation-s3@rcs0:
- {shard-rkl}:[ABORT][13] -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-4/igt@gem_ctx_isolation@preservation...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/shard-rkl-1/igt@gem_ctx_isolation@preservation...@rcs0.html
* igt@gem_ctx_persistence@many-contexts:
- {shard-rkl}:[INCOMPLETE][15] -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-3/igt@gem_ctx_persiste...@many-contexts.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/shard-rkl-4/igt@gem_ctx_persiste...@many-contexts.html
* igt@gem_eio@suspend:
- {shard-rkl}:[FAIL][17] ([i915#5115] / [i915#7052]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-3/igt@gem_...@suspend.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/shard-rkl-2/igt@gem_...@suspend.html
* igt@gem_exec_fair@basic-deadline:
- {shard-rkl}:[FAIL][19] ([i915#2846]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-6/igt@gem_exec_f...@basic-deadline.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/shard-rkl-5/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- {shard-rkl}:[SKIP][21] ([fdo#109313]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/shard-rkl-1/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/shard-rkl-5/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
* igt@gem_exec_reloc@basic-write-read:
- {shard-rkl}:[SKIP][23] ([i915#3281])
Re: [Intel-gfx] [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control
Hello, On Thu, Feb 02, 2023 at 02:26:06PM +, Tvrtko Ursulin wrote: > When you say active/inactive - to what you are referring in the cgroup > world? Offline/online? For those my understanding was offline was a > temporary state while css is getting destroyed. Oh, it's just based on activity. So, for example, iocost puts a cgroup on its active list which is canned periodically when an IO is issued from an inactive cgroup. If an active cgroup doesn't have any activity between two scans, it becomes inactive and dropped from the list. drm can prolly use the same approach? > Also, I am really postponing implementing those changes until I hear at > least something from the DRM community. Yeah, that sounds like a good idea. Thanks. -- tejun
Re: [Intel-gfx] [PATCH v3] vfio: fix deadlock between group lock and kvm lock
On Thu, 2 Feb 2023 11:24:42 -0500
Matthew Rosato wrote:
> After 51cdc8bc120e, we have another deadlock scenario between the
> kvm->lock and the vfio group_lock with two different codepaths acquiring
> the locks in different order. Specifically in vfio_open_device, vfio
> holds the vfio group_lock when issuing device->ops->open_device but some
> drivers (like vfio-ap) need to acquire kvm->lock during their open_device
> routine; Meanwhile, kvm_vfio_release will acquire the kvm->lock first
> before calling vfio_file_set_kvm which will acquire the vfio group_lock.
>
> To resolve this, let's remove the need for the vfio group_lock from the
> kvm_vfio_release codepath. This is done by introducing a new spinlock to
> protect modifications to the vfio group kvm pointer, and acquiring a kvm
> ref from within vfio while holding this spinlock, with the reference held
> until the last close for the device in question.
>
> Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio group_lock")
> Reported-by: Anthony Krowiak
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Matthew Rosato
> ---
> Changes from v2:
> * Relocate the new functions back to vfio_main and externalize to call
> from group (Kevin) since cdev will need this too
> * s/vfio_kvm_*_kvm/vfio_device_*_kvm/ and only pass device as input.
> Handle new kvm_ref_lock directly inside vfio_device_get_kvm (Alex)
> * Add assert_lockdep_held for dev_set lock (Alex)
> * Internalize error paths for vfio_device_get_kvm_safe and now return
> void - either device->kvm is set with a ref taken or is NULL (Alex)
> * Other flow suggestions to make the call path cleaner - Thanks! (Alex)
> * Can't pass group->kvm to vfio_device_open, as it references the value
> outside of new lock. Pass device->kvm to minimize changes in this
> fix (Alex, Yi)
> Changes from v1:
> * use spin_lock instead of spin_lock_irqsave (Jason)
> * clear device->kvm_put as part of vfio_kvm_put_kvm (Yi)
> * Re-arrange code to avoid referencing the group contents from within
> vfio_main (Kevin) which meant moving most of the code in this patch
> to group.c along with getting/dropping of the dev_set lock
> ---
> drivers/vfio/group.c | 32 ++
> drivers/vfio/vfio.h | 14
> drivers/vfio/vfio_main.c | 70
> include/linux/vfio.h | 2 +-
> 4 files changed, 103 insertions(+), 15 deletions(-)
LGTM. I'm not sure moving the functions to vfio_main really buys us
anything since we're making so much use of group fields. The cdev
approach will necessarily be different, so the bulk of the get code will
likely need to move back to group.c anyway.
I'll wait for further comments and reviews by others before applying.
Thanks,
Alex
> diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> index bb24b2f0271e..7fed4233ca23 100644
> --- a/drivers/vfio/group.c
> +++ b/drivers/vfio/group.c
> @@ -164,13 +164,23 @@ static int vfio_device_group_open(struct vfio_device
> *device)
> goto out_unlock;
> }
>
> + mutex_lock(>dev_set->lock);
> +
> /*
> - * Here we pass the KVM pointer with the group under the lock. If the
> - * device driver will use it, it must obtain a reference and release it
> - * during close_device.
> + * Before the first device open, get the KVM pointer currently
> + * associated with the group (if there is one) and obtain a reference
> + * now that will be held until the open_count reaches 0 again. Save
> + * the pointer in the device for use by drivers.
>*/
> - ret = vfio_device_open(device, device->group->iommufd,
> -device->group->kvm);
> + if (device->open_count == 0)
> + vfio_device_get_kvm_safe(device);
> +
> + ret = vfio_device_open(device, device->group->iommufd, device->kvm);
> +
> + if (device->open_count == 0)
> + vfio_device_put_kvm(device);
> +
> + mutex_unlock(>dev_set->lock);
>
> out_unlock:
> mutex_unlock(>group->group_lock);
> @@ -180,7 +190,14 @@ static int vfio_device_group_open(struct vfio_device
> *device)
> void vfio_device_group_close(struct vfio_device *device)
> {
> mutex_lock(>group->group_lock);
> + mutex_lock(>dev_set->lock);
> +
> vfio_device_close(device, device->group->iommufd);
> +
> + if (device->open_count == 0)
> + vfio_device_put_kvm(device);
> +
> + mutex_unlock(>dev_set->lock);
> mutex_unlock(>group->group_lock);
> }
>
> @@ -450,6 +467,7 @@ static struct vfio_group *vfio_group_alloc(struct
> iommu_group *iommu_group,
>
> refcount_set(>drivers, 1);
> mutex_init(>group_lock);
> + spin_lock_init(>kvm_ref_lock);
> INIT_LIST_HEAD(>device_list);
> mutex_init(>device_lock);
> group->iommu_group = iommu_group;
> @@ -803,9 +821,9 @@ void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
> if
Re: [Intel-gfx] [PATCH 1/1] drm/i915/dp: Fix logic to fetch slice_height
On Thu, 02 Feb 2023, "Kandpal, Suraj" wrote:
>>
>> On Thu, 02 Feb 2023, Suraj Kandpal wrote:
>> > According to Bpec: 49259 VDSC spec implies that 108 lines is an
>> > optimal slice height, but any size can be used as long as vertical
>> > active integer multiple and maximum vertical slice count requirements are
>> met.
>>
>> The commit message and subject should really indicate that this increases
>> the slice height considerably. It's a 13.5x increase at a minimum, could be
>> much more. Seems misleading to call it "fix logic", as if there's a small
>> issue
>> somewhere.
>>
>> Bspec references should be here:
>>
>> Bspec: 49259
>> > Cc: Ankit Nautiyal
>> > Cc: Swati Sharma
>> > Signed-off-by: Suraj Kandpal
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> > b/drivers/gpu/drm/i915/display/intel_dp.c
>> > index 62cbab7402e9..7bd2e56ef0fa 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> > @@ -1415,6 +1415,22 @@ static int
>> intel_dp_sink_dsc_version_minor(struct intel_dp *intel_dp)
>> >DP_DSC_MINOR_SHIFT;
>> > }
>> >
>> > +static int intel_dp_get_slice_height(int vactive)
>>
>> intel_dp_dsc_get_slice_height
>>
>> > +{
>> > + int slice_height;
>> > +
>> > + /*
>> > + * VDSC spec implies that 108 lines is an optimal slice height,
>>
>> Please be more specific with spec references than vague "VSDC spec". Spec
>> version is required at a minimum. Section and section title are a nice bonus.
>>
>> > + * but any size can be used as long as vertical active integer
>> > + * multiple and maximum vertical slice count requirements are met.
>> > + */
>> > + for (slice_height = 108; slice_height <= vactive; slice_height += 2)
>>
>> Where does it say 108 is a minimum, and you should go up only...?
>
> So in VDSC 1.2a section 3.8 option for slices it says
> "a slice height of 108 lines typically provides better
> performance than a slice height of 8 lines."
> It also states the following
> "Also it says There is no cost associated with slice height because
> there is no additional buffering or any other additional resources required"
> that's why I decided to move up from slice height of 108
>
>>
>> > + if (!(vactive % slice_height))
>>
>> Matter of taste, but please use (vactive % slice_height == 0) for clarity on
>> computations like this.
>>
>> > + return slice_height;
>> > +
>> > + return 0;
>>
>> I guess it's unlikely we ever hit here, but you could have the old code as
>> fallback and never return 0. Because you don't check for 0 in the caller
>> anyway.
>
> I will do this
>
>>
>> Also makes me wonder why we have intel_hdmi_dsc_get_slice_height()
>> separately, with almost identical implementation. Maybe we should
>> consolidate.
>
> That's separate because the minimum there starts from slice_height of 96 as
> indicated in
> HDMI spec
Do you think it's fine to duplicate a whole function if their sole
difference is the starting point of a for loop?
BR,
Jani.
>
> Regards,
> Suraj Kandpal
>>
>> > +}
>> > +
>> > static int intel_dp_dsc_compute_params(struct intel_encoder *encoder,
>> > struct intel_crtc_state *crtc_state) {
>> > @@
>> -1433,17
>> > +1449,7 @@ static int intel_dp_dsc_compute_params(struct intel_encoder
>> *encoder,
>> >vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
>> >vdsc_cfg->pic_height = crtc_state->hw.adjusted_mode.crtc_vdisplay;
>> >
>> > - /*
>> > - * Slice Height of 8 works for all currently available panels. So start
>> > - * with that if pic_height is an integral multiple of 8. Eventually add
>> > - * logic to try multiple slice heights.
>> > - */
>> > - if (vdsc_cfg->pic_height % 8 == 0)
>> > - vdsc_cfg->slice_height = 8;
>> > - else if (vdsc_cfg->pic_height % 4 == 0)
>> > - vdsc_cfg->slice_height = 4;
>> > - else
>> > - vdsc_cfg->slice_height = 2;
>> > + vdsc_cfg->slice_height =
>> > +intel_dp_get_slice_height(vdsc_cfg->pic_height);
>> >
>> >ret = intel_dsc_compute_params(crtc_state);
>> >if (ret)
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 11/13] drm/i915/dsb: Write each legacy LUT entry twice with DSB
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, January 18, 2023 10:01 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 11/13] drm/i915/dsb: Write each legacy LUT entry
> twice with DSB
>
> From: Ville Syrjälä
>
> The DSB has problems loading the legacy LUT. Looks like simply writing each
> LUT entry twice back-to-back is sufficient workaround for this.
>
> Curiously it doesn't even matter what data we provide for the first write, the
> second write always seems to work 100%. So this doesn't seem to be some
> kind of simple race where the data gets latched before it's actually available
> on some bus (which was my first hunch).
>
> TODO: need to figure out what is the actual hw issue here
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 4c3344ee473e..8de2dc4b7904 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -860,9 +860,18 @@ static void ilk_load_lut_8(const struct
> intel_crtc_state *crtc_state,
>
> lut = blob->data;
>
> - for (i = 0; i < 256; i++)
> + for (i = 0; i < 256; i++) {
> + /*
> + * DSB fails to correctly load the legacy
> + * LUT unless we write each entry twice.
> + * It doesn't actually matter what data we
> + * provide for the first write.
> + */
Is it confirmed by hardware team? Is there any difference with indexed register
write and single register write.
Regards,
Animesh
> + if (crtc_state->dsb)
> + ilk_lut_write(crtc_state, LGC_PALETTE(pipe, i), 0);
> ilk_lut_write(crtc_state, LGC_PALETTE(pipe, i),
> i9xx_lut_8([i]));
> + }
> }
>
> static void ilk_load_lut_10(const struct intel_crtc_state *crtc_state,
> --
> 2.38.2
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Make sure dsm_size has correct granularity (rev2)
== Series Details ==
Series: drm/i915: Make sure dsm_size has correct granularity (rev2)
URL : https://patchwork.freedesktop.org/series/113282/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12684 -> Patchwork_113282v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/index.html
Participating hosts (27 -> 25)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113282v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg1-6: NOTRUN -> [SKIP][1] ([i915#7828])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/bat-dg1-6/igt@kms_chamelium_...@common-hpd-after-suspend.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-n3050: [PASS][2] -> [FAIL][3] ([i915#6298])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- bat-dg1-6: [ABORT][4] ([i915#4983]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/bat-dg1-6/igt@i915_selftest@live@gt_lrc.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/bat-dg1-6/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@gt_pm:
- {bat-rpls-2}: [DMESG-FAIL][6] ([i915#4258]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@reset:
- {bat-rpls-2}: [ABORT][8] ([i915#4983]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/bat-rpls-2/igt@i915_selftest@l...@reset.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/bat-rpls-2/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12684 -> Patchwork_113282v2
CI-20190529: 20190529
CI_DRM_12684: 57eb8680d3ef1213de1d9c607b95e522035036e6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7144: cda71bf809b981a646270963d6b1ccee4fd4643b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113282v2: 57eb8680d3ef1213de1d9c607b95e522035036e6 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
8daa9156f25b drm/i915: Make sure dsm_size has correct granularity
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113282v2/index.html
[Intel-gfx] [PATCH v2] drm/i915/dp: Increase slice_height for DP
According VDSC spec 1.2a Section 3.8 Options for Slice
implies that 108 lines is an optimal slice height, but any
size can be used as long as vertical active
integer multiple and maximum vertical slice count requirements are met.
Bspec: 49259
Cc: Jani Nikula
Cc: Ankit Nautiyal
Cc: Swati Sharma
Signed-off-by: Suraj Kandpal
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 62cbab7402e9..cb4fbcd935db 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1415,6 +1415,30 @@ static int intel_dp_sink_dsc_version_minor(struct
intel_dp *intel_dp)
DP_DSC_MINOR_SHIFT;
}
+static int intel_dp_get_slice_height(int vactive)
+{
+ int slice_height;
+
+ /*
+* VDSC1.2a spec in Section 3.8 Options for Slices implies that
+* 108 lines is an optimal slice height,
+* but any size can be used as long as vertical active integer
+* multiple and maximum vertical slice count requirements are met.
+*/
+ for (slice_height = 108; slice_height <= vactive; slice_height += 2)
+ if (vactive % slice_height == 0)
+ return slice_height;
+
+ if (vactive % 8 == 0)
+ slice_height = 8;
+ else if (vactive % 4 == 0)
+ slice_height = 4;
+ else
+ slice_height = 2;
+
+ return slice_height;
+}
+
static int intel_dp_dsc_compute_params(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state)
{
@@ -1433,17 +1457,7 @@ static int intel_dp_dsc_compute_params(struct
intel_encoder *encoder,
vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
vdsc_cfg->pic_height = crtc_state->hw.adjusted_mode.crtc_vdisplay;
- /*
-* Slice Height of 8 works for all currently available panels. So start
-* with that if pic_height is an integral multiple of 8. Eventually add
-* logic to try multiple slice heights.
-*/
- if (vdsc_cfg->pic_height % 8 == 0)
- vdsc_cfg->slice_height = 8;
- else if (vdsc_cfg->pic_height % 4 == 0)
- vdsc_cfg->slice_height = 4;
- else
- vdsc_cfg->slice_height = 2;
+ vdsc_cfg->slice_height =
intel_dp_get_slice_height(vdsc_cfg->pic_height);
ret = intel_dsc_compute_params(crtc_state);
if (ret)
--
2.25.1
[Intel-gfx] ✓ Fi.CI.IGT: success for i915: fix memory leak with using debugfs_lookup()
== Series Details ==
Series: i915: fix memory leak with using debugfs_lookup()
URL : https://patchwork.freedesktop.org/series/113603/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12683_full -> Patchwork_113603v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/index.html
Participating hosts (10 -> 11)
--
Additional (1): shard-rkl0
Known issues
Here are the changes found in Patchwork_113603v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-glk5/igt@gem_exec_fair@basic-none-...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/shard-glk4/igt@gem_exec_fair@basic-none-...@rcs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][3] -> [ABORT][4] ([i915#5566])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-glk8/igt@gen9_exec_pa...@allowed-single.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/shard-glk6/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-1:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2521])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-glk8/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-hdmi-a-1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/shard-glk6/igt@kms_async_flips@alternate-sync-async-f...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@fbdev@pan:
- {shard-rkl}:[SKIP][7] ([i915#2582]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-5/igt@fb...@pan.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/shard-rkl-6/igt@fb...@pan.html
* igt@feature_discovery@psr1:
- {shard-rkl}:[SKIP][9] ([i915#658]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@feature_discov...@psr1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/shard-rkl-6/igt@feature_discov...@psr1.html
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- {shard-rkl}:[DMESG-WARN][11] ([i915#5122]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@gem_ctx_isolation@preservation...@bcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/shard-rkl-5/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_ctx_isolation@preservation-s3@rcs0:
- {shard-rkl}:[ABORT][13] -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@gem_ctx_isolation@preservation...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/shard-rkl-5/igt@gem_ctx_isolation@preservation...@rcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [FAIL][15] ([i915#2846]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-glk5/igt@gem_exec_f...@basic-deadline.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/shard-glk8/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][17] ([i915#2842]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][19] ([i915#3281]) -> [PASS][20] +7 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@gem_exec_re...@basic-wc-read-noreloc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/shard-rkl-5/igt@gem_exec_re...@basic-wc-read-noreloc.html
* igt@gem_pwrite_snooped:
- {shard-rkl}:[SKIP][21] ([i915#3282]) -> [PASS][22] +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@gem_pwrite_snooped.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/shard-rkl-5/igt@gem_pwrite_snooped.html
* igt@gen9_exec_parse@bb-start-cmd:
- {shard-rkl}:[SKIP][23] ([i915#2527]) -> [PASS][24] +2 similar
issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@gen9_exec_pa...@bb-start-cmd.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/shard-rkl-5/igt@gen9_exec_pa...@bb-start-cmd.html
* igt@i915_pm_rpm@modeset-lpsp-stress:
- {shard-dg1}:[SKIP][25] ([i915#1397])
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dmc: some dmc id related fixes and cleanups
== Series Details ==
Series: drm/i915/dmc: some dmc id related fixes and cleanups
URL : https://patchwork.freedesktop.org/series/113596/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12683_full -> Patchwork_113596v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113596v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_isolation@preservation-s3@rcs0:
- {shard-tglu}: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/shard-tglu-6/igt@gem_ctx_isolation@preservation...@rcs0.html
Known issues
Here are the changes found in Patchwork_113596v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-glk: [PASS][2] -> [FAIL][3] ([i915#2842])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-glk5/igt@gem_exec_fair@basic-none-...@rcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/shard-glk2/igt@gem_exec_fair@basic-none-...@rcs0.html
Possible fixes
* igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][4] ([i915#7742]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@drm_fdinfo@most-busy-check-...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/shard-rkl-6/igt@drm_fdinfo@most-busy-check-...@rcs0.html
* igt@fbdev@nullptr:
- {shard-rkl}:[SKIP][6] ([i915#2582]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@fb...@nullptr.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/shard-rkl-6/igt@fb...@nullptr.html
* igt@feature_discovery@psr1:
- {shard-rkl}:[SKIP][8] ([i915#658]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@feature_discov...@psr1.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/shard-rkl-6/igt@feature_discov...@psr1.html
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- {shard-rkl}:[DMESG-WARN][10] ([i915#5122]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@gem_ctx_isolation@preservation...@bcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/shard-rkl-5/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_ctx_isolation@preservation-s3@rcs0:
- {shard-rkl}:[ABORT][12] -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@gem_ctx_isolation@preservation...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/shard-rkl-5/igt@gem_ctx_isolation@preservation...@rcs0.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][14] ([i915#6247]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/shard-rkl-1/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-glk: [FAIL][16] ([i915#2842]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-glk6/igt@gem_exec_fair@basic-p...@vecs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/shard-glk2/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- {shard-rkl}:[SKIP][18] ([fdo#109313]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-6/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/shard-rkl-5/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
* igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][20] ([i915#3281]) -> [PASS][21] +1 similar
issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@gem_exec_re...@basic-wc-read-noreloc.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/shard-rkl-5/igt@gem_exec_re...@basic-wc-read-noreloc.html
* igt@gem_partial_pwrite_pread@writes-after-reads:
- {shard-rkl}:[SKIP][22] ([i915#3282]) -> [PASS][23] +4 similar
issues
[22]:
[Intel-gfx] [PATCH] drm/i915: Make sure dsm_size has correct granularity
DSM granularity is 1MB so make sure we stick to that. v2: replace "1 * SZ_1M" with SZ_1M (Andrzej). Cc: Matthew Auld Suggested-by: Lucas De Marchi Signed-off-by: Nirmoy Das Reviewed-by: Andrzej Hajda --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c index 90a967374b1a..d8e06e783e30 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c @@ -909,7 +909,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, u16 type, dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE) & GEN12_BDSM_MASK; if (WARN_ON(lmem_size < dsm_base)) return ERR_PTR(-ENODEV); - dsm_size = lmem_size - dsm_base; + dsm_size = ALIGN_DOWN(lmem_size - dsm_base, SZ_1M); } io_size = dsm_size; -- 2.39.0
Re: [Intel-gfx] [PATCH 1/1] drm/i915/dp: Fix logic to fetch slice_height
>
> On Thu, 02 Feb 2023, Suraj Kandpal wrote:
> > According to Bpec: 49259 VDSC spec implies that 108 lines is an
> > optimal slice height, but any size can be used as long as vertical
> > active integer multiple and maximum vertical slice count requirements are
> met.
>
> The commit message and subject should really indicate that this increases
> the slice height considerably. It's a 13.5x increase at a minimum, could be
> much more. Seems misleading to call it "fix logic", as if there's a small
> issue
> somewhere.
>
> Bspec references should be here:
>
> Bspec: 49259
> > Cc: Ankit Nautiyal
> > Cc: Swati Sharma
> > Signed-off-by: Suraj Kandpal
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 62cbab7402e9..7bd2e56ef0fa 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1415,6 +1415,22 @@ static int
> intel_dp_sink_dsc_version_minor(struct intel_dp *intel_dp)
> > DP_DSC_MINOR_SHIFT;
> > }
> >
> > +static int intel_dp_get_slice_height(int vactive)
>
> intel_dp_dsc_get_slice_height
>
> > +{
> > + int slice_height;
> > +
> > + /*
> > +* VDSC spec implies that 108 lines is an optimal slice height,
>
> Please be more specific with spec references than vague "VSDC spec". Spec
> version is required at a minimum. Section and section title are a nice bonus.
>
> > +* but any size can be used as long as vertical active integer
> > +* multiple and maximum vertical slice count requirements are met.
> > +*/
> > + for (slice_height = 108; slice_height <= vactive; slice_height += 2)
>
> Where does it say 108 is a minimum, and you should go up only...?
So in VDSC 1.2a section 3.8 option for slices it says
"a slice height of 108 lines typically provides better
performance than a slice height of 8 lines."
It also states the following
"Also it says There is no cost associated with slice height because
there is no additional buffering or any other additional resources required"
that's why I decided to move up from slice height of 108
>
> > + if (!(vactive % slice_height))
>
> Matter of taste, but please use (vactive % slice_height == 0) for clarity on
> computations like this.
>
> > + return slice_height;
> > +
> > + return 0;
>
> I guess it's unlikely we ever hit here, but you could have the old code as
> fallback and never return 0. Because you don't check for 0 in the caller
> anyway.
I will do this
>
> Also makes me wonder why we have intel_hdmi_dsc_get_slice_height()
> separately, with almost identical implementation. Maybe we should
> consolidate.
That's separate because the minimum there starts from slice_height of 96 as
indicated in
HDMI spec
Regards,
Suraj Kandpal
>
> > +}
> > +
> > static int intel_dp_dsc_compute_params(struct intel_encoder *encoder,
> >struct intel_crtc_state *crtc_state) {
> > @@
> -1433,17
> > +1449,7 @@ static int intel_dp_dsc_compute_params(struct intel_encoder
> *encoder,
> > vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
> > vdsc_cfg->pic_height = crtc_state->hw.adjusted_mode.crtc_vdisplay;
> >
> > - /*
> > -* Slice Height of 8 works for all currently available panels. So start
> > -* with that if pic_height is an integral multiple of 8. Eventually add
> > -* logic to try multiple slice heights.
> > -*/
> > - if (vdsc_cfg->pic_height % 8 == 0)
> > - vdsc_cfg->slice_height = 8;
> > - else if (vdsc_cfg->pic_height % 4 == 0)
> > - vdsc_cfg->slice_height = 4;
> > - else
> > - vdsc_cfg->slice_height = 2;
> > + vdsc_cfg->slice_height =
> > +intel_dp_get_slice_height(vdsc_cfg->pic_height);
> >
> > ret = intel_dsc_compute_params(crtc_state);
> > if (ret)
>
> --
> Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.IGT: success for Fix logic to get slice_height for dp
== Series Details ==
Series: Fix logic to get slice_height for dp
URL : https://patchwork.freedesktop.org/series/113594/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12683_full -> Patchwork_113594v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v1/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113594v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_capture@pi@rcs0:
- {shard-tglu}: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v1/shard-tglu-6/igt@gem_exec_capture@p...@rcs0.html
Known issues
Here are the changes found in Patchwork_113594v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][2] -> [ABORT][3] ([i915#5566])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-glk8/igt@gen9_exec_pa...@allowed-single.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v1/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
Possible fixes
* igt@api_intel_bb@object-reloc-purge-cache:
- {shard-rkl}:[SKIP][4] ([i915#3281]) -> [PASS][5] +2 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@api_intel...@object-reloc-purge-cache.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v1/shard-rkl-5/igt@api_intel...@object-reloc-purge-cache.html
* igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][6] ([i915#7742]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@drm_fdinfo@most-busy-check-...@rcs0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v1/shard-rkl-5/igt@drm_fdinfo@most-busy-check-...@rcs0.html
* igt@fbdev@eof:
- {shard-rkl}:[SKIP][8] ([i915#2582]) -> [PASS][9] +1 similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-3/igt@fb...@eof.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v1/shard-rkl-6/igt@fb...@eof.html
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- {shard-rkl}:[DMESG-WARN][10] ([i915#5122]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@gem_ctx_isolation@preservation...@bcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v1/shard-rkl-1/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_ctx_isolation@preservation-s3@rcs0:
- {shard-rkl}:[ABORT][12] -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@gem_ctx_isolation@preservation...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v1/shard-rkl-1/igt@gem_ctx_isolation@preservation...@rcs0.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][14] ([i915#6247]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v1/shard-rkl-3/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [FAIL][16] ([i915#2846]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-glk5/igt@gem_exec_f...@basic-deadline.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v1/shard-glk2/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][18] ([i915#2842]) -> [PASS][19] +3 similar
issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@gem_exec_fair@basic-n...@vcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v1/shard-rkl-5/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_set_tiling_vs_pwrite:
- {shard-rkl}:[SKIP][20] ([i915#3282]) -> [PASS][21] +5 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@gem_set_tiling_vs_pwrite.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113594v1/shard-rkl-5/igt@gem_set_tiling_vs_pwrite.html
* igt@gen9_exec_parse@bb-start-param:
- {shard-rkl}:[SKIP][22] ([i915#2527]) -> [PASS][23] +1 similar
issue
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/shard-rkl-4/igt@gen9_exec_pa...@bb-start-param.html
[23]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/hwmon: Enable PL1 power limit (rev2)
== Series Details ==
Series: drm/i915/hwmon: Enable PL1 power limit (rev2)
URL : https://patchwork.freedesktop.org/series/113578/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12684 -> Patchwork_113578v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_113578v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_113578v2, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v2/index.html
Participating hosts (27 -> 26)
--
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113578v2:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@client:
- fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/fi-kbl-soraka/igt@i915_selftest@l...@client.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v2/fi-kbl-soraka/igt@i915_selftest@l...@client.html
Known issues
Here are the changes found in Patchwork_113578v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[PASS][3] -> [ABORT][4] ([i915#7911])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v2/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005: [PASS][5] -> [DMESG-FAIL][6] ([i915#5334])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v2/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg1-6: NOTRUN -> [SKIP][7] ([i915#7828])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v2/bat-dg1-6/igt@kms_chamelium_...@common-hpd-after-suspend.html
Possible fixes
* igt@i915_module_load@reload:
- fi-kbl-soraka: [DMESG-WARN][8] ([i915#1982]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/fi-kbl-soraka/igt@i915_module_l...@reload.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v2/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gt_lrc:
- bat-dg1-6: [ABORT][10] ([i915#4983]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/bat-dg1-6/igt@i915_selftest@live@gt_lrc.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v2/bat-dg1-6/igt@i915_selftest@live@gt_lrc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
[i915#7981]: https://gitlab.freedesktop.org/drm/intel/issues/7981
Build changes
-
* Linux: CI_DRM_12684 -> Patchwork_113578v2
CI-20190529: 20190529
CI_DRM_12684: 57eb8680d3ef1213de1d9c607b95e522035036e6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7144: cda71bf809b981a646270963d6b1ccee4fd4643b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113578v2: 57eb8680d3ef1213de1d9c607b95e522035036e6 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
2b6945e1b865 drm/i915/hwmon: Enable PL1 power limit
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113578v2/index.html
Re: [Intel-gfx] [PATCH 07/13] drm/i915/dsb: Nuke the DSB debug
> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Wednesday, January 18, 2023 10:01 PM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 07/13] drm/i915/dsb: Nuke the DSB debug > > From: Ville Syrjälä > > We'll be wanting to start the DSB from the vblank evasion critical section so > printk()s are a big nono. Get rid if the debug print. > > Signed-off-by: Ville Syrjälä LGTM. Reviewed-by: Animesh Manna > --- > drivers/gpu/drm/i915/display/intel_dsb.c | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c > b/drivers/gpu/drm/i915/display/intel_dsb.c > index 43679090eceb..96159d69bbff 100644 > --- a/drivers/gpu/drm/i915/display/intel_dsb.c > +++ b/drivers/gpu/drm/i915/display/intel_dsb.c > @@ -265,11 +265,6 @@ void intel_dsb_commit(struct intel_dsb *dsb, bool > wait_for_vblank) > i915_ggtt_offset(dsb->vma)); > intel_de_write(dev_priv, DSB_TAIL(pipe, dsb->id), > i915_ggtt_offset(dsb->vma) + tail); > - > - drm_dbg_kms(_priv->drm, > - "DSB execution started - head 0x%x, tail 0x%x\n", > - i915_ggtt_offset(dsb->vma), > - i915_ggtt_offset(dsb->vma) + tail); > } > > void intel_dsb_wait(struct intel_dsb *dsb) > -- > 2.38.2
Re: [Intel-gfx] [PATCH 06/13] drm/i915/dsb: Allow vblank synchronized DSB execution
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, January 18, 2023 10:01 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 06/13] drm/i915/dsb: Allow vblank synchronized
> DSB execution
>
> From: Ville Syrjälä
>
> Allow the caller to ask for the DSB commands to execute during vblank.
>
> Signed-off-by: Ville Syrjälä
LGTM.
Reviewed-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 2 +-
> drivers/gpu/drm/i915/display/intel_dsb.c | 4 +++-
> drivers/gpu/drm/i915/display/intel_dsb.h | 3 ++-
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 6d6d300fa2df..162d671182e3 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1258,7 +1258,7 @@ static void icl_load_luts(const struct
> intel_crtc_state *crtc_state)
>
> if (crtc_state->dsb) {
> intel_dsb_finish(crtc_state->dsb);
> - intel_dsb_commit(crtc_state->dsb);
> + intel_dsb_commit(crtc_state->dsb, false);
> intel_dsb_wait(crtc_state->dsb);
> }
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index f454329b6901..43679090eceb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -237,10 +237,11 @@ void intel_dsb_finish(struct intel_dsb *dsb)
> /**
> * intel_dsb_commit() - Trigger workload execution of DSB.
> * @dsb: DSB context
> + * @wait_for_vblank: wait for vblank before executing
> *
> * This function is used to do actual write to hardware using DSB.
> */
> -void intel_dsb_commit(struct intel_dsb *dsb)
> +void intel_dsb_commit(struct intel_dsb *dsb, bool wait_for_vblank)
> {
> struct intel_crtc *crtc = dsb->crtc;
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); @@ -
> 258,6 +259,7 @@ void intel_dsb_commit(struct intel_dsb *dsb)
> }
>
> intel_de_write(dev_priv, DSB_CTRL(pipe, dsb->id),
> +(wait_for_vblank ? DSB_WAIT_FOR_VBLANK : 0) |
> DSB_ENABLE);
> intel_de_write(dev_priv, DSB_HEAD(pipe, dsb->id),
> i915_ggtt_offset(dsb->vma));
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.h
> b/drivers/gpu/drm/i915/display/intel_dsb.h
> index 6b22499e8a5d..b8148b47022d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.h
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.h
> @@ -19,7 +19,8 @@ void intel_dsb_finish(struct intel_dsb *dsb); void
> intel_dsb_cleanup(struct intel_dsb *dsb); void intel_dsb_reg_write(struct
> intel_dsb *dsb,
>i915_reg_t reg, u32 val);
> -void intel_dsb_commit(struct intel_dsb *dsb);
> +void intel_dsb_commit(struct intel_dsb *dsb,
> + bool wait_for_vblank);
> void intel_dsb_wait(struct intel_dsb *dsb);
>
> #endif
> --
> 2.38.2
[Intel-gfx] ✓ Fi.CI.BAT: success for vfio: fix deadlock between group lock and kvm lock (rev5)
== Series Details ==
Series: vfio: fix deadlock between group lock and kvm lock (rev5)
URL : https://patchwork.freedesktop.org/series/113535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12684 -> Patchwork_113535v5
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/index.html
Participating hosts (27 -> 25)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113535v5 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg1-6: NOTRUN -> [SKIP][1] ([i915#7828])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/bat-dg1-6/igt@kms_chamelium_...@common-hpd-after-suspend.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-n3050: [PASS][2] -> [FAIL][3] ([i915#6298])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- bat-dg1-6: [ABORT][4] ([i915#4983]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/bat-dg1-6/igt@i915_selftest@live@gt_lrc.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/bat-dg1-6/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@reset:
- {bat-rpls-2}: [ABORT][6] ([i915#4983]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/bat-rpls-2/igt@i915_selftest@l...@reset.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/bat-rpls-2/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12684 -> Patchwork_113535v5
CI-20190529: 20190529
CI_DRM_12684: 57eb8680d3ef1213de1d9c607b95e522035036e6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7144: cda71bf809b981a646270963d6b1ccee4fd4643b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113535v5: 57eb8680d3ef1213de1d9c607b95e522035036e6 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
9764937dc1e4 vfio: fix deadlock between group lock and kvm lock
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v5/index.html
Re: [Intel-gfx] [PATCH] drm/i915/pxp: limit drm-errors or warnings on firmware API failures
On Thu, 2023-02-02 at 08:43 +, Tvrtko Ursulin wrote:
>
> On 02/02/2023 08:13, Alan Previn wrote:
> > MESA driver is creating protected context on every driver handle
> > initialization to query caps bit for app. So when running CI tests,
> > they are observing hundreds of drm_errors when enabling PXP
> > in .config but using SOC or BIOS configuration that cannot support
> > PXP sessions.
> >
> > Update error handling codes to be more selective on which errors
> > are reported as drm_error vs drm_WARN_ONCE vs drm_debug.
> > Don't completely remove all FW error replies (at least keep them
> > but use drm_debug) or else cusomers that really needs to know that
> > content protection failed won't be aware of it when debugging.
> >
> > Signed-off-by: Alan Previn
>
> How does this relate to b762787bf767 ("drm/i915/pxp: Use drm_dbg if arb
> session failed due to fw version") which I thought was already fixing
> the drm_error spam caused by userspace probing?
>
Good question. That previous error was specific to a board that was using
outdated firmware version that really needed to be upgraded.
At that point i wasn't aware of the the fact that MESA was seeing
high frequency of this failure that is tied to platform issues
(BIOS configuration / SOC fusing). Also, i believe in the prior case
PXP was not enabled by default the .config in all testing.
In this latest reported bug (i realized i forgot to include the bug no. for this
new patch -
https://gitlab.freedesktop.org/drm/intel/-/issues/7706#note_1746952),
i was informed that PXP is being enabled by default and there
were DUT hardware that was not PXP-capable (SOC fusing / BIOS config).
So with this patch, i am trying to balance between issues that is critical
but are root-caused from HW/platform gaps (louder drm-warn - but just ONCE)
vs other cases where it could also come from hw/sw state machine (which cannot
be a WARB_ONCE message since it can occur due to runtime operation events).
One thing to note: i am pushing-for / waiting-on our firmware team to get
blessing on more fw-error-code to error-string translations that can be allowed
upstream which is why i added the "pxp_fw_err_to_string" and a single
"drm_dbg" so that in future, we don't have to keep adding a whole new lines of
code to multiple functions but just one new error code translation - and instead
just add the new err-code-to-string entry into a single location.
note: i will re-rev with the bug id.
Re: [Intel-gfx] [PATCH 05/13] drm/i915/dsb: Dump the DSB command buffer when DSB fails
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, January 18, 2023 10:01 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 05/13] drm/i915/dsb: Dump the DSB command
> buffer when DSB fails
>
> From: Ville Syrjälä
>
> Dump the full DSB command buffers and head/tail pointers if the the DSB
> hasn't completed its job in time.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dsb.c | 33 +---
> 1 file changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 9e25b1345927..f454329b6901 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -92,6 +92,22 @@ static bool assert_dsb_has_room(struct intel_dsb
> *dsb)
>crtc->base.base.id, crtc->base.name, dsb->id); }
>
> +static void intel_dsb_dump(struct intel_dsb *dsb) {
> + struct intel_crtc *crtc = dsb->crtc;
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + const u32 *buf = dsb->cmd_buf;
> + int i;
> +
> + drm_dbg_kms(>drm, "[CRTC:%d:%s] DSB %d commands {\n",
> + crtc->base.base.id, crtc->base.name, dsb->id);
> + for (i = 0; i < ALIGN(dsb->free_pos, 64 / 4); i += 4)
> + drm_dbg_kms(>drm,
> + " 0x%08x: 0x%08x 0x%08x 0x%08x 0x%08x\n",
> + i * 4, buf[i], buf[i+1], buf[i+2], buf[i+3]);
> + drm_dbg_kms(>drm, "}\n");
> +}
> +
> static bool is_dsb_busy(struct drm_i915_private *i915, enum pipe pipe,
> enum dsb_id id)
> {
> @@ -260,10 +276,21 @@ void intel_dsb_wait(struct intel_dsb *dsb)
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum pipe pipe = crtc->pipe;
>
> - if (wait_for(!is_dsb_busy(dev_priv, pipe, dsb->id), 1))
> + if (wait_for(!is_dsb_busy(dev_priv, pipe, dsb->id), 1)) {
> + u32 offset = i915_ggtt_offset(dsb->vma);
> +
> + intel_de_write(dev_priv, DSB_CTRL(pipe, dsb->id),
> +DSB_ENABLE | DSB_HALT);
One doubt - Why DSB_ENABLE bit is set here? Is setting DSB_HALT not sufficient.
Other than above the changes look good to me.
Regards,
Animesh
> +
> drm_err(_priv->drm,
> - "[CRTC:%d:%s] DSB %d timed out waiting for idle\n",
> - crtc->base.base.id, crtc->base.name, dsb->id);
> + "[CRTC:%d:%s] DSB %d timed out waiting for idle
> (current head=0x%x, head=0x%x, tail=0x%x)\n",
> + crtc->base.base.id, crtc->base.name, dsb->id,
> + intel_de_read(dev_priv, DSB_CURRENT_HEAD(pipe,
> dsb->id)) - offset,
> + intel_de_read(dev_priv, DSB_HEAD(pipe, dsb->id)) -
> offset,
> + intel_de_read(dev_priv, DSB_TAIL(pipe, dsb->id)) -
> offset);
> +
> + intel_dsb_dump(dsb);
> + }
>
> /* Attempt to reset it */
> dsb->free_pos = 0;
> --
> 2.38.2
Re: [Intel-gfx] [PATCH v10 23/23] drm/i915/vm_bind: Support capture of persistent mappings
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:16:09PM -0800, Niranjana Vishwanathapura wrote:
> Support dump capture of persistent mappings upon user request.
>
> Capture of a mapping is requested with the VM_BIND ioctl and
> processed during the GPU error handling. They are synchronously
> unbound during eviction so that no additional vma resource
> reference taking is required in the submission path. Thus, a
> list of persistent vmas requiring capture is maintained instead
> of a list of vma resources.
>
> v2: enable with CONFIG_DRM_I915_CAPTURE_ERROR, remove gfp
> overwrite, add kernel-doc and expand commit message
> v3: Ensure vma->resource is valid during capture
>
> Signed-off-by: Brian Welty
> Signed-off-by: Niranjana Vishwanathapura
> ---
> .../drm/i915/gem/i915_gem_vm_bind_object.c| 13 +
> drivers/gpu/drm/i915/gt/intel_gtt.c | 5 ++
> drivers/gpu/drm/i915/gt/intel_gtt.h | 7 +++
> drivers/gpu/drm/i915/i915_gem.c | 14 -
> drivers/gpu/drm/i915/i915_gpu_error.c | 52 ++-
> drivers/gpu/drm/i915/i915_vma.c | 4 ++
> drivers/gpu/drm/i915/i915_vma_types.h | 4 ++
> include/uapi/drm/i915_drm.h | 9 +++-
> 8 files changed, 104 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> index 78e7c0642c5f..562a67a988f2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> @@ -88,6 +88,12 @@ static void i915_gem_vm_bind_remove(struct i915_vma *vma,
> bool release_obj)
> {
> lockdep_assert_held(>vm->vm_bind_lock);
>
> +#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
> + mutex_lock(>vm->vm_capture_lock);
> + if (!list_empty(>vm_capture_link))
> + list_del_init(>vm_capture_link);
> + mutex_unlock(>vm->vm_capture_lock);
> +#endif
> spin_lock(>vm->vm_rebind_lock);
> if (!list_empty(>vm_rebind_link))
> list_del_init(>vm_rebind_link);
> @@ -357,6 +363,13 @@ static int i915_gem_vm_bind_obj(struct
> i915_address_space *vm,
> continue;
> }
>
> +#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
> + if (va->flags & I915_GEM_VM_BIND_CAPTURE) {
> + mutex_lock(>vm_capture_lock);
> + list_add_tail(>vm_capture_link,
> >vm_capture_list);
> + mutex_unlock(>vm_capture_lock);
> + }
> +#endif
> list_add_tail(>vm_bind_link, >vm_bound_list);
> i915_vm_bind_it_insert(vma, >va);
> if (!obj->priv_root)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
> b/drivers/gpu/drm/i915/gt/intel_gtt.c
> index 2e4c9fabf3b8..103ca55222be 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
> @@ -297,6 +297,11 @@ void i915_address_space_init(struct i915_address_space
> *vm, int subclass)
> spin_lock_init(>vm_rebind_lock);
> spin_lock_init(>userptr_invalidated_lock);
> INIT_LIST_HEAD(>userptr_invalidated_list);
> +
> +#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
> + INIT_LIST_HEAD(>vm_capture_list);
> + mutex_init(>vm_capture_lock);
> +#endif
can we have all these, init/add/remove inside a single
CONFIG_RM_I915_CAPTURE_ERROR?
> }
>
> void *__px_vaddr(struct drm_i915_gem_object *p)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
> b/drivers/gpu/drm/i915/gt/intel_gtt.h
> index 620b4e020a9f..7f69e1d4fb5e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> @@ -281,6 +281,13 @@ struct i915_address_space {
> /** @root_obj: root object for dma-resv sharing by private objects */
> struct drm_i915_gem_object *root_obj;
>
> +#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
> + /* @vm_capture_list: list of vm captures */
> + struct list_head vm_capture_list;
> + /* @vm_capture_lock: protects vm_capture_list */
> + struct mutex vm_capture_lock;
> +#endif
> +
> /* Global GTT */
> bool is_ggtt:1;
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 969581e7106f..d97822f203fc 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -143,6 +143,8 @@ int i915_gem_object_unbind(struct drm_i915_gem_object
> *obj,
> while (!ret && (vma = list_first_entry_or_null(>vma.list,
> struct i915_vma,
> obj_link))) {
> + bool sync_unbind = true;
> +
> list_move_tail(>obj_link, _in_list);
> if (!i915_vma_is_bound(vma, I915_VMA_BIND_MASK))
> continue;
> @@ -171,8 +173,18 @@ int i915_gem_object_unbind(struct drm_i915_gem_object
> *obj,
>* and
[Intel-gfx] PR for ADLP DMC v2.18
The following changes since commit 5c11a3742947810ee8bffbd476eb5a1b0c7999f2: amdgpu: Add VCN 4.0.2 firmware (2023-01-25 07:40:41 -0500) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware.git dmc-adlp_2.18 for you to fetch changes up to a5046f435699b88a20fe9f5803da2a5c2f604a7f: i915: Add DMC v2.18 for ADLP (2023-02-02 12:58:28 -0300) Gustavo Sousa (1): i915: Add DMC v2.18 for ADLP WHENCE| 3 +++ i915/adlp_dmc.bin | Bin 0 -> 78500 bytes 2 files changed, 3 insertions(+) create mode 100644 i915/adlp_dmc.bin
[Intel-gfx] ✓ Fi.CI.IGT: success for We need to have additional checks for DP MST UHBR (rev2)
== Series Details ==
Series: We need to have additional checks for DP MST UHBR (rev2)
URL : https://patchwork.freedesktop.org/series/112876/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681_full -> Patchwork_112876v2_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112876v2/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_112876v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_flip@2x-plain-flip-fb-recreate@bc-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2122])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-glk4/igt@kms_flip@2x-plain-flip-fb-recre...@bc-hdmi-a1-hdmi-a2.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112876v2/shard-glk5/igt@kms_flip@2x-plain-flip-fb-recre...@bc-hdmi-a1-hdmi-a2.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@c-hdmi-a1:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#79]) +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-glk2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-hdmi-a1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112876v2/shard-glk3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-hdmi-a1.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][5] ([i915#7742]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112876v2/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
* igt@fbdev@info:
- {shard-rkl}:[SKIP][7] ([i915#2582]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-4/igt@fb...@info.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112876v2/shard-rkl-6/igt@fb...@info.html
* igt@fbdev@write:
- {shard-tglu}: [SKIP][9] ([i915#2582]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-tglu-6/igt@fb...@write.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112876v2/shard-tglu-2/igt@fb...@write.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][11] ([i915#6268]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-4/igt@gem_ctx_e...@basic-nohangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112876v2/shard-rkl-4/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][13] ([i915#6252]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112876v2/shard-rkl-1/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[FAIL][15] ([fdo#103375]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@gem_...@in-flight-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112876v2/shard-rkl-2/igt@gem_...@in-flight-suspend.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][17] ([i915#6247]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112876v2/shard-rkl-1/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: [FAIL][19] ([i915#2842]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-glk9/igt@gem_exec_fair@basic-none-r...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112876v2/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- {shard-rkl}:[SKIP][21] ([fdo#109313]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-6/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112876v2/shard-rkl-5/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
* igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][23] ([i915#3281]) -> [PASS][24] +12 similar
issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@gem_exec_re...@basic-wc-read-noreloc.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112876v2/shard-rkl-5/igt@gem_exec_re...@basic-wc-read-noreloc.html
* igt@gem_mmap_gtt@coherency:
Re: [Intel-gfx] [PATCH v10 22/23] drm/i915/vm_bind: Properly build persistent map sg table
Hi Niranjana, On Tue, Jan 17, 2023 at 11:16:08PM -0800, Niranjana Vishwanathapura wrote: > Properly build the sg table for persistent mapping which can > be partial map of the underlying object. Ensure the sg pages > are properly set for page backed regions. The dump capture > support requires this for page backed regions. > > v2: Remove redundant sg_mark_end() call > > Signed-off-by: Niranjana Vishwanathapura Reviewed-by: Andi Shyti Andi
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Consolidate TLB invalidation flow (rev2)
== Series Details ==
Series: drm/i915: Consolidate TLB invalidation flow (rev2)
URL : https://patchwork.freedesktop.org/series/113563/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681_full -> Patchwork_113563v2_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v2/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_113563v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v2/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
Possible fixes
* igt@fbdev@info:
- {shard-rkl}:[SKIP][3] ([i915#2582]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-4/igt@fb...@info.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v2/shard-rkl-6/igt@fb...@info.html
* igt@fbdev@write:
- {shard-tglu}: [SKIP][5] ([i915#2582]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-tglu-6/igt@fb...@write.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v2/shard-tglu-8/igt@fb...@write.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][7] ([i915#6252]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v2/shard-rkl-4/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[FAIL][9] ([fdo#103375]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@gem_...@in-flight-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v2/shard-rkl-5/igt@gem_...@in-flight-suspend.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][11] ([i915#6247]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v2/shard-rkl-1/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [FAIL][13] ([i915#2842]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-glk4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v2/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- {shard-rkl}:[FAIL][15] ([i915#2842]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-4/igt@gem_exec_fair@basic-throt...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v2/shard-rkl-5/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_exec_reloc@basic-gtt-read-noreloc:
- {shard-rkl}:[SKIP][17] ([i915#3281]) -> [PASS][18] +12 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@gem_exec_re...@basic-gtt-read-noreloc.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v2/shard-rkl-5/igt@gem_exec_re...@basic-gtt-read-noreloc.html
* igt@gem_pwrite_snooped:
- {shard-rkl}:[SKIP][19] ([i915#3282]) -> [PASS][20] +6 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@gem_pwrite_snooped.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v2/shard-rkl-5/igt@gem_pwrite_snooped.html
* igt@gen9_exec_parse@valid-registers:
- {shard-rkl}:[SKIP][21] ([i915#2527]) -> [PASS][22] +3 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-4/igt@gen9_exec_pa...@valid-registers.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v2/shard-rkl-5/igt@gen9_exec_pa...@valid-registers.html
* igt@i915_pm_dc@dc9-dpms:
- {shard-rkl}:[SKIP][23] ([i915#3361]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@i915_pm...@dc9-dpms.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113563v2/shard-rkl-1/igt@i915_pm...@dc9-dpms.html
* igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-hdmi-a:
- {shard-tglu}: [FAIL][25] ([i915#3825]) -> [PASS][26]
[25]:
Re: [Intel-gfx] [PATCH v10 20/23] drm/i915/vm_bind: Render VM_BIND documentation
Hi Niranjana, On Tue, Jan 17, 2023 at 11:16:06PM -0800, Niranjana Vishwanathapura wrote: > Update i915 documentation to include VM_BIND changes > and render all VM_BIND related documentation. > > Reviewed-by: Matthew Auld > Signed-off-by: Niranjana Vishwanathapura looks good! Reviewed-by: Andi Shyti Andi > --- > Documentation/gpu/i915.rst | 78 -- > 1 file changed, 59 insertions(+), 19 deletions(-) > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > index 60ea21734902..01429a8f0d6c 100644 > --- a/Documentation/gpu/i915.rst > +++ b/Documentation/gpu/i915.rst > @@ -283,15 +283,18 @@ An Intel GPU has multiple engines. There are several > engine types. > > The Intel GPU family is a family of integrated GPU's using Unified > Memory Access. For having the GPU "do work", user space will feed the > -GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2` > -or `DRM_IOCTL_I915_GEM_EXECBUFFER2_WR`. Most such batchbuffers will > -instruct the GPU to perform work (for example rendering) and that work > -needs memory from which to read and memory to which to write. All memory > -is encapsulated within GEM buffer objects (usually created with the ioctl > -`DRM_IOCTL_I915_GEM_CREATE`). An ioctl providing a batchbuffer for the GPU > -to create will also list all GEM buffer objects that the batchbuffer reads > -and/or writes. For implementation details of memory management see > -`GEM BO Management Implementation Details`_. > +GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2`, > +`DRM_IOCTL_I915_GEM_EXECBUFFER2_WR` or `DRM_IOCTL_I915_GEM_EXECBUFFER3`. > +Most such batchbuffers will instruct the GPU to perform work (for example > +rendering) and that work needs memory from which to read and memory to > +which to write. All memory is encapsulated within GEM buffer objects > +(usually created with the ioctl `DRM_IOCTL_I915_GEM_CREATE`). In vm_bind mode > +(see `VM_BIND mode`_), the batch buffer and all the GEM buffer objects that > +it reads and/or writes should be bound with vm_bind ioctl before submitting > +the batch buffer to GPU. In legacy (non-VM_BIND) mode, an ioctl providing a > +batchbuffer for the GPU to create will also list all GEM buffer objects that > +the batchbuffer reads and/or writes. For implementation details of memory > +management see `GEM BO Management Implementation Details`_. > > The i915 driver allows user space to create a context via the ioctl > `DRM_IOCTL_I915_GEM_CONTEXT_CREATE` which is identified by a 32-bit > @@ -309,8 +312,9 @@ In addition to the ordering guarantees, the kernel will > restore GPU > state via HW context when commands are issued to a context, this saves > user space the need to restore (most of atleast) the GPU state at the > start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer > -work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1) > -to identify what context to use with the command. > +work can pass that ID (drm_i915_gem_execbuffer3::ctx_id, or in the lower > +bits of drm_i915_gem_execbuffer2::rsvd1) to identify what context to use > +with the command. > > The GPU has its own memory management and address space. The kernel > driver maintains the memory translation table for the GPU. For older > @@ -318,14 +322,14 @@ GPUs (i.e. those before Gen8), there is a single global > such translation > table, a global Graphics Translation Table (GTT). For newer generation > GPUs each context has its own translation table, called Per-Process > Graphics Translation Table (PPGTT). Of important note, is that although > -PPGTT is named per-process it is actually per context. When user space > -submits a batchbuffer, the kernel walks the list of GEM buffer objects > -used by the batchbuffer and guarantees that not only is the memory of > -each such GEM buffer object resident but it is also present in the > -(PP)GTT. If the GEM buffer object is not yet placed in the (PP)GTT, > -then it is given an address. Two consequences of this are: the kernel > -needs to edit the batchbuffer submitted to write the correct value of > -the GPU address when a GEM BO is assigned a GPU address and the kernel > +PPGTT is named per-process it is actually per context. In legacy > +(non-vm_bind) mode, when user space submits a batchbuffer, the kernel walks > +the list of GEM buffer objects used by the batchbuffer and guarantees that > +not only is the memory of each such GEM buffer object resident but it is > +also present in the (PP)GTT. If the GEM buffer object is not yet placed in > +the (PP)GTT, then it is given an address. Two consequences of this are: the > +kernel needs to edit the batchbuffer submitted to write the correct value > +of the GPU address when a GEM BO is assigned a GPU address and the kernel > might evict a different GEM BO from the (PP)GTT to make address room > for another GEM BO. Consequently, the ioctls submitting
[Intel-gfx] [PATCH] drm/i915/hwmon: Enable PL1 power limit
Previous documentation suggested that PL1 power limit is always enabled. However we now find this not to be the case on some platforms (such as ATSM). Therefore enable PL1 power limit during hwmon initialization. Bspec: 51864 v2: Add Bspec reference (Gwan-gyeong) Signed-off-by: Ashutosh Dixit Reviewed-by: Gwan-gyeong Mun --- drivers/gpu/drm/i915/i915_hwmon.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c index 1225bc432f0d5..4683a5b96eff1 100644 --- a/drivers/gpu/drm/i915/i915_hwmon.c +++ b/drivers/gpu/drm/i915/i915_hwmon.c @@ -687,6 +687,11 @@ hwm_get_preregistration_info(struct drm_i915_private *i915) for_each_gt(gt, i915, i) hwm_energy(>ddat_gt[i], ); } + + /* Enable PL1 power limit */ + if (i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit)) + hwm_locked_with_pm_intel_uncore_rmw(ddat, hwmon->rg.pkg_rapl_limit, + PKG_PWR_LIM_1_EN, PKG_PWR_LIM_1_EN); } void i915_hwmon_register(struct drm_i915_private *i915) -- 2.38.0
[Intel-gfx] [PATCH v3] vfio: fix deadlock between group lock and kvm lock
After 51cdc8bc120e, we have another deadlock scenario between the
kvm->lock and the vfio group_lock with two different codepaths acquiring
the locks in different order. Specifically in vfio_open_device, vfio
holds the vfio group_lock when issuing device->ops->open_device but some
drivers (like vfio-ap) need to acquire kvm->lock during their open_device
routine; Meanwhile, kvm_vfio_release will acquire the kvm->lock first
before calling vfio_file_set_kvm which will acquire the vfio group_lock.
To resolve this, let's remove the need for the vfio group_lock from the
kvm_vfio_release codepath. This is done by introducing a new spinlock to
protect modifications to the vfio group kvm pointer, and acquiring a kvm
ref from within vfio while holding this spinlock, with the reference held
until the last close for the device in question.
Fixes: 51cdc8bc120e ("kvm/vfio: Fix potential deadlock on vfio group_lock")
Reported-by: Anthony Krowiak
Suggested-by: Jason Gunthorpe
Signed-off-by: Matthew Rosato
---
Changes from v2:
* Relocate the new functions back to vfio_main and externalize to call
from group (Kevin) since cdev will need this too
* s/vfio_kvm_*_kvm/vfio_device_*_kvm/ and only pass device as input.
Handle new kvm_ref_lock directly inside vfio_device_get_kvm (Alex)
* Add assert_lockdep_held for dev_set lock (Alex)
* Internalize error paths for vfio_device_get_kvm_safe and now return
void - either device->kvm is set with a ref taken or is NULL (Alex)
* Other flow suggestions to make the call path cleaner - Thanks! (Alex)
* Can't pass group->kvm to vfio_device_open, as it references the value
outside of new lock. Pass device->kvm to minimize changes in this
fix (Alex, Yi)
Changes from v1:
* use spin_lock instead of spin_lock_irqsave (Jason)
* clear device->kvm_put as part of vfio_kvm_put_kvm (Yi)
* Re-arrange code to avoid referencing the group contents from within
vfio_main (Kevin) which meant moving most of the code in this patch
to group.c along with getting/dropping of the dev_set lock
---
drivers/vfio/group.c | 32 ++
drivers/vfio/vfio.h | 14
drivers/vfio/vfio_main.c | 70
include/linux/vfio.h | 2 +-
4 files changed, 103 insertions(+), 15 deletions(-)
diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
index bb24b2f0271e..7fed4233ca23 100644
--- a/drivers/vfio/group.c
+++ b/drivers/vfio/group.c
@@ -164,13 +164,23 @@ static int vfio_device_group_open(struct vfio_device
*device)
goto out_unlock;
}
+ mutex_lock(>dev_set->lock);
+
/*
-* Here we pass the KVM pointer with the group under the lock. If the
-* device driver will use it, it must obtain a reference and release it
-* during close_device.
+* Before the first device open, get the KVM pointer currently
+* associated with the group (if there is one) and obtain a reference
+* now that will be held until the open_count reaches 0 again. Save
+* the pointer in the device for use by drivers.
*/
- ret = vfio_device_open(device, device->group->iommufd,
- device->group->kvm);
+ if (device->open_count == 0)
+ vfio_device_get_kvm_safe(device);
+
+ ret = vfio_device_open(device, device->group->iommufd, device->kvm);
+
+ if (device->open_count == 0)
+ vfio_device_put_kvm(device);
+
+ mutex_unlock(>dev_set->lock);
out_unlock:
mutex_unlock(>group->group_lock);
@@ -180,7 +190,14 @@ static int vfio_device_group_open(struct vfio_device
*device)
void vfio_device_group_close(struct vfio_device *device)
{
mutex_lock(>group->group_lock);
+ mutex_lock(>dev_set->lock);
+
vfio_device_close(device, device->group->iommufd);
+
+ if (device->open_count == 0)
+ vfio_device_put_kvm(device);
+
+ mutex_unlock(>dev_set->lock);
mutex_unlock(>group->group_lock);
}
@@ -450,6 +467,7 @@ static struct vfio_group *vfio_group_alloc(struct
iommu_group *iommu_group,
refcount_set(>drivers, 1);
mutex_init(>group_lock);
+ spin_lock_init(>kvm_ref_lock);
INIT_LIST_HEAD(>device_list);
mutex_init(>device_lock);
group->iommu_group = iommu_group;
@@ -803,9 +821,9 @@ void vfio_file_set_kvm(struct file *file, struct kvm *kvm)
if (!vfio_file_is_group(file))
return;
- mutex_lock(>group_lock);
+ spin_lock(>kvm_ref_lock);
group->kvm = kvm;
- mutex_unlock(>group_lock);
+ spin_unlock(>kvm_ref_lock);
}
EXPORT_SYMBOL_GPL(vfio_file_set_kvm);
diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
index f8219a438bfb..20d715b0a3a8 100644
--- a/drivers/vfio/vfio.h
+++ b/drivers/vfio/vfio.h
@@ -74,6 +74,7 @@ struct vfio_group {
struct file *opened_file;
struct blocking_notifier_head notifier;
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv (rev2)
== Series Details ==
Series: drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv (rev2)
URL : https://patchwork.freedesktop.org/series/113568/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12684 -> Patchwork_113568v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/index.html
Participating hosts (27 -> 25)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113568v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][1] -> [DMESG-FAIL][2] ([i915#5334])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg1-6: NOTRUN -> [SKIP][3] ([i915#7828])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/bat-dg1-6/igt@kms_chamelium_...@common-hpd-after-suspend.html
Possible fixes
* igt@fbdev@write:
- fi-blb-e6850: [SKIP][4] ([fdo#109271]) -> [PASS][5] +4 similar
issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/fi-blb-e6850/igt@fb...@write.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/fi-blb-e6850/igt@fb...@write.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-1}: [ABORT][6] ([i915#6311] / [i915#7359]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_lrc:
- bat-dg1-6: [ABORT][8] ([i915#4983]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12684/bat-dg1-6/igt@i915_selftest@live@gt_lrc.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/bat-dg1-6/igt@i915_selftest@live@gt_lrc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12684 -> Patchwork_113568v2
CI-20190529: 20190529
CI_DRM_12684: 57eb8680d3ef1213de1d9c607b95e522035036e6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7144: cda71bf809b981a646270963d6b1ccee4fd4643b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113568v2: 57eb8680d3ef1213de1d9c607b95e522035036e6 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
b971a91df4f8 drm/i915/quirks: Add inverted backlight quirk for HP 14-r206nv
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113568v2/index.html
[Intel-gfx] ✗ Fi.CI.BUILD: failure for introduce vm_flags modifier functions
== Series Details == Series: introduce vm_flags modifier functions URL : https://patchwork.freedesktop.org/series/113606/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/113606/revisions/1/mbox/ not applied Applying: mm: introduce vma->vm_flags modifier functions Applying: mm: replace VM_LOCKED_CLEAR_MASK with VM_LOCKED_MASK error: sha1 information is lacking or useless (include/linux/mm.h). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0002 mm: replace VM_LOCKED_CLEAR_MASK with VM_LOCKED_MASK When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pxp: limit drm-errors or warnings on firmware API failures
== Series Details ==
Series: drm/i915/pxp: limit drm-errors or warnings on firmware API failures
URL : https://patchwork.freedesktop.org/series/113584/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12681_full -> Patchwork_113584v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113584v1/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_113584v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@perf@stress-open-close:
- shard-glk: [PASS][1] -> [ABORT][2] ([i915#5213])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-glk9/igt@p...@stress-open-close.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113584v1/shard-glk1/igt@p...@stress-open-close.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][3] ([i915#7742]) -> [PASS][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113584v1/shard-rkl-3/igt@drm_fdi...@virtual-idle.html
* igt@drm_read@short-buffer-block:
- {shard-rkl}:[SKIP][5] ([i915#4098]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@drm_r...@short-buffer-block.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113584v1/shard-rkl-6/igt@drm_r...@short-buffer-block.html
* igt@fbdev@write:
- {shard-tglu}: [SKIP][7] ([i915#2582]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-tglu-6/igt@fb...@write.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113584v1/shard-tglu-1/igt@fb...@write.html
- {shard-rkl}:[SKIP][9] ([i915#2582]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@fb...@write.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113584v1/shard-rkl-6/igt@fb...@write.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][11] ([i915#6252]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113584v1/shard-rkl-4/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[FAIL][13] ([fdo#103375]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@gem_...@in-flight-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113584v1/shard-rkl-1/igt@gem_...@in-flight-suspend.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][15] ([i915#6247]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113584v1/shard-rkl-4/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_reloc@basic-cpu-gtt:
- {shard-rkl}:[SKIP][17] ([i915#3281]) -> [PASS][18] +2 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@gem_exec_re...@basic-cpu-gtt.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113584v1/shard-rkl-5/igt@gem_exec_re...@basic-cpu-gtt.html
* igt@gem_readwrite@read-bad-handle:
- {shard-rkl}:[SKIP][19] ([i915#3282]) -> [PASS][20] +1 similar
issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@gem_readwr...@read-bad-handle.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113584v1/shard-rkl-5/igt@gem_readwr...@read-bad-handle.html
* igt@gen9_exec_parse@shadow-peek:
- {shard-rkl}:[SKIP][21] ([i915#2527]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@gen9_exec_pa...@shadow-peek.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113584v1/shard-rkl-5/igt@gen9_exec_pa...@shadow-peek.html
* igt@i915_pm_dc@dc9-dpms:
- {shard-rkl}:[SKIP][23] ([i915#3361]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@i915_pm...@dc9-dpms.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113584v1/shard-rkl-4/igt@i915_pm...@dc9-dpms.html
* igt@i915_pm_rpm@modeset-lpsp-stress:
- {shard-rkl}:[SKIP][25] ([i915#1397]) -> [PASS][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@i915_pm_...@modeset-lpsp-stress.html
[26]:
Re: [Intel-gfx] [PATCH v10 18/23] drm/i915/vm_bind: Limit vm_bind mode to non-recoverable contexts
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:16:04PM -0800, Niranjana Vishwanathapura wrote:
> Only support vm_bind mode with non-recoverable contexts.
> With new vm_bind mode with eb3 submission path, we need not
> support older recoverable contexts.
>
> Reviewed-by: Matthew Auld
> Signed-off-by: Niranjana Vishwanathapura
Reviewed-by: Andi Shyti
Andi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index fb4d2dab5053..9809c58316c2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -1617,6 +1617,12 @@ i915_gem_create_context(struct drm_i915_private *i915,
> INIT_LIST_HEAD(>stale.engines);
>
> if (pc->vm) {
> + /* Only non-recoverable contexts are allowed in vm_bind mode */
> + if (i915_gem_vm_is_vm_bind_mode(pc->vm) &&
> + (pc->user_flags & BIT(UCONTEXT_RECOVERABLE))) {
> + err = -EINVAL;
> + goto err_ctx;
> + }
> vm = i915_vm_get(pc->vm);
> } else if (HAS_FULL_PPGTT(i915)) {
> struct i915_ppgtt *ppgtt;
> --
> 2.21.0.rc0.32.g243a4c7e27
[Intel-gfx] ✗ Fi.CI.IGT: failure for vfio: fix deadlock between group lock and kvm lock (rev4)
== Series Details ==
Series: vfio: fix deadlock between group lock and kvm lock (rev4)
URL : https://patchwork.freedesktop.org/series/113535/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12681_full -> Patchwork_113535v4_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_113535v4_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_113535v4_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v4/index.html
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113535v4_full:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@execlists:
- shard-glk: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-glk4/igt@i915_selftest@l...@execlists.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v4/shard-glk3/igt@i915_selftest@l...@execlists.html
Known issues
Here are the changes found in Patchwork_113535v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@perf@stress-open-close:
- shard-glk: [PASS][3] -> [ABORT][4] ([i915#5213])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-glk9/igt@p...@stress-open-close.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v4/shard-glk6/igt@p...@stress-open-close.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][5] ([i915#7742]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v4/shard-rkl-5/igt@drm_fdi...@virtual-idle.html
* igt@drm_read@short-buffer-block:
- {shard-tglu}: [SKIP][7] ([i915#7651]) -> [PASS][8] +6 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-tglu-6/igt@drm_r...@short-buffer-block.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v4/shard-tglu-2/igt@drm_r...@short-buffer-block.html
* igt@fbdev@nullptr:
- {shard-rkl}:[SKIP][9] ([i915#2582]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-4/igt@fb...@nullptr.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v4/shard-rkl-6/igt@fb...@nullptr.html
* igt@fbdev@write:
- {shard-tglu}: [SKIP][11] ([i915#2582]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-tglu-6/igt@fb...@write.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v4/shard-tglu-2/igt@fb...@write.html
* igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[FAIL][13] ([fdo#103375]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@gem_...@in-flight-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v4/shard-rkl-5/igt@gem_...@in-flight-suspend.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][15] ([i915#6247]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v4/shard-rkl-3/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_fair@basic-deadline:
- {shard-rkl}:[FAIL][17] ([i915#2846]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-1/igt@gem_exec_f...@basic-deadline.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v4/shard-rkl-4/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][19] ([i915#3281]) -> [PASS][20] +10 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@gem_exec_re...@basic-wc-read-noreloc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v4/shard-rkl-5/igt@gem_exec_re...@basic-wc-read-noreloc.html
* igt@gem_partial_pwrite_pread@writes-after-reads-uncached:
- {shard-rkl}:[SKIP][21] ([i915#3282]) -> [PASS][22] +8 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12681/shard-rkl-3/igt@gem_partial_pwrite_pr...@writes-after-reads-uncached.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113535v4/shard-rkl-5/igt@gem_partial_pwrite_pr...@writes-after-reads-uncached.html
* igt@gen9_exec_parse@bb-start-far:
-
Re: [Intel-gfx] [PATCH v10 12/23] drm/i915/vm_bind: Use common execbuf functions in execbuf path
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:15:58PM -0800, Niranjana Vishwanathapura wrote:
> Update the execbuf path to use common execbuf functions to
> reduce code duplication with the newer execbuf3 path.
>
> Reviewed-by: Matthew Auld
> Signed-off-by: Niranjana Vishwanathapura
Reviewed-by: Andi Shyti
Andi
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 513 ++
> 1 file changed, 39 insertions(+), 474 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 6a7f0227f65f..8b49543f3265 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -28,6 +28,7 @@
> #include "i915_file_private.h"
> #include "i915_gem_clflush.h"
> #include "i915_gem_context.h"
> +#include "i915_gem_execbuffer_common.h"
> #include "i915_gem_evict.h"
> #include "i915_gem_ioctls.h"
> #include "i915_reg.h"
> @@ -236,13 +237,6 @@ enum {
> * the batchbuffer in trusted mode, otherwise the ioctl is rejected.
> */
>
> -struct eb_fence {
> - struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
> - struct dma_fence *dma_fence;
> - u64 value;
> - struct dma_fence_chain *chain_fence;
> -};
> -
> struct i915_execbuffer {
> struct drm_i915_private *i915; /** i915 backpointer */
> struct drm_file *file; /** per-file lookup tables and limits */
> @@ -2452,164 +2446,29 @@ static const enum intel_engine_id user_ring_map[] = {
> [I915_EXEC_VEBOX] = VECS0
> };
>
> -static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct
> intel_context *ce)
> -{
> - struct intel_ring *ring = ce->ring;
> - struct intel_timeline *tl = ce->timeline;
> - struct i915_request *rq;
> -
> - /*
> - * Completely unscientific finger-in-the-air estimates for suitable
> - * maximum user request size (to avoid blocking) and then backoff.
> - */
> - if (intel_ring_update_space(ring) >= PAGE_SIZE)
> - return NULL;
> -
> - /*
> - * Find a request that after waiting upon, there will be at least half
> - * the ring available. The hysteresis allows us to compete for the
> - * shared ring and should mean that we sleep less often prior to
> - * claiming our resources, but not so long that the ring completely
> - * drains before we can submit our next request.
> - */
> - list_for_each_entry(rq, >requests, link) {
> - if (rq->ring != ring)
> - continue;
> -
> - if (__intel_ring_space(rq->postfix,
> -ring->emit, ring->size) > ring->size / 2)
> - break;
> - }
> - if (>link == >requests)
> - return NULL; /* weird, we will check again later for real */
> -
> - return i915_request_get(rq);
> -}
> -
> -static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context
> *ce,
> -bool throttle)
> -{
> - struct intel_timeline *tl;
> - struct i915_request *rq = NULL;
> -
> - /*
> - * Take a local wakeref for preparing to dispatch the execbuf as
> - * we expect to access the hardware fairly frequently in the
> - * process, and require the engine to be kept awake between accesses.
> - * Upon dispatch, we acquire another prolonged wakeref that we hold
> - * until the timeline is idle, which in turn releases the wakeref
> - * taken on the engine, and the parent device.
> - */
> - tl = intel_context_timeline_lock(ce);
> - if (IS_ERR(tl))
> - return PTR_ERR(tl);
> -
> - intel_context_enter(ce);
> - if (throttle)
> - rq = eb_throttle(eb, ce);
> - intel_context_timeline_unlock(tl);
> -
> - if (rq) {
> - bool nonblock = eb->file->filp->f_flags & O_NONBLOCK;
> - long timeout = nonblock ? 0 : MAX_SCHEDULE_TIMEOUT;
> -
> - if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
> - timeout) < 0) {
> - i915_request_put(rq);
> -
> - /*
> - * Error path, cannot use intel_context_timeline_lock as
> - * that is user interruptable and this clean up step
> - * must be done.
> - */
> - mutex_lock(>timeline->mutex);
> - intel_context_exit(ce);
> - mutex_unlock(>timeline->mutex);
> -
> - if (nonblock)
> - return -EWOULDBLOCK;
> - else
> - return -EINTR;
> - }
> - i915_request_put(rq);
> - }
> -
> - return 0;
> -}
> -
> static int eb_pin_engine(struct i915_execbuffer *eb, bool throttle)
> {
> - struct intel_context *ce = eb->context, *child;
> int err;
> -
Re: [Intel-gfx] [PATCH 04/13] drm/i915/dsb: Introduce intel_dsb_finish()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, January 18, 2023 10:01 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 04/13] drm/i915/dsb: Introduce intel_dsb_finish()
>
> From: Ville Syrjälä
>
> Introduce a function to emits whatever commands we need at the end of the
> DSB command buffer. For the moment we only do the tail cacheline
> alignment there, but eventually we might want eg. emit an interrupt.
>
> Signed-off-by: Ville Syrjälä
LGTM.
Reviewed-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 1 +
> drivers/gpu/drm/i915/display/intel_dsb.c | 11 +++
> drivers/gpu/drm/i915/display/intel_dsb.h | 1 +
> 3 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 5d99913429b9..6d6d300fa2df 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1257,6 +1257,7 @@ static void icl_load_luts(const struct
> intel_crtc_state *crtc_state)
> }
>
> if (crtc_state->dsb) {
> + intel_dsb_finish(crtc_state->dsb);
> intel_dsb_commit(crtc_state->dsb);
> intel_dsb_wait(crtc_state->dsb);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 0b2faa33f204..9e25b1345927 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -199,7 +199,7 @@ void intel_dsb_reg_write(struct intel_dsb *dsb,
> }
> }
>
> -static u32 intel_dsb_align_tail(struct intel_dsb *dsb)
> +static void intel_dsb_align_tail(struct intel_dsb *dsb)
> {
> u32 aligned_tail, tail;
>
> @@ -211,8 +211,11 @@ static u32 intel_dsb_align_tail(struct intel_dsb *dsb)
> aligned_tail - tail);
>
> dsb->free_pos = aligned_tail / 4;
> +}
>
> - return aligned_tail;
> +void intel_dsb_finish(struct intel_dsb *dsb) {
> + intel_dsb_align_tail(dsb);
> }
>
> /**
> @@ -228,8 +231,8 @@ void intel_dsb_commit(struct intel_dsb *dsb)
> enum pipe pipe = crtc->pipe;
> u32 tail;
>
> - tail = intel_dsb_align_tail(dsb);
> - if (tail == 0)
> + tail = dsb->free_pos * 4;
> + if (drm_WARN_ON(_priv->drm, !IS_ALIGNED(tail,
> CACHELINE_BYTES)))
> return;
>
> if (is_dsb_busy(dev_priv, pipe, dsb->id)) { diff --git
> a/drivers/gpu/drm/i915/display/intel_dsb.h
> b/drivers/gpu/drm/i915/display/intel_dsb.h
> index 7999199c2464..6b22499e8a5d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.h
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.h
> @@ -15,6 +15,7 @@ struct intel_dsb;
>
> struct intel_dsb *intel_dsb_prepare(struct intel_crtc *crtc,
> unsigned int max_cmds);
> +void intel_dsb_finish(struct intel_dsb *dsb);
> void intel_dsb_cleanup(struct intel_dsb *dsb); void
> intel_dsb_reg_write(struct intel_dsb *dsb,
>i915_reg_t reg, u32 val);
> --
> 2.38.2
Re: [Intel-gfx] [PATCH 03/13] drm/i915/dsb: Split intel_dsb_wait() from intel_dsb_commit()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Wednesday, January 18, 2023 10:01 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 03/13] drm/i915/dsb: Split intel_dsb_wait() from
> intel_dsb_commit()
>
> From: Ville Syrjälä
>
> Starting the DSB execution vs. waiting for it stop are two totally different
> things. Split intel_dsb_wait() from
> intel_dsb_commit() so that we can eventually allow the DSB to execute
> asynchronously.
>
> Signed-off-by: Ville Syrjälä
LGTM.
Reviewed-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 4 +++-
> drivers/gpu/drm/i915/display/intel_dsb.c | 11 +--
> drivers/gpu/drm/i915/display/intel_dsb.h | 1 +
> 3 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index 8d97c299e657..5d99913429b9 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1256,8 +1256,10 @@ static void icl_load_luts(const struct
> intel_crtc_state *crtc_state)
> break;
> }
>
> - if (crtc_state->dsb)
> + if (crtc_state->dsb) {
> intel_dsb_commit(crtc_state->dsb);
> + intel_dsb_wait(crtc_state->dsb);
> + }
> }
>
> static u32 chv_cgm_degamma_ldw(const struct drm_color_lut *color) diff --
> git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index f41146fc84d7..0b2faa33f204 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -235,7 +235,7 @@ void intel_dsb_commit(struct intel_dsb *dsb)
> if (is_dsb_busy(dev_priv, pipe, dsb->id)) {
> drm_err(_priv->drm, "[CRTC:%d:%s] DSB %d is busy\n",
> crtc->base.base.id, crtc->base.name, dsb->id);
> - goto reset;
> + return;
> }
>
> intel_de_write(dev_priv, DSB_CTRL(pipe, dsb->id), @@ -249,13
> +249,20 @@ void intel_dsb_commit(struct intel_dsb *dsb)
> "DSB execution started - head 0x%x, tail 0x%x\n",
> i915_ggtt_offset(dsb->vma),
> i915_ggtt_offset(dsb->vma) + tail);
> +}
> +
> +void intel_dsb_wait(struct intel_dsb *dsb) {
> + struct intel_crtc *crtc = dsb->crtc;
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe pipe = crtc->pipe;
>
> if (wait_for(!is_dsb_busy(dev_priv, pipe, dsb->id), 1))
> drm_err(_priv->drm,
> "[CRTC:%d:%s] DSB %d timed out waiting for idle\n",
> crtc->base.base.id, crtc->base.name, dsb->id);
>
> -reset:
> + /* Attempt to reset it */
> dsb->free_pos = 0;
> dsb->ins_start_offset = 0;
> intel_de_write(dev_priv, DSB_CTRL(pipe, dsb->id), 0); diff --git
> a/drivers/gpu/drm/i915/display/intel_dsb.h
> b/drivers/gpu/drm/i915/display/intel_dsb.h
> index 05c221b6d0a4..7999199c2464 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.h
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.h
> @@ -19,5 +19,6 @@ void intel_dsb_cleanup(struct intel_dsb *dsb); void
> intel_dsb_reg_write(struct intel_dsb *dsb,
>i915_reg_t reg, u32 val);
> void intel_dsb_commit(struct intel_dsb *dsb);
> +void intel_dsb_wait(struct intel_dsb *dsb);
>
> #endif
> --
> 2.38.2
Re: [Intel-gfx] [PATCH 5/5] drm/i915/dmc: check incoming dmc id validity
On Thu, Feb 02, 2023 at 02:04:52PM +0200, Jani Nikula wrote:
> Add validity checks for the dmc ids computed from pipe parameters in
> intel_dmc_enable_pipe() and intel_dmc_disable_pipe(). It's slightly
> difficult for humans and static analyzers alike to ensure the resulting
> dmc ids are within bounds. Just check them and reject invalid ones.
>
> Signed-off-by: Jani Nikula
Patchset looks ok to me:
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index ab0ad8e3e620..3b8e8193d042 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -415,7 +415,9 @@ static void pipedmc_clock_gating_wa(struct
> drm_i915_private *i915, bool enable)
>
> void intel_dmc_enable_pipe(struct drm_i915_private *i915, enum pipe pipe)
> {
> - if (!has_dmc_id_fw(i915, PIPE_TO_DMC_ID(pipe)))
> + enum intel_dmc_id dmc_id = PIPE_TO_DMC_ID(pipe);
> +
> + if (!is_valid_dmc_id(dmc_id) || !has_dmc_id_fw(i915, dmc_id))
> return;
>
> if (DISPLAY_VER(i915) >= 14)
> @@ -426,7 +428,9 @@ void intel_dmc_enable_pipe(struct drm_i915_private *i915,
> enum pipe pipe)
>
> void intel_dmc_disable_pipe(struct drm_i915_private *i915, enum pipe pipe)
> {
> - if (!has_dmc_id_fw(i915, PIPE_TO_DMC_ID(pipe)))
> + enum intel_dmc_id dmc_id = PIPE_TO_DMC_ID(pipe);
> +
> + if (!is_valid_dmc_id(dmc_id) || !has_dmc_id_fw(i915, dmc_id))
> return;
>
> if (DISPLAY_VER(i915) >= 14)
> --
> 2.34.1
>
[Intel-gfx] ✓ Fi.CI.BAT: success for i915: fix memory leak with using debugfs_lookup()
== Series Details ==
Series: i915: fix memory leak with using debugfs_lookup()
URL : https://patchwork.freedesktop.org/series/113603/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12683 -> Patchwork_113603v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/index.html
Participating hosts (26 -> 25)
--
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113603v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-adln-1}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/bat-adln-1/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/bat-adln-1/igt@gem_exec_suspend@basic...@smem.html
Known issues
Here are the changes found in Patchwork_113603v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005: [PASS][3] -> [DMESG-FAIL][4] ([i915#5334])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][5] ([fdo#109271]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/fi-bsw-nick/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050: [PASS][6] -> [FAIL][7] ([i915#6298])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Possible fixes
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[ABORT][8] ([i915#7911]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_pm:
- {bat-rpls-2}: [DMESG-FAIL][10] ([i915#4258]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@reset:
- {bat-rpls-2}: [ABORT][12] ([i915#4983]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/bat-rpls-2/igt@i915_selftest@l...@reset.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
- {bat-rpls-1}: [ABORT][14] ([i915#4983]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/bat-rpls-1/igt@i915_selftest@l...@reset.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113603v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6763]: https://gitlab.freedesktop.org/drm/intel/issues/6763
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12683 -> Patchwork_113603v1
CI-20190529: 20190529
CI_DRM_12683:
Re: [Intel-gfx] [PATCH] drm/i915/gt: Use sysfs_emit() and sysfs_emit_at()
Hi Nirmoy,
On Mon, Jan 30, 2023 at 02:13:58PM +0100, Nirmoy Das wrote:
> Use sysfs_emit() and sysfs_emit_at() in show() callback
> as recommended by Documentation/filesystems/sysfs.rst
>
> Cc: Andi Shyti
> Signed-off-by: Nirmoy Das
Pushed in drm-intel-gt-next.
Thank you,
Andi
> ---
> drivers/gpu/drm/i915/gt/sysfs_engines.c | 34 -
> 1 file changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/sysfs_engines.c
> b/drivers/gpu/drm/i915/gt/sysfs_engines.c
> index f2d9858d827c..323cead181b8 100644
> --- a/drivers/gpu/drm/i915/gt/sysfs_engines.c
> +++ b/drivers/gpu/drm/i915/gt/sysfs_engines.c
> @@ -24,7 +24,7 @@ static struct intel_engine_cs *kobj_to_engine(struct
> kobject *kobj)
> static ssize_t
> name_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
> {
> - return sprintf(buf, "%s\n", kobj_to_engine(kobj)->name);
> + return sysfs_emit(buf, "%s\n", kobj_to_engine(kobj)->name);
> }
>
> static struct kobj_attribute name_attr =
> @@ -33,7 +33,7 @@ __ATTR(name, 0444, name_show, NULL);
> static ssize_t
> class_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
> {
> - return sprintf(buf, "%d\n", kobj_to_engine(kobj)->uabi_class);
> + return sysfs_emit(buf, "%d\n", kobj_to_engine(kobj)->uabi_class);
> }
>
> static struct kobj_attribute class_attr =
> @@ -42,7 +42,7 @@ __ATTR(class, 0444, class_show, NULL);
> static ssize_t
> inst_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
> {
> - return sprintf(buf, "%d\n", kobj_to_engine(kobj)->uabi_instance);
> + return sysfs_emit(buf, "%d\n", kobj_to_engine(kobj)->uabi_instance);
> }
>
> static struct kobj_attribute inst_attr =
> @@ -51,7 +51,7 @@ __ATTR(instance, 0444, inst_show, NULL);
> static ssize_t
> mmio_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf)
> {
> - return sprintf(buf, "0x%x\n", kobj_to_engine(kobj)->mmio_base);
> + return sysfs_emit(buf, "0x%x\n", kobj_to_engine(kobj)->mmio_base);
> }
>
> static struct kobj_attribute mmio_attr =
> @@ -107,11 +107,9 @@ __caps_show(struct intel_engine_cs *engine,
> for_each_set_bit(n, , show_unknown ? BITS_PER_LONG : count) {
> if (n >= count || !repr[n]) {
> if (GEM_WARN_ON(show_unknown))
> - len += snprintf(buf + len, PAGE_SIZE - len,
> - "[%x] ", n);
> + len += sysfs_emit_at(buf, len, "[%x] ", n);
> } else {
> - len += snprintf(buf + len, PAGE_SIZE - len,
> - "%s ", repr[n]);
> + len += sysfs_emit_at(buf, len, "%s ", repr[n]);
> }
> if (GEM_WARN_ON(len >= PAGE_SIZE))
> break;
> @@ -182,7 +180,7 @@ max_spin_show(struct kobject *kobj, struct kobj_attribute
> *attr, char *buf)
> {
> struct intel_engine_cs *engine = kobj_to_engine(kobj);
>
> - return sprintf(buf, "%lu\n", engine->props.max_busywait_duration_ns);
> + return sysfs_emit(buf, "%lu\n", engine->props.max_busywait_duration_ns);
> }
>
> static struct kobj_attribute max_spin_attr =
> @@ -193,7 +191,7 @@ max_spin_default(struct kobject *kobj, struct
> kobj_attribute *attr, char *buf)
> {
> struct intel_engine_cs *engine = kobj_to_engine(kobj);
>
> - return sprintf(buf, "%lu\n", engine->defaults.max_busywait_duration_ns);
> + return sysfs_emit(buf, "%lu\n",
> engine->defaults.max_busywait_duration_ns);
> }
>
> static struct kobj_attribute max_spin_def =
> @@ -236,7 +234,7 @@ timeslice_show(struct kobject *kobj, struct
> kobj_attribute *attr, char *buf)
> {
> struct intel_engine_cs *engine = kobj_to_engine(kobj);
>
> - return sprintf(buf, "%lu\n", engine->props.timeslice_duration_ms);
> + return sysfs_emit(buf, "%lu\n", engine->props.timeslice_duration_ms);
> }
>
> static struct kobj_attribute timeslice_duration_attr =
> @@ -247,7 +245,7 @@ timeslice_default(struct kobject *kobj, struct
> kobj_attribute *attr, char *buf)
> {
> struct intel_engine_cs *engine = kobj_to_engine(kobj);
>
> - return sprintf(buf, "%lu\n", engine->defaults.timeslice_duration_ms);
> + return sysfs_emit(buf, "%lu\n", engine->defaults.timeslice_duration_ms);
> }
>
> static struct kobj_attribute timeslice_duration_def =
> @@ -287,7 +285,7 @@ stop_show(struct kobject *kobj, struct kobj_attribute
> *attr, char *buf)
> {
> struct intel_engine_cs *engine = kobj_to_engine(kobj);
>
> - return sprintf(buf, "%lu\n", engine->props.stop_timeout_ms);
> + return sysfs_emit(buf, "%lu\n", engine->props.stop_timeout_ms);
> }
>
> static struct kobj_attribute stop_timeout_attr =
> @@ -298,7 +296,7 @@ stop_default(struct kobject *kobj, struct kobj_attribute
> *attr, char *buf)
> {
> struct intel_engine_cs *engine =
Re: [Intel-gfx] [PULL] drm-misc-next
[Public] > -Original Message- > From: dim-tools On Behalf Of > John Paul Adrian Glaubitz > Sent: Monday, January 23, 2023 10:01 AM > To: tzimmerm...@suse.de > Cc: tvrtko.ursu...@linux.intel.com; dim-to...@lists.freedesktop.org; > daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; rodrigo.v...@intel.com; airl...@gmail.com > Subject: Re: [PULL] drm-misc-next > > Hi Thomas! > > > Driver Changes: > > > > * Remove obsolete drivers for userspace modesetting i810, mga, r128, > >savage, sis, tdfx, via > > Is the Rage 128 GPU still supported via the generic modesetting driver? > > I'm asking because, we're still supporting PowerMacs in Debian Ports of > which some of those are sporting a Rage 128 GPU. Similar question applies to > the > i810 GPU used in some old ThinkPads, for example. These are not KMS drivers. They are just the kernel component needed for 3D rendering. These drivers have nothing to do with driving the displays on these cards. For display support you need to use the old Xorg DDXs for these cards or the relevant non-DRM fbdev drivers. Alex > > Thanks, > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist >`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dmc: some dmc id related fixes and cleanups
== Series Details ==
Series: drm/i915/dmc: some dmc id related fixes and cleanups
URL : https://patchwork.freedesktop.org/series/113596/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12683 -> Patchwork_113596v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/index.html
Participating hosts (26 -> 26)
--
Additional (1): fi-kbl-soraka
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_113596v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@dmabuf:
- fi-bsw-nick:[PASS][3] -> [DMESG-FAIL][4] ([i915#7562] /
[i915#7913])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/fi-bsw-nick/igt@i915_selftest@l...@dmabuf.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/fi-bsw-nick/igt@i915_selftest@l...@dmabuf.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][5] ([i915#1886])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][6] ([i915#7913])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/fi-kbl-soraka/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium_frames@hdmi-crc-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271]) +15 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-bsw-nick:NOTRUN -> [SKIP][8] ([fdo#109271]) +1 similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/fi-bsw-nick/igt@kms_chamelium_...@common-hpd-after-suspend.html
Possible fixes
* igt@fbdev@write:
- fi-blb-e6850: [SKIP][9] ([fdo#109271]) -> [PASS][10] +4 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/fi-blb-e6850/igt@fb...@write.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/fi-blb-e6850/igt@fb...@write.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[ABORT][11] ([i915#7911]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@reset:
- {bat-rpls-2}: [ABORT][13] ([i915#4983]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12683/bat-rpls-2/igt@i915_selftest@l...@reset.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113596v1/bat-rpls-2/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7562]: https://gitlab.freedesktop.org/drm/intel/issues/7562
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
Build changes
-
* Linux: CI_DRM_12683 -> Patchwork_113596v1
CI-20190529: 20190529
CI_DRM_12683: cbc540884f5894cb0e1c84a3822b80342e852b80 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7144: cda71bf809b981a646270963d6b1ccee4fd4643b @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113596v1: cbc540884f5894cb0e1c84a3822b80342e852b80 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
7326d8aba11a drm/i915/dmc: check incoming dmc id validity
4d0bd34448a5 drm/i915/dmc: add
[Intel-gfx] [PATCH v2 6/6] mm: export dump_mm()
mmap_assert_write_locked() is used in vm_flags modifiers. Because mmap_assert_write_locked() uses dump_mm() and vm_flags are sometimes modified from from inside a module, it's necessary to export dump_mm() function. Signed-off-by: Suren Baghdasaryan --- mm/debug.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/debug.c b/mm/debug.c index 9d3d893dc7f4..96d594e16292 100644 --- a/mm/debug.c +++ b/mm/debug.c @@ -215,6 +215,7 @@ void dump_mm(const struct mm_struct *mm) mm->def_flags, >def_flags ); } +EXPORT_SYMBOL(dump_mm); static bool page_init_poisoning __read_mostly = true; -- 2.39.1
[Intel-gfx] Assertion failure in i915 intel_display.c#assert_plane() after resume from hibernation
Hi A user in Debian, cc'ed reporte the following issue when resuming from hibernation, tested as well on recent 6.1.7 kernel, context see https://bugs.debian.org/971068 > Can repro on the sid kernel, uname -a of > Linux nabtop 6.1.0-2-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.1.7-1 > (2023-01-18) i686 GNU/Linux > > Log below. Backtrace is only trivially different. > > Best, > наб > > -- >8 -- > Jan 22 14:06:46 nabtop kernel: OOM killer disabled. > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Marking nosave pages: [mem > 0x-0x0fff] > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Marking nosave pages: [mem > 0x0009f000-0x000f] > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Marking nosave pages: [mem > 0xb5aa1000-0xb5aa6fff] > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Marking nosave pages: [mem > 0xb5bba000-0xb5c0efff] > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Marking nosave pages: [mem > 0xb5d08000-0xb5f0efff] > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Marking nosave pages: [mem > 0xb5f18000-0xb5f1efff] > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Marking nosave pages: [mem > 0xb5f65000-0xb5f9efff] > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Marking nosave pages: [mem > 0xb5fe1000-0xb5ffefff] > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Marking nosave pages: [mem > 0xb600-0x] > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Basic memory bitmaps created > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Preallocating image memory > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Allocated 183519 pages for > snapshot > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Allocated 734076 kbytes in > 0.70 seconds (1048.68 MB/s) > Jan 22 14:06:46 nabtop kernel: Freezing remaining freezable tasks ... > (elapsed 0.001 seconds) done. > Jan 22 14:06:46 nabtop kernel: wifi1: deauthenticating from de:0d:17:ad:80:55 > by local choice (Reason: 3=DEAUTH_LEAVING) > Jan 22 14:06:46 nabtop kernel: ACPI: EC: interrupt blocked > Jan 22 14:06:46 nabtop kernel: ACPI: PM: Preparing to enter system sleep > state S4 > Jan 22 14:06:46 nabtop kernel: ACPI: EC: event blocked > Jan 22 14:06:46 nabtop kernel: ACPI: EC: EC stopped > Jan 22 14:06:46 nabtop kernel: ACPI: PM: Saving platform NVS memory > Jan 22 14:06:46 nabtop kernel: Disabling non-boot CPUs ... > Jan 22 14:06:46 nabtop kernel: smpboot: CPU 1 is now offline > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Creating image: > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Need to copy 175700 pages > Jan 22 14:06:46 nabtop kernel: PM: hibernation: Normal pages needed: 57765 + > 1024, available pages: 167322 > Jan 22 14:06:46 nabtop kernel: ACPI: PM: Restoring platform NVS memory > Jan 22 14:06:46 nabtop kernel: ACPI: EC: EC started > Jan 22 14:06:46 nabtop kernel: Enabling non-boot CPUs ... > Jan 22 14:06:46 nabtop kernel: x86: Booting SMP configuration: > Jan 22 14:06:46 nabtop kernel: smpboot: Booting Node 0 Processor 1 APIC 0x1 > Jan 22 14:06:46 nabtop kernel: CPU1 is up > Jan 22 14:06:46 nabtop kernel: ACPI: PM: Waking up from system sleep state S4 > Jan 22 14:06:46 nabtop kernel: ACPI: EC: interrupt unblocked > Jan 22 14:06:46 nabtop kernel: ACPI: EC: event unblocked > Jan 22 14:06:46 nabtop kernel: usb usb1: root hub lost power or was reset > Jan 22 14:06:46 nabtop kernel: usb usb2: root hub lost power or was reset > Jan 22 14:06:46 nabtop kernel: usb usb4: root hub lost power or was reset > Jan 22 14:06:46 nabtop kernel: usb usb3: root hub lost power or was reset > Jan 22 14:06:46 nabtop kernel: usb usb6: root hub lost power or was reset > Jan 22 14:06:46 nabtop kernel: usb usb7: root hub lost power or was reset > Jan 22 14:06:46 nabtop kernel: usb usb8: root hub lost power or was reset > Jan 22 14:06:46 nabtop kernel: usb usb5: root hub lost power or was reset > Jan 22 14:06:46 nabtop kernel: sd 0:0:0:0: [sda] Starting disk > Jan 22 14:06:46 nabtop kernel: iwlwifi :08:00.0: Radio type=0x1-0x2-0x0 > Jan 22 14:06:46 nabtop kernel: iwlwifi :08:00.0: Radio type=0x1-0x2-0x0 > Jan 22 14:06:46 nabtop kernel: [ cut here ] > Jan 22 14:06:46 nabtop kernel: primary B assertion failure (expected off, > current on) > Jan 22 14:06:46 nabtop kernel: WARNING: CPU: 0 PID: 1038 at > drivers/gpu/drm/i915/display/intel_display.c:476 assert_plane+0x9f/0xb0 [i915] > Jan 22 14:06:46 nabtop kernel: Modules linked in: ghash_generic gf128mul gcm > ccm algif_aead des_generic libdes ecb algif_skcipher bnep cmac md4 algif_hash > af_alg binfmt_misc btusb btrtl btbcm btintel btmtk bluetooth > jitterentropy_rng sha512_generic ctr drbg joydev ansi_cprng ecdh_generic ecc > iwldvm mac80211 libarc4 iTCO_wdt intel_pmc_bxt snd_hda_codec_conexant > iTCO_vendor_support uvcvideo watchdog snd_hda_codec_generic ledtrig_audio > videobuf2_vmalloc videobuf2_memops i915 videobuf2_v4l2 nls_ascii > snd_hda_intel iwlwifi videobuf2_common snd_intel_dspcfg drm_buddy > snd_intel_sdw_acpi
Re: [Intel-gfx] [PATCH v2 3/6] mm: replace vma->vm_flags direct modifications with modifier calls
On Wed 25-01-23 00:38:48, Suren Baghdasaryan wrote: > Replace direct modifications to vma->vm_flags with calls to modifier > functions to be able to track flag changes and to keep vma locking > correctness. Is this a manual (git grep) based work or have you used Coccinele for the patch generation? My potentially incomplete check $ git grep ">[[:space:]]*vm_flags[[:space:]]*[&|^]=" shows that nothing should be left after this. There is still quite a lot of direct checks of the flags (more than 600). Maybe it would be good to make flags accessible only via accessors which would also prevent any future direct setting of those flags in uncontrolled way as well. Anyway Acked-by: Michal Hocko -- Michal Hocko SUSE Labs
Re: [Intel-gfx] [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control
On 28/01/2023 01:11, Tejun Heo wrote:
On Thu, Jan 12, 2023 at 04:56:07PM +, Tvrtko Ursulin wrote:
...
+ /*
+* 1st pass - reset working values and update hierarchical weights and
+* GPU utilisation.
+*/
+ if (!__start_scanning(root, period_us))
+ goto out_retry; /*
+* Always come back later if scanner races with
+* core cgroup management. (Repeated pattern.)
+*/
+
+ css_for_each_descendant_pre(node, >css) {
+ struct drm_cgroup_state *drmcs = css_to_drmcs(node);
+ struct cgroup_subsys_state *css;
+ unsigned int over_weights = 0;
+ u64 unused_us = 0;
+
+ if (!css_tryget_online(node))
+ goto out_retry;
+
+ /*
+* 2nd pass - calculate initial budgets, mark over budget
+* siblings and add up unused budget for the group.
+*/
+ css_for_each_child(css, >css) {
+ struct drm_cgroup_state *sibling = css_to_drmcs(css);
+
+ if (!css_tryget_online(css)) {
+ css_put(node);
+ goto out_retry;
+ }
+
+ sibling->per_s_budget_us =
+ DIV_ROUND_UP_ULL(drmcs->per_s_budget_us *
+sibling->weight,
+drmcs->sum_children_weights);
+
+ sibling->over = sibling->active_us >
+ sibling->per_s_budget_us;
+ if (sibling->over)
+ over_weights += sibling->weight;
+ else
+ unused_us += sibling->per_s_budget_us -
+sibling->active_us;
+
+ css_put(css);
+ }
+
+ /*
+* 3rd pass - spread unused budget according to relative weights
+* of over budget siblings.
+*/
+ css_for_each_child(css, >css) {
+ struct drm_cgroup_state *sibling = css_to_drmcs(css);
+
+ if (!css_tryget_online(css)) {
+ css_put(node);
+ goto out_retry;
+ }
+
+ if (sibling->over) {
+ u64 budget_us =
+ DIV_ROUND_UP_ULL(unused_us *
+sibling->weight,
+over_weights);
+ sibling->per_s_budget_us += budget_us;
+ sibling->over = sibling->active_us >
+ sibling->per_s_budget_us;
+ }
+
+ css_put(css);
+ }
+
+ css_put(node);
+ }
+
+ /*
+* 4th pass - send out over/under budget notifications.
+*/
+ css_for_each_descendant_post(node, >css) {
+ struct drm_cgroup_state *drmcs = css_to_drmcs(node);
+
+ if (!css_tryget_online(node))
+ goto out_retry;
+
+ if (drmcs->over || drmcs->over_budget)
+ signal_drm_budget(drmcs,
+ drmcs->active_us,
+ drmcs->per_s_budget_us);
+ drmcs->over_budget = drmcs->over;
+
+ css_put(node);
+ }
It keeps bothering me that the distribution logic has no memory. Maybe this
is good enough for coarse control with long cycle durations but it likely
will get in trouble if pushed to finer grained control. State keeping
doesn't require a lot of complexity. The only state that needs tracking is
each cgroup's vtime and then the core should be able to tell specific
drivers how much each cgroup is over or under fairly accurately at any given
time.
That said, this isn't a blocker. What's implemented can work well enough
with coarse enough time grain and that might be enough for the time being
and we can get back to it later. I think Michal already mentioned it but it
might be a good idea to track active and inactive cgroups and build the
weight tree with only active ones. There are machines with a lot of mostly
idle cgroups (> tens of thousands) and tree wide scanning even at low
frequency can become a pretty bad bottleneck.
Right, that's the kind of experience (tens of thousands) I was missing,
thank you. Another one item on my TODO list then but I have a question
first.
When you say active/inactive - to what you are referring in the cgroup
world?
Re: [Intel-gfx] [PULL] drm-misc-next
Hi Thomas! On 1/23/23 16:35, Thomas Zimmermann wrote: The only thing that is not supported any longer is hardware-accelerated 3d rendering. However, this has not worked anyway, as Mesa has dropped support for those chips a long time ago. Correct me if I'm wrong, but I thought that's what Mesa Classic was forked off for? AFAIK Mesa classic is for old radeon, i915 and old nouveau code. The so-called amber branch: https://docs.mesa3d.org/amber.html But the removed code is for even older hardware. https://docs.mesa3d.org/systems.html#deprecated-systems-and-drivers OK, thanks a lot for the clarification! I'm glad the 2D drivers will still work and it seems that news article on Phoronix [1] is a little misleading as from reading the it, it seems that driver support for the afore- mentioned hardware is dropped completely which is it not the case. Thanks, Adrian [1] https://www.phoronix.com/news/Linux-6.3-Dropping-Old-DRM -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Intel-gfx] [PATCH v2 6/6] mm: export dump_mm()
On Wed 25-01-23 00:38:51, Suren Baghdasaryan wrote: > mmap_assert_write_locked() is used in vm_flags modifiers. Because > mmap_assert_write_locked() uses dump_mm() and vm_flags are sometimes > modified from from inside a module, it's necessary to export > dump_mm() function. > > Signed-off-by: Suren Baghdasaryan Acked-by: Michal Hocko > --- > mm/debug.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/debug.c b/mm/debug.c > index 9d3d893dc7f4..96d594e16292 100644 > --- a/mm/debug.c > +++ b/mm/debug.c > @@ -215,6 +215,7 @@ void dump_mm(const struct mm_struct *mm) > mm->def_flags, >def_flags > ); > } > +EXPORT_SYMBOL(dump_mm); > > static bool page_init_poisoning __read_mostly = true; > > -- > 2.39.1 -- Michal Hocko SUSE Labs
[Intel-gfx] [PATCH v2 1/6] mm: introduce vma->vm_flags modifier functions
vm_flags are among VMA attributes which affect decisions like VMA merging
and splitting. Therefore all vm_flags modifications are performed after
taking exclusive mmap_lock to prevent vm_flags updates racing with such
operations. Introduce modifier functions for vm_flags to be used whenever
flags are updated. This way we can better check and control correct
locking behavior during these updates.
Signed-off-by: Suren Baghdasaryan
---
include/linux/mm.h | 37 +
include/linux/mm_types.h | 8 +++-
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c2f62bdce134..b71f2809caac 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -627,6 +627,43 @@ static inline void vma_init(struct vm_area_struct *vma,
struct mm_struct *mm)
INIT_LIST_HEAD(>anon_vma_chain);
}
+/* Use when VMA is not part of the VMA tree and needs no locking */
+static inline void init_vm_flags(struct vm_area_struct *vma,
+unsigned long flags)
+{
+ vma->vm_flags = flags;
+}
+
+/* Use when VMA is part of the VMA tree and modifications need coordination */
+static inline void reset_vm_flags(struct vm_area_struct *vma,
+ unsigned long flags)
+{
+ mmap_assert_write_locked(vma->vm_mm);
+ init_vm_flags(vma, flags);
+}
+
+static inline void set_vm_flags(struct vm_area_struct *vma,
+ unsigned long flags)
+{
+ mmap_assert_write_locked(vma->vm_mm);
+ vma->vm_flags |= flags;
+}
+
+static inline void clear_vm_flags(struct vm_area_struct *vma,
+ unsigned long flags)
+{
+ mmap_assert_write_locked(vma->vm_mm);
+ vma->vm_flags &= ~flags;
+}
+
+static inline void mod_vm_flags(struct vm_area_struct *vma,
+ unsigned long set, unsigned long clear)
+{
+ mmap_assert_write_locked(vma->vm_mm);
+ vma->vm_flags |= set;
+ vma->vm_flags &= ~clear;
+}
+
static inline void vma_set_anonymous(struct vm_area_struct *vma)
{
vma->vm_ops = NULL;
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 2d6d790d9bed..6c7c70bf50dd 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -491,7 +491,13 @@ struct vm_area_struct {
* See vmf_insert_mixed_prot() for discussion.
*/
pgprot_t vm_page_prot;
- unsigned long vm_flags; /* Flags, see mm.h. */
+
+ /*
+* Flags, see mm.h.
+* WARNING! Do not modify directly.
+* Use {init|reset|set|clear|mod}_vm_flags() functions instead.
+*/
+ unsigned long vm_flags;
/*
* For areas with an address space and backing store,
--
2.39.1
Re: [Intel-gfx] [PATCH v2 1/6] mm: introduce vma->vm_flags modifier functions
On Thu, Jan 26, 2023 at 11:17:09AM +0200, Mike Rapoport wrote: > On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote: > > vm_flags are among VMA attributes which affect decisions like VMA merging > > and splitting. Therefore all vm_flags modifications are performed after > > taking exclusive mmap_lock to prevent vm_flags updates racing with such > > operations. Introduce modifier functions for vm_flags to be used whenever > > flags are updated. This way we can better check and control correct > > locking behavior during these updates. > > > > Signed-off-by: Suren Baghdasaryan > > --- > > include/linux/mm.h | 37 + > > include/linux/mm_types.h | 8 +++- > > 2 files changed, 44 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index c2f62bdce134..b71f2809caac 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -627,6 +627,43 @@ static inline void vma_init(struct vm_area_struct > > *vma, struct mm_struct *mm) > > INIT_LIST_HEAD(>anon_vma_chain); > > } > > > > +/* Use when VMA is not part of the VMA tree and needs no locking */ > > +static inline void init_vm_flags(struct vm_area_struct *vma, > > +unsigned long flags) > > I'd suggest to make it vm_flags_init() etc. Thinking more about it, it will be even clearer to name these vma_flags_xyz() > Except that > > Acked-by: Mike Rapoport (IBM) > -- Sincerely yours, Mike.
Re: [Intel-gfx] [PATCH v2 4/6] mm: replace vma->vm_flags indirect modification in ksm_madvise
On Wed, Jan 25, 2023 at 12:38:49AM -0800, Suren Baghdasaryan wrote:
> Replace indirect modifications to vma->vm_flags with calls to modifier
> functions to be able to track flag changes and to keep vma locking
> correctness. Add a BUG_ON check in ksm_madvise() to catch indirect
> vm_flags modification attempts.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
> ---
> arch/powerpc/kvm/book3s_hv_uvmem.c | 5 -
> arch/s390/mm/gmap.c| 5 -
> mm/khugepaged.c| 2 ++
> mm/ksm.c | 2 ++
> 4 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c
> b/arch/powerpc/kvm/book3s_hv_uvmem.c
> index 1d67baa5557a..325a7a47d348 100644
> --- a/arch/powerpc/kvm/book3s_hv_uvmem.c
> +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
> @@ -393,6 +393,7 @@ static int kvmppc_memslot_page_merge(struct kvm *kvm,
> {
> unsigned long gfn = memslot->base_gfn;
> unsigned long end, start = gfn_to_hva(kvm, gfn);
> + unsigned long vm_flags;
> int ret = 0;
> struct vm_area_struct *vma;
> int merge_flag = (merge) ? MADV_MERGEABLE : MADV_UNMERGEABLE;
> @@ -409,12 +410,14 @@ static int kvmppc_memslot_page_merge(struct kvm *kvm,
> ret = H_STATE;
> break;
> }
> + vm_flags = vma->vm_flags;
> ret = ksm_madvise(vma, vma->vm_start, vma->vm_end,
> - merge_flag, >vm_flags);
> + merge_flag, _flags);
> if (ret) {
> ret = H_STATE;
> break;
> }
> + reset_vm_flags(vma, vm_flags);
> start = vma->vm_end;
> } while (end > vma->vm_end);
>
> diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gmap.c
> index 3a695b8a1e3c..d5eb47dcdacb 100644
> --- a/arch/s390/mm/gmap.c
> +++ b/arch/s390/mm/gmap.c
> @@ -2587,14 +2587,17 @@ int gmap_mark_unmergeable(void)
> {
> struct mm_struct *mm = current->mm;
> struct vm_area_struct *vma;
> + unsigned long vm_flags;
> int ret;
> VMA_ITERATOR(vmi, mm, 0);
>
> for_each_vma(vmi, vma) {
> + vm_flags = vma->vm_flags;
> ret = ksm_madvise(vma, vma->vm_start, vma->vm_end,
> - MADV_UNMERGEABLE, >vm_flags);
> + MADV_UNMERGEABLE, _flags);
> if (ret)
> return ret;
> + reset_vm_flags(vma, vm_flags);
> }
> mm->def_flags &= ~VM_MERGEABLE;
> return 0;
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 8abc59345bf2..76b24cd0c179 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -354,6 +354,8 @@ struct attribute_group khugepaged_attr_group = {
> int hugepage_madvise(struct vm_area_struct *vma,
>unsigned long *vm_flags, int advice)
> {
> + /* vma->vm_flags can be changed only using modifier functions */
> + BUG_ON(vm_flags == >vm_flags);
> switch (advice) {
> case MADV_HUGEPAGE:
> #ifdef CONFIG_S390
> diff --git a/mm/ksm.c b/mm/ksm.c
> index 04f1c8c2df11..992b2be9f5e6 100644
> --- a/mm/ksm.c
> +++ b/mm/ksm.c
> @@ -2573,6 +2573,8 @@ int ksm_madvise(struct vm_area_struct *vma, unsigned
> long start,
> struct mm_struct *mm = vma->vm_mm;
> int err;
>
> + /* vma->vm_flags can be changed only using modifier functions */
> + BUG_ON(vm_flags == >vm_flags);
> switch (advice) {
> case MADV_MERGEABLE:
> /*
> --
> 2.39.1
>
>
Re: [Intel-gfx] [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control
On Thu, Jan 12, 2023 at 04:56:07PM +, Tvrtko Ursulin
wrote:
> +static int drmcs_can_attach(struct cgroup_taskset *tset)
> +{
> + int ret;
> +
> + /*
> + * As processes are getting moved between groups we need to ensure
> + * both that the old group does not see a sudden downward jump in the
> + * GPU utilisation, and that the new group does not see a sudden jump
> + * up with all the GPU time clients belonging to the migrated process
> + * have accumulated.
> + *
> + * To achieve that we suspend the scanner until the migration is
> + * completed where the resume at the end ensures both groups start
> + * observing GPU utilisation from a reset state.
> + */
> +
> + ret = mutex_lock_interruptible(_mutex);
> + if (ret)
> + return ret;
> + start_suspend_scanning();
> + mutex_unlock(_mutex);
> +
> + finish_suspend_scanning();
Here's scanning suspension, communicated via
root_drmcs.scanning_suspended = true;
root_drmcs.suspended_period_us = root_drmcs.period_us;
root_drmcs.period_us = 0;
but I don't see those used in scan_worker() and the scanning traversal
can apparently run concurrently with a task migration.
> [...]
> +static bool
> +__start_scanning(struct drm_cgroup_state *root, unsigned int period_us)
> [...]
> + css_for_each_descendant_post(node, >css) {
> [...]
> + active = drmcs_get_active_time_us(drmcs);
> + if (period_us && active > drmcs->prev_active_us)
> + drmcs->active_us += active - drmcs->prev_active_us;
> + drmcs->prev_active_us = active;
drmcs_get_active_time_us() could count a task's contribution here,
the task would migrate to a different drmcs,
and it'd be counted 2nd time.
signature.asc
Description: Digital signature
Re: [Intel-gfx] [PATCH v2 4/6] mm: replace vma->vm_flags indirect modification in ksm_madvise
On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team wrote: > > On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote: > > Replace indirect modifications to vma->vm_flags with calls to modifier > > functions to be able to track flag changes and to keep vma locking > > correctness. Add a BUG_ON check in ksm_madvise() to catch indirect > > vm_flags modification attempts. > > Those BUG_ONs scream to much IMHO. KSM is an MM internal code so I > gueess we should be willing to trust it. Yes, but I really want to prevent an indirect misuse since it was not easy to find these. If you feel strongly about it I will remove them or if you have a better suggestion I'm all for it. > > > Signed-off-by: Suren Baghdasaryan > > Acked-by: Michal Hocko > -- > Michal Hocko > SUSE Labs > > -- > To unsubscribe from this group and stop receiving emails from it, send an > email to kernel-team+unsubscr...@android.com. >
Re: [Intel-gfx] [PATCH v2 4/6] mm: replace vma->vm_flags indirect modification in ksm_madvise
On Wed, Jan 25, 2023 at 9:08 AM Michal Hocko wrote: > > On Wed 25-01-23 08:57:48, Suren Baghdasaryan wrote: > > On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team > > wrote: > > > > > > On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote: > > > > Replace indirect modifications to vma->vm_flags with calls to modifier > > > > functions to be able to track flag changes and to keep vma locking > > > > correctness. Add a BUG_ON check in ksm_madvise() to catch indirect > > > > vm_flags modification attempts. > > > > > > Those BUG_ONs scream to much IMHO. KSM is an MM internal code so I > > > gueess we should be willing to trust it. > > > > Yes, but I really want to prevent an indirect misuse since it was not > > easy to find these. If you feel strongly about it I will remove them > > or if you have a better suggestion I'm all for it. > > You can avoid that by making flags inaccesible directly, right? Ah, you mean Peter's suggestion of using __private? I guess that would cover it. I'll drop these BUG_ONs in the next version. Thanks! > > -- > Michal Hocko > SUSE Labs
Re: [Intel-gfx] [RFC v3 00/12] DRM scheduling cgroup controller
On Thu, Jan 26, 2023 at 05:57:24PM +, Tvrtko Ursulin wrote: > So even if the RFC shows just a simple i915 implementation, the controller > itself shouldn't prevent a smarter approach (via exposed ABI). scan/query + over budget notification is IMO limited in guarantees. > [...] > Yes agreed, and to re-stress out, the ABI as proposed does not preclude > changing from scanning to charging or whatever. The idea was for it to be > compatible in concept with the CPU controller and also avoid baking in the > controlling method to individual drivers. > [...] But I submit to your point of rather not exposing this via cgroup API for possible future refinements. > Secondly, doing this in userspace would require the ability to get some sort > of an atomic snapshot of the whole tree hierarchy to account for changes in > layout of the tree and task migrations. Or some retry logic with some added > ABI fields to enable it. Note, that the proposed implementation is succeptible to miscount due to concurrent tree modifications and task migrations too (scanning may not converge under frequent cgroup layout modifications, and migrating tasks may be summed 0 or >1 times). While in-kernel implementation may assure the snapshot view, it'd come at cost. (Read: since the mechanism isn't precise anyway, I don't suggest a fully synchronized scanning.) Regards, Michal signature.asc Description: Digital signature
Re: [Intel-gfx] [PATCH v2 6/6] mm: export dump_mm()
On Wed, Jan 25, 2023 at 12:38:51AM -0800, Suren Baghdasaryan wrote: > mmap_assert_write_locked() is used in vm_flags modifiers. Because > mmap_assert_write_locked() uses dump_mm() and vm_flags are sometimes > modified from from inside a module, it's necessary to export > dump_mm() function. > > Signed-off-by: Suren Baghdasaryan Acked-by: Mike Rapoport (IBM) > --- > mm/debug.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/mm/debug.c b/mm/debug.c > index 9d3d893dc7f4..96d594e16292 100644 > --- a/mm/debug.c > +++ b/mm/debug.c > @@ -215,6 +215,7 @@ void dump_mm(const struct mm_struct *mm) > mm->def_flags, >def_flags > ); > } > +EXPORT_SYMBOL(dump_mm); > > static bool page_init_poisoning __read_mostly = true; > > -- > 2.39.1 >
Re: [Intel-gfx] [PATCH v2 2/6] mm: replace VM_LOCKED_CLEAR_MASK with VM_LOCKED_MASK
On Wed, Jan 25, 2023 at 12:38:47AM -0800, Suren Baghdasaryan wrote:
> To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
> replace it with VM_LOCKED_MASK bitmask and convert all users.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Mike Rapoport (IBM)
> ---
> include/linux/mm.h | 4 ++--
> kernel/fork.c | 2 +-
> mm/hugetlb.c | 4 ++--
> mm/mlock.c | 6 +++---
> mm/mmap.c | 6 +++---
> mm/mremap.c| 2 +-
> 6 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index b71f2809caac..da62bdd627bf 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -421,8 +421,8 @@ extern unsigned int kobjsize(const void *objp);
> /* This mask defines which mm->def_flags a process can inherit its parent */
> #define VM_INIT_DEF_MASK VM_NOHUGEPAGE
>
> -/* This mask is used to clear all the VMA flags used by mlock */
> -#define VM_LOCKED_CLEAR_MASK (~(VM_LOCKED | VM_LOCKONFAULT))
> +/* This mask represents all the VMA flag bits used by mlock */
> +#define VM_LOCKED_MASK (VM_LOCKED | VM_LOCKONFAULT)
>
> /* Arch-specific flags to clear when updating VM flags on protection change
> */
> #ifndef VM_ARCH_CLEAR
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 6683c1b0f460..03d472051236 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -669,7 +669,7 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> tmp->anon_vma = NULL;
> } else if (anon_vma_fork(tmp, mpnt))
> goto fail_nomem_anon_vma_fork;
> - tmp->vm_flags &= ~(VM_LOCKED | VM_LOCKONFAULT);
> + clear_vm_flags(tmp, VM_LOCKED_MASK);
> file = tmp->vm_file;
> if (file) {
> struct address_space *mapping = file->f_mapping;
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index d20c8b09890e..4ecdbad9a451 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -6973,8 +6973,8 @@ static unsigned long page_table_shareable(struct
> vm_area_struct *svma,
> unsigned long s_end = sbase + PUD_SIZE;
>
> /* Allow segments to share if only one is marked locked */
> - unsigned long vm_flags = vma->vm_flags & VM_LOCKED_CLEAR_MASK;
> - unsigned long svm_flags = svma->vm_flags & VM_LOCKED_CLEAR_MASK;
> + unsigned long vm_flags = vma->vm_flags & ~VM_LOCKED_MASK;
> + unsigned long svm_flags = svma->vm_flags & ~VM_LOCKED_MASK;
>
> /*
>* match the virtual addresses, permission and the alignment of the
> diff --git a/mm/mlock.c b/mm/mlock.c
> index 0336f52e03d7..5c4fff93cd6b 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -497,7 +497,7 @@ static int apply_vma_lock_flags(unsigned long start,
> size_t len,
> if (vma->vm_start != tmp)
> return -ENOMEM;
>
> - newflags = vma->vm_flags & VM_LOCKED_CLEAR_MASK;
> + newflags = vma->vm_flags & ~VM_LOCKED_MASK;
> newflags |= flags;
> /* Here we know that vma->vm_start <= nstart < vma->vm_end. */
> tmp = vma->vm_end;
> @@ -661,7 +661,7 @@ static int apply_mlockall_flags(int flags)
> struct vm_area_struct *vma, *prev = NULL;
> vm_flags_t to_add = 0;
>
> - current->mm->def_flags &= VM_LOCKED_CLEAR_MASK;
> + current->mm->def_flags &= ~VM_LOCKED_MASK;
> if (flags & MCL_FUTURE) {
> current->mm->def_flags |= VM_LOCKED;
>
> @@ -681,7 +681,7 @@ static int apply_mlockall_flags(int flags)
> for_each_vma(vmi, vma) {
> vm_flags_t newflags;
>
> - newflags = vma->vm_flags & VM_LOCKED_CLEAR_MASK;
> + newflags = vma->vm_flags & ~VM_LOCKED_MASK;
> newflags |= to_add;
>
> /* Ignore errors */
> diff --git a/mm/mmap.c b/mm/mmap.c
> index d4abc6feced1..323bd253b25a 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2671,7 +2671,7 @@ unsigned long mmap_region(struct file *file, unsigned
> long addr,
> if ((vm_flags & VM_SPECIAL) || vma_is_dax(vma) ||
> is_vm_hugetlb_page(vma) ||
> vma == get_gate_vma(current->mm))
> - vma->vm_flags &= VM_LOCKED_CLEAR_MASK;
> + clear_vm_flags(vma, VM_LOCKED_MASK);
> else
> mm->locked_vm += (len >> PAGE_SHIFT);
> }
> @@ -3340,8 +3340,8 @@ static struct vm_area_struct *__install_special_mapping(
> vma->vm_start = addr;
> vma->vm_end = addr + len;
>
> - vma->vm_flags = vm_flags | mm->def_flags | VM_DONTEXPAND | VM_SOFTDIRTY;
> - vma->vm_flags &= VM_LOCKED_CLEAR_MASK;
> + init_vm_flags(vma, (vm_flags | mm->def_flags |
> + VM_DONTEXPAND | VM_SOFTDIRTY) & ~VM_LOCKED_MASK);
> vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>
> vma->vm_ops = ops;
> diff --git a/mm/mremap.c
[Intel-gfx] [PATCH v2 5/6] mm: introduce mod_vm_flags_nolock and use it in untrack_pfn
In cases when VMA flags are modified after VMA was isolated and mmap_lock
was downgraded, flags modifications would result in an assertion because
mmap write lock is not held.
Introduce mod_vm_flags_nolock to be used in such situation.
Pass a hint to untrack_pfn to conditionally use mod_vm_flags_nolock for
flags modification and to avoid assertion.
Signed-off-by: Suren Baghdasaryan
---
arch/x86/mm/pat/memtype.c | 10 +++---
include/linux/mm.h| 12 +---
include/linux/pgtable.h | 5 +++--
mm/memory.c | 13 +++--
mm/memremap.c | 4 ++--
mm/mmap.c | 16 ++--
6 files changed, 38 insertions(+), 22 deletions(-)
diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
index ae9645c900fa..d8adc0b42cf2 100644
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -1046,7 +1046,7 @@ void track_pfn_insert(struct vm_area_struct *vma,
pgprot_t *prot, pfn_t pfn)
* can be for the entire vma (in which case pfn, size are zero).
*/
void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn,
-unsigned long size)
+unsigned long size, bool mm_wr_locked)
{
resource_size_t paddr;
unsigned long prot;
@@ -1065,8 +1065,12 @@ void untrack_pfn(struct vm_area_struct *vma, unsigned
long pfn,
size = vma->vm_end - vma->vm_start;
}
free_pfn_range(paddr, size);
- if (vma)
- clear_vm_flags(vma, VM_PAT);
+ if (vma) {
+ if (mm_wr_locked)
+ clear_vm_flags(vma, VM_PAT);
+ else
+ mod_vm_flags_nolock(vma, 0, VM_PAT);
+ }
}
/*
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 55335edd1373..48d49930c411 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -656,12 +656,18 @@ static inline void clear_vm_flags(struct vm_area_struct
*vma,
vma->vm_flags &= ~flags;
}
+static inline void mod_vm_flags_nolock(struct vm_area_struct *vma,
+ unsigned long set, unsigned long clear)
+{
+ vma->vm_flags |= set;
+ vma->vm_flags &= ~clear;
+}
+
static inline void mod_vm_flags(struct vm_area_struct *vma,
unsigned long set, unsigned long clear)
{
mmap_assert_write_locked(vma->vm_mm);
- vma->vm_flags |= set;
- vma->vm_flags &= ~clear;
+ mod_vm_flags_nolock(vma, set, clear);
}
static inline void vma_set_anonymous(struct vm_area_struct *vma)
@@ -2087,7 +2093,7 @@ static inline void zap_vma_pages(struct vm_area_struct
*vma)
}
void unmap_vmas(struct mmu_gather *tlb, struct maple_tree *mt,
struct vm_area_struct *start_vma, unsigned long start,
- unsigned long end);
+ unsigned long end, bool mm_wr_locked);
struct mmu_notifier_range;
diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
index 5fd45454c073..c63cd44777ec 100644
--- a/include/linux/pgtable.h
+++ b/include/linux/pgtable.h
@@ -1185,7 +1185,8 @@ static inline int track_pfn_copy(struct vm_area_struct
*vma)
* can be for the entire vma (in which case pfn, size are zero).
*/
static inline void untrack_pfn(struct vm_area_struct *vma,
- unsigned long pfn, unsigned long size)
+ unsigned long pfn, unsigned long size,
+ bool mm_wr_locked)
{
}
@@ -1203,7 +1204,7 @@ extern void track_pfn_insert(struct vm_area_struct *vma,
pgprot_t *prot,
pfn_t pfn);
extern int track_pfn_copy(struct vm_area_struct *vma);
extern void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn,
- unsigned long size);
+ unsigned long size, bool mm_wr_locked);
extern void untrack_pfn_moved(struct vm_area_struct *vma);
#endif
diff --git a/mm/memory.c b/mm/memory.c
index d6902065e558..5b11b50e2c4a 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1613,7 +1613,7 @@ void unmap_page_range(struct mmu_gather *tlb,
static void unmap_single_vma(struct mmu_gather *tlb,
struct vm_area_struct *vma, unsigned long start_addr,
unsigned long end_addr,
- struct zap_details *details)
+ struct zap_details *details, bool mm_wr_locked)
{
unsigned long start = max(vma->vm_start, start_addr);
unsigned long end;
@@ -1628,7 +1628,7 @@ static void unmap_single_vma(struct mmu_gather *tlb,
uprobe_munmap(vma, start, end);
if (unlikely(vma->vm_flags & VM_PFNMAP))
- untrack_pfn(vma, 0, 0);
+ untrack_pfn(vma, 0, 0, mm_wr_locked);
if (start != end) {
if (unlikely(is_vm_hugetlb_page(vma))) {
@@ -1675,7 +1675,7 @@ static void unmap_single_vma(struct mmu_gather *tlb,
*/
void unmap_vmas(struct mmu_gather *tlb, struct maple_tree *mt,
Re: [Intel-gfx] [PATCH v2 2/6] mm: replace VM_LOCKED_CLEAR_MASK with VM_LOCKED_MASK
On Wed 25-01-23 00:38:47, Suren Baghdasaryan wrote:
> To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
> replace it with VM_LOCKED_MASK bitmask and convert all users.
>
> Signed-off-by: Suren Baghdasaryan
Acked-by: Michal Hocko
> ---
> include/linux/mm.h | 4 ++--
> kernel/fork.c | 2 +-
> mm/hugetlb.c | 4 ++--
> mm/mlock.c | 6 +++---
> mm/mmap.c | 6 +++---
> mm/mremap.c| 2 +-
> 6 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index b71f2809caac..da62bdd627bf 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -421,8 +421,8 @@ extern unsigned int kobjsize(const void *objp);
> /* This mask defines which mm->def_flags a process can inherit its parent */
> #define VM_INIT_DEF_MASK VM_NOHUGEPAGE
>
> -/* This mask is used to clear all the VMA flags used by mlock */
> -#define VM_LOCKED_CLEAR_MASK (~(VM_LOCKED | VM_LOCKONFAULT))
> +/* This mask represents all the VMA flag bits used by mlock */
> +#define VM_LOCKED_MASK (VM_LOCKED | VM_LOCKONFAULT)
>
> /* Arch-specific flags to clear when updating VM flags on protection change
> */
> #ifndef VM_ARCH_CLEAR
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 6683c1b0f460..03d472051236 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -669,7 +669,7 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
> tmp->anon_vma = NULL;
> } else if (anon_vma_fork(tmp, mpnt))
> goto fail_nomem_anon_vma_fork;
> - tmp->vm_flags &= ~(VM_LOCKED | VM_LOCKONFAULT);
> + clear_vm_flags(tmp, VM_LOCKED_MASK);
> file = tmp->vm_file;
> if (file) {
> struct address_space *mapping = file->f_mapping;
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index d20c8b09890e..4ecdbad9a451 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -6973,8 +6973,8 @@ static unsigned long page_table_shareable(struct
> vm_area_struct *svma,
> unsigned long s_end = sbase + PUD_SIZE;
>
> /* Allow segments to share if only one is marked locked */
> - unsigned long vm_flags = vma->vm_flags & VM_LOCKED_CLEAR_MASK;
> - unsigned long svm_flags = svma->vm_flags & VM_LOCKED_CLEAR_MASK;
> + unsigned long vm_flags = vma->vm_flags & ~VM_LOCKED_MASK;
> + unsigned long svm_flags = svma->vm_flags & ~VM_LOCKED_MASK;
>
> /*
>* match the virtual addresses, permission and the alignment of the
> diff --git a/mm/mlock.c b/mm/mlock.c
> index 0336f52e03d7..5c4fff93cd6b 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -497,7 +497,7 @@ static int apply_vma_lock_flags(unsigned long start,
> size_t len,
> if (vma->vm_start != tmp)
> return -ENOMEM;
>
> - newflags = vma->vm_flags & VM_LOCKED_CLEAR_MASK;
> + newflags = vma->vm_flags & ~VM_LOCKED_MASK;
> newflags |= flags;
> /* Here we know that vma->vm_start <= nstart < vma->vm_end. */
> tmp = vma->vm_end;
> @@ -661,7 +661,7 @@ static int apply_mlockall_flags(int flags)
> struct vm_area_struct *vma, *prev = NULL;
> vm_flags_t to_add = 0;
>
> - current->mm->def_flags &= VM_LOCKED_CLEAR_MASK;
> + current->mm->def_flags &= ~VM_LOCKED_MASK;
> if (flags & MCL_FUTURE) {
> current->mm->def_flags |= VM_LOCKED;
>
> @@ -681,7 +681,7 @@ static int apply_mlockall_flags(int flags)
> for_each_vma(vmi, vma) {
> vm_flags_t newflags;
>
> - newflags = vma->vm_flags & VM_LOCKED_CLEAR_MASK;
> + newflags = vma->vm_flags & ~VM_LOCKED_MASK;
> newflags |= to_add;
>
> /* Ignore errors */
> diff --git a/mm/mmap.c b/mm/mmap.c
> index d4abc6feced1..323bd253b25a 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2671,7 +2671,7 @@ unsigned long mmap_region(struct file *file, unsigned
> long addr,
> if ((vm_flags & VM_SPECIAL) || vma_is_dax(vma) ||
> is_vm_hugetlb_page(vma) ||
> vma == get_gate_vma(current->mm))
> - vma->vm_flags &= VM_LOCKED_CLEAR_MASK;
> + clear_vm_flags(vma, VM_LOCKED_MASK);
> else
> mm->locked_vm += (len >> PAGE_SHIFT);
> }
> @@ -3340,8 +3340,8 @@ static struct vm_area_struct *__install_special_mapping(
> vma->vm_start = addr;
> vma->vm_end = addr + len;
>
> - vma->vm_flags = vm_flags | mm->def_flags | VM_DONTEXPAND | VM_SOFTDIRTY;
> - vma->vm_flags &= VM_LOCKED_CLEAR_MASK;
> + init_vm_flags(vma, (vm_flags | mm->def_flags |
> + VM_DONTEXPAND | VM_SOFTDIRTY) & ~VM_LOCKED_MASK);
> vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
>
> vma->vm_ops = ops;
> diff --git a/mm/mremap.c b/mm/mremap.c
> index
Re: [Intel-gfx] [PATCH v2 1/6] mm: introduce vma->vm_flags modifier functions
On Wed, Jan 25, 2023 at 08:49:50AM -0800, Suren Baghdasaryan wrote:
> On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
> > > + /*
> > > + * Flags, see mm.h.
> > > + * WARNING! Do not modify directly.
> > > + * Use {init|reset|set|clear|mod}_vm_flags() functions instead.
> > > + */
> > > + unsigned long vm_flags;
> >
> > We have __private and ACCESS_PRIVATE() to help with enforcing this.
>
> Thanks for pointing this out, Peter! I guess for that I'll need to
> convert all read accesses and provide get_vm_flags() too? That will
> cause some additional churt (a quick search shows 801 hits over 248
> files) but maybe it's worth it? I think Michal suggested that too in
> another patch. Should I do that while we are at it?
Here's a trick I saw somewhere in the VFS:
union {
const vm_flags_t vm_flags;
vm_flags_t __private __vm_flags;
};
Now it can be read by anybody but written only by those using
ACCESS_PRIVATE.
[Intel-gfx] [PATCH v2 4/6] mm: replace vma->vm_flags indirect modification in ksm_madvise
Replace indirect modifications to vma->vm_flags with calls to modifier
functions to be able to track flag changes and to keep vma locking
correctness. Add a BUG_ON check in ksm_madvise() to catch indirect
vm_flags modification attempts.
Signed-off-by: Suren Baghdasaryan
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 5 -
arch/s390/mm/gmap.c| 5 -
mm/khugepaged.c| 2 ++
mm/ksm.c | 2 ++
4 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c
b/arch/powerpc/kvm/book3s_hv_uvmem.c
index 1d67baa5557a..325a7a47d348 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -393,6 +393,7 @@ static int kvmppc_memslot_page_merge(struct kvm *kvm,
{
unsigned long gfn = memslot->base_gfn;
unsigned long end, start = gfn_to_hva(kvm, gfn);
+ unsigned long vm_flags;
int ret = 0;
struct vm_area_struct *vma;
int merge_flag = (merge) ? MADV_MERGEABLE : MADV_UNMERGEABLE;
@@ -409,12 +410,14 @@ static int kvmppc_memslot_page_merge(struct kvm *kvm,
ret = H_STATE;
break;
}
+ vm_flags = vma->vm_flags;
ret = ksm_madvise(vma, vma->vm_start, vma->vm_end,
- merge_flag, >vm_flags);
+ merge_flag, _flags);
if (ret) {
ret = H_STATE;
break;
}
+ reset_vm_flags(vma, vm_flags);
start = vma->vm_end;
} while (end > vma->vm_end);
diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gmap.c
index 3a695b8a1e3c..d5eb47dcdacb 100644
--- a/arch/s390/mm/gmap.c
+++ b/arch/s390/mm/gmap.c
@@ -2587,14 +2587,17 @@ int gmap_mark_unmergeable(void)
{
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
+ unsigned long vm_flags;
int ret;
VMA_ITERATOR(vmi, mm, 0);
for_each_vma(vmi, vma) {
+ vm_flags = vma->vm_flags;
ret = ksm_madvise(vma, vma->vm_start, vma->vm_end,
- MADV_UNMERGEABLE, >vm_flags);
+ MADV_UNMERGEABLE, _flags);
if (ret)
return ret;
+ reset_vm_flags(vma, vm_flags);
}
mm->def_flags &= ~VM_MERGEABLE;
return 0;
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 8abc59345bf2..76b24cd0c179 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -354,6 +354,8 @@ struct attribute_group khugepaged_attr_group = {
int hugepage_madvise(struct vm_area_struct *vma,
unsigned long *vm_flags, int advice)
{
+ /* vma->vm_flags can be changed only using modifier functions */
+ BUG_ON(vm_flags == >vm_flags);
switch (advice) {
case MADV_HUGEPAGE:
#ifdef CONFIG_S390
diff --git a/mm/ksm.c b/mm/ksm.c
index 04f1c8c2df11..992b2be9f5e6 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -2573,6 +2573,8 @@ int ksm_madvise(struct vm_area_struct *vma, unsigned long
start,
struct mm_struct *mm = vma->vm_mm;
int err;
+ /* vma->vm_flags can be changed only using modifier functions */
+ BUG_ON(vm_flags == >vm_flags);
switch (advice) {
case MADV_MERGEABLE:
/*
--
2.39.1
Re: [Intel-gfx] [PATCH v2 1/6] mm: introduce vma->vm_flags modifier functions
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> vm_flags are among VMA attributes which affect decisions like VMA merging
> and splitting. Therefore all vm_flags modifications are performed after
> taking exclusive mmap_lock to prevent vm_flags updates racing with such
> operations. Introduce modifier functions for vm_flags to be used whenever
> flags are updated. This way we can better check and control correct
> locking behavior during these updates.
>
> Signed-off-by: Suren Baghdasaryan
> ---
> include/linux/mm.h | 37 +
> include/linux/mm_types.h | 8 +++-
> 2 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index c2f62bdce134..b71f2809caac 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -627,6 +627,43 @@ static inline void vma_init(struct vm_area_struct *vma,
> struct mm_struct *mm)
> INIT_LIST_HEAD(>anon_vma_chain);
> }
>
> +/* Use when VMA is not part of the VMA tree and needs no locking */
> +static inline void init_vm_flags(struct vm_area_struct *vma,
> + unsigned long flags)
I'd suggest to make it vm_flags_init() etc.
Except that
Acked-by: Mike Rapoport (IBM)
> +{
> + vma->vm_flags = flags;
> +}
> +
> +/* Use when VMA is part of the VMA tree and modifications need coordination
> */
> +static inline void reset_vm_flags(struct vm_area_struct *vma,
> + unsigned long flags)
> +{
> + mmap_assert_write_locked(vma->vm_mm);
> + init_vm_flags(vma, flags);
> +}
> +
> +static inline void set_vm_flags(struct vm_area_struct *vma,
> + unsigned long flags)
> +{
> + mmap_assert_write_locked(vma->vm_mm);
> + vma->vm_flags |= flags;
> +}
> +
> +static inline void clear_vm_flags(struct vm_area_struct *vma,
> + unsigned long flags)
> +{
> + mmap_assert_write_locked(vma->vm_mm);
> + vma->vm_flags &= ~flags;
> +}
> +
> +static inline void mod_vm_flags(struct vm_area_struct *vma,
> + unsigned long set, unsigned long clear)
> +{
> + mmap_assert_write_locked(vma->vm_mm);
> + vma->vm_flags |= set;
> + vma->vm_flags &= ~clear;
> +}
> +
> static inline void vma_set_anonymous(struct vm_area_struct *vma)
> {
> vma->vm_ops = NULL;
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 2d6d790d9bed..6c7c70bf50dd 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -491,7 +491,13 @@ struct vm_area_struct {
>* See vmf_insert_mixed_prot() for discussion.
>*/
> pgprot_t vm_page_prot;
> - unsigned long vm_flags; /* Flags, see mm.h. */
> +
> + /*
> + * Flags, see mm.h.
> + * WARNING! Do not modify directly.
> + * Use {init|reset|set|clear|mod}_vm_flags() functions instead.
> + */
> + unsigned long vm_flags;
>
> /*
>* For areas with an address space and backing store,
> --
> 2.39.1
>
>
[Intel-gfx] [PATCH v2 2/6] mm: replace VM_LOCKED_CLEAR_MASK with VM_LOCKED_MASK
To simplify the usage of VM_LOCKED_CLEAR_MASK in clear_vm_flags(),
replace it with VM_LOCKED_MASK bitmask and convert all users.
Signed-off-by: Suren Baghdasaryan
---
include/linux/mm.h | 4 ++--
kernel/fork.c | 2 +-
mm/hugetlb.c | 4 ++--
mm/mlock.c | 6 +++---
mm/mmap.c | 6 +++---
mm/mremap.c| 2 +-
6 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index b71f2809caac..da62bdd627bf 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -421,8 +421,8 @@ extern unsigned int kobjsize(const void *objp);
/* This mask defines which mm->def_flags a process can inherit its parent */
#define VM_INIT_DEF_MASK VM_NOHUGEPAGE
-/* This mask is used to clear all the VMA flags used by mlock */
-#define VM_LOCKED_CLEAR_MASK (~(VM_LOCKED | VM_LOCKONFAULT))
+/* This mask represents all the VMA flag bits used by mlock */
+#define VM_LOCKED_MASK (VM_LOCKED | VM_LOCKONFAULT)
/* Arch-specific flags to clear when updating VM flags on protection change */
#ifndef VM_ARCH_CLEAR
diff --git a/kernel/fork.c b/kernel/fork.c
index 6683c1b0f460..03d472051236 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -669,7 +669,7 @@ static __latent_entropy int dup_mmap(struct mm_struct *mm,
tmp->anon_vma = NULL;
} else if (anon_vma_fork(tmp, mpnt))
goto fail_nomem_anon_vma_fork;
- tmp->vm_flags &= ~(VM_LOCKED | VM_LOCKONFAULT);
+ clear_vm_flags(tmp, VM_LOCKED_MASK);
file = tmp->vm_file;
if (file) {
struct address_space *mapping = file->f_mapping;
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index d20c8b09890e..4ecdbad9a451 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6973,8 +6973,8 @@ static unsigned long page_table_shareable(struct
vm_area_struct *svma,
unsigned long s_end = sbase + PUD_SIZE;
/* Allow segments to share if only one is marked locked */
- unsigned long vm_flags = vma->vm_flags & VM_LOCKED_CLEAR_MASK;
- unsigned long svm_flags = svma->vm_flags & VM_LOCKED_CLEAR_MASK;
+ unsigned long vm_flags = vma->vm_flags & ~VM_LOCKED_MASK;
+ unsigned long svm_flags = svma->vm_flags & ~VM_LOCKED_MASK;
/*
* match the virtual addresses, permission and the alignment of the
diff --git a/mm/mlock.c b/mm/mlock.c
index 0336f52e03d7..5c4fff93cd6b 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -497,7 +497,7 @@ static int apply_vma_lock_flags(unsigned long start, size_t
len,
if (vma->vm_start != tmp)
return -ENOMEM;
- newflags = vma->vm_flags & VM_LOCKED_CLEAR_MASK;
+ newflags = vma->vm_flags & ~VM_LOCKED_MASK;
newflags |= flags;
/* Here we know that vma->vm_start <= nstart < vma->vm_end. */
tmp = vma->vm_end;
@@ -661,7 +661,7 @@ static int apply_mlockall_flags(int flags)
struct vm_area_struct *vma, *prev = NULL;
vm_flags_t to_add = 0;
- current->mm->def_flags &= VM_LOCKED_CLEAR_MASK;
+ current->mm->def_flags &= ~VM_LOCKED_MASK;
if (flags & MCL_FUTURE) {
current->mm->def_flags |= VM_LOCKED;
@@ -681,7 +681,7 @@ static int apply_mlockall_flags(int flags)
for_each_vma(vmi, vma) {
vm_flags_t newflags;
- newflags = vma->vm_flags & VM_LOCKED_CLEAR_MASK;
+ newflags = vma->vm_flags & ~VM_LOCKED_MASK;
newflags |= to_add;
/* Ignore errors */
diff --git a/mm/mmap.c b/mm/mmap.c
index d4abc6feced1..323bd253b25a 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2671,7 +2671,7 @@ unsigned long mmap_region(struct file *file, unsigned
long addr,
if ((vm_flags & VM_SPECIAL) || vma_is_dax(vma) ||
is_vm_hugetlb_page(vma) ||
vma == get_gate_vma(current->mm))
- vma->vm_flags &= VM_LOCKED_CLEAR_MASK;
+ clear_vm_flags(vma, VM_LOCKED_MASK);
else
mm->locked_vm += (len >> PAGE_SHIFT);
}
@@ -3340,8 +3340,8 @@ static struct vm_area_struct *__install_special_mapping(
vma->vm_start = addr;
vma->vm_end = addr + len;
- vma->vm_flags = vm_flags | mm->def_flags | VM_DONTEXPAND | VM_SOFTDIRTY;
- vma->vm_flags &= VM_LOCKED_CLEAR_MASK;
+ init_vm_flags(vma, (vm_flags | mm->def_flags |
+ VM_DONTEXPAND | VM_SOFTDIRTY) & ~VM_LOCKED_MASK);
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
vma->vm_ops = ops;
diff --git a/mm/mremap.c b/mm/mremap.c
index 1b3ee02bead7..35db9752cb6a 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -687,7 +687,7 @@ static unsigned long move_vma(struct vm_area_struct *vma,
if (unlikely(!err && (flags & MREMAP_DONTUNMAP))) {
Re: [Intel-gfx] [PULL] drm-misc-next
Hi Thomas! On 1/23/23 16:13, Thomas Zimmermann wrote: Driver Changes: * Remove obsolete drivers for userspace modesetting i810, mga, r128, savage, sis, tdfx, via Is the Rage 128 GPU still supported via the generic modesetting driver? I'm asking because, we're still supporting PowerMacs in Debian Ports of which some of those are sporting a Rage 128 GPU. Similar question applies to the i810 GPU used in some old ThinkPads, for example. Yes, all of those chips are still supported by the generic modesetting drivers and even the old userspace Xorg drivers. OK, good to know. The only thing that is not supported any longer is hardware-accelerated 3d rendering. However, this has not worked anyway, as Mesa has dropped support for those chips a long time ago. Correct me if I'm wrong, but I thought that's what Mesa Classic was forked off for? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [Intel-gfx] [PATCH v2 4/6] mm: replace vma->vm_flags indirect modification in ksm_madvise
On Wed 25-01-23 08:57:48, Suren Baghdasaryan wrote: > On Wed, Jan 25, 2023 at 1:38 AM 'Michal Hocko' via kernel-team > wrote: > > > > On Wed 25-01-23 00:38:49, Suren Baghdasaryan wrote: > > > Replace indirect modifications to vma->vm_flags with calls to modifier > > > functions to be able to track flag changes and to keep vma locking > > > correctness. Add a BUG_ON check in ksm_madvise() to catch indirect > > > vm_flags modification attempts. > > > > Those BUG_ONs scream to much IMHO. KSM is an MM internal code so I > > gueess we should be willing to trust it. > > Yes, but I really want to prevent an indirect misuse since it was not > easy to find these. If you feel strongly about it I will remove them > or if you have a better suggestion I'm all for it. You can avoid that by making flags inaccesible directly, right? -- Michal Hocko SUSE Labs
Re: [Intel-gfx] [PATCH v2 5/6] mm: introduce mod_vm_flags_nolock and use it in untrack_pfn
On Wed, Jan 25, 2023 at 1:42 AM Michal Hocko wrote:
>
> On Wed 25-01-23 00:38:50, Suren Baghdasaryan wrote:
> > In cases when VMA flags are modified after VMA was isolated and mmap_lock
> > was downgraded, flags modifications would result in an assertion because
> > mmap write lock is not held.
> > Introduce mod_vm_flags_nolock to be used in such situation.
> > Pass a hint to untrack_pfn to conditionally use mod_vm_flags_nolock for
> > flags modification and to avoid assertion.
>
> The changelog nor the documentation of mod_vm_flags_nolock
> really explain when it is safe to use it. This is really important for
> future potential users.
True. I'll add clarification in the comments and in the changelog. Thanks!
>
> > Signed-off-by: Suren Baghdasaryan
> > ---
> > arch/x86/mm/pat/memtype.c | 10 +++---
> > include/linux/mm.h| 12 +---
> > include/linux/pgtable.h | 5 +++--
> > mm/memory.c | 13 +++--
> > mm/memremap.c | 4 ++--
> > mm/mmap.c | 16 ++--
> > 6 files changed, 38 insertions(+), 22 deletions(-)
> >
> > diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
> > index ae9645c900fa..d8adc0b42cf2 100644
> > --- a/arch/x86/mm/pat/memtype.c
> > +++ b/arch/x86/mm/pat/memtype.c
> > @@ -1046,7 +1046,7 @@ void track_pfn_insert(struct vm_area_struct *vma,
> > pgprot_t *prot, pfn_t pfn)
> > * can be for the entire vma (in which case pfn, size are zero).
> > */
> > void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn,
> > - unsigned long size)
> > + unsigned long size, bool mm_wr_locked)
> > {
> > resource_size_t paddr;
> > unsigned long prot;
> > @@ -1065,8 +1065,12 @@ void untrack_pfn(struct vm_area_struct *vma,
> > unsigned long pfn,
> > size = vma->vm_end - vma->vm_start;
> > }
> > free_pfn_range(paddr, size);
> > - if (vma)
> > - clear_vm_flags(vma, VM_PAT);
> > + if (vma) {
> > + if (mm_wr_locked)
> > + clear_vm_flags(vma, VM_PAT);
> > + else
> > + mod_vm_flags_nolock(vma, 0, VM_PAT);
> > + }
> > }
> >
> > /*
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 55335edd1373..48d49930c411 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -656,12 +656,18 @@ static inline void clear_vm_flags(struct
> > vm_area_struct *vma,
> > vma->vm_flags &= ~flags;
> > }
> >
> > +static inline void mod_vm_flags_nolock(struct vm_area_struct *vma,
> > +unsigned long set, unsigned long clear)
> > +{
> > + vma->vm_flags |= set;
> > + vma->vm_flags &= ~clear;
> > +}
> > +
> > static inline void mod_vm_flags(struct vm_area_struct *vma,
> > unsigned long set, unsigned long clear)
> > {
> > mmap_assert_write_locked(vma->vm_mm);
> > - vma->vm_flags |= set;
> > - vma->vm_flags &= ~clear;
> > + mod_vm_flags_nolock(vma, set, clear);
> > }
> >
> > static inline void vma_set_anonymous(struct vm_area_struct *vma)
> > @@ -2087,7 +2093,7 @@ static inline void zap_vma_pages(struct
> > vm_area_struct *vma)
> > }
> > void unmap_vmas(struct mmu_gather *tlb, struct maple_tree *mt,
> > struct vm_area_struct *start_vma, unsigned long start,
> > - unsigned long end);
> > + unsigned long end, bool mm_wr_locked);
> >
> > struct mmu_notifier_range;
> >
> > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> > index 5fd45454c073..c63cd44777ec 100644
> > --- a/include/linux/pgtable.h
> > +++ b/include/linux/pgtable.h
> > @@ -1185,7 +1185,8 @@ static inline int track_pfn_copy(struct
> > vm_area_struct *vma)
> > * can be for the entire vma (in which case pfn, size are zero).
> > */
> > static inline void untrack_pfn(struct vm_area_struct *vma,
> > -unsigned long pfn, unsigned long size)
> > +unsigned long pfn, unsigned long size,
> > +bool mm_wr_locked)
> > {
> > }
> >
> > @@ -1203,7 +1204,7 @@ extern void track_pfn_insert(struct vm_area_struct
> > *vma, pgprot_t *prot,
> >pfn_t pfn);
> > extern int track_pfn_copy(struct vm_area_struct *vma);
> > extern void untrack_pfn(struct vm_area_struct *vma, unsigned long pfn,
> > - unsigned long size);
> > + unsigned long size, bool mm_wr_locked);
> > extern void untrack_pfn_moved(struct vm_area_struct *vma);
> > #endif
> >
> > diff --git a/mm/memory.c b/mm/memory.c
> > index d6902065e558..5b11b50e2c4a 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -1613,7 +1613,7 @@ void unmap_page_range(struct mmu_gather *tlb,
> > static void unmap_single_vma(struct mmu_gather *tlb,
> > struct vm_area_struct *vma, unsigned long start_addr,
> > unsigned long
Re: [Intel-gfx] [PATCH v2 1/6] mm: introduce vma->vm_flags modifier functions
On Wed, Jan 25, 2023 at 10:37 AM Matthew Wilcox wrote:
>
> On Wed, Jan 25, 2023 at 08:49:50AM -0800, Suren Baghdasaryan wrote:
> > On Wed, Jan 25, 2023 at 1:10 AM Peter Zijlstra wrote:
> > > > + /*
> > > > + * Flags, see mm.h.
> > > > + * WARNING! Do not modify directly.
> > > > + * Use {init|reset|set|clear|mod}_vm_flags() functions instead.
> > > > + */
> > > > + unsigned long vm_flags;
> > >
> > > We have __private and ACCESS_PRIVATE() to help with enforcing this.
> >
> > Thanks for pointing this out, Peter! I guess for that I'll need to
> > convert all read accesses and provide get_vm_flags() too? That will
> > cause some additional churt (a quick search shows 801 hits over 248
> > files) but maybe it's worth it? I think Michal suggested that too in
> > another patch. Should I do that while we are at it?
>
> Here's a trick I saw somewhere in the VFS:
>
> union {
> const vm_flags_t vm_flags;
> vm_flags_t __private __vm_flags;
> };
>
> Now it can be read by anybody but written only by those using
> ACCESS_PRIVATE.
Huh, this is quite nice! I think it does not save us from the cases
when vma->vm_flags is passed by a reference and modified indirectly,
like in ksm_madvise()? Though maybe such usecases are so rare (I found
only 2 cases) that we can ignore this?
Re: [Intel-gfx] [PATCH v2 3/6] mm: replace vma->vm_flags direct modifications with modifier calls
Hi, On Wed, Jan 25, 2023 at 12:38:48AM -0800, Suren Baghdasaryan wrote: > Replace direct modifications to vma->vm_flags with calls to modifier > functions to be able to track flag changes and to keep vma locking > correctness. > > Signed-off-by: Suren Baghdasaryan > --- > [...] > drivers/hsi/clients/cmt_speech.c | 2 +- > 120 files changed, 188 insertions(+), 199 deletions(-) > [...] > diff --git a/drivers/hsi/clients/cmt_speech.c > b/drivers/hsi/clients/cmt_speech.c > index 8069f795c864..952a31e742a1 100644 > --- a/drivers/hsi/clients/cmt_speech.c > +++ b/drivers/hsi/clients/cmt_speech.c > @@ -1264,7 +1264,7 @@ static int cs_char_mmap(struct file *file, struct > vm_area_struct *vma) > if (vma_pages(vma) != 1) > return -EINVAL; > > - vma->vm_flags |= VM_IO | VM_DONTDUMP | VM_DONTEXPAND; > + set_vm_flags(vma, VM_IO | VM_DONTDUMP | VM_DONTEXPAND); > vma->vm_ops = _char_vm_ops; > vma->vm_private_data = file->private_data; > Acked-by: Sebastian Reichel -- Sebastian signature.asc Description: PGP signature
