Re: [Intel-gfx] [PATCH 1/7] drm/i915: Move GGTT fence registers under gt/
Chris Wilson writes:
> Since the fence registers control HW detiling throught the GGTT
> aperture, make them a part of the intel_ggtt under gt/
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/Makefile | 2 +-
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
> .../intel_ggtt_fencing.c} | 27 +++
> .../intel_ggtt_fencing.h} | 9 +++
> drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +-
> drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
> drivers/gpu/drm/i915/gvt/aperture_gm.c| 2 +-
> drivers/gpu/drm/i915/i915_drv.c | 6 ++---
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> drivers/gpu/drm/i915/i915_gem.c | 2 +-
> drivers/gpu/drm/i915/i915_vma.h | 1 -
> drivers/gpu/drm/i915/selftests/i915_gem.c | 2 +-
> 12 files changed, 24 insertions(+), 34 deletions(-)
> rename drivers/gpu/drm/i915/{i915_gem_fence_reg.c =>
> gt/intel_ggtt_fencing.c} (97%)
> rename drivers/gpu/drm/i915/{i915_gem_fence_reg.h =>
> gt/intel_ggtt_fencing.h} (92%)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 9f887a86e555..1b2ed963179c 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -92,6 +92,7 @@ gt-y += \
> gt/intel_engine_pool.o \
> gt/intel_engine_user.o \
> gt/intel_ggtt.o \
> + gt/intel_ggtt_fencing.o \
> gt/intel_gt.o \
> gt/intel_gt_irq.o \
> gt/intel_gt_pm.o \
> @@ -153,7 +154,6 @@ i915-y += \
> i915_buddy.o \
> i915_cmd_parser.o \
> i915_gem_evict.o \
> - i915_gem_fence_reg.o \
> i915_gem_gtt.o \
> i915_gem.o \
> i915_globals.o \
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index aed498a0d032..a7b72fa569a7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -65,7 +65,7 @@ static int ggtt_init_hw(struct i915_ggtt *ggtt)
> ggtt->mappable_end);
> }
>
> - i915_ggtt_init_fences(ggtt);
> + intel_ggtt_init_fences(ggtt);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> similarity index 97%
> rename from drivers/gpu/drm/i915/i915_gem_fence_reg.c
> rename to drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> index d152b648c73c..94af75673a58 100644
> --- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> @@ -233,16 +233,9 @@ static int fence_update(struct i915_fence_reg *fence,
> int ret;
>
> if (vma) {
> - if (!i915_vma_is_map_and_fenceable(vma))
> - return -EINVAL;
> -
> - if (drm_WARN(&uncore->i915->drm,
> - !i915_gem_object_get_stride(vma->obj) ||
> - !i915_gem_object_get_tiling(vma->obj),
> - "bogus fence setup with stride: 0x%x, tiling mode:
> %i\n",
> - i915_gem_object_get_stride(vma->obj),
> - i915_gem_object_get_tiling(vma->obj)))
> - return -EINVAL;
> + GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
> + GEM_BUG_ON(!i915_gem_object_get_stride(vma->obj) ||
> +!i915_gem_object_get_tiling(vma->obj));
>
> ret = i915_vma_sync(vma);
> if (ret)
> @@ -276,7 +269,7 @@ static int fence_update(struct i915_fence_reg *fence,
> /*
>* We only need to update the register itself if the device is awake.
>* If the device is currently powered down, we will defer the write
> - * to the runtime resume, see i915_gem_restore_fences().
> + * to the runtime resume, see intel_ggtt_restore_fences().
>*
>* This only works for removing the fence register, on acquisition
>* the caller must hold the rpm wakeref. The fence register must
> @@ -487,14 +480,14 @@ void i915_unreserve_fence(struct i915_fence_reg *fence)
> }
>
> /**
> - * i915_gem_restore_fences - restore fence state
> + * intel_ggtt_restore_fences - restore fence state
> * @ggtt: Global GTT
> *
> * Restore the hw fence state to match the software tracking again, to be
> called
> * after a gpu reset and on resume. Note that on runtime suspend we only
> cancel
> * the fences, to be reacquired by the user later.
> */
> -void i915_gem_restore_fences(struct i915_ggtt *ggtt)
> +void intel_ggtt_restore_fences(struct i915_ggtt *ggtt)
> {
> int i;
>
> @@ -746,7 +739,7 @@ static void detect_bit_6_swizzle(struct i915_ggtt *ggtt)
> * bit 17 of its physical address and therefore being interpreted differently
> * by the GPU.
> */
> -static void i915_gem_swizzle_page(struct page *page)
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Remove manual save/resume of fence register state
Chris Wilson writes:
> Since we always reload the fence register state on runtime resume,
> having it explicitly in the S0ix resume code is redundant. Indeed, it
> is not even being used!
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ddd5b40cbbbc..a7ea1d855359 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -539,7 +539,6 @@ struct i915_suspend_saved_registers {
> u32 saveSWF0[16];
> u32 saveSWF1[16];
> u32 saveSWF3[3];
> - u64 saveFENCE[I915_MAX_NUM_FENCES];
> u32 savePCH_PORT_HOTPLUG;
> u16 saveGCDGMBUS;
> };
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Requesting access to CLOSE the issue
Hi , When I was going through the gitlab issues,I encountered an issue https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/186 for which the patch is merged in 5.5 kernel and becomes the duplicate of https://gitlab.freedesktop.org/drm/intel/issues/673 and can be CLOSED. I didn't get to see CLOSE option in the issue. Can anyone help me out with this considering as high priority? Regards, Sri Lakshmi Karanam. [cid:image002.png@01D5FB92.2E7F2860] ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/gt: Allocate i915_fence_reg array
Chris Wilson writes:
> Since the number of fence regs can vary dramactically between platforms,
> allocate the array on demand so we don't waste as much space.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 6 --
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 10 ++
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 1 +
> drivers/gpu/drm/i915/gt/intel_gtt.h | 5 +++--
> drivers/gpu/drm/i915/i915_vma.h | 1 +
> 5 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index bde4f64a41f7..8fcf14372d7a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -698,11 +698,13 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
> */
> void i915_ggtt_driver_release(struct drm_i915_private *i915)
> {
> + struct i915_ggtt *ggtt = &i915->ggtt;
> struct pagevec *pvec;
>
> - fini_aliasing_ppgtt(&i915->ggtt);
> + fini_aliasing_ppgtt(ggtt);
>
> - ggtt_cleanup_hw(&i915->ggtt);
> + intel_ggtt_fini_fences(ggtt);
> + ggtt_cleanup_hw(ggtt);
>
> pvec = &i915->mm.wc_stash.pvec;
> if (pvec->nr) {
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> index 94af75673a58..b6ba68c42546 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> @@ -857,6 +857,11 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
> if (intel_vgpu_active(i915))
> num_fences = intel_uncore_read(uncore,
> vgtif_reg(avail_rs.fence_num));
> + ggtt->fence_regs = kcalloc(num_fences,
> +sizeof(*ggtt->fence_regs),
> +GFP_KERNEL);
> + if (!ggtt->fence_regs)
> + num_fences = 0;
So unlikely and easily shown in other debug flow that does
not warrant an err?
-Mika
>
> /* Initialize fence registers to zero */
> for (i = 0; i < num_fences; i++) {
> @@ -871,6 +876,11 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
> intel_ggtt_restore_fences(ggtt);
> }
>
> +void intel_ggtt_fini_fences(struct i915_ggtt *ggtt)
> +{
> + kfree(ggtt->fence_regs);
> +}
> +
> void intel_gt_init_swizzling(struct intel_gt *gt)
> {
> struct drm_i915_private *i915 = gt->i915;
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
> b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
> index 3b3eb5bf1b75..9850f6a85d2a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
> @@ -64,6 +64,7 @@ void i915_gem_object_save_bit_17_swizzle(struct
> drm_i915_gem_object *obj,
>struct sg_table *pages);
>
> void intel_ggtt_init_fences(struct i915_ggtt *ggtt);
> +void intel_ggtt_fini_fences(struct i915_ggtt *ggtt);
>
> void intel_gt_init_swizzling(struct intel_gt *gt);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
> b/drivers/gpu/drm/i915/gt/intel_gtt.h
> index ce6ff9d3a350..d93ebdf3fa0e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> @@ -26,7 +26,6 @@
> #include
>
> #include "gt/intel_reset.h"
> -#include "gt/intel_ggtt_fencing.h"
> #include "i915_selftest.h"
> #include "i915_vma_types.h"
>
> @@ -135,6 +134,8 @@ typedef u64 gen8_pte_t;
> #define GEN8_PDE_IPS_64K BIT(11)
> #define GEN8_PDE_PS_2M BIT(7)
>
> +struct i915_fence_reg;
> +
> #define for_each_sgt_daddr(__dp, __iter, __sgt) \
> __for_each_sgt_daddr(__dp, __iter, __sgt, I915_GTT_PAGE_SIZE)
>
> @@ -333,7 +334,7 @@ struct i915_ggtt {
> u32 pin_bias;
>
> unsigned int num_fences;
> - struct i915_fence_reg fence_regs[I915_MAX_NUM_FENCES];
> + struct i915_fence_reg *fence_regs;
> struct list_head fence_list;
>
> /**
> diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
> index 2764c277326f..b958ad07f212 100644
> --- a/drivers/gpu/drm/i915/i915_vma.h
> +++ b/drivers/gpu/drm/i915/i915_vma.h
> @@ -30,6 +30,7 @@
>
> #include
>
> +#include "gt/intel_ggtt_fencing.h"
> #include "gem/i915_gem_object.h"
>
> #include "i915_gem_gtt.h"
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_exec_gttfill: MMAP_OFFSET related refresh
On Thu, 2020-03-05 at 18:53 +0100, Janusz Krzysztofik wrote:
> The test already tried to use a working mapping by first trying legacy
> WC, then GTT. Use gem_mmap__device_coherent() helper instead of
> approaching its implementation locally.
>
> Signed-off-by: Janusz Krzysztofik
Please ignore this submission, an equivalent implementation has been
just merged.
Thanks,
Janusz
> ---
> tests/i915/gem_exec_gttfill.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
> diff --git a/tests/i915/gem_exec_gttfill.c b/tests/i915/gem_exec_gttfill.c
> index f810dafd1..27277df48 100644
> --- a/tests/i915/gem_exec_gttfill.c
> +++ b/tests/i915/gem_exec_gttfill.c
> @@ -155,15 +155,10 @@ static void fillgtt(int fd, unsigned ring, int timeout)
> igt_assert(batches);
> for (unsigned i = 0; i < count; i++) {
> batches[i].handle = gem_create(fd, BATCH_SIZE);
> - batches[i].ptr =
> - __gem_mmap__wc(fd, batches[i].handle,
> -0, BATCH_SIZE, PROT_WRITE);
> - if (!batches[i].ptr) {
> - batches[i].ptr =
> - __gem_mmap__gtt(fd, batches[i].handle,
> - BATCH_SIZE, PROT_WRITE);
> - }
> - igt_require(batches[i].ptr);
> + batches[i].ptr = gem_mmap__device_coherent(fd,
> +batches[i].handle, 0,
> +BATCH_SIZE,
> +PROT_WRITE);
> }
>
> /* Flush all memory before we start the timer */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC][PATCH 1/5] drm: Introduce scaling filter property
On Tue, Mar 10, 2020 at 06:01:06PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 12:35:41PM +0530, Pankaj Bharadiya wrote:
> > Introduce new scaling filter property to allow userspace to select
> > the driver's default scaling filter or Nearest-neighbor(NN) filter
> > for upscaling operations on crtc/plane.
> >
> > Drivers can set up this property for a plane by calling
> > drm_plane_enable_scaling_filter() and for a CRTC by calling
> > drm_crtc_enable_scaling_filter().
> >
> > NN filter works by filling in the missing color values in the upscaled
> > image with that of the coordinate-mapped nearest source pixel value.
> >
> > NN filter for integer multiple scaling can be particularly useful for
> > for pixel art games that rely on sharp, blocky images to deliver their
> > distinctive look.
> >
> > Signed-off-by: Pankaj Bharadiya
> > Signed-off-by: Shashank Sharma
> > Signed-off-by: Ankit Nautiyal
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 8 +++
> > drivers/gpu/drm/drm_crtc.c| 16 ++
> > drivers/gpu/drm/drm_mode_config.c | 13
> > drivers/gpu/drm/drm_plane.c | 35 +++
> > include/drm/drm_crtc.h| 10 +
> > include/drm/drm_mode_config.h | 6 ++
> > include/drm/drm_plane.h | 14 +
> > 7 files changed, 102 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index a1e5e262bae2..4e3c1f3176e4 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> > *crtc,
> > return ret;
> > } else if (property == config->prop_vrr_enabled) {
> > state->vrr_enabled = val;
> > + } else if (property == config->scaling_filter_property) {
> > + state->scaling_filter = val;
>
> I think we want a per-plane/per-crtc prop for this. If we start adding
> more filters we are surely going to need different sets for different hw
> blocks.
In the past we've only done that once we have a demonstrated need. Usually
the patch to move the property to a per-object location isn't a lot of
churn.
-Daniel
>
> > } else if (property == config->degamma_lut_property) {
> > ret = drm_atomic_replace_property_blob_from_id(dev,
> > &state->degamma_lut,
> > @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> > *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> > else if (property == config->prop_out_fence_ptr)
> > *val = 0;
> > + else if (property == config->scaling_filter_property)
> > + *val = state->scaling_filter;
> > else if (crtc->funcs->atomic_get_property)
> > return crtc->funcs->atomic_get_property(crtc, state, property,
> > val);
> > else
> > @@ -583,6 +587,8 @@ static int drm_atomic_plane_set_property(struct
> > drm_plane *plane,
> > sizeof(struct drm_rect),
> > &replaced);
> > return ret;
> > + } else if (property == config->scaling_filter_property) {
> > + state->scaling_filter = val;
> > } else if (plane->funcs->atomic_set_property) {
> > return plane->funcs->atomic_set_property(plane, state,
> > property, val);
> > @@ -641,6 +647,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
> > } else if (property == config->prop_fb_damage_clips) {
> > *val = (state->fb_damage_clips) ?
> > state->fb_damage_clips->base.id : 0;
> > + } else if (property == config->scaling_filter_property) {
> > + *val = state->scaling_filter;
> > } else if (plane->funcs->atomic_get_property) {
> > return plane->funcs->atomic_get_property(plane, state,
> > property, val);
> > } else {
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 4936e1080e41..1ce7b2ac9eb5 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -748,3 +748,19 @@ int drm_mode_crtc_set_obj_prop(struct drm_mode_object
> > *obj,
> >
> > return ret;
> > }
> > +
> > +/**
> > + * drm_crtc_enable_scaling_filter - Enables crtc scaling filter property.
> > + * @crtc: CRTC on which to enable scaling filter property.
> > + *
> > + * This function lets driver to enable the scaling filter property on a
> > crtc.
> > + */
> > +void drm_crtc_enable_scaling_filter(struct drm_crtc *crtc)
> > +{
> > + struct drm_device *dev = crtc->dev;
> > +
> > + drm_object_attach_property(&crtc->base,
> > + dev->mode_config.scaling_filter_property,
> > + 0);
> > +}
> > +EXPORT_SYMBOL(drm_crtc_enable_scaling_filter);
> > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > b/drivers
[Intel-gfx] [RESUBMIT PATCH 2/2] tests/gem_userptr_blits: Refresh other now MMAP_GTT dependent subtests
Extend initial check for support of MMAP_GTT mapping to userptr with
equivalent checks for each MMAP_OFFSET mapping type supported by i915
driver. Based on that, extend coverage of process-exit-gtt* subtests
over non-GTT mapping types. In case of dmabuf-* subtests, use first
supported mapping type if there are any.
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_userptr_blits.c | 108 -
1 file changed, 79 insertions(+), 29 deletions(-)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index 975cd9dab..475200930 100644
--- a/tests/i915/gem_userptr_blits.c
+++ b/tests/i915/gem_userptr_blits.c
@@ -73,18 +73,30 @@
static uint32_t userptr_flags = LOCAL_I915_USERPTR_UNSYNCHRONIZED;
-static bool can_gtt_mmap;
+static bool *can_mmap;
#define WIDTH 512
#define HEIGHT 512
static uint32_t linear[WIDTH*HEIGHT];
-static bool has_gtt_mmap(int i915)
+static bool has_mmap(int i915, const struct mmap_offset *t)
{
void *ptr, *map = NULL;
uint32_t handle;
+ handle = gem_create(i915, PAGE_SIZE);
+ map = __gem_mmap_offset(i915, handle, 0, PAGE_SIZE, PROT_WRITE,
+ t->type);
+ gem_close(i915, handle);
+ if (map) {
+ munmap(map, PAGE_SIZE);
+ } else {
+ igt_debug("no HW / kernel support for mmap-offset(%s)\n",
+ t->name);
+ return false;
+ }
+
igt_assert(posix_memalign(&ptr, PAGE_SIZE, PAGE_SIZE) == 0);
if (__gem_userptr(i915, ptr, 4096, 0,
@@ -92,9 +104,12 @@ static bool has_gtt_mmap(int i915)
goto out_ptr;
igt_assert(handle != 0);
- map = __gem_mmap__gtt(i915, handle, 4096, PROT_WRITE);
+ map = __gem_mmap_offset(i915, handle, 0, 4096, PROT_WRITE, t->type);
if (map)
munmap(map, 4096);
+ else if (errno == ENODEV)
+ igt_debug("mmap-offset(%s) banned, lockdep loop prevention\n",
+ t->name);
gem_close(i915, handle);
out_ptr:
@@ -642,20 +657,25 @@ static int test_invalid_mapping(int fd, const struct
mmap_offset *t)
return 0;
}
-#define PE_GTT_MAP 0x1
-#define PE_BUSY 0x2
-static void test_process_exit(int fd, int flags)
+#define PE_BUSY 0x1
+static void test_process_exit(int fd, const struct mmap_offset *mmo, int flags)
{
- if (flags & PE_GTT_MAP)
- igt_require(can_gtt_mmap);
+ if (mmo)
+ igt_require_f(can_mmap[mmo->type],
+ "HW & kernel support for LLC and mmap-offset(%s)
over userptr\n",
+ mmo->name);
igt_fork(child, 1) {
uint32_t handle;
handle = create_userptr_bo(fd, sizeof(linear));
- if (flags & PE_GTT_MAP) {
- uint32_t *ptr = __gem_mmap__gtt(fd, handle,
sizeof(linear), PROT_READ | PROT_WRITE);
+ if (mmo) {
+ uint32_t *ptr;
+
+ ptr = __gem_mmap_offset(fd, handle, 0, sizeof(linear),
+ PROT_READ | PROT_WRITE,
+ mmo->type);
if (ptr)
*ptr = 0;
}
@@ -933,13 +953,14 @@ static void (* volatile orig_sigbus)(int sig, siginfo_t
*info, void *param);
static volatile unsigned long sigbus_start;
static volatile long sigbus_cnt = -1;
-static void *umap(int fd, uint32_t handle)
+static void *umap(int fd, uint32_t handle, const struct mmap_offset *mmo)
{
void *ptr;
- if (can_gtt_mmap) {
- ptr = gem_mmap__gtt(fd, handle, sizeof(linear),
- PROT_READ | PROT_WRITE);
+ if (mmo) {
+ ptr = __gem_mmap_offset(fd, handle, 0, sizeof(linear),
+ PROT_READ | PROT_WRITE, mmo->type);
+ igt_assert(ptr);
} else {
uint32_t tmp = gem_create(fd, sizeof(linear));
igt_assert_eq(copy(fd, tmp, handle), 0);
@@ -951,16 +972,17 @@ static void *umap(int fd, uint32_t handle)
}
static void
-check_bo(int fd1, uint32_t handle1, int is_userptr, int fd2, uint32_t handle2)
+check_bo(int fd1, uint32_t handle1, int is_userptr, int fd2, uint32_t handle2,
+const struct mmap_offset *mmo)
{
unsigned char *ptr1, *ptr2;
unsigned long size = sizeof(linear);
- ptr2 = umap(fd2, handle2);
+ ptr2 = umap(fd2, handle2, mmo);
if (is_userptr)
ptr1 = is_userptr > 0 ? get_handle_ptr(handle1) : ptr2;
else
- ptr1 = umap(fd1, handle1);
+ ptr1 = umap(fd1, handle1, mmo);
igt_assert(ptr1);
igt_assert(ptr2);
@@ -968,7 +990,7 @@ check_bo(int fd1, uint32_t handle1, int is_userptr, int
fd2, uint32_t handle2)
sigbus_start = (unsigned
Re: [Intel-gfx] [PATCH 03/51] drm: add managed resources tied to drm_device
On Wed, Mar 11, 2020 at 10:07:13AM +0100, Thomas Zimmermann wrote: > Hi Daniel > > Am 02.03.20 um 23:25 schrieb Daniel Vetter: > > We have lots of these. And the cleanup code tends to be of dubious > > quality. The biggest wrong pattern is that developers use devm_, which > > ties the release action to the underlying struct device, whereas > > all the userspace visible stuff attached to a drm_device can long > > outlive that one (e.g. after a hotunplug while userspace has open > > files and mmap'ed buffers). Give people what they want, but with more > > correctness. > > > > Mostly copied from devres.c, with types adjusted to fit drm_device and > > a few simplifications - I didn't (yet) copy over everything. Since > > the types don't match code sharing looked like a hopeless endeavour. > > > > For now it's only super simplified, no groups, you can't remove > > actions (but kfree exists, we'll need that soon). Plus all specific to > > drm_device ofc, including the logging. Which I didn't bother to make > > compile-time optional, since none of the other drm logging is compile > > time optional either. > > > > One tricky bit here is the chicken&egg between allocating your > > drm_device structure and initiliazing it with drm_dev_init. For > > perfect onion unwinding we'd need to have the action to kfree the > > allocation registered before drm_dev_init registers any of its own > > release handlers. But drm_dev_init doesn't know where exactly the > > drm_device is emebedded into the overall structure, and by the time it > > returns it'll all be too late. And forcing drivers to be able clean up > > everything except the one kzalloc is silly. > > > > Work around this by having a very special final_kfree pointer. This > > also avoids troubles with the list head possibly disappearing from > > underneath us when we release all resources attached to the > > drm_device. > > > > v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless > > shuffling while getting everything into shape. > > > > v3: Add static to add/del_dr (Neil) > > Move typo fix to the right patch (Neil) > > > > v4: Enforce contract for drmm_add_final_kfree: > > > > Use ksize() to check that the drm_device is indeed contained somewhere > > in the final kfree(). Because we need that or the entire managed > > release logic blows up in a pile of use-after-frees. Motivated by a > > discussion with Laurent. > > > > v5: Review from Laurent: > > - %zu instead of casting size_t > > - header guards > > - sorting of includes > > - guarding of data assignment if we didn't allocate it for a NULL > > pointer > > - delete spurious newline > > - cast void* data parameter correctly in ->release call, no idea how > > this even worked before > > > > v3: Review from Sam > > - Add the kerneldoc for the managed sub-struct back in, even if it > > doesn't show up in the generated html somehow. > > - Explain why __always_inline. > > - Fix bisectability around the final kfree() in drm_dev_relase(). This > > is just interim code which will disappear again. > > - Some whitespace polish. > > - Add debug output when drmm_add_action or drmm_kmalloc fail. > > > > Cc: Sam Ravnborg > > Cc: Laurent Pinchart > > Cc: Neil Armstrong > Cc: Greg Kroah-Hartman > > Cc: "Rafael J. Wysocki" > > Signed-off-by: Daniel Vetter > > --- > > Documentation/gpu/drm-internals.rst | 6 + > > drivers/gpu/drm/Makefile| 3 +- > > drivers/gpu/drm/drm_drv.c | 12 ++ > > drivers/gpu/drm/drm_internal.h | 3 + > > drivers/gpu/drm/drm_managed.c | 186 > > include/drm/drm_device.h| 15 +++ > > include/drm/drm_managed.h | 30 + > > include/drm/drm_print.h | 6 + > > 8 files changed, 260 insertions(+), 1 deletion(-) > > create mode 100644 drivers/gpu/drm/drm_managed.c > > create mode 100644 include/drm/drm_managed.h > > > > diff --git a/Documentation/gpu/drm-internals.rst > > b/Documentation/gpu/drm-internals.rst > > index a73320576ca9..a6b6145fda78 100644 > > --- a/Documentation/gpu/drm-internals.rst > > +++ b/Documentation/gpu/drm-internals.rst > > @@ -132,6 +132,12 @@ be unmapped; on many devices, the ROM address decoder > > is shared with > > other BARs, so leaving it mapped could cause undesired behaviour like > > hangs or memory corruption. > > > > +Managed Resources > > +- > > + > > +.. kernel-doc:: drivers/gpu/drm/drm_managed.c > > + :doc: managed resources > > + > > Bus-specific Device Registration and PCI Support > > > > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > > index 7f72ef5e7811..183c60048307 100644 > > --- a/drivers/gpu/drm/Makefile > > +++ b/drivers/gpu/drm/Makefile > > @@ -17,7 +17,8 @@ drm-y :=drm_auth.o drm_cache.o \ > > drm_plane.o drm_color_mgmt.o drm_print.o \ > > drm_dumb_buffers.o drm_mode_config.o drm_v
[Intel-gfx] [RESUBMIT PATCH 0/2] tests/gem_userptr_blits: Refresh other now MMAP_GTT dependent subtests
Together with recently submitted patches, this series concludes MMAP_OFFSET related changes required for gem_userptr_blits. Thanks, Janusz Janusz Krzysztofik (2): tests/gem_userptr_blits: Refresh readonly-mmap-unsync exercise tests/gem_userptr_blits: Refresh other now MMAP_GTT dependent subtests tests/i915/gem_userptr_blits.c | 129 - 1 file changed, 95 insertions(+), 34 deletions(-) -- 2.21.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RESUBMIT PATCH 1/2] tests/gem_userptr_blits: Refresh readonly-mmap-unsync exercise
Upgrade the subtest to use MMAP_GTT API v4 (aka MMAP_OFFSET),
dynamically examine each mapping type supported by i915 driver.
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_userptr_blits.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index beced298a..975cd9dab 100644
--- a/tests/i915/gem_userptr_blits.c
+++ b/tests/i915/gem_userptr_blits.c
@@ -1277,7 +1277,7 @@ static void sigjmp_handler(int sig)
siglongjmp(sigjmp, sig);
}
-static void test_readonly_mmap(int i915)
+static void test_readonly_mmap(int i915, const struct mmap_offset *t)
{
char *original, *result;
uint32_t handle;
@@ -1294,6 +1294,14 @@ static void test_readonly_mmap(int i915)
* on the GPU as well.
*/
+ handle = gem_create(i915, PAGE_SIZE);
+ ptr = __gem_mmap_offset(i915, handle, 0, PAGE_SIZE,
+ PROT_READ | PROT_WRITE, t->type);
+ gem_close(i915, handle);
+ igt_require_f(ptr, "HW & kernel support for mmap-offset(%s)\n",
+ t->name);
+ munmap(ptr, PAGE_SIZE);
+
igt_require(igt_setup_clflush());
sz = 16 << 12;
@@ -1307,11 +1315,11 @@ static void test_readonly_mmap(int i915)
igt_clflush_range(pages, sz);
original = g_compute_checksum_for_data(G_CHECKSUM_SHA1, pages, sz);
- ptr = __gem_mmap__gtt(i915, handle, sz, PROT_WRITE);
+ ptr = __gem_mmap_offset(i915, handle, 0, sz, PROT_WRITE, t->type);
igt_assert(ptr == NULL);
/* Optional kernel support for GTT mmaps of userptr */
- ptr = __gem_mmap__gtt(i915, handle, sz, PROT_READ);
+ ptr = __gem_mmap_offset(i915, handle, 0, sz, PROT_READ, t->type);
gem_close(i915, handle);
if (ptr) { /* Check that a write into the GTT readonly map fails */
@@ -2110,8 +2118,11 @@ igt_main_args("c:", NULL, help_str, opt_handler, NULL)
igt_subtest("readonly-unsync")
test_readonly(fd);
- igt_subtest("readonly-mmap-unsync")
- test_readonly_mmap(fd);
+ igt_describe("Examine mmap-offset mapping to read-only
userptr");
+ igt_subtest_with_dynamic("readonly-mmap-unsync")
+ for_each_mmap_offset_type(fd, t)
+ igt_dynamic(t->name)
+ test_readonly_mmap(fd, t);
igt_subtest("readonly-pwrite-unsync")
test_readonly_pwrite(fd);
--
2.21.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/51] drm: add managed resources tied to drm_device
On Wed, Mar 11, 2020 at 10:14:03AM +0100, Thomas Zimmermann wrote:
>
>
> Am 02.03.20 um 23:25 schrieb Daniel Vetter:
> <...>
> > +
> > +int __drmm_add_action(struct drm_device *dev,
> > + drmres_release_t action,
> > + void *data, const char *name)
> > +{
> > + struct drmres *dr;
> > + void **void_ptr;
> > +
> > + dr = alloc_dr(action, data ? sizeof(void*) : 0,
> > + GFP_KERNEL | __GFP_ZERO,
> > + dev_to_node(dev->dev));
> > + if (!dr) {
> > + drm_dbg_drmres(dev, "failed to add action %s for %p\n",
> > + name, data);
> > + return -ENOMEM;
> > + }
> > +
> > + dr->node.name = name;
>
> Maybe do a kstrdup_const() on name and later a kfree_const() during
> release. Just in case someone decides to allocate 'name' dynamically.
Makes sense, but a bit of churn since I need a free_dr() helper now :-)
-Daniel
>
> > + if (data) {
> > + void_ptr = (void **)&dr->data;
> > + *void_ptr = data;
> > + }
> > +
> > + add_dr(dev, dr);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(__drmm_add_action);
> > +
> > +void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp)
> > +{
> > + struct drmres *dr;
> > +
> > + dr = alloc_dr(NULL, size, gfp, dev_to_node(dev->dev));
> > + if (!dr) {
> > + drm_dbg_drmres(dev, "failed to allocate %zu bytes, %u flags\n",
> > + size, gfp);
> > + return NULL;
> > + }
> > + dr->node.name = "kmalloc";
> > +
> > + add_dr(dev, dr);
> > +
> > + return dr->data;
> > +}
> > +EXPORT_SYMBOL(drmm_kmalloc);
> > +
> > +void drmm_kfree(struct drm_device *dev, void *data)
> > +{
> > + struct drmres *dr_match = NULL, *dr;
> > + unsigned long flags;
> > +
> > + if (!data)
> > + return;
> > +
> > + spin_lock_irqsave(&dev->managed.lock, flags);
> > + list_for_each_entry(dr, &dev->managed.resources, node.entry) {
> > + if (dr->data == data) {
> > + dr_match = dr;
> > + del_dr(dev, dr_match);
> > + break;
> > + }
> > + }
> > + spin_unlock_irqrestore(&dev->managed.lock, flags);
> > +
> > + if (WARN_ON(!dr_match))
> > + return;
> > +
> > + kfree(dr_match);
> > +}
> > +EXPORT_SYMBOL(drmm_kfree);
> > diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> > index bb60a949f416..d39132b477dd 100644
> > --- a/include/drm/drm_device.h
> > +++ b/include/drm/drm_device.h
> > @@ -67,6 +67,21 @@ struct drm_device {
> > /** @dev: Device structure of bus-device */
> > struct device *dev;
> >
> > + /**
> > +* @managed:
> > +*
> > +* Managed resources linked to the lifetime of this &drm_device as
> > +* tracked by @ref.
> > +*/
> > + struct {
> > + /** @managed.resources: managed resources list */
> > + struct list_head resources;
> > + /** @managed.final_kfree: pointer for final kfree() call */
> > + void *final_kfree;
> > + /** @managed.lock: protects @managed.resources */
> > + spinlock_t lock;
> > + } managed;
> > +
> > /** @driver: DRM driver managing the device */
> > struct drm_driver *driver;
> >
> > diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
> > new file mode 100644
> > index ..7b5df7d09b19
> > --- /dev/null
> > +++ b/include/drm/drm_managed.h
> > @@ -0,0 +1,30 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#ifndef _DRM_MANAGED_H_
> > +#define _DRM_MANAGED_H_
> > +
> > +#include
> > +#include
> > +
> > +struct drm_device;
> > +
> > +typedef void (*drmres_release_t)(struct drm_device *dev, void *res);
> > +
> > +#define drmm_add_action(dev, action, data) \
> > + __drmm_add_action(dev, action, data, #action)
> > +
> > +int __must_check __drmm_add_action(struct drm_device *dev,
> > + drmres_release_t action,
> > + void *data, const char *name);
> > +
> > +void drmm_add_final_kfree(struct drm_device *dev, void *parent);
> > +
> > +void *drmm_kmalloc(struct drm_device *dev, size_t size, gfp_t gfp)
> > __malloc;
> > +static inline void *drmm_kzalloc(struct drm_device *dev, size_t size,
> > gfp_t gfp)
> > +{
> > + return drmm_kmalloc(dev, size, gfp | __GFP_ZERO);
> > +}
> > +
> > +void drmm_kfree(struct drm_device *dev, void *data);
> > +
> > +#endif
> > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> > index ca7cee8e728a..1c9417430d08 100644
> > --- a/include/drm/drm_print.h
> > +++ b/include/drm/drm_print.h
> > @@ -313,6 +313,10 @@ enum drm_debug_category {
> > * @DRM_UT_DP: Used in the DP code.
> > */
> > DRM_UT_DP = 0x100,
> > + /**
> > +* @DRM_UT_DRMRES: Used in the drm managed resources code.
> > +*/
> > + DRM_UT_DRMRES = 0x200,
> > };
> >
> > static inline bool drm_debug_enabled(enum drm_debug_category
Re: [Intel-gfx] [PATCH 21/51] drm: Use drmm_ for drm_dev_init cleanup
On Wed, Mar 11, 2020 at 10:39:13AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 02.03.20 um 23:26 schrieb Daniel Vetter:
> > Well for the simple stuff at least, vblank, gem and minor cleanup I
> > want to further split up as a demonstration.
> >
> > v2: We need to clear drm_device->dev otherwise the debug drm printing
> > after our cleanup hook (e.g. in drm_manged_release) will chase
> > released memory and result in a use-after-free. Not really pretty, but
> > oh well.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_drv.c | 48 ---
> > 1 file changed, 25 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index ef79c03e311c..23e5b0e7e041 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -580,6 +580,23 @@ static void drm_fs_inode_free(struct inode *inode)
> > *used.
> > */
> >
> > +static void drm_dev_init_release(struct drm_device *dev, void *res)
> > +{
> > + drm_legacy_ctxbitmap_cleanup(dev);
> > + drm_legacy_remove_map_hash(dev);
> > + drm_fs_inode_free(dev->anon_inode);
> > +
> > + put_device(dev->dev);
> > + /* Prevent use-after-free in drm_managed_release when debugging is
> > +* enabled. Slightly awkward, but can't really be helped. */
> > + dev->dev = NULL;
> > + mutex_destroy(&dev->master_mutex);
> > + mutex_destroy(&dev->clientlist_mutex);
> > + mutex_destroy(&dev->filelist_mutex);
> > + mutex_destroy(&dev->struct_mutex);
> > + drm_legacy_destroy_members(dev);
> > +}
> > +
> > /**
> > * drm_dev_init - Initialise new DRM device
> > * @dev: DRM device
> > @@ -647,11 +664,15 @@ int drm_dev_init(struct drm_device *dev,
> > mutex_init(&dev->clientlist_mutex);
> > mutex_init(&dev->master_mutex);
> >
> > + ret = drmm_add_action(dev, drm_dev_init_release, NULL);
> > + if (ret)
> > + return ret;
> > +
>
> Is this code supposed to stay for the long term? As devices are
> allocated dynamically, I can imagine that there will be a call that
> allocates the memory and, at the same time, sets drm_dev_init_release()
> as the release callback.
There's a chicken-egg situation here. The plan is to fix this with a
devm_drm_dev_alloc() macro, which we discussed quite a bit in earlier
versions. It's just that the patch series is already big as-is, hence this
is postponed to the next round.
> The question is also released to patch 3, where I proposed to rename
> __drm_add_action() to __drmm_kzalloc().
>
> > dev->anon_inode = drm_fs_inode_new();
> > if (IS_ERR(dev->anon_inode)) {
> > ret = PTR_ERR(dev->anon_inode);
> > DRM_ERROR("Cannot allocate anonymous inode: %d\n", ret);
> > - goto err_free;
> > + goto err;
> > }
> >
> > if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> > @@ -688,19 +709,12 @@ int drm_dev_init(struct drm_device *dev,
> > if (drm_core_check_feature(dev, DRIVER_GEM))
> > drm_gem_destroy(dev);
> > err_ctxbitmap:
> > - drm_legacy_ctxbitmap_cleanup(dev);
> > - drm_legacy_remove_map_hash(dev);
> > err_minors:
> > drm_minor_free(dev, DRM_MINOR_PRIMARY);
> > drm_minor_free(dev, DRM_MINOR_RENDER);
> > - drm_fs_inode_free(dev->anon_inode);
> > -err_free:
> > - put_device(dev->dev);
> > - mutex_destroy(&dev->master_mutex);
> > - mutex_destroy(&dev->clientlist_mutex);
> > - mutex_destroy(&dev->filelist_mutex);
> > - mutex_destroy(&dev->struct_mutex);
> > - drm_legacy_destroy_members(dev);
> > +err:
> > + drm_managed_release(dev);
> > +
>
> Here's more of a general observation than a comment on the actual patch:
>
> One odd thing about the overall interface is that there's no way of
> updating the release callback afterwards. In an OOP language, such as
> C++, an error within the constructor would rollback the performed
> actions and return without calling the destructor. Destructors only run
> for fully constructed objects.
>
> In our case, the equivalent is to run the init function and set
> drm_dev_init_release() as the final step. The init's rollback-code would
> have to stay, obviously.
See the various drivers later on in the series, the init rollback
completely disappears once we're done here. If this wouldn't Just Work for
both final destruction and init rollback there's really no point. There's
a few ugly corner-cases with getting this boot-strapped though.
-Daniel
>
> Best regards
> Thomas
>
> > return ret;
> > }
> > EXPORT_SYMBOL(drm_dev_init);
> > @@ -763,20 +777,8 @@ void drm_dev_fini(struct drm_device *dev)
> > if (drm_core_check_feature(dev, DRIVER_GEM))
> > drm_gem_destroy(dev);
> >
> > - drm_legacy_ctxbitmap_cleanup(dev);
> > - drm_legacy_remove_map_hash(dev);
> > - drm_fs_inode_free(dev->anon_inode);
> > -
> > drm_minor_free(dev, DRM_MINOR_PRIMARY);
> > drm_minor_free(dev, DRM_MINOR_RENDER);
> > -
> > - put_device(dev->
Re: [Intel-gfx] [PATCH 22/51] drm: manage drm_minor cleanup with drmm_
On Wed, Mar 11, 2020 at 10:59:10AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 02.03.20 um 23:26 schrieb Daniel Vetter:
> > The cleanup here is somewhat tricky, since we can't tell apart the
> > allocated minor index from 0. So register a cleanup action first, and
> > if the index allocation fails, unregister that cleanup action again to
> > avoid bad mistakes.
> >
> > The kdev for the minor already handles NULL, so no problem there.
> >
> > Hence add drmm_remove_action() to the drm_managed library.
> >
> > v2: Make pointer math around void ** consistent with what Laurent
> > suggested.
> >
> > Cc: Laurent Pinchart
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_drv.c | 74 +--
> > drivers/gpu/drm/drm_managed.c | 28 +
> > include/drm/drm_managed.h | 4 ++
> > 3 files changed, 59 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 23e5b0e7e041..29d106195ab3 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -93,19 +93,35 @@ static struct drm_minor **drm_minor_get_slot(struct
> > drm_device *dev,
> > }
> > }
> >
> > +static void drm_minor_alloc_release(struct drm_device *dev, void *data)
> > +{
> > + struct drm_minor *minor = data;
> > + unsigned long flags;
> > +
> > + put_device(minor->kdev);
> > +
> > + spin_lock_irqsave(&drm_minor_lock, flags);
> > + idr_remove(&drm_minors_idr, minor->index);
> > + spin_unlock_irqrestore(&drm_minor_lock, flags);
> > +}
> > +
> > static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
> > {
> > struct drm_minor *minor;
> > unsigned long flags;
> > int r;
> >
> > - minor = kzalloc(sizeof(*minor), GFP_KERNEL);
> > + minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
> > if (!minor)
> > return -ENOMEM;
> >
> > minor->type = type;
> > minor->dev = dev;
> >
> > + r = drmm_add_action(dev, drm_minor_alloc_release, minor);
> > + if (r)
> > + return r;
> > +
> > idr_preload(GFP_KERNEL);
> > spin_lock_irqsave(&drm_minor_lock, flags);
> > r = idr_alloc(&drm_minors_idr,
> > @@ -116,47 +132,18 @@ static int drm_minor_alloc(struct drm_device *dev,
> > unsigned int type)
> > spin_unlock_irqrestore(&drm_minor_lock, flags);
> > idr_preload_end();
> >
> > - if (r < 0)
> > - goto err_free;
> > + if (r < 0) {
> > + drmm_remove_action(dev, drm_minor_alloc_release, minor);
> > + return r;
> > + }
> >
> > minor->index = r;
> > -
> > minor->kdev = drm_sysfs_minor_alloc(minor);
> > - if (IS_ERR(minor->kdev)) {
> > - r = PTR_ERR(minor->kdev);
> > - goto err_index;
> > - }
> > + if (IS_ERR(minor->kdev))
> > + return PTR_ERR(minor->kdev);
> >
> > *drm_minor_get_slot(dev, type) = minor;
> > return 0;
> > -
> > -err_index:
> > - spin_lock_irqsave(&drm_minor_lock, flags);
> > - idr_remove(&drm_minors_idr, minor->index);
> > - spin_unlock_irqrestore(&drm_minor_lock, flags);
> > -err_free:
> > - kfree(minor);
> > - return r;
> > -}
>
> TBH, I think you're reducing code quality by removing the rollback code
> from init functions, just for the sake of it.
>
> Specifically in this case here, you saved a few lines of code, but the
> overall flow is way more complicated to follow. That's typically a
> reliably source of bugs. This call to drmm_remove_action() just makes it
> worse.
>
> Rather, see my remark on OOP destruction in patch 21. For now, I'd focus
> on the device cleanup and leave init functions as they are.
Ah, I can simplify this with add_action_or_reset. This removes the only
user of drmm_remove_action, which I think is actually a good thing :-)
-Daniel
>
> Best regards
> Thomas
>
> > -
> > -static void drm_minor_free(struct drm_device *dev, unsigned int type)
> > -{
> > - struct drm_minor **slot, *minor;
> > - unsigned long flags;
> > -
> > - slot = drm_minor_get_slot(dev, type);
> > - minor = *slot;
> > - if (!minor)
> > - return;
> > -
> > - put_device(minor->kdev);
> > -
> > - spin_lock_irqsave(&drm_minor_lock, flags);
> > - idr_remove(&drm_minors_idr, minor->index);
> > - spin_unlock_irqrestore(&drm_minor_lock, flags);
> > -
> > - kfree(minor);
> > - *slot = NULL;
> > }
> >
> > static int drm_minor_register(struct drm_device *dev, unsigned int type)
> > @@ -678,16 +665,16 @@ int drm_dev_init(struct drm_device *dev,
> > if (drm_core_check_feature(dev, DRIVER_RENDER)) {
> > ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
> > if (ret)
> > - goto err_minors;
> > + goto err;
> > }
> >
> > ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
> > if (ret)
> > - goto err_minors;
> > + goto err;
> >
> > ret = drm_legacy_create_map_hash(dev);
> > if (ret)
> > -
Re: [Intel-gfx] [PATCH v6 3/3] drm/i915/perf: introduce global sseu pinning
On 14/03/2020 10:33, Lionel Landwerlin wrote:
On Gen11 powergating half the execution units is a functional
requirement when using the VME samplers. Not fullfilling this
requirement can lead to hangs.
This unfortunately plays fairly poorly with the NOA requirements. NOA
requires a stable power configuration to maintain its configuration.
As a result using OA (and NOA feeding into it) so far has required us
to use a power configuration that can work for all contexts. The only
power configuration fullfilling this is powergating half the execution
units.
This makes performance analysis for 3D workloads somewhat pointless.
Failing to find a solution that would work for everybody, this change
introduces a new i915-perf stream open parameter that punts the
decision off to userspace. If this parameter is omitted, the existing
Gen11 behavior remains (half EU array powergating).
This change takes the initiative to move all perf related sseu
configuration into i915_perf.c
v2: Make parameter priviliged if different from default
v3: Fix context modifying its sseu config while i915-perf is enabled
v4: Always consider global sseu a privileged operation (Tvrtko)
Override req_sseu point in intel_sseu_make_rpcs() (Tvrtko)
Remove unrelated changes (Tvrtko)
v5: Some typos (Tvrtko)
Process sseu param in read_properties_unlocked() (Tvrtko)
v6: Actually commit the bits from v5...
Fixup some checkpath warnings
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 10 +--
drivers/gpu/drm/i915/gem/i915_gem_context.h | 4 +
drivers/gpu/drm/i915/gt/intel_sseu.c| 33 ++--
drivers/gpu/drm/i915/i915_perf.c| 83 -
drivers/gpu/drm/i915/i915_perf_types.h | 7 ++
include/uapi/drm/i915_drm.h | 11 +++
6 files changed, 115 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 026999b34abd..c0e476fcd1fa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1401,10 +1401,10 @@ static int get_ringsize(struct i915_gem_context *ctx,
return 0;
}
-static int
-user_to_context_sseu(struct drm_i915_private *i915,
-const struct drm_i915_gem_context_param_sseu *user,
-struct intel_sseu *context)
+int
+i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+ const struct drm_i915_gem_context_param_sseu
*user,
+ struct intel_sseu *context)
{
const struct sseu_dev_info *device = &RUNTIME_INFO(i915)->sseu;
@@ -1539,7 +1539,7 @@ static int set_sseu(struct i915_gem_context *ctx,
goto out_ce;
}
- ret = user_to_context_sseu(i915, &user_sseu, &sseu);
+ ret = i915_gem_user_to_context_sseu(i915, &user_sseu, &sseu);
if (ret)
goto out_ce;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 57b7ae2893e1..f37c36719b04 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -221,4 +221,8 @@ i915_gem_engines_iter_next(struct i915_gem_engines_iter
*it);
struct i915_lut_handle *i915_lut_handle_alloc(void);
void i915_lut_handle_free(struct i915_lut_handle *lut);
+int i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+ const struct drm_i915_gem_context_param_sseu
*user,
+ struct intel_sseu *context);
+
#endif /* !__I915_GEM_CONTEXT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 74f793423231..d173271c7397 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -65,7 +65,6 @@ u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
{
const struct sseu_dev_info *sseu = &RUNTIME_INFO(i915)->sseu;
bool subslice_pg = sseu->has_subslice_pg;
- struct intel_sseu ctx_sseu;
u8 slices, subslices;
u32 rpcs = 0;
@@ -78,31 +77,13 @@ u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
/*
* If i915/perf is active, we want a stable powergating configuration
-* on the system.
-*
-* We could choose full enablement, but on ICL we know there are use
-* cases which disable slices for functional, apart for performance
-* reasons. So in this case we select a known stable subset.
+* on the system. Use the configuration pinned by i915/perf.
*/
- if (!i915->perf.exclusive_stream) {
- ctx_sseu = *req_sseu;
- } else {
- ctx_sseu = intel_sseu_from_device_info(sseu);
-
- if (IS_GEN(i915, 11)) {
- /*
-
Re: [Intel-gfx] [PATCH v5 3/3] drm/i915/perf: introduce global sseu pinning
On 13/03/2020 14:34, Lionel Landwerlin wrote:
On Gen11 powergating half the execution units is a functional
requirement when using the VME samplers. Not fullfilling this
requirement can lead to hangs.
This unfortunately plays fairly poorly with the NOA requirements. NOA
requires a stable power configuration to maintain its configuration.
As a result using OA (and NOA feeding into it) so far has required us
to use a power configuration that can work for all contexts. The only
power configuration fullfilling this is powergating half the execution
units.
This makes performance analysis for 3D workloads somewhat pointless.
Failing to find a solution that would work for everybody, this change
introduces a new i915-perf stream open parameter that punts the
decision off to userspace. If this parameter is omitted, the existing
Gen11 behavior remains (half EU array powergating).
You also need to test the new prop from the IGT, right?
Regards,
Tvrtko
This change takes the initiative to move all perf related sseu
configuration into i915_perf.c
v2: Make parameter priviliged if different from default
v3: Fix context modifying its sseu config while i915-perf is enabled
v4: Always consider global sseu a privileged operation (Tvrtko)
Override req_sseu point in intel_sseu_make_rpcs() (Tvrtko)
Remove unrelated changes (Tvrtko)
v5: Some typos (Tvrtko)
Process sseu param in read_properties_unlocked() (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 10 +--
drivers/gpu/drm/i915/gem/i915_gem_context.h | 4 +
drivers/gpu/drm/i915/gt/intel_sseu.c| 33 ++--
drivers/gpu/drm/i915/i915_perf.c| 83 -
drivers/gpu/drm/i915/i915_perf_types.h | 7 ++
include/uapi/drm/i915_drm.h | 11 +++
6 files changed, 115 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 026999b34abd..c0e476fcd1fa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1401,10 +1401,10 @@ static int get_ringsize(struct i915_gem_context *ctx,
return 0;
}
-static int
-user_to_context_sseu(struct drm_i915_private *i915,
-const struct drm_i915_gem_context_param_sseu *user,
-struct intel_sseu *context)
+int
+i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+ const struct drm_i915_gem_context_param_sseu
*user,
+ struct intel_sseu *context)
{
const struct sseu_dev_info *device = &RUNTIME_INFO(i915)->sseu;
@@ -1539,7 +1539,7 @@ static int set_sseu(struct i915_gem_context *ctx,
goto out_ce;
}
- ret = user_to_context_sseu(i915, &user_sseu, &sseu);
+ ret = i915_gem_user_to_context_sseu(i915, &user_sseu, &sseu);
if (ret)
goto out_ce;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 57b7ae2893e1..f37c36719b04 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -221,4 +221,8 @@ i915_gem_engines_iter_next(struct i915_gem_engines_iter
*it);
struct i915_lut_handle *i915_lut_handle_alloc(void);
void i915_lut_handle_free(struct i915_lut_handle *lut);
+int i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+ const struct drm_i915_gem_context_param_sseu
*user,
+ struct intel_sseu *context);
+
#endif /* !__I915_GEM_CONTEXT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 74f793423231..d173271c7397 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -65,7 +65,6 @@ u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
{
const struct sseu_dev_info *sseu = &RUNTIME_INFO(i915)->sseu;
bool subslice_pg = sseu->has_subslice_pg;
- struct intel_sseu ctx_sseu;
u8 slices, subslices;
u32 rpcs = 0;
@@ -78,31 +77,13 @@ u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
/*
* If i915/perf is active, we want a stable powergating configuration
-* on the system.
-*
-* We could choose full enablement, but on ICL we know there are use
-* cases which disable slices for functional, apart for performance
-* reasons. So in this case we select a known stable subset.
+* on the system. Use the configuration pinned by i915/perf.
*/
- if (!i915->perf.exclusive_stream) {
- ctx_sseu = *req_sseu;
- } else {
- ctx_sseu = intel_sseu_from_device_info(sseu);
-
- if (IS_GEN(i915, 11)) {
- /*
-* We only need subslice count so
Re: [Intel-gfx] [PATCH v5 3/3] drm/i915/perf: introduce global sseu pinning
On 16/03/2020 11:16, Tvrtko Ursulin wrote:
On 13/03/2020 14:34, Lionel Landwerlin wrote:
On Gen11 powergating half the execution units is a functional
requirement when using the VME samplers. Not fullfilling this
requirement can lead to hangs.
This unfortunately plays fairly poorly with the NOA requirements. NOA
requires a stable power configuration to maintain its configuration.
As a result using OA (and NOA feeding into it) so far has required us
to use a power configuration that can work for all contexts. The only
power configuration fullfilling this is powergating half the execution
units.
This makes performance analysis for 3D workloads somewhat pointless.
Failing to find a solution that would work for everybody, this change
introduces a new i915-perf stream open parameter that punts the
decision off to userspace. If this parameter is omitted, the existing
Gen11 behavior remains (half EU array powergating).
You also need to test the new prop from the IGT, right?
Regards,
Tvrtko
Along the lines of what you did for the context sseu param :
https://patchwork.freedesktop.org/series/74111/
-Lionel
This change takes the initiative to move all perf related sseu
configuration into i915_perf.c
v2: Make parameter priviliged if different from default
v3: Fix context modifying its sseu config while i915-perf is enabled
v4: Always consider global sseu a privileged operation (Tvrtko)
Override req_sseu point in intel_sseu_make_rpcs() (Tvrtko)
Remove unrelated changes (Tvrtko)
v5: Some typos (Tvrtko)
Process sseu param in read_properties_unlocked() (Tvrtko)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 10 +--
drivers/gpu/drm/i915/gem/i915_gem_context.h | 4 +
drivers/gpu/drm/i915/gt/intel_sseu.c | 33 ++--
drivers/gpu/drm/i915/i915_perf.c | 83 -
drivers/gpu/drm/i915/i915_perf_types.h | 7 ++
include/uapi/drm/i915_drm.h | 11 +++
6 files changed, 115 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 026999b34abd..c0e476fcd1fa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1401,10 +1401,10 @@ static int get_ringsize(struct
i915_gem_context *ctx,
return 0;
}
-static int
-user_to_context_sseu(struct drm_i915_private *i915,
- const struct drm_i915_gem_context_param_sseu *user,
- struct intel_sseu *context)
+int
+i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+ const struct drm_i915_gem_context_param_sseu *user,
+ struct intel_sseu *context)
{
const struct sseu_dev_info *device = &RUNTIME_INFO(i915)->sseu;
@@ -1539,7 +1539,7 @@ static int set_sseu(struct i915_gem_context
*ctx,
goto out_ce;
}
- ret = user_to_context_sseu(i915, &user_sseu, &sseu);
+ ret = i915_gem_user_to_context_sseu(i915, &user_sseu, &sseu);
if (ret)
goto out_ce;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 57b7ae2893e1..f37c36719b04 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -221,4 +221,8 @@ i915_gem_engines_iter_next(struct
i915_gem_engines_iter *it);
struct i915_lut_handle *i915_lut_handle_alloc(void);
void i915_lut_handle_free(struct i915_lut_handle *lut);
+int i915_gem_user_to_context_sseu(struct drm_i915_private *i915,
+ const struct drm_i915_gem_context_param_sseu *user,
+ struct intel_sseu *context);
+
#endif /* !__I915_GEM_CONTEXT_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 74f793423231..d173271c7397 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -65,7 +65,6 @@ u32 intel_sseu_make_rpcs(struct drm_i915_private
*i915,
{
const struct sseu_dev_info *sseu = &RUNTIME_INFO(i915)->sseu;
bool subslice_pg = sseu->has_subslice_pg;
- struct intel_sseu ctx_sseu;
u8 slices, subslices;
u32 rpcs = 0;
@@ -78,31 +77,13 @@ u32 intel_sseu_make_rpcs(struct
drm_i915_private *i915,
/*
* If i915/perf is active, we want a stable powergating
configuration
- * on the system.
- *
- * We could choose full enablement, but on ICL we know there are
use
- * cases which disable slices for functional, apart for performance
- * reasons. So in this case we select a known stable subset.
+ * on the system. Use the configuration pinned by i915/perf.
*/
- if (!i915->perf.exclusive_stream) {
- ctx_sseu = *req_sseu;
- } else {
- ctx_sseu = intel_sseu_from_device_info(sseu);
-
- if (IS_GEN(i915, 11)) {
- /*
- * We only need subslice c
Re: [Intel-gfx] [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function
Am 16.03.20 um 09:56 schrieb Christoph Hellwig: On Fri, Mar 13, 2020 at 09:17:42AM -0300, Jason Gunthorpe wrote: On Fri, Mar 13, 2020 at 04:21:39AM -0700, Christoph Hellwig wrote: On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote: The non-page scatterlist is also a big concern for RDMA as we have drivers that want the page list, so even if we did as this series contemplates I'd have still have to split the drivers and create the notion of a dma-only SGL. The drivers I looked at want a list of IOVA address, aligned to the device "page size". What other data do drivers want? Execept for the software protocol stack drivers, which of couse need pages for the stack futher down. In principle it is possible to have just an aligned page list - however the page size is variable, following certain rules, and today the drivers still determine the correct page size largely on their own. Some progress was made recently to consolidate this, but more is needed. If the common code doesn't know the device page size in advance then today's approach of sending largest possible dma mapped SGLs into the device driver is best. The driver only has to do splitting. The point was that drivers don't need pages, drivers need IOVAs. In what form they are stuffed into the hardware is the drivers problem. Well I would prefer if the drivers can somehow express their requirements and get IOVA structures already in the form they need. Converting the IOVA data from one form to another is sometimes quite costly. Especially when it is only temporarily needed. Regards, Christian. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] MAINTAINERS: adjust to reservation.h renaming
On Fri, Mar 06, 2020 at 02:56:06AM -0800, Joe Perches wrote:
> On Fri, 2020-03-06 at 11:39 +0100, Daniel Vetter wrote:
> > On Wed, Mar 04, 2020 at 01:08:32PM +0100, Christian König wrote:
> > > Am 04.03.20 um 13:07 schrieb Lukas Bulwahn:
> > > > Commit 52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
> > > > renamed include/linux/reservation.h to include/linux/dma-resv.h, but
> > > > missed the reference in the MAINTAINERS entry.
> > > >
> > > > Since then, ./scripts/get_maintainer.pl --self-test complains:
> > > >
> > > >warning: no file matches F: include/linux/reservation.h
> > > >
> > > > Adjust the DMA BUFFER SHARING FRAMEWORK entry in MAINTAINERS.
> > > >
> > > > Co-developed-by: Sebastian Duda
> > > > Signed-off-by: Sebastian Duda
> > > > Signed-off-by: Lukas Bulwahn
> > >
> > > Reviewed-by: Christian König
> >
> > You'll push this too?
> > -Daniel
> >
> > > > ---
> > > > Christian, please pick this patch.
> > > > applies cleanly on current master and next-20200303
> > > >
> > > > MAINTAINERS | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index 6158a143a13e..3d6cb2789c9e 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -5022,7 +5022,7 @@ L:dri-de...@lists.freedesktop.org
> > > > L:linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
> > > > F:drivers/dma-buf/
> > > > F:include/linux/dma-buf*
> > > > -F: include/linux/reservation.h
> > > > +F: include/linux/dma-resv.h
> > > > F:include/linux/*fence.h
> > > > F:Documentation/driver-api/dma-buf.rst
> > > > K:dma_(buf|fence|resv)
>
> Slightly unrelated:
>
> The K: entry matches a lot of other things
> and may have a lot of false positive matches
> like any variable named dma_buffer
>
> This should also use (?:...) to avoid a perl
> capture group.
>
> Perhaps:
>
> K:'\bdma_(?:buf|fence|resv)\b'
Hm either people aren't using get_maintainers.pl consistently, or it
doesn't seem to be a real world problem. I'm not seeing any unrelated
patches on dri-devel at least.
But happy to merge such a patch if it shows up ofc, it's definitely the
more correct thing :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] MAINTAINERS: adjust to reservation.h renaming
On Mon, Mar 16, 2020 at 10:50:07AM +0100, Daniel Vetter wrote:
> On Fri, Mar 06, 2020 at 02:56:06AM -0800, Joe Perches wrote:
> > On Fri, 2020-03-06 at 11:39 +0100, Daniel Vetter wrote:
> > > On Wed, Mar 04, 2020 at 01:08:32PM +0100, Christian König wrote:
> > > > Am 04.03.20 um 13:07 schrieb Lukas Bulwahn:
> > > > > Commit 52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
> > > > > renamed include/linux/reservation.h to include/linux/dma-resv.h, but
> > > > > missed the reference in the MAINTAINERS entry.
> > > > >
> > > > > Since then, ./scripts/get_maintainer.pl --self-test complains:
> > > > >
> > > > >warning: no file matches F: include/linux/reservation.h
> > > > >
> > > > > Adjust the DMA BUFFER SHARING FRAMEWORK entry in MAINTAINERS.
> > > > >
> > > > > Co-developed-by: Sebastian Duda
> > > > > Signed-off-by: Sebastian Duda
> > > > > Signed-off-by: Lukas Bulwahn
> > > >
> > > > Reviewed-by: Christian König
> > >
> > > You'll push this too?
> > > -Daniel
> > >
> > > > > ---
> > > > > Christian, please pick this patch.
> > > > > applies cleanly on current master and next-20200303
> > > > >
> > > > > MAINTAINERS | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > index 6158a143a13e..3d6cb2789c9e 100644
> > > > > --- a/MAINTAINERS
> > > > > +++ b/MAINTAINERS
> > > > > @@ -5022,7 +5022,7 @@ L: dri-de...@lists.freedesktop.org
> > > > > L: linaro-mm-...@lists.linaro.org (moderated for non-subscribers)
> > > > > F: drivers/dma-buf/
> > > > > F: include/linux/dma-buf*
> > > > > -F: include/linux/reservation.h
> > > > > +F: include/linux/dma-resv.h
> > > > > F: include/linux/*fence.h
> > > > > F: Documentation/driver-api/dma-buf.rst
> > > > > K: dma_(buf|fence|resv)
> >
> > Slightly unrelated:
> >
> > The K: entry matches a lot of other things
> > and may have a lot of false positive matches
> > like any variable named dma_buffer
> >
> > This should also use (?:...) to avoid a perl
> > capture group.
> >
> > Perhaps:
> >
> > K: '\bdma_(?:buf|fence|resv)\b'
>
> Hm either people aren't using get_maintainers.pl consistently, or it
> doesn't seem to be a real world problem. I'm not seeing any unrelated
> patches on dri-devel at least.
>
> But happy to merge such a patch if it shows up ofc, it's definitely the
> more correct thing :-)
Ofc as usual if you lean out the window you immediately get to eat your
hat, right after sending this I got a mail from syzbot about some random
stuff because of this :-)
I'm gonna do the patch now ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Mark up racy check of drm_gem_object.handle_count
On Mon, Mar 09, 2020 at 12:01:51PM +, Chris Wilson wrote: > [ 1715.899800] BUG: KCSAN: data-race in drm_gem_handle_create_tail / > drm_gem_object_handle_put_unlocked > [ 1715.899838] > [ 1715.899861] write to 0x8881830f3604 of 4 bytes by task 7834 on cpu 1: > [ 1715.899896] drm_gem_handle_create_tail+0x62/0x250 > [ 1715.899927] drm_gem_open_ioctl+0xc1/0x160 > [ 1715.899956] drm_ioctl_kernel+0xe4/0x120 > [ 1715.899981] drm_ioctl+0x297/0x4c7 > [ 1715.93] ksys_ioctl+0x89/0xb0 > [ 1715.900027] __x64_sys_ioctl+0x42/0x60 > [ 1715.900052] do_syscall_64+0x6e/0x2c0 > [ 1715.900079] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 1715.900100] > [ 1715.900119] read to 0x8881830f3604 of 4 bytes by task 8137 on cpu 0: > [ 1715.900149] drm_gem_object_handle_put_unlocked+0x31/0x130 > [ 1715.900180] drm_gem_object_release_handle+0x93/0xe0 > [ 1715.900208] drm_gem_handle_delete+0x7b/0xe0 > [ 1715.900235] drm_gem_close_ioctl+0x61/0x80 > [ 1715.900264] drm_ioctl_kernel+0xe4/0x120 > [ 1715.900291] drm_ioctl+0x297/0x4c7 > [ 1715.900316] ksys_ioctl+0x89/0xb0 > [ 1715.900340] __x64_sys_ioctl+0x42/0x60 > [ 1715.900363] do_syscall_64+0x6e/0x2c0 > [ 1715.900388] entry_SYSCALL_64_after_hwframe+0x44/0xa9 I'm impressed. The dream that we all get replaced by some scripts might be real :-) > Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_gem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index a9e4a610445a..37627d06fb06 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -218,7 +218,7 @@ drm_gem_object_handle_put_unlocked(struct drm_gem_object > *obj) > struct drm_device *dev = obj->dev; > bool final = false; > > - if (WARN_ON(obj->handle_count == 0)) > + if (WARN_ON(READ_ONCE(obj->handle_count) == 0)) > return; > > /* > -- > 2.20.1 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/mm: Allow drm_mm_initialized() to be used outside of the locks
On Mon, Mar 09, 2020 at 12:15:29PM +, Chris Wilson wrote:
> Mark up the potential racy read in drm_mm_initialized(), as we want a
> cheap and cheerful check:
>
> [ 121.098731] BUG: KCSAN: data-race in _i915_gem_object_create_stolen [i915]
> / rm_hole
> [ 121.098766]
> [ 121.098789] write (marked) to 0x8881f01ed330 of 8 bytes by task 3568
> on cpu 3:
> [ 121.098831] rm_hole+0x64/0x140
> [ 121.098860] drm_mm_insert_node_in_range+0x3d3/0x6c0
> [ 121.099254] i915_gem_stolen_insert_node_in_range+0x91/0xe0 [i915]
> [ 121.099646] _i915_gem_object_create_stolen+0x9d/0x100 [i915]
> [ 121.100047] i915_gem_object_create_region+0x7a/0xa0 [i915]
> [ 121.100451] i915_gem_object_create_stolen+0x33/0x50 [i915]
> [ 121.100849] intel_engine_create_ring+0x1af/0x280 [i915]
> [ 121.101242] __execlists_context_alloc+0xce/0x3d0 [i915]
> [ 121.101635] execlists_context_alloc+0x25/0x40 [i915]
> [ 121.102030] intel_context_alloc_state+0xb6/0xf0 [i915]
> [ 121.102420] __intel_context_do_pin+0x1ff/0x220 [i915]
> [ 121.102815] i915_gem_do_execbuffer+0x46b4/0x4c20 [i915]
> [ 121.103211] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
> [ 121.103244] drm_ioctl_kernel+0xe4/0x120
> [ 121.103269] drm_ioctl+0x297/0x4c7
> [ 121.103296] ksys_ioctl+0x89/0xb0
> [ 121.103321] __x64_sys_ioctl+0x42/0x60
> [ 121.103349] do_syscall_64+0x6e/0x2c0
> [ 121.103377] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 121.103403]
> [ 121.103426] read to 0x8881f01ed330 of 8 bytes by task 3109 on cpu 1:
> [ 121.103819] _i915_gem_object_create_stolen+0x30/0x100 [i915]
> [ 121.104228] i915_gem_object_create_region+0x7a/0xa0 [i915]
> [ 121.104631] i915_gem_object_create_stolen+0x33/0x50 [i915]
> [ 121.105025] intel_engine_create_ring+0x1af/0x280 [i915]
> [ 121.105420] __execlists_context_alloc+0xce/0x3d0 [i915]
> [ 121.105818] execlists_context_alloc+0x25/0x40 [i915]
> [ 121.106202] intel_context_alloc_state+0xb6/0xf0 [i915]
> [ 121.106595] __intel_context_do_pin+0x1ff/0x220 [i915]
> [ 121.106985] i915_gem_do_execbuffer+0x46b4/0x4c20 [i915]
> [ 121.107375] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915]
> [ 121.107409] drm_ioctl_kernel+0xe4/0x120
> [ 121.107437] drm_ioctl+0x297/0x4c7
> [ 121.107464] ksys_ioctl+0x89/0xb0
> [ 121.107489] __x64_sys_ioctl+0x42/0x60
> [ 121.107511] do_syscall_64+0x6e/0x2c0
> [ 121.107535] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Signed-off-by: Chris Wilson
A bit on the fence on this, but also kinda the only option.
Reviewed-by: Daniel Vetter
> ---
> include/drm/drm_mm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
> index d7939c054259..ee8b0e80ca90 100644
> --- a/include/drm/drm_mm.h
> +++ b/include/drm/drm_mm.h
> @@ -272,7 +272,7 @@ static inline bool drm_mm_node_allocated(const struct
> drm_mm_node *node)
> */
> static inline bool drm_mm_initialized(const struct drm_mm *mm)
> {
> - return mm->hole_stack.next;
> + return READ_ONCE(mm->hole_stack.next);
> }
>
> /**
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/gt: Allocate i915_fence_reg array
Quoting Mika Kuoppala (2020-03-16 07:29:36)
> Chris Wilson writes:
>
> > Since the number of fence regs can vary dramactically between platforms,
> > allocate the array on demand so we don't waste as much space.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_ggtt.c | 6 --
> > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 10 ++
> > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 1 +
> > drivers/gpu/drm/i915/gt/intel_gtt.h | 5 +++--
> > drivers/gpu/drm/i915/i915_vma.h | 1 +
> > 5 files changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > index bde4f64a41f7..8fcf14372d7a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> > @@ -698,11 +698,13 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
> > */
> > void i915_ggtt_driver_release(struct drm_i915_private *i915)
> > {
> > + struct i915_ggtt *ggtt = &i915->ggtt;
> > struct pagevec *pvec;
> >
> > - fini_aliasing_ppgtt(&i915->ggtt);
> > + fini_aliasing_ppgtt(ggtt);
> >
> > - ggtt_cleanup_hw(&i915->ggtt);
> > + intel_ggtt_fini_fences(ggtt);
> > + ggtt_cleanup_hw(ggtt);
> >
> > pvec = &i915->mm.wc_stash.pvec;
> > if (pvec->nr) {
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > index 94af75673a58..b6ba68c42546 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> > @@ -857,6 +857,11 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
> > if (intel_vgpu_active(i915))
> > num_fences = intel_uncore_read(uncore,
> > vgtif_reg(avail_rs.fence_num));
> > + ggtt->fence_regs = kcalloc(num_fences,
> > +sizeof(*ggtt->fence_regs),
> > +GFP_KERNEL);
> > + if (!ggtt->fence_regs)
> > + num_fences = 0;
>
> So unlikely and easily shown in other debug flow that does
> not warrant an err?
Yeah, we get a warn already and it /should/ not be fatal. We should be
able to bring the display up.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/7] drm/dp: get/set phy compliance pattern
During phy compliance auto test mode source need to read
requested test pattern from sink through DPCD. After processing
the request source need to set the pattern. So set/get method
added in drm layer as it is DP protocol.
v2: As per review feedback from Manasi on RFC version,
- added dp revision as function argument in set_phy_pattern api.
- used int for link_rate and u8 for lane_count to align with existing code.
v3: As per review feedback from Harry,
- used sizeof() instead of magic number.
- corrected kernel-doc for drm_dp_phy_test_params structure.
Reviewed-by: Harry Wentland
Reviewed-by: Manasi Navare
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/drm_dp_helper.c | 94 +
include/drm/drm_dp_helper.h | 31 +++
2 files changed, 125 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index c6fbe6e6bc9d..28e59d1ffa93 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1533,3 +1533,97 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_S
return num_bpc;
}
EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
+
+/**
+ * drm_dp_get_phy_test_pattern() - get the requested pattern from the sink.
+ * @aux: DisplayPort AUX channel
+ * @data: DP phy compliance test parameters.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
+ struct drm_dp_phy_test_params *data)
+{
+ int err;
+ u8 rate, lanes;
+
+ err = drm_dp_dpcd_readb(aux, DP_TEST_LINK_RATE, &rate);
+ if (err < 0)
+ return err;
+ data->link_rate = drm_dp_bw_code_to_link_rate(rate);
+
+ err = drm_dp_dpcd_readb(aux, DP_TEST_LANE_COUNT, &lanes);
+ if (err < 0)
+ return err;
+ data->num_lanes = lanes & DP_MAX_LANE_COUNT_MASK;
+
+ if (lanes & DP_ENHANCED_FRAME_CAP)
+ data->enhanced_frame_cap = true;
+
+ err = drm_dp_dpcd_readb(aux, DP_PHY_TEST_PATTERN, &data->phy_pattern);
+ if (err < 0)
+ return err;
+
+ switch (data->phy_pattern) {
+ case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
+ err = drm_dp_dpcd_read(aux, DP_TEST_80BIT_CUSTOM_PATTERN_7_0,
+ &data->custom80, sizeof(data->custom80));
+ if (err < 0)
+ return err;
+
+ break;
+ case DP_PHY_TEST_PATTERN_CP2520:
+ err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
+ &data->hbr2_reset,
+ sizeof(data->hbr2_reset));
+ if (err < 0)
+ return err;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_phy_test_pattern);
+
+/**
+ * drm_dp_set_phy_test_pattern() - set the pattern to the sink.
+ * @aux: DisplayPort AUX channel
+ * @data: DP phy compliance test parameters.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
+ struct drm_dp_phy_test_params *data, u8 dp_rev)
+{
+ int err, i;
+ u8 link_config[2];
+ u8 test_pattern;
+
+ link_config[0] = drm_dp_link_rate_to_bw_code(data->link_rate);
+ link_config[1] = data->num_lanes;
+ if (data->enhanced_frame_cap)
+ link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
+ err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, link_config, 2);
+ if (err < 0)
+ return err;
+
+ test_pattern = data->phy_pattern;
+ if (dp_rev < 0x12) {
+ test_pattern = (test_pattern << 2) &
+ DP_LINK_QUAL_PATTERN_11_MASK;
+ err = drm_dp_dpcd_writeb(aux, DP_TRAINING_PATTERN_SET,
+test_pattern);
+ if (err < 0)
+ return err;
+ } else {
+ for (i = 0; i < data->num_lanes; i++) {
+ err = drm_dp_dpcd_writeb(aux,
+DP_LINK_QUAL_LANE0_SET + i,
+test_pattern);
+ if (err < 0)
+ return err;
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_set_phy_test_pattern);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 10ddb622a73e..e22cf5b2f174 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -702,6 +702,15 @@
# define DP_TEST_COUNT_MASK0xf
#define DP_PHY_TEST_PATTERN 0x248
+# define DP_PHY_TEST_PATTERN_SEL_MASK 0x7
+# define DP_PHY_TEST_PATTERN_NONE 0x0
+# define DP_PHY_TEST_PATTERN_D10_2 0x1
+# define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
+# define DP
[Intel-gfx] [PATCH v5 1/7] drm/amd/display: Align macro name as per DP spec
[Why]: Aligh with DP spec wanted to follow same naming convention. [How]: Changed the macro name of the dpcd address used for getting requested test-pattern. Cc: Harry Wentland Cc: Alex Deucher Reviewed-by: Harry Wentland Reviewed-by: Manasi Navare Signed-off-by: Animesh Manna --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- include/drm/drm_dp_helper.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 9553755be286..324a7bf81446 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -2530,7 +2530,7 @@ static void dp_test_send_phy_test_pattern(struct dc_link *link) /* get phy test pattern and pattern parameters from DP receiver */ core_link_read_dpcd( link, - DP_TEST_PHY_PATTERN, + DP_PHY_TEST_PATTERN, &dpcd_test_pattern.raw, sizeof(dpcd_test_pattern)); core_link_read_dpcd( diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index c6119e4c169a..10ddb622a73e 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -701,7 +701,7 @@ # define DP_TEST_CRC_SUPPORTED (1 << 5) # define DP_TEST_COUNT_MASK0xf -#define DP_TEST_PHY_PATTERN 0x248 +#define DP_PHY_TEST_PATTERN 0x248 #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250 #defineDP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251 #defineDP_TEST_80BIT_CUSTOM_PATTERN_23_16 0x252 -- 2.24.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 5/7] drm/i915/dp: Add debugfs entry for DP phy compliance
These debugfs entry will help testapp to understand the test request
during dp phy compliance mode.
Reviewed-by: Manasi Navare
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 1e6eb7f2f72d..ab20b7ea26f7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1326,6 +1326,16 @@ static int i915_displayport_test_data_show(struct
seq_file *m, void *data)
intel_dp->compliance.test_data.vdisplay);
seq_printf(m, "bpc: %u\n",
intel_dp->compliance.test_data.bpc);
+ } else if (intel_dp->compliance.test_type ==
+ DP_TEST_LINK_PHY_TEST_PATTERN) {
+ seq_printf(m, "pattern: %d\n",
+
intel_dp->compliance.test_data.phytest.phy_pattern);
+ seq_printf(m, "Number of lanes: %d\n",
+
intel_dp->compliance.test_data.phytest.num_lanes);
+ seq_printf(m, "Link Rate: %d\n",
+
intel_dp->compliance.test_data.phytest.link_rate);
+ seq_printf(m, "level: %02x\n",
+ intel_dp->train_set[0]);
}
} else
seq_puts(m, "0");
@@ -1358,7 +1368,7 @@ static int i915_displayport_test_type_show(struct
seq_file *m, void *data)
if (encoder && connector->status == connector_status_connected)
{
intel_dp = enc_to_intel_dp(encoder);
- seq_printf(m, "%02lx", intel_dp->compliance.test_type);
+ seq_printf(m, "%02lx\n",
intel_dp->compliance.test_type);
} else
seq_puts(m, "0");
}
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 3/7] drm/i915/dp: Made intel_dp_adjust_train() non-static
vswing/pre-emphasis adjustment calculation is needed in processing
of auto phy compliance request other than link training, so have
made non-static function.
No functional change.
v1: initial patch.
v2:
- used "intel_dp" prefix in function name. (Jani)
- used array notation instead pointer for link_status. (Ville)
v3: Scrapped the initial patch, modified commit description accordingly.
- made non-static function and used intel_dp prefix. (Jani, Manasi)
Reviewed-by: Manasi Navare
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 9 -
drivers/gpu/drm/i915/display/intel_dp_link_training.h | 4
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index a7defb37ab00..e4f1843170b7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -34,9 +34,8 @@ intel_dp_dump_link_status(const u8
link_status[DP_LINK_STATUS_SIZE])
link_status[3], link_status[4], link_status[5]);
}
-static void
-intel_get_adjust_train(struct intel_dp *intel_dp,
- const u8 link_status[DP_LINK_STATUS_SIZE])
+void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
+ const u8 link_status[DP_LINK_STATUS_SIZE])
{
u8 v = 0;
u8 p = 0;
@@ -219,7 +218,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp)
voltage = intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK;
/* Update training set as requested by target */
- intel_get_adjust_train(intel_dp, link_status);
+ intel_dp_get_adjust_train(intel_dp, link_status);
if (!intel_dp_update_link_train(intel_dp)) {
drm_err(&i915->drm,
"failed to update link training\n");
@@ -338,7 +337,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp
*intel_dp)
}
/* Update training set as requested by target */
- intel_get_adjust_train(intel_dp, link_status);
+ intel_dp_get_adjust_train(intel_dp, link_status);
if (!intel_dp_update_link_train(intel_dp)) {
drm_err(&i915->drm,
"failed to update link training\n");
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
index 174566adcc92..01f1dabbb060 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
@@ -6,8 +6,12 @@
#ifndef __INTEL_DP_LINK_TRAINING_H__
#define __INTEL_DP_LINK_TRAINING_H__
+#include
+
struct intel_dp;
+void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
+ const u8 link_status[DP_LINK_STATUS_SIZE]);
void intel_dp_start_link_train(struct intel_dp *intel_dp);
void intel_dp_stop_link_train(struct intel_dp *intel_dp);
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 6/7] drm/i915/dp: Register definition for DP compliance register
DP_COMP_CTL and DP_COMP_PAT register used to program DP
compliance pattern.
v1: Initial patch.
v2: used pipe instead of port in macro definition. [Manasi]
Reviewed-by: Manasi Navare
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_reg.h | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 309cb7d96b35..e93b90e17573 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9792,6 +9792,26 @@ enum skl_power_gate {
#define DDI_BUF_BALANCE_LEG_ENABLE(1 << 31)
#define DDI_BUF_TRANS_HI(port, i) _MMIO(_PORT(port, _DDI_BUF_TRANS_A,
_DDI_BUF_TRANS_B) + (i) * 8 + 4)
+/* DDI DP Compliance Control */
+#define DDI_DP_COMP_CTL_A 0x605F0
+#define DDI_DP_COMP_CTL_B 0x615F0
+#define DDI_DP_COMP_CTL(pipe) _MMIO_PORT(pipe, DDI_DP_COMP_CTL_A, \
+DDI_DP_COMP_CTL_B)
+#define DDI_DP_COMP_CTL_ENABLE(1 << 31)
+#define DDI_DP_COMP_CTL_D10_2 (0 << 28)
+#define DDI_DP_COMP_CTL_SCRAMBLED_0 (1 << 28)
+#define DDI_DP_COMP_CTL_PRBS7 (2 << 28)
+#define DDI_DP_COMP_CTL_CUSTOM80 (3 << 28)
+#define DDI_DP_COMP_CTL_HBR2 (4 << 28)
+#define DDI_DP_COMP_CTL_SCRAMBLED_1 (5 << 28)
+#define DDI_DP_COMP_CTL_HBR2_RESET(0xFC << 0)
+
+/* DDI DP Compliance Pattern */
+#define DDI_DP_COMP_PAT_A 0x605F4
+#define DDI_DP_COMP_PAT_B 0x615F4
+#define DDI_DP_COMP_PAT(pipe, i) _MMIO(_PIPE(pipe, DDI_DP_COMP_PAT_A, \
+DDI_DP_COMP_PAT_B) + (i) * 4)
+
/* Sideband Interface (SBI) is programmed indirectly, via
* SBI_ADDR, which contains the register offset; and SBI_DATA,
* which contains the payload */
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 7/7] drm/i915/dp: Program vswing, pre-emphasis, test-pattern
This patch process phy compliance request by programming requested
vswing, pre-emphasis and test pattern.
v1: Initial patch.
v2: Fixes added during testing with test-scope. (Khaled/Clint/Manasi)
- pipe used as argument during registers programming instead of port.
- TRANS_CONF must be disable/enable as well during ddi disable/enable.
- harcoded PLTPAT 80 bit custom pattern as the DPR-100 does not set it
in the sink’s DPCDs
- TRANS_DDI_FUNC_CTL DDI_Select (Bits 27:30) need to reset/set during
disable/enable.
v3: used macros instead of numbers and some cosmetic changes. [Manasi]
Cc: Clinton Taylor
Cc: Manasi Navare
Signed-off-by: Animesh Manna
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/i915/display/intel_dp.c | 147
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
2 files changed, 148 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 16a4a48c8168..8846471a49b8 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5020,6 +5020,151 @@ static u8 intel_dp_prepare_phytest(struct intel_dp
*intel_dp)
return DP_TEST_ACK;
}
+static void intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *dev_priv =
+ to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_dp_phy_test_params *data =
+ &intel_dp->compliance.test_data.phytest;
+ struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
+ enum pipe pipe = crtc->pipe;
+ u32 pattern_val;
+
+ switch (data->phy_pattern) {
+ case DP_PHY_TEST_PATTERN_NONE:
+ DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
+ intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+ break;
+ case DP_PHY_TEST_PATTERN_D10_2:
+ DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
+ intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+ DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
+ break;
+ case DP_PHY_TEST_PATTERN_ERROR_COUNT:
+ DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
+ intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+ DDI_DP_COMP_CTL_ENABLE |
+ DDI_DP_COMP_CTL_SCRAMBLED_0);
+ break;
+ case DP_PHY_TEST_PATTERN_PRBS7:
+ DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
+ intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+ DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
+ break;
+ case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
+ /*
+* FIXME: Ideally pattern should come from DPCD 0x250. As
+* current firmware of DPR-100 could not set it, so hardcoding
+* now for complaince test.
+*/
+ DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern 0x3e0f83e0
0x0f83e0f8 0xf83e\n");
+ pattern_val = 0x3e0f83e0;
+ intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), pattern_val);
+ pattern_val = 0x0f83e0f8;
+ intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), pattern_val);
+ pattern_val = 0xf83e;
+ intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), pattern_val);
+ intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+ DDI_DP_COMP_CTL_ENABLE |
+ DDI_DP_COMP_CTL_CUSTOM80);
+ break;
+ case DP_PHY_TEST_PATTERN_CP2520:
+ /*
+* FIXME: Ideally pattern should come from DPCD 0x24A. As
+* current firmware of DPR-100 could not set it, so hardcoding
+* now for complaince test.
+*/
+ DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
+ pattern_val = 0xFB;
+ intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
+ DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
+ pattern_val);
+ break;
+ default:
+ WARN(1, "Invalid Phy Test Pattern\n");
+ }
+}
+
+static void
+intel_dp_autotest_phy_ddi_disable(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
+ enum pipe pipe = crtc->pipe;
+ u32 trans_ddi_func_ctl_value, trans_conf_value, dp_tp_ctl_value;
+
+ trans_ddi_func_ctl_value = intel_de_read(dev_priv,
+
[Intel-gfx] [PATCH v5 4/7] drm/i915/dp: Preparation for DP phy compliance auto test
During DP phy compliance auto test mode, sink will request
combination of different test pattern with differnt level of
vswing, pre-emphasis. Function added to prepare for it.
Reviewed-by: Manasi Navare
Signed-off-by: Animesh Manna
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 24 +++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5e00e611f077..42d0b102c2cf 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1238,6 +1238,7 @@ struct intel_dp_compliance_data {
u8 video_pattern;
u16 hdisplay, vdisplay;
u8 bpc;
+ struct drm_dp_phy_test_params phytest;
};
struct intel_dp_compliance {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 0a417cd2af2b..16a4a48c8168 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5001,9 +5001,33 @@ static u8 intel_dp_autotest_edid(struct intel_dp
*intel_dp)
return test_result;
}
+static u8 intel_dp_prepare_phytest(struct intel_dp *intel_dp)
+{
+ struct drm_dp_phy_test_params *data =
+ &intel_dp->compliance.test_data.phytest;
+
+ if (drm_dp_get_phy_test_pattern(&intel_dp->aux, data)) {
+ DRM_DEBUG_KMS("DP Phy Test pattern AUX read failure\n");
+ return DP_TEST_NAK;
+ }
+
+ /*
+* link_mst is set to false to avoid executing mst related code
+* during compliance testing.
+*/
+ intel_dp->link_mst = false;
+
+ return DP_TEST_ACK;
+}
+
static u8 intel_dp_autotest_phy_pattern(struct intel_dp *intel_dp)
{
u8 test_result = DP_TEST_NAK;
+
+ test_result = intel_dp_prepare_phytest(intel_dp);
+ if (test_result != DP_TEST_ACK)
+ DRM_ERROR("Phy test preparation failed\n");
+
return test_result;
}
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 0/7] DP Phy compliance auto test
Driver changes mainly to process the request coming from Test equipment as short pulse hpd interrupt to change link-pattern/v-swing/pre-emphasis Complete auto test suite takes much lesser time than manual run. Overall design: -- Automate test request will come to source device as HDP short pulse interrupt from test scope. Read DPCD 0x201, Check for bit 1 for automated test request. If set continue and read DPCD 0x218. Check for bit 3 for phy test pattern, If set continue. Get the requested test pattern through DPCD 0x248. Compute requested voltage swing level and pre-emphasis level from DPCD 0x206 and 0x207 Set signal level through vswing programming sequence. Write DDI_COMP_CTL and DDI_COMP_PATx as per requested pattern. Configure the link and write the new test pattern through DPCD. High level patch description. - patch 1: Align macro name as per DP spec.. patch 2: drm level api added to get/set test pattern as per vesa DP spec. This maybe useful for other driver so added in drm layer. patch 3: vswing/preemphasis adjustment calculation is needed during phy compliance request processing along with existing link training process, so moved the same function in intel_dp.c. patch 4: Preparation for auto phy compliance test scope request. patch 5: Added debugfs entry for phy compliance. patch 6: Register difnition of DP compliance register added. patch 7: This patch os mainly processing the request. Complete phy compliance test suite executed and received positive result. v1: Redesigned the code as per review feedback from Manasi on RFC. v2: Addressed review comments from Manasi. v3: Addressed review commnets from Harry, Ville, Jani. v4: Had design closure and added fixes after complete test-run. (Thanks to Khaled/Manasi/Clint for fixes and test execution) v5: Fixed some nitpicks by Manasi. Animesh Manna (7): drm/amd/display: Align macro name as per DP spec drm/dp: get/set phy compliance pattern drm/i915/dp: Made intel_dp_adjust_train() non-static drm/i915/dp: Preparation for DP phy compliance auto test drm/i915/dp: Add debugfs entry for DP phy compliance drm/i915/dp: Register definition for DP compliance register drm/i915/dp: Program vswing, pre-emphasis, test-pattern .../gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- drivers/gpu/drm/drm_dp_helper.c | 94 ++ .../drm/i915/display/intel_display_debugfs.c | 12 +- .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_dp.c | 171 ++ drivers/gpu/drm/i915/display/intel_dp.h | 1 + .../drm/i915/display/intel_dp_link_training.c | 9 +- .../drm/i915/display/intel_dp_link_training.h | 4 + drivers/gpu/drm/i915/i915_reg.h | 20 ++ include/drm/drm_dp_helper.h | 33 +++- 10 files changed, 339 insertions(+), 8 deletions(-) -- 2.24.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] i915/sysfs_heartbeat_interval: Check for support prior to 'nopreempt' test
To turn off preemption, we now require per-engine resets.
Signed-off-by: Chris Wilson
---
tests/i915/sysfs_heartbeat_interval.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/i915/sysfs_heartbeat_interval.c
b/tests/i915/sysfs_heartbeat_interval.c
index 0ba19b263..ef131a16c 100644
--- a/tests/i915/sysfs_heartbeat_interval.c
+++ b/tests/i915/sysfs_heartbeat_interval.c
@@ -227,7 +227,7 @@ static void test_nopreempt(int i915, int engine)
*/
/* Test heartbeats with forced preemption disabled */
- igt_sysfs_printf(engine, "preempt_timeout_ms", "%u", 0);
+ igt_require(igt_sysfs_printf(engine, "preempt_timeout_ms", "%u", 0) >
0);
igt_assert(igt_sysfs_scanf(engine, ATTR, "%u", &saved) == 1);
igt_debug("Initial %s:%u\n", ATTR, saved);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] intel-ci: Tweak blacklist for very long running stability tests
To exclude yynamic tests just use their group name? Signed-off-by: Chris Wilson Cc: Petri Latvala --- tests/intel-ci/blacklist.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt index 948b47569..184c23c37 100644 --- a/tests/intel-ci/blacklist.txt +++ b/tests/intel-ci/blacklist.txt @@ -60,9 +60,9 @@ igt@gem_sync@(?!.*basic).* igt@gem_tiled_swapping@(?!non-threaded).* igt@gem_userptr_blits@(major|minor|forked|mlocked|swapping).* igt@gem_wait@.*hang.* -igt@sysfs_heartbeat_timeout@long.* -igt@sysfs_preemption_timeout@off.* -igt@sysfs_timeslice_duration@off.* +igt@sysfs_heartbeat_timeout@long +igt@sysfs_preemption_timeout@off +igt@sysfs_timeslice_duration@off ### # GEM: Not worth fixing ### -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/gt: Allocate i915_fence_reg array
Chris Wilson writes:
> Since the number of fence regs can vary dramactically between platforms,
> allocate the array on demand so we don't waste as much space.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 6 --
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 10 ++
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 1 +
> drivers/gpu/drm/i915/gt/intel_gtt.h | 5 +++--
> drivers/gpu/drm/i915/i915_vma.h | 1 +
> 5 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index bde4f64a41f7..8fcf14372d7a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -698,11 +698,13 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
> */
> void i915_ggtt_driver_release(struct drm_i915_private *i915)
> {
> + struct i915_ggtt *ggtt = &i915->ggtt;
> struct pagevec *pvec;
>
> - fini_aliasing_ppgtt(&i915->ggtt);
> + fini_aliasing_ppgtt(ggtt);
>
> - ggtt_cleanup_hw(&i915->ggtt);
> + intel_ggtt_fini_fences(ggtt);
> + ggtt_cleanup_hw(ggtt);
>
> pvec = &i915->mm.wc_stash.pvec;
> if (pvec->nr) {
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> index 94af75673a58..b6ba68c42546 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
> @@ -857,6 +857,11 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
> if (intel_vgpu_active(i915))
> num_fences = intel_uncore_read(uncore,
> vgtif_reg(avail_rs.fence_num));
> + ggtt->fence_regs = kcalloc(num_fences,
> +sizeof(*ggtt->fence_regs),
> +GFP_KERNEL);
> + if (!ggtt->fence_regs)
> + num_fences = 0;
>
> /* Initialize fence registers to zero */
> for (i = 0; i < num_fences; i++) {
> @@ -871,6 +876,11 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
> intel_ggtt_restore_fences(ggtt);
> }
>
> +void intel_ggtt_fini_fences(struct i915_ggtt *ggtt)
> +{
> + kfree(ggtt->fence_regs);
> +}
> +
> void intel_gt_init_swizzling(struct intel_gt *gt)
> {
> struct drm_i915_private *i915 = gt->i915;
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
> b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
> index 3b3eb5bf1b75..9850f6a85d2a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
> @@ -64,6 +64,7 @@ void i915_gem_object_save_bit_17_swizzle(struct
> drm_i915_gem_object *obj,
>struct sg_table *pages);
>
> void intel_ggtt_init_fences(struct i915_ggtt *ggtt);
> +void intel_ggtt_fini_fences(struct i915_ggtt *ggtt);
>
> void intel_gt_init_swizzling(struct intel_gt *gt);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
> b/drivers/gpu/drm/i915/gt/intel_gtt.h
> index ce6ff9d3a350..d93ebdf3fa0e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gtt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
> @@ -26,7 +26,6 @@
> #include
>
> #include "gt/intel_reset.h"
> -#include "gt/intel_ggtt_fencing.h"
> #include "i915_selftest.h"
> #include "i915_vma_types.h"
>
> @@ -135,6 +134,8 @@ typedef u64 gen8_pte_t;
> #define GEN8_PDE_IPS_64K BIT(11)
> #define GEN8_PDE_PS_2M BIT(7)
>
> +struct i915_fence_reg;
> +
> #define for_each_sgt_daddr(__dp, __iter, __sgt) \
> __for_each_sgt_daddr(__dp, __iter, __sgt, I915_GTT_PAGE_SIZE)
>
> @@ -333,7 +334,7 @@ struct i915_ggtt {
> u32 pin_bias;
>
> unsigned int num_fences;
> - struct i915_fence_reg fence_regs[I915_MAX_NUM_FENCES];
> + struct i915_fence_reg *fence_regs;
> struct list_head fence_list;
>
> /**
> diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
> index 2764c277326f..b958ad07f212 100644
> --- a/drivers/gpu/drm/i915/i915_vma.h
> +++ b/drivers/gpu/drm/i915/i915_vma.h
> @@ -30,6 +30,7 @@
>
> #include
>
> +#include "gt/intel_ggtt_fencing.h"
> #include "gem/i915_gem_object.h"
>
> #include "i915_gem_gtt.h"
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/4] drm/i915: Move GGTT fence registers under gt/
Since the fence registers control HW detiling through the GGTT
aperture, make them a part of the intel_ggtt under gt/
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
.../intel_ggtt_fencing.c} | 27 +++
.../intel_ggtt_fencing.h} | 9 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
drivers/gpu/drm/i915/gvt/aperture_gm.c| 2 +-
drivers/gpu/drm/i915/i915_drv.c | 6 ++---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_vma.h | 1 -
drivers/gpu/drm/i915/selftests/i915_gem.c | 2 +-
12 files changed, 24 insertions(+), 34 deletions(-)
rename drivers/gpu/drm/i915/{i915_gem_fence_reg.c => gt/intel_ggtt_fencing.c}
(97%)
rename drivers/gpu/drm/i915/{i915_gem_fence_reg.h => gt/intel_ggtt_fencing.h}
(92%)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9f887a86e555..1b2ed963179c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -92,6 +92,7 @@ gt-y += \
gt/intel_engine_pool.o \
gt/intel_engine_user.o \
gt/intel_ggtt.o \
+ gt/intel_ggtt_fencing.o \
gt/intel_gt.o \
gt/intel_gt_irq.o \
gt/intel_gt_pm.o \
@@ -153,7 +154,6 @@ i915-y += \
i915_buddy.o \
i915_cmd_parser.o \
i915_gem_evict.o \
- i915_gem_fence_reg.o \
i915_gem_gtt.o \
i915_gem.o \
i915_globals.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index aed498a0d032..a7b72fa569a7 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -65,7 +65,7 @@ static int ggtt_init_hw(struct i915_ggtt *ggtt)
ggtt->mappable_end);
}
- i915_ggtt_init_fences(ggtt);
+ intel_ggtt_init_fences(ggtt);
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
similarity index 97%
rename from drivers/gpu/drm/i915/i915_gem_fence_reg.c
rename to drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index d152b648c73c..94af75673a58 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -233,16 +233,9 @@ static int fence_update(struct i915_fence_reg *fence,
int ret;
if (vma) {
- if (!i915_vma_is_map_and_fenceable(vma))
- return -EINVAL;
-
- if (drm_WARN(&uncore->i915->drm,
-!i915_gem_object_get_stride(vma->obj) ||
-!i915_gem_object_get_tiling(vma->obj),
-"bogus fence setup with stride: 0x%x, tiling mode:
%i\n",
-i915_gem_object_get_stride(vma->obj),
-i915_gem_object_get_tiling(vma->obj)))
- return -EINVAL;
+ GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
+ GEM_BUG_ON(!i915_gem_object_get_stride(vma->obj) ||
+ !i915_gem_object_get_tiling(vma->obj));
ret = i915_vma_sync(vma);
if (ret)
@@ -276,7 +269,7 @@ static int fence_update(struct i915_fence_reg *fence,
/*
* We only need to update the register itself if the device is awake.
* If the device is currently powered down, we will defer the write
-* to the runtime resume, see i915_gem_restore_fences().
+* to the runtime resume, see intel_ggtt_restore_fences().
*
* This only works for removing the fence register, on acquisition
* the caller must hold the rpm wakeref. The fence register must
@@ -487,14 +480,14 @@ void i915_unreserve_fence(struct i915_fence_reg *fence)
}
/**
- * i915_gem_restore_fences - restore fence state
+ * intel_ggtt_restore_fences - restore fence state
* @ggtt: Global GTT
*
* Restore the hw fence state to match the software tracking again, to be
called
* after a gpu reset and on resume. Note that on runtime suspend we only cancel
* the fences, to be reacquired by the user later.
*/
-void i915_gem_restore_fences(struct i915_ggtt *ggtt)
+void intel_ggtt_restore_fences(struct i915_ggtt *ggtt)
{
int i;
@@ -746,7 +739,7 @@ static void detect_bit_6_swizzle(struct i915_ggtt *ggtt)
* bit 17 of its physical address and therefore being interpreted differently
* by the GPU.
*/
-static void i915_gem_swizzle_page(struct page *page)
+static void swizzle_page(struct page *page)
{
char temp[64];
char *vaddr;
@@ -791,7 +784,7 @@ i915_gem_object_do_bit_17_swizzle(struct
drm_i915_gem_object
[Intel-gfx] [CI 4/4] drm/i915/gt: Allocate i915_fence_reg array
Since the number of fence regs can vary dramactically between platforms,
allocate the array on demand so we don't waste as much space.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 6 --
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 10 ++
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 5 +++--
drivers/gpu/drm/i915/i915_vma.h | 1 +
5 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index bde4f64a41f7..8fcf14372d7a 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -698,11 +698,13 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
*/
void i915_ggtt_driver_release(struct drm_i915_private *i915)
{
+ struct i915_ggtt *ggtt = &i915->ggtt;
struct pagevec *pvec;
- fini_aliasing_ppgtt(&i915->ggtt);
+ fini_aliasing_ppgtt(ggtt);
- ggtt_cleanup_hw(&i915->ggtt);
+ intel_ggtt_fini_fences(ggtt);
+ ggtt_cleanup_hw(ggtt);
pvec = &i915->mm.wc_stash.pvec;
if (pvec->nr) {
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 94af75673a58..b6ba68c42546 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -857,6 +857,11 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
if (intel_vgpu_active(i915))
num_fences = intel_uncore_read(uncore,
vgtif_reg(avail_rs.fence_num));
+ ggtt->fence_regs = kcalloc(num_fences,
+ sizeof(*ggtt->fence_regs),
+ GFP_KERNEL);
+ if (!ggtt->fence_regs)
+ num_fences = 0;
/* Initialize fence registers to zero */
for (i = 0; i < num_fences; i++) {
@@ -871,6 +876,11 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
intel_ggtt_restore_fences(ggtt);
}
+void intel_ggtt_fini_fences(struct i915_ggtt *ggtt)
+{
+ kfree(ggtt->fence_regs);
+}
+
void intel_gt_init_swizzling(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
index 3b3eb5bf1b75..9850f6a85d2a 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
@@ -64,6 +64,7 @@ void i915_gem_object_save_bit_17_swizzle(struct
drm_i915_gem_object *obj,
struct sg_table *pages);
void intel_ggtt_init_fences(struct i915_ggtt *ggtt);
+void intel_ggtt_fini_fences(struct i915_ggtt *ggtt);
void intel_gt_init_swizzling(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index ce6ff9d3a350..d93ebdf3fa0e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -26,7 +26,6 @@
#include
#include "gt/intel_reset.h"
-#include "gt/intel_ggtt_fencing.h"
#include "i915_selftest.h"
#include "i915_vma_types.h"
@@ -135,6 +134,8 @@ typedef u64 gen8_pte_t;
#define GEN8_PDE_IPS_64K BIT(11)
#define GEN8_PDE_PS_2M BIT(7)
+struct i915_fence_reg;
+
#define for_each_sgt_daddr(__dp, __iter, __sgt) \
__for_each_sgt_daddr(__dp, __iter, __sgt, I915_GTT_PAGE_SIZE)
@@ -333,7 +334,7 @@ struct i915_ggtt {
u32 pin_bias;
unsigned int num_fences;
- struct i915_fence_reg fence_regs[I915_MAX_NUM_FENCES];
+ struct i915_fence_reg *fence_regs;
struct list_head fence_list;
/**
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 2764c277326f..b958ad07f212 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -30,6 +30,7 @@
#include
+#include "gt/intel_ggtt_fencing.h"
#include "gem/i915_gem_object.h"
#include "i915_gem_gtt.h"
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/4] drm/i915: Remove manual save/resume of fence register state
Since we always reload the fence register state on runtime resume,
having it explicitly in the S0ix resume code is redundant. Indeed, it
is not even being used!
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ddd5b40cbbbc..a7ea1d855359 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -539,7 +539,6 @@ struct i915_suspend_saved_registers {
u32 saveSWF0[16];
u32 saveSWF1[16];
u32 saveSWF3[3];
- u64 saveFENCE[I915_MAX_NUM_FENCES];
u32 savePCH_PORT_HOTPLUG;
u16 saveGCDGMBUS;
};
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/4] drm/i915/gt: Pull restoration of GGTT fences underneath the GT
Make the GT responsible for restoring its fence when it wakes up from
suspend.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 ++
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 +
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/i915_gem.c | 1 -
drivers/gpu/drm/i915/selftests/i915_gem.c | 2 --
5 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index a7b72fa569a7..bde4f64a41f7 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1195,6 +1195,8 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
if (INTEL_GEN(ggtt->vm.i915) >= 8)
setup_private_pat(ggtt->vm.gt->uncore);
+
+ intel_ggtt_restore_fences(ggtt);
}
static struct scatterlist *
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 8b653c0f5e5f..2e40400d1ecd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -324,6 +324,7 @@ int intel_gt_runtime_resume(struct intel_gt *gt)
{
GT_TRACE(gt, "\n");
intel_gt_init_swizzling(gt);
+ intel_ggtt_restore_fences(gt->ggtt);
return intel_uc_runtime_resume(>->uc);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 832140f4ea3d..48ba37e35bea 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1288,7 +1288,6 @@ static int i915_drm_resume(struct drm_device *dev)
drm_err(&dev_priv->drm, "failed to re-enable GGTT\n");
i915_ggtt_resume(&dev_priv->ggtt);
- intel_ggtt_restore_fences(&dev_priv->ggtt);
intel_csr_ucode_resume(dev_priv);
@@ -1606,8 +1605,6 @@ static int intel_runtime_suspend(struct device *kdev)
intel_gt_runtime_resume(&dev_priv->gt);
- intel_ggtt_restore_fences(&dev_priv->ggtt);
-
enable_rpm_wakeref_asserts(rpm);
return ret;
@@ -1687,7 +1684,6 @@ static int intel_runtime_resume(struct device *kdev)
* we can do is to hope that things will still work (and disable RPM).
*/
intel_gt_runtime_resume(&dev_priv->gt);
- intel_ggtt_restore_fences(&dev_priv->ggtt);
/*
* On VLV/CHV display interrupts are part of the display
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2c53be0bd9fd..762b50b08d73 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1156,7 +1156,6 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
/* Minimal basic recovery for KMS */
ret = i915_ggtt_enable_hw(dev_priv);
i915_ggtt_resume(&dev_priv->ggtt);
- intel_ggtt_restore_fences(&dev_priv->ggtt);
intel_init_clock_gating(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c
b/drivers/gpu/drm/i915/selftests/i915_gem.c
index 7ea517a21e0b..88d400b9df88 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
@@ -125,8 +125,6 @@ static void pm_resume(struct drm_i915_private *i915)
*/
with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
i915_ggtt_resume(&i915->ggtt);
- intel_ggtt_restore_fences(&i915->ggtt);
-
i915_gem_resume(i915);
}
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1 1/3] drm/i915: Decouple cdclk calculation from modeset checks
We need to calculate cdclk after watermarks/ddb has been calculated
as with recent hw CDCLK needs to be adjusted accordingly to DBuf
requirements, which is not possible with current code organization.
Setting CDCLK according to DBuf BW requirements and not just rejecting
if it doesn't satisfy BW requirements, will allow us to save power when
it is possible and gain additional bandwidth when it's needed - i.e
boosting both our power management and perfomance capabilities.
This patch is preparation for that, first we now extract modeset
calculation from modeset checks, in order to call it after wm/ddb
has been calculated.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_display.c | 22
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8f23c4d51c33..cdff3054b344 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14542,6 +14542,14 @@ static int intel_modeset_checks(struct
intel_atomic_state *state)
return ret;
}
+ return 0;
+}
+
+static int intel_modeset_cdclk(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ int ret;
+
ret = intel_modeset_calc_cdclk(state);
if (ret)
return ret;
@@ -14879,10 +14887,6 @@ static int intel_atomic_check(struct drm_device *dev,
goto fail;
}
- ret = intel_atomic_check_crtcs(state);
- if (ret)
- goto fail;
-
intel_fbc_choose_crtc(dev_priv, state);
ret = calc_watermark_data(state);
if (ret)
@@ -14892,6 +14896,16 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
+ if (any_ms) {
+ ret = intel_modeset_cdclk(state);
+ if (ret)
+ goto fail;
+ }
+
+ ret = intel_atomic_check_crtcs(state);
+ if (ret)
+ goto fail;
+
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
if (!needs_modeset(new_crtc_state) &&
--
2.24.1.485.gad05a3d8e5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1 3/3] drm/i915: Remove unneeded hack now for CDCLK
No need to bump up CDCLK now, as it is now correctly calculated, accounting for DBuf BW as BSpec says. Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/display/intel_cdclk.c | 12 1 file changed, 12 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c index f0dcea4d6357..45469f6833b8 100644 --- a/drivers/gpu/drm/i915/display/intel_cdclk.c +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c @@ -2055,18 +2055,6 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state) /* Account for additional needs from the planes */ min_cdclk = max(intel_planes_min_cdclk(crtc_state), min_cdclk); - /* -* HACK. Currently for TGL platforms we calculate -* min_cdclk initially based on pixel_rate divided -* by 2, accounting for also plane requirements, -* however in some cases the lowest possible CDCLK -* doesn't work and causing the underruns. -* Explicitly stating here that this seems to be currently -* rather a Hack, than final solution. -*/ - if (IS_TIGERLAKE(dev_priv)) - min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate); - /* * Similar story as with skl_write_plane_wm and intel_enable_sagv * - in some certain driver parts, we don't have any guarantee that -- 2.24.1.485.gad05a3d8e5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1 2/3] drm/i915: Adjust CDCLK accordingly to our DBuf bw needs
According to BSpec max BW per slice is calculated using formula
Max BW = CDCLK * 64. Currently when calculating min CDCLK we
account only per plane requirements, however in order to avoid
FIFO underruns we need to estimate accumulated BW consumed by
all planes(ddb entries basically) residing on that particular
DBuf slice. This will allow us to put CDCLK lower and save power
when we don't need that much bandwidth or gain additional
perfomance once plane consumption grows.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_bw.c | 46 +++
drivers/gpu/drm/i915/display/intel_bw.h | 1 +
drivers/gpu/drm/i915/display/intel_cdclk.c| 22 +
drivers/gpu/drm/i915/display/intel_display.c | 10 +++-
.../drm/i915/display/intel_display_power.h| 1 +
drivers/gpu/drm/i915/intel_pm.c | 34 +-
drivers/gpu/drm/i915/intel_pm.h | 3 ++
7 files changed, 114 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 58b264bc318d..a85125110d7e 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -6,6 +6,7 @@
#include
#include "intel_bw.h"
+#include "intel_pm.h"
#include "intel_display_types.h"
#include "intel_sideband.h"
@@ -334,6 +335,51 @@ static unsigned int intel_bw_crtc_data_rate(const struct
intel_crtc_state *crtc_
return data_rate;
}
+int intel_bw_calc_min_cdclk(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ int max_bw_per_dbuf[DBUF_SLICE_MAX];
+ int i = 0;
+ enum plane_id plane_id;
+ struct intel_crtc_state *crtc_state;
+ struct intel_crtc *crtc;
+ int max_bw = 0;
+ int min_cdclk;
+
+ memset(max_bw_per_dbuf, 0, sizeof(max_bw_per_dbuf[0]) * DBUF_SLICE_MAX);
+
+ for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
+ for_each_plane_id_on_crtc(crtc, plane_id) {
+ struct skl_ddb_entry *plane_alloc =
+ &crtc_state->wm.skl.plane_ddb_y[plane_id];
+ struct skl_ddb_entry *uv_plane_alloc =
+ &crtc_state->wm.skl.plane_ddb_uv[plane_id];
+ unsigned int data_rate =
crtc_state->data_rate[plane_id];
+ int slice_id = 0;
+ u32 dbuf_mask = skl_ddb_dbuf_slice_mask(dev_priv,
plane_alloc);
+
+ dbuf_mask |= skl_ddb_dbuf_slice_mask(dev_priv,
uv_plane_alloc);
+
+ DRM_DEBUG_KMS("Got dbuf mask %x for pipe %c ddb %d-%d
plane %d data rate %d\n",
+ dbuf_mask, pipe_name(crtc->pipe),
plane_alloc->start,
+ plane_alloc->end, plane_id, data_rate);
+
+ while (dbuf_mask != 0) {
+ if (dbuf_mask & 1) {
+ max_bw_per_dbuf[slice_id] += data_rate;
+ max_bw = max(max_bw,
max_bw_per_dbuf[slice_id]);
+ }
+ slice_id++;
+ dbuf_mask >>= 1;
+ }
+ }
+ }
+
+ min_cdclk = max_bw / 64;
+
+ return min_cdclk;
+}
+
void intel_bw_crtc_update(struct intel_bw_state *bw_state,
const struct intel_crtc_state *crtc_state)
{
diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
b/drivers/gpu/drm/i915/display/intel_bw.h
index a8aa7624c5aa..8a522b571c51 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.h
+++ b/drivers/gpu/drm/i915/display/intel_bw.h
@@ -29,5 +29,6 @@ int intel_bw_init(struct drm_i915_private *dev_priv);
int intel_bw_atomic_check(struct intel_atomic_state *state);
void intel_bw_crtc_update(struct intel_bw_state *bw_state,
const struct intel_crtc_state *crtc_state);
+int intel_bw_calc_min_cdclk(struct intel_atomic_state *state);
#endif /* __INTEL_BW_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 0741d643455b..f0dcea4d6357 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -25,6 +25,7 @@
#include "intel_cdclk.h"
#include "intel_display_types.h"
#include "intel_sideband.h"
+#include "intel_bw.h"
/**
* DOC: CDCLK / RAWCLK
@@ -1979,11 +1980,19 @@ int intel_crtc_compute_min_cdclk(const struct
intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv =
to_i915(crtc_state->uapi.crtc->dev);
+ struct intel_atomic_state *state = NULL;
int min_cdclk;
if (!crtc_state->hw.enable)
return 0;
+ /*
+* FIXME: Unfortunately when this gets called from
intel_modeset_setup_hw_
[Intel-gfx] [PATCH v1 0/3] Consider DBuf bandwidth when calculating CDCLK
We need to calculate cdclk after watermarks/ddb has been calculated as with recent hw CDCLK needs to be adjusted accordingly to DBuf requirements, which is not possible with current code organization. Setting CDCLK according to DBuf BW requirements and not just rejecting if it doesn't satisfy BW requirements, will allow us to save power when it is possible and gain additional bandwidth when it's needed - i.e boosting both our power management and perfomance capabilities. This patch is preparation for that, first we now extract modeset calculation from modeset checks, in order to call it after wm/ddb has been calculated. Stanislav Lisovskiy (3): drm/i915: Decouple cdclk calculation from modeset checks drm/i915: Adjust CDCLK accordingly to our DBuf bw needs drm/i915: Remove unneeded hack now for CDCLK drivers/gpu/drm/i915/display/intel_bw.c | 46 +++ drivers/gpu/drm/i915/display/intel_bw.h | 1 + drivers/gpu/drm/i915/display/intel_cdclk.c| 28 +++ drivers/gpu/drm/i915/display/intel_display.c | 32 +++-- .../drm/i915/display/intel_display_power.h| 1 + drivers/gpu/drm/i915/intel_pm.c | 34 +- drivers/gpu/drm/i915/intel_pm.h | 3 ++ 7 files changed, 129 insertions(+), 16 deletions(-) -- 2.24.1.485.gad05a3d8e5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/15] drm/i915/gem: Bind the fence async for execbuf
It is illegal to wait on an another vma while holding the vm->mutex, as
that easily leads to ABBA deadlocks (we wait on a second vma that waits
on us to release the vm->mutex). So while the vm->mutex exists, move the
waiting outside of the lock into the async binding pipeline.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 21 +++--
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 87 ++-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 5 ++
3 files changed, 103 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 7fb47ff185a3..db5ad6a0df28 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -472,13 +472,19 @@ eb_pin_vma(struct i915_execbuffer *eb,
return false;
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
- if (unlikely(i915_vma_pin_fence(vma))) {
- i915_vma_unpin(vma);
- return false;
- }
+ struct i915_fence_reg *reg = vma->fence;
- if (vma->fence)
+ /* Avoid waiting to change the fence; defer to async worker */
+ if (reg) {
+ if (READ_ONCE(reg->dirty))
+ return false;
+
+ atomic_inc(®->pin_count);
ev->flags |= __EXEC_OBJECT_HAS_FENCE;
+ } else {
+ if (i915_gem_object_is_tiled(vma->obj))
+ return false;
+ }
}
ev->flags |= __EXEC_OBJECT_HAS_PIN;
@@ -955,7 +961,7 @@ static int eb_reserve_vma(struct eb_vm_work *work, struct
eb_vma *ev)
pin:
if (unlikely(exec_flags & EXEC_OBJECT_NEEDS_FENCE)) {
- err = __i915_vma_pin_fence(vma); /* XXX no waiting */
+ err = __i915_vma_pin_fence_async(vma, &work->base);
if (unlikely(err))
return err;
@@ -1030,6 +1036,9 @@ static int eb_bind_vma(struct dma_fence_work *base)
GEM_BUG_ON(vma->vm != vm);
+ if (ev->flags & __EXEC_OBJECT_HAS_FENCE)
+ __i915_vma_apply_fence_async(vma);
+
if (!ev->bind_flags)
goto put;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 97659a1249fd..d99d57be3505 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -21,10 +21,13 @@
* IN THE SOFTWARE.
*/
+#include "i915_active.h"
#include "i915_drv.h"
#include "i915_scatterlist.h"
+#include "i915_sw_fence_work.h"
#include "i915_pvinfo.h"
#include "i915_vgpu.h"
+#include "i915_vma.h"
/**
* DOC: fence register handling
@@ -336,16 +339,14 @@ static struct i915_fence_reg *fence_find(struct i915_ggtt
*ggtt)
int __i915_vma_pin_fence(struct i915_vma *vma)
{
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vma->vm);
- struct i915_fence_reg *fence;
+ struct i915_fence_reg *fence = vma->fence;
struct i915_vma *set = i915_gem_object_is_tiled(vma->obj) ? vma : NULL;
int err;
lockdep_assert_held(&vma->vm->mutex);
/* Just update our place in the LRU if our fence is getting reused. */
- if (vma->fence) {
- fence = vma->fence;
- GEM_BUG_ON(fence->vma != vma);
+ if (fence && fence->vma == vma) {
atomic_inc(&fence->pin_count);
if (!fence->dirty) {
list_move_tail(&fence->link, &ggtt->fence_list);
@@ -377,6 +378,84 @@ int __i915_vma_pin_fence(struct i915_vma *vma)
return err;
}
+int __i915_vma_pin_fence_async(struct i915_vma *vma,
+ struct dma_fence_work *work)
+{
+ struct i915_ggtt *ggtt = i915_vm_to_ggtt(vma->vm);
+ struct i915_vma *set = i915_gem_object_is_tiled(vma->obj) ? vma : NULL;
+ struct i915_fence_reg *fence = vma->fence;
+ int err;
+
+ lockdep_assert_held(&vma->vm->mutex);
+
+ /* Just update our place in the LRU if our fence is getting reused. */
+ if (fence && fence->vma == vma) {
+ } else if (set) {
+ fence = fence_find(ggtt);
+ if (IS_ERR(fence))
+ return PTR_ERR(fence);
+
+ GEM_BUG_ON(atomic_read(&fence->pin_count));
+ fence->dirty = true;
+ } else {
+ return 0;
+ }
+
+ atomic_inc(&fence->pin_count);
+ if (!fence->dirty) {
+ list_move_tail(&fence->link, &ggtt->fence_list);
+ return 0;
+ }
+
+ fence->tiling = 0;
+ if (set) {
+ if (INTEL_GEN(fence_to_i915(fence)) < 4) {
+ /* implicit 'unfenced' GPU blits */
+
[Intel-gfx] [PATCH 10/15] drm/i915/gem: Assign context id for async work
Allocate a few dma fence context id that we can use to associate async work
[for the CPU] launched on behalf of this context. For extra fun, we allow
a configurable concurrency width.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4
drivers/gpu/drm/i915/gem/i915_gem_context.h | 6 ++
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 6 ++
3 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 026999b34abd..ade01be32a4a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -721,6 +721,10 @@ __create_context(struct drm_i915_private *i915)
ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
mutex_init(&ctx->mutex);
+ ctx->async.width = rounddown_pow_of_two(num_online_cpus());
+ ctx->async.context = dma_fence_context_alloc(ctx->async.width);
+ ctx->async.width--;
+
spin_lock_init(&ctx->stale.lock);
INIT_LIST_HEAD(&ctx->stale.engines);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 57b7ae2893e1..0919694f4514 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -134,6 +134,12 @@ int i915_gem_context_setparam_ioctl(struct drm_device
*dev, void *data,
int i915_gem_context_reset_stats_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+static inline u64 i915_gem_context_async_id(struct i915_gem_context *ctx)
+{
+ return (ctx->async.context +
+ (atomic_fetch_inc(&ctx->async.cur) & ctx->async.width));
+}
+
static inline struct i915_gem_context *
i915_gem_context_get(struct i915_gem_context *ctx)
{
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 28760bd03265..5f5cfa3a3e9b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -85,6 +85,12 @@ struct i915_gem_context {
struct intel_timeline *timeline;
+ struct {
+ u64 context;
+ atomic_t cur;
+ unsigned int width;
+ } async;
+
/**
* @vm: unique address space (GTT)
*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/15] drm/i915: Immediately execute the fenced work
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/i915_sw_fence_work.c | 6 +-
drivers/gpu/drm/i915/i915_sw_fence_work.h | 7 +++
drivers/gpu/drm/i915/i915_vma.c| 2 +-
4 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3f4f28e9468..f647f98a9bc6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1784,7 +1784,7 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
dma_resv_add_excl_fence(shadow->resv, &pw->base.dma);
dma_resv_unlock(shadow->resv);
- dma_fence_work_commit(&pw->base);
+ dma_fence_work_commit_imm(&pw->base);
return 0;
err_batch_unlock:
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index 997b2998f1f2..cb2858d369cf 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -38,7 +38,10 @@ fence_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
if (!f->dma.error) {
dma_fence_get(&f->dma);
- queue_work(system_unbound_wq, &f->work);
+ if (f->immediate)
+ fence_work(&f->work);
+ else
+ queue_work(system_unbound_wq, &f->work);
} else {
fence_complete(f);
}
@@ -88,6 +91,7 @@ void dma_fence_work_init(struct dma_fence_work *f,
dma_fence_init(&f->dma, &fence_ops, &f->lock, 0, 0);
i915_sw_fence_init(&f->chain, fence_notify);
INIT_WORK(&f->work, fence_work);
+ f->immediate = false;
}
int dma_fence_work_chain(struct dma_fence_work *f, struct dma_fence *signal)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.h
b/drivers/gpu/drm/i915/i915_sw_fence_work.h
index 3a22b287e201..c258a2b2e6f4 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.h
@@ -28,6 +28,7 @@ struct dma_fence_work {
struct i915_sw_fence chain;
struct i915_sw_dma_fence_cb cb;
+ bool immediate;
struct work_struct work;
const struct dma_fence_work_ops *ops;
};
@@ -41,4 +42,10 @@ static inline void dma_fence_work_commit(struct
dma_fence_work *f)
i915_sw_fence_commit(&f->chain);
}
+static inline void dma_fence_work_commit_imm(struct dma_fence_work *f)
+{
+ f->immediate = atomic_read(&f->chain.pending) <= 1;
+ dma_fence_work_commit(f);
+}
+
#endif /* I915_SW_FENCE_WORK_H */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 73dafaafb3e5..880e18f5b71b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -956,7 +956,7 @@ int i915_vma_pin(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
mutex_unlock(&vma->vm->mutex);
err_fence:
if (work)
- dma_fence_work_commit(&work->base);
+ dma_fence_work_commit_imm(&work->base);
if (wakeref)
intel_runtime_pm_put(&vma->vm->i915->runtime_pm, wakeref);
err_pages:
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/15] drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence
Only GPU activity via the GGTT fence is asynchronous, we know that we
control the CPU access directly, so we only need to wait for the GPU to
stop using the fence before we relinquish it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 12
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 3 +++
drivers/gpu/drm/i915/i915_vma.c | 4
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index b6ba68c42546..495ad8b2cab0 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -237,15 +237,18 @@ static int fence_update(struct i915_fence_reg *fence,
GEM_BUG_ON(!i915_gem_object_get_stride(vma->obj) ||
!i915_gem_object_get_tiling(vma->obj));
- ret = i915_vma_sync(vma);
- if (ret)
- return ret;
+ if (INTEL_GEN(fence_to_i915(fence)) < 4) {
+ /* implicit 'unfenced' GPU blits */
+ ret = i915_vma_sync(vma);
+ if (ret)
+ return ret;
+ }
}
old = xchg(&fence->vma, NULL);
if (old) {
/* XXX Ideally we would move the waiting to outside the mutex */
- ret = i915_vma_sync(old);
+ ret = i915_active_wait(&fence->active);
if (ret) {
fence->vma = old;
return ret;
@@ -867,6 +870,7 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
for (i = 0; i < num_fences; i++) {
struct i915_fence_reg *fence = &ggtt->fence_regs[i];
+ i915_active_init(&fence->active, NULL, NULL);
fence->ggtt = ggtt;
fence->id = i;
list_add_tail(&fence->link, &ggtt->fence_list);
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
index 9850f6a85d2a..08c6bb667581 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
@@ -28,6 +28,8 @@
#include
#include
+#include "i915_active.h"
+
struct drm_i915_gem_object;
struct i915_ggtt;
struct i915_vma;
@@ -41,6 +43,7 @@ struct i915_fence_reg {
struct i915_ggtt *ggtt;
struct i915_vma *vma;
atomic_t pin_count;
+ struct i915_active active;
int id;
/**
* Whether the tiling parameters for the currently
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 5b3efb43a8ef..aedbd056fd45 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1214,6 +1214,10 @@ int i915_vma_move_to_active(struct i915_vma *vma,
dma_resv_add_shared_fence(vma->resv, &rq->fence);
obj->write_domain = 0;
}
+
+ if (flags & EXEC_OBJECT_NEEDS_FENCE && vma->fence)
+ i915_active_add_request(&vma->fence->active, rq);
+
obj->read_domains |= I915_GEM_GPU_DOMAINS;
obj->mm.dirty = true;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/15] drm/i915/gem: Drop cached obj->bind_count
We cached the number of vma bound to the object in order to speed up
shrinker decisions. This has been superseded by being more proactive in
removing objects we cannot shrink from the shrinker lists, and so we can
drop the clumsy attempt at atomically counting the bind count and
comparing it to the number of pinned mappings of the object. This will
only get more clumsier with asynchronous binding and unbinding.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 -
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 ---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 2 --
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 18 ++---
.../drm/i915/gem/selftests/i915_gem_mman.c| 4 ---
drivers/gpu/drm/i915/i915_debugfs.c | 7 ++---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 7 -
drivers/gpu/drm/i915/i915_vma.c | 24 -
.../gpu/drm/i915/selftests/i915_gem_evict.c | 26 +--
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 1 -
12 files changed, 13 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 0cc40e77bbd2..af43e82f45c7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -369,7 +369,7 @@ static void i915_gem_object_bump_inactive_ggtt(struct
drm_i915_gem_object *obj)
struct i915_vma *vma;
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
- if (!atomic_read(&obj->bind_count))
+ if (list_empty(&obj->vma.list))
return;
mutex_lock(&i915->ggtt.vm.mutex);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 5da9f9e534b9..3f01cdd1a39b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -206,7 +206,6 @@ static void __i915_gem_free_objects(struct drm_i915_private
*i915,
}
obj->mmo.offsets = RB_ROOT;
- GEM_BUG_ON(atomic_read(&obj->bind_count));
GEM_BUG_ON(obj->userfault_count);
GEM_BUG_ON(!list_empty(&obj->lut_list));
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index a0b10bcd8d8a..54ee658bb168 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -179,9 +179,6 @@ struct drm_i915_gem_object {
#define TILING_MASK (FENCE_MINIMUM_STRIDE - 1)
#define STRIDE_MASK (~TILING_MASK)
- /** Count of VMA actually bound by this object */
- atomic_t bind_count;
-
struct {
/*
* Protects the pages and their use. Do not use directly, but
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 24f4cadea114..5d855fcd5c0f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -199,8 +199,6 @@ int __i915_gem_object_put_pages(struct drm_i915_gem_object
*obj)
if (i915_gem_object_has_pinned_pages(obj))
return -EBUSY;
- GEM_BUG_ON(atomic_read(&obj->bind_count));
-
/* May be called by shrinker from within get_pages() (on another bo) */
mutex_lock(&obj->mm.lock);
if (unlikely(atomic_read(&obj->mm.pages_pin_count))) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index 03e5eb4c99d1..5b65ce738b16 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -26,18 +26,6 @@ static bool can_release_pages(struct drm_i915_gem_object
*obj)
if (!i915_gem_object_is_shrinkable(obj))
return false;
- /*
-* Only report true if by unbinding the object and putting its pages
-* we can actually make forward progress towards freeing physical
-* pages.
-*
-* If the pages are pinned for any other reason than being bound
-* to the GPU, simply unbinding from the GPU is not going to succeed
-* in releasing our pin count on the pages themselves.
-*/
- if (atomic_read(&obj->mm.pages_pin_count) >
atomic_read(&obj->bind_count))
- return false;
-
/*
* We can only return physical pages to the system if we can either
* discard the contents (because the user has marked them as being
@@ -54,6 +42,8 @@ static bool unsafe_drop_pages(struct drm_i915_gem_object *obj,
flags = 0;
if (shrink & I915_SHRINK_ACTIVE)
flags = I915_GEM_OBJECT_UNBIND_ACTIVE;
+ if (!(shrink & I915_SHRINK_BOUND))
+ flags = I915_GEM_OBJECT_UNBIND_TEST;
[Intel-gfx] [PATCH 06/15] drm/i915/gt: Store the fence details on the fence
Make a copy of the object tiling parameters at the point of grabbing the
fence.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 93 +++-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 4 +
2 files changed, 37 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 495ad8b2cab0..1b9adae1a7a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -68,8 +68,7 @@ static struct intel_uncore *fence_to_uncore(struct
i915_fence_reg *fence)
return fence->ggtt->vm.gt->uncore;
}
-static void i965_write_fence_reg(struct i915_fence_reg *fence,
-struct i915_vma *vma)
+static void i965_write_fence_reg(struct i915_fence_reg *fence)
{
i915_reg_t fence_reg_lo, fence_reg_hi;
int fence_pitch_shift;
@@ -87,18 +86,16 @@ static void i965_write_fence_reg(struct i915_fence_reg
*fence,
}
val = 0;
- if (vma) {
- unsigned int stride = i915_gem_object_get_stride(vma->obj);
+ if (fence->tiling) {
+ unsigned int stride = fence->stride;
- GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
- GEM_BUG_ON(!IS_ALIGNED(vma->node.start, I965_FENCE_PAGE));
- GEM_BUG_ON(!IS_ALIGNED(vma->fence_size, I965_FENCE_PAGE));
GEM_BUG_ON(!IS_ALIGNED(stride, 128));
- val = (vma->node.start + vma->fence_size - I965_FENCE_PAGE) <<
32;
- val |= vma->node.start;
+ val = fence->start + fence->size - I965_FENCE_PAGE;
+ val <<= 32;
+ val |= fence->start;
val |= (u64)((stride / 128) - 1) << fence_pitch_shift;
- if (i915_gem_object_get_tiling(vma->obj) == I915_TILING_Y)
+ if (fence->tiling == I915_TILING_Y)
val |= BIT(I965_FENCE_TILING_Y_SHIFT);
val |= I965_FENCE_REG_VALID;
}
@@ -125,21 +122,15 @@ static void i965_write_fence_reg(struct i915_fence_reg
*fence,
}
}
-static void i915_write_fence_reg(struct i915_fence_reg *fence,
-struct i915_vma *vma)
+static void i915_write_fence_reg(struct i915_fence_reg *fence)
{
u32 val;
val = 0;
- if (vma) {
- unsigned int tiling = i915_gem_object_get_tiling(vma->obj);
+ if (fence->tiling) {
+ unsigned int stride = fence->stride;
+ unsigned int tiling = fence->tiling;
bool is_y_tiled = tiling == I915_TILING_Y;
- unsigned int stride = i915_gem_object_get_stride(vma->obj);
-
- GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
- GEM_BUG_ON(vma->node.start & ~I915_FENCE_START_MASK);
- GEM_BUG_ON(!is_power_of_2(vma->fence_size));
- GEM_BUG_ON(!IS_ALIGNED(vma->node.start, vma->fence_size));
if (is_y_tiled && HAS_128_BYTE_Y_TILING(fence_to_i915(fence)))
stride /= 128;
@@ -147,10 +138,10 @@ static void i915_write_fence_reg(struct i915_fence_reg
*fence,
stride /= 512;
GEM_BUG_ON(!is_power_of_2(stride));
- val = vma->node.start;
+ val = fence->start;
if (is_y_tiled)
val |= BIT(I830_FENCE_TILING_Y_SHIFT);
- val |= I915_FENCE_SIZE_BITS(vma->fence_size);
+ val |= I915_FENCE_SIZE_BITS(fence->size);
val |= ilog2(stride) << I830_FENCE_PITCH_SHIFT;
val |= I830_FENCE_REG_VALID;
@@ -165,25 +156,18 @@ static void i915_write_fence_reg(struct i915_fence_reg
*fence,
}
}
-static void i830_write_fence_reg(struct i915_fence_reg *fence,
-struct i915_vma *vma)
+static void i830_write_fence_reg(struct i915_fence_reg *fence)
{
u32 val;
val = 0;
- if (vma) {
- unsigned int stride = i915_gem_object_get_stride(vma->obj);
-
- GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
- GEM_BUG_ON(vma->node.start & ~I830_FENCE_START_MASK);
- GEM_BUG_ON(!is_power_of_2(vma->fence_size));
- GEM_BUG_ON(!is_power_of_2(stride / 128));
- GEM_BUG_ON(!IS_ALIGNED(vma->node.start, vma->fence_size));
+ if (fence->tiling) {
+ unsigned int stride = fence->stride;
- val = vma->node.start;
- if (i915_gem_object_get_tiling(vma->obj) == I915_TILING_Y)
+ val = fence->start;
+ if (fence->tiling == I915_TILING_Y)
val |= BIT(I830_FENCE_TILING_Y_SHIFT);
- val |= I830_FENCE_SIZE_BITS(vma->fence_size);
+ val |= I830_FENCE_SIZE_BITS(fence->size);
val |= ilog2(stride / 1
[Intel-gfx] [PATCH 11/15] drm/i915: Export a preallocate variant of i915_active_acquire()
Sometimes we have to be very careful not to allocate underneath a mutex
(or spinlock) and yet still want to track activity. Enter
i915_active_acquire_for_context(). This raises the activity counter on
i915_active prior to use and ensures that the fence-tree contains a slot
for the context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 107 ++---
drivers/gpu/drm/i915/i915_active.h | 5 ++
2 files changed, 103 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index c4048628188a..6bb09f3020e2 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -217,11 +217,10 @@ excl_retire(struct dma_fence *fence, struct dma_fence_cb
*cb)
}
static struct i915_active_fence *
-active_instance(struct i915_active *ref, struct intel_timeline *tl)
+active_instance(struct i915_active *ref, u64 idx)
{
struct active_node *node, *prealloc;
struct rb_node **p, *parent;
- u64 idx = tl->fence_context;
/*
* We track the most recently used timeline to skip a rbtree search
@@ -367,7 +366,7 @@ int i915_active_ref(struct i915_active *ref,
if (err)
return err;
- active = active_instance(ref, tl);
+ active = active_instance(ref, tl->fence_context);
if (!active) {
err = -ENOMEM;
goto out;
@@ -384,32 +383,104 @@ int i915_active_ref(struct i915_active *ref,
atomic_dec(&ref->count);
}
if (!__i915_active_fence_set(active, fence))
- atomic_inc(&ref->count);
+ __i915_active_acquire(ref);
out:
i915_active_release(ref);
return err;
}
-struct dma_fence *
-i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f)
+static struct dma_fence *
+__i915_active_set_fence(struct i915_active *ref,
+ struct i915_active_fence *active,
+ struct dma_fence *fence)
{
struct dma_fence *prev;
/* We expect the caller to manage the exclusive timeline ordering */
GEM_BUG_ON(i915_active_is_idle(ref));
+ if (is_barrier(active)) { /* proto-node used by our idle barrier */
+ /*
+* This request is on the kernel_context timeline, and so
+* we can use it to substitute for the pending idle-barrer
+* request that we want to emit on the kernel_context.
+*/
+ __active_del_barrier(ref, node_from_active(active));
+ RCU_INIT_POINTER(active->fence, NULL);
+ atomic_dec(&ref->count);
+ }
+
rcu_read_lock();
- prev = __i915_active_fence_set(&ref->excl, f);
+ prev = __i915_active_fence_set(active, fence);
if (prev)
prev = dma_fence_get_rcu(prev);
else
- atomic_inc(&ref->count);
+ __i915_active_acquire(ref);
rcu_read_unlock();
return prev;
}
+static struct i915_active_fence *
+__active_lookup(struct i915_active *ref, u64 idx)
+{
+ struct active_node *node;
+ struct rb_node *p;
+
+ /* Like active_instance() but with no malloc */
+
+ node = READ_ONCE(ref->cache);
+ if (node && node->timeline == idx)
+ return &node->base;
+
+ spin_lock_irq(&ref->tree_lock);
+ GEM_BUG_ON(i915_active_is_idle(ref));
+
+ p = ref->tree.rb_node;
+ while (p) {
+ node = rb_entry(p, struct active_node, node);
+ if (node->timeline == idx) {
+ ref->cache = node;
+ spin_unlock_irq(&ref->tree_lock);
+ return &node->base;
+ }
+
+ if (node->timeline < idx)
+ p = p->rb_right;
+ else
+ p = p->rb_left;
+ }
+
+ spin_unlock_irq(&ref->tree_lock);
+
+ return NULL;
+}
+
+struct dma_fence *
+__i915_active_ref(struct i915_active *ref, u64 idx, struct dma_fence *fence)
+{
+ struct dma_fence *prev = ERR_PTR(-ENOENT);
+ struct i915_active_fence *active;
+
+ if (!i915_active_acquire_if_busy(ref))
+ return ERR_PTR(-EINVAL);
+
+ active = __active_lookup(ref, idx);
+ if (active)
+ prev = __i915_active_set_fence(ref, active, fence);
+
+ i915_active_release(ref);
+ return prev;
+}
+
+struct dma_fence *
+i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f)
+{
+ /* We expect the caller to manage the exclusive timeline ordering */
+ return __i915_active_set_fence(ref, &ref->excl, f);
+}
+
bool i915_active_acquire_if_busy(struct i915_active *ref)
{
debug_active_assert(ref);
@@ -443,6 +514,24 @@ int i915_active_acquire(struct i915_active *ref)
return err;
}
+int i915_active_acquire_for_context(struct
[Intel-gfx] [PATCH 07/15] drm/i915/gt: Make fence revocation unequivocal
If we must revoke the fence because the VMA is no longer present, or
because the fence no longer applies, ensure that we do and convert it
into an error if we try but cannot.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 21 +++-
drivers/gpu/drm/i915/i915_gem.c | 12 +--
drivers/gpu/drm/i915/i915_vma.c | 4 +---
drivers/gpu/drm/i915/i915_vma.h | 2 +-
4 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 1b9adae1a7a8..97659a1249fd 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -291,23 +291,26 @@ static int fence_update(struct i915_fence_reg *fence,
*
* This function force-removes any fence from the given object, which is useful
* if the kernel wants to do untiled GTT access.
- *
- * Returns:
- *
- * 0 on success, negative error code on failure.
*/
-int i915_vma_revoke_fence(struct i915_vma *vma)
+void i915_vma_revoke_fence(struct i915_vma *vma)
{
struct i915_fence_reg *fence = vma->fence;
+ intel_wakeref_t wakeref;
lockdep_assert_held(&vma->vm->mutex);
if (!fence)
- return 0;
+ return;
- if (atomic_read(&fence->pin_count))
- return -EBUSY;
+ GEM_BUG_ON(fence->vma != vma);
+ GEM_BUG_ON(!i915_active_is_idle(&fence->active));
+ GEM_BUG_ON(atomic_read(&fence->pin_count));
+
+ fence->tiling = 0;
+ WRITE_ONCE(fence->vma, NULL);
+ vma->fence = NULL;
- return fence_update(fence, NULL);
+ with_intel_runtime_pm_if_in_use(fence_to_uncore(fence)->rpm, wakeref)
+ fence_write(fence);
}
static struct i915_fence_reg *fence_find(struct i915_ggtt *ggtt)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 762b50b08d73..b0836fc47ae6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -993,18 +993,16 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
return ERR_PTR(ret);
}
+ ret = i915_vma_pin(vma, size, alignment, flags | PIN_GLOBAL);
+ if (ret)
+ return ERR_PTR(ret);
+
if (vma->fence && !i915_gem_object_is_tiled(obj)) {
mutex_lock(&ggtt->vm.mutex);
- ret = i915_vma_revoke_fence(vma);
+ i915_vma_revoke_fence(vma);
mutex_unlock(&ggtt->vm.mutex);
- if (ret)
- return ERR_PTR(ret);
}
- ret = i915_vma_pin(vma, size, alignment, flags | PIN_GLOBAL);
- if (ret)
- return ERR_PTR(ret);
-
ret = i915_vma_wait_for_bind(vma);
if (ret) {
i915_vma_unpin(vma);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index aedbd056fd45..df197b07ac99 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1280,9 +1280,7 @@ int __i915_vma_unbind(struct i915_vma *vma)
i915_vma_flush_writes(vma);
/* release the fence reg _after_ flushing */
- ret = i915_vma_revoke_fence(vma);
- if (ret)
- return ret;
+ i915_vma_revoke_fence(vma);
/* Force a pagefault for domain tracking on next user access */
i915_vma_revoke_mmap(vma);
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index b958ad07f212..8ad1daabcd58 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -326,7 +326,7 @@ static inline struct page *i915_vma_first_page(struct
i915_vma *vma)
* True if the vma has a fence, false otherwise.
*/
int __must_check i915_vma_pin_fence(struct i915_vma *vma);
-int __must_check i915_vma_revoke_fence(struct i915_vma *vma);
+void i915_vma_revoke_fence(struct i915_vma *vma);
int __i915_vma_pin_fence(struct i915_vma *vma);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/15] drm/i915/gem: Asynchronous GTT unbinding
It is reasonably common for userspace (even modern drivers like iris) to
reuse an active address for a new buffer. This would cause the
application to stall under its mutex (originally struct_mutex) until the
old batches were idle and it could synchronously remove the stale PTE.
However, we can queue up a job that waits on the signal for the old
nodes to complete and upon those signals, remove the old nodes replacing
them with the new ones for the batch. This is still CPU driven, but in
theory we can do the GTT patching from the GPU. The job itself has a
completion signal allowing the execbuf to wait upon the rebinding, and
also other observers to coordinate with the common VM activity.
Letting userspace queue up more work, lets it do more stuff without
blocking other clients. In turn, we take care not to let it too much
concurrent work, creating a small number of queues for each context to
limit the number of concurrent tasks.
The implementation relies on only scheduling one unbind operation per
vma as we use the unbound vma->node location to track the stale PTE.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1402
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Cc: Andi Shyti
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 673 --
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 1 +
drivers/gpu/drm/i915/gt/intel_ggtt.c | 3 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 4 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 3 +-
drivers/gpu/drm/i915/i915_vma.c | 134 ++--
drivers/gpu/drm/i915/i915_vma.h | 17 +
8 files changed, 701 insertions(+), 136 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 50b2000a72de..7fb47ff185a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -18,6 +18,7 @@
#include "gt/intel_engine_pool.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
+#include "gt/intel_gt_requests.h"
#include "gt/intel_ring.h"
#include "i915_drv.h"
@@ -31,6 +32,9 @@ struct eb_vma {
struct i915_vma *vma;
unsigned int flags;
+ struct drm_mm_node hole;
+ unsigned int bind_flags;
+
/** This vma's place in the execbuf reservation list */
struct drm_i915_gem_exec_object2 *exec;
struct list_head bind_link;
@@ -57,7 +61,8 @@ enum {
#define __EXEC_OBJECT_HAS_FENCEBIT(30)
#define __EXEC_OBJECT_NEEDS_MAPBIT(29)
#define __EXEC_OBJECT_NEEDS_BIAS BIT(28)
-#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 28) /* all of the above */
+#define __EXEC_OBJECT_HAS_PAGESBIT(27)
+#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 27) /* all of the above */
#define __EXEC_HAS_RELOC BIT(31)
#define __EXEC_INTERNAL_FLAGS (~0u << 31)
@@ -314,6 +319,12 @@ static struct eb_vma_array *eb_vma_array_create(unsigned
int count)
return arr;
}
+static struct eb_vma_array *eb_vma_array_get(struct eb_vma_array *arr)
+{
+ kref_get(&arr->kref);
+ return arr;
+}
+
static inline void eb_unreserve_vma(struct eb_vma *ev)
{
struct i915_vma *vma = ev->vma;
@@ -324,8 +335,12 @@ static inline void eb_unreserve_vma(struct eb_vma *ev)
if (ev->flags & __EXEC_OBJECT_HAS_PIN)
__i915_vma_unpin(vma);
+ if (ev->flags & __EXEC_OBJECT_HAS_PAGES)
+ i915_vma_put_pages(vma);
+
ev->flags &= ~(__EXEC_OBJECT_HAS_PIN |
- __EXEC_OBJECT_HAS_FENCE);
+ __EXEC_OBJECT_HAS_FENCE |
+ __EXEC_OBJECT_HAS_PAGES);
}
static void eb_vma_array_destroy(struct kref *kref)
@@ -529,6 +544,7 @@ eb_add_vma(struct i915_execbuffer *eb,
GEM_BUG_ON(i915_vma_is_closed(vma));
+ memset(&ev->hole, 0, sizeof(ev->hole));
ev->vma = i915_vma_get(vma);
ev->exec = entry;
ev->flags = entry->flags;
@@ -592,64 +608,545 @@ static inline int use_cpu_reloc(const struct reloc_cache
*cache,
obj->cache_level != I915_CACHE_NONE);
}
-static int eb_reserve_vma(const struct i915_execbuffer *eb,
- struct eb_vma *ev,
- u64 pin_flags)
+struct eb_vm_work {
+ struct dma_fence_work base;
+ struct list_head unbound;
+ struct eb_vma_array *array;
+ struct i915_address_space *vm;
+ struct list_head eviction_list;
+ u64 *p_flags;
+ u64 active;
+};
+
+static inline u64 node_end(const struct drm_mm_node *node)
+{
+ return node->start + node->size;
+}
+
+static int set_bind_fence(struct i915_vma *vma, struct eb_vm_work *work)
+{
+ struct dma_fence *prev;
+ int err = 0;
+
+ prev = i915_active_set_exclusive(&vma->active, &work->base.dma);
+ if (unlikely(prev)) {
+ err = i915_sw_fen
[Intel-gfx] [PATCH 13/15] drm/i915/gem: Separate the ww_mutex walker into its own list
In preparation for making eb_vma bigger and heavy to run inn parallel,
we need to stop apply an in-place swap() to reorder around ww_mutex
deadlocks. Keep the array intact and reorder the locks using a dedicated
list.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 48 +++
drivers/gpu/drm/i915/i915_utils.h | 6 +++
2 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3d0d0baa0ec..50b2000a72de 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -35,6 +35,7 @@ struct eb_vma {
struct drm_i915_gem_exec_object2 *exec;
struct list_head bind_link;
struct list_head reloc_link;
+ struct list_head lock_link;
struct hlist_node node;
u32 handle;
@@ -253,6 +254,8 @@ struct i915_execbuffer {
/** list of vma that have execobj.relocation_count */
struct list_head relocs;
+ struct list_head lock;
+
/**
* Track the most recently used object for relocations, as we
* frequently have to perform multiple relocations within the same
@@ -396,6 +399,10 @@ static int eb_create(struct i915_execbuffer *eb)
eb->lut_size = -eb->buffer_count;
}
+ INIT_LIST_HEAD(&eb->relocs);
+ INIT_LIST_HEAD(&eb->unbound);
+ INIT_LIST_HEAD(&eb->lock);
+
return 0;
}
@@ -564,6 +571,8 @@ eb_add_vma(struct i915_execbuffer *eb,
eb_unreserve_vma(ev);
list_add_tail(&ev->bind_link, &eb->unbound);
}
+
+ list_add_tail(&ev->lock_link, &eb->lock);
}
static inline int use_cpu_reloc(const struct reloc_cache *cache,
@@ -779,9 +788,6 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
if (unlikely(i915_gem_context_is_closed(eb->gem_context)))
return -ENOENT;
- INIT_LIST_HEAD(&eb->relocs);
- INIT_LIST_HEAD(&eb->unbound);
-
batch = eb_batch_index(eb);
for (i = 0; i < eb->buffer_count; i++) {
@@ -1546,38 +1552,39 @@ static int eb_relocate(struct i915_execbuffer *eb)
static int eb_move_to_gpu(struct i915_execbuffer *eb)
{
- const unsigned int count = eb->buffer_count;
struct ww_acquire_ctx acquire;
- unsigned int i;
+ struct eb_vma *ev;
int err = 0;
ww_acquire_init(&acquire, &reservation_ww_class);
- for (i = 0; i < count; i++) {
- struct eb_vma *ev = &eb->vma[i];
+ list_for_each_entry(ev, &eb->lock, lock_link) {
struct i915_vma *vma = ev->vma;
err = ww_mutex_lock_interruptible(&vma->resv->lock, &acquire);
if (err == -EDEADLK) {
- GEM_BUG_ON(i == 0);
- do {
- int j = i - 1;
+ struct eb_vma *unlock = ev, *en;
- ww_mutex_unlock(&eb->vma[j].vma->resv->lock);
-
- swap(eb->vma[i], eb->vma[j]);
- } while (--i);
+ list_for_each_entry_safe_continue_reverse(unlock, en,
&eb->lock, lock_link) {
+ ww_mutex_unlock(&unlock->vma->resv->lock);
+ list_move_tail(&unlock->lock_link, &eb->lock);
+ }
+ GEM_BUG_ON(!list_is_first(&ev->lock_link, &eb->lock));
err = ww_mutex_lock_slow_interruptible(&vma->resv->lock,
&acquire);
}
- if (err)
- break;
+ if (err) {
+ list_for_each_entry_continue_reverse(ev, &eb->lock,
lock_link)
+ ww_mutex_unlock(&ev->vma->resv->lock);
+
+ ww_acquire_fini(&acquire);
+ goto err_skip;
+ }
}
ww_acquire_done(&acquire);
- while (i--) {
- struct eb_vma *ev = &eb->vma[i];
+ list_for_each_entry(ev, &eb->lock, lock_link) {
struct i915_vma *vma = ev->vma;
unsigned int flags = ev->flags;
struct drm_i915_gem_object *obj = vma->obj;
@@ -1878,9 +1885,10 @@ static int eb_parse(struct i915_execbuffer *eb)
if (err)
goto err_trampoline;
- eb->vma[eb->buffer_count].vma = i915_vma_get(shadow);
- eb->vma[eb->buffer_count].flags = __EXEC_OBJECT_HAS_PIN;
eb->batch = &eb->vma[eb->buffer_count++];
+ eb->batch->vma = i915_vma_get(shadow);
+ eb->batch->flags = __EXEC_OBJECT_HAS_PIN;
+ list_add_tail(&eb->batch->lock_link, &eb->lock);
eb->vma[eb->buffer_count].vma = NULL;
eb->trampoline = trampoline;
diff --git a/drivers/gpu/drm/i915/i915_ut
[Intel-gfx] [PATCH 01/15] drm/i915: Move GGTT fence registers under gt/
Since the fence registers control HW detiling through the GGTT
aperture, make them a part of the intel_ggtt under gt/
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
.../intel_ggtt_fencing.c} | 27 +++
.../intel_ggtt_fencing.h} | 9 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
drivers/gpu/drm/i915/gvt/aperture_gm.c| 2 +-
drivers/gpu/drm/i915/i915_drv.c | 6 ++---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_vma.h | 1 -
drivers/gpu/drm/i915/selftests/i915_gem.c | 2 +-
12 files changed, 24 insertions(+), 34 deletions(-)
rename drivers/gpu/drm/i915/{i915_gem_fence_reg.c => gt/intel_ggtt_fencing.c}
(97%)
rename drivers/gpu/drm/i915/{i915_gem_fence_reg.h => gt/intel_ggtt_fencing.h}
(92%)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9f887a86e555..1b2ed963179c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -92,6 +92,7 @@ gt-y += \
gt/intel_engine_pool.o \
gt/intel_engine_user.o \
gt/intel_ggtt.o \
+ gt/intel_ggtt_fencing.o \
gt/intel_gt.o \
gt/intel_gt_irq.o \
gt/intel_gt_pm.o \
@@ -153,7 +154,6 @@ i915-y += \
i915_buddy.o \
i915_cmd_parser.o \
i915_gem_evict.o \
- i915_gem_fence_reg.o \
i915_gem_gtt.o \
i915_gem.o \
i915_globals.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index aed498a0d032..a7b72fa569a7 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -65,7 +65,7 @@ static int ggtt_init_hw(struct i915_ggtt *ggtt)
ggtt->mappable_end);
}
- i915_ggtt_init_fences(ggtt);
+ intel_ggtt_init_fences(ggtt);
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
similarity index 97%
rename from drivers/gpu/drm/i915/i915_gem_fence_reg.c
rename to drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index d152b648c73c..94af75673a58 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -233,16 +233,9 @@ static int fence_update(struct i915_fence_reg *fence,
int ret;
if (vma) {
- if (!i915_vma_is_map_and_fenceable(vma))
- return -EINVAL;
-
- if (drm_WARN(&uncore->i915->drm,
-!i915_gem_object_get_stride(vma->obj) ||
-!i915_gem_object_get_tiling(vma->obj),
-"bogus fence setup with stride: 0x%x, tiling mode:
%i\n",
-i915_gem_object_get_stride(vma->obj),
-i915_gem_object_get_tiling(vma->obj)))
- return -EINVAL;
+ GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
+ GEM_BUG_ON(!i915_gem_object_get_stride(vma->obj) ||
+ !i915_gem_object_get_tiling(vma->obj));
ret = i915_vma_sync(vma);
if (ret)
@@ -276,7 +269,7 @@ static int fence_update(struct i915_fence_reg *fence,
/*
* We only need to update the register itself if the device is awake.
* If the device is currently powered down, we will defer the write
-* to the runtime resume, see i915_gem_restore_fences().
+* to the runtime resume, see intel_ggtt_restore_fences().
*
* This only works for removing the fence register, on acquisition
* the caller must hold the rpm wakeref. The fence register must
@@ -487,14 +480,14 @@ void i915_unreserve_fence(struct i915_fence_reg *fence)
}
/**
- * i915_gem_restore_fences - restore fence state
+ * intel_ggtt_restore_fences - restore fence state
* @ggtt: Global GTT
*
* Restore the hw fence state to match the software tracking again, to be
called
* after a gpu reset and on resume. Note that on runtime suspend we only cancel
* the fences, to be reacquired by the user later.
*/
-void i915_gem_restore_fences(struct i915_ggtt *ggtt)
+void intel_ggtt_restore_fences(struct i915_ggtt *ggtt)
{
int i;
@@ -746,7 +739,7 @@ static void detect_bit_6_swizzle(struct i915_ggtt *ggtt)
* bit 17 of its physical address and therefore being interpreted differently
* by the GPU.
*/
-static void i915_gem_swizzle_page(struct page *page)
+static void swizzle_page(struct page *page)
{
char temp[64];
char *vaddr;
@@ -791,7 +784,7 @@ i915_gem_object_do_bit_17_swizzle(struct
drm_i915_gem_object
[Intel-gfx] [PATCH 12/15] drm/i915/gem: Split eb_vma into its own allocation
Use a separate array allocation for the execbuf vma, so that we can
track their lifetime independently from the copy of the user arguments.
With luck, this has a secondary benefit of splitting the malloc size to
within reason and avoid vmalloc.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 132 ++
1 file changed, 74 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index f647f98a9bc6..d3d0d0baa0ec 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -40,6 +40,11 @@ struct eb_vma {
u32 handle;
};
+struct eb_vma_array {
+ struct kref kref;
+ struct eb_vma vma[];
+};
+
enum {
FORCE_CPU_RELOC = 1,
FORCE_GTT_RELOC,
@@ -52,7 +57,6 @@ enum {
#define __EXEC_OBJECT_NEEDS_MAPBIT(29)
#define __EXEC_OBJECT_NEEDS_BIAS BIT(28)
#define __EXEC_OBJECT_INTERNAL_FLAGS (~0u << 28) /* all of the above */
-#define __EXEC_OBJECT_RESERVED (__EXEC_OBJECT_HAS_PIN |
__EXEC_OBJECT_HAS_FENCE)
#define __EXEC_HAS_RELOC BIT(31)
#define __EXEC_INTERNAL_FLAGS (~0u << 31)
@@ -283,6 +287,7 @@ struct i915_execbuffer {
*/
int lut_size;
struct hlist_head *buckets; /** ht for relocation handles */
+ struct eb_vma_array *array;
};
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
@@ -292,8 +297,62 @@ static inline bool eb_use_cmdparser(const struct
i915_execbuffer *eb)
eb->args->batch_len);
}
+static struct eb_vma_array *eb_vma_array_create(unsigned int count)
+{
+ struct eb_vma_array *arr;
+
+ arr = kvmalloc(struct_size(arr, vma, count), GFP_KERNEL | __GFP_NOWARN);
+ if (!arr)
+ return NULL;
+
+ kref_init(&arr->kref);
+ arr->vma[0].vma = NULL;
+
+ return arr;
+}
+
+static inline void eb_unreserve_vma(struct eb_vma *ev)
+{
+ struct i915_vma *vma = ev->vma;
+
+ if (unlikely(ev->flags & __EXEC_OBJECT_HAS_FENCE))
+ __i915_vma_unpin_fence(vma);
+
+ if (ev->flags & __EXEC_OBJECT_HAS_PIN)
+ __i915_vma_unpin(vma);
+
+ ev->flags &= ~(__EXEC_OBJECT_HAS_PIN |
+ __EXEC_OBJECT_HAS_FENCE);
+}
+
+static void eb_vma_array_destroy(struct kref *kref)
+{
+ struct eb_vma_array *arr = container_of(kref, typeof(*arr), kref);
+ struct eb_vma *ev = arr->vma;
+
+ while (ev->vma) {
+ eb_unreserve_vma(ev);
+ i915_vma_put(ev->vma);
+ ev++;
+ }
+
+ kvfree(arr);
+}
+
+static void eb_vma_array_put(struct eb_vma_array *arr)
+{
+ kref_put(&arr->kref, eb_vma_array_destroy);
+}
+
static int eb_create(struct i915_execbuffer *eb)
{
+ /* Allocate an extra slot for use by the command parser + sentinel */
+ eb->array = eb_vma_array_create(eb->buffer_count + 2);
+ if (!eb->array)
+ return -ENOMEM;
+
+ eb->vma = eb->array->vma;
+
if (!(eb->args->flags & I915_EXEC_HANDLE_LUT)) {
unsigned int size = 1 + ilog2(eb->buffer_count);
@@ -327,8 +386,10 @@ static int eb_create(struct i915_execbuffer *eb)
break;
} while (--size);
- if (unlikely(!size))
+ if (unlikely(!size)) {
+ eb_vma_array_put(eb->array);
return -ENOMEM;
+ }
eb->lut_size = size;
} else {
@@ -402,26 +463,6 @@ eb_pin_vma(struct i915_execbuffer *eb,
return !eb_vma_misplaced(entry, vma, ev->flags);
}
-static inline void __eb_unreserve_vma(struct i915_vma *vma, unsigned int flags)
-{
- GEM_BUG_ON(!(flags & __EXEC_OBJECT_HAS_PIN));
-
- if (unlikely(flags & __EXEC_OBJECT_HAS_FENCE))
- __i915_vma_unpin_fence(vma);
-
- __i915_vma_unpin(vma);
-}
-
-static inline void
-eb_unreserve_vma(struct eb_vma *ev)
-{
- if (!(ev->flags & __EXEC_OBJECT_HAS_PIN))
- return;
-
- __eb_unreserve_vma(ev->vma, ev->flags);
- ev->flags &= ~__EXEC_OBJECT_RESERVED;
-}
-
static int
eb_validate_vma(struct i915_execbuffer *eb,
struct drm_i915_gem_exec_object2 *entry,
@@ -794,6 +835,7 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
eb_add_vma(eb, i, batch, vma);
}
+ eb->vma[i].vma = NULL;
return 0;
err_obj:
@@ -823,31 +865,13 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned
long handle)
}
}
-static void eb_release_vmas(const struct i915_execbuffer *eb)
-{
- const unsigned int count = eb->buffer_count;
- unsigned int i;
-
- for (i = 0; i < count; i++) {
- struct eb_vma *ev = &eb->vma[i];
- struct i915_vma *vma = ev->vma;
-
- if (!vma)
- break;
-
[Intel-gfx] [PATCH 04/15] drm/i915/gt: Allocate i915_fence_reg array
Since the number of fence regs can vary dramactically between platforms,
allocate the array on demand so we don't waste as much space.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 6 --
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 10 ++
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 1 +
drivers/gpu/drm/i915/gt/intel_gtt.h | 5 +++--
drivers/gpu/drm/i915/i915_vma.h | 1 +
5 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index bde4f64a41f7..8fcf14372d7a 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -698,11 +698,13 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt)
*/
void i915_ggtt_driver_release(struct drm_i915_private *i915)
{
+ struct i915_ggtt *ggtt = &i915->ggtt;
struct pagevec *pvec;
- fini_aliasing_ppgtt(&i915->ggtt);
+ fini_aliasing_ppgtt(ggtt);
- ggtt_cleanup_hw(&i915->ggtt);
+ intel_ggtt_fini_fences(ggtt);
+ ggtt_cleanup_hw(ggtt);
pvec = &i915->mm.wc_stash.pvec;
if (pvec->nr) {
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index 94af75673a58..b6ba68c42546 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -857,6 +857,11 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
if (intel_vgpu_active(i915))
num_fences = intel_uncore_read(uncore,
vgtif_reg(avail_rs.fence_num));
+ ggtt->fence_regs = kcalloc(num_fences,
+ sizeof(*ggtt->fence_regs),
+ GFP_KERNEL);
+ if (!ggtt->fence_regs)
+ num_fences = 0;
/* Initialize fence registers to zero */
for (i = 0; i < num_fences; i++) {
@@ -871,6 +876,11 @@ void intel_ggtt_init_fences(struct i915_ggtt *ggtt)
intel_ggtt_restore_fences(ggtt);
}
+void intel_ggtt_fini_fences(struct i915_ggtt *ggtt)
+{
+ kfree(ggtt->fence_regs);
+}
+
void intel_gt_init_swizzling(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
index 3b3eb5bf1b75..9850f6a85d2a 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h
@@ -64,6 +64,7 @@ void i915_gem_object_save_bit_17_swizzle(struct
drm_i915_gem_object *obj,
struct sg_table *pages);
void intel_ggtt_init_fences(struct i915_ggtt *ggtt);
+void intel_ggtt_fini_fences(struct i915_ggtt *ggtt);
void intel_gt_init_swizzling(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index ce6ff9d3a350..d93ebdf3fa0e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -26,7 +26,6 @@
#include
#include "gt/intel_reset.h"
-#include "gt/intel_ggtt_fencing.h"
#include "i915_selftest.h"
#include "i915_vma_types.h"
@@ -135,6 +134,8 @@ typedef u64 gen8_pte_t;
#define GEN8_PDE_IPS_64K BIT(11)
#define GEN8_PDE_PS_2M BIT(7)
+struct i915_fence_reg;
+
#define for_each_sgt_daddr(__dp, __iter, __sgt) \
__for_each_sgt_daddr(__dp, __iter, __sgt, I915_GTT_PAGE_SIZE)
@@ -333,7 +334,7 @@ struct i915_ggtt {
u32 pin_bias;
unsigned int num_fences;
- struct i915_fence_reg fence_regs[I915_MAX_NUM_FENCES];
+ struct i915_fence_reg *fence_regs;
struct list_head fence_list;
/**
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 2764c277326f..b958ad07f212 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -30,6 +30,7 @@
#include
+#include "gt/intel_ggtt_fencing.h"
#include "gem/i915_gem_object.h"
#include "i915_gem_gtt.h"
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/15] drm/i915: Remove manual save/resume of fence register state
Since we always reload the fence register state on runtime resume,
having it explicitly in the S0ix resume code is redundant. Indeed, it
is not even being used!
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ddd5b40cbbbc..a7ea1d855359 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -539,7 +539,6 @@ struct i915_suspend_saved_registers {
u32 saveSWF0[16];
u32 saveSWF1[16];
u32 saveSWF3[3];
- u64 saveFENCE[I915_MAX_NUM_FENCES];
u32 savePCH_PORT_HOTPLUG;
u16 saveGCDGMBUS;
};
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/15] drm/i915/gt: Pull restoration of GGTT fences underneath the GT
Make the GT responsible for restoring its fence when it wakes up from
suspend.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 ++
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 +
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/i915_gem.c | 1 -
drivers/gpu/drm/i915/selftests/i915_gem.c | 2 --
5 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index a7b72fa569a7..bde4f64a41f7 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1195,6 +1195,8 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
if (INTEL_GEN(ggtt->vm.i915) >= 8)
setup_private_pat(ggtt->vm.gt->uncore);
+
+ intel_ggtt_restore_fences(ggtt);
}
static struct scatterlist *
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 8b653c0f5e5f..2e40400d1ecd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -324,6 +324,7 @@ int intel_gt_runtime_resume(struct intel_gt *gt)
{
GT_TRACE(gt, "\n");
intel_gt_init_swizzling(gt);
+ intel_ggtt_restore_fences(gt->ggtt);
return intel_uc_runtime_resume(>->uc);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 832140f4ea3d..48ba37e35bea 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1288,7 +1288,6 @@ static int i915_drm_resume(struct drm_device *dev)
drm_err(&dev_priv->drm, "failed to re-enable GGTT\n");
i915_ggtt_resume(&dev_priv->ggtt);
- intel_ggtt_restore_fences(&dev_priv->ggtt);
intel_csr_ucode_resume(dev_priv);
@@ -1606,8 +1605,6 @@ static int intel_runtime_suspend(struct device *kdev)
intel_gt_runtime_resume(&dev_priv->gt);
- intel_ggtt_restore_fences(&dev_priv->ggtt);
-
enable_rpm_wakeref_asserts(rpm);
return ret;
@@ -1687,7 +1684,6 @@ static int intel_runtime_resume(struct device *kdev)
* we can do is to hope that things will still work (and disable RPM).
*/
intel_gt_runtime_resume(&dev_priv->gt);
- intel_ggtt_restore_fences(&dev_priv->ggtt);
/*
* On VLV/CHV display interrupts are part of the display
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2c53be0bd9fd..762b50b08d73 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1156,7 +1156,6 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
/* Minimal basic recovery for KMS */
ret = i915_ggtt_enable_hw(dev_priv);
i915_ggtt_resume(&dev_priv->ggtt);
- intel_ggtt_restore_fences(&dev_priv->ggtt);
intel_init_clock_gating(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem.c
b/drivers/gpu/drm/i915/selftests/i915_gem.c
index 7ea517a21e0b..88d400b9df88 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem.c
@@ -125,8 +125,6 @@ static void pm_resume(struct drm_i915_private *i915)
*/
with_intel_runtime_pm(&i915->runtime_pm, wakeref) {
i915_ggtt_resume(&i915->ggtt);
- intel_ggtt_restore_fences(&i915->ggtt);
-
i915_gem_resume(i915);
}
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/2] intel-ci: Tweak blacklist for very long running stability tests
On Mon, Mar 16, 2020 at 10:54:26AM +, Chris Wilson wrote:
> To exclude yynamic tests just use their group name?
Yes, the igt_subtest_with_dynamic("somename") macro creates a subtest
entry point just like igt_subtest, for the purposes of testlists and
blacklists.
>
> Signed-off-by: Chris Wilson
> Cc: Petri Latvala
> ---
> tests/intel-ci/blacklist.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
> index 948b47569..184c23c37 100644
> --- a/tests/intel-ci/blacklist.txt
> +++ b/tests/intel-ci/blacklist.txt
> @@ -60,9 +60,9 @@ igt@gem_sync@(?!.*basic).*
> igt@gem_tiled_swapping@(?!non-threaded).*
> igt@gem_userptr_blits@(major|minor|forked|mlocked|swapping).*
> igt@gem_wait@.*hang.*
> -igt@sysfs_heartbeat_timeout@long.*
> -igt@sysfs_preemption_timeout@off.*
> -igt@sysfs_timeslice_duration@off.*
> +igt@sysfs_heartbeat_timeout@long
> +igt@sysfs_preemption_timeout@off
> +igt@sysfs_timeslice_duration@off
Please fix the test names along with this change. I spent some minutes
trying to figure out what changes, before I realized
sysfs_heartbeat_timeout doesn't exist. It's
sysfs_heartbeat_interval. sysfs_preemption_timeout is
sysfs_preempt_timeout.
Ways to doublecheck:
igt_runner -L -t igt@sysfs_heartbeat_timeout@long build/tests
igt_runner -L -b tests/intel-ci/blacklist.txt build/tests
https://patchwork.freedesktop.org/series/74263/
Acked-by: Petri Latvala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Fixes that failed to apply to v5.6-rc3
On Thu, 27 Feb 2020, Jani Nikula wrote:
> Hi all -
>
> The following commits have been marked as Cc: stable or fixing something
> in v5.6-rc3 or earlier, but failed to cherry-pick to
> drm-intel-fixes. Please see if they are worth backporting, and please do
> so if they are.
New ones for -rc6:
003d8b9143a6 ("drm/i915/gem: Only call eb_lookup_vma once during execbuf ioctl")
520f8350364d ("drm/i915: properly sanity check batch_start_offset")
07bcfd1291de ("drm/i915/gen12: Disable preemption timeout")
fb899dd8ea9c ("drm/i915: Apply Wa_1406680159:icl,ehl as an engine workaround")
BR,
Jani.
> This one was fine to cherry-pick, but caused problematic (for me!)
> conflicts in drm-tip rebuild:
> 42fb60de3129 ("drm/i915/gem: Don't leak non-persistent requests on changing
> engines")
>
> BR,
> Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 1/3] drm/i915: Get active pending request for given context
This patch gives us the active pending request count which is yet
to be submitted to the GPU.
V2:
* Change 64-bit to atomic for request count. (Tvrtko Ursulin)
V3:
* Remove mutex for request count.
* Rebase.
* Fixes hitting underflow for predictive request. (Tvrtko Ursulin)
V4:
* Rebase.
V5:
* Rebase.
V6:
* Rebase.
V7:
* Rebase.
* Add GEM_BUG_ON for req_cnt.
Cc: Vipin Anand
Signed-off-by: Ankit Navik
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 5 +
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
4 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 026999b34abd..d0ff999429ff 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -879,6 +879,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
unsigned int flags)
}
trace_i915_context_create(ctx);
+ atomic_set(&ctx->req_cnt, 0);
return ctx;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 28760bd03265..a9ba13f8865e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -171,6 +171,11 @@ struct i915_gem_context {
*/
struct radix_tree_root handles_vma;
+ /** req_cnt: tracks the pending commands, based on which we decide to
+* go for low/medium/high load configuration of the GPU.
+*/
+ atomic_t req_cnt;
+
/**
* @name: arbitrary name, used for user debug
*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3f4f28e9468..f90c968f95cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2565,6 +2565,8 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (batch->private)
intel_engine_pool_mark_active(batch->private, eb.request);
+ atomic_inc(&eb.gem_context->req_cnt);
+
trace_i915_request_queue(eb.request, eb.batch_flags);
err = eb_submit(&eb, batch);
err_request:
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 112531b29f59..ccfebebb0071 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2143,6 +2143,8 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
}
if (__i915_request_submit(rq)) {
+ struct i915_gem_context *ctx;
+
if (!merge) {
*port = execlists_schedule_in(last,
port - execlists->pending);
port++;
@@ -2158,6 +2160,13 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
submit = true;
last = rq;
+
+ ctx = rcu_dereference_protected(
+ rq->context->gem_context, true);
+
+ GEM_BUG_ON(atomic_read(&ctx->req_cnt));
+ if (atomic_read(&ctx->req_cnt) > 0)
+ atomic_dec(&ctx->req_cnt);
}
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 3/3] drm/i915: Predictive governor to control slice/subslice/eu
Load classification is used for predictive governor to control
eu/slice/subslice based on workloads.
sysfs is provided to enable/disable the feature
V2:
* Fix code style.
* Move predictive_load_timer into a drm_i915_private
structure.
* Make generic function to set optimum config. (Tvrtko Ursulin)
V3:
* Rebase.
* Fix race condition for predictive load set.
* Add slack to start hrtimer for more power efficient. (Tvrtko Ursulin)
V4:
* Fix data type and initialization of mutex to protect predictive load
state.
* Move predictive timer init to i915_gem_init_early. (Tvrtko Ursulin)
* Move debugfs to kernel parameter.
V5:
* Rebase.
* Remove mutex for pred_timer
V6:
* Rebase.
* Fix warnings.
V7:
* Drop timer and move logic to __execlists_update_reg_state. (Tvrtko Ursulin)
* Remove kernel boot param and make it to sysfs entry. (Jani Nikula)
Cc: Vipin Anand
Signed-off-by: Ankit Navik
---
drivers/gpu/drm/i915/i915_sysfs.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 45d32ef42787..5d76e4992c8d 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -433,12 +433,43 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
return ret ?: count;
}
+static ssize_t deu_enable_show(struct device *kdev, struct device_attribute
*attr, char *buf)
+{
+ struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
+
+ return snprintf(buf, PAGE_SIZE, "%u\n", i915->predictive_load_enable);
+}
+
+static ssize_t deu_enable_store(struct device *kdev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+ struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
+ ssize_t ret;
+ u32 val;
+
+ ret = kstrtou32(buf, 0, &val);
+ if (ret)
+ return ret;
+
+ /* Check invalid values */
+ if (val != 0 && val != 1)
+ ret = -EINVAL;
+
+ i915->predictive_load_enable = val;
+
+ return count;
+}
+
static DEVICE_ATTR_RO(gt_act_freq_mhz);
static DEVICE_ATTR_RO(gt_cur_freq_mhz);
static DEVICE_ATTR_RW(gt_boost_freq_mhz);
static DEVICE_ATTR_RW(gt_max_freq_mhz);
static DEVICE_ATTR_RW(gt_min_freq_mhz);
+static DEVICE_ATTR_RW(deu_enable);
+
static DEVICE_ATTR_RO(vlv_rpe_freq_mhz);
static ssize_t gt_rp_mhz_show(struct device *kdev, struct device_attribute
*attr, char *buf);
@@ -474,6 +505,7 @@ static const struct attribute * const gen6_attrs[] = {
&dev_attr_gt_RP0_freq_mhz.attr,
&dev_attr_gt_RP1_freq_mhz.attr,
&dev_attr_gt_RPn_freq_mhz.attr,
+ &dev_attr_deu_enable.attr,
NULL,
};
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 0/3] drm/i915: Context aware user agnostic EU/Slice/Sub-slice control within kernel
This patch sets improves GPU power consumption on Linux kernel based OS such as Chromium OS, Ubuntu, etc. Following are the power savings. Power savings on GLK-GT1 Bobba platform running on Chrome OS. ---| App /KPI| % Power Benefit (mW) | |--| Hangout Call- 20 minute | 1.8% | Youtube 4K VPB | 14.13% | WebGL Aquarium | 13.76% | Unity3D | 6.78% | | | |--| Chrome PLT | BatteryLife Improves | | by ~45 minute| ---| Power savings on KBL-GT3 running on Android and Ubuntu (Linux). ---| App /KPI| % Power Benefit (mW) | |--| | Android | Ubuntu | |--|---| 3D Mark (Ice storm) | 2.30%| N.A. | TRex On screen | 2.49%| 2.97% | Manhattan On screen | 3.11%| 4.90% | Carchase On Screen | N.A. | 5.06% | AnTuTu 6.1.4| 3.42%| N.A. | SynMark2| N.A. | 1.7% | ---| We have also observed GPU core residencies improves by 1.035%. Technical Insights of the patch: Current GPU configuration code for i915 does not allow us to change EU/Slice/Sub-slice configuration dynamically. Its done only once while context is created. While particular graphics application is running, if we examine the command requests from user space, we observe that command density is not consistent. It means there is scope to change the graphics configuration dynamically even while context is running actively. This patch series proposes the solution to find the active pending load for all active context at given time and based on that, dynamically perform graphics configuration for each context. The feature can be enabled using sysfs. we examine pending commands for a context in the queue, essentially, we intercept them before they are executed by GPU and we update context with required number of EUs. For the prior one, empirical data to achieve best performance in least power was considered. For the later one, we roughly categorized number of EUs logically based on platform. Now we compare number of pending commands with a particular threshold and then set number of EUs accordingly with update context. That threshold is also based on experiments & findings. If GPU is able to catch up with CPU, typically there are no pending commands, the EU config would remain unchanged there. In case there are more pending commands we reprogram context with higher number of EUs. Ankit Navik (3): drm/i915: Get active pending request for given context drm/i915: set optimum eu/slice/sub-slice configuration based on load type drm/i915: Predictive governor to control slice/subslice/eu drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++ drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 37 +++ drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 + drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 + drivers/gpu/drm/i915/gt/intel_context_types.h | 2 + drivers/gpu/drm/i915/gt/intel_lrc.c | 79 ++- drivers/gpu/drm/i915/i915_drv.h | 5 ++ drivers/gpu/drm/i915/i915_sysfs.c | 32 + drivers/gpu/drm/i915/intel_device_info.c | 55 +++- 9 files changed, 214 insertions(+), 4 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 2/3] drm/i915: set optimum eu/slice/sub-slice configuration based on load type
This patch will select optimum eu/slice/sub-slice configuration based on
type of load (low, medium, high) as input.
Based on our readings and experiments we have predefined set of optimum
configuration for each platform(CHT, KBL).
i915_gem_context_set_load_type will select optimum configuration from
pre-defined optimum configuration table(opt_config).
It also introduce flag update_render_config which can set by any governor.
v2:
* Move static optimum_config to device init time.
* Rename function to appropriate name, fix data types and patch ordering.
* Rename prev_load_type to pending_load_type. (Tvrtko Ursulin)
v3:
* Add safe guard check in i915_gem_context_set_load_type.
* Rename struct from optimum_config to i915_sseu_optimum_config to
avoid namespace clashes.
* Reduces memcpy for space efficient.
* Rebase.
* Improved commit message. (Tvrtko Ursulin)
v4:
* Move optimum config table to file scope. (Tvrtko Ursulin)
v5:
* Adds optimal table of slice/sub-slice/EU for Gen 9 GT1.
* Rebase.
v6:
* Rebase.
* Fix warnings.
v7:
* Fix return conditions.
* Remove i915_gem_context_set_load_type and move logic to
__execlists_update_reg_state. (Tvrtko Ursulin)
Cc: Vipin Anand
Signed-off-by: Ankit Navik
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 32 +++
drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 70 ++-
drivers/gpu/drm/i915/i915_drv.h | 5 ++
drivers/gpu/drm/i915/intel_device_info.c | 55 +-
7 files changed, 165 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d0ff999429ff..3aad45b0ba5a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -880,6 +880,9 @@ i915_gem_create_context(struct drm_i915_private *i915,
unsigned int flags)
trace_i915_context_create(ctx);
atomic_set(&ctx->req_cnt, 0);
+ ctx->slice_cnt = hweight8(RUNTIME_INFO(i915)->sseu.slice_mask);
+ ctx->subslice_cnt = hweight8(RUNTIME_INFO(i915)->sseu.subslice_mask[0]);
+ ctx->eu_cnt = RUNTIME_INFO(i915)->sseu.eu_per_subslice;
return ctx;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index a9ba13f8865e..1af1acd73794 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -46,6 +46,19 @@ struct i915_gem_engines_iter {
const struct i915_gem_engines *engines;
};
+enum gem_load_type {
+ LOAD_TYPE_LOW,
+ LOAD_TYPE_MEDIUM,
+ LOAD_TYPE_HIGH,
+ LOAD_TYPE_LAST
+};
+
+struct i915_sseu_optimum_config {
+ u8 slice;
+ u8 subslice;
+ u8 eu;
+};
+
/**
* struct i915_gem_context - client state
*
@@ -155,6 +168,25 @@ struct i915_gem_context {
*/
atomic_t active_count;
+ /** slice_cnt: used to set the # of slices to be enabled. */
+ u8 slice_cnt;
+
+ /** subslice_cnt: used to set the # of subslices to be enabled. */
+ u8 subslice_cnt;
+
+ /** eu_cnt: used to set the # of eu to be enabled. */
+ u8 eu_cnt;
+
+ /** load_type: The designated load_type (high/medium/low) for a given
+* number of pending commands in the command queue.
+*/
+ enum gem_load_type load_type;
+
+ /** pending_load_type: The earlier load type that the GPU was configured
+* for (high/medium/low).
+*/
+ enum gem_load_type pending_load_type;
+
/**
* @hang_timestamp: The last time(s) this context caused a GPU hang
*/
diff --git a/drivers/gpu/drm/i915/gt/intel_context_sseu.c
b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
index 57a30956c922..4f51bfb9690c 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
@@ -84,6 +84,8 @@ intel_context_reconfigure_sseu(struct intel_context *ce,
if (ret)
return ret;
+ ce->user_sseu = true;
+
/* Nothing to do if unmodified. */
if (!memcmp(&ce->sseu, &sseu, sizeof(sseu)))
goto unlock;
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0f3b68b95c56..fd580026 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -93,6 +93,8 @@ struct intel_context {
const struct intel_context_ops *ops;
+ bool user_sseu;
+
/** sseu: Control eu/slice partitioning */
struct intel_sseu sseu;
};
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ccfebebb0071..7c5f05886278 100
[Intel-gfx] [PATCH v7 1/3] drm/i915: Get active pending request for given context
This patch gives us the active pending request count which is yet
to be submitted to the GPU.
V2:
* Change 64-bit to atomic for request count. (Tvrtko Ursulin)
V3:
* Remove mutex for request count.
* Rebase.
* Fixes hitting underflow for predictive request. (Tvrtko Ursulin)
V4:
* Rebase.
V5:
* Rebase.
V6:
* Rebase.
V7:
* Rebase.
* Add GEM_BUG_ON for req_cnt.
Cc: Vipin Anand
Signed-off-by: Ankit Navik
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 5 +
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
4 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 026999b34abd..d0ff999429ff 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -879,6 +879,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
unsigned int flags)
}
trace_i915_context_create(ctx);
+ atomic_set(&ctx->req_cnt, 0);
return ctx;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index 28760bd03265..a9ba13f8865e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -171,6 +171,11 @@ struct i915_gem_context {
*/
struct radix_tree_root handles_vma;
+ /** req_cnt: tracks the pending commands, based on which we decide to
+* go for low/medium/high load configuration of the GPU.
+*/
+ atomic_t req_cnt;
+
/**
* @name: arbitrary name, used for user debug
*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3f4f28e9468..f90c968f95cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2565,6 +2565,8 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (batch->private)
intel_engine_pool_mark_active(batch->private, eb.request);
+ atomic_inc(&eb.gem_context->req_cnt);
+
trace_i915_request_queue(eb.request, eb.batch_flags);
err = eb_submit(&eb, batch);
err_request:
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 112531b29f59..ccfebebb0071 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2143,6 +2143,8 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
}
if (__i915_request_submit(rq)) {
+ struct i915_gem_context *ctx;
+
if (!merge) {
*port = execlists_schedule_in(last,
port - execlists->pending);
port++;
@@ -2158,6 +2160,13 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
submit = true;
last = rq;
+
+ ctx = rcu_dereference_protected(
+ rq->context->gem_context, true);
+
+ GEM_BUG_ON(atomic_read(&ctx->req_cnt));
+ if (atomic_read(&ctx->req_cnt) > 0)
+ atomic_dec(&ctx->req_cnt);
}
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 3/3] drm/i915: Predictive governor to control slice/subslice/eu
Load classification is used for predictive governor to control
eu/slice/subslice based on workloads.
sysfs is provided to enable/disable the feature
V2:
* Fix code style.
* Move predictive_load_timer into a drm_i915_private
structure.
* Make generic function to set optimum config. (Tvrtko Ursulin)
V3:
* Rebase.
* Fix race condition for predictive load set.
* Add slack to start hrtimer for more power efficient. (Tvrtko Ursulin)
V4:
* Fix data type and initialization of mutex to protect predictive load
state.
* Move predictive timer init to i915_gem_init_early. (Tvrtko Ursulin)
* Move debugfs to kernel parameter.
V5:
* Rebase.
* Remove mutex for pred_timer
V6:
* Rebase.
* Fix warnings.
V7:
* Drop timer and move logic to __execlists_update_reg_state. (Tvrtko Ursulin)
* Remove kernel boot param and make it to sysfs entry. (Jani Nikula)
Cc: Vipin Anand
Signed-off-by: Ankit Navik
---
drivers/gpu/drm/i915/i915_sysfs.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 45d32ef42787..5d76e4992c8d 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -433,12 +433,43 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
return ret ?: count;
}
+static ssize_t deu_enable_show(struct device *kdev, struct device_attribute
*attr, char *buf)
+{
+ struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
+
+ return snprintf(buf, PAGE_SIZE, "%u\n", i915->predictive_load_enable);
+}
+
+static ssize_t deu_enable_store(struct device *kdev,
+ struct device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+ struct drm_i915_private *i915 = kdev_minor_to_i915(kdev);
+ ssize_t ret;
+ u32 val;
+
+ ret = kstrtou32(buf, 0, &val);
+ if (ret)
+ return ret;
+
+ /* Check invalid values */
+ if (val != 0 && val != 1)
+ ret = -EINVAL;
+
+ i915->predictive_load_enable = val;
+
+ return count;
+}
+
static DEVICE_ATTR_RO(gt_act_freq_mhz);
static DEVICE_ATTR_RO(gt_cur_freq_mhz);
static DEVICE_ATTR_RW(gt_boost_freq_mhz);
static DEVICE_ATTR_RW(gt_max_freq_mhz);
static DEVICE_ATTR_RW(gt_min_freq_mhz);
+static DEVICE_ATTR_RW(deu_enable);
+
static DEVICE_ATTR_RO(vlv_rpe_freq_mhz);
static ssize_t gt_rp_mhz_show(struct device *kdev, struct device_attribute
*attr, char *buf);
@@ -474,6 +505,7 @@ static const struct attribute * const gen6_attrs[] = {
&dev_attr_gt_RP0_freq_mhz.attr,
&dev_attr_gt_RP1_freq_mhz.attr,
&dev_attr_gt_RPn_freq_mhz.attr,
+ &dev_attr_deu_enable.attr,
NULL,
};
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 0/3] Dynamic EU configuration of Slice/Sub-slice/EU
drm/i915: Context aware user agnostic EU/Slice/Sub-slice control within kernel This patch sets improves GPU power consumption on Linux kernel based OS such as Chromium OS, Ubuntu, etc. Following are the power savings. Power savings on GLK-GT1 Bobba platform running on Chrome OS. ---| App /KPI| % Power Benefit (mW) | |--| Hangout Call- 20 minute | 1.8% | Youtube 4K VPB | 14.13% | WebGL Aquarium | 13.76% | Unity3D | 6.78% | | | |--| Chrome PLT | BatteryLife Improves | | by ~45 minute| ---| Power savings on KBL-GT3 running on Android and Ubuntu (Linux). ---| App /KPI| % Power Benefit (mW) | |--| | Android | Ubuntu | |--|---| 3D Mark (Ice storm) | 2.30%| N.A. | TRex On screen | 2.49%| 2.97% | Manhattan On screen | 3.11%| 4.90% | Carchase On Screen | N.A. | 5.06% | AnTuTu 6.1.4| 3.42%| N.A. | SynMark2| N.A. | 1.7% | ---| We have also observed GPU core residencies improves by 1.035%. Technical Insights of the patch: Current GPU configuration code for i915 does not allow us to change EU/Slice/Sub-slice configuration dynamically. Its done only once while context is created. While particular graphics application is running, if we examine the command requests from user space, we observe that command density is not consistent. It means there is scope to change the graphics configuration dynamically even while context is running actively. This patch series proposes the solution to find the active pending load for all active context at given time and based on that, dynamically perform graphics configuration for each context. The feature can be enabled using sysfs. We examine pending commands for a context in the queue, essentially, we intercept them before they are executed by GPU and we update context with required number of EUs. For the prior one, empirical data to achieve best performance in least power was considered. For the later one, we roughly categorized number of EUs logically based on platform. Now we compare number of pending commands with a particular threshold and then set number of EUs accordingly with update context. That threshold is also based on experiments & findings. If GPU is able to catch up with CPU, typically there are no pending commands, the EU config would remain unchanged there. In case there are more pending commands we reprogram context with higher number of EUs. Ankit Navik (3): drm/i915: Get active pending request for given context drm/i915: set optimum eu/slice/sub-slice configuration based on load type drm/i915: Predictive governor to control slice/subslice/eu drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++ drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 37 +++ drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 + drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 + drivers/gpu/drm/i915/gt/intel_context_types.h | 2 + drivers/gpu/drm/i915/gt/intel_lrc.c | 79 ++- drivers/gpu/drm/i915/i915_drv.h | 5 ++ drivers/gpu/drm/i915/i915_sysfs.c | 32 + drivers/gpu/drm/i915/intel_device_info.c | 55 +++- 9 files changed, 214 insertions(+), 4 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 2/3] drm/i915: set optimum eu/slice/sub-slice configuration based on load type
This patch will select optimum eu/slice/sub-slice configuration based on
type of load (low, medium, high) as input.
Based on our readings and experiments we have predefined set of optimum
configuration for each platform(CHT, KBL).
i915_gem_context_set_load_type will select optimum configuration from
pre-defined optimum configuration table(opt_config).
It also introduce flag update_render_config which can set by any governor.
v2:
* Move static optimum_config to device init time.
* Rename function to appropriate name, fix data types and patch ordering.
* Rename prev_load_type to pending_load_type. (Tvrtko Ursulin)
v3:
* Add safe guard check in i915_gem_context_set_load_type.
* Rename struct from optimum_config to i915_sseu_optimum_config to
avoid namespace clashes.
* Reduces memcpy for space efficient.
* Rebase.
* Improved commit message. (Tvrtko Ursulin)
v4:
* Move optimum config table to file scope. (Tvrtko Ursulin)
v5:
* Adds optimal table of slice/sub-slice/EU for Gen 9 GT1.
* Rebase.
v6:
* Rebase.
* Fix warnings.
v7:
* Fix return conditions.
* Remove i915_gem_context_set_load_type and move logic to
__execlists_update_reg_state. (Tvrtko Ursulin)
Cc: Vipin Anand
Signed-off-by: Ankit Navik
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 +
drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 32 +++
drivers/gpu/drm/i915/gt/intel_context_sseu.c | 2 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 2 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 70 ++-
drivers/gpu/drm/i915/i915_drv.h | 5 ++
drivers/gpu/drm/i915/intel_device_info.c | 55 +-
7 files changed, 165 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index d0ff999429ff..3aad45b0ba5a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -880,6 +880,9 @@ i915_gem_create_context(struct drm_i915_private *i915,
unsigned int flags)
trace_i915_context_create(ctx);
atomic_set(&ctx->req_cnt, 0);
+ ctx->slice_cnt = hweight8(RUNTIME_INFO(i915)->sseu.slice_mask);
+ ctx->subslice_cnt = hweight8(RUNTIME_INFO(i915)->sseu.subslice_mask[0]);
+ ctx->eu_cnt = RUNTIME_INFO(i915)->sseu.eu_per_subslice;
return ctx;
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
index a9ba13f8865e..1af1acd73794 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
@@ -46,6 +46,19 @@ struct i915_gem_engines_iter {
const struct i915_gem_engines *engines;
};
+enum gem_load_type {
+ LOAD_TYPE_LOW,
+ LOAD_TYPE_MEDIUM,
+ LOAD_TYPE_HIGH,
+ LOAD_TYPE_LAST
+};
+
+struct i915_sseu_optimum_config {
+ u8 slice;
+ u8 subslice;
+ u8 eu;
+};
+
/**
* struct i915_gem_context - client state
*
@@ -155,6 +168,25 @@ struct i915_gem_context {
*/
atomic_t active_count;
+ /** slice_cnt: used to set the # of slices to be enabled. */
+ u8 slice_cnt;
+
+ /** subslice_cnt: used to set the # of subslices to be enabled. */
+ u8 subslice_cnt;
+
+ /** eu_cnt: used to set the # of eu to be enabled. */
+ u8 eu_cnt;
+
+ /** load_type: The designated load_type (high/medium/low) for a given
+* number of pending commands in the command queue.
+*/
+ enum gem_load_type load_type;
+
+ /** pending_load_type: The earlier load type that the GPU was configured
+* for (high/medium/low).
+*/
+ enum gem_load_type pending_load_type;
+
/**
* @hang_timestamp: The last time(s) this context caused a GPU hang
*/
diff --git a/drivers/gpu/drm/i915/gt/intel_context_sseu.c
b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
index 57a30956c922..4f51bfb9690c 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_context_sseu.c
@@ -84,6 +84,8 @@ intel_context_reconfigure_sseu(struct intel_context *ce,
if (ret)
return ret;
+ ce->user_sseu = true;
+
/* Nothing to do if unmodified. */
if (!memcmp(&ce->sseu, &sseu, sizeof(sseu)))
goto unlock;
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 0f3b68b95c56..fd580026 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -93,6 +93,8 @@ struct intel_context {
const struct intel_context_ops *ops;
+ bool user_sseu;
+
/** sseu: Control eu/slice partitioning */
struct intel_sseu sseu;
};
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ccfebebb0071..7c5f05886278 100
Re: [Intel-gfx] [PATCH v7 1/3] drm/i915: Get active pending request for given context
Quoting Ankit Navik (2020-03-16 13:29:49)
> This patch gives us the active pending request count which is yet
> to be submitted to the GPU.
>
> V2:
> * Change 64-bit to atomic for request count. (Tvrtko Ursulin)
>
> V3:
> * Remove mutex for request count.
> * Rebase.
> * Fixes hitting underflow for predictive request. (Tvrtko Ursulin)
>
> V4:
> * Rebase.
>
> V5:
> * Rebase.
>
> V6:
> * Rebase.
>
> V7:
> * Rebase.
> * Add GEM_BUG_ON for req_cnt.
>
> Cc: Vipin Anand
> Signed-off-by: Ankit Navik
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
> drivers/gpu/drm/i915/gem/i915_gem_context_types.h | 5 +
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 ++
> drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
> 4 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 026999b34abd..d0ff999429ff 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -879,6 +879,7 @@ i915_gem_create_context(struct drm_i915_private *i915,
> unsigned int flags)
> }
>
> trace_i915_context_create(ctx);
> + atomic_set(&ctx->req_cnt, 0);
>
> return ctx;
> }
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> index 28760bd03265..a9ba13f8865e 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context_types.h
> @@ -171,6 +171,11 @@ struct i915_gem_context {
> */
> struct radix_tree_root handles_vma;
>
> + /** req_cnt: tracks the pending commands, based on which we decide to
> +* go for low/medium/high load configuration of the GPU.
> +*/
> + atomic_t req_cnt;
> +
> /**
> * @name: arbitrary name, used for user debug
> *
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index d3f4f28e9468..f90c968f95cd 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2565,6 +2565,8 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> if (batch->private)
> intel_engine_pool_mark_active(batch->private, eb.request);
>
> + atomic_inc(&eb.gem_context->req_cnt);
> +
> trace_i915_request_queue(eb.request, eb.batch_flags);
> err = eb_submit(&eb, batch);
> err_request:
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 112531b29f59..ccfebebb0071 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -2143,6 +2143,8 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> }
>
> if (__i915_request_submit(rq)) {
> + struct i915_gem_context *ctx;
> +
> if (!merge) {
> *port = execlists_schedule_in(last,
> port - execlists->pending);
> port++;
> @@ -2158,6 +2160,13 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
>
> submit = true;
> last = rq;
> +
> + ctx = rcu_dereference_protected(
> + rq->context->gem_context, true);
> +
> + GEM_BUG_ON(atomic_read(&ctx->req_cnt));
> + if (atomic_read(&ctx->req_cnt) > 0)
> + atomic_dec(&ctx->req_cnt);
This is wrong on so many levels. The GEM context is an opaque pointer
here, and often not available. The rcu_dereference_protected is woeful.
There is not even a 1:1 relationship between execbuf and requests -- you
should have recognised that the moment you "handled" the bug.
Please do look at the other metrics we have time and time again pointed
you towards.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp/mst : Get clock rate from sink's available PBN
On Wed, 2020-03-11, Lyude Paul wrote:
>On Tue, 2020-01-07 at 01:41 +0800, Lee Shawn C wrote:
>> Driver report physcial bandwidth for max dot clock rate.
>> It would caused compatibility issue sometimes when physical bandwidth
>> exceed MST hub output ability.
>>
>> For example, here is a MST hub with HDMI 1.4 and DP 1.2 output.
>> And source have DP 1.2 output capability. Connect a HDMI 2.0 display
>> then source will retrieve EDID from external monitor.
>> Driver got max resolution was 4k@60fps. DP 1.2 can support this
>> resolution because it did not surpass max physical bandwidth.
>> After modeset, source output display data but MST hub can't output
>> HDMI properly due to it already over HDMI 1.4 spec.
>>
>> Apply this calculation, source calcualte max dot clock according to
>> available PBN. Driver will remove the mode that over current clock
>> rate. And external display can works normally.
>>
>> Cc: Manasi Navare
>> Cc: Jani Nikula
>> Cc: Ville Syrjala
>> Cc: Cooper Chiou
>>
>> Signed-off-by: Lee Shawn C
>> ---
>> drivers/gpu/drm/i915/display/intel_dp_mst.c | 27
>> ++---
>> 1 file changed, 24 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> index 3b066c63816d..eaa440165ad2 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> @@ -550,6 +550,27 @@ static int intel_dp_mst_get_modes(struct
>> drm_connector
>> *connector)
>> return intel_dp_mst_get_ddc_modes(connector);
>> }
>>
>> +static int
>> +intel_dp_mst_downstream_max_dotclock(struct drm_connector *connector)
>> +{
>> +struct intel_connector *intel_connector =
>> to_intel_connector(connector);
>> +struct intel_dp *intel_dp = intel_connector->mst_port;
>> +struct drm_dp_mst_port *port;
>> +u64 clock_rate = 0;
>> +
>> +if (intel_dp->mst_mgr.mst_primary)
>> +list_for_each_entry(port, &intel_dp->mst_mgr.mst_primary-
>> >ports, next)
>> +if (port->connector == connector) {
>> +clock_rate = ((u64)port->available_pbn * (54 *
>> 8 * 1000 * 1000)) / (64 * 1006);
>> +
>> +// FIXME: We should used pipe bpp to do this
>> calculation.
>> +//But can't retrieve bpp setting from
>> drm_connector.
>> +return (int)(clock_rate / 24);
>> +}
>> +
>> +return to_i915(connector->dev)->max_dotclk_freq;
>> +}
>
>Hi! So-there's no need to loop through the ports like this, just use the
>drm_dp_mst_port struct that's associated with intel_connector->port directly
>(feel free to change the declaration to `struct drm_dp_mst_port *port` instead
>of `void *port`, it's not illegal to dereference it anymore I promise!
>
>Additionally - you don't want to use pipe_bpp here at all. My advice is to use
>the hard-coded bpc we currently have for MST. Once you guys have retry logic
>to dynamically select the bpc depending on the available bandwidth, I'd move
>this check over to using the smallest possible BPC reported by the connector's
>display_info. Remember we're checking if -any- variant of each mode is somehow
>possible, it's ok and expected for modes to potentially fail at higher BPCs.
>
>Anyway-this looks fine otherwise, but like Ville mentioned available_pbn isn't
>the thing that we want to be using here. I've got support for using full_pbn
>instead and that should be pushed sometime today or tommorrow (dealing with
>some topic branch weirdness with dim right now). This is the patch series,
>jfyi:
>
>https://patchwork.freedesktop.org/series/74295/
>
>Also-feel free to write a drm helper to do these mode_valid checks for mst, if
>it's feasible and not overkill
>
Thanks! I will refer the change from patch series you mentioned. Hardcode bpc
to 24 and use full_pbn instead of available_pbn.
BTW, this patch series still on specific branch
(topic/mst-bw-check-fixes-for-airlied) and not merge to drm branch yet.
It would be better to wait the patches merged into drm branch. After that, I
can commit new patch to fix issue. Any comment?
>> +
>> static enum drm_mode_status
>> intel_dp_mst_mode_valid(struct drm_connector *connector,
>> struct drm_display_mode *mode)
>> @@ -557,8 +578,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
>> struct drm_i915_private *dev_priv = to_i915(connector->dev);
>> struct intel_connector *intel_connector =
>> to_intel_connector(connector);
>> struct intel_dp *intel_dp = intel_connector->mst_port;
>> -int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
>> -int max_rate, mode_rate, max_lanes, max_link_clock;
>> +int max_rate, mode_rate, max_lanes, max_link_clock, max_dotclk;
>>
>> if (drm_connector_is_unregistered(connector))
>> return MODE_ERROR;
>> @@ -572,7 +5
Re: [Intel-gfx] [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function
On Fri, Mar 13, 2020 at 09:17:42AM -0300, Jason Gunthorpe wrote: > On Fri, Mar 13, 2020 at 04:21:39AM -0700, Christoph Hellwig wrote: > > On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote: > > > The non-page scatterlist is also a big concern for RDMA as we have > > > drivers that want the page list, so even if we did as this series > > > contemplates I'd have still have to split the drivers and create the > > > notion of a dma-only SGL. > > > > The drivers I looked at want a list of IOVA address, aligned to the > > device "page size". What other data do drivers want? Execept for the > > software protocol stack drivers, which of couse need pages for the > > stack futher down. > > In principle it is possible to have just an aligned page list - > however the page size is variable, following certain rules, and today > the drivers still determine the correct page size largely on their > own. > > Some progress was made recently to consolidate this, but more is > needed. > > If the common code doesn't know the device page size in advance then > today's approach of sending largest possible dma mapped SGLs into the > device driver is best. The driver only has to do splitting. The point was that drivers don't need pages, drivers need IOVAs. In what form they are stuffed into the hardware is the drivers problem. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function
On Mon, Mar 16, 2020 at 10:41:42AM +0100, Christian König wrote: > Well I would prefer if the drivers can somehow express their requirements > and get IOVA structures already in the form they need. > > Converting the IOVA data from one form to another is sometimes quite costly. > Especially when it is only temporarily needed. We basically have two ways to generate the IOVA: - a linear translation for the direct mapping case or some dumb IOMMU drivers - in that case case there is a 1:1 mapping between input segments and output segments in DMA mapping - a non-trivial IOMMU where all aligned segments are merged into a single IOVA range So I don't really see how the dma layer could help much with any limitation beyond existing max size and dma boundary ones. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] lib/scatterlist: add sg_set_dma_addr() function
On Thu, Mar 12, 2020 at 11:19:28AM -0300, Jason Gunthorpe wrote: > The non-page scatterlist is also a big concern for RDMA as we have > drivers that want the page list, so even if we did as this series > contemplates I'd have still have to split the drivers and create the > notion of a dma-only SGL. The drivers I looked at want a list of IOVA address, aligned to the device "page size". What other data do drivers want? Execept for the software protocol stack drivers, which of couse need pages for the stack futher down. > I haven't used bio_vecs before, do they support chaining like SGL so > they can be very big? RDMA dma maps gigabytes of memory bio_vecs itself don't have the chaining, but the bios build around them do. But each entry can map a huge pile. If needed we could use the same chaining scheme we use for scatterlists for bio_vecs as well, but lets see if we really end up needing that. > So I'm guessing the path forward is something like > > - Add some generic dma_sg data structure and helper > - Add dma mapping code to go from pages to dma_sg That has been on my todo list for a while. All the DMA consolidatation is to prepare for that and we're finally getting close. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Port sync for skl+
== Series Details == Series: drm/i915: Port sync for skl+ URL : https://patchwork.freedesktop.org/series/74691/ State : failure == Summary == Applying: drm/i915/mst: Use .compute_config_late() to compute master transcoder Applying: drm/i915: Move TRANS_DDI_FUNC_CTL2 programming where it belongs Applying: drm/i915: Drop usless master_transcoder assignments Applying: drm/i915: Move icl_get_trans_port_sync_config() into the DDI code Applying: drm/i915: Use REG_FIELD_PREP() & co. for TRANS_DDI_FUNC_CTL2 Applying: drm/i915: Include port sync state in the state dump Applying: drm/i915: Store cpu_transcoder_mask in device info Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/i915_pci.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_pci.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_pci.c Auto-merging drivers/gpu/drm/i915/i915_drv.h error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0007 drm/i915: Store cpu_transcoder_mask in device info 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 mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: DisplayID parser fixes
== Series Details == Series: drm/edid: DisplayID parser fixes URL : https://patchwork.freedesktop.org/series/74689/ State : success == Summary == CI Bug Log - changes from CI_DRM_8137 -> Patchwork_16968 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16968/index.html Known issues Here are the changes found in Patchwork_16968 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gem_contexts: - fi-cml-s: [PASS][1] -> [DMESG-FAIL][2] ([i915#877]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16968/fi-cml-s/igt@i915_selftest@live@gem_contexts.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][3] ([CI#94]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16968/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live@execlists: - fi-cfl-8700k: [INCOMPLETE][5] ([i915#656]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16968/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [FAIL][7] ([i915#217]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16968/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html Warnings * igt@kms_chamelium@vga-edid-read: - fi-icl-u2: [SKIP][9] ([fdo#109309]) -> [FAIL][10] ([i915#217]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-u2/igt@kms_chamel...@vga-edid-read.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16968/fi-icl-u2/igt@kms_chamel...@vga-edid-read.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 Participating hosts (48 -> 40) -- Additional (2): fi-skl-6770hq fi-tgl-dsi Missing(10): fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-kbl-7500u fi-ivb-3770 fi-elk-e7500 fi-bdw-samus fi-byt-clapper fi-skl-6700k2 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8137 -> Patchwork_16968 CI-20190529: 20190529 CI_DRM_8137: 5786b5e77cc17a1b494b9bdf3c3f29eedc2e2e7d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5510: e100092d50105463f58db531fa953c70cc58bb10 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16968: 609d707c7434c8dfa31c7f685efdce7d4367387c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 609d707c7434 drm/edid: Fix DispID tile parsing for override EDID 678f62987d76 drm/edid: Clarify validate_displayid() 66e180ae8ec2 drm/edid: Don't include ext block csum in DispID size 4526537fc44c drm/edid: Don't parse garbage as DispID blocks 4d6e31e9e435 drm/edid: Move validate_displayid() drm_find_displayid_extension() 1558d22756e5 drm/edid: Return DispID length from drm_find_displayid_extension() 8ccc6544e3cd drm/edid: Remove idx==1 assumptions from all over the DispID parsing 943ea3d21966 drm/edid: Swap some operands in for_each_displayid_db() 93d5ae5ea6b2 drm: Constify topology id == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16968/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gem: Try allocating va from free space
If the current node/entry location is occupied, and the object is not
pinned, try assigning it some free space. We cannot wait here, so if in
doubt, we unreserve and try to grab all at once.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d3f4f28e9468..ffa383246a2b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -385,8 +385,17 @@ eb_pin_vma(struct i915_execbuffer *eb,
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_GTT))
pin_flags |= PIN_GLOBAL;
- if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags)))
- return false;
+ if (unlikely(i915_vma_pin(vma, 0, 0, pin_flags))) {
+ if (entry->flags & EXEC_OBJECT_PINNED)
+ return false;
+
+ pin_flags &= ~PIN_OFFSET_FIXED;
+ if (unlikely(i915_vma_pin(vma,
+ entry->pad_to_size,
+ entry->alignment,
+ pin_flags)))
+ return false;
+ }
if (unlikely(ev->flags & EXEC_OBJECT_NEEDS_FENCE)) {
if (unlikely(i915_vma_pin_fence(vma))) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/edp: Ignore short pulse when panel powered off (rev2)
== Series Details ==
Series: drm/i915/edp: Ignore short pulse when panel powered off (rev2)
URL : https://patchwork.freedesktop.org/series/74265/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8137 -> Patchwork_16970
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/index.html
Known issues
Here are the changes found in Patchwork_16970 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-r: [PASS][1] -> [FAIL][2] ([i915#665]) +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-kbl-r/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/fi-kbl-r/igt@i915_pm_...@basic-pci-d3-state.html
- fi-icl-guc: [PASS][3] -> [SKIP][4] ([i915#1316])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/fi-icl-guc/igt@i915_pm_...@basic-pci-d3-state.html
- fi-tgl-y: [PASS][5] -> [SKIP][6] ([CI#94] / [i915#1316])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/fi-tgl-y/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@basic-rte:
- fi-icl-guc: [PASS][7] -> [FAIL][8] ([i915#704])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-guc/igt@i915_pm_...@basic-rte.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/fi-icl-guc/igt@i915_pm_...@basic-rte.html
- fi-icl-u2: [PASS][9] -> [FAIL][10] ([i915#579])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-u2/igt@i915_pm_...@basic-rte.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/fi-icl-u2/igt@i915_pm_...@basic-rte.html
- fi-tgl-y: [PASS][11] -> [FAIL][12] ([CI#94] / [i915#579])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-tgl-y/igt@i915_pm_...@basic-rte.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/fi-tgl-y/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- fi-cml-u2: [PASS][13] -> [FAIL][14] ([i915#665])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-cml-u2/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/fi-cml-u2/igt@i915_pm_...@module-reload.html
- fi-icl-guc: [PASS][15] -> [FAIL][16] ([i915#579])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-guc/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/fi-icl-guc/igt@i915_pm_...@module-reload.html
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [FAIL][17] ([CI#94]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live@execlists:
- fi-cfl-8700k: [INCOMPLETE][19] ([i915#656]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][21] ([i915#217]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
- fi-kbl-7500u: [FAIL][23] ([i915#323]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Warnings
* igt@i915_pm_rpm@module-reload:
- fi-icl-u2: [DMESG-WARN][25] ([i915#289]) -> [DMESG-FAIL][26]
([i915#289])
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-u2/igt@i915_pm_...@module-reload.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16970/fi-icl-u2/igt@i915_pm_...@module-reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1316]: htt
Re: [Intel-gfx] [RFC][PATCH 1/5] drm: Introduce scaling filter property
On Mon, Mar 16, 2020 at 09:31:32AM +0100, Daniel Vetter wrote:
> On Tue, Mar 10, 2020 at 06:01:06PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 25, 2020 at 12:35:41PM +0530, Pankaj Bharadiya wrote:
> > > Introduce new scaling filter property to allow userspace to select
> > > the driver's default scaling filter or Nearest-neighbor(NN) filter
> > > for upscaling operations on crtc/plane.
> > >
> > > Drivers can set up this property for a plane by calling
> > > drm_plane_enable_scaling_filter() and for a CRTC by calling
> > > drm_crtc_enable_scaling_filter().
> > >
> > > NN filter works by filling in the missing color values in the upscaled
> > > image with that of the coordinate-mapped nearest source pixel value.
> > >
> > > NN filter for integer multiple scaling can be particularly useful for
> > > for pixel art games that rely on sharp, blocky images to deliver their
> > > distinctive look.
> > >
> > > Signed-off-by: Pankaj Bharadiya
> > > Signed-off-by: Shashank Sharma
> > > Signed-off-by: Ankit Nautiyal
> > > ---
> > > drivers/gpu/drm/drm_atomic_uapi.c | 8 +++
> > > drivers/gpu/drm/drm_crtc.c| 16 ++
> > > drivers/gpu/drm/drm_mode_config.c | 13
> > > drivers/gpu/drm/drm_plane.c | 35 +++
> > > include/drm/drm_crtc.h| 10 +
> > > include/drm/drm_mode_config.h | 6 ++
> > > include/drm/drm_plane.h | 14 +
> > > 7 files changed, 102 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > > b/drivers/gpu/drm/drm_atomic_uapi.c
> > > index a1e5e262bae2..4e3c1f3176e4 100644
> > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct
> > > drm_crtc *crtc,
> > > return ret;
> > > } else if (property == config->prop_vrr_enabled) {
> > > state->vrr_enabled = val;
> > > + } else if (property == config->scaling_filter_property) {
> > > + state->scaling_filter = val;
> >
> > I think we want a per-plane/per-crtc prop for this. If we start adding
> > more filters we are surely going to need different sets for different hw
> > blocks.
>
> In the past we've only done that once we have a demonstrated need. Usually
> the patch to move the property to a per-object location isn't a lot of
> churn.
Seems silly to not do it from the start when we already know there is
hardware out there that has different capabilities per hw block.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v6,1/3] drm/i915/perf: remove generated code
== Series Details ==
Series: series starting with [v6,1/3] drm/i915/perf: remove generated code
URL : https://patchwork.freedesktop.org/series/74702/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e31b72062fe2 drm/i915/perf: remove generated code
-:24: WARNING:UNKNOWN_COMMIT_ID: Unknown commit id '53f8f541ca', maybe rebased
or not pulled?
#24:
commit 53f8f541ca ("lib: Add i915_perf library"), previously this was
-:205: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#205:
deleted file mode 100644
total: 0 errors, 2 warnings, 0 checks, 278 lines checked
066f2aa79c73 drm/i915/perf: remove redundant power configuration register
override
bbce3b010ffb drm/i915/perf: introduce global sseu pinning
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,1/3] drm/i915/perf: remove generated code
== Series Details == Series: series starting with [v6,1/3] drm/i915/perf: remove generated code URL : https://patchwork.freedesktop.org/series/74702/ State : success == Summary == CI Bug Log - changes from CI_DRM_8137 -> Patchwork_16971 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16971/index.html Known issues Here are the changes found in Patchwork_16971 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][1] ([CI#94]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16971/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live@execlists: - fi-cfl-8700k: [INCOMPLETE][3] ([i915#656]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16971/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [FAIL][5] ([i915#217]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16971/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 Participating hosts (48 -> 37) -- Additional (2): fi-skl-6770hq fi-tgl-dsi Missing(13): fi-bdw-5557u fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-kbl-7500u fi-ivb-3770 fi-skl-lmem fi-bdw-samus fi-byt-clapper fi-skl-6600u fi-snb-2600 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8137 -> Patchwork_16971 CI-20190529: 20190529 CI_DRM_8137: 5786b5e77cc17a1b494b9bdf3c3f29eedc2e2e7d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5510: e100092d50105463f58db531fa953c70cc58bb10 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16971: bbce3b010ffba286df1d08925e6318b62bab7ea6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == bbce3b010ffb drm/i915/perf: introduce global sseu pinning 066f2aa79c73 drm/i915/perf: remove redundant power configuration register override e31b72062fe2 drm/i915/perf: remove generated code == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16971/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/7] drm/i915: Move GGTT fence registers under gt/
== Series Details == Series: series starting with [1/7] drm/i915: Move GGTT fence registers under gt/ URL : https://patchwork.freedesktop.org/series/74703/ State : warning == Summary == $ dim checkpatch origin/drm-tip cfd159dc30dd drm/i915: Move GGTT fence registers under gt/ -:6: WARNING:TYPO_SPELLING: 'throught' may be misspelled - perhaps 'through'? #6: Since the fence registers control HW detiling throught the GGTT -:47: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #47: rename from drivers/gpu/drm/i915/i915_gem_fence_reg.c total: 0 errors, 2 warnings, 0 checks, 205 lines checked 4e7c950ab87c drm/i915/gt: Pull restoration of GGTT fences underneath the GT 84d01acc1bc9 drm/i915: Remove manual save/resume of fence register state 9f9e340e8b4d drm/i915/gt: Allocate i915_fence_reg array 5003f815b7aa drm/i915/gt: Store the fence details on the fence 750dc9e7ceb3 drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence 9eeea4468363 drm/i915/gt: Make fence revocation unequivocal ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [1/7] drm/i915: Move GGTT fence registers under gt/
== Series Details == Series: series starting with [1/7] drm/i915: Move GGTT fence registers under gt/ URL : https://patchwork.freedesktop.org/series/74703/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 Error: Cannot open file ./drivers/gpu/drm/i915/i915_gem_fence_reg.c Error: Cannot open file ./drivers/gpu/drm/i915/i915_gem_fence_reg.c Error: Cannot open file ./drivers/gpu/drm/i915/i915_gem_fence_reg.c Error: Cannot open file ./drivers/gpu/drm/i915/i915_gem_fence_reg.c WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/i915/i915_gem_fence_reg.c' failed with return code 2 WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function fence register handling ./drivers/gpu/drm/i915/i915_gem_fence_reg.c' failed with return code 1 WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function tiling swizzling details ./drivers/gpu/drm/i915/i915_gem_fence_reg.c' failed with return code 1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gem: Check for a closed context when looking up an engine
Beware that the context may already be closed as we try to lookup an
engine.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1389
Fixes: 130a95e9098e ("drm/i915/gem: Consolidate ctx->engines[] release")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gem/i915_gem_context.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.h
b/drivers/gpu/drm/i915/gem/i915_gem_context.h
index 57b7ae2893e1..a09fd67fed1d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.h
@@ -192,12 +192,16 @@ i915_gem_context_unlock_engines(struct i915_gem_context
*ctx)
static inline struct intel_context *
i915_gem_context_get_engine(struct i915_gem_context *ctx, unsigned int idx)
{
- struct intel_context *ce = ERR_PTR(-EINVAL);
+ struct intel_context *ce;
rcu_read_lock(); {
struct i915_gem_engines *e = rcu_dereference(ctx->engines);
- if (likely(idx < e->num_engines && e->engines[idx]))
+ if (unlikely(e == NULL)) /* context was closed! */
+ ce = ERR_PTR(-ENOENT);
+ else if (likely(idx < e->num_engines && e->engines[idx]))
ce = intel_context_get(e->engines[idx]);
+ else
+ ce = ERR_PTR(-EINVAL);
} rcu_read_unlock();
return ce;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: convert to struct drm_device based logging macros.
== Series Details == Series: drm/i915/gt: convert to struct drm_device based logging macros. URL : https://patchwork.freedesktop.org/series/74707/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6cfa7991dd93 drm/i915/ggtt: convert to drm_device based logging macros. -:84: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #84: References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html total: 0 errors, 1 warnings, 0 checks, 89 lines checked 0d578a154f1b drm/i915/lrc: convert to struct drm_device based logging macros. -:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #14: References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html total: 0 errors, 1 warnings, 0 checks, 44 lines checked 90332a78c06d drm/i915/rc6: convert to struct drm_device based logging macros. -:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #13: References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html total: 0 errors, 1 warnings, 0 checks, 109 lines checked 449bd50495fa drm/i915/renderstate: use struct drm_device based logging macros. ad89d4cdd325 drm/i915/ring_submission: use drm_device based logging macros. -:85: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #85: References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html total: 0 errors, 1 warnings, 0 checks, 63 lines checked e344bc88a34c drm/i915/rps: use struct drm_device based logging macros. -:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #15: References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html total: 0 errors, 1 warnings, 0 checks, 164 lines checked 8dfd9a57f09d drm/i915/workarounds: convert to drm_device based logging macros. -:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #12: References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html total: 0 errors, 1 warnings, 0 checks, 25 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/7] drm/i915: Move GGTT fence registers under gt/
== Series Details == Series: series starting with [1/7] drm/i915: Move GGTT fence registers under gt/ URL : https://patchwork.freedesktop.org/series/74703/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8137 -> Patchwork_16972 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16972 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16972, 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_16972/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16972: ### IGT changes ### Possible regressions * igt@gem_tiled_fence_blits@basic: - fi-blb-e6850: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-blb-e6850/igt@gem_tiled_fence_bl...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16972/fi-blb-e6850/igt@gem_tiled_fence_bl...@basic.html Known issues Here are the changes found in Patchwork_16972 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-skl-lmem:[PASS][3] -> [INCOMPLETE][4] ([i915#656]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-skl-lmem/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16972/fi-skl-lmem/igt@i915_selftest@l...@execlists.html - fi-icl-y: [PASS][5] -> [DMESG-FAIL][6] ([fdo#108569]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-y/igt@i915_selftest@l...@execlists.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16972/fi-icl-y/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gem_contexts: - fi-cml-s: [PASS][7] -> [DMESG-FAIL][8] ([i915#877]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16972/fi-cml-s/igt@i915_selftest@live@gem_contexts.html Possible fixes * igt@i915_selftest@live@execlists: - fi-cfl-8700k: [INCOMPLETE][9] ([i915#656]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16972/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [FAIL][11] ([i915#217]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16972/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html - fi-kbl-7500u: [FAIL][13] ([i915#323]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16972/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 Participating hosts (48 -> 45) -- Additional (2): fi-skl-6770hq fi-tgl-dsi Missing(5): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8137 -> Patchwork_16972 CI-20190529: 20190529 CI_DRM_8137: 5786b5e77cc17a1b494b9bdf3c3f29eedc2e2e7d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5510: e100092d50105463f58db531fa953c70cc58bb10 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16972: 9eeea446836327fedf640ae8513c72a66c71dedf @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9eeea4468363 drm/i915/gt: Make fence revocation unequivocal 750dc9e7ceb3 drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence 5003f815b7aa drm/i915/gt: Store the fence details on the fence 9f9e340e8b4d drm/i915/gt: Allocate i915_fence_reg array 84d01acc1bc9 drm/i915: Remove manual save/resume of fence register state 4e7c950ab87c drm/i915/gt: Pull restoration of GGTT fences underneath the GT cfd159dc30dd drm/i915: Move GGTT fence registers under gt/ == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16972/index.html ___ Intel-gfx mailing list Intel-
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: convert to struct drm_device based logging macros.
== Series Details == Series: drm/i915/gt: convert to struct drm_device based logging macros. URL : https://patchwork.freedesktop.org/series/74707/ State : success == Summary == CI Bug Log - changes from CI_DRM_8137 -> Patchwork_16973 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16973/index.html Known issues Here are the changes found in Patchwork_16973 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][1] ([CI#94]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16973/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live@execlists: - fi-cfl-8700k: [INCOMPLETE][3] ([i915#656]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16973/fi-cfl-8700k/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [FAIL][5] ([i915#217]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16973/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 [i915#656]: https://gitlab.freedesktop.org/drm/intel/issues/656 Participating hosts (48 -> 44) -- Additional (2): fi-skl-6770hq fi-tgl-dsi Missing(6): fi-kbl-soraka fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8137 -> Patchwork_16973 CI-20190529: 20190529 CI_DRM_8137: 5786b5e77cc17a1b494b9bdf3c3f29eedc2e2e7d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5510: e100092d50105463f58db531fa953c70cc58bb10 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16973: 8dfd9a57f09d583da9d2a6829720e9967f846bad @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8dfd9a57f09d drm/i915/workarounds: convert to drm_device based logging macros. e344bc88a34c drm/i915/rps: use struct drm_device based logging macros. ad89d4cdd325 drm/i915/ring_submission: use drm_device based logging macros. 449bd50495fa drm/i915/renderstate: use struct drm_device based logging macros. 90332a78c06d drm/i915/rc6: convert to struct drm_device based logging macros. 0d578a154f1b drm/i915/lrc: convert to struct drm_device based logging macros. 6cfa7991dd93 drm/i915/ggtt: convert to drm_device based logging macros. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16973/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: move audio CDCLK constraint setup to bind/unbind
Hey Ville and others, On Fri, 13 Mar 2020, Kai Vehmanen wrote: > On Fri, 13 Mar 2020, Ville Syrjälä wrote: > Now thinking of another possibility, is it possible to hook code to > power-up of power domains? E.g. can I hook custom code which is executed [...] > If we could reprogram AUD_FREQ_CNTRL outside the get/put_power() flow > (i.e. independently from audio driver), and guarantee that if the display > side is powered on, the link params are always correct, it might be > possible to get away without calling get_power() from audio controller ... no need to answer this. I made an ugly hack directly to intel_display_power.c and added a hook to audio restore, but, but, this does not seem to help. I can still hit hangs unless I bump cdclk before the reset -- i.e. restoring AUD_FREQ_CNTRL is not enough. Br, Kai___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (rev3)
== Series Details ==
Series: drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (rev3)
URL : https://patchwork.freedesktop.org/series/74100/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3d21f79cfaf6 drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (v3)
-:47: WARNING:LONG_LINE: line over 100 characters
#47: FILE: drivers/gpu/drm/drm_dp_helper.c:1242:
+ { OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false,
BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) },
total: 0 errors, 1 warnings, 0 checks, 38 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (rev3)
== Series Details == Series: drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (rev3) URL : https://patchwork.freedesktop.org/series/74100/ State : success == Summary == CI Bug Log - changes from CI_DRM_8137 -> Patchwork_16974 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16974/index.html Known issues Here are the changes found in Patchwork_16974 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][1] ([CI#94]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16974/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [FAIL][3] ([i915#217]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16974/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html Warnings * igt@runner@aborted: - fi-kbl-8809g: [FAIL][5] ([i915#1209]) -> [FAIL][6] ([i915#192] / [i915#193] / [i915#194]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-kbl-8809g/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16974/fi-kbl-8809g/igt@run...@aborted.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [i915#1209]: https://gitlab.freedesktop.org/drm/intel/issues/1209 [i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192 [i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193 [i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 Participating hosts (48 -> 42) -- Additional (2): fi-skl-6770hq fi-tgl-dsi Missing(8): fi-cml-u2 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-cfl-8700k fi-skl-lmem fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8137 -> Patchwork_16974 CI-20190529: 20190529 CI_DRM_8137: 5786b5e77cc17a1b494b9bdf3c3f29eedc2e2e7d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5510: e100092d50105463f58db531fa953c70cc58bb10 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16974: 3d21f79cfaf691c090222cc2db9655b6379ef2d3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3d21f79cfaf6 drm/i915/dp: Add dpcd link_rate quirk for Apple 15" MBP 2017 (v3) == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16974/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 1/3] drm/i915/perf: remove generated code
Looks good. Thanks for cleaning this up.
With s/mutex_lock/mutex_unlock/ below:
Reviewed-by: Umesh Nerlige Ramappa
Thanks,
Umesh
On Sat, Mar 14, 2020 at 12:33:29PM +0200, Lionel Landwerlin wrote:
A little bit of history :
Back when i915-perf was introduced (4.13), there was no way to
dynamically add new OA configurations to i915. Only the generated
configs baked in at build time were allowed.
It quickly became obvious that we would need to allow applications
to upload their own configurations, for instance to be able to test
new ones, and so by the next stable version (4.14) we added uAPIs
to allow uploading new configurations.
When adding that capability, we took the opportunity to remove most
HW configurations except the TestOa one which is a configuration
IGT would rely on to verify that the HW is outputting correct
values. At the time it made sense to have that confiuration in at
the same time a given HW platform added to the i915-perf driver.
Now that IGT has become the reference point for HW configurations (see
commit 53f8f541ca ("lib: Add i915_perf library"), previously this was
located in the GPUTop repository), the need for having those
configurations in i915-perf is gone.
On the Mesa side, we haven't relied on this test configuration for a
while. The MDAPI library always required 4.14 feature level and always
loaded its configuration into i915.
I'm sure nobody will miss this generated stuff in i915 :)
v2: Fix selftests by creating an empty config
v3: Fix unlocking on allocation error (Dan Carpenter)
v4: Fixup checkpatch warnings
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/Makefile | 17 ---
drivers/gpu/drm/i915/i915_perf.c | 81 +-
drivers/gpu/drm/i915/i915_perf_types.h | 2 -
drivers/gpu/drm/i915/oa/i915_oa_bdw.c | 90 ---
drivers/gpu/drm/i915/oa/i915_oa_bdw.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_bxt.c | 88 ---
drivers/gpu/drm/i915/oa/i915_oa_bxt.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_cflgt2.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_cflgt2.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_cflgt3.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_cflgt3.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_chv.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_chv.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_cnl.c | 101 -
drivers/gpu/drm/i915/oa/i915_oa_cnl.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_glk.c | 88 ---
drivers/gpu/drm/i915/oa/i915_oa_glk.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_hsw.c | 118
drivers/gpu/drm/i915/oa/i915_oa_hsw.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_icl.c | 98 -
drivers/gpu/drm/i915/oa/i915_oa_icl.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_kblgt2.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_kblgt2.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_kblgt3.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_kblgt3.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_sklgt2.c | 88 ---
drivers/gpu/drm/i915/oa/i915_oa_sklgt2.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_sklgt3.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_sklgt3.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_sklgt4.c | 89 ---
drivers/gpu/drm/i915/oa/i915_oa_sklgt4.h | 16 ---
drivers/gpu/drm/i915/oa/i915_oa_tgl.c | 121 -
drivers/gpu/drm/i915/oa/i915_oa_tgl.h | 16 ---
drivers/gpu/drm/i915/selftests/i915_perf.c | 98 -
34 files changed, 96 insertions(+), 1757 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_bdw.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_bdw.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_bxt.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_bxt.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_cflgt2.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_cflgt2.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_cflgt3.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_cflgt3.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_chv.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_chv.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_cnl.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_cnl.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_glk.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_glk.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_hsw.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_hsw.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_icl.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_icl.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_kblgt2.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_kblgt2.h
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_kblgt3.c
delete mode 100644 drivers/gpu/drm/i915/oa/i915_oa_kblgt3.h
del
[Intel-gfx] ✗ Fi.CI.BUILD: failure for tests/gem_userptr_blits: Refresh other now MMAP_GTT dependent subtests
== Series Details == Series: tests/gem_userptr_blits: Refresh other now MMAP_GTT dependent subtests URL : https://patchwork.freedesktop.org/series/74730/ State : failure == Summary == Applying: tests/gem_userptr_blits: Refresh readonly-mmap-unsync exercise error: sha1 information is lacking or useless (tests/i915/gem_userptr_blits.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 tests/gem_userptr_blits: Refresh readonly-mmap-unsync exercise 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 mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/perf: rework aging tail workaround
On Thu, 12 Mar 2020 16:04:59 -0700, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin
>
> We're about to introduce an options to open the perf stream, giving
> the user ability to configure how often it wants the kernel to poll
> the OA registers for available data.
>
> Right now the workaround against the OA tail pointer race condition
> requires at least twice the internal kernel polling timer to make any
> data available.
>
> This changes introduce checks on the OA data written into the circular
> buffer to make as much data as possible available on the first
> iteration of the polling timer.
Excellent, this absolutely needs to be done, I was thinking it may be
possible even with the approach taken in the original code but the approach
here looks better. It is also a nice cleanup.
> @@ -507,64 +487,76 @@ static bool oa_buffer_check_unlocked(struct
> i915_perf_stream *stream)
>
> now = ktime_get_mono_fast_ns();
>
> - /* Update the aged tail
> - *
> - * Flip the tail pointer available for read()s once the aging tail is
> - * old enough to trust that the corresponding data will be visible to
> - * the CPU...
> - *
> - * Do this before updating the aging pointer in case we may be able to
> - * immediately start aging a new pointer too (if new data has become
> - * available) without needing to wait for a later hrtimer callback.
> - */
> - if (aging_tail != INVALID_TAIL_PTR &&
> - ((now - stream->oa_buffer.aging_timestamp) >
> - OA_TAIL_MARGIN_NSEC)) {
> -
> - aged_idx ^= 1;
> - stream->oa_buffer.aged_tail_idx = aged_idx;
> + if (hw_tail == stream->oa_buffer.aging_tail) {
> + /* If the HW tail hasn't move since the last check and the HW
> + * tail has been aging for long enough, declare it the new
> + * tail.
> + */
Is this really needed? True we will never return the last report but maybe
it's ok, save some code?
> + if ((now - stream->oa_buffer.aging_timestamp) >
Do we need to initialize 'aging_timestamp = ktime_get_mono_fast_ns()' when
the stream is enabled?
> + OA_TAIL_MARGIN_NSEC) {
> + stream->oa_buffer.tail =
> + stream->oa_buffer.aging_tail;
> + }
> + } else {
> + u32 head, tail, landed_report_heads;
>
> - aged_tail = aging_tail;
> + /* NB: The head we observe here might effectively be a little
> out of
> + * date (between head and tails[aged_idx].offset if there is
> currently
> + * a read() in progress.
> + */
Is this comment correct? Aren't we are taking the same lock when updating
head after the read?
> + head = stream->oa_buffer.head - gtt_offset;
>
> - /* Mark that we need a new pointer to start aging... */
> - stream->oa_buffer.tails[!aged_idx].offset = INVALID_TAIL_PTR;
> - aging_tail = INVALID_TAIL_PTR;
> - }
> + hw_tail -= gtt_offset;
>
> - /* Update the aging tail
> - *
> - * We throttle aging tail updates until we have a new tail that
> - * represents >= one report more data than is already available for
> - * reading. This ensures there will be enough data for a successful
> - * read once this new pointer has aged and ensures we will give the new
> - * pointer time to age.
> - */
> - if (aging_tail == INVALID_TAIL_PTR &&
> - (aged_tail == INVALID_TAIL_PTR ||
> - OA_TAKEN(hw_tail, aged_tail) >= report_size)) {
> - struct i915_vma *vma = stream->oa_buffer.vma;
> - u32 gtt_offset = i915_ggtt_offset(vma);
> -
> - /* Be paranoid and do a bounds check on the pointer read back
> - * from hardware, just in case some spurious hardware condition
> - * could put the tail out of bounds...
> + /* Walk the stream backward until we find at least 2 reports
> + * with dword 0 & 1 not at 0. Since the circular buffer
> + * pointers progress by increments of 64 bytes and that
> + * reports can be up to 256 bytes long, we can't tell whether
> + * a report has fully landed in memory before the first 2
> + * dwords of the following report have effectively landed.
> + *
> + * This is assuming that the writes of the OA unit land in
> + * memory in the order they were written to.
> + * If not : (╯°□°）╯︵ ┻━┻
>*/
> - if (hw_tail >= gtt_offset &&
> - hw_tail < (gtt_offset + OA_BUFFER_SIZE)) {
> - stream->oa_buffer.tails[!aged_idx].offset =
> - aging_tail = hw_tail;
> - stream->oa_buffer.aging_timestamp = now;
> - } else {
> - drm_e
[Intel-gfx] ✓ Fi.CI.BAT: success for DP Phy compliance auto test (rev7)
== Series Details == Series: DP Phy compliance auto test (rev7) URL : https://patchwork.freedesktop.org/series/71121/ State : success == Summary == CI Bug Log - changes from CI_DRM_8137 -> Patchwork_16976 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16976/index.html Known issues Here are the changes found in Patchwork_16976 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][1] ([CI#94]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16976/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [FAIL][3] ([i915#217]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16976/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 Participating hosts (48 -> 40) -- Additional (2): fi-skl-6770hq fi-tgl-dsi Missing(10): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-cfl-8700k fi-gdg-551 fi-cfl-8109u fi-skl-lmem fi-bdw-samus fi-byt-clapper fi-skl-6600u Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8137 -> Patchwork_16976 CI-20190529: 20190529 CI_DRM_8137: 5786b5e77cc17a1b494b9bdf3c3f29eedc2e2e7d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5510: e100092d50105463f58db531fa953c70cc58bb10 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16976: 4ad08d0aeb29717115dee440c00328a747dff267 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4ad08d0aeb29 drm/i915/dp: Program vswing, pre-emphasis, test-pattern 4b9c4eccdf1e drm/i915/dp: Register definition for DP compliance register dd3763085c66 drm/i915/dp: Add debugfs entry for DP phy compliance 36b158155387 drm/i915/dp: Preparation for DP phy compliance auto test c73615687108 drm/i915/dp: Made intel_dp_adjust_train() non-static b1d667b9289e drm/dp: get/set phy compliance pattern 8fffd6e04a72 drm/amd/display: Align macro name as per DP spec == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16976/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/4] drm/i915: Move GGTT fence registers under gt/
== Series Details == Series: series starting with [CI,1/4] drm/i915: Move GGTT fence registers under gt/ URL : https://patchwork.freedesktop.org/series/74738/ State : warning == Summary == $ dim checkpatch origin/drm-tip 24d226d21d96 drm/i915: Move GGTT fence registers under gt/ -:47: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #47: rename from drivers/gpu/drm/i915/i915_gem_fence_reg.c total: 0 errors, 1 warnings, 0 checks, 205 lines checked d4f53935c4b1 drm/i915/gt: Pull restoration of GGTT fences underneath the GT 44619e18bb07 drm/i915: Remove manual save/resume of fence register state 03a2376f90fc drm/i915/gt: Allocate i915_fence_reg array ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [CI,1/4] drm/i915: Move GGTT fence registers under gt/
== Series Details == Series: series starting with [CI,1/4] drm/i915: Move GGTT fence registers under gt/ URL : https://patchwork.freedesktop.org/series/74738/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 Error: Cannot open file ./drivers/gpu/drm/i915/i915_gem_fence_reg.c Error: Cannot open file ./drivers/gpu/drm/i915/i915_gem_fence_reg.c Error: Cannot open file ./drivers/gpu/drm/i915/i915_gem_fence_reg.c Error: Cannot open file ./drivers/gpu/drm/i915/i915_gem_fence_reg.c WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/i915/i915_gem_fence_reg.c' failed with return code 2 WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function fence register handling ./drivers/gpu/drm/i915/i915_gem_fence_reg.c' failed with return code 1 WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function tiling swizzling details ./drivers/gpu/drm/i915/i915_gem_fence_reg.c' failed with return code 1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Move GGTT fence registers under gt/
== Series Details == Series: series starting with [CI,1/4] drm/i915: Move GGTT fence registers under gt/ URL : https://patchwork.freedesktop.org/series/74738/ State : success == Summary == CI Bug Log - changes from CI_DRM_8137 -> Patchwork_16977 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16977/index.html Known issues Here are the changes found in Patchwork_16977 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-skl-6700k2: [PASS][1] -> [INCOMPLETE][2] ([i915#69]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-skl-6700k2/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16977/fi-skl-6700k2/igt@gem_exec_susp...@basic-s3.html * igt@i915_selftest@live@gem_contexts: - fi-cml-s: [PASS][3] -> [DMESG-FAIL][4] ([i915#877]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-cml-s/igt@i915_selftest@live@gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16977/fi-cml-s/igt@i915_selftest@live@gem_contexts.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][5] ([CI#94]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16977/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [FAIL][7] ([i915#217]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16977/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html - fi-kbl-7500u: [FAIL][9] ([i915#323]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16977/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 [i915#323]: https://gitlab.freedesktop.org/drm/intel/issues/323 [i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69 [i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877 Participating hosts (48 -> 44) -- Additional (2): fi-skl-6770hq fi-tgl-dsi Missing(6): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-cfl-8700k fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8137 -> Patchwork_16977 CI-20190529: 20190529 CI_DRM_8137: 5786b5e77cc17a1b494b9bdf3c3f29eedc2e2e7d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5510: e100092d50105463f58db531fa953c70cc58bb10 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16977: 03a2376f90fc4cac76b7918c3f92593348ff2e5e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 03a2376f90fc drm/i915/gt: Allocate i915_fence_reg array 44619e18bb07 drm/i915: Remove manual save/resume of fence register state d4f53935c4b1 drm/i915/gt: Pull restoration of GGTT fences underneath the GT 24d226d21d96 drm/i915: Move GGTT fence registers under gt/ == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16977/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Consider DBuf bandwidth when calculating CDCLK
== Series Details ==
Series: Consider DBuf bandwidth when calculating CDCLK
URL : https://patchwork.freedesktop.org/series/74739/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
70a984e1e806 drm/i915: Decouple cdclk calculation from modeset checks
01a1b24738fd drm/i915: Adjust CDCLK accordingly to our DBuf bw needs
-:137: WARNING:LONG_LINE: line over 100 characters
#137: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:2101:
+ DRM_DEBUG_KMS("DBuf bw min cdclk %d current min_cdclk %d\n",
dbuf_bw_cdclk, min_cdclk);
total: 0 errors, 1 warnings, 0 checks, 195 lines checked
a2e501b7cf7c drm/i915: Remove unneeded hack now for CDCLK
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/perf: move pollin setup to non hw specific code
On Thu, 12 Mar 2020 16:05:00 -0700, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin
>
> This isn't really gen specific stuff, so just move it to the common
> code.
It seems pollin is not the only member which is not gen specific but is
initialized in gen specific code. Anyway any other such moves are for
future patches.
> @@ -2626,6 +2620,12 @@ static void gen12_oa_enable(struct i915_perf_stream
> *stream)
> */
> static void i915_oa_stream_enable(struct i915_perf_stream *stream)
> {
> + /*
> + * Maybe make ->pollin per-stream state if we support multiple
> + * concurrent streams in the future.
> + */
> + stream->pollin = false;
What about the comment above? Isn't pollin already per-stream?
Please fix if needed. Otherwise this is:
Reviewed-by: Ashutosh Dixit
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/15] drm/i915: Move GGTT fence registers under gt/
== Series Details ==
Series: series starting with [01/15] drm/i915: Move GGTT fence registers under
gt/
URL : https://patchwork.freedesktop.org/series/74740/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2bf8a0072a07 drm/i915: Move GGTT fence registers under gt/
-:47: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#47:
rename from drivers/gpu/drm/i915/i915_gem_fence_reg.c
total: 0 errors, 1 warnings, 0 checks, 205 lines checked
eb984adc50b0 drm/i915/gt: Pull restoration of GGTT fences underneath the GT
ec7d53e3657f drm/i915: Remove manual save/resume of fence register state
11c6a912a6f4 drm/i915/gt: Allocate i915_fence_reg array
fb9609af3e59 drm/i915/gt: Only wait for GPU activity before unbinding a GGTT
fence
047943aa26dd drm/i915/gt: Store the fence details on the fence
68777e6d26ac drm/i915/gt: Make fence revocation unequivocal
ca73a0e0d45c drm/i915/gem: Drop cached obj->bind_count
-:159: WARNING:LONG_LINE: line over 100 characters
#159: FILE: drivers/gpu/drm/i915/i915_debugfs.c:286:
+ seq_printf(m, "%s: %lu objects, %llu bytes (%llu active, %llu
inactive, %llu closed)\n", \
total: 0 errors, 1 warnings, 0 checks, 228 lines checked
6e568cc647bc drm/i915: Immediately execute the fenced work
0e046d2c468f drm/i915/gem: Assign context id for async work
16a27ae3ea5b drm/i915: Export a preallocate variant of i915_active_acquire()
c447dbfb9f9e drm/i915/gem: Split eb_vma into its own allocation
10bf1fdc1a47 drm/i915/gem: Separate the ww_mutex walker into its own list
-:92: WARNING:LONG_LINE: line over 100 characters
#92: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1568:
+ list_for_each_entry_safe_continue_reverse(unlock, en,
&eb->lock, lock_link) {
-:140: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pos' - possible
side-effects?
#140: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+ n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
-:140: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#140: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+ n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
-:140: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'member' - possible
side-effects?
#140: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+ n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
total: 0 errors, 1 warnings, 3 checks, 120 lines checked
dbdbd5f98bb5 drm/i915/gem: Asynchronous GTT unbinding
671fabf9545b drm/i915/gem: Bind the fence async for execbuf
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Consider DBuf bandwidth when calculating CDCLK
== Series Details == Series: Consider DBuf bandwidth when calculating CDCLK URL : https://patchwork.freedesktop.org/series/74739/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8137 -> Patchwork_16978 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16978 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16978, 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_16978/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16978: ### IGT changes ### Possible regressions * igt@debugfs_test@read_all_entries: - fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-hsw-peppy/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-hsw-peppy/igt@debugfs_test@read_all_entries.html * igt@runner@aborted: - fi-pnv-d510:NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-pnv-d510/igt@run...@aborted.html - fi-hsw-peppy: NOTRUN -> [FAIL][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-hsw-peppy/igt@run...@aborted.html - fi-gdg-551: NOTRUN -> [FAIL][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-gdg-551/igt@run...@aborted.html - fi-snb-2520m: NOTRUN -> [FAIL][6] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-snb-2520m/igt@run...@aborted.html - fi-byt-j1900: NOTRUN -> [FAIL][7] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-byt-j1900/igt@run...@aborted.html - fi-elk-e7500: NOTRUN -> [FAIL][8] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-elk-e7500/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_16978 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-bdw-5557u: [PASS][9] -> [INCOMPLETE][10] ([i915#146]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-bdw-5557u/igt@gem_exec_susp...@basic-s0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-bdw-5557u/igt@gem_exec_susp...@basic-s0.html - fi-bsw-n3050: [PASS][11] -> [INCOMPLETE][12] ([i915#392]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-bsw-n3050/igt@gem_exec_susp...@basic-s0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-bsw-n3050/igt@gem_exec_susp...@basic-s0.html - fi-byt-j1900: [PASS][13] -> [INCOMPLETE][14] ([i915#45]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-byt-j1900/igt@gem_exec_susp...@basic-s0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-byt-j1900/igt@gem_exec_susp...@basic-s0.html * igt@i915_selftest@live@execlists: - fi-apl-guc: [PASS][15] -> [INCOMPLETE][16] ([fdo#103927] / [i915#1430] / [i915#656]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-apl-guc/igt@i915_selftest@l...@execlists.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-apl-guc/igt@i915_selftest@l...@execlists.html - fi-icl-dsi: [PASS][17] -> [INCOMPLETE][18] ([i915#140]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-dsi/igt@i915_selftest@l...@execlists.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-icl-dsi/igt@i915_selftest@l...@execlists.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][19] ([CI#94]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [FAIL][21] ([i915#217]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8137/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16978/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [i915#140]: https://gitlab.freedesktop.org/drm/intel/issues/140 [i915#1430]: https://gitlab.freedesktop.org/drm/intel/issues/1430 [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146 [i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217 [i915#392]: https://
Re: [Intel-gfx] [PATCH 02/10] drm/i915: Adjust PM QoS response frequency based on GPU load.
Francisco Jerez writes: > Tvrtko Ursulin writes: >[...] >> Some time ago we entertained the idea of GPU "load average", where that >> was defined as a count of runnable requests (so batch buffers). How >> that, more generic metric, would behave here if used as an input signal >> really intrigues me. Sadly I don't have a patch ready to give to you and >> ask to please test it. >> >> Or maybe the key is count of runnable contexts as opposed to requests, >> which would more match the ELSP[1] idea. >> >[..] > This patch takes the rather conservative approach of limiting the > application of the response frequency PM QoS request to the more > restrictive set of cases where we are most certain that CPU latency > shouldn't be an issue, in order to avoid regressions. But it might be > that you find the additional energy efficiency benefit from the more > aggressive approach to be worth the cost to a few execlists submission > latency-sensitive applications. I'm trying to get some numbers > comparing the two approaches now, will post them here once I have > results so we can make a more informed trade-off. > I got some results from the promised comparison between the dual-ELSP utilization approach used in this series and the more obvious alternative of keeping track of the time that any request (or context) is in flight. As expected there are quite a few performance improvements (numbers relative to this approach), however most of them are either synthetic benchmarks or off-screen variants of benchmarks (the corresponding on-screen variant of each benchmark below doesn't show a significant improvement): synmark/OglCSDof: XXX ±0.15% x18 -> XXX ±0.22% x12 d=1.15% ±0.18% p=0.00% synmark/OglDeferred: XXX ±0.31% x18 -> XXX ±0.15% x12 d=1.16% ±0.26% p=0.00% synmark/OglTexFilterAniso: XXX ±0.18% x18 -> XXX ±0.21% x12 d=1.25% ±0.19% p=0.00% synmark/OglPSPhong: XXX ±0.43% x18 -> XXX ±0.29% x12 d=1.28% ±0.38% p=0.00% synmark/OglBatch0: XXX ±0.40% x18 -> XXX ±0.53% x12 d=1.29% ±0.46% p=0.00% synmark/OglVSDiffuse8: XXX ±0.49% x17 -> XXX ±0.25% x12 d=1.30% ±0.41% p=0.00% synmark/OglVSTangent: XXX ±0.53% x18 -> XXX ±0.31% x12 d=1.31% ±0.46% p=0.00% synmark/OglGeomPoint: XXX ±0.56% x18 -> XXX ±0.15% x12 d=1.48% ±0.44% p=0.00% gputest/plot3d: XXX ±0.16% x18 -> XXX ±0.11% x12 d=1.50% ±0.14% p=0.00% gputest/tess_x32: XXX ±0.15% x18 -> XXX ±0.06% x12 d=1.59% ±0.13% p=0.00% synmark/OglTexFilterTri: XXX ±0.15% x18 -> XXX ±0.19% x12 d=1.62% ±0.17% p=0.00% synmark/OglBatch3: XXX ±0.57% x18 -> XXX ±0.33% x12 d=1.70% ±0.49% p=0.00% synmark/OglBatch1: XXX ±0.41% x18 -> XXX ±0.34% x12 d=1.81% ±0.38% p=0.00% synmark/OglShMapVsm: XXX ±0.53% x18 -> XXX ±0.38% x12 d=1.81% ±0.48% p=0.00% synmark/OglTexMem128: XXX ±0.62% x18 -> XXX ±0.29% x12 d=1.87% ±0.52% p=0.00% phoronix/x11perf/test=Scrolling 500 x 500 px: XXX ±0.35% x6 -> XXX ±0.56% x12 d=2.23% ±0.52% p=0.00% phoronix/x11perf/test=500px Copy From Window To Window: XXX ±0.00% x3 -> XXX ±0.74% x12 d=2.41% ±0.70% p=0.01% gfxbench/gl_trex_off: XXX ±0.04% x3 -> XXX ±0.34% x12 d=2.59% ±0.32% p=0.00% synmark/OglBatch2: XXX ±0.85% x18 -> XXX ±0.21% x12 d=2.87% ±0.67% p=0.00% glbenchmark/GLB27_EgyptHD_inherited_C24Z16_FixedTime_Offscreen: XXX ±0.35% x3 -> XXX ±0.84% x12 d=3.03% ±0.81% p=0.01% glbenchmark/GLB27_TRex_C24Z16_Offscreen: XXX ±0.23% x3 -> XXX ±0.32% x12
[Intel-gfx] [CI] drm/i915/gt: Restore check for invalid vma for fencing
Apparently we do try and attach a fence to an invalid vma (during
execbuf) so we cannot simply assert it never happens and report EINVAL
instead.
Fixes: dec9cf9ee8cb ("drm/i915/gt: Pull restoration of GGTT fences underneath
the GT")
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index b6ba68c42546..225970f4a4ef 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -233,10 +233,12 @@ static int fence_update(struct i915_fence_reg *fence,
int ret;
if (vma) {
- GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma));
GEM_BUG_ON(!i915_gem_object_get_stride(vma->obj) ||
!i915_gem_object_get_tiling(vma->obj));
+ if (!i915_vma_is_map_and_fenceable(vma))
+ return -EINVAL;
+
ret = i915_vma_sync(vma);
if (ret)
return ret;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
