Re: [Intel-gfx] [PATCH 01/15] drm/i915: Drop pointless dev_priv argument
On Tue, Jan 18, 2022 at 11:23:40AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> skl_ddb_entry_init_from_hw() has no need for dev_priv.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/intel_pm.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 62fde21fac39..7185af0ff205 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4289,8 +4289,7 @@ skl_cursor_allocation(const struct intel_crtc_state
> *crtc_state,
> return max(num_active == 1 ? 32 : 8, min_ddb_alloc);
> }
>
> -static void skl_ddb_entry_init_from_hw(struct drm_i915_private *dev_priv,
> -struct skl_ddb_entry *entry, u32 reg)
> +static void skl_ddb_entry_init_from_hw(struct skl_ddb_entry *entry, u32 reg)
> {
> entry->start = REG_FIELD_GET(PLANE_BUF_START_MASK, reg);
> entry->end = REG_FIELD_GET(PLANE_BUF_END_MASK, reg);
> @@ -4311,7 +4310,7 @@ skl_ddb_get_hw_plane_state(struct drm_i915_private
> *dev_priv,
> /* Cursor doesn't support NV12/planar, so no extra calculation needed */
> if (plane_id == PLANE_CURSOR) {
> val = intel_uncore_read(&dev_priv->uncore, CUR_BUF_CFG(pipe));
> - skl_ddb_entry_init_from_hw(dev_priv, ddb_y, val);
> + skl_ddb_entry_init_from_hw(ddb_y, val);
> return;
> }
>
> @@ -4325,7 +4324,7 @@ skl_ddb_get_hw_plane_state(struct drm_i915_private
> *dev_priv,
>
> if (DISPLAY_VER(dev_priv) >= 11) {
> val = intel_uncore_read(&dev_priv->uncore, PLANE_BUF_CFG(pipe,
> plane_id));
> - skl_ddb_entry_init_from_hw(dev_priv, ddb_y, val);
> + skl_ddb_entry_init_from_hw(ddb_y, val);
> } else {
> val = intel_uncore_read(&dev_priv->uncore, PLANE_BUF_CFG(pipe,
> plane_id));
> val2 = intel_uncore_read(&dev_priv->uncore,
> PLANE_NV12_BUF_CFG(pipe, plane_id));
> @@ -4334,8 +4333,8 @@ skl_ddb_get_hw_plane_state(struct drm_i915_private
> *dev_priv,
> drm_format_info_is_yuv_semiplanar(drm_format_info(fourcc)))
> swap(val, val2);
>
> - skl_ddb_entry_init_from_hw(dev_priv, ddb_y, val);
> - skl_ddb_entry_init_from_hw(dev_priv, ddb_uv, val2);
> + skl_ddb_entry_init_from_hw(ddb_y, val);
> + skl_ddb_entry_init_from_hw(ddb_uv, val2);
> }
> }
>
> --
> 2.32.0
>
Re: [Intel-gfx] [PATCH 02/15] drm/i915: Extract skl_ddb_entry_init()
On Tue, Jan 18, 2022 at 11:23:41AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Extract a small helper to populate a ddb entry.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/intel_pm.c | 44 +++--
> 1 file changed, 25 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 7185af0ff205..9a9d4acb2988 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4058,6 +4058,15 @@ static int intel_compute_sagv_mask(struct
> intel_atomic_state *state)
> return 0;
> }
>
> +static u16 skl_ddb_entry_init(struct skl_ddb_entry *entry,
> + u16 start, u16 end)
> +{
> + entry->start = start;
> + entry->end = end;
> +
> + return end;
> +}
> +
> static int intel_dbuf_slice_size(struct drm_i915_private *dev_priv)
> {
> return INTEL_INFO(dev_priv)->dbuf.size /
> @@ -4196,8 +4205,7 @@ skl_crtc_allocate_ddb(struct intel_atomic_state *state,
> struct intel_crtc *crtc)
> int ret;
>
> if (new_dbuf_state->weight[pipe] == 0) {
> - new_dbuf_state->ddb[pipe].start = 0;
> - new_dbuf_state->ddb[pipe].end = 0;
> + skl_ddb_entry_init(&new_dbuf_state->ddb[pipe], 0, 0);
> goto out;
> }
>
> @@ -4213,8 +4221,10 @@ skl_crtc_allocate_ddb(struct intel_atomic_state
> *state, struct intel_crtc *crtc)
> start = ddb_range_size * weight_start / weight_total;
> end = ddb_range_size * weight_end / weight_total;
>
> - new_dbuf_state->ddb[pipe].start = ddb_slices.start - mbus_offset +
> start;
> - new_dbuf_state->ddb[pipe].end = ddb_slices.start - mbus_offset + end;
> + skl_ddb_entry_init(&new_dbuf_state->ddb[pipe],
> +ddb_slices.start - mbus_offset + start,
> +ddb_slices.start - mbus_offset + end);
> +
> out:
> if (old_dbuf_state->slices[pipe] == new_dbuf_state->slices[pipe] &&
> skl_ddb_entry_equal(&old_dbuf_state->ddb[pipe],
> @@ -4291,8 +4301,9 @@ skl_cursor_allocation(const struct intel_crtc_state
> *crtc_state,
>
> static void skl_ddb_entry_init_from_hw(struct skl_ddb_entry *entry, u32 reg)
> {
> - entry->start = REG_FIELD_GET(PLANE_BUF_START_MASK, reg);
> - entry->end = REG_FIELD_GET(PLANE_BUF_END_MASK, reg);
> + skl_ddb_entry_init(entry,
> +REG_FIELD_GET(PLANE_BUF_START_MASK, reg),
> +REG_FIELD_GET(PLANE_BUF_END_MASK, reg));
> if (entry->end)
> entry->end++;
> }
> @@ -5154,9 +5165,8 @@ skl_allocate_plane_ddb(struct intel_atomic_state *state,
> /* Allocate fixed number of blocks for cursor. */
> total[PLANE_CURSOR] = skl_cursor_allocation(crtc_state, num_active);
> alloc_size -= total[PLANE_CURSOR];
> - crtc_state->wm.skl.plane_ddb_y[PLANE_CURSOR].start =
> - alloc->end - total[PLANE_CURSOR];
> - crtc_state->wm.skl.plane_ddb_y[PLANE_CURSOR].end = alloc->end;
> + skl_ddb_entry_init(&crtc_state->wm.skl.plane_ddb_y[PLANE_CURSOR],
> +alloc->end - total[PLANE_CURSOR], alloc->end);
>
> if (total_data_rate == 0)
> return 0;
> @@ -5257,17 +5267,13 @@ skl_allocate_plane_ddb(struct intel_atomic_state
> *state,
> DISPLAY_VER(dev_priv) >= 11 && uv_total[plane_id]);
>
> /* Leave disabled planes at (0,0) */
> - if (total[plane_id]) {
> - plane_alloc->start = start;
> - start += total[plane_id];
> - plane_alloc->end = start;
> - }
> + if (total[plane_id])
> + start = skl_ddb_entry_init(plane_alloc, start,
> +start + total[plane_id]);
>
> - if (uv_total[plane_id]) {
> - uv_plane_alloc->start = start;
> - start += uv_total[plane_id];
> - uv_plane_alloc->end = start;
> - }
> + if (uv_total[plane_id])
> + start = skl_ddb_entry_init(uv_plane_alloc, start,
> +start + uv_total[plane_id]);
> }
>
> /*
> --
> 2.32.0
>
Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map
On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote: Am 27.01.22 um 08:57 schrieb Lucas De Marchi: On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote: Am 26.01.22 um 21:36 schrieb Lucas De Marchi: When dma_buf_map struct is passed around, it's useful to be able to initialize a second map that takes care of reading/writing to an offset of the original map. Add a helper that copies the struct and add the offset to the proper address. Well what you propose here can lead to all kind of problems and is rather bad design as far as I can see. The struct dma_buf_map is only to be filled in by the exporter and should not be modified in this way by the importer. humn... not sure if I was clear. There is no importer and exporter here. Yeah, and exactly that's what I'm pointing out as problem here. You are using the inter driver framework for something internal to the driver. That is an absolutely clear NAK! We could discuss that, but you guys are just sending around patches to do this without any consensus that this is a good idea. s/you guys/you/ if you have to blame anyone - I'm the only s-o-b in these patches. I'm sending these to _build consensus_ on what may be a good use for it showing a real problem it's helping to fix. From its documentation: * The type :c:type:`struct dma_buf_map ` and its helpers are * actually independent from the dma-buf infrastructure. When sharing buffers * among devices, drivers have to know the location of the memory to access * the buffers in a safe way. :c:type:`struct dma_buf_map ` * solves this problem for dma-buf and its users. If other drivers or * sub-systems require similar functionality, the type could be generalized * and moved to a more prominent header file. if there is no consensus and a better alternative, I'm perfectly fine in throwing it out and using the better approach. Lucas De Marchi
Re: [Intel-gfx] [RFC PATCH] drm/i915: Remove all frontbuffer tracking calls from the gem code
Op 26-01-2022 om 14:09 schreef Jouni Högander:
> We should now rely on userspace doing dirtyfb. There is no
> need to have separate frontbuffer tracking hooks in gem code.
>
> This patch is removing all frontbuffer tracking calls from the gem
> code.
>
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_overlay.c | 2 --
> drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 2 --
> drivers/gpu/drm/i915/gem/i915_gem_domain.c | 5
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 24
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 16 -
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 7 --
> drivers/gpu/drm/i915/i915_gem.c | 5
> 7 files changed, 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
> b/drivers/gpu/drm/i915/display/intel_overlay.c
> index 5358f03b52db..fc2691dac278 100644
> --- a/drivers/gpu/drm/i915/display/intel_overlay.c
> +++ b/drivers/gpu/drm/i915/display/intel_overlay.c
> @@ -809,8 +809,6 @@ static int intel_overlay_do_put_image(struct
> intel_overlay *overlay,
> goto out_pin_section;
> }
>
> - i915_gem_object_flush_frontbuffer(new_bo, ORIGIN_DIRTYFB);
> -
> if (!overlay->active) {
> const struct intel_crtc_state *crtc_state =
> overlay->crtc->config;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> index 8a248003dfae..115e6d877e38 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> @@ -20,8 +20,6 @@ static void __do_clflush(struct drm_i915_gem_object *obj)
> {
> GEM_BUG_ON(!i915_gem_object_has_pages(obj));
> drm_clflush_sg(obj->mm.pages);
> -
> - i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
> }
>
> static void clflush_work(struct dma_fence_work *base)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index 26532c07d467..ab1fc2d930e1 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -63,7 +63,6 @@ flush_write_domain(struct drm_i915_gem_object *obj,
> unsigned int flush_domains)
> }
> spin_unlock(&obj->vma.lock);
>
> - i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
> break;
>
> case I915_GEM_DOMAIN_WC:
> @@ -615,9 +614,6 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
> *data,
> out_unlock:
> i915_gem_object_unlock(obj);
>
> - if (!err && write_domain)
> - i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
> -
> out:
> i915_gem_object_put(obj);
> return err;
> @@ -728,7 +724,6 @@ int i915_gem_object_prepare_write(struct
> drm_i915_gem_object *obj,
> }
>
> out:
> - i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
> obj->mm.dirty = true;
> /* return with the pages pinned */
> return 0;
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 1a9e1f940a7d..f7ba66deb923 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -394,30 +394,6 @@ static void i915_gem_free_object(struct drm_gem_object
> *gem_obj)
> queue_delayed_work(i915->wq, &i915->mm.free_work, 0);
> }
>
> -void __i915_gem_object_flush_frontbuffer(struct drm_i915_gem_object *obj,
> - enum fb_op_origin origin)
> -{
> - struct intel_frontbuffer *front;
> -
> - front = __intel_frontbuffer_get(obj);
> - if (front) {
> - intel_frontbuffer_flush(front, origin);
> - intel_frontbuffer_put(front);
> - }
> -}
> -
> -void __i915_gem_object_invalidate_frontbuffer(struct drm_i915_gem_object
> *obj,
> - enum fb_op_origin origin)
> -{
> - struct intel_frontbuffer *front;
> -
> - front = __intel_frontbuffer_get(obj);
> - if (front) {
> - intel_frontbuffer_invalidate(front, origin);
> - intel_frontbuffer_put(front);
> - }
> -}
> -
> static void
> i915_gem_object_read_from_page_kmap(struct drm_i915_gem_object *obj, u64
> offset, void *dst, int size)
> {
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> index 02c37fe4a535..d7a08172b239 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> @@ -578,22 +578,6 @@ void __i915_gem_object_flush_frontbuffer(struct
> drm_i915_gem_object *obj,
> void __i915_gem_object_invalidate_frontbuffer(struct drm_i915_gem_object
> *obj,
> enum fb_op_origin origin);
>
> -static inline void
> -i915_
Re: [Intel-gfx] [PATCH 03/15] drm/i915: Fix plane relative_data_rate calculation
On Tue, Jan 18, 2022 at 11:23:42AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We are currently computing the relative data rates as
> src_size * scale_factor where scale_factor is src_size / dst_size.
> Thus relative data rate is src_size * src_size / dst_size,
> which is just utter nonsense. What we really seem to want is
> just a reasonable estimate on how much data will be fetched
> which is just src_size. So let's do that instead.
>
> Signed-off-by: Ville Syrjälä
Omg, how could it stay like this all the time?
I actually had similar question, but thought that there just might
be again some magical/empirical heuristics behind this.
Need to challenge more anything, which can't be explained with
BSpec formulas or by common sense...
Reviewed-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/intel_pm.c | 63 ++---
> 1 file changed, 2 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 9a9d4acb2988..e8fb56f288b4 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4373,55 +4373,6 @@ void skl_pipe_ddb_get_hw_state(struct intel_crtc *crtc,
> intel_display_power_put(dev_priv, power_domain, wakeref);
> }
>
> -/*
> - * Determines the downscale amount of a plane for the purposes of watermark
> calculations.
> - * The bspec defines downscale amount as:
> - *
> - * """
> - * Horizontal down scale amount = maximum[1, Horizontal source size /
> - * Horizontal destination size]
> - * Vertical down scale amount = maximum[1, Vertical source size /
> - * Vertical destination size]
> - * Total down scale amount = Horizontal down scale amount *
> - * Vertical down scale amount
> - * """
> - *
> - * Return value is provided in 16.16 fixed point form to retain fractional
> part.
> - * Caller should take care of dividing & rounding off the value.
> - */
> -static uint_fixed_16_16_t
> -skl_plane_downscale_amount(const struct intel_crtc_state *crtc_state,
> -const struct intel_plane_state *plane_state)
> -{
> - struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> - u32 src_w, src_h, dst_w, dst_h;
> - uint_fixed_16_16_t fp_w_ratio, fp_h_ratio;
> - uint_fixed_16_16_t downscale_h, downscale_w;
> -
> - if (drm_WARN_ON(&dev_priv->drm,
> - !intel_wm_plane_visible(crtc_state, plane_state)))
> - return u32_to_fixed16(0);
> -
> - /*
> - * Src coordinates are already rotated by 270 degrees for
> - * the 90/270 degree plane rotation cases (to match the
> - * GTT mapping), hence no need to account for rotation here.
> - *
> - * n.b., src is 16.16 fixed point, dst is whole integer.
> - */
> - src_w = drm_rect_width(&plane_state->uapi.src) >> 16;
> - src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
> - dst_w = drm_rect_width(&plane_state->uapi.dst);
> - dst_h = drm_rect_height(&plane_state->uapi.dst);
> -
> - fp_w_ratio = div_fixed16(src_w, dst_w);
> - fp_h_ratio = div_fixed16(src_h, dst_h);
> - downscale_w = max_fixed16(fp_w_ratio, u32_to_fixed16(1));
> - downscale_h = max_fixed16(fp_h_ratio, u32_to_fixed16(1));
> -
> - return mul_fixed16(downscale_w, downscale_h);
> -}
> -
> struct dbuf_slice_conf_entry {
> u8 active_pipes;
> u8 dbuf_mask[I915_MAX_PIPES];
> @@ -4932,10 +4883,7 @@ skl_plane_relative_data_rate(const struct
> intel_crtc_state *crtc_state,
> {
> struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
> const struct drm_framebuffer *fb = plane_state->hw.fb;
> - u32 data_rate;
> - u32 width = 0, height = 0;
> - uint_fixed_16_16_t down_scale_amount;
> - u64 rate;
> + int width, height;
>
> if (!plane_state->uapi.visible)
> return 0;
> @@ -4961,14 +4909,7 @@ skl_plane_relative_data_rate(const struct
> intel_crtc_state *crtc_state,
> height /= 2;
> }
>
> - data_rate = width * height;
> -
> - down_scale_amount = skl_plane_downscale_amount(crtc_state, plane_state);
> -
> - rate = mul_round_up_u32_fixed16(data_rate, down_scale_amount);
> -
> - rate *= fb->format->cpp[color_plane];
> - return rate;
> + return width * height * fb->format->cpp[color_plane];
> }
>
> static u64
> --
> 2.32.0
>
Re: [Intel-gfx] [PATCH 04/15] drm/i915: Introduce skl_plane_ddb_iter
On Tue, Jan 18, 2022 at 11:23:43AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Collect a bit of the stuff used during the plane ddb
> allocation into a struct we can pass around.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/intel_pm.c | 97 +
> 1 file changed, 49 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index e8fb56f288b4..cd1b5f09f241 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5066,6 +5066,13 @@ static bool icl_need_wm1_wa(struct drm_i915_private
> *i915,
> (IS_DISPLAY_VER(i915, 12, 13) && plane_id == PLANE_CURSOR);
> }
>
> +struct skl_plane_ddb_iter {
> + u64 data_rate;
> + u16 total[I915_MAX_PLANES];
> + u16 uv_total[I915_MAX_PLANES];
> + u16 start, size;
> +};
> +
> static int
> skl_allocate_plane_ddb(struct intel_atomic_state *state,
> struct intel_crtc *crtc)
> @@ -5077,10 +5084,7 @@ skl_allocate_plane_ddb(struct intel_atomic_state
> *state,
> intel_atomic_get_new_dbuf_state(state);
> const struct skl_ddb_entry *alloc = &dbuf_state->ddb[crtc->pipe];
> int num_active = hweight8(dbuf_state->active_pipes);
> - u16 alloc_size, start = 0;
> - u16 total[I915_MAX_PLANES] = {};
> - u16 uv_total[I915_MAX_PLANES] = {};
> - u64 total_data_rate;
> + struct skl_plane_ddb_iter iter = {};
> enum plane_id plane_id;
> u32 blocks;
> int level;
> @@ -5093,23 +5097,21 @@ skl_allocate_plane_ddb(struct intel_atomic_state
> *state,
> return 0;
>
> if (DISPLAY_VER(dev_priv) >= 11)
> - total_data_rate =
> - icl_get_total_relative_data_rate(state, crtc);
> + iter.data_rate = icl_get_total_relative_data_rate(state, crtc);
> else
> - total_data_rate =
> - skl_get_total_relative_data_rate(state, crtc);
> + iter.data_rate = skl_get_total_relative_data_rate(state, crtc);
>
> - alloc_size = skl_ddb_entry_size(alloc);
> - if (alloc_size == 0)
> + iter.size = skl_ddb_entry_size(alloc);
> + if (iter.size == 0)
> return 0;
>
> /* Allocate fixed number of blocks for cursor. */
> - total[PLANE_CURSOR] = skl_cursor_allocation(crtc_state, num_active);
> - alloc_size -= total[PLANE_CURSOR];
> + iter.total[PLANE_CURSOR] = skl_cursor_allocation(crtc_state,
> num_active);
> + iter.size -= iter.total[PLANE_CURSOR];
> skl_ddb_entry_init(&crtc_state->wm.skl.plane_ddb_y[PLANE_CURSOR],
> -alloc->end - total[PLANE_CURSOR], alloc->end);
> +alloc->end - iter.total[PLANE_CURSOR], alloc->end);
>
> - if (total_data_rate == 0)
> + if (iter.data_rate == 0)
> return 0;
>
> /*
> @@ -5123,7 +5125,7 @@ skl_allocate_plane_ddb(struct intel_atomic_state *state,
> &crtc_state->wm.skl.optimal.planes[plane_id];
>
> if (plane_id == PLANE_CURSOR) {
> - if (wm->wm[level].min_ddb_alloc >
> total[PLANE_CURSOR]) {
> + if (wm->wm[level].min_ddb_alloc >
> iter.total[PLANE_CURSOR]) {
> drm_WARN_ON(&dev_priv->drm,
> wm->wm[level].min_ddb_alloc
> != U16_MAX);
> blocks = U32_MAX;
> @@ -5136,8 +5138,8 @@ skl_allocate_plane_ddb(struct intel_atomic_state *state,
> blocks += wm->uv_wm[level].min_ddb_alloc;
> }
>
> - if (blocks <= alloc_size) {
> - alloc_size -= blocks;
> + if (blocks <= iter.size) {
> + iter.size -= blocks;
> break;
> }
> }
> @@ -5146,7 +5148,7 @@ skl_allocate_plane_ddb(struct intel_atomic_state *state,
> drm_dbg_kms(&dev_priv->drm,
> "Requested display configuration exceeds system DDB
> limitations");
> drm_dbg_kms(&dev_priv->drm, "minimum required %d/%d\n",
> - blocks, alloc_size);
> + blocks, iter.size);
> return -EINVAL;
> }
>
> @@ -5158,7 +5160,7 @@ skl_allocate_plane_ddb(struct intel_atomic_state *state,
> for_each_plane_id_on_crtc(crtc, plane_id) {
> const struct skl_plane_wm *wm =
> &crtc_state->wm.skl.optimal.planes[plane_id];
> - u64 rate;
> + u64 data_rate;
> u16 extra;
>
> if (plane_id == PLANE_CURSOR)
> @@ -5168,32 +5170,30 @@ skl_allocate_plane_ddb(struct intel_atomic_state
> *state,
>* We've accounted for all active planes; remaining planes are
>
Re: [Intel-gfx] [PATCH 05/15] drm/i915: Extract skl_allocate_plane_ddb()
On Tue, Jan 18, 2022 at 11:23:44AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace some copy-pasta with a function.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/intel_pm.c | 41 +++--
> 1 file changed, 24 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index cd1b5f09f241..93ff07f6ef26 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5073,9 +5073,24 @@ struct skl_plane_ddb_iter {
> u16 start, size;
> };
>
> +static u16
> +skl_allocate_plane_ddb(struct skl_plane_ddb_iter *iter,
> +const struct skl_wm_level *wm,
> +u64 data_rate)
> +{
> + u16 extra;
> +
> + extra = min_t(u16, iter->size,
> + DIV64_U64_ROUND_UP(iter->size * data_rate,
> iter->data_rate));
> + iter->size -= extra;
> + iter->data_rate -= data_rate;
> +
> + return wm->min_ddb_alloc + extra;
> +}
> +
> static int
> -skl_allocate_plane_ddb(struct intel_atomic_state *state,
> -struct intel_crtc *crtc)
> +skl_crtc_allocate_plane_ddb(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> struct intel_crtc_state *crtc_state =
> @@ -5160,8 +5175,6 @@ skl_allocate_plane_ddb(struct intel_atomic_state *state,
> for_each_plane_id_on_crtc(crtc, plane_id) {
> const struct skl_plane_wm *wm =
> &crtc_state->wm.skl.optimal.planes[plane_id];
> - u64 data_rate;
> - u16 extra;
>
> if (plane_id == PLANE_CURSOR)
> continue;
> @@ -5173,22 +5186,16 @@ skl_allocate_plane_ddb(struct intel_atomic_state
> *state,
> if (iter.data_rate == 0)
> break;
>
> - data_rate = crtc_state->plane_data_rate[plane_id];
> - extra = min_t(u16, iter.size,
> - DIV64_U64_ROUND_UP(iter.size * data_rate,
> iter.data_rate));
> - iter.total[plane_id] = wm->wm[level].min_ddb_alloc + extra;
> - iter.size -= extra;
> - iter.data_rate -= data_rate;
> + iter.total[plane_id] =
> + skl_allocate_plane_ddb(&iter, &wm->wm[level],
> +
> crtc_state->plane_data_rate[plane_id]);
>
> if (iter.data_rate == 0)
> break;
>
> - data_rate = crtc_state->uv_plane_data_rate[plane_id];
> - extra = min_t(u16, iter.size,
> - DIV64_U64_ROUND_UP(iter.size * data_rate,
> iter.data_rate));
> - iter.uv_total[plane_id] = wm->uv_wm[level].min_ddb_alloc +
> extra;
> - iter.size -= extra;
> - iter.data_rate -= data_rate;
> + iter.uv_total[plane_id] =
> + skl_allocate_plane_ddb(&iter, &wm->uv_wm[level],
> +
> crtc_state->uv_plane_data_rate[plane_id]);
> }
> drm_WARN_ON(&dev_priv->drm, iter.size != 0 || iter.data_rate != 0);
>
> @@ -6136,7 +6143,7 @@ skl_compute_ddb(struct intel_atomic_state *state)
>
> for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> - ret = skl_allocate_plane_ddb(state, crtc);
> + ret = skl_crtc_allocate_plane_ddb(state, crtc);
> if (ret)
> return ret;
>
> --
> 2.32.0
>
Re: [Intel-gfx] [PATCH 06/15] drm/i915: Extract skl_crtc_calc_dbuf_bw()
On Tue, Jan 18, 2022 at 11:23:45AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Extract the dbuf slice data_rate calculation into a small
> helper. Should make it a bit easier to handle the different
> color planes of planar formats correctly.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 82 +
> 1 file changed, 44 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index c35bad21b657..f0d6fad048c7 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -672,6 +672,49 @@ intel_atomic_get_bw_state(struct intel_atomic_state
> *state)
> return to_intel_bw_state(bw_state);
> }
>
> +static void skl_crtc_calc_dbuf_bw(struct intel_bw_state *bw_state,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + struct intel_dbuf_bw *crtc_bw = &bw_state->dbuf_bw[crtc->pipe];
> + enum plane_id plane_id;
> +
> + memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
> +
> + if (!crtc_state->hw.active)
> + return;
> +
> + for_each_plane_id_on_crtc(crtc, plane_id) {
> + const struct skl_ddb_entry *ddb_y =
> + &crtc_state->wm.skl.plane_ddb_y[plane_id];
> + const struct skl_ddb_entry *ddb_uv =
> + &crtc_state->wm.skl.plane_ddb_uv[plane_id];
> + unsigned int data_rate = crtc_state->data_rate[plane_id];
> + unsigned int dbuf_mask = 0;
> + enum dbuf_slice slice;
> +
> + dbuf_mask |= skl_ddb_dbuf_slice_mask(i915, ddb_y);
> + dbuf_mask |= skl_ddb_dbuf_slice_mask(i915, ddb_uv);
> +
> + /*
> + * FIXME: To calculate that more properly we probably
> + * need to split per plane data_rate into data_rate_y
> + * and data_rate_uv for multiplanar formats in order not
> + * to get accounted those twice if they happen to reside
> + * on different slices.
> + * However for pre-icl this would work anyway because
> + * we have only single slice and for icl+ uv plane has
> + * non-zero data rate.
> + * So in worst case those calculation are a bit
> + * pessimistic, which shouldn't pose any significant
> + * problem anyway.
> + */
> + for_each_dbuf_slice_in_mask(i915, slice, dbuf_mask)
> + crtc_bw->used_bw[slice] += data_rate;
> + }
> +}
> +
> int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> @@ -684,50 +727,13 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state
> *state)
> int i;
>
> for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
> - enum plane_id plane_id;
> - struct intel_dbuf_bw *crtc_bw;
> -
> new_bw_state = intel_atomic_get_bw_state(state);
> if (IS_ERR(new_bw_state))
> return PTR_ERR(new_bw_state);
>
> old_bw_state = intel_atomic_get_old_bw_state(state);
>
> - crtc_bw = &new_bw_state->dbuf_bw[crtc->pipe];
> -
> - memset(&crtc_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
> -
> - if (!crtc_state->hw.active)
> - continue;
> -
> - for_each_plane_id_on_crtc(crtc, plane_id) {
> - const struct skl_ddb_entry *plane_alloc =
> - &crtc_state->wm.skl.plane_ddb_y[plane_id];
> - const 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];
> - unsigned int dbuf_mask = 0;
> - enum dbuf_slice slice;
> -
> - dbuf_mask |= skl_ddb_dbuf_slice_mask(dev_priv,
> plane_alloc);
> - dbuf_mask |= skl_ddb_dbuf_slice_mask(dev_priv,
> uv_plane_alloc);
> -
> - /*
> - * FIXME: To calculate that more properly we probably
> - * need to to split per plane data_rate into data_rate_y
> - * and data_rate_uv for multiplanar formats in order not
> - * to get accounted those twice if they happen to reside
> - * on different slices.
> - * However for pre-icl this would work anyway because
> - * we have only single slice and for icl+ uv plane has
> - * non-zero da
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/pmu: Fix KMD and GuC race on accessing busyness
== Series Details == Series: series starting with [1/2] drm/i915/pmu: Fix KMD and GuC race on accessing busyness URL : https://patchwork.freedesktop.org/series/99388/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11148_full -> Patchwork_22119_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22119_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22119_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22119_full: ### IGT changes ### Possible regressions * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend: - shard-snb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11148/shard-snb7/igt@kms_vbl...@pipe-a-ts-continuation-dpms-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22119/shard-snb4/igt@kms_vbl...@pipe-a-ts-continuation-dpms-suspend.html Known issues Here are the changes found in Patchwork_22119_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#4843]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11148/shard-skl4/igt@gem_...@in-flight-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22119/shard-skl8/igt@gem_...@in-flight-suspend.html * igt@gem_exec_balancer@parallel-balancer: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11148/shard-iclb1/igt@gem_exec_balan...@parallel-balancer.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22119/shard-iclb7/igt@gem_exec_balan...@parallel-balancer.html * igt@gem_exec_capture@pi@vcs0: - shard-skl: NOTRUN -> [INCOMPLETE][7] ([i915#4547]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22119/shard-skl9/igt@gem_exec_capture@p...@vcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11148/shard-glk9/igt@gem_exec_fair@basic-pace-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22119/shard-glk3/igt@gem_exec_fair@basic-pace-s...@rcs0.html - shard-tglb: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22119/shard-tglb2/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11148/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22119/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_whisper@basic-normal-all: - shard-glk: [PASS][13] -> [DMESG-WARN][14] ([i915#118]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11148/shard-glk2/igt@gem_exec_whis...@basic-normal-all.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22119/shard-glk2/igt@gem_exec_whis...@basic-normal-all.html * igt@gem_lmem_swapping@parallel-random-verify: - shard-kbl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22119/shard-kbl4/igt@gem_lmem_swapp...@parallel-random-verify.html * igt@gem_lmem_swapping@random-engines: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22119/shard-skl1/igt@gem_lmem_swapp...@random-engines.html * igt@gem_lmem_swapping@verify-random: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22119/shard-apl1/igt@gem_lmem_swapp...@verify-random.html * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-y-tiled: - shard-snb: NOTRUN -> [SKIP][18] ([fdo#109271]) +68 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22119/shard-snb6/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-y-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3323]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22119/shard-kbl4/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@input-checking: - shard-skl: NOTRUN -> [DMESG
[Intel-gfx] [PATCH] drm/i915/selftests: fix some error codes in __cancel_reset()
There were two error paths in __cancel_reset() which return success
instead of a negative error code as expected.
Fixes: 4e6835466771 ("drm/i915/selftests: Add a cancel request selftest that
triggers a reset")
Signed-off-by: Dan Carpenter
---
>From static analysis. I am not 100% sure this. Please review extra
carefully!
drivers/gpu/drm/i915/selftests/i915_request.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 2a99dd7c2fe8..05e9f977757b 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -809,7 +809,8 @@ static int __cancel_reset(struct drm_i915_private *i915,
preempt_timeout_ms = engine->props.preempt_timeout_ms;
engine->props.preempt_timeout_ms = 100;
- if (igt_spinner_init(&spin, engine->gt))
+ err = igt_spinner_init(&spin, engine->gt);
+ if (err)
goto out_restore;
ce = intel_context_create(engine);
@@ -838,8 +839,10 @@ static int __cancel_reset(struct drm_i915_private *i915,
}
nop = intel_context_create_request(ce);
- if (IS_ERR(nop))
+ if (IS_ERR(nop)) {
+ err = PTR_ERR(nop);
goto out_rq;
+ }
i915_request_get(nop);
i915_request_add(nop);
--
2.20.1
Re: [Intel-gfx] [PATCH 03/15] drm/i915: Fix plane relative_data_rate calculation
On Thu, Jan 27, 2022 at 10:21:06AM +0200, Lisovskiy, Stanislav wrote:
> On Tue, Jan 18, 2022 at 11:23:42AM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We are currently computing the relative data rates as
> > src_size * scale_factor where scale_factor is src_size / dst_size.
> > Thus relative data rate is src_size * src_size / dst_size,
> > which is just utter nonsense. What we really seem to want is
> > just a reasonable estimate on how much data will be fetched
> > which is just src_size. So let's do that instead.
> >
> > Signed-off-by: Ville Syrjälä
>
> Omg, how could it stay like this all the time?
>
> I actually had similar question, but thought that there just might
> be again some magical/empirical heuristics behind this.
> Need to challenge more anything, which can't be explained with
> BSpec formulas or by common sense...
Yeah, I suspect it's just some kind of brain fart when writing the
spec. I think I filed an issues for it but nothing really happened
IIRC.
>
> Reviewed-by: Stanislav Lisovskiy
>
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 63 ++---
> > 1 file changed, 2 insertions(+), 61 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 9a9d4acb2988..e8fb56f288b4 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4373,55 +4373,6 @@ void skl_pipe_ddb_get_hw_state(struct intel_crtc
> > *crtc,
> > intel_display_power_put(dev_priv, power_domain, wakeref);
> > }
> >
> > -/*
> > - * Determines the downscale amount of a plane for the purposes of
> > watermark calculations.
> > - * The bspec defines downscale amount as:
> > - *
> > - * """
> > - * Horizontal down scale amount = maximum[1, Horizontal source size /
> > - * Horizontal destination size]
> > - * Vertical down scale amount = maximum[1, Vertical source size /
> > - * Vertical destination size]
> > - * Total down scale amount = Horizontal down scale amount *
> > - * Vertical down scale amount
> > - * """
> > - *
> > - * Return value is provided in 16.16 fixed point form to retain fractional
> > part.
> > - * Caller should take care of dividing & rounding off the value.
> > - */
> > -static uint_fixed_16_16_t
> > -skl_plane_downscale_amount(const struct intel_crtc_state *crtc_state,
> > - const struct intel_plane_state *plane_state)
> > -{
> > - struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> > - u32 src_w, src_h, dst_w, dst_h;
> > - uint_fixed_16_16_t fp_w_ratio, fp_h_ratio;
> > - uint_fixed_16_16_t downscale_h, downscale_w;
> > -
> > - if (drm_WARN_ON(&dev_priv->drm,
> > - !intel_wm_plane_visible(crtc_state, plane_state)))
> > - return u32_to_fixed16(0);
> > -
> > - /*
> > -* Src coordinates are already rotated by 270 degrees for
> > -* the 90/270 degree plane rotation cases (to match the
> > -* GTT mapping), hence no need to account for rotation here.
> > -*
> > -* n.b., src is 16.16 fixed point, dst is whole integer.
> > -*/
> > - src_w = drm_rect_width(&plane_state->uapi.src) >> 16;
> > - src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
> > - dst_w = drm_rect_width(&plane_state->uapi.dst);
> > - dst_h = drm_rect_height(&plane_state->uapi.dst);
> > -
> > - fp_w_ratio = div_fixed16(src_w, dst_w);
> > - fp_h_ratio = div_fixed16(src_h, dst_h);
> > - downscale_w = max_fixed16(fp_w_ratio, u32_to_fixed16(1));
> > - downscale_h = max_fixed16(fp_h_ratio, u32_to_fixed16(1));
> > -
> > - return mul_fixed16(downscale_w, downscale_h);
> > -}
> > -
> > struct dbuf_slice_conf_entry {
> > u8 active_pipes;
> > u8 dbuf_mask[I915_MAX_PIPES];
> > @@ -4932,10 +4883,7 @@ skl_plane_relative_data_rate(const struct
> > intel_crtc_state *crtc_state,
> > {
> > struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
> > const struct drm_framebuffer *fb = plane_state->hw.fb;
> > - u32 data_rate;
> > - u32 width = 0, height = 0;
> > - uint_fixed_16_16_t down_scale_amount;
> > - u64 rate;
> > + int width, height;
> >
> > if (!plane_state->uapi.visible)
> > return 0;
> > @@ -4961,14 +4909,7 @@ skl_plane_relative_data_rate(const struct
> > intel_crtc_state *crtc_state,
> > height /= 2;
> > }
> >
> > - data_rate = width * height;
> > -
> > - down_scale_amount = skl_plane_downscale_amount(crtc_state, plane_state);
> > -
> > - rate = mul_round_up_u32_fixed16(data_rate, down_scale_amount);
> > -
> > - rate *= fb->format->cpp[color_plane];
> > - return rate;
> > + return width * height * fb->format->cpp[color_plane];
> > }
> >
> > static u64
> > --
> > 2.32.0
> >
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v2 2/5] mei: add support for graphics system controller (gsc) devices
> -Original Message- > From: Greg Kroah-Hartman > Sent: Wednesday, January 26, 2022 20:06 > To: Usyskin, Alexander > Cc: Jani Nikula ; Joonas Lahtinen > ; Vivi, Rodrigo ; > David Airlie ; Daniel Vetter ; Winkler, > Tomas ; Lubart, Vitaly ; > intel-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org > Subject: Re: [PATCH v2 2/5] mei: add support for graphics system controller > (gsc) devices > > On Wed, Jan 19, 2022 at 05:58:04PM +0200, Alexander Usyskin wrote: > > From: Tomas Winkler > > > > GSC is a graphics system controller, based on CSE, it provides > > a chassis controller for graphics discrete cards, as well as it > > supports media protection on selected devices. > > > > mei_gsc binds to a auxiliary devices exposed by Intel discrete > > driver i915. > > > > Signed-off-by: Alexander Usyskin > > Signed-off-by: Tomas Winkler > > --- > > drivers/misc/mei/Kconfig | 14 +++ > > drivers/misc/mei/Makefile | 3 + > > drivers/misc/mei/gsc-me.c | 192 > ++ > > drivers/misc/mei/hw-me.c | 27 +- > > drivers/misc/mei/hw-me.h | 2 + > > 5 files changed, 236 insertions(+), 2 deletions(-) > > create mode 100644 drivers/misc/mei/gsc-me.c > > > > diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig > > index 0e0bcd0da852..ec119bb98251 100644 > > --- a/drivers/misc/mei/Kconfig > > +++ b/drivers/misc/mei/Kconfig > > @@ -46,6 +46,20 @@ config INTEL_MEI_TXE > > Supported SoCs: > > Intel Bay Trail > > > > +config INTEL_MEI_GSC > > + tristate "Intel MEI GSC embedded device" > > + select INTEL_MEI > > + select INTEL_MEI_ME > > Please don't select, why not just depend on? These are hard dependencies. If user wants to have INTEL_GSC, user should enable INTEL_MEI and INTEL_MEI_ME anyway. INTEL_MEI_ME selects INTEL_MEI in this file and it was taken as example. What is wrong with select? Why to avoid it use? -- Thanks, Sasha > > thanks, > > greg k-h
[Intel-gfx] [PATCH] drm/i915: delete shadow "ret" variable
This "ret" declaration shadows an existing "ret" variable at the top of
the function. Delete it.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/i915_vma.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 0026e85a0a0d..b66591d6e436 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -505,8 +505,6 @@ int i915_vma_bind(struct i915_vma *vma,
work->pinned = i915_gem_object_get(vma->obj);
} else {
if (vma->obj) {
- int ret;
-
ret = i915_gem_object_wait_moving_fence(vma->obj, true);
if (ret) {
i915_vma_resource_free(vma->resource);
--
2.20.1
Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map
Am 27.01.22 um 09:18 schrieb Lucas De Marchi: On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote: Am 27.01.22 um 08:57 schrieb Lucas De Marchi: On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote: Am 26.01.22 um 21:36 schrieb Lucas De Marchi: [SNIP] humn... not sure if I was clear. There is no importer and exporter here. Yeah, and exactly that's what I'm pointing out as problem here. You are using the inter driver framework for something internal to the driver. That is an absolutely clear NAK! We could discuss that, but you guys are just sending around patches to do this without any consensus that this is a good idea. s/you guys/you/ if you have to blame anyone - I'm the only s-o-b in these patches. I'm sending these to _build consensus_ on what may be a good use for it showing a real problem it's helping to fix. Well a cover letter would have been helpful, my impression was that you have a larger set and just want to upstream some minor DMA-buf changes necessary for it. Now I know why people are bugging me all the time to add cover letters to add more context to my sets. From its documentation: * The type :c:type:`struct dma_buf_map ` and its helpers are * actually independent from the dma-buf infrastructure. When sharing buffers * among devices, drivers have to know the location of the memory to access * the buffers in a safe way. :c:type:`struct dma_buf_map ` * solves this problem for dma-buf and its users. If other drivers or * sub-systems require similar functionality, the type could be generalized * and moved to a more prominent header file. if there is no consensus and a better alternative, I'm perfectly fine in throwing it out and using the better approach. When Thomas Zimmermann upstreamed the dma_buf_map work we had a discussion if that shouldn't be independent of the DMA-buf framework. The consensus was that as soon as we have more widely use for it this should be made independent. So basically that is what's happening now. I suggest the following approach: 1. Find a funky name for this, something like iomem_, kiomap_ or similar. 2. Separate this from all you driver dependent work and move the dma_buf_map structure out of DMA-buf into this new whatever_ prefix. 3. Ping Thomas, LKML, me and probably a couple of other core people if this is the right idea or not. 4. Work on dropping the map parameter from dma_buf_vunmap(). This is basically why we can't modify the pointers returned from dma_buf_vmap() and has already cause a few problems with dma_buf_map_incr(). Regards, Christian. Lucas De Marchi
Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map
On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
> Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
> > On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
> > > Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
> > > > When dma_buf_map struct is passed around, it's useful to be able to
> > > > initialize a second map that takes care of reading/writing to an offset
> > > > of the original map.
> > > >
> > > > Add a helper that copies the struct and add the offset to the proper
> > > > address.
> > >
> > > Well what you propose here can lead to all kind of problems and is
> > > rather bad design as far as I can see.
> > >
> > > The struct dma_buf_map is only to be filled in by the exporter and
> > > should not be modified in this way by the importer.
> >
> > humn... not sure if I was clear. There is no importer and exporter here.
>
> Yeah, and exactly that's what I'm pointing out as problem here.
>
> You are using the inter driver framework for something internal to the
> driver. That is an absolutely clear NAK!
>
> We could discuss that, but you guys are just sending around patches to do
> this without any consensus that this is a good idea.
Uh I suggested this, also we're already using dma_buf_map all over the
place as a convenient abstraction. So imo that's all fine, it should allow
drivers to simplify some code where on igpu it's in normal kernel memory
and on dgpu it's behind some pci bar.
Maybe we should have a better name for that struct (and maybe also a
better place), but way back when we discussed that bikeshed I didn't come
up with anything better really.
> > There is a role delegation on filling out and reading a buffer when
> > that buffer represents a struct layout.
> >
> > struct bla {
> > int a;
> > int b;
> > int c;
> > struct foo foo;
> > struct bar bar;
> > int d;
> > }
> >
> >
> > This implementation allows you to have:
> >
> > fill_foo(struct dma_buf_map *bla_map) { ... }
> > fill_bar(struct dma_buf_map *bla_map) { ... }
> >
> > and the first thing these do is to make sure the map it's pointing to
> > is relative to the struct it's supposed to write/read. Otherwise you're
> > suggesting everything to be relative to struct bla, or to do the same
> > I'm doing it, but IMO more prone to error:
> >
> > struct dma_buf_map map = *bla_map;
> > dma_buf_map_incr(map, offsetof(...));
Wrt the issue at hand I think the above is perfectly fine code. The idea
with dma_buf_map is really that it's just a special pointer, so writing
the code exactly as pointer code feels best. Unfortunately you cannot make
them typesafe (because of C), so the code sometimes looks a bit ugly.
Otherwise we could do stuff like container_of and all that with
typechecking in the macros.
-Daniel
> > IMO this construct is worse because at a point in time in the function
> > the map was pointing to the wrong thing the function was supposed to
> > read/write.
> >
> > It's also useful when the function has double duty, updating a global
> > part of the struct and a table inside it (see example in patch 6)
> >
> > thanks
> > Lucas De Marchi
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 01/19] dma-buf-map: Add read/write helpers
On Thu, Jan 27, 2022 at 08:59:36AM +0100, Christian König wrote:
> Am 27.01.22 um 08:36 schrieb Matthew Brost:
> > [SNIP]
> > > >/**
> > > > * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
> > > > * @dst: The dma-buf mapping structure
> > > > @@ -263,4 +304,44 @@ static inline void dma_buf_map_incr(struct
> > > > dma_buf_map *map, size_t incr)
> > > > map->vaddr += incr;
> > > >}
> > > > +/**
> > > > + * dma_buf_map_read_field - Read struct member from dma-buf mapping
> > > > with
> > > > + * arbitrary size and handling un-aligned accesses
> > > > + *
> > > > + * @map__: The dma-buf mapping structure
> > > > + * @type__:The struct to be used containing the field to read
> > > > + * @field__: Member from struct we want to read
> > > > + *
> > > > + * Read a value from dma-buf mapping calculating the offset and size:
> > > > this assumes
> > > > + * the dma-buf mapping is aligned with a a struct type__. A single u8,
> > > > u16, u32
> > > > + * or u64 can be read, based on the offset and size of type__.field__.
> > > > + */
> > > > +#define dma_buf_map_read_field(map__, type__, field__) ({
> > > > \
> > > > + type__ *t__;
> > > > \
> > > > + typeof(t__->field__) val__;
> > > > \
> > > > + dma_buf_map_memcpy_from_offset(&val__, map__, offsetof(type__,
> > > > field__),\
> > > > + sizeof(t__->field__));
> > > > \
> > > > + val__;
> > > > \
> > > > +})
> > > > +
> > > > +/**
> > > > + * dma_buf_map_write_field - Write struct member to the dma-buf
> > > > mapping with
> > > > + * arbitrary size and handling un-aligned accesses
> > > > + *
> > > > + * @map__: The dma-buf mapping structure
> > > > + * @type__:The struct to be used containing the field to write
> > > > + * @field__: Member from struct we want to write
> > > > + * @val__: Value to be written
> > > > + *
> > > > + * Write a value to the dma-buf mapping calculating the offset and
> > > > size.
> > > > + * A single u8, u16, u32 or u64 can be written based on the offset and
> > > > size of
> > > > + * type__.field__.
> > > > + */
> > > > +#define dma_buf_map_write_field(map__, type__, field__, val__) ({
> > > > \
> > > > + type__ *t__;
> > > > \
> > > > + typeof(t__->field__) val = val__;
> > > > \
> > > > + dma_buf_map_memcpy_to_offset(map__, offsetof(type__, field__),
> > > > \
> > > > +&val, sizeof(t__->field__));
> > > > \
> > > > +})
> > > > +
> > > Uff well that absolutely looks like overkill to me.
> > >
> > Hold on...
> >
> > > That's a rather special use case as far as I can see and I think we should
> > > only have this in the common framework if more than one driver is using
> > > it.
> > >
> > I disagree, this is rather elegant.
> >
> > The i915 can't be the *only* driver that defines a struct which
> > describes the layout of a dma_buf object.
>
> That's not the problem, amdgpu as well as nouveau are doing that as well.
> The problem is DMA-buf is a buffer sharing framework between drivers.
>
> In other words which importer is supposed to use this with a DMA-buf
> exported by another device?
>
> > IMO this base macro allows *all* other drivers to build on this write
> > directly to fields in structures those drivers have defined.
>
> Exactly that's the point. This is something drivers should absolutely *NOT*
> do.
>
> That are driver internals and it is extremely questionable to move this into
> the common framework.
See my other reply.
This is about struct dma_buf_map, which is just a tagged pointer.
Which happens to be used by the dma_buf cross-driver interface, but it's
also used plenty internally in buffer allocation helpers, fbdev,
everything else. And it was _meant_ to be used like that - this thing is
my idea, I know :-)
I guess we could move/rename it, but like I said I really don't have any
good ideas. Got some?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave and Daniel, here's this week's PR for drm-misc-fixes. Besides the bug fixes, it contains a backmerge from drm/drm-fixes to get the tree to v5.17-rc1. Best regards Thomas drm-misc-fixes-2022-01-27: * drm/ast: Revert 1600x800 with 108MHz PCLK * drm/atomic: fix CRTC handling during modeset * drm/privacy-screen: Honor acpi=off * drm/ttm: build fix for ARCH=um The following changes since commit e783362eb54cd99b2cac8b3a9aeac942e6f6ac07: Linux 5.17-rc1 (2022-01-23 10:12:53 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-01-27 for you to fetch changes up to 7fde14d705985dd933a3d916d39daa72b1668098: drm/privacy-screen: honor acpi=off in detect_thinkpad_privacy_screen (2022-01-26 15:25:50 +0100) * drm/ast: Revert 1600x800 with 108MHz PCLK * drm/atomic: fix CRTC handling during modeset * drm/privacy-screen: Honor acpi=off * drm/ttm: build fix for ARCH=um Dave Airlie (1): Revert "drm/ast: Support 1600x900 with 108MHz PCLK" Manasi Navare (1): drm/atomic: Add the crtc to affected crtc only if uapi.enable = true Thomas Zimmermann (1): Merge drm/drm-fixes into drm-misc-fixes Tong Zhang (1): drm/privacy-screen: honor acpi=off in detect_thinkpad_privacy_screen drivers/gpu/drm/ast/ast_tables.h | 2 -- drivers/gpu/drm/drm_atomic.c | 12 drivers/gpu/drm/drm_privacy_screen_x86.c | 3 +++ 3 files changed, 11 insertions(+), 6 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Re: [Intel-gfx] [PATCH v2 2/5] mei: add support for graphics system controller (gsc) devices
On Thu, 27 Jan 2022, "Usyskin, Alexander" wrote: >> -Original Message- >> From: Greg Kroah-Hartman >> Sent: Wednesday, January 26, 2022 20:06 >> To: Usyskin, Alexander >> Cc: Jani Nikula ; Joonas Lahtinen >> ; Vivi, Rodrigo ; >> David Airlie ; Daniel Vetter ; Winkler, >> Tomas ; Lubart, Vitaly ; >> intel-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org >> Subject: Re: [PATCH v2 2/5] mei: add support for graphics system controller >> (gsc) devices >> >> On Wed, Jan 19, 2022 at 05:58:04PM +0200, Alexander Usyskin wrote: >> > From: Tomas Winkler >> > >> > GSC is a graphics system controller, based on CSE, it provides >> > a chassis controller for graphics discrete cards, as well as it >> > supports media protection on selected devices. >> > >> > mei_gsc binds to a auxiliary devices exposed by Intel discrete >> > driver i915. >> > >> > Signed-off-by: Alexander Usyskin >> > Signed-off-by: Tomas Winkler >> > --- >> > drivers/misc/mei/Kconfig | 14 +++ >> > drivers/misc/mei/Makefile | 3 + >> > drivers/misc/mei/gsc-me.c | 192 >> ++ >> > drivers/misc/mei/hw-me.c | 27 +- >> > drivers/misc/mei/hw-me.h | 2 + >> > 5 files changed, 236 insertions(+), 2 deletions(-) >> > create mode 100644 drivers/misc/mei/gsc-me.c >> > >> > diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig >> > index 0e0bcd0da852..ec119bb98251 100644 >> > --- a/drivers/misc/mei/Kconfig >> > +++ b/drivers/misc/mei/Kconfig >> > @@ -46,6 +46,20 @@ config INTEL_MEI_TXE >> > Supported SoCs: >> > Intel Bay Trail >> > >> > +config INTEL_MEI_GSC >> > + tristate "Intel MEI GSC embedded device" >> > + select INTEL_MEI >> > + select INTEL_MEI_ME >> >> Please don't select, why not just depend on? > > These are hard dependencies. If user wants to have INTEL_GSC, > user should enable INTEL_MEI and INTEL_MEI_ME anyway. Isn't that exactly what depends on conveys? > INTEL_MEI_ME selects INTEL_MEI in this file and it was taken as example. > > What is wrong with select? Why to avoid it use? Documentation/kbuild/kconfig-language.rst: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. If we followed that rule, we'd have a lot less kconfig dependency issues. If I had the time, I'd add a lint/verbose mode to scripts/kconfig tool to warn about selecting symbols that are visible or have dependencies. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map
On Thu, Jan 27, 2022 at 09:55:05AM +0100, Christian König wrote: Am 27.01.22 um 09:18 schrieb Lucas De Marchi: On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote: Am 27.01.22 um 08:57 schrieb Lucas De Marchi: On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote: Am 26.01.22 um 21:36 schrieb Lucas De Marchi: [SNIP] humn... not sure if I was clear. There is no importer and exporter here. Yeah, and exactly that's what I'm pointing out as problem here. You are using the inter driver framework for something internal to the driver. That is an absolutely clear NAK! We could discuss that, but you guys are just sending around patches to do this without any consensus that this is a good idea. s/you guys/you/ if you have to blame anyone - I'm the only s-o-b in these patches. I'm sending these to _build consensus_ on what may be a good use for it showing a real problem it's helping to fix. Well a cover letter would have been helpful, my impression was that you have a larger set and just want to upstream some minor DMA-buf changes necessary for it. I missed adding this sentence to the cover letter, as my impression was that dma-buf-map was already used outside inter-driver framework. But there is actually a cover letter: https://lore.kernel.org/all/20220126203702.1784589-1-lucas.demar...@intel.com/ And looking at it now, it seems I missed adding Thomas Zimmermann to Cc. Now I know why people are bugging me all the time to add cover letters to add more context to my sets. From its documentation: * The type :c:type:`struct dma_buf_map ` and its helpers are * actually independent from the dma-buf infrastructure. When sharing buffers * among devices, drivers have to know the location of the memory to access * the buffers in a safe way. :c:type:`struct dma_buf_map ` * solves this problem for dma-buf and its users. If other drivers or * sub-systems require similar functionality, the type could be generalized * and moved to a more prominent header file. if there is no consensus and a better alternative, I'm perfectly fine in throwing it out and using the better approach. When Thomas Zimmermann upstreamed the dma_buf_map work we had a discussion if that shouldn't be independent of the DMA-buf framework. The consensus was that as soon as we have more widely use for it this should be made independent. So basically that is what's happening now. I suggest the following approach: 1. Find a funky name for this, something like iomem_, kiomap_ or similar. iosys_map? 2. Separate this from all you driver dependent work and move the dma_buf_map structure out of DMA-buf into this new whatever_ prefix. should this be a follow up to the driver work or a prerequisite? thanks Lucas De Marchi 3. Ping Thomas, LKML, me and probably a couple of other core people if this is the right idea or not. 4. Work on dropping the map parameter from dma_buf_vunmap(). This is basically why we can't modify the pointers returned from dma_buf_vmap() and has already cause a few problems with dma_buf_map_incr(). Regards, Christian. Lucas De Marchi
Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map
Am 27.01.22 um 10:12 schrieb Lucas De Marchi: On Thu, Jan 27, 2022 at 09:55:05AM +0100, Christian König wrote: Am 27.01.22 um 09:18 schrieb Lucas De Marchi: On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote: Am 27.01.22 um 08:57 schrieb Lucas De Marchi: On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote: Am 26.01.22 um 21:36 schrieb Lucas De Marchi: [SNIP] humn... not sure if I was clear. There is no importer and exporter here. Yeah, and exactly that's what I'm pointing out as problem here. You are using the inter driver framework for something internal to the driver. That is an absolutely clear NAK! We could discuss that, but you guys are just sending around patches to do this without any consensus that this is a good idea. s/you guys/you/ if you have to blame anyone - I'm the only s-o-b in these patches. I'm sending these to _build consensus_ on what may be a good use for it showing a real problem it's helping to fix. Well a cover letter would have been helpful, my impression was that you have a larger set and just want to upstream some minor DMA-buf changes necessary for it. I missed adding this sentence to the cover letter, as my impression was that dma-buf-map was already used outside inter-driver framework. But there is actually a cover letter: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20220126203702.1784589-1-lucas.demarchi%40intel.com%2F&data=04%7C01%7Cchristian.koenig%40amd.com%7Cb36def4a6ebd4879731c08d9e1753ccd%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637788715933199161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gwW05OaUq%2FxlBWnY%2FPuPfl0YDdKp5VTbllaSmn45nE8%3D&reserved=0 And looking at it now, it seems I missed adding Thomas Zimmermann to Cc. Now I know why people are bugging me all the time to add cover letters to add more context to my sets. From its documentation: * The type :c:type:`struct dma_buf_map ` and its helpers are * actually independent from the dma-buf infrastructure. When sharing buffers * among devices, drivers have to know the location of the memory to access * the buffers in a safe way. :c:type:`struct dma_buf_map ` * solves this problem for dma-buf and its users. If other drivers or * sub-systems require similar functionality, the type could be generalized * and moved to a more prominent header file. if there is no consensus and a better alternative, I'm perfectly fine in throwing it out and using the better approach. When Thomas Zimmermann upstreamed the dma_buf_map work we had a discussion if that shouldn't be independent of the DMA-buf framework. The consensus was that as soon as we have more widely use for it this should be made independent. So basically that is what's happening now. I suggest the following approach: 1. Find a funky name for this, something like iomem_, kiomap_ or similar. iosys_map? Works for me. 2. Separate this from all you driver dependent work and move the dma_buf_map structure out of DMA-buf into this new whatever_ prefix. should this be a follow up to the driver work or a prerequisite? Prerequisite. Structural changes like this always separate to the actually work switching over to them because the later needs a much fewer audience for review. Regards, Christian. thanks Lucas De Marchi 3. Ping Thomas, LKML, me and probably a couple of other core people if this is the right idea or not. 4. Work on dropping the map parameter from dma_buf_vunmap(). This is basically why we can't modify the pointers returned from dma_buf_vmap() and has already cause a few problems with dma_buf_map_incr(). Regards, Christian. Lucas De Marchi
Re: [Intel-gfx] [PATCH v5 02/10] drm/i915/guc: Add XE_LP registers for GuC error state capture.
On Wed, 26 Jan 2022, "Teres Alexis, Alan Previn"
wrote:
> Thanks Jani for taking the time to review...
>
> 1. apologies on the const issue, this is my bad, i think it was
> one of the comments from earlier rev not sure how i missed it.
> Will fix this on next rev.
>
> 2. I do have a question below on the const for one of specific types
> of tables. Need your thoughts
>
> ...alan
>
>
> On Wed, 2022-01-26 at 20:13 +0200, Jani Nikula wrote:
>> On Wed, 26 Jan 2022, Alan Previn wrote:
>> > Add device specific tables and register lists to cover different engines
>> > class types for GuC error state capture for XE_LP products.
>> >
> ...
>
>> > +static struct __ext_steer_reg xelpd_extregs[] = {
>> > + {"GEN7_SAMPLER_INSTDONE", GEN7_SAMPLER_INSTDONE},
>> > + {"GEN7_ROW_INSTDONE", GEN7_ROW_INSTDONE}
>> > +};
>>
>> Either this needs to be const or, if it needs to be mutable, moved to
>> device specific data.
>>
>> Ditto for all such things all over the place.
>>
>> BR,
>> Jani.
>
>
> I had a question though... the list of registers like the one above as well
> as below shall be made const... however, the table-of-lists (see farther
> down), contains a pointer to "extended_regs"
> that shall be allocated at startup - is it okay for that list to remain
> non-const
> since the others with actual register offsets remain const?
A static mutable array like this is module or driver specific. Your
allocation is device specific.
Sure, you have a check in there with /* already populated */ comment on
the module specific data to avoid allocating it multiple times.
Now, consider probing two devices with different properties. The latter
one will use the stuff you allocated for the first device. It will get
really tricky really quickly.
Pretty much the rule is no static (or global) non-const data for
anything. We do have to make some exceptions, but every one of them adds
to the burden of checking if they're going to be a problem, maybe later
on if not right now. So it's not so much about being const per se, it's
about ensuring we don't screw up with device specific data.
BR,
Jani.
>
> Alan: will add const for this and above tables:
> static struct __guc_mmio_reg_descr xe_lpd_global_regs[] = {
> COMMON_BASE_GLOBAL(),
> COMMON_GEN9BASE_GLOBAL(),
> COMMON_GEN12BASE_GLOBAL(),
> };
>
> Is this okay to not be const?:
> static struct __guc_mmio_reg_descr_group default_lists[] = {
> MAKE_REGLIST(default_global_regs, PF, GLOBAL, 0),
> MAKE_REGLIST(default_rc_class_regs, PF, ENGINE_CLASS,
> GUC_RENDER_CLASS),
> MAKE_REGLIST(xe_lpd_rc_inst_regs, PF, ENGINE_INSTANCE,
> GUC_RENDER_CLASS),
> MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS,
> GUC_VIDEO_CLASS),
> MAKE_REGLIST(xe_lpd_vd_inst_regs, PF, ENGINE_INSTANCE,
> GUC_VIDEO_CLASS),
> MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS,
> GUC_VIDEOENHANCE_CLASS),
> MAKE_REGLIST(xe_lpd_vec_inst_regs, PF, ENGINE_INSTANCE,
> GUC_VIDEOENHANCE_CLASS),
> MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS,
> GUC_BLITTER_CLASS),
> MAKE_REGLIST(xe_lpd_blt_inst_regs, PF, ENGINE_INSTANCE,
> GUC_BLITTER_CLASS),
> {}
> };
>
>
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 00/14] drm/i915: M/N cleanup
From: Ville Syrjälä
Start cleaning up the M/N stuff. Couple of eventual goals:
- fix/enhance DRRS (it's currently in kind of poor state)
- move towards eliminating any RMW stuff from the atomic
commit so that we can start playing around with using
DSB for it, and the DRRS PIPECONF RMWs are a bit in the
way so need to think of a way to avoid them, or at least
make them not race with the atomic commit.
Ville Syrjälä (14):
drm/i915: Extract intel_{get,set}_m_n()
drm/i915: Clean up M/N register defines
drm/i915: s/gmch_{m,n}/data_{m,n}/
drm/i915: Move drrs hardware bit frobbing to small helpers
drm/i915: Make M/N set/get a bit more direct
drm/i915: Move PCH transcoder M/N setup into the PCH code
drm/i915: Move M/N setup to a more logical place on ddi platforms
drm/i915: Extract {i9xx,ilk}_configure_cpu_transcoder()
drm/i915: Add fdi_m2_n2
drm/i915: Program FDI RX TUSIZE2
drm/i915: Dump dp_m2_n2 always
drm/i915: Extract can_enable_drrs()
drm/i915: Set DP M2/N2 equal to M1/N1 when not doing DRRS
drm/i915: Always check dp_m2_n2 on pre-bdw
drivers/gpu/drm/i915/display/g4x_dp.c | 20 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 18 +-
drivers/gpu/drm/i915/display/intel_display.c | 355 --
drivers/gpu/drm/i915/display/intel_display.h | 35 +-
.../drm/i915/display/intel_display_types.h| 21 +-
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 -
drivers/gpu/drm/i915/display/intel_drrs.c | 107 +++---
drivers/gpu/drm/i915/display/intel_fdi.c | 9 +
.../gpu/drm/i915/display/intel_pch_display.c | 56 ++-
.../gpu/drm/i915/display/intel_pch_display.h | 6 +
drivers/gpu/drm/i915/i915_reg.h | 22 +-
12 files changed, 342 insertions(+), 311 deletions(-)
--
2.34.1
[Intel-gfx] [PATCH 01/14] drm/i915: Extract intel_{get,set}_m_n()
From: Ville Syrjälä
Make the M/N setup/readout a bit less repitive by extracting
a few small helpers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 109 ---
1 file changed, 47 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 91add3d85151..f76faa195cb9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3113,6 +3113,17 @@ static void intel_panel_sanitize_ssc(struct
drm_i915_private *dev_priv)
}
}
+static void intel_set_m_n(struct drm_i915_private *i915,
+ const struct intel_link_m_n *m_n,
+ i915_reg_t data_m_reg, i915_reg_t data_n_reg,
+ i915_reg_t link_m_reg, i915_reg_t link_n_reg)
+{
+ intel_de_write(i915, data_m_reg, TU_SIZE(m_n->tu) | m_n->gmch_m);
+ intel_de_write(i915, data_n_reg, m_n->gmch_n);
+ intel_de_write(i915, link_m_reg, m_n->link_m);
+ intel_de_write(i915, link_n_reg, m_n->link_n);
+}
+
static void intel_pch_transcoder_set_m_n(const struct intel_crtc_state
*crtc_state,
const struct intel_link_m_n *m_n)
{
@@ -3120,11 +3131,9 @@ static void intel_pch_transcoder_set_m_n(const struct
intel_crtc_state *crtc_sta
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
- intel_de_write(dev_priv, PCH_TRANS_DATA_M1(pipe),
- TU_SIZE(m_n->tu) | m_n->gmch_m);
- intel_de_write(dev_priv, PCH_TRANS_DATA_N1(pipe), m_n->gmch_n);
- intel_de_write(dev_priv, PCH_TRANS_LINK_M1(pipe), m_n->link_m);
- intel_de_write(dev_priv, PCH_TRANS_LINK_N1(pipe), m_n->link_n);
+ intel_set_m_n(dev_priv, m_n,
+ PCH_TRANS_DATA_M1(pipe), PCH_TRANS_DATA_N1(pipe),
+ PCH_TRANS_LINK_M1(pipe), PCH_TRANS_LINK_N1(pipe));
}
static bool transcoder_has_m2_n2(struct drm_i915_private *dev_priv,
@@ -3150,35 +3159,23 @@ static void intel_cpu_transcoder_set_m_n(const struct
intel_crtc_state *crtc_sta
enum transcoder transcoder = crtc_state->cpu_transcoder;
if (DISPLAY_VER(dev_priv) >= 5) {
- intel_de_write(dev_priv, PIPE_DATA_M1(transcoder),
- TU_SIZE(m_n->tu) | m_n->gmch_m);
- intel_de_write(dev_priv, PIPE_DATA_N1(transcoder),
- m_n->gmch_n);
- intel_de_write(dev_priv, PIPE_LINK_M1(transcoder),
- m_n->link_m);
- intel_de_write(dev_priv, PIPE_LINK_N1(transcoder),
- m_n->link_n);
+ intel_set_m_n(dev_priv, m_n,
+ PIPE_DATA_M1(transcoder),
PIPE_DATA_N1(transcoder),
+ PIPE_LINK_M1(transcoder),
PIPE_LINK_N1(transcoder));
/*
* M2_N2 registers are set only if DRRS is supported
* (to make sure the registers are not unnecessarily accessed).
*/
if (m2_n2 && crtc_state->has_drrs &&
transcoder_has_m2_n2(dev_priv, transcoder)) {
- intel_de_write(dev_priv, PIPE_DATA_M2(transcoder),
- TU_SIZE(m2_n2->tu) | m2_n2->gmch_m);
- intel_de_write(dev_priv, PIPE_DATA_N2(transcoder),
- m2_n2->gmch_n);
- intel_de_write(dev_priv, PIPE_LINK_M2(transcoder),
- m2_n2->link_m);
- intel_de_write(dev_priv, PIPE_LINK_N2(transcoder),
- m2_n2->link_n);
+ intel_set_m_n(dev_priv, m2_n2,
+ PIPE_DATA_M2(transcoder),
PIPE_DATA_N2(transcoder),
+ PIPE_LINK_M2(transcoder),
PIPE_LINK_N2(transcoder));
}
} else {
- intel_de_write(dev_priv, PIPE_DATA_M_G4X(pipe),
- TU_SIZE(m_n->tu) | m_n->gmch_m);
- intel_de_write(dev_priv, PIPE_DATA_N_G4X(pipe), m_n->gmch_n);
- intel_de_write(dev_priv, PIPE_LINK_M_G4X(pipe), m_n->link_m);
- intel_de_write(dev_priv, PIPE_LINK_N_G4X(pipe), m_n->link_n);
+ intel_set_m_n(dev_priv, m_n,
+ PIPE_DATA_M_G4X(pipe), PIPE_DATA_N_G4X(pipe),
+ PIPE_LINK_M_G4X(pipe), PIPE_LINK_N_G4X(pipe));
}
}
@@ -3863,6 +3860,18 @@ int ilk_get_lanes_required(int target_clock, int
link_bw, int bpp)
return DIV_ROUND_UP(bps, link_bw * 8);
}
+static void intel_get_m_n(struct drm_i915_private *i915,
+ struct intel_link_m_n *m_n,
+ i915_reg_t data_m_reg, i915_reg_t
[Intel-gfx] [PATCH 03/14] drm/i915: s/gmch_{m,n}/data_{m,n}/
From: Ville Syrjälä
Rename the gmch_* M/N members to data_* to match the register
definitions and thus make life a little less confusing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
drivers/gpu/drm/i915/display/intel_display.c | 48 ++--
drivers/gpu/drm/i915/display/intel_display.h | 4 +-
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/i915/display/intel_drrs.c| 2 +-
5 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 5d1f7d6218c5..ca8becb07e45 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3684,8 +3684,8 @@ static bool m_n_equal(const struct intel_link_m_n *m_n_1,
const struct intel_link_m_n *m_n_2)
{
return m_n_1->tu == m_n_2->tu &&
- m_n_1->gmch_m == m_n_2->gmch_m &&
- m_n_1->gmch_n == m_n_2->gmch_n &&
+ m_n_1->data_m == m_n_2->data_m &&
+ m_n_1->data_n == m_n_2->data_n &&
m_n_1->link_m == m_n_2->link_m &&
m_n_1->link_n == m_n_2->link_n;
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index d91164d1eb92..75de794185b2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3082,7 +3082,7 @@ intel_link_compute_m_n(u16 bits_per_pixel, int nlanes,
m_n->tu = 64;
compute_m_n(data_clock,
link_clock * nlanes * 8,
- &m_n->gmch_m, &m_n->gmch_n,
+ &m_n->data_m, &m_n->data_n,
constant_n);
compute_m_n(pixel_clock, link_clock,
@@ -3118,8 +3118,8 @@ static void intel_set_m_n(struct drm_i915_private *i915,
i915_reg_t data_m_reg, i915_reg_t data_n_reg,
i915_reg_t link_m_reg, i915_reg_t link_n_reg)
{
- intel_de_write(i915, data_m_reg, TU_SIZE(m_n->tu) | m_n->gmch_m);
- intel_de_write(i915, data_n_reg, m_n->gmch_n);
+ intel_de_write(i915, data_m_reg, TU_SIZE(m_n->tu) | m_n->data_m);
+ intel_de_write(i915, data_n_reg, m_n->data_n);
intel_de_write(i915, link_m_reg, m_n->link_m);
intel_de_write(i915, link_n_reg, m_n->link_n);
}
@@ -3867,8 +3867,8 @@ static void intel_get_m_n(struct drm_i915_private *i915,
{
m_n->link_m = intel_de_read(i915, link_m_reg) & DATA_LINK_M_N_MASK;
m_n->link_n = intel_de_read(i915, link_n_reg) & DATA_LINK_M_N_MASK;
- m_n->gmch_m = intel_de_read(i915, data_m_reg) & DATA_LINK_M_N_MASK;
- m_n->gmch_n = intel_de_read(i915, data_n_reg) & DATA_LINK_M_N_MASK;
+ m_n->data_m = intel_de_read(i915, data_m_reg) & DATA_LINK_M_N_MASK;
+ m_n->data_n = intel_de_read(i915, data_n_reg) & DATA_LINK_M_N_MASK;
m_n->tu = REG_FIELD_GET(TU_SIZE_MASK, intel_de_read(i915, data_m_reg))
+ 1;
}
@@ -5498,9 +5498,9 @@ intel_dump_m_n_config(const struct intel_crtc_state
*pipe_config,
struct drm_i915_private *i915 = to_i915(pipe_config->uapi.crtc->dev);
drm_dbg_kms(&i915->drm,
- "%s: lanes: %i; gmch_m: %u, gmch_n: %u, link_m: %u, link_n:
%u, tu: %u\n",
+ "%s: lanes: %i; data_m: %u, data_n: %u, link_m: %u, link_n:
%u, tu: %u\n",
id, lane_count,
- m_n->gmch_m, m_n->gmch_n,
+ m_n->data_m, m_n->data_n,
m_n->link_m, m_n->link_n, m_n->tu);
}
@@ -6196,8 +6196,8 @@ intel_compare_link_m_n(const struct intel_link_m_n *m_n,
bool exact)
{
return m_n->tu == m2_n2->tu &&
- intel_compare_m_n(m_n->gmch_m, m_n->gmch_n,
- m2_n2->gmch_m, m2_n2->gmch_n, exact) &&
+ intel_compare_m_n(m_n->data_m, m_n->data_n,
+ m2_n2->data_m, m2_n2->data_n, exact) &&
intel_compare_m_n(m_n->link_m, m_n->link_n,
m2_n2->link_m, m2_n2->link_n, exact);
}
@@ -6396,16 +6396,16 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
&pipe_config->name,\
!fastset)) { \
pipe_config_mismatch(fastset, crtc, __stringify(name), \
-"(expected tu %i gmch %i/%i link %i/%i, " \
-"found tu %i, gmch %i/%i link %i/%i)", \
+"(expected tu %i data %i/%i link %i/%i, " \
+"found tu %i, data %i/%i link %i/%i)", \
current_config->name.tu, \
-current_config->name.gmch_m, \
-current_config->name.gmch_n, \
+
[Intel-gfx] [PATCH 02/14] drm/i915: Clean up M/N register defines
From: Ville Syrjälä
Use REG_GENMASK() & co. for the M/N register values. There are
also a lot of weird unused defines (eg. *_OFFSET) we can just
throw out.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 10 -
drivers/gpu/drm/i915/i915_reg.h | 22 +++-
2 files changed, 8 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f76faa195cb9..d91164d1eb92 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3865,11 +3865,11 @@ static void intel_get_m_n(struct drm_i915_private *i915,
i915_reg_t data_m_reg, i915_reg_t data_n_reg,
i915_reg_t link_m_reg, i915_reg_t link_n_reg)
{
- m_n->link_m = intel_de_read(i915, link_m_reg);
- m_n->link_n = intel_de_read(i915, link_n_reg);
- m_n->gmch_m = intel_de_read(i915, data_m_reg) & ~TU_SIZE_MASK;
- m_n->gmch_n = intel_de_read(i915, data_n_reg);
- m_n->tu = ((intel_de_read(i915, data_m_reg) & TU_SIZE_MASK) >>
TU_SIZE_SHIFT) + 1;
+ m_n->link_m = intel_de_read(i915, link_m_reg) & DATA_LINK_M_N_MASK;
+ m_n->link_n = intel_de_read(i915, link_n_reg) & DATA_LINK_M_N_MASK;
+ m_n->gmch_m = intel_de_read(i915, data_m_reg) & DATA_LINK_M_N_MASK;
+ m_n->gmch_n = intel_de_read(i915, data_n_reg) & DATA_LINK_M_N_MASK;
+ m_n->tu = REG_FIELD_GET(TU_SIZE_MASK, intel_de_read(i915, data_m_reg))
+ 1;
}
static void intel_pch_transcoder_get_m_n(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2e4dd9db63fe..ec48406eb37a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5209,16 +5209,14 @@ enum {
#define _PIPEB_DATA_M_G4X 0x71050
/* Transfer unit size for display port - 1, default is 0x3f (for TU size 64) */
-#define TU_SIZE(x) (((x) - 1) << 25) /* default size 64 */
-#define TU_SIZE_SHIFT 25
-#define TU_SIZE_MASK (0x3f << 25)
+#define TU_SIZE_MASK REG_GENMASK(30, 25)
+#define TU_SIZE(x)REG_FIELD_PREP(TU_SIZE_MASK, (x) - 1) /*
default size 64 */
-#define DATA_LINK_M_N_MASK(0xff)
+#define DATA_LINK_M_N_MASKREG_GENMASK(23, 0)
#define DATA_LINK_N_MAX (0x80)
#define _PIPEA_DATA_N_G4X 0x70054
#define _PIPEB_DATA_N_G4X 0x71054
-#define PIPE_GMCH_DATA_N_MASK(0xff)
/*
* Computing Link M and N values for the Display Port link
@@ -5233,11 +5231,8 @@ enum {
#define _PIPEA_LINK_M_G4X 0x70060
#define _PIPEB_LINK_M_G4X 0x71060
-#define PIPEA_DP_LINK_M_MASK (0xff)
-
#define _PIPEA_LINK_N_G4X 0x70064
#define _PIPEB_LINK_N_G4X 0x71064
-#define PIPEA_DP_LINK_N_MASK (0xff)
#define PIPE_DATA_M_G4X(pipe) _MMIO_PIPE(pipe, _PIPEA_DATA_M_G4X,
_PIPEB_DATA_M_G4X)
#define PIPE_DATA_N_G4X(pipe) _MMIO_PIPE(pipe, _PIPEA_DATA_N_G4X,
_PIPEB_DATA_N_G4X)
@@ -6840,24 +6835,13 @@ enum {
#define _PIPEA_DATA_M1 0x60030
-#define PIPE_DATA_M1_OFFSET0
#define _PIPEA_DATA_N1 0x60034
-#define PIPE_DATA_N1_OFFSET0
-
#define _PIPEA_DATA_M2 0x60038
-#define PIPE_DATA_M2_OFFSET0
#define _PIPEA_DATA_N2 0x6003c
-#define PIPE_DATA_N2_OFFSET0
-
#define _PIPEA_LINK_M1 0x60040
-#define PIPE_LINK_M1_OFFSET0
#define _PIPEA_LINK_N1 0x60044
-#define PIPE_LINK_N1_OFFSET0
-
#define _PIPEA_LINK_M2 0x60048
-#define PIPE_LINK_M2_OFFSET0
#define _PIPEA_LINK_N2 0x6004c
-#define PIPE_LINK_N2_OFFSET0
/* PIPEB timing regs are same start from 0x61000 */
--
2.34.1
[Intel-gfx] [PATCH 04/14] drm/i915: Move drrs hardware bit frobbing to small helpers
From: Ville Syrjälä
Split the drrs code that actually changes the refresh rate
(via PIPECONF or M/N values) to small helper functions that
only deal with the hardware details an nothing else. We'll
soon have a third way of doing this, and it's less confusing
when each difference method lives in its own funciton.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_drrs.c | 67 ---
1 file changed, 36 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 46be46f2c47e..0cacdb174fd0 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -87,6 +87,38 @@ intel_drrs_compute_config(struct intel_dp *intel_dp,
pipe_config->dp_m2_n2.data_m *=
pipe_config->splitter.link_count;
}
+static void
+intel_drrs_set_refresh_rate_pipeconf(const struct intel_crtc_state *crtc_state,
+enum drrs_refresh_rate_type refresh_type)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+ u32 val, bit;
+
+ if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+ bit = PIPECONF_EDP_RR_MODE_SWITCH_VLV;
+ else
+ bit = PIPECONF_EDP_RR_MODE_SWITCH;
+
+ val = intel_de_read(dev_priv, PIPECONF(cpu_transcoder));
+
+ if (refresh_type == DRRS_LOW_RR)
+ val |= bit;
+ else
+ val &= ~bit;
+
+ intel_de_write(dev_priv, PIPECONF(cpu_transcoder), val);
+}
+
+static void
+intel_drrs_set_refresh_rate_m_n(const struct intel_crtc_state *crtc_state,
+ enum drrs_refresh_rate_type refresh_type)
+{
+ intel_dp_set_m_n(crtc_state,
+refresh_type == DRRS_LOW_RR ? M2_N2 : M1_N1);
+}
+
static void intel_drrs_set_state(struct drm_i915_private *dev_priv,
const struct intel_crtc_state *crtc_state,
enum drrs_refresh_rate_type refresh_type)
@@ -120,37 +152,10 @@ static void intel_drrs_set_state(struct drm_i915_private
*dev_priv,
return;
}
- if (DISPLAY_VER(dev_priv) >= 8 && !IS_CHERRYVIEW(dev_priv)) {
- switch (refresh_type) {
- case DRRS_HIGH_RR:
- intel_dp_set_m_n(crtc_state, M1_N1);
- break;
- case DRRS_LOW_RR:
- intel_dp_set_m_n(crtc_state, M2_N2);
- break;
- case DRRS_MAX_RR:
- default:
- drm_err(&dev_priv->drm,
- "Unsupported refreshrate type\n");
- }
- } else if (DISPLAY_VER(dev_priv) > 6) {
- i915_reg_t reg = PIPECONF(crtc_state->cpu_transcoder);
- u32 val;
-
- val = intel_de_read(dev_priv, reg);
- if (refresh_type == DRRS_LOW_RR) {
- if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
- val |= PIPECONF_EDP_RR_MODE_SWITCH_VLV;
- else
- val |= PIPECONF_EDP_RR_MODE_SWITCH;
- } else {
- if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
- val &= ~PIPECONF_EDP_RR_MODE_SWITCH_VLV;
- else
- val &= ~PIPECONF_EDP_RR_MODE_SWITCH;
- }
- intel_de_write(dev_priv, reg, val);
- }
+ if (DISPLAY_VER(dev_priv) >= 8 && !IS_CHERRYVIEW(dev_priv))
+ intel_drrs_set_refresh_rate_m_n(crtc_state, refresh_type);
+ else if (DISPLAY_VER(dev_priv) > 6)
+ intel_drrs_set_refresh_rate_pipeconf(crtc_state, refresh_type);
dev_priv->drrs.refresh_rate_type = refresh_type;
--
2.34.1
[Intel-gfx] [PATCH 06/14] drm/i915: Move PCH transcoder M/N setup into the PCH code
From: Ville Syrjälä
Do the PCH transcoder M/N setup next to where all the other
PCH transcoder stuff is programmed.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 92 ---
drivers/gpu/drm/i915/display/intel_display.h | 14 ++-
.../gpu/drm/i915/display/intel_pch_display.c | 48 ++
.../gpu/drm/i915/display/intel_pch_display.h | 6 ++
5 files changed, 83 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
b/drivers/gpu/drm/i915/display/g4x_dp.c
index da2b59d990bb..a08936d8c0e7 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -18,6 +18,7 @@
#include "intel_fifo_underrun.h"
#include "intel_hdmi.h"
#include "intel_hotplug.h"
+#include "intel_pch_display.h"
#include "intel_pps.h"
#include "vlv_sideband.h"
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 3b40a0b0b79e..602ea6d15628 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -118,10 +118,6 @@
static void intel_set_transcoder_timings(const struct intel_crtc_state
*crtc_state);
static void intel_set_pipe_src_size(const struct intel_crtc_state *crtc_state);
-static void intel_pch_transcoder_set_m1_n1(struct intel_crtc *crtc,
- const struct intel_link_m_n *m_n);
-static void intel_pch_transcoder_set_m2_n2(struct intel_crtc *crtc,
- const struct intel_link_m_n *m_n);
static void i9xx_set_pipeconf(const struct intel_crtc_state *crtc_state);
static void ilk_set_pipeconf(const struct intel_crtc_state *crtc_state);
static void hsw_set_transconf(const struct intel_crtc_state *crtc_state);
@@ -1837,26 +1833,18 @@ static void ilk_crtc_enable(struct intel_atomic_state
*state,
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, false);
- if (intel_crtc_has_dp_encoder(new_crtc_state)) {
- if (new_crtc_state->has_pch_encoder) {
- intel_pch_transcoder_set_m1_n1(crtc,
- &new_crtc_state->dp_m_n);
- intel_pch_transcoder_set_m2_n2(crtc,
-
&new_crtc_state->dp_m2_n2);
- } else {
- intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
- &new_crtc_state->dp_m_n);
- intel_cpu_transcoder_set_m2_n2(crtc, cpu_transcoder,
-
&new_crtc_state->dp_m2_n2);
- }
- }
-
- intel_set_transcoder_timings(new_crtc_state);
- intel_set_pipe_src_size(new_crtc_state);
-
- if (new_crtc_state->has_pch_encoder)
+ if (new_crtc_state->has_pch_encoder) {
intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
&new_crtc_state->fdi_m_n);
+ } else if (intel_crtc_has_dp_encoder(new_crtc_state)) {
+ intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
+ &new_crtc_state->dp_m_n);
+ intel_cpu_transcoder_set_m2_n2(crtc, cpu_transcoder,
+ &new_crtc_state->dp_m2_n2);
+ }
+
+ intel_set_transcoder_timings(new_crtc_state);
+ intel_set_pipe_src_size(new_crtc_state);
ilk_set_pipeconf(new_crtc_state);
@@ -3133,10 +3121,10 @@ static void intel_panel_sanitize_ssc(struct
drm_i915_private *dev_priv)
}
}
-static void intel_set_m_n(struct drm_i915_private *i915,
- const struct intel_link_m_n *m_n,
- i915_reg_t data_m_reg, i915_reg_t data_n_reg,
- i915_reg_t link_m_reg, i915_reg_t link_n_reg)
+void intel_set_m_n(struct drm_i915_private *i915,
+ const struct intel_link_m_n *m_n,
+ i915_reg_t data_m_reg, i915_reg_t data_n_reg,
+ i915_reg_t link_m_reg, i915_reg_t link_n_reg)
{
intel_de_write(i915, data_m_reg, TU_SIZE(m_n->tu) | m_n->data_m);
intel_de_write(i915, data_n_reg, m_n->data_n);
@@ -3144,28 +3132,6 @@ static void intel_set_m_n(struct drm_i915_private *i915,
intel_de_write(i915, link_n_reg, m_n->link_n);
}
-static void intel_pch_transcoder_set_m1_n1(struct intel_crtc *crtc,
- const struct intel_link_m_n *m_n)
-{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum pipe pipe = crtc->pipe;
-
- intel_set_m_n(dev_priv, m_n,
- PCH_TRANS_DATA_M1(pipe), PCH_TRANS_DATA_N1(pipe),
- PCH_T
[Intel-gfx] [PATCH 05/14] drm/i915: Make M/N set/get a bit more direct
From: Ville Syrjälä
Throw out the middle-men (dp_{get/set}_m_n()) and just call
the cpu/pch transcoder functions directly. Let's us nuke
this enum link_m_n_set stuff.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 19 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 16 +-
drivers/gpu/drm/i915/display/intel_display.c | 189 +-
drivers/gpu/drm/i915/display/intel_display.h | 23 ++-
.../drm/i915/display/intel_display_types.h| 19 --
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +-
drivers/gpu/drm/i915/display/intel_drrs.c | 7 +-
.../gpu/drm/i915/display/intel_pch_display.c | 6 +-
8 files changed, 153 insertions(+), 130 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
b/drivers/gpu/drm/i915/display/g4x_dp.c
index f37677df6ebf..da2b59d990bb 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -100,6 +100,23 @@ void g4x_dp_set_clock(struct intel_encoder *encoder,
}
}
+static void g4x_dp_get_m_n(struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+
+ if (crtc_state->has_pch_encoder) {
+ intel_pch_transcoder_get_m1_n1(crtc, &crtc_state->dp_m_n);
+ intel_pch_transcoder_get_m2_n2(crtc, &crtc_state->dp_m2_n2);
+ } else {
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+
+ intel_cpu_transcoder_get_m1_n1(crtc, cpu_transcoder,
+ &crtc_state->dp_m_n);
+ intel_cpu_transcoder_get_m2_n2(crtc, cpu_transcoder,
+ &crtc_state->dp_m2_n2);
+ }
+}
+
static void intel_dp_prepare(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config)
{
@@ -384,7 +401,7 @@ static void intel_dp_get_config(struct intel_encoder
*encoder,
pipe_config->lane_count =
((tmp & DP_PORT_WIDTH_MASK) >> DP_PORT_WIDTH_SHIFT) + 1;
- intel_dp_get_m_n(crtc, pipe_config);
+ g4x_dp_get_m_n(pipe_config);
if (port == PORT_A) {
if ((intel_de_read(dev_priv, DP_A) & DP_PLL_FREQ_MASK) ==
DP_PLL_FREQ_162MHZ)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index ca8becb07e45..9bc916d36bd2 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2498,6 +2498,8 @@ static void intel_ddi_pre_enable_dp(struct
intel_atomic_state *state,
const struct drm_connector_state
*conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
if (DISPLAY_VER(dev_priv) >= 12)
tgl_ddi_pre_enable_dp(state, encoder, crtc_state, conn_state);
@@ -2510,7 +2512,10 @@ static void intel_ddi_pre_enable_dp(struct
intel_atomic_state *state,
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)) {
intel_ddi_set_dp_msa(crtc_state, conn_state);
- intel_dp_set_m_n(crtc_state, M1_N1);
+ intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
+ &crtc_state->dp_m_n);
+ intel_cpu_transcoder_set_m2_n2(crtc, cpu_transcoder,
+ &crtc_state->dp_m2_n2);
}
}
@@ -3358,7 +3363,6 @@ static void intel_ddi_read_func_ctl(struct intel_encoder
*encoder,
pipe_config->output_types |= BIT(INTEL_OUTPUT_DP);
pipe_config->lane_count =
((temp & DDI_PORT_WIDTH_MASK) >> DDI_PORT_WIDTH_SHIFT)
+ 1;
- intel_dp_get_m_n(crtc, pipe_config);
if (DISPLAY_VER(dev_priv) >= 11) {
i915_reg_t dp_tp_ctl = dp_tp_ctl_reg(encoder,
pipe_config);
@@ -3372,6 +3376,11 @@ static void intel_ddi_read_func_ctl(struct intel_encoder
*encoder,
pipe_config->fec_enable);
}
+ intel_cpu_transcoder_get_m1_n1(crtc, cpu_transcoder,
+ &pipe_config->dp_m_n);
+ intel_cpu_transcoder_get_m2_n2(crtc, cpu_transcoder,
+ &pipe_config->dp_m2_n2);
+
if (dig_port->lspcon.active && dig_port->dp.has_hdmi_sink)
pipe_config->infoframes.enable |=
intel_lspcon_infoframes_enabled(encoder,
pipe_config);
@@ -3395,7 +3404,8 @@ static void intel_ddi_read_func_ctl(struct intel_encoder
*encoder,
pipe_config->mst_master_transcoder =
REG_FIELD_GET(TRANS_DDI_MST_TRA
Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map
On Thu, Jan 27, 2022 at 09:57:25AM +0100, Daniel Vetter wrote:
On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
> On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
> > Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
> > > When dma_buf_map struct is passed around, it's useful to be able to
> > > initialize a second map that takes care of reading/writing to an offset
> > > of the original map.
> > >
> > > Add a helper that copies the struct and add the offset to the proper
> > > address.
> >
> > Well what you propose here can lead to all kind of problems and is
> > rather bad design as far as I can see.
> >
> > The struct dma_buf_map is only to be filled in by the exporter and
> > should not be modified in this way by the importer.
>
> humn... not sure if I was clear. There is no importer and exporter here.
Yeah, and exactly that's what I'm pointing out as problem here.
You are using the inter driver framework for something internal to the
driver. That is an absolutely clear NAK!
We could discuss that, but you guys are just sending around patches to do
this without any consensus that this is a good idea.
Uh I suggested this, also we're already using dma_buf_map all over the
place as a convenient abstraction. So imo that's all fine, it should allow
drivers to simplify some code where on igpu it's in normal kernel memory
and on dgpu it's behind some pci bar.
Maybe we should have a better name for that struct (and maybe also a
better place), but way back when we discussed that bikeshed I didn't come
up with anything better really.
I suggest iosys_map since it abstracts access to IO and system memory.
> There is a role delegation on filling out and reading a buffer when
> that buffer represents a struct layout.
>
> struct bla {
> int a;
> int b;
> int c;
> struct foo foo;
> struct bar bar;
> int d;
> }
>
>
> This implementation allows you to have:
>
> fill_foo(struct dma_buf_map *bla_map) { ... }
> fill_bar(struct dma_buf_map *bla_map) { ... }
>
> and the first thing these do is to make sure the map it's pointing to
> is relative to the struct it's supposed to write/read. Otherwise you're
> suggesting everything to be relative to struct bla, or to do the same
> I'm doing it, but IMO more prone to error:
>
> struct dma_buf_map map = *bla_map;
> dma_buf_map_incr(map, offsetof(...));
Wrt the issue at hand I think the above is perfectly fine code. The idea
with dma_buf_map is really that it's just a special pointer, so writing
the code exactly as pointer code feels best. Unfortunately you cannot make
them typesafe (because of C), so the code sometimes looks a bit ugly.
Otherwise we could do stuff like container_of and all that with
typechecking in the macros.
I had exactly this code above, but after writting quite a few patches
using it, particularly with functions that have to write to 2 maps (see
patch 6 for example), it felt much better to have something to
initialize correctly from the start
struct dma_buf_map other_map = *bla_map;
/* poor Lucas forgetting dma_buf_map_incr(map, offsetof(...)); */
is error prone and hard to debug since you will be reading/writting
from/to another location rather than exploding
While with the construct below
other_map;
...
other_map = INITIALIZER()
I can rely on the compiler complaining about uninitialized var. And
in most of the cases I can just have this single line in the beggining of the
function when the offset is constant:
struct dma_buf_map other_map = INITIALIZER(bla_map, offsetof(..));
Lucas De Marchi
-Daniel
> IMO this construct is worse because at a point in time in the function
> the map was pointing to the wrong thing the function was supposed to
> read/write.
>
> It's also useful when the function has double duty, updating a global
> part of the struct and a table inside it (see example in patch 6)
>
> thanks
> Lucas De Marchi
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] [PATCH 07/14] drm/i915: Move M/N setup to a more logical place on ddi platforms
From: Ville Syrjälä
Let's do the cpu transcoder M/N setup next to where we program
most other cpu transcoder timings/etc.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 +-
drivers/gpu/drm/i915/display/intel_display.c | 14 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4
3 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9bc916d36bd2..b170ebb387f8 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2498,8 +2498,6 @@ static void intel_ddi_pre_enable_dp(struct
intel_atomic_state *state,
const struct drm_connector_state
*conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
- enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
if (DISPLAY_VER(dev_priv) >= 12)
tgl_ddi_pre_enable_dp(state, encoder, crtc_state, conn_state);
@@ -2509,14 +2507,8 @@ static void intel_ddi_pre_enable_dp(struct
intel_atomic_state *state,
/* MST will call a setting of MSA after an allocating of Virtual Channel
* from MST encoder pre_enable callback.
*/
- if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST)) {
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
intel_ddi_set_dp_msa(crtc_state, conn_state);
-
- intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
- &crtc_state->dp_m_n);
- intel_cpu_transcoder_set_m2_n2(crtc, cpu_transcoder,
- &crtc_state->dp_m2_n2);
- }
}
static void intel_ddi_pre_enable_hdmi(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 602ea6d15628..50dbc2116c14 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2003,16 +2003,22 @@ static void hsw_configure_cpu_transcoder(const struct
intel_crtc_state *crtc_sta
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+ if (crtc_state->has_pch_encoder) {
+ intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
+ &crtc_state->fdi_m_n);
+ } else if (intel_crtc_has_dp_encoder(crtc_state)) {
+ intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
+ &crtc_state->dp_m_n);
+ intel_cpu_transcoder_set_m2_n2(crtc, cpu_transcoder,
+ &crtc_state->dp_m2_n2);
+ }
+
intel_set_transcoder_timings(crtc_state);
if (cpu_transcoder != TRANSCODER_EDP)
intel_de_write(dev_priv, PIPE_MULT(cpu_transcoder),
crtc_state->pixel_multiplier - 1);
- if (crtc_state->has_pch_encoder)
- intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
- &crtc_state->fdi_m_n);
-
hsw_set_frame_start_delay(crtc_state);
hsw_set_transconf(crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 95f9a5c03a47..6b6eab507d30 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -472,7 +472,6 @@ static void intel_mst_pre_enable_dp(struct
intel_atomic_state *state,
struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
struct intel_digital_port *dig_port = intel_mst->primary;
struct intel_dp *intel_dp = &dig_port->dp;
- struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
@@ -523,9 +522,6 @@ static void intel_mst_pre_enable_dp(struct
intel_atomic_state *state,
intel_ddi_enable_pipe_clock(encoder, pipe_config);
intel_ddi_set_dp_msa(pipe_config, conn_state);
-
- intel_cpu_transcoder_set_m1_n1(crtc, pipe_config->cpu_transcoder,
- &pipe_config->dp_m_n);
}
static void intel_mst_enable_dp(struct intel_atomic_state *state,
--
2.34.1
Re: [Intel-gfx] [PATCH 1/3] drm: add writeback pointers to drm_connector
>
> + laurent on this
>
> Hi Suraj
> Jani pointed me to this thread as i had posted something similar here :
> https://patchwork.freedesktop.org/patch/470296/ but since this thread was
> posted earlier, we can discuss further here.
>
> Overall, its similar to what I had posted in the RFC and your commit text also
> covers my concerns too.
>
> One question I have about your change is since you have changed
> wb_connector::encoder to be a pointer, i saw the other changes in the series
> but they do not allocate an encoder. Would this not affect the other drivers
> which are assuming that the encoder in wb_connector is struct drm_encoder
> encoder and not struct drm_encoder* encoder.
>
> Your changes fix the compilation issue but wouldnt this crash as encoder
> wasnt allocated for other drivers.
>
Hi Abhinav,
That shouldn't be an issue as normally drivers tend to have their own output
structure which has drm_connector and drm_encoder embedded in it depending
on the level of binding they have decided to give the connector and encoder in
their respective output and the addresses of these are passed to the
drm_connector* and drm_encoder* in drm_writeback_connector structure
which then gets initialized in drm_writeback_connector_init().
In our i915 code we have intel_connector structure with drm_connector base
field and intel_wd with a intel_encoder base which in turn has drm_encoder
field and both intel_connector and intel_wd are initialized not requiring
explicit
alloc and dealloc for drm_encoder
intel_wd = kzalloc(sizeof(*intel_wd), GFP_KERNEL);
intel_connector = intel_connector_alloc();
wb_conn = &intel_connector->wb_conn;
wb_conn->base = &intel_connector->base;
wb_conn->encoder = &intel_wd->base.base;
Similary for komeda driver has
struct komeda_wb_connector {
struct drm_connector conn;
/** @base: &drm_writeback_connector */
struct drm_writeback_connector base;
/** @wb_layer: represents associated writeback pipeline of komeda */
struct komeda_layer *wb_layer;
};
static int komeda_wb_connector_add(struct komeda_kms_dev *kms,
struct komeda_crtc *kcrtc)
{
struct komeda_wb_connector *kwb_conn;
struct drm_writeback_connector *wb_conn;
kwb_conn = kzalloc(sizeof(*kwb_conn), GFP_KERNEL);
wb_conn = &kwb_conn->base;
wb_conn->base = &kwb_conn->conn;
and they do not depend on the encoder binding so changes will work for them
Also in vkms driver we have the
struct vkms_output {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct drm_connector connector;
struct drm_writeback_connector wb_connector;
struct hrtimer vblank_hrtimer;
ktime_t period_ns;
struct drm_pending_vblank_event *event;
/* ordered wq for composer_work */
struct workqueue_struct *composer_workq;
/* protects concurrent access to composer */
spinlock_t lock;
/* protected by @lock */
bool composer_enabled;
struct vkms_crtc_state *composer_state;
spinlock_t composer_lock;
};
Which gets allocated covering for the drm_encoder alloc and dealloc
Regards,
Suraj Kandpal
[Intel-gfx] [PATCH 09/14] drm/i915: Add fdi_m2_n2
From: Ville Syrjälä
We're going to need M2/N2 for FDI when doing refresh rate switching
with PCH ports. We'll start by setting to match the FDI M1/N1.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 19 +--
drivers/gpu/drm/i915/display/intel_display.h | 2 ++
.../drm/i915/display/intel_display_types.h| 2 +-
drivers/gpu/drm/i915/display/intel_fdi.c | 3 +++
.../gpu/drm/i915/display/intel_pch_display.c | 2 ++
5 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 0a58ecf21b70..8b4d842e2ee0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1815,6 +1815,7 @@ static void ilk_configure_cpu_transcoder(const struct
intel_crtc_state *crtc_sta
if (crtc_state->has_pch_encoder) {
intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
&crtc_state->fdi_m_n);
+ intel_cpu_transcoder_set_m2_n2(crtc, cpu_transcoder,
&crtc_state->fdi_m2_n2);
} else if (intel_crtc_has_dp_encoder(crtc_state)) {
intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
&crtc_state->dp_m_n);
intel_cpu_transcoder_set_m2_n2(crtc, cpu_transcoder,
&crtc_state->dp_m2_n2);
@@ -3143,8 +3144,8 @@ void intel_set_m_n(struct drm_i915_private *i915,
intel_de_write(i915, link_n_reg, m_n->link_n);
}
-static bool transcoder_has_m2_n2(struct drm_i915_private *dev_priv,
-enum transcoder cpu_transcoder)
+bool intel_cpu_transcoder_has_m2_n2(struct drm_i915_private *dev_priv,
+ enum transcoder cpu_transcoder)
{
if (IS_HASWELL(dev_priv))
return cpu_transcoder == TRANSCODER_EDP;
@@ -3175,7 +3176,7 @@ void intel_cpu_transcoder_set_m2_n2(struct intel_crtc
*crtc,
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- if (!transcoder_has_m2_n2(dev_priv, cpu_transcoder))
+ if (!intel_cpu_transcoder_has_m2_n2(dev_priv, cpu_transcoder))
return;
intel_set_m_n(dev_priv, m_n,
@@ -3873,7 +3874,7 @@ void intel_cpu_transcoder_get_m2_n2(struct intel_crtc
*crtc,
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- if (!transcoder_has_m2_n2(dev_priv, cpu_transcoder))
+ if (!intel_cpu_transcoder_has_m2_n2(dev_priv, cpu_transcoder))
return;
intel_get_m_n(dev_priv, m_n,
@@ -5612,10 +5613,14 @@ static void intel_dump_pipe_config(const struct
intel_crtc_state *pipe_config,
pipe_config->splitter.link_count,
pipe_config->splitter.pixel_overlap);
- if (pipe_config->has_pch_encoder)
- intel_dump_m_n_config(pipe_config, "fdi",
+ if (pipe_config->has_pch_encoder) {
+ intel_dump_m_n_config(pipe_config, "fdi m_n",
pipe_config->fdi_lanes,
&pipe_config->fdi_m_n);
+ intel_dump_m_n_config(pipe_config, "fdi m2_n2",
+ pipe_config->fdi_lanes,
+ &pipe_config->fdi_m2_n2);
+ }
if (intel_crtc_has_dp_encoder(pipe_config)) {
intel_dump_m_n_config(pipe_config, "dp m_n",
@@ -6467,6 +6472,7 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_BOOL(has_pch_encoder);
PIPE_CONF_CHECK_I(fdi_lanes);
PIPE_CONF_CHECK_M_N(fdi_m_n);
+ PIPE_CONF_CHECK_M_N(fdi_m2_n2);
PIPE_CONF_CHECK_I(lane_count);
PIPE_CONF_CHECK_X(lane_lat_optim_mask);
@@ -7375,6 +7381,7 @@ static void intel_crtc_copy_fastset(const struct
intel_crtc_state *old_crtc_stat
* FIXME: should really copy more fuzzy state here
*/
new_crtc_state->fdi_m_n = old_crtc_state->fdi_m_n;
+ new_crtc_state->fdi_m2_n2 = old_crtc_state->fdi_m2_n2;
new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
new_crtc_state->has_drrs = old_crtc_state->has_drrs;
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index afa312e11624..71a27285cf99 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -575,6 +575,8 @@ void intel_cpu_transcoder_get_m1_n1(struct intel_crtc *crtc,
void intel_cpu_transcoder_get_m2_n2(struct intel_crtc *crtc,
enum transcoder cpu_transcoder,
struct intel_link_m_n *m_n);
+bool intel_cpu_transcoder_has_m2_n2(struct drm_i915_private *dev_priv,
+ enum transcoder cpu_transcoder);
void intel_plane_destroy(struct drm_plane *plane);
void intel_enable_tr
[Intel-gfx] [PATCH 10/14] drm/i915: Program FDI RX TUSIZE2
From: Ville Syrjälä When using the refresh rate swithching with FDI we must program RXTUSIZE2 in addition to RXTUSIZE1. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_fdi.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c b/drivers/gpu/drm/i915/display/intel_fdi.c index fdbeaf6f38f4..4b634c1d2837 100644 --- a/drivers/gpu/drm/i915/display/intel_fdi.c +++ b/drivers/gpu/drm/i915/display/intel_fdi.c @@ -381,6 +381,8 @@ static void ilk_fdi_link_train(struct intel_crtc *crtc, */ intel_de_write(dev_priv, FDI_RX_TUSIZE1(pipe), intel_de_read(dev_priv, PIPE_DATA_M1(pipe)) & TU_SIZE_MASK); + intel_de_write(dev_priv, FDI_RX_TUSIZE2(pipe), + intel_de_read(dev_priv, PIPE_DATA_M2(pipe)) & TU_SIZE_MASK); /* FDI needs bits from pipe first */ assert_transcoder_enabled(dev_priv, crtc_state->cpu_transcoder); @@ -491,6 +493,8 @@ static void gen6_fdi_link_train(struct intel_crtc *crtc, */ intel_de_write(dev_priv, FDI_RX_TUSIZE1(pipe), intel_de_read(dev_priv, PIPE_DATA_M1(pipe)) & TU_SIZE_MASK); + intel_de_write(dev_priv, FDI_RX_TUSIZE2(pipe), + intel_de_read(dev_priv, PIPE_DATA_M2(pipe)) & TU_SIZE_MASK); /* Train 1: umask FDI RX Interrupt symbol_lock and bit_lock bit for train result */ @@ -637,6 +641,8 @@ static void ivb_manual_fdi_link_train(struct intel_crtc *crtc, */ intel_de_write(dev_priv, FDI_RX_TUSIZE1(pipe), intel_de_read(dev_priv, PIPE_DATA_M1(pipe)) & TU_SIZE_MASK); + intel_de_write(dev_priv, FDI_RX_TUSIZE2(pipe), + intel_de_read(dev_priv, PIPE_DATA_M2(pipe)) & TU_SIZE_MASK); /* Train 1: umask FDI RX Interrupt symbol_lock and bit_lock bit for train result */ -- 2.34.1
[Intel-gfx] [PATCH 08/14] drm/i915: Extract {i9xx, ilk}_configure_cpu_transcoder()
From: Ville Syrjälä
Follow the path laid out by hsw+ and extract helpers to configure
the cpu transcoder for earlier platforms as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 65 +++-
1 file changed, 35 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 50dbc2116c14..0a58ecf21b70 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1808,13 +1808,29 @@ static void intel_disable_primary_plane(const struct
intel_crtc_state *crtc_stat
plane->disable_arm(plane, crtc_state);
}
+static void ilk_configure_cpu_transcoder(const struct intel_crtc_state
*crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+
+ if (crtc_state->has_pch_encoder) {
+ intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
&crtc_state->fdi_m_n);
+ } else if (intel_crtc_has_dp_encoder(crtc_state)) {
+ intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
&crtc_state->dp_m_n);
+ intel_cpu_transcoder_set_m2_n2(crtc, cpu_transcoder,
&crtc_state->dp_m2_n2);
+ }
+
+ intel_set_transcoder_timings(crtc_state);
+
+ ilk_set_pipeconf(crtc_state);
+}
+
static void ilk_crtc_enable(struct intel_atomic_state *state,
struct intel_crtc *crtc)
{
const struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
enum pipe pipe = crtc->pipe;
if (drm_WARN_ON(&dev_priv->drm, crtc->active))
@@ -1833,21 +1849,10 @@ static void ilk_crtc_enable(struct intel_atomic_state
*state,
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, false);
- if (new_crtc_state->has_pch_encoder) {
- intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
- &new_crtc_state->fdi_m_n);
- } else if (intel_crtc_has_dp_encoder(new_crtc_state)) {
- intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
- &new_crtc_state->dp_m_n);
- intel_cpu_transcoder_set_m2_n2(crtc, cpu_transcoder,
- &new_crtc_state->dp_m2_n2);
- }
+ ilk_configure_cpu_transcoder(new_crtc_state);
- intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
- ilk_set_pipeconf(new_crtc_state);
-
crtc->active = true;
intel_encoders_pre_enable(state, crtc);
@@ -2445,26 +2450,34 @@ static void modeset_put_crtc_power_domains(struct
intel_crtc *crtc,
domains);
}
+static void i9xx_configure_cpu_transcoder(const struct intel_crtc_state
*crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+
+ if (intel_crtc_has_dp_encoder(crtc_state)) {
+ intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
&crtc_state->dp_m_n);
+ intel_cpu_transcoder_set_m2_n2(crtc, cpu_transcoder,
&crtc_state->dp_m2_n2);
+ }
+
+ intel_set_transcoder_timings(crtc_state);
+
+ i9xx_set_pipeconf(crtc_state);
+}
+
static void valleyview_crtc_enable(struct intel_atomic_state *state,
struct intel_crtc *crtc)
{
const struct intel_crtc_state *new_crtc_state =
intel_atomic_get_new_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
enum pipe pipe = crtc->pipe;
if (drm_WARN_ON(&dev_priv->drm, crtc->active))
return;
- if (intel_crtc_has_dp_encoder(new_crtc_state)) {
- intel_cpu_transcoder_set_m1_n1(crtc, cpu_transcoder,
- &new_crtc_state->dp_m_n);
- intel_cpu_transcoder_set_m2_n2(crtc, cpu_transcoder,
- &new_crtc_state->dp_m2_n2);
- }
+ i9xx_configure_cpu_transcoder(new_crtc_state);
- intel_set_transcoder_timings(new_crtc_state);
intel_set_pipe_src_size(new_crtc_state);
if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B) {
@@ -2472,8 +2485,6 @@ static void valleyview_crtc_enable(struct
intel_atomic_state *state,
intel_de_write(dev_priv, CHV_CANVAS(pipe), 0);
}
- i9xx_set_pipeconf(new_crtc_state);
-
cr
[Intel-gfx] [PATCH 11/14] drm/i915: Dump dp_m2_n2 always
From: Ville Syrjälä
No point in special casing the dp_m2_n2 dumping. Just do it always.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8b4d842e2ee0..93bb4f577960 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5624,11 +5624,11 @@ static void intel_dump_pipe_config(const struct
intel_crtc_state *pipe_config,
if (intel_crtc_has_dp_encoder(pipe_config)) {
intel_dump_m_n_config(pipe_config, "dp m_n",
- pipe_config->lane_count, &pipe_config->dp_m_n);
- if (pipe_config->has_drrs)
- intel_dump_m_n_config(pipe_config, "dp m2_n2",
- pipe_config->lane_count,
- &pipe_config->dp_m2_n2);
+ pipe_config->lane_count,
+ &pipe_config->dp_m_n);
+ intel_dump_m_n_config(pipe_config, "dp m2_n2",
+ pipe_config->lane_count,
+ &pipe_config->dp_m2_n2);
}
drm_dbg_kms(&dev_priv->drm,
--
2.34.1
[Intel-gfx] [PATCH 13/14] drm/i915: Set DP M2/N2 equal to M1/N1 when not doing DRRS
From: Ville Syrjälä
Make life simpler by always programming DP M2/N2.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_drrs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index c46fcf1e7596..27d0fbf0372e 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -74,10 +74,14 @@ intel_drrs_compute_config(struct intel_dp *intel_dp,
int output_bpp, bool constant_n)
{
struct intel_connector *connector = intel_dp->attached_connector;
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
int pixel_clock;
- if (!can_enable_drrs(connector, pipe_config))
+ if (!can_enable_drrs(connector, pipe_config)) {
+ if (intel_cpu_transcoder_has_m2_n2(i915,
pipe_config->cpu_transcoder))
+ pipe_config->dp_m2_n2 = pipe_config->dp_m_n;
return;
+ }
pipe_config->has_drrs = true;
--
2.34.1
[Intel-gfx] [PATCH 14/14] drm/i915: Always check dp_m2_n2 on pre-bdw
From: Ville Syrjälä
No point in special casing the check of dp_m2_n2 on pre-bdw platforms.
Either the transcoder has M2/N2 in which case the values should be
set to something sensible, or it doesn't in which case dp_m2_n2 is
always zeroed.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 93bb4f577960..4464beb2ce68 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6477,13 +6477,12 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_I(lane_count);
PIPE_CONF_CHECK_X(lane_lat_optim_mask);
- if (DISPLAY_VER(dev_priv) < 8) {
- PIPE_CONF_CHECK_M_N(dp_m_n);
-
- if (current_config->has_drrs)
- PIPE_CONF_CHECK_M_N(dp_m2_n2);
- } else
+ if (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv)) {
PIPE_CONF_CHECK_M_N_ALT(dp_m_n, dp_m2_n2);
+ } else {
+ PIPE_CONF_CHECK_M_N(dp_m_n);
+ PIPE_CONF_CHECK_M_N(dp_m2_n2);
+ }
PIPE_CONF_CHECK_X(output_types);
--
2.34.1
[Intel-gfx] [PATCH 12/14] drm/i915: Extract can_enable_drrs()
From: Ville Syrjälä
Pull the "can we do DRRS?" check into helper in order
to reduce the clutter in intel_drrs_compute_config().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_drrs.c | 31 ++-
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 53f014b4436b..c46fcf1e7596 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -47,17 +47,13 @@
* requested by userspace.
*/
-void
-intel_drrs_compute_config(struct intel_dp *intel_dp,
- struct intel_crtc_state *pipe_config,
- int output_bpp, bool constant_n)
+static bool can_enable_drrs(struct intel_connector *connector,
+ const struct intel_crtc_state *pipe_config)
{
- struct intel_connector *intel_connector = intel_dp->attached_connector;
- struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- int pixel_clock;
+ const struct drm_i915_private *i915 = to_i915(connector->base.dev);
if (pipe_config->vrr.enable)
- return;
+ return false;
/*
* DRRS and PSR can't be enable together, so giving preference to PSR
@@ -66,15 +62,26 @@ intel_drrs_compute_config(struct intel_dp *intel_dp,
* after intel_psr_compute_config().
*/
if (pipe_config->has_psr)
- return;
+ return false;
- if (!intel_connector->panel.downclock_mode ||
- dev_priv->drrs.type != SEAMLESS_DRRS_SUPPORT)
+ return connector->panel.downclock_mode &&
+ i915->drrs.type == SEAMLESS_DRRS_SUPPORT;
+}
+
+void
+intel_drrs_compute_config(struct intel_dp *intel_dp,
+ struct intel_crtc_state *pipe_config,
+ int output_bpp, bool constant_n)
+{
+ struct intel_connector *connector = intel_dp->attached_connector;
+ int pixel_clock;
+
+ if (!can_enable_drrs(connector, pipe_config))
return;
pipe_config->has_drrs = true;
- pixel_clock = intel_connector->panel.downclock_mode->clock;
+ pixel_clock = connector->panel.downclock_mode->clock;
if (pipe_config->splitter.enable)
pixel_clock /= pipe_config->splitter.link_count;
--
2.34.1
Re: [Intel-gfx] [PATCH v5 1/5] drm/i915: add needs_compact_pt flag
On 1/26/22 18:11, Robert Beckett wrote: On 26/01/2022 13:49, Thomas Hellström (Intel) wrote: On 1/25/22 20:35, Robert Beckett wrote: From: Ramalingam C Add a new platform flag, needs_compact_pt, to mark the requirement of compact pt layout support for the ppGTT when using 64K GTT pages. With this flag has_64k_pages will only indicate requirement of 64K GTT page sizes or larger for device local memory access. Suggested-by: Matthew Auld Signed-off-by: Ramalingam C Signed-off-by: Robert Beckett --- drivers/gpu/drm/i915/i915_drv.h | 10 +++--- drivers/gpu/drm/i915/i915_pci.c | 2 ++ drivers/gpu/drm/i915/intel_device_info.h | 1 + 3 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 44c1f98144b4..1258b7779705 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1512,12 +1512,16 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915, /* * Set this flag, when platform requires 64K GTT page sizes or larger for - * device local memory access. Also this flag implies that we require or - * at least support the compact PT layout for the ppGTT when using the 64K - * GTT pages. Why do we remove these comment lines? Because HAS_64K_PAGES now means just 64K page, it no longer means also requires compact pt. This is to support other products that will have 64K but not have the PDE non-sharing restriction in future. Those lines moved to the next change NEEDS_COMPACT_PT, which is now separate. Yes, NEEDS_COMPACT_PT indicates that compact is *required* but does "HAS_64K_PAGES" still mean compact is supported? That information is lost. /Thomas
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/adlp: Fix TypeC PHY-ready status readout
== Series Details == Series: drm/i915/adlp: Fix TypeC PHY-ready status readout URL : https://patchwork.freedesktop.org/series/99359/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11145_full -> Patchwork_22111_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22111_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22111_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22111_full: ### IGT changes ### Possible regressions * igt@kms_plane@plane-position-hole-dpms@pipe-b-planes: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11145/shard-tglb1/igt@kms_plane@plane-position-hole-d...@pipe-b-planes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22111/shard-tglb3/igt@kms_plane@plane-position-hole-d...@pipe-b-planes.html Known issues Here are the changes found in Patchwork_22111_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22111/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_eio@unwedge-stress: - shard-skl: [PASS][4] -> [TIMEOUT][5] ([i915#3063]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11145/shard-skl5/igt@gem_...@unwedge-stress.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22111/shard-skl6/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@parallel-keep-submit-fence: - shard-iclb: [PASS][6] -> [SKIP][7] ([i915#4525]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11145/shard-iclb2/igt@gem_exec_balan...@parallel-keep-submit-fence.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22111/shard-iclb7/igt@gem_exec_balan...@parallel-keep-submit-fence.html * igt@gem_exec_capture@pi@bcs0: - shard-skl: NOTRUN -> [INCOMPLETE][8] ([i915#4547]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22111/shard-skl8/igt@gem_exec_capture@p...@bcs0.html * igt@gem_exec_fair@basic-none@rcs0: - shard-glk: NOTRUN -> [FAIL][9] ([i915#2842]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22111/shard-glk1/igt@gem_exec_fair@basic-n...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][10] -> [FAIL][11] ([i915#2842]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11145/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22111/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11145/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22111/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-iclb: NOTRUN -> [FAIL][14] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22111/shard-iclb2/igt@gem_exec_fair@basic-pace-s...@rcs0.html - shard-tglb: NOTRUN -> [FAIL][15] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22111/shard-tglb8/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_whisper@basic-queues: - shard-glk: [PASS][16] -> [DMESG-WARN][17] ([i915#118]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11145/shard-glk3/igt@gem_exec_whis...@basic-queues.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22111/shard-glk2/igt@gem_exec_whis...@basic-queues.html * igt@gem_lmem_swapping@basic: - shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22111/shard-skl9/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random: - shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22111/shard-kbl7/igt@gem_lmem_swapp...@parallel-random.html * igt@gem_lmem_swapping@random-engines: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork
Re: [Intel-gfx] mmotm 2022-01-26-21-04 uploaded (gpu/drm/i915/i915_gem_evict.h)
On Wed, 26 Jan 2022, Randy Dunlap wrote: > On 1/26/22 21:04, a...@linux-foundation.org wrote: >> The mm-of-the-moment snapshot 2022-01-26-21-04 has been uploaded to >> >>https://www.ozlabs.org/~akpm/mmotm/ >> >> mmotm-readme.txt says >> >> README for mm-of-the-moment: >> >> https://www.ozlabs.org/~akpm/mmotm/ >> >> This is a snapshot of my -mm patch queue. Uploaded at random hopefully >> more than once a week. >> >> You will need quilt to apply these patches to the latest Linus release (5.x >> or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in >> https://ozlabs.org/~akpm/mmotm/series >> >> The file broken-out.tar.gz contains two datestamp files: .DATE and >> .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, >> followed by the base kernel version against which this patch series is to >> be applied. > > on x86_64: > (from linux-next.patch) > > > HDRTEST drivers/gpu/drm/i915/i915_gem_evict.h > In file included from :0:0: > ./../drivers/gpu/drm/i915/i915_gem_evict.h:15:15: error: ‘struct > i915_gem_ww_ctx’ declared inside parameter list will not be visible outside > of this definition or declaration [-Werror] > struct i915_gem_ww_ctx *ww, >^~~ > ./../drivers/gpu/drm/i915/i915_gem_evict.h:21:14: error: ‘struct > i915_gem_ww_ctx’ declared inside parameter list will not be visible outside > of this definition or declaration [-Werror] >struct i915_gem_ww_ctx *ww, > ^~~ > ./../drivers/gpu/drm/i915/i915_gem_evict.h:25:16: error: ‘struct > i915_gem_ww_ctx’ declared inside parameter list will not be visible outside > of this definition or declaration [-Werror] > struct i915_gem_ww_ctx *ww); > ^~~ > cc1: all warnings being treated as errors Thanks for the report. This is only visible with CONFIG_DRM_I915_WERROR=y which depends on COMPILE_TEST=n. We use the "HDRTEST" and -Werror for development and CI to keep the driver clean, but it's not really intended for general consumption. Usually when something like this even hits the tree it's because of a merge mishap somewhere down the line. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: fix some error codes in __cancel_reset()
== Series Details == Series: drm/i915/selftests: fix some error codes in __cancel_reset() URL : https://patchwork.freedesktop.org/series/99407/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11149 -> Patchwork_22120 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22120 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22120, 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_22120/index.html Participating hosts (45 -> 39) -- Missing(6): fi-kbl-soraka fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510 fi-bdw-samus Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22120: ### IGT changes ### Possible regressions * igt@gem_exec_suspend@basic-s0@smem: - fi-snb-2600:[PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/fi-snb-2600/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22120/fi-snb-2600/igt@gem_exec_suspend@basic...@smem.html Known issues Here are the changes found in Patchwork_22120 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@cs-gfx: - fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#109315]) +17 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22120/fi-hsw-4770/igt@amdgpu/amd_ba...@cs-gfx.html * igt@i915_selftest@live: - fi-skl-6600u: NOTRUN -> [FAIL][4] ([i915#4547]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22120/fi-skl-6600u/igt@i915_selft...@live.html * igt@i915_selftest@live@hangcheck: - bat-dg1-6: [PASS][5] -> [DMESG-FAIL][6] ([i915#4494] / [i915#4957]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22120/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html * igt@prime_vgem@basic-userptr: - fi-skl-6600u: NOTRUN -> [SKIP][7] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22120/fi-skl-6600u/igt@prime_v...@basic-userptr.html Possible fixes * igt@i915_selftest@live@hangcheck: - fi-hsw-4770:[INCOMPLETE][8] ([i915#4785]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22120/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html * igt@kms_psr@primary_page_flip: - fi-skl-6600u: [FAIL][10] ([i915#4547]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/fi-skl-6600u/igt@kms_psr@primary_page_flip.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22120/fi-skl-6600u/igt@kms_psr@primary_page_flip.html Warnings * igt@i915_selftest@live@hangcheck: - bat-dg1-5: [DMESG-FAIL][12] ([i915#4957]) -> [DMESG-FAIL][13] ([i915#4494] / [i915#4957]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22120/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html * igt@runner@aborted: - fi-skl-6600u: [FAIL][14] ([i915#4312]) -> [FAIL][15] ([i915#1436] / [i915#4312]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/fi-skl-6600u/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22120/fi-skl-6600u/igt@run...@aborted.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312 [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494 [i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547 [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785 [i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957 Build changes - * Linux: CI_DRM_11149 -> Patchwork_22120 CI-20190529: 20190529 CI_DRM_11149: 626b06cccf398c25e95dc0534ad018193005ad1b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6336: ae2eb9e18bc58a4c45f28cfd80962938198dec3c @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_22120: c9d418d80bc202415534bf3ff6da904dc6ec109d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c9d418d80bc2 drm/i915/selftests: fix some error codes
Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map
On Thu, Jan 27, 2022 at 01:33:32AM -0800, Lucas De Marchi wrote:
> On Thu, Jan 27, 2022 at 09:57:25AM +0100, Daniel Vetter wrote:
> > On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
> > > Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
> > > > On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
> > > > > Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
> > > > > > When dma_buf_map struct is passed around, it's useful to be able to
> > > > > > initialize a second map that takes care of reading/writing to an
> > > > > > offset
> > > > > > of the original map.
> > > > > >
> > > > > > Add a helper that copies the struct and add the offset to the proper
> > > > > > address.
> > > > >
> > > > > Well what you propose here can lead to all kind of problems and is
> > > > > rather bad design as far as I can see.
> > > > >
> > > > > The struct dma_buf_map is only to be filled in by the exporter and
> > > > > should not be modified in this way by the importer.
> > > >
> > > > humn... not sure if I was clear. There is no importer and exporter
> > > > here.
> > >
> > > Yeah, and exactly that's what I'm pointing out as problem here.
> > >
> > > You are using the inter driver framework for something internal to the
> > > driver. That is an absolutely clear NAK!
> > >
> > > We could discuss that, but you guys are just sending around patches to do
> > > this without any consensus that this is a good idea.
> >
> > Uh I suggested this, also we're already using dma_buf_map all over the
> > place as a convenient abstraction. So imo that's all fine, it should allow
> > drivers to simplify some code where on igpu it's in normal kernel memory
> > and on dgpu it's behind some pci bar.
> >
> > Maybe we should have a better name for that struct (and maybe also a
> > better place), but way back when we discussed that bikeshed I didn't come
> > up with anything better really.
>
> I suggest iosys_map since it abstracts access to IO and system memory.
>
> >
> > > > There is a role delegation on filling out and reading a buffer when
> > > > that buffer represents a struct layout.
> > > >
> > > > struct bla {
> > > > int a;
> > > > int b;
> > > > int c;
> > > > struct foo foo;
> > > > struct bar bar;
> > > > int d;
> > > > }
> > > >
> > > >
> > > > This implementation allows you to have:
> > > >
> > > > fill_foo(struct dma_buf_map *bla_map) { ... }
> > > > fill_bar(struct dma_buf_map *bla_map) { ... }
> > > >
> > > > and the first thing these do is to make sure the map it's pointing to
> > > > is relative to the struct it's supposed to write/read. Otherwise you're
> > > > suggesting everything to be relative to struct bla, or to do the same
> > > > I'm doing it, but IMO more prone to error:
> > > >
> > > > struct dma_buf_map map = *bla_map;
> > > > dma_buf_map_incr(map, offsetof(...));
> >
> > Wrt the issue at hand I think the above is perfectly fine code. The idea
> > with dma_buf_map is really that it's just a special pointer, so writing
> > the code exactly as pointer code feels best. Unfortunately you cannot make
> > them typesafe (because of C), so the code sometimes looks a bit ugly.
> > Otherwise we could do stuff like container_of and all that with
> > typechecking in the macros.
>
> I had exactly this code above, but after writting quite a few patches
> using it, particularly with functions that have to write to 2 maps (see
> patch 6 for example), it felt much better to have something to
> initialize correctly from the start
>
> struct dma_buf_map other_map = *bla_map;
> /* poor Lucas forgetting dma_buf_map_incr(map, offsetof(...)); */
>
> is error prone and hard to debug since you will be reading/writting
> from/to another location rather than exploding
>
> While with the construct below
>
> other_map;
> ...
> other_map = INITIALIZER()
>
> I can rely on the compiler complaining about uninitialized var. And
> in most of the cases I can just have this single line in the beggining of the
> function when the offset is constant:
>
> struct dma_buf_map other_map = INITIALIZER(bla_map, offsetof(..));
Hm yeah that's a good point that this allows us to rely on the compiler to
check for uninitialized variables.
Maybe include the above (with editing, but keeping the examples) in the
kerneldoc to explain why/how to use this? With that the concept at least
has my
Acked-by: Daniel Vetter
I'll leave it up to you & Christian to find a prettier color choice for
the naming bikeshed.
-Daniel
>
> Lucas De Marchi
>
> > -Daniel
> >
> > > > IMO this construct is worse because at a point in time in the function
> > > > the map was pointing to the wrong thing the function was supposed to
> > > > read/write.
> > > >
> > > > It's also useful when the function has double duty, updating a global
> > > > part of the struct and a table inside it (see example in patch 6)
> > > >
> > > > thanks
> > > > Lucas De Marchi
> > >
> >
> > -
Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map
Am 27.01.22 um 11:00 schrieb Daniel Vetter:
On Thu, Jan 27, 2022 at 01:33:32AM -0800, Lucas De Marchi wrote:
On Thu, Jan 27, 2022 at 09:57:25AM +0100, Daniel Vetter wrote:
On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
When dma_buf_map struct is passed around, it's useful to be able to
initialize a second map that takes care of reading/writing to an offset
of the original map.
Add a helper that copies the struct and add the offset to the proper
address.
Well what you propose here can lead to all kind of problems and is
rather bad design as far as I can see.
The struct dma_buf_map is only to be filled in by the exporter and
should not be modified in this way by the importer.
humn... not sure if I was clear. There is no importer and exporter here.
Yeah, and exactly that's what I'm pointing out as problem here.
You are using the inter driver framework for something internal to the
driver. That is an absolutely clear NAK!
We could discuss that, but you guys are just sending around patches to do
this without any consensus that this is a good idea.
Uh I suggested this, also we're already using dma_buf_map all over the
place as a convenient abstraction. So imo that's all fine, it should allow
drivers to simplify some code where on igpu it's in normal kernel memory
and on dgpu it's behind some pci bar.
Maybe we should have a better name for that struct (and maybe also a
better place), but way back when we discussed that bikeshed I didn't come
up with anything better really.
I suggest iosys_map since it abstracts access to IO and system memory.
There is a role delegation on filling out and reading a buffer when
that buffer represents a struct layout.
struct bla {
int a;
int b;
int c;
struct foo foo;
struct bar bar;
int d;
}
This implementation allows you to have:
fill_foo(struct dma_buf_map *bla_map) { ... }
fill_bar(struct dma_buf_map *bla_map) { ... }
and the first thing these do is to make sure the map it's pointing to
is relative to the struct it's supposed to write/read. Otherwise you're
suggesting everything to be relative to struct bla, or to do the same
I'm doing it, but IMO more prone to error:
struct dma_buf_map map = *bla_map;
dma_buf_map_incr(map, offsetof(...));
Wrt the issue at hand I think the above is perfectly fine code. The idea
with dma_buf_map is really that it's just a special pointer, so writing
the code exactly as pointer code feels best. Unfortunately you cannot make
them typesafe (because of C), so the code sometimes looks a bit ugly.
Otherwise we could do stuff like container_of and all that with
typechecking in the macros.
I had exactly this code above, but after writting quite a few patches
using it, particularly with functions that have to write to 2 maps (see
patch 6 for example), it felt much better to have something to
initialize correctly from the start
struct dma_buf_map other_map = *bla_map;
/* poor Lucas forgetting dma_buf_map_incr(map, offsetof(...)); */
is error prone and hard to debug since you will be reading/writting
from/to another location rather than exploding
While with the construct below
other_map;
...
other_map = INITIALIZER()
I can rely on the compiler complaining about uninitialized var. And
in most of the cases I can just have this single line in the beggining of the
function when the offset is constant:
struct dma_buf_map other_map = INITIALIZER(bla_map, offsetof(..));
Hm yeah that's a good point that this allows us to rely on the compiler to
check for uninitialized variables.
Maybe include the above (with editing, but keeping the examples) in the
kerneldoc to explain why/how to use this? With that the concept at least
has my
Acked-by: Daniel Vetter
I'll leave it up to you & Christian to find a prettier color choice for
the naming bikeshed.
There is one major issue remaining with this and that is dma_buf_vunmap():
void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
Here we expect the original pointer as returned by dma_buf_map(),
otherwise we vunmap() the wrong area!
For all TTM based driver this doesn't matter since we keep the vmap base
separately in the BO anyway (IIRC), but we had at least one case where
this made boom last year.
Christian.
-Daniel
Lucas De Marchi
-Daniel
IMO this construct is worse because at a point in time in the function
the map was pointing to the wrong thing the function was supposed to
read/write.
It's also useful when the function has double duty, updating a global
part of the struct and a table inside it (see example in patch 6)
thanks
Lucas De Marchi
--
Daniel Vetter
Software Engineer, Intel Corporation
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.ffwll.ch%2F&dat
[Intel-gfx] [PATCH] drm/i915/adl-n: Add PCH Support for Alder Lake N
Add the PCH ID for ADL-N.
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/intel_pch.c | 1 +
drivers/gpu/drm/i915/intel_pch.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
index da8f82c2342f..4f7a61d5502e 100644
--- a/drivers/gpu/drm/i915/intel_pch.c
+++ b/drivers/gpu/drm/i915/intel_pch.c
@@ -130,6 +130,7 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
unsigned short id)
case INTEL_PCH_ADP_DEVICE_ID_TYPE:
case INTEL_PCH_ADP2_DEVICE_ID_TYPE:
case INTEL_PCH_ADP3_DEVICE_ID_TYPE:
+ case INTEL_PCH_ADP4_DEVICE_ID_TYPE:
drm_dbg_kms(&dev_priv->drm, "Found Alder Lake PCH\n");
drm_WARN_ON(&dev_priv->drm, !IS_ALDERLAKE_S(dev_priv) &&
!IS_ALDERLAKE_P(dev_priv));
diff --git a/drivers/gpu/drm/i915/intel_pch.h b/drivers/gpu/drm/i915/intel_pch.h
index 6bff77521094..6fd20408f7bf 100644
--- a/drivers/gpu/drm/i915/intel_pch.h
+++ b/drivers/gpu/drm/i915/intel_pch.h
@@ -58,6 +58,7 @@ enum intel_pch {
#define INTEL_PCH_ADP_DEVICE_ID_TYPE 0x7A80
#define INTEL_PCH_ADP2_DEVICE_ID_TYPE 0x5180
#define INTEL_PCH_ADP3_DEVICE_ID_TYPE 0x7A00
+#define INTEL_PCH_ADP4_DEVICE_ID_TYPE 0x5480
#define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
#define INTEL_PCH_P3X_DEVICE_ID_TYPE 0x7000
#define INTEL_PCH_QEMU_DEVICE_ID_TYPE 0x2900 /* qemu q35 has 2918 */
--
2.34.1
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: M/N cleanup
== Series Details == Series: drm/i915: M/N cleanup URL : https://patchwork.freedesktop.org/series/99409/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gvt/display.o drivers/gpu/drm/i915/gvt/display.c: In function ‘emulate_monitor_status_change’: drivers/gpu/drm/i915/gvt/display.c:256:57: error: ‘TU_SIZE_SHIFT’ undeclared (first use in this function); did you mean ‘TV_XSIZE_SHIFT’? vgpu_vreg_t(vgpu, PIPE_DATA_M1(TRANSCODER_A)) = 63 << TU_SIZE_SHIFT; ^ TV_XSIZE_SHIFT drivers/gpu/drm/i915/gvt/display.c:256:57: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:288: recipe for target 'drivers/gpu/drm/i915/gvt/display.o' failed make[4]: *** [drivers/gpu/drm/i915/gvt/display.o] Error 1 scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:550: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1831: recipe for target 'drivers' failed make: *** [drivers] Error 2
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: delete shadow "ret" variable
== Series Details ==
Series: drm/i915: delete shadow "ret" variable
URL : https://patchwork.freedesktop.org/series/99408/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11149 -> Patchwork_22121
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/index.html
Participating hosts (45 -> 41)
--
Additional (1): fi-icl-u2
Missing(5): fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510
fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22121 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-gfx:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/fi-hsw-4770/igt@amdgpu/amd_ba...@cs-gfx.html
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u: [PASS][3] -> [INCOMPLETE][4] ([i915#4547])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-icl-u2: NOTRUN -> [SKIP][5] ([i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][7] -> [DMESG-FAIL][8] ([i915#4957])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][9] -> [INCOMPLETE][10] ([i915#3921])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][11] ([fdo#111827]) +8 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: NOTRUN -> [SKIP][12] ([fdo#109278]) +2 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][13] ([fdo#109285])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][14] ([i915#3301])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/fi-icl-u2/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [DMESG-FAIL][15] ([i915#4957]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- fi-hsw-4770:[INCOMPLETE][17] ([i915#4785]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#4312]: https:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/adl-n: Add PCH Support for Alder Lake N
== Series Details == Series: drm/i915/adl-n: Add PCH Support for Alder Lake N URL : https://patchwork.freedesktop.org/series/99413/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 01/14] drm/i915: Extract intel_{get, set}_m_n()
On Thu, 27 Jan 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make the M/N setup/readout a bit less repitive by extracting
> a few small helpers.
>
> Signed-off-by: Ville Syrjälä
Nice!
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 109 ---
> 1 file changed, 47 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 91add3d85151..f76faa195cb9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3113,6 +3113,17 @@ static void intel_panel_sanitize_ssc(struct
> drm_i915_private *dev_priv)
> }
> }
>
> +static void intel_set_m_n(struct drm_i915_private *i915,
> + const struct intel_link_m_n *m_n,
> + i915_reg_t data_m_reg, i915_reg_t data_n_reg,
> + i915_reg_t link_m_reg, i915_reg_t link_n_reg)
> +{
> + intel_de_write(i915, data_m_reg, TU_SIZE(m_n->tu) | m_n->gmch_m);
> + intel_de_write(i915, data_n_reg, m_n->gmch_n);
> + intel_de_write(i915, link_m_reg, m_n->link_m);
> + intel_de_write(i915, link_n_reg, m_n->link_n);
> +}
> +
> static void intel_pch_transcoder_set_m_n(const struct intel_crtc_state
> *crtc_state,
>const struct intel_link_m_n *m_n)
> {
> @@ -3120,11 +3131,9 @@ static void intel_pch_transcoder_set_m_n(const struct
> intel_crtc_state *crtc_sta
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum pipe pipe = crtc->pipe;
>
> - intel_de_write(dev_priv, PCH_TRANS_DATA_M1(pipe),
> -TU_SIZE(m_n->tu) | m_n->gmch_m);
> - intel_de_write(dev_priv, PCH_TRANS_DATA_N1(pipe), m_n->gmch_n);
> - intel_de_write(dev_priv, PCH_TRANS_LINK_M1(pipe), m_n->link_m);
> - intel_de_write(dev_priv, PCH_TRANS_LINK_N1(pipe), m_n->link_n);
> + intel_set_m_n(dev_priv, m_n,
> + PCH_TRANS_DATA_M1(pipe), PCH_TRANS_DATA_N1(pipe),
> + PCH_TRANS_LINK_M1(pipe), PCH_TRANS_LINK_N1(pipe));
> }
>
> static bool transcoder_has_m2_n2(struct drm_i915_private *dev_priv,
> @@ -3150,35 +3159,23 @@ static void intel_cpu_transcoder_set_m_n(const struct
> intel_crtc_state *crtc_sta
> enum transcoder transcoder = crtc_state->cpu_transcoder;
>
> if (DISPLAY_VER(dev_priv) >= 5) {
> - intel_de_write(dev_priv, PIPE_DATA_M1(transcoder),
> -TU_SIZE(m_n->tu) | m_n->gmch_m);
> - intel_de_write(dev_priv, PIPE_DATA_N1(transcoder),
> -m_n->gmch_n);
> - intel_de_write(dev_priv, PIPE_LINK_M1(transcoder),
> -m_n->link_m);
> - intel_de_write(dev_priv, PIPE_LINK_N1(transcoder),
> -m_n->link_n);
> + intel_set_m_n(dev_priv, m_n,
> + PIPE_DATA_M1(transcoder),
> PIPE_DATA_N1(transcoder),
> + PIPE_LINK_M1(transcoder),
> PIPE_LINK_N1(transcoder));
> /*
>* M2_N2 registers are set only if DRRS is supported
>* (to make sure the registers are not unnecessarily accessed).
>*/
> if (m2_n2 && crtc_state->has_drrs &&
> transcoder_has_m2_n2(dev_priv, transcoder)) {
> - intel_de_write(dev_priv, PIPE_DATA_M2(transcoder),
> -TU_SIZE(m2_n2->tu) | m2_n2->gmch_m);
> - intel_de_write(dev_priv, PIPE_DATA_N2(transcoder),
> -m2_n2->gmch_n);
> - intel_de_write(dev_priv, PIPE_LINK_M2(transcoder),
> -m2_n2->link_m);
> - intel_de_write(dev_priv, PIPE_LINK_N2(transcoder),
> -m2_n2->link_n);
> + intel_set_m_n(dev_priv, m2_n2,
> + PIPE_DATA_M2(transcoder),
> PIPE_DATA_N2(transcoder),
> + PIPE_LINK_M2(transcoder),
> PIPE_LINK_N2(transcoder));
> }
> } else {
> - intel_de_write(dev_priv, PIPE_DATA_M_G4X(pipe),
> -TU_SIZE(m_n->tu) | m_n->gmch_m);
> - intel_de_write(dev_priv, PIPE_DATA_N_G4X(pipe), m_n->gmch_n);
> - intel_de_write(dev_priv, PIPE_LINK_M_G4X(pipe), m_n->link_m);
> - intel_de_write(dev_priv, PIPE_LINK_N_G4X(pipe), m_n->link_n);
> + intel_set_m_n(dev_priv, m_n,
> + PIPE_DATA_M_G4X(pipe), PIPE_DATA_N_G4X(pipe),
> + PIPE_LINK_M_G4X(pipe), PIPE_LINK_N_G4X(pipe));
> }
> }
>
> @@ -3863,6 +3860,18 @@ int ilk_get_lanes_required(int target_clock, int
> link_bw, int bpp)
> return DIV_ROUND_UP(bps, link_bw * 8);
> }
>
> +sta
Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map
On Thu, Jan 27, 2022 at 11:21:20AM +0100, Christian König wrote:
> Am 27.01.22 um 11:00 schrieb Daniel Vetter:
> > On Thu, Jan 27, 2022 at 01:33:32AM -0800, Lucas De Marchi wrote:
> > > On Thu, Jan 27, 2022 at 09:57:25AM +0100, Daniel Vetter wrote:
> > > > On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
> > > > > Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
> > > > > > On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
> > > > > > > Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
> > > > > > > > When dma_buf_map struct is passed around, it's useful to be
> > > > > > > > able to
> > > > > > > > initialize a second map that takes care of reading/writing to
> > > > > > > > an offset
> > > > > > > > of the original map.
> > > > > > > >
> > > > > > > > Add a helper that copies the struct and add the offset to the
> > > > > > > > proper
> > > > > > > > address.
> > > > > > > Well what you propose here can lead to all kind of problems and is
> > > > > > > rather bad design as far as I can see.
> > > > > > >
> > > > > > > The struct dma_buf_map is only to be filled in by the exporter and
> > > > > > > should not be modified in this way by the importer.
> > > > > > humn... not sure if I was clear. There is no importer and exporter
> > > > > > here.
> > > > > Yeah, and exactly that's what I'm pointing out as problem here.
> > > > >
> > > > > You are using the inter driver framework for something internal to the
> > > > > driver. That is an absolutely clear NAK!
> > > > >
> > > > > We could discuss that, but you guys are just sending around patches
> > > > > to do
> > > > > this without any consensus that this is a good idea.
> > > > Uh I suggested this, also we're already using dma_buf_map all over the
> > > > place as a convenient abstraction. So imo that's all fine, it should
> > > > allow
> > > > drivers to simplify some code where on igpu it's in normal kernel memory
> > > > and on dgpu it's behind some pci bar.
> > > >
> > > > Maybe we should have a better name for that struct (and maybe also a
> > > > better place), but way back when we discussed that bikeshed I didn't
> > > > come
> > > > up with anything better really.
> > > I suggest iosys_map since it abstracts access to IO and system memory.
> > >
> > > > > > There is a role delegation on filling out and reading a buffer when
> > > > > > that buffer represents a struct layout.
> > > > > >
> > > > > > struct bla {
> > > > > > int a;
> > > > > > int b;
> > > > > > int c;
> > > > > > struct foo foo;
> > > > > > struct bar bar;
> > > > > > int d;
> > > > > > }
> > > > > >
> > > > > >
> > > > > > This implementation allows you to have:
> > > > > >
> > > > > > fill_foo(struct dma_buf_map *bla_map) { ... }
> > > > > > fill_bar(struct dma_buf_map *bla_map) { ... }
> > > > > >
> > > > > > and the first thing these do is to make sure the map it's pointing
> > > > > > to
> > > > > > is relative to the struct it's supposed to write/read. Otherwise
> > > > > > you're
> > > > > > suggesting everything to be relative to struct bla, or to do the
> > > > > > same
> > > > > > I'm doing it, but IMO more prone to error:
> > > > > >
> > > > > > struct dma_buf_map map = *bla_map;
> > > > > > dma_buf_map_incr(map, offsetof(...));
> > > > Wrt the issue at hand I think the above is perfectly fine code. The idea
> > > > with dma_buf_map is really that it's just a special pointer, so writing
> > > > the code exactly as pointer code feels best. Unfortunately you cannot
> > > > make
> > > > them typesafe (because of C), so the code sometimes looks a bit ugly.
> > > > Otherwise we could do stuff like container_of and all that with
> > > > typechecking in the macros.
> > > I had exactly this code above, but after writting quite a few patches
> > > using it, particularly with functions that have to write to 2 maps (see
> > > patch 6 for example), it felt much better to have something to
> > > initialize correctly from the start
> > >
> > > struct dma_buf_map other_map = *bla_map;
> > > /* poor Lucas forgetting dma_buf_map_incr(map, offsetof(...)); */
> > >
> > > is error prone and hard to debug since you will be reading/writting
> > > from/to another location rather than exploding
> > >
> > > While with the construct below
> > >
> > > other_map;
> > > ...
> > > other_map = INITIALIZER()
> > >
> > > I can rely on the compiler complaining about uninitialized var. And
> > > in most of the cases I can just have this single line in the beggining of
> > > the
> > > function when the offset is constant:
> > >
> > > struct dma_buf_map other_map = INITIALIZER(bla_map, offsetof(..));
> > Hm yeah that's a good point that this allows us to rely on the compiler to
> > check for uninitialized variables.
> >
> > Maybe include the above (with editing, but keeping the examples) in the
> > kerneldoc to explain why/how to use this? With that the concept at least
> > has my
> >
> > A
Re: [Intel-gfx] [PATCH 02/14] drm/i915: Clean up M/N register defines
On Thu, 27 Jan 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use REG_GENMASK() & co. for the M/N register values. There are
> also a lot of weird unused defines (eg. *_OFFSET) we can just
> throw out.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 10 -
> drivers/gpu/drm/i915/i915_reg.h | 22 +++-
> 2 files changed, 8 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f76faa195cb9..d91164d1eb92 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3865,11 +3865,11 @@ static void intel_get_m_n(struct drm_i915_private
> *i915,
> i915_reg_t data_m_reg, i915_reg_t data_n_reg,
> i915_reg_t link_m_reg, i915_reg_t link_n_reg)
> {
> - m_n->link_m = intel_de_read(i915, link_m_reg);
> - m_n->link_n = intel_de_read(i915, link_n_reg);
> - m_n->gmch_m = intel_de_read(i915, data_m_reg) & ~TU_SIZE_MASK;
> - m_n->gmch_n = intel_de_read(i915, data_n_reg);
> - m_n->tu = ((intel_de_read(i915, data_m_reg) & TU_SIZE_MASK) >>
> TU_SIZE_SHIFT) + 1;
> + m_n->link_m = intel_de_read(i915, link_m_reg) & DATA_LINK_M_N_MASK;
> + m_n->link_n = intel_de_read(i915, link_n_reg) & DATA_LINK_M_N_MASK;
> + m_n->gmch_m = intel_de_read(i915, data_m_reg) & DATA_LINK_M_N_MASK;
> + m_n->gmch_n = intel_de_read(i915, data_n_reg) & DATA_LINK_M_N_MASK;
> + m_n->tu = REG_FIELD_GET(TU_SIZE_MASK, intel_de_read(i915, data_m_reg))
> + 1;
The commit message might mention we throw some bits away while reading.
A follow-up could perhasps axe the double read of the data_m_reg, but
*shrug*.
Reviewed-by: Jani Nikula
> }
>
> static void intel_pch_transcoder_get_m_n(struct intel_crtc *crtc,
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 2e4dd9db63fe..ec48406eb37a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5209,16 +5209,14 @@ enum {
> #define _PIPEB_DATA_M_G4X0x71050
>
> /* Transfer unit size for display port - 1, default is 0x3f (for TU size 64)
> */
> -#define TU_SIZE(x) (((x) - 1) << 25) /* default size 64 */
> -#define TU_SIZE_SHIFT 25
> -#define TU_SIZE_MASK (0x3f << 25)
> +#define TU_SIZE_MASKREG_GENMASK(30, 25)
> +#define TU_SIZE(x) REG_FIELD_PREP(TU_SIZE_MASK, (x) - 1) /*
> default size 64 */
>
> -#define DATA_LINK_M_N_MASK (0xff)
> +#define DATA_LINK_M_N_MASK REG_GENMASK(23, 0)
> #define DATA_LINK_N_MAX (0x80)
>
> #define _PIPEA_DATA_N_G4X0x70054
> #define _PIPEB_DATA_N_G4X0x71054
> -#define PIPE_GMCH_DATA_N_MASK (0xff)
>
> /*
> * Computing Link M and N values for the Display Port link
> @@ -5233,11 +5231,8 @@ enum {
>
> #define _PIPEA_LINK_M_G4X0x70060
> #define _PIPEB_LINK_M_G4X0x71060
> -#define PIPEA_DP_LINK_M_MASK (0xff)
> -
> #define _PIPEA_LINK_N_G4X0x70064
> #define _PIPEB_LINK_N_G4X0x71064
> -#define PIPEA_DP_LINK_N_MASK (0xff)
>
> #define PIPE_DATA_M_G4X(pipe) _MMIO_PIPE(pipe, _PIPEA_DATA_M_G4X,
> _PIPEB_DATA_M_G4X)
> #define PIPE_DATA_N_G4X(pipe) _MMIO_PIPE(pipe, _PIPEA_DATA_N_G4X,
> _PIPEB_DATA_N_G4X)
> @@ -6840,24 +6835,13 @@ enum {
>
>
> #define _PIPEA_DATA_M1 0x60030
> -#define PIPE_DATA_M1_OFFSET0
> #define _PIPEA_DATA_N1 0x60034
> -#define PIPE_DATA_N1_OFFSET0
> -
> #define _PIPEA_DATA_M2 0x60038
> -#define PIPE_DATA_M2_OFFSET0
> #define _PIPEA_DATA_N2 0x6003c
> -#define PIPE_DATA_N2_OFFSET0
> -
> #define _PIPEA_LINK_M1 0x60040
> -#define PIPE_LINK_M1_OFFSET0
> #define _PIPEA_LINK_N1 0x60044
> -#define PIPE_LINK_N1_OFFSET0
> -
> #define _PIPEA_LINK_M2 0x60048
> -#define PIPE_LINK_M2_OFFSET0
> #define _PIPEA_LINK_N2 0x6004c
> -#define PIPE_LINK_N2_OFFSET0
>
> /* PIPEB timing regs are same start from 0x61000 */
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 03/14] drm/i915: s/gmch_{m,n}/data_{m,n}/
On Thu, 27 Jan 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename the gmch_* M/N members to data_* to match the register
> definitions and thus make life a little less confusing.
Yes, please!
Reviewed-by: Jani Nikula
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
> drivers/gpu/drm/i915/display/intel_display.c | 48 ++--
> drivers/gpu/drm/i915/display/intel_display.h | 4 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_drrs.c| 2 +-
> 5 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 5d1f7d6218c5..ca8becb07e45 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3684,8 +3684,8 @@ static bool m_n_equal(const struct intel_link_m_n
> *m_n_1,
> const struct intel_link_m_n *m_n_2)
> {
> return m_n_1->tu == m_n_2->tu &&
> - m_n_1->gmch_m == m_n_2->gmch_m &&
> - m_n_1->gmch_n == m_n_2->gmch_n &&
> + m_n_1->data_m == m_n_2->data_m &&
> + m_n_1->data_n == m_n_2->data_n &&
> m_n_1->link_m == m_n_2->link_m &&
> m_n_1->link_n == m_n_2->link_n;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index d91164d1eb92..75de794185b2 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3082,7 +3082,7 @@ intel_link_compute_m_n(u16 bits_per_pixel, int nlanes,
> m_n->tu = 64;
> compute_m_n(data_clock,
> link_clock * nlanes * 8,
> - &m_n->gmch_m, &m_n->gmch_n,
> + &m_n->data_m, &m_n->data_n,
> constant_n);
>
> compute_m_n(pixel_clock, link_clock,
> @@ -3118,8 +3118,8 @@ static void intel_set_m_n(struct drm_i915_private *i915,
> i915_reg_t data_m_reg, i915_reg_t data_n_reg,
> i915_reg_t link_m_reg, i915_reg_t link_n_reg)
> {
> - intel_de_write(i915, data_m_reg, TU_SIZE(m_n->tu) | m_n->gmch_m);
> - intel_de_write(i915, data_n_reg, m_n->gmch_n);
> + intel_de_write(i915, data_m_reg, TU_SIZE(m_n->tu) | m_n->data_m);
> + intel_de_write(i915, data_n_reg, m_n->data_n);
> intel_de_write(i915, link_m_reg, m_n->link_m);
> intel_de_write(i915, link_n_reg, m_n->link_n);
> }
> @@ -3867,8 +3867,8 @@ static void intel_get_m_n(struct drm_i915_private *i915,
> {
> m_n->link_m = intel_de_read(i915, link_m_reg) & DATA_LINK_M_N_MASK;
> m_n->link_n = intel_de_read(i915, link_n_reg) & DATA_LINK_M_N_MASK;
> - m_n->gmch_m = intel_de_read(i915, data_m_reg) & DATA_LINK_M_N_MASK;
> - m_n->gmch_n = intel_de_read(i915, data_n_reg) & DATA_LINK_M_N_MASK;
> + m_n->data_m = intel_de_read(i915, data_m_reg) & DATA_LINK_M_N_MASK;
> + m_n->data_n = intel_de_read(i915, data_n_reg) & DATA_LINK_M_N_MASK;
> m_n->tu = REG_FIELD_GET(TU_SIZE_MASK, intel_de_read(i915, data_m_reg))
> + 1;
> }
>
> @@ -5498,9 +5498,9 @@ intel_dump_m_n_config(const struct intel_crtc_state
> *pipe_config,
> struct drm_i915_private *i915 = to_i915(pipe_config->uapi.crtc->dev);
>
> drm_dbg_kms(&i915->drm,
> - "%s: lanes: %i; gmch_m: %u, gmch_n: %u, link_m: %u, link_n:
> %u, tu: %u\n",
> + "%s: lanes: %i; data_m: %u, data_n: %u, link_m: %u, link_n:
> %u, tu: %u\n",
> id, lane_count,
> - m_n->gmch_m, m_n->gmch_n,
> + m_n->data_m, m_n->data_n,
> m_n->link_m, m_n->link_n, m_n->tu);
> }
>
> @@ -6196,8 +6196,8 @@ intel_compare_link_m_n(const struct intel_link_m_n *m_n,
> bool exact)
> {
> return m_n->tu == m2_n2->tu &&
> - intel_compare_m_n(m_n->gmch_m, m_n->gmch_n,
> - m2_n2->gmch_m, m2_n2->gmch_n, exact) &&
> + intel_compare_m_n(m_n->data_m, m_n->data_n,
> + m2_n2->data_m, m2_n2->data_n, exact) &&
> intel_compare_m_n(m_n->link_m, m_n->link_n,
> m2_n2->link_m, m2_n2->link_n, exact);
> }
> @@ -6396,16 +6396,16 @@ intel_pipe_config_compare(const struct
> intel_crtc_state *current_config,
> &pipe_config->name,\
> !fastset)) { \
> pipe_config_mismatch(fastset, crtc, __stringify(name), \
> - "(expected tu %i gmch %i/%i link %i/%i, " \
> - "found tu %i, gmch %i/%i link %i/%i)", \
> + "(expected tu %i data %i/%i link %i/%i, " \
> + "found tu %i, data %i/%i link %i/%i)", \
>
[Intel-gfx] [PATCH v4 0/5] Add driver for GSC controller
GSC is a graphics system controller, it provides a chassis controller for graphics discrete cards. There are two MEI interfaces in GSC: HECI1 and HECI2. This series includes instantiation of the auxiliary devices for HECI2 and mei-gsc auxiliary device driver that binds to the auxiliary device. In v2 the platform device was replaced by the auxiliary device. v3 is the rebase over drm-tip to make public CI running. In v4 the not needed debug prints and empty line were removed, 'select' were replaced by 'depends on' in MEI Kconfig, the new include file now listed in the MAINTATINERS file. Greg KH, please review and ACK the MEI patches after main merge window closure. We are pushing all through gfx tree as the auxiliary device belongs there. Alexander Usyskin (2): mei: gsc: setup char driver alive in spite of firmware handshake failure mei: gsc: retrieve the firmware version Tomas Winkler (3): drm/i915/gsc: add gsc as a mei auxiliary device mei: add support for graphics system controller (gsc) devices mei: gsc: add runtime pm handlers MAINTAINERS | 1 + drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile| 3 + drivers/gpu/drm/i915/gt/intel_gsc.c | 199 ++ drivers/gpu/drm/i915/gt/intel_gsc.h | 37 drivers/gpu/drm/i915/gt/intel_gt.c | 3 + drivers/gpu/drm/i915/gt/intel_gt.h | 5 + drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 ++ drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 + drivers/gpu/drm/i915/i915_drv.h | 8 + drivers/gpu/drm/i915/i915_pci.c | 3 +- drivers/gpu/drm/i915/i915_reg.h | 3 + drivers/gpu/drm/i915/intel_device_info.h | 2 + drivers/misc/mei/Kconfig | 14 ++ drivers/misc/mei/Makefile| 3 + drivers/misc/mei/bus-fixup.c | 25 +++ drivers/misc/mei/gsc-me.c| 252 +++ drivers/misc/mei/hw-me.c | 29 ++- drivers/misc/mei/hw-me.h | 2 + include/linux/mei_aux.h | 19 ++ 20 files changed, 621 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_gsc.c create mode 100644 drivers/gpu/drm/i915/gt/intel_gsc.h create mode 100644 drivers/misc/mei/gsc-me.c create mode 100644 include/linux/mei_aux.h -- 2.32.0
[Intel-gfx] [PATCH v4 1/5] drm/i915/gsc: add gsc as a mei auxiliary device
From: Tomas Winkler
GSC is a graphics system controller, it provides
a chassis controller for graphics discrete cards.
There are two MEI interfaces in GSC: HECI1 and HECI2.
Both interfaces are on the BAR0 at offsets 0x00258000 and 0x00259000.
GSC is a GT Engine (class 4: instance 6). HECI1 interrupt is signaled
via bit 15 and HECI2 via bit 14 in the interrupt register.
This patch exports GSC as auxiliary device for mei driver to bind to
for HECI2 interface.
CC: Rodrigo Vivi
Signed-off-by: Tomas Winkler
Signed-off-by: Vitaly Lubart
Signed-off-by: Alexander Usyskin
---
V4: add header to the MAINTAINERS file
drop empty line
---
MAINTAINERS | 1 +
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile| 3 +
drivers/gpu/drm/i915/gt/intel_gsc.c | 199 +++
drivers/gpu/drm/i915/gt/intel_gsc.h | 37 +
drivers/gpu/drm/i915/gt/intel_gt.c | 3 +
drivers/gpu/drm/i915/gt/intel_gt.h | 5 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +
drivers/gpu/drm/i915/i915_drv.h | 8 +
drivers/gpu/drm/i915/i915_pci.c | 3 +-
drivers/gpu/drm/i915/i915_reg.h | 3 +
drivers/gpu/drm/i915/intel_device_info.h | 2 +
include/linux/mei_aux.h | 19 +++
14 files changed, 298 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gsc.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_gsc.h
create mode 100644 include/linux/mei_aux.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 8241d0381e09..a5489f4ecb4f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9723,6 +9723,7 @@ S:Supported
F: Documentation/driver-api/mei/*
F: drivers/misc/mei/
F: drivers/watchdog/mei_wdt.c
+F: include/linux/mei_aux.h
F: include/linux/mei_cl_bus.h
F: include/uapi/linux/mei.h
F: samples/mei/*
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 2ac220bfd0ed..3b0508e7a805 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -29,6 +29,7 @@ config DRM_I915
select VMAP_PFN
select DRM_TTM
select DRM_BUDDY
+ select AUXILIARY_BUS
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 451df10e3a36..5d5c04b5c0ac 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -194,6 +194,9 @@ i915-y += gt/uc/intel_uc.o \
gt/uc/intel_huc_debugfs.o \
gt/uc/intel_huc_fw.o
+# graphics system controller (GSC) support
+i915-y += gt/intel_gsc.o
+
# modesetting core code
i915-y += \
display/intel_atomic.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c
b/drivers/gpu/drm/i915/gt/intel_gsc.c
new file mode 100644
index ..f1870acd1866
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2019-2022, Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include "i915_reg.h"
+#include "i915_drv.h"
+#include "gt/intel_gt.h"
+#include "intel_gsc.h"
+
+#define GSC_BAR_LENGTH 0x0FFC
+
+static void gsc_irq_mask(struct irq_data *d)
+{
+ /* generic irq handling */
+}
+
+static void gsc_irq_unmask(struct irq_data *d)
+{
+ /* generic irq handling */
+}
+
+static struct irq_chip gsc_irq_chip = {
+ .name = "gsc_irq_chip",
+ .irq_mask = gsc_irq_mask,
+ .irq_unmask = gsc_irq_unmask,
+};
+
+static int gsc_irq_init(struct drm_i915_private *dev_priv, int irq)
+{
+ irq_set_chip_and_handler_name(irq, &gsc_irq_chip,
+ handle_simple_irq, "gsc_irq_handler");
+
+ return irq_set_chip_data(irq, dev_priv);
+}
+
+struct intel_gsc_def {
+ const char *name;
+ const unsigned long bar;
+ size_t bar_size;
+};
+
+/* gscfi (graphics system controller firmware interface) resources */
+static const struct intel_gsc_def intel_gsc_def_dg1[] = {
+ {
+ },
+ {
+ .name = "mei-gscfi",
+ .bar = GSC_DG1_HECI2_BASE,
+ .bar_size = GSC_BAR_LENGTH,
+ }
+};
+
+static void intel_gsc_release_dev(struct device *dev)
+{
+ struct auxiliary_device *aux_dev = to_auxiliary_dev(dev);
+ struct mei_aux_device *adev = auxiliary_dev_to_mei_aux_dev(aux_dev);
+
+ kfree(adev);
+}
+
+static void intel_gsc_destroy_one(struct intel_gsc_intf *intf)
+{
+ if (intf->adev) {
+ auxiliary_device_delete(&intf->adev->aux_dev);
+ auxiliary_device_uninit(&intf->adev->aux_dev);
+ intf->adev = NULL;
+ }
+ if (intf->irq >= 0)
+ irq_free_desc(intf->irq);
+ intf->irq = -1;
+}
+
+static void intel_gsc_
[Intel-gfx] [PATCH v4 2/5] mei: add support for graphics system controller (gsc) devices
From: Tomas Winkler
GSC is a graphics system controller, based on CSE, it provides
a chassis controller for graphics discrete cards, as well as it
supports media protection on selected devices.
mei_gsc binds to a auxiliary devices exposed by Intel discrete
driver i915.
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
V4: drop debug prints
replace selects with depends on in Kconfig
---
drivers/misc/mei/Kconfig | 14 +++
drivers/misc/mei/Makefile | 3 +
drivers/misc/mei/gsc-me.c | 186 ++
drivers/misc/mei/hw-me.c | 27 +-
drivers/misc/mei/hw-me.h | 2 +
5 files changed, 230 insertions(+), 2 deletions(-)
create mode 100644 drivers/misc/mei/gsc-me.c
diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig
index 0e0bcd0da852..d21486d69df2 100644
--- a/drivers/misc/mei/Kconfig
+++ b/drivers/misc/mei/Kconfig
@@ -46,6 +46,20 @@ config INTEL_MEI_TXE
Supported SoCs:
Intel Bay Trail
+config INTEL_MEI_GSC
+ tristate "Intel MEI GSC embedded device"
+ depends on INTEL_MEI
+ depends on INTEL_MEI_ME
+ depends on X86 && PCI
+ depends on DRM_I915
+ help
+ Intel auxiliary driver for GSC devices embedded in Intel graphics
devices.
+
+ An MEI device here called GSC can be embedded in an
+ Intel graphics devices, to support a range of chassis
+ tasks such as graphics card firmware update and security
+ tasks.
+
source "drivers/misc/mei/hdcp/Kconfig"
source "drivers/misc/mei/pxp/Kconfig"
diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile
index d8e5165917f2..fb740d754900 100644
--- a/drivers/misc/mei/Makefile
+++ b/drivers/misc/mei/Makefile
@@ -18,6 +18,9 @@ obj-$(CONFIG_INTEL_MEI_ME) += mei-me.o
mei-me-objs := pci-me.o
mei-me-objs += hw-me.o
+obj-$(CONFIG_INTEL_MEI_GSC) += mei-gsc.o
+mei-gsc-objs := gsc-me.o
+
obj-$(CONFIG_INTEL_MEI_TXE) += mei-txe.o
mei-txe-objs := pci-txe.o
mei-txe-objs += hw-txe.o
diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
new file mode 100644
index ..0afae70e0609
--- /dev/null
+++ b/drivers/misc/mei/gsc-me.c
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(c) 2019-2022, Intel Corporation. All rights reserved.
+ *
+ * Intel Management Engine Interface (Intel MEI) Linux driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mei_dev.h"
+#include "hw-me.h"
+#include "hw-me-regs.h"
+
+#include "mei-trace.h"
+
+#define MEI_GSC_RPM_TIMEOUT 500
+
+static int mei_gsc_read_hfs(const struct mei_device *dev, int where, u32 *val)
+{
+ struct mei_me_hw *hw = to_me_hw(dev);
+
+ *val = ioread32(hw->mem_addr + where + 0xC00);
+
+ return 0;
+}
+
+static int mei_gsc_probe(struct auxiliary_device *aux_dev,
+const struct auxiliary_device_id *aux_dev_id)
+{
+ struct mei_aux_device *adev = auxiliary_dev_to_mei_aux_dev(aux_dev);
+ struct mei_device *dev;
+ struct mei_me_hw *hw;
+ struct device *device;
+ const struct mei_cfg *cfg;
+ int ret;
+
+ cfg = mei_me_get_cfg(aux_dev_id->driver_data);
+ if (!cfg)
+ return -ENODEV;
+
+ device = &aux_dev->dev;
+
+ dev = mei_me_dev_init(device, cfg);
+ if (IS_ERR(dev)) {
+ ret = PTR_ERR(dev);
+ goto err;
+ }
+
+ hw = to_me_hw(dev);
+ hw->mem_addr = devm_ioremap_resource(device, &adev->bar);
+ if (IS_ERR(hw->mem_addr)) {
+ dev_err(device, "mmio not mapped\n");
+ ret = PTR_ERR(hw->mem_addr);
+ goto err;
+ }
+
+ hw->irq = adev->irq;
+ hw->read_fws = mei_gsc_read_hfs;
+
+ dev_set_drvdata(&aux_dev->dev, dev);
+
+ ret = devm_request_threaded_irq(device, hw->irq,
+ mei_me_irq_quick_handler,
+ mei_me_irq_thread_handler,
+ IRQF_ONESHOT, KBUILD_MODNAME, dev);
+ if (ret) {
+ dev_err(device, "irq register failed %d\n", ret);
+ goto err;
+ }
+
+ pm_runtime_get_noresume(device);
+ pm_runtime_set_active(device);
+ pm_runtime_enable(device);
+
+ if (mei_start(dev)) {
+ dev_err(device, "init hw failure.\n");
+ ret = -ENODEV;
+ goto err;
+ }
+
+ pm_runtime_set_autosuspend_delay(device, MEI_GSC_RPM_TIMEOUT);
+ pm_runtime_use_autosuspend(device);
+
+ ret = mei_register(dev, device);
+ if (ret)
+ goto register_err;
+
+ pm_runtime_put_noidle(device);
+ return 0;
+
+register_err:
+ mei_stop(dev);
+
+err:
+ dev_err(device, "probe failed: %d\n", ret);
+ dev_set_drvdata(&aux_dev->dev, NULL);
+ return ret;
+}
+
+static void mei_gsc_remove(struct auxiliary_de
[Intel-gfx] [PATCH v4 3/5] mei: gsc: setup char driver alive in spite of firmware handshake failure
Setup char device in spite of firmware handshake failure.
In order to provide host access to the firmware status registers and other
information required for the manufacturing process.
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/gsc-me.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
index 0afae70e0609..cf427f6fdec9 100644
--- a/drivers/misc/mei/gsc-me.c
+++ b/drivers/misc/mei/gsc-me.c
@@ -79,11 +79,12 @@ static int mei_gsc_probe(struct auxiliary_device *aux_dev,
pm_runtime_set_active(device);
pm_runtime_enable(device);
- if (mei_start(dev)) {
- dev_err(device, "init hw failure.\n");
- ret = -ENODEV;
- goto err;
- }
+ /* Continue to char device setup in spite of firmware handshake failure.
+* In order to provide access to the firmware status registers to the
user
+* space via sysfs.
+*/
+ if (mei_start(dev))
+ dev_warn(device, "init hw failure.\n");
pm_runtime_set_autosuspend_delay(device, MEI_GSC_RPM_TIMEOUT);
pm_runtime_use_autosuspend(device);
--
2.32.0
[Intel-gfx] [PATCH v4 4/5] mei: gsc: add runtime pm handlers
From: Tomas Winkler
Implement runtime handlers for mei-gsc, to track
idle state of the device properly.
CC: Rodrigo Vivi
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
V4: drop debug prints
---
drivers/misc/mei/gsc-me.c | 67 ++-
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/gsc-me.c b/drivers/misc/mei/gsc-me.c
index cf427f6fdec9..dac482ddab51 100644
--- a/drivers/misc/mei/gsc-me.c
+++ b/drivers/misc/mei/gsc-me.c
@@ -152,7 +152,72 @@ static int __maybe_unused mei_gsc_pm_resume(struct device
*device)
return 0;
}
-static SIMPLE_DEV_PM_OPS(mei_gsc_pm_ops, mei_gsc_pm_suspend,
mei_gsc_pm_resume);
+static int __maybe_unused mei_gsc_pm_runtime_idle(struct device *device)
+{
+ struct mei_device *dev = dev_get_drvdata(device);
+
+ if (!dev)
+ return -ENODEV;
+ if (mei_write_is_idle(dev))
+ pm_runtime_autosuspend(device);
+
+ return -EBUSY;
+}
+
+static int __maybe_unused mei_gsc_pm_runtime_suspend(struct device *device)
+{
+ struct mei_device *dev = dev_get_drvdata(device);
+ struct mei_me_hw *hw;
+ int ret;
+
+ if (!dev)
+ return -ENODEV;
+
+ mutex_lock(&dev->device_lock);
+
+ if (mei_write_is_idle(dev)) {
+ hw = to_me_hw(dev);
+ hw->pg_state = MEI_PG_ON;
+ ret = 0;
+ } else {
+ ret = -EAGAIN;
+ }
+
+ mutex_unlock(&dev->device_lock);
+
+ return ret;
+}
+
+static int __maybe_unused mei_gsc_pm_runtime_resume(struct device *device)
+{
+ struct mei_device *dev = dev_get_drvdata(device);
+ struct mei_me_hw *hw;
+ irqreturn_t irq_ret;
+
+ if (!dev)
+ return -ENODEV;
+
+ mutex_lock(&dev->device_lock);
+
+ hw = to_me_hw(dev);
+ hw->pg_state = MEI_PG_OFF;
+
+ mutex_unlock(&dev->device_lock);
+
+ irq_ret = mei_me_irq_thread_handler(1, dev);
+ if (irq_ret != IRQ_HANDLED)
+ dev_err(dev->dev, "thread handler fail %d\n", irq_ret);
+
+ return 0;
+}
+
+static const struct dev_pm_ops mei_gsc_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(mei_gsc_pm_suspend,
+ mei_gsc_pm_resume)
+ SET_RUNTIME_PM_OPS(mei_gsc_pm_runtime_suspend,
+ mei_gsc_pm_runtime_resume,
+ mei_gsc_pm_runtime_idle)
+};
static const struct auxiliary_device_id mei_gsc_id_table[] = {
{
--
2.32.0
[Intel-gfx] [PATCH v4 5/5] mei: gsc: retrieve the firmware version
Add a hook to retrieve the firmware version of the
GSC devices to bus-fixup.
GSC has a different MKHI clients GUIDs but the same message structure
to retrieve the firmware version as MEI so mei_fwver() can be reused.
CC: Ashutosh Dixit
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus-fixup.c | 25 +
drivers/misc/mei/hw-me.c | 2 ++
2 files changed, 27 insertions(+)
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 67844089db21..59506ba6fc48 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -30,6 +30,12 @@ static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
#define MEI_UUID_MKHIF_FIX UUID_LE(0x55213584, 0x9a29, 0x4916, \
0xba, 0xdf, 0xf, 0xb7, 0xed, 0x68, 0x2a, 0xeb)
+#define MEI_UUID_IGSC_MKHI UUID_LE(0xE2C2AFA2, 0x3817, 0x4D19, \
+ 0x9D, 0x95, 0x06, 0xB1, 0x6B, 0x58, 0x8A, 0x5D)
+
+#define MEI_UUID_IGSC_MKHI_FIX UUID_LE(0x46E0C1FB, 0xA546, 0x414F, \
+ 0x91, 0x70, 0xB7, 0xF4, 0x6D, 0x57, 0xB4, 0xAD)
+
#define MEI_UUID_HDCP UUID_LE(0xB638AB7E, 0x94E2, 0x4EA2, \
0xA5, 0x52, 0xD1, 0xC5, 0x4B, 0x62, 0x7F, 0x04)
@@ -241,6 +247,23 @@ static void mei_mkhi_fix(struct mei_cl_device *cldev)
mei_cldev_disable(cldev);
}
+static void mei_gsc_mkhi_ver(struct mei_cl_device *cldev)
+{
+ int ret;
+
+ /* No need to enable the client if nothing is needed from it */
+ if (!cldev->bus->fw_f_fw_ver_supported)
+ return;
+
+ ret = mei_cldev_enable(cldev);
+ if (ret)
+ return;
+
+ ret = mei_fwver(cldev);
+ if (ret < 0)
+ dev_err(&cldev->dev, "FW version command failed %d\n", ret);
+ mei_cldev_disable(cldev);
+}
/**
* mei_wd - wd client on the bus, change protocol version
* as the API has changed.
@@ -492,6 +515,8 @@ static struct mei_fixup {
MEI_FIXUP(MEI_UUID_NFC_HCI, mei_nfc),
MEI_FIXUP(MEI_UUID_WD, mei_wd),
MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
+ MEI_FIXUP(MEI_UUID_IGSC_MKHI, mei_gsc_mkhi_ver),
+ MEI_FIXUP(MEI_UUID_IGSC_MKHI_FIX, mei_gsc_mkhi_ver),
MEI_FIXUP(MEI_UUID_HDCP, whitelist),
MEI_FIXUP(MEI_UUID_ANY, vt_support),
MEI_FIXUP(MEI_UUID_PAVP, whitelist),
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 9748d14849a1..7e77328142ff 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -1577,12 +1577,14 @@ static const struct mei_cfg mei_me_pch15_sps_cfg = {
static const struct mei_cfg mei_me_gsc_cfg = {
MEI_CFG_TYPE_GSC,
MEI_CFG_PCH8_HFS,
+ MEI_CFG_FW_VER_SUPP,
};
/* Graphics System Controller Firmware Interface */
static const struct mei_cfg mei_me_gscfi_cfg = {
MEI_CFG_TYPE_GSCFI,
MEI_CFG_PCH8_HFS,
+ MEI_CFG_FW_VER_SUPP,
};
/*
--
2.32.0
Re: [Intel-gfx] [PATCH 04/14] drm/i915: Move drrs hardware bit frobbing to small helpers
On Thu, 27 Jan 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Split the drrs code that actually changes the refresh rate
> (via PIPECONF or M/N values) to small helper functions that
> only deal with the hardware details an nothing else. We'll
> soon have a third way of doing this, and it's less confusing
> when each difference method lives in its own funciton.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_drrs.c | 67 ---
> 1 file changed, 36 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
> b/drivers/gpu/drm/i915/display/intel_drrs.c
> index 46be46f2c47e..0cacdb174fd0 100644
> --- a/drivers/gpu/drm/i915/display/intel_drrs.c
> +++ b/drivers/gpu/drm/i915/display/intel_drrs.c
> @@ -87,6 +87,38 @@ intel_drrs_compute_config(struct intel_dp *intel_dp,
> pipe_config->dp_m2_n2.data_m *=
> pipe_config->splitter.link_count;
> }
>
> +static void
> +intel_drrs_set_refresh_rate_pipeconf(const struct intel_crtc_state
> *crtc_state,
> + enum drrs_refresh_rate_type refresh_type)
Side note, for future, does this really need to be an enum? Could it
just be a bool "reduced" or something?
Anyway,
Reviewed-by: Jani Nikula
> +{
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> + u32 val, bit;
> +
> + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + bit = PIPECONF_EDP_RR_MODE_SWITCH_VLV;
> + else
> + bit = PIPECONF_EDP_RR_MODE_SWITCH;
> +
> + val = intel_de_read(dev_priv, PIPECONF(cpu_transcoder));
> +
> + if (refresh_type == DRRS_LOW_RR)
> + val |= bit;
> + else
> + val &= ~bit;
> +
> + intel_de_write(dev_priv, PIPECONF(cpu_transcoder), val);
> +}
> +
> +static void
> +intel_drrs_set_refresh_rate_m_n(const struct intel_crtc_state *crtc_state,
> + enum drrs_refresh_rate_type refresh_type)
> +{
> + intel_dp_set_m_n(crtc_state,
> + refresh_type == DRRS_LOW_RR ? M2_N2 : M1_N1);
> +}
> +
> static void intel_drrs_set_state(struct drm_i915_private *dev_priv,
>const struct intel_crtc_state *crtc_state,
>enum drrs_refresh_rate_type refresh_type)
> @@ -120,37 +152,10 @@ static void intel_drrs_set_state(struct
> drm_i915_private *dev_priv,
> return;
> }
>
> - if (DISPLAY_VER(dev_priv) >= 8 && !IS_CHERRYVIEW(dev_priv)) {
> - switch (refresh_type) {
> - case DRRS_HIGH_RR:
> - intel_dp_set_m_n(crtc_state, M1_N1);
> - break;
> - case DRRS_LOW_RR:
> - intel_dp_set_m_n(crtc_state, M2_N2);
> - break;
> - case DRRS_MAX_RR:
> - default:
> - drm_err(&dev_priv->drm,
> - "Unsupported refreshrate type\n");
> - }
> - } else if (DISPLAY_VER(dev_priv) > 6) {
> - i915_reg_t reg = PIPECONF(crtc_state->cpu_transcoder);
> - u32 val;
> -
> - val = intel_de_read(dev_priv, reg);
> - if (refresh_type == DRRS_LOW_RR) {
> - if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> - val |= PIPECONF_EDP_RR_MODE_SWITCH_VLV;
> - else
> - val |= PIPECONF_EDP_RR_MODE_SWITCH;
> - } else {
> - if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> - val &= ~PIPECONF_EDP_RR_MODE_SWITCH_VLV;
> - else
> - val &= ~PIPECONF_EDP_RR_MODE_SWITCH;
> - }
> - intel_de_write(dev_priv, reg, val);
> - }
> + if (DISPLAY_VER(dev_priv) >= 8 && !IS_CHERRYVIEW(dev_priv))
> + intel_drrs_set_refresh_rate_m_n(crtc_state, refresh_type);
> + else if (DISPLAY_VER(dev_priv) > 6)
> + intel_drrs_set_refresh_rate_pipeconf(crtc_state, refresh_type);
>
> dev_priv->drrs.refresh_rate_type = refresh_type;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 04/14] drm/i915: Move drrs hardware bit frobbing to small helpers
On Thu, 27 Jan 2022, Jani Nikula wrote:
> On Thu, 27 Jan 2022, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> Split the drrs code that actually changes the refresh rate
>> (via PIPECONF or M/N values) to small helper functions that
>> only deal with the hardware details an nothing else. We'll
>> soon have a third way of doing this, and it's less confusing
>> when each difference method lives in its own funciton.
>>
>> Signed-off-by: Ville Syrjälä
>> ---
>> drivers/gpu/drm/i915/display/intel_drrs.c | 67 ---
>> 1 file changed, 36 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
>> b/drivers/gpu/drm/i915/display/intel_drrs.c
>> index 46be46f2c47e..0cacdb174fd0 100644
>> --- a/drivers/gpu/drm/i915/display/intel_drrs.c
>> +++ b/drivers/gpu/drm/i915/display/intel_drrs.c
>> @@ -87,6 +87,38 @@ intel_drrs_compute_config(struct intel_dp *intel_dp,
>> pipe_config->dp_m2_n2.data_m *=
>> pipe_config->splitter.link_count;
>> }
>>
>> +static void
>> +intel_drrs_set_refresh_rate_pipeconf(const struct intel_crtc_state
>> *crtc_state,
>> + enum drrs_refresh_rate_type refresh_type)
>
> Side note, for future, does this really need to be an enum? Could it
> just be a bool "reduced" or something?
And I mean throughout the driver, not just right here.
>
> Anyway,
>
> Reviewed-by: Jani Nikula
>
>
>
>> +{
>> +struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>> +struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> +enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>> +u32 val, bit;
>> +
>> +if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>> +bit = PIPECONF_EDP_RR_MODE_SWITCH_VLV;
>> +else
>> +bit = PIPECONF_EDP_RR_MODE_SWITCH;
>> +
>> +val = intel_de_read(dev_priv, PIPECONF(cpu_transcoder));
>> +
>> +if (refresh_type == DRRS_LOW_RR)
>> +val |= bit;
>> +else
>> +val &= ~bit;
>> +
>> +intel_de_write(dev_priv, PIPECONF(cpu_transcoder), val);
>> +}
>> +
>> +static void
>> +intel_drrs_set_refresh_rate_m_n(const struct intel_crtc_state *crtc_state,
>> +enum drrs_refresh_rate_type refresh_type)
>> +{
>> +intel_dp_set_m_n(crtc_state,
>> + refresh_type == DRRS_LOW_RR ? M2_N2 : M1_N1);
>> +}
>> +
>> static void intel_drrs_set_state(struct drm_i915_private *dev_priv,
>> const struct intel_crtc_state *crtc_state,
>> enum drrs_refresh_rate_type refresh_type)
>> @@ -120,37 +152,10 @@ static void intel_drrs_set_state(struct
>> drm_i915_private *dev_priv,
>> return;
>> }
>>
>> -if (DISPLAY_VER(dev_priv) >= 8 && !IS_CHERRYVIEW(dev_priv)) {
>> -switch (refresh_type) {
>> -case DRRS_HIGH_RR:
>> -intel_dp_set_m_n(crtc_state, M1_N1);
>> -break;
>> -case DRRS_LOW_RR:
>> -intel_dp_set_m_n(crtc_state, M2_N2);
>> -break;
>> -case DRRS_MAX_RR:
>> -default:
>> -drm_err(&dev_priv->drm,
>> -"Unsupported refreshrate type\n");
>> -}
>> -} else if (DISPLAY_VER(dev_priv) > 6) {
>> -i915_reg_t reg = PIPECONF(crtc_state->cpu_transcoder);
>> -u32 val;
>> -
>> -val = intel_de_read(dev_priv, reg);
>> -if (refresh_type == DRRS_LOW_RR) {
>> -if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>> -val |= PIPECONF_EDP_RR_MODE_SWITCH_VLV;
>> -else
>> -val |= PIPECONF_EDP_RR_MODE_SWITCH;
>> -} else {
>> -if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>> -val &= ~PIPECONF_EDP_RR_MODE_SWITCH_VLV;
>> -else
>> -val &= ~PIPECONF_EDP_RR_MODE_SWITCH;
>> -}
>> -intel_de_write(dev_priv, reg, val);
>> -}
>> +if (DISPLAY_VER(dev_priv) >= 8 && !IS_CHERRYVIEW(dev_priv))
>> +intel_drrs_set_refresh_rate_m_n(crtc_state, refresh_type);
>> +else if (DISPLAY_VER(dev_priv) > 6)
>> +intel_drrs_set_refresh_rate_pipeconf(crtc_state, refresh_type);
>>
>> dev_priv->drrs.refresh_rate_type = refresh_type;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v4 0/5] Add driver for GSC controller
On Thu, Jan 27, 2022 at 01:20:58PM +0200, Alexander Usyskin wrote: > GSC is a graphics system controller, it provides > a chassis controller for graphics discrete cards. > > There are two MEI interfaces in GSC: HECI1 and HECI2. > > This series includes instantiation of the auxiliary devices for HECI2 > and mei-gsc auxiliary device driver that binds to the auxiliary device. > > In v2 the platform device was replaced by the auxiliary device. > v3 is the rebase over drm-tip to make public CI running. > In v4 the not needed debug prints and empty line were removed, > 'select' were replaced by 'depends on' in MEI Kconfig, > the new include file now listed in the MAINTATINERS file. > > Greg KH, please review and ACK the MEI patches after main merge window > closure. The merge window already closed, did you forget to update your email? > We are pushing all through gfx tree as the auxiliary device belongs there. I'll get to this in a week or so, please be patient. greg k-h
Re: [Intel-gfx] [PATCH v4 0/5] Add driver for GSC controller
On Thu, Jan 27, 2022 at 12:31:07PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 27, 2022 at 01:20:58PM +0200, Alexander Usyskin wrote: > > GSC is a graphics system controller, it provides > > a chassis controller for graphics discrete cards. > > > > There are two MEI interfaces in GSC: HECI1 and HECI2. > > > > This series includes instantiation of the auxiliary devices for HECI2 > > and mei-gsc auxiliary device driver that binds to the auxiliary device. > > > > In v2 the platform device was replaced by the auxiliary device. > > v3 is the rebase over drm-tip to make public CI running. > > In v4 the not needed debug prints and empty line were removed, > > 'select' were replaced by 'depends on' in MEI Kconfig, > > the new include file now listed in the MAINTATINERS file. > > > > Greg KH, please review and ACK the MEI patches after main merge window > > closure. > > The merge window already closed, did you forget to update your email? > > > We are pushing all through gfx tree as the auxiliary device belongs there. > > I'll get to this in a week or so, please be patient. In the meantime, while you are waiting, please review other patches on the mailing lists to help with maintainer's workloads. greg k-h
Re: [Intel-gfx] [PATCH 02/14] drm/i915: Clean up M/N register defines
On Thu, Jan 27, 2022 at 01:17:21PM +0200, Jani Nikula wrote:
> On Thu, 27 Jan 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Use REG_GENMASK() & co. for the M/N register values. There are
> > also a lot of weird unused defines (eg. *_OFFSET) we can just
> > throw out.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 10 -
> > drivers/gpu/drm/i915/i915_reg.h | 22 +++-
> > 2 files changed, 8 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index f76faa195cb9..d91164d1eb92 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -3865,11 +3865,11 @@ static void intel_get_m_n(struct drm_i915_private
> > *i915,
> > i915_reg_t data_m_reg, i915_reg_t data_n_reg,
> > i915_reg_t link_m_reg, i915_reg_t link_n_reg)
> > {
> > - m_n->link_m = intel_de_read(i915, link_m_reg);
> > - m_n->link_n = intel_de_read(i915, link_n_reg);
> > - m_n->gmch_m = intel_de_read(i915, data_m_reg) & ~TU_SIZE_MASK;
> > - m_n->gmch_n = intel_de_read(i915, data_n_reg);
> > - m_n->tu = ((intel_de_read(i915, data_m_reg) & TU_SIZE_MASK) >>
> > TU_SIZE_SHIFT) + 1;
> > + m_n->link_m = intel_de_read(i915, link_m_reg) & DATA_LINK_M_N_MASK;
> > + m_n->link_n = intel_de_read(i915, link_n_reg) & DATA_LINK_M_N_MASK;
> > + m_n->gmch_m = intel_de_read(i915, data_m_reg) & DATA_LINK_M_N_MASK;
> > + m_n->gmch_n = intel_de_read(i915, data_n_reg) & DATA_LINK_M_N_MASK;
> > + m_n->tu = REG_FIELD_GET(TU_SIZE_MASK, intel_de_read(i915, data_m_reg))
> > + 1;
>
> The commit message might mention we throw some bits away while reading.
Right, forgot to note that.
>
> A follow-up could perhasps axe the double read of the data_m_reg, but
> *shrug*.
I was going back and forth between keeping the double read vs. reading
each just once here vs. reading straight in the callers and just passing
the values through (would avoid needing i915_reg_t for the prototype
in the headrer in a later patch). Somehow none of them tasted quit right
so opted to keep the current thing for now.
>
> Reviewed-by: Jani Nikula
>
>
> > }
> >
> > static void intel_pch_transcoder_get_m_n(struct intel_crtc *crtc,
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 2e4dd9db63fe..ec48406eb37a 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5209,16 +5209,14 @@ enum {
> > #define _PIPEB_DATA_M_G4X 0x71050
> >
> > /* Transfer unit size for display port - 1, default is 0x3f (for TU size
> > 64) */
> > -#define TU_SIZE(x) (((x) - 1) << 25) /* default size 64 */
> > -#define TU_SIZE_SHIFT 25
> > -#define TU_SIZE_MASK (0x3f << 25)
> > +#define TU_SIZE_MASK REG_GENMASK(30, 25)
> > +#define TU_SIZE(x)REG_FIELD_PREP(TU_SIZE_MASK, (x) - 1)
> > /* default size 64 */
> >
> > -#define DATA_LINK_M_N_MASK(0xff)
> > +#define DATA_LINK_M_N_MASKREG_GENMASK(23, 0)
> > #define DATA_LINK_N_MAX (0x80)
> >
> > #define _PIPEA_DATA_N_G4X 0x70054
> > #define _PIPEB_DATA_N_G4X 0x71054
> > -#define PIPE_GMCH_DATA_N_MASK(0xff)
> >
> > /*
> > * Computing Link M and N values for the Display Port link
> > @@ -5233,11 +5231,8 @@ enum {
> >
> > #define _PIPEA_LINK_M_G4X 0x70060
> > #define _PIPEB_LINK_M_G4X 0x71060
> > -#define PIPEA_DP_LINK_M_MASK (0xff)
> > -
> > #define _PIPEA_LINK_N_G4X 0x70064
> > #define _PIPEB_LINK_N_G4X 0x71064
> > -#define PIPEA_DP_LINK_N_MASK (0xff)
> >
> > #define PIPE_DATA_M_G4X(pipe) _MMIO_PIPE(pipe, _PIPEA_DATA_M_G4X,
> > _PIPEB_DATA_M_G4X)
> > #define PIPE_DATA_N_G4X(pipe) _MMIO_PIPE(pipe, _PIPEA_DATA_N_G4X,
> > _PIPEB_DATA_N_G4X)
> > @@ -6840,24 +6835,13 @@ enum {
> >
> >
> > #define _PIPEA_DATA_M1 0x60030
> > -#define PIPE_DATA_M1_OFFSET0
> > #define _PIPEA_DATA_N1 0x60034
> > -#define PIPE_DATA_N1_OFFSET0
> > -
> > #define _PIPEA_DATA_M2 0x60038
> > -#define PIPE_DATA_M2_OFFSET0
> > #define _PIPEA_DATA_N2 0x6003c
> > -#define PIPE_DATA_N2_OFFSET0
> > -
> > #define _PIPEA_LINK_M1 0x60040
> > -#define PIPE_LINK_M1_OFFSET0
> > #define _PIPEA_LINK_N1 0x60044
> > -#define PIPE_LINK_N1_OFFSET0
> > -
> > #define _PIPEA_LINK_M2 0x60048
> > -#define PIPE_LINK_M2_OFFSET0
> > #define _PIPEA_LINK_N2 0x6004c
> > -#define PIPE_LINK_N2_OFFSET0
> >
> > /* PIPEB timing regs are same start from 0x61000 */
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 04/14] drm/i915: Move drrs hardware bit frobbing to small helpers
On Thu, Jan 27, 2022 at 01:24:05PM +0200, Jani Nikula wrote: > On Thu, 27 Jan 2022, Jani Nikula wrote: > > On Thu, 27 Jan 2022, Ville Syrjala wrote: > >> From: Ville Syrjälä > >> > >> Split the drrs code that actually changes the refresh rate > >> (via PIPECONF or M/N values) to small helper functions that > >> only deal with the hardware details an nothing else. We'll > >> soon have a third way of doing this, and it's less confusing > >> when each difference method lives in its own funciton. > >> > >> Signed-off-by: Ville Syrjälä > >> --- > >> drivers/gpu/drm/i915/display/intel_drrs.c | 67 --- > >> 1 file changed, 36 insertions(+), 31 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c > >> b/drivers/gpu/drm/i915/display/intel_drrs.c > >> index 46be46f2c47e..0cacdb174fd0 100644 > >> --- a/drivers/gpu/drm/i915/display/intel_drrs.c > >> +++ b/drivers/gpu/drm/i915/display/intel_drrs.c > >> @@ -87,6 +87,38 @@ intel_drrs_compute_config(struct intel_dp *intel_dp, > >>pipe_config->dp_m2_n2.data_m *= > >> pipe_config->splitter.link_count; > >> } > >> > >> +static void > >> +intel_drrs_set_refresh_rate_pipeconf(const struct intel_crtc_state > >> *crtc_state, > >> + enum drrs_refresh_rate_type refresh_type) > > > > Side note, for future, does this really need to be an enum? Could it > > just be a bool "reduced" or something? > > And I mean throughout the driver, not just right here. I suppose a bool would suffice. I was going to rename it to at least have a bit more consistent namespace, but perhaps we could just nuke it entirely. -- Ville Syrjälä Intel
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add driver for GSC controller (rev4)
== Series Details == Series: Add driver for GSC controller (rev4) URL : https://patchwork.freedesktop.org/series/98066/ State : failure == Summary == Applying: drm/i915/gsc: add gsc as a mei auxiliary device Using index info to reconstruct a base tree... M MAINTAINERS M drivers/gpu/drm/i915/Makefile M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/i915_pci.c M drivers/gpu/drm/i915/i915_reg.h M drivers/gpu/drm/i915/intel_device_info.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_device_info.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_device_info.h Auto-merging drivers/gpu/drm/i915/i915_reg.h Auto-merging drivers/gpu/drm/i915/i915_pci.c Auto-merging drivers/gpu/drm/i915/i915_drv.h Auto-merging drivers/gpu/drm/i915/Makefile Auto-merging MAINTAINERS error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915/gsc: add gsc as a mei auxiliary device 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".
Re: [Intel-gfx] [PATCH 02/14] drm/i915: Clean up M/N register defines
On Thu, 27 Jan 2022, Ville Syrjälä wrote:
> On Thu, Jan 27, 2022 at 01:17:21PM +0200, Jani Nikula wrote:
>> On Thu, 27 Jan 2022, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > Use REG_GENMASK() & co. for the M/N register values. There are
>> > also a lot of weird unused defines (eg. *_OFFSET) we can just
>> > throw out.
>> >
>> > Signed-off-by: Ville Syrjälä
>> > ---
>> > drivers/gpu/drm/i915/display/intel_display.c | 10 -
>> > drivers/gpu/drm/i915/i915_reg.h | 22 +++-
>> > 2 files changed, 8 insertions(+), 24 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> > b/drivers/gpu/drm/i915/display/intel_display.c
>> > index f76faa195cb9..d91164d1eb92 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> > @@ -3865,11 +3865,11 @@ static void intel_get_m_n(struct drm_i915_private
>> > *i915,
>> > i915_reg_t data_m_reg, i915_reg_t data_n_reg,
>> > i915_reg_t link_m_reg, i915_reg_t link_n_reg)
>> > {
>> > - m_n->link_m = intel_de_read(i915, link_m_reg);
>> > - m_n->link_n = intel_de_read(i915, link_n_reg);
>> > - m_n->gmch_m = intel_de_read(i915, data_m_reg) & ~TU_SIZE_MASK;
>> > - m_n->gmch_n = intel_de_read(i915, data_n_reg);
>> > - m_n->tu = ((intel_de_read(i915, data_m_reg) & TU_SIZE_MASK) >>
>> > TU_SIZE_SHIFT) + 1;
>> > + m_n->link_m = intel_de_read(i915, link_m_reg) & DATA_LINK_M_N_MASK;
>> > + m_n->link_n = intel_de_read(i915, link_n_reg) & DATA_LINK_M_N_MASK;
>> > + m_n->gmch_m = intel_de_read(i915, data_m_reg) & DATA_LINK_M_N_MASK;
>> > + m_n->gmch_n = intel_de_read(i915, data_n_reg) & DATA_LINK_M_N_MASK;
>> > + m_n->tu = REG_FIELD_GET(TU_SIZE_MASK, intel_de_read(i915, data_m_reg))
>> > + 1;
>>
>> The commit message might mention we throw some bits away while reading.
>
> Right, forgot to note that.
>
>>
>> A follow-up could perhasps axe the double read of the data_m_reg, but
>> *shrug*.
>
> I was going back and forth between keeping the double read vs. reading
> each just once here vs. reading straight in the callers and just passing
> the values through (would avoid needing i915_reg_t for the prototype
> in the headrer in a later patch). Somehow none of them tasted quit right
> so opted to keep the current thing for now.
Yeah, not a big deal. Also now that i915_reg_t is in i915_reg_defs.h I
think the overhead for that is neglible.
BR,
Jani.
>
>>
>> Reviewed-by: Jani Nikula
>>
>>
>> > }
>> >
>> > static void intel_pch_transcoder_get_m_n(struct intel_crtc *crtc,
>> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> > b/drivers/gpu/drm/i915/i915_reg.h
>> > index 2e4dd9db63fe..ec48406eb37a 100644
>> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > @@ -5209,16 +5209,14 @@ enum {
>> > #define _PIPEB_DATA_M_G4X 0x71050
>> >
>> > /* Transfer unit size for display port - 1, default is 0x3f (for TU size
>> > 64) */
>> > -#define TU_SIZE(x) (((x) - 1) << 25) /* default size 64 */
>> > -#define TU_SIZE_SHIFT25
>> > -#define TU_SIZE_MASK (0x3f << 25)
>> > +#define TU_SIZE_MASK REG_GENMASK(30, 25)
>> > +#define TU_SIZE(x) REG_FIELD_PREP(TU_SIZE_MASK, (x) - 1)
>> > /* default size 64 */
>> >
>> > -#define DATA_LINK_M_N_MASK (0xff)
>> > +#define DATA_LINK_M_N_MASK REG_GENMASK(23, 0)
>> > #define DATA_LINK_N_MAX (0x80)
>> >
>> > #define _PIPEA_DATA_N_G4X 0x70054
>> > #define _PIPEB_DATA_N_G4X 0x71054
>> > -#define PIPE_GMCH_DATA_N_MASK (0xff)
>> >
>> > /*
>> > * Computing Link M and N values for the Display Port link
>> > @@ -5233,11 +5231,8 @@ enum {
>> >
>> > #define _PIPEA_LINK_M_G4X 0x70060
>> > #define _PIPEB_LINK_M_G4X 0x71060
>> > -#define PIPEA_DP_LINK_M_MASK(0xff)
>> > -
>> > #define _PIPEA_LINK_N_G4X 0x70064
>> > #define _PIPEB_LINK_N_G4X 0x71064
>> > -#define PIPEA_DP_LINK_N_MASK(0xff)
>> >
>> > #define PIPE_DATA_M_G4X(pipe) _MMIO_PIPE(pipe, _PIPEA_DATA_M_G4X,
>> > _PIPEB_DATA_M_G4X)
>> > #define PIPE_DATA_N_G4X(pipe) _MMIO_PIPE(pipe, _PIPEA_DATA_N_G4X,
>> > _PIPEB_DATA_N_G4X)
>> > @@ -6840,24 +6835,13 @@ enum {
>> >
>> >
>> > #define _PIPEA_DATA_M10x60030
>> > -#define PIPE_DATA_M1_OFFSET0
>> > #define _PIPEA_DATA_N10x60034
>> > -#define PIPE_DATA_N1_OFFSET0
>> > -
>> > #define _PIPEA_DATA_M20x60038
>> > -#define PIPE_DATA_M2_OFFSET0
>> > #define _PIPEA_DATA_N20x6003c
>> > -#define PIPE_DATA_N2_OFFSET0
>> > -
>> > #define _PIPEA_LINK_M10x60040
>> > -#define PIPE_LINK_M1_OFFSET0
>> > #define _PIPEA_LINK_N10x60044
>> > -#define PIPE_LINK_N1_OFFSET0
>> > -
>> > #define _PIPEA_LINK_M20x60048
>> > -#define PIPE_LINK_M2_OFFSET0
>> > #de
Re: [Intel-gfx] [PATCH 04/14] drm/i915: Move drrs hardware bit frobbing to small helpers
On Thu, 27 Jan 2022, Ville Syrjälä wrote: > On Thu, Jan 27, 2022 at 01:24:05PM +0200, Jani Nikula wrote: >> On Thu, 27 Jan 2022, Jani Nikula wrote: >> > On Thu, 27 Jan 2022, Ville Syrjala wrote: >> >> From: Ville Syrjälä >> >> >> >> Split the drrs code that actually changes the refresh rate >> >> (via PIPECONF or M/N values) to small helper functions that >> >> only deal with the hardware details an nothing else. We'll >> >> soon have a third way of doing this, and it's less confusing >> >> when each difference method lives in its own funciton. >> >> >> >> Signed-off-by: Ville Syrjälä >> >> --- >> >> drivers/gpu/drm/i915/display/intel_drrs.c | 67 --- >> >> 1 file changed, 36 insertions(+), 31 deletions(-) >> >> >> >> diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c >> >> b/drivers/gpu/drm/i915/display/intel_drrs.c >> >> index 46be46f2c47e..0cacdb174fd0 100644 >> >> --- a/drivers/gpu/drm/i915/display/intel_drrs.c >> >> +++ b/drivers/gpu/drm/i915/display/intel_drrs.c >> >> @@ -87,6 +87,38 @@ intel_drrs_compute_config(struct intel_dp *intel_dp, >> >> pipe_config->dp_m2_n2.data_m *= >> >> pipe_config->splitter.link_count; >> >> } >> >> >> >> +static void >> >> +intel_drrs_set_refresh_rate_pipeconf(const struct intel_crtc_state >> >> *crtc_state, >> >> + enum drrs_refresh_rate_type refresh_type) >> > >> > Side note, for future, does this really need to be an enum? Could it >> > just be a bool "reduced" or something? >> >> And I mean throughout the driver, not just right here. > > I suppose a bool would suffice. I was going to rename it to > at least have a bit more consistent namespace, but perhaps > we could just nuke it entirely. Also, should be done in follow-up, let's not complicate this set any more. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl-n: Add PCH Support for Alder Lake N
== Series Details ==
Series: drm/i915/adl-n: Add PCH Support for Alder Lake N
URL : https://patchwork.freedesktop.org/series/99413/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11149 -> Patchwork_22123
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/index.html
Participating hosts (45 -> 39)
--
Missing(6): fi-hsw-4200u fi-bsw-cyan fi-snb-2520m fi-ctg-p8600
fi-cfl-8109u fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22123 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u: NOTRUN -> [SKIP][1] ([fdo#109271]) +18 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][2] -> [DMESG-FAIL][3] ([i915#4494] /
[i915#4957])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][4] -> [INCOMPLETE][5] ([i915#3921])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [DMESG-FAIL][6] ([i915#4957]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: [FAIL][8] ([i915#4547]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
Warnings
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][10] ([i915#4785]) -> [INCOMPLETE][11]
([i915#3303])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
Build changes
-
* Linux: CI_DRM_11149 -> Patchwork_22123
CI-20190529: 20190529
CI_DRM_11149: 626b06cccf398c25e95dc0534ad018193005ad1b @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6336: ae2eb9e18bc58a4c45f28cfd80962938198dec3c @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22123: a8a597803de5650612f61da756491a1a15d9718b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a8a597803de5 drm/i915/adl-n: Add PCH Support for Alder Lake N
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/index.html
[Intel-gfx] [PATCH] drm/i915: Fix a race between vma / object destruction and unbinding
The vma destruction code was using an unlocked advisory check for drm_mm_node_allocated() to avoid racing with eviction code unbinding the vma. This is very fragile and prohibits the dereference of non-refcounted pointers of dying vmas after a call to __i915_vma_unbind(). It also prohibits the dereference of vma->obj of refcounted pointers of dying vmas after a call to __i915_vma_unbind(), since even if a refcount is held on the vma, that won't guarantee that its backing object doesn't get destroyed. So introduce an unbind under the vm mutex at object destroy time, removing all weak references of the vma and its object from the object vma list and from the vm bound list. Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_object.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c index 1a9e1f940a7d..e03e362d320b 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -280,6 +280,12 @@ void __i915_gem_object_pages_fini(struct drm_i915_gem_object *obj) GEM_BUG_ON(vma->obj != obj); spin_unlock(&obj->vma.lock); + /* Verify that the vma is unbound under the vm mutex. */ + mutex_lock(&vma->vm->mutex); + atomic_and(~I915_VMA_PIN_MASK, &vma->flags); + __i915_vma_unbind(vma); + mutex_unlock(&vma->vm->mutex); + __i915_vma_put(vma); spin_lock(&obj->vma.lock); -- 2.34.1
Re: [Intel-gfx] [Linaro-mm-sig] Re: [PATCH 02/19] dma-buf-map: Add helper to initialize second map
On Thu, Jan 27, 2022 at 12:44:21PM +0100, Christian König wrote:
> Am 27.01.22 um 12:16 schrieb Daniel Vetter:
> > On Thu, Jan 27, 2022 at 11:21:20AM +0100, Christian König wrote:
> > > Am 27.01.22 um 11:00 schrieb Daniel Vetter:
> > > > On Thu, Jan 27, 2022 at 01:33:32AM -0800, Lucas De Marchi wrote:
> > > > > On Thu, Jan 27, 2022 at 09:57:25AM +0100, Daniel Vetter wrote:
> > > > > > On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
> > > > > > > Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
> > > > > > > > On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
> > > > > > > > > Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
> > > > > > > > > > When dma_buf_map struct is passed around, it's useful to be
> > > > > > > > > > able to
> > > > > > > > > > initialize a second map that takes care of reading/writing
> > > > > > > > > > to an offset
> > > > > > > > > > of the original map.
> > > > > > > > > >
> > > > > > > > > > Add a helper that copies the struct and add the offset to
> > > > > > > > > > the proper
> > > > > > > > > > address.
> > > > > > > > > Well what you propose here can lead to all kind of problems
> > > > > > > > > and is
> > > > > > > > > rather bad design as far as I can see.
> > > > > > > > >
> > > > > > > > > The struct dma_buf_map is only to be filled in by the
> > > > > > > > > exporter and
> > > > > > > > > should not be modified in this way by the importer.
> > > > > > > > humn... not sure if I was clear. There is no importer and
> > > > > > > > exporter here.
> > > > > > > Yeah, and exactly that's what I'm pointing out as problem here.
> > > > > > >
> > > > > > > You are using the inter driver framework for something internal
> > > > > > > to the
> > > > > > > driver. That is an absolutely clear NAK!
> > > > > > >
> > > > > > > We could discuss that, but you guys are just sending around
> > > > > > > patches to do
> > > > > > > this without any consensus that this is a good idea.
> > > > > > Uh I suggested this, also we're already using dma_buf_map all over
> > > > > > the
> > > > > > place as a convenient abstraction. So imo that's all fine, it
> > > > > > should allow
> > > > > > drivers to simplify some code where on igpu it's in normal kernel
> > > > > > memory
> > > > > > and on dgpu it's behind some pci bar.
> > > > > >
> > > > > > Maybe we should have a better name for that struct (and maybe also a
> > > > > > better place), but way back when we discussed that bikeshed I
> > > > > > didn't come
> > > > > > up with anything better really.
> > > > > I suggest iosys_map since it abstracts access to IO and system memory.
> > > > >
> > > > > > > > There is a role delegation on filling out and reading a buffer
> > > > > > > > when
> > > > > > > > that buffer represents a struct layout.
> > > > > > > >
> > > > > > > > struct bla {
> > > > > > > > int a;
> > > > > > > > int b;
> > > > > > > > int c;
> > > > > > > > struct foo foo;
> > > > > > > > struct bar bar;
> > > > > > > > int d;
> > > > > > > > }
> > > > > > > >
> > > > > > > >
> > > > > > > > This implementation allows you to have:
> > > > > > > >
> > > > > > > > fill_foo(struct dma_buf_map *bla_map) { ... }
> > > > > > > > fill_bar(struct dma_buf_map *bla_map) { ... }
> > > > > > > >
> > > > > > > > and the first thing these do is to make sure the map it's
> > > > > > > > pointing to
> > > > > > > > is relative to the struct it's supposed to write/read.
> > > > > > > > Otherwise you're
> > > > > > > > suggesting everything to be relative to struct bla, or to do
> > > > > > > > the same
> > > > > > > > I'm doing it, but IMO more prone to error:
> > > > > > > >
> > > > > > > > struct dma_buf_map map = *bla_map;
> > > > > > > > dma_buf_map_incr(map, offsetof(...));
> > > > > > Wrt the issue at hand I think the above is perfectly fine code. The
> > > > > > idea
> > > > > > with dma_buf_map is really that it's just a special pointer, so
> > > > > > writing
> > > > > > the code exactly as pointer code feels best. Unfortunately you
> > > > > > cannot make
> > > > > > them typesafe (because of C), so the code sometimes looks a bit
> > > > > > ugly.
> > > > > > Otherwise we could do stuff like container_of and all that with
> > > > > > typechecking in the macros.
> > > > > I had exactly this code above, but after writting quite a few patches
> > > > > using it, particularly with functions that have to write to 2 maps
> > > > > (see
> > > > > patch 6 for example), it felt much better to have something to
> > > > > initialize correctly from the start
> > > > >
> > > > > struct dma_buf_map other_map = *bla_map;
> > > > > /* poor Lucas forgetting dma_buf_map_incr(map, offsetof(...));
> > > > > */
> > > > >
> > > > > is error prone and hard to debug since you will be reading/writting
> > > > > from/to another location rather than exploding
> > > > >
> > > > > While with the construct below
> > > > >
> > >
Re: [Intel-gfx] [PATCH] drm/i915: Fix a race between vma / object destruction and unbinding
Op 27-01-2022 om 12:56 schreef Thomas Hellström: > The vma destruction code was using an unlocked advisory check for > drm_mm_node_allocated() to avoid racing with eviction code unbinding > the vma. > > This is very fragile and prohibits the dereference of non-refcounted > pointers of dying vmas after a call to __i915_vma_unbind(). It also > prohibits the dereference of vma->obj of refcounted pointers of > dying vmas after a call to __i915_vma_unbind(), since even if a > refcount is held on the vma, that won't guarantee that its backing > object doesn't get destroyed. > > So introduce an unbind under the vm mutex at object destroy time, > removing all weak references of the vma and its object from the > object vma list and from the vm bound list. > > Signed-off-by: Thomas Hellström > --- > drivers/gpu/drm/i915/gem/i915_gem_object.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c > b/drivers/gpu/drm/i915/gem/i915_gem_object.c > index 1a9e1f940a7d..e03e362d320b 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c > @@ -280,6 +280,12 @@ void __i915_gem_object_pages_fini(struct > drm_i915_gem_object *obj) > GEM_BUG_ON(vma->obj != obj); > spin_unlock(&obj->vma.lock); > > + /* Verify that the vma is unbound under the vm mutex. */ > + mutex_lock(&vma->vm->mutex); > + atomic_and(~I915_VMA_PIN_MASK, &vma->flags); > + __i915_vma_unbind(vma); > + mutex_unlock(&vma->vm->mutex); > + > __i915_vma_put(vma); > > spin_lock(&obj->vma.lock); Reviewed-by: Maarten Lankhorst
[Intel-gfx] [PULL] drm-misc-next
Hi Dave & Daniel, First pull for v5.18 drm-misc-next-2022-01-27: drm-misc-next for v5.18: UAPI Changes: - Fix invalid IN_FORMATS blob when plane->format_mod_supported is NULL. Cross-subsystem Changes: - Assorted dt bindings updates. - Fix vga16fb vga checking on x86. - Fix extra semicolon in rwsem.h's _down_write_nest_lock. - Assorted small fixes to agp and fbdev drivers. - Fix oops in creating a udmabuf with 0 pages. - Hot-unplug firmware fb devices on forced removal - Reqquest memory region in simplefb and simpledrm, and don't make the ioresource as busy. Core Changes: - Mock a drm_plane in drm-plane-helper selftest. - Assorted bug fixes to device logging, dbi. - Use DP helper for sink count in mst. - Assorted documentation fixes. - Assorted small fixes. - Move DP headers to drm/dp, and add a drm dp helper module. - Move the buddy allocator from i915 to common drm. - Add simple pci and platform module init macros to remove a lot of boilerplate from some drivers. - Support microsoft extension for HMDs and specialized monitors. - Improve edid parser's deep color handling. - Add type 7 timing support to edid parser. - Add a weak backpointer to the ttm_bo from ttm_resource - Add 3 eDP panels. Driver Changes: - Add support for HDMI and JZ4780 to ingenic. - Add support for higher DP/eDP bitrates to nouveau. - Assorted driver fixes to tilcdc, vmwgfx, sn65dsi83, meson, stm, panfrost, v3d, gma500, vc4, virtio, mgag200, ast, radeon, amdgpu, nouveau, various bridge drivers. - Convert and revert exynos dsi support to bridge driver. - Add vcc supply regulator support for sn65dsi83. - More conversion of bridge/chipone-icn6211 to atomic. - Remove conflicting fb's from stm, and add support for new hw version. - Add device link in parade-ps8640 to fix suspend/resume. - Update Boe-tv110c9m init sequence. - Add wide screen support to AST2600. - Fix omapdrm implicit dma_buf fencing. - Add support for multiple overlay planes to vkms. - Convert bridge/anx7625 to atomic, add HDCP support, add eld support for audio, and fix HPD. - Add driver for ChromeOS privacy screen. - Handover display from firmware to vc4 more gracefully, and support nomodeset. - Add flexible and ycbcr pixel formats to stm/ltdc. - Convert exynos mipi dsi to atomic. - Add initial dual core group GPUs support to panfrost. - No longer add exclusive fence in amdgpu as shared fence. - Add CSC and full range supoprt to vc4. - Shutdown the display on system shutdown and unbind. - Add Multi-Inno Technology MI0700S4T-6 simple panel. The following changes since commit 9758ff2fa240173e9a45613b07774b7a78b7653e: Merge drm/drm-next into drm-misc-next (2021-12-16 14:48:27 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2022-01-27 for you to fetch changes up to a5d092d37eb5d25520d283985082e977bda68eb7: drm/panel: simple: add Multi-Inno Technology MI0700S4T-6 (2022-01-27 09:29:16 +0100) drm-misc-next for v5.18: UAPI Changes: - Fix invalid IN_FORMATS blob when plane->format_mod_supported is NULL. Cross-subsystem Changes: - Assorted dt bindings updates. - Fix vga16fb vga checking on x86. - Fix extra semicolon in rwsem.h's _down_write_nest_lock. - Assorted small fixes to agp and fbdev drivers. - Fix oops in creating a udmabuf with 0 pages. - Hot-unplug firmware fb devices on forced removal - Reqquest memory region in simplefb and simpledrm, and don't make the ioresource as busy. Core Changes: - Mock a drm_plane in drm-plane-helper selftest. - Assorted bug fixes to device logging, dbi. - Use DP helper for sink count in mst. - Assorted documentation fixes. - Assorted small fixes. - Move DP headers to drm/dp, and add a drm dp helper module. - Move the buddy allocator from i915 to common drm. - Add simple pci and platform module init macros to remove a lot of boilerplate from some drivers. - Support microsoft extension for HMDs and specialized monitors. - Improve edid parser's deep color handling. - Add type 7 timing support to edid parser. - Add a weak backpointer to the ttm_bo from ttm_resource - Add 3 eDP panels. Driver Changes: - Add support for HDMI and JZ4780 to ingenic. - Add support for higher DP/eDP bitrates to nouveau. - Assorted driver fixes to tilcdc, vmwgfx, sn65dsi83, meson, stm, panfrost, v3d, gma500, vc4, virtio, mgag200, ast, radeon, amdgpu, nouveau, various bridge drivers. - Convert and revert exynos dsi support to bridge driver. - Add vcc supply regulator support for sn65dsi83. - More conversion of bridge/chipone-icn6211 to atomic. - Remove conflicting fb's from stm, and add support for new hw version. - Add device link in parade-ps8640 to fix suspend/resume. - Update Boe-tv110c9m init sequence. - Add wide screen support to AST2600. - Fix omapdrm implicit dma_buf fencing. - Add support for multiple overlay planes to vkms. - Convert bridge/anx7625 to atomic, add HDCP support, add eld support for audio, an
Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/i915/pmu: Fix KMD and GuC race on accessing busyness
On Thu, 27 Jan 2022, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm/i915/pmu: Fix KMD and GuC race on > accessing busyness > URL : https://patchwork.freedesktop.org/series/99386/ > State : failure > > == Summary == > > CALLscripts/checksyscalls.sh > CALLscripts/atomic/check-atomics.sh > DESCEND objtool > CHK include/generated/compile.h > CC [M] drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c: In function > ‘guc_update_pm_timestamp’: > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1217:36: error: ‘uncore’ > undeclared (first use in this function); did you mean ‘node’? > gpm_ts = intel_uncore_read64_2x32(uncore, MISC_STATUS0, MISC_STATUS1) >> > ^~ > node > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1217:36: note: each > undeclared identifier is reported only once for each function it appears in > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:1210:19: error: unused > variable ‘gt’ [-Werror=unused-variable] > struct intel_gt *gt = guc_to_gt(guc); Please use CONFIG_DRM_I915_WERROR=y during development. BR, Jani. >^~ > cc1: all warnings being treated as errors > scripts/Makefile.build:288: recipe for target > 'drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o' failed > make[4]: *** [drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o] Error 1 > scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm/i915' failed > make[3]: *** [drivers/gpu/drm/i915] Error 2 > scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm' failed > make[2]: *** [drivers/gpu/drm] Error 2 > scripts/Makefile.build:550: recipe for target 'drivers/gpu' failed > make[1]: *** [drivers/gpu] Error 2 > Makefile:1831: recipe for target 'drivers' failed > make: *** [drivers] Error 2 > > -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: Lock dpt_obj around set_cache_level, v2.
Op 26-01-2022 om 13:55 schreef Gwan-gyeong Mun:
>
>
> On 1/26/22 9:37 AM, Maarten Lankhorst wrote:
>> set_cache_level may unbind the object, which will result in the below
>> lockdep splat:
>> <6> [184.578145] [IGT] kms_addfb_basic: starting subtest
>> addfb25-framebuffer-vs-set-tiling
>> <4> [184.578220] [ cut here ]
>> <4> [184.578221] WARN_ON(debug_locks &&
>> !(lock_is_held(&(&((obj)->base.resv)->lock.base)->dep_map) != 0))
>> <4> [184.578237] WARNING: CPU: 6 PID: 5544 at
>> drivers/gpu/drm/i915/i915_gem.c:123 i915_gem_object_unbind+0x4a9/0x510 [i915]
>> <4> [184.578323] Modules linked in: vgem drm_shmem_helper snd_hda_codec_hdmi
>> i915 mei_hdcp x86_pkg_temp_thermal snd_hda_intel coretemp crct10dif_pclmul
>> snd_intel_dspcfg crc32_pclmul ttm snd_hda_codec ghash_clmulni_intel
>> snd_hwdep drm_kms_helper snd_hda_core e1000e mei_me syscopyarea ptp snd_pcm
>> sysfillrect mei pps_core sysimgblt fb_sys_fops prime_numbers intel_lpss_pci
>> smsc75xx usbnet mii
>> <4> [184.578349] CPU: 6 PID: 5544 Comm: kms_addfb_basic Not tainted
>> 5.16.0-CI-Patchwork_22006+ #1
>> <4> [184.578351] Hardware name: Intel Corporation Alder Lake Client
>> Platform/AlderLake-P DDR4 RVP, BIOS ADLPFWI1.R00.2422.A00.2110131104
>> 10/13/2021
>> <4> [184.578352] RIP: 0010:i915_gem_object_unbind+0x4a9/0x510 [i915]
>> <4> [184.578424] Code: 00 be ff ff ff ff 48 8d 78 68 e8 a2 6e 2b e1 85 c0 0f
>> 85 b1 fb ff ff 48 c7 c6 48 37 9e a0 48 c7 c7 d9 fc a1 a0 e8 a3 54 26 e1 <0f>
>> 0b e9 97 fb ff ff 31 ed 48 8b 5c 24 58 65 48 33 1c 25 28 00 00
>> <4> [184.578426] RSP: 0018:c900013b3b68 EFLAGS: 00010286
>> <4> [184.578428] RAX: RBX: c900013b3bb0 RCX:
>> 0001
>> <4> [184.578429] RDX: 8001 RSI: 8230b42d RDI:
>>
>> <4> [184.578430] RBP: 888120e1 R08: R09:
>> c0007fff
>> <4> [184.578431] R10: 0001 R11: c900013b3980 R12:
>> 8881176ea740
>> <4> [184.578432] R13: 888120e1 R14: R15:
>> 0001
>> <4> [184.578433] FS: 7f65074f5e40() GS:8f30()
>> knlGS:
>> <4> [184.578435] CS: 0010 DS: ES: CR0: 80050033
>> <4> [184.578436] CR2: 7fff4420ede8 CR3: 00010c2f2005 CR4:
>> 00770ee0
>> <4> [184.578437] PKRU: 5554
>> <4> [184.578438] Call Trace:
>> <4> [184.578439]
>> <4> [184.578440] ? dma_resv_iter_first_unlocked+0x78/0xf0
>> <4> [184.578447] intel_dpt_create+0x88/0x220 [i915]
>> <4> [184.578530] intel_framebuffer_init+0x5b8/0x620 [i915]
>> <4> [184.578612] intel_framebuffer_create+0x3d/0x60 [i915]
>> <4> [184.578691] intel_user_framebuffer_create+0x18f/0x2c0 [i915]
>> <4> [184.578775] drm_internal_framebuffer_create+0x36d/0x4c0
>> <4> [184.578779] drm_mode_addfb2+0x2f/0xd0
>> <4> [184.578781] ? drm_mode_addfb_ioctl+0x10/0x10
>> <4> [184.578784] drm_ioctl_kernel+0xac/0x140
>> <4> [184.578787] drm_ioctl+0x201/0x3d0
>> <4> [184.578789] ? drm_mode_addfb_ioctl+0x10/0x10
>> <4> [184.578796] __x64_sys_ioctl+0x6a/0xa0
>> <4> [184.578800] do_syscall_64+0x37/0xb0
>> <4> [184.578803] entry_SYSCALL_64_after_hwframe+0x44/0xae
>> <4> [184.578805] RIP: 0033:0x7f6506736317
>> <4> [184.578807] Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26 00 00 00 48
>> c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48>
>> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 41 4b 2d 00 f7 d8 64 89 01 48
>> <4> [184.578808] RSP: 002b:7fff44211a98 EFLAGS: 0246 ORIG_RAX:
>> 0010
>> <4> [184.578810] RAX: ffda RBX: 0006 RCX:
>> 7f6506736317
>> <4> [184.578811] RDX: 7fff44211b30 RSI: c06864b8 RDI:
>> 0006
>> <4> [184.578812] RBP: 7fff44211b30 R08: 7fff44311170 R09:
>>
>> <4> [184.578813] R10: 0008 R11: 0246 R12:
>> c06864b8
>> <4> [184.578813] R13: 0006 R14: R15:
>>
>> <4> [184.578819]
>> <4> [184.578820] irq event stamp: 47931
>> <4> [184.578821] hardirqs last enabled at (47937): []
>> __up_console_sem+0x62/0x70
>> <4> [184.578824] hardirqs last disabled at (47942): []
>> __up_console_sem+0x47/0x70
>> <4> [184.578826] softirqs last enabled at (47340): []
>> __do_softirq+0x32d/0x493
>> <4> [184.578828] softirqs last disabled at (47335): []
>> irq_exit_rcu+0xa6/0xe0
>> <4> [184.578830] ---[ end trace f17ec219f892c7d4 ]---
>>
>> Changes since v1:
>> - Fix intel_pin_fb_obj_dpt too.
>>
>> Fixes: 0f341974cbc2 ("drm/i915: Add i915_vma_unbind_unlocked, and take obj
>> lock for i915_vma_unbind, v2.")
>> Signed-off-by: Maarten Lankhorst
>> Testcase: kms_addfb_basic
>> ---
>> drivers/gpu/drm/i915/display/intel_dpt.c | 6 +-
>> drivers/gpu/drm/i915/display/intel_fb_pin.c | 6 +-
>> 2 files changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
>> b/drivers
[Intel-gfx] [PATCH v2 02/14] drm/i915: Clean up M/N register defines
From: Ville Syrjälä
Use REG_GENMASK() & co. for the M/N register values. There are
also a lot of weird unused defines (eg. *_OFFSET) we can just
throw out.
Also let's mask out the unused bits during readout for good
measure. Previously we only masked out the TU_SIZE from one
of the registers, which was a bit too inconsistent for my
taste.
v2: Mention the readout masking in the commit msg (Jani)
Dal wth gvt
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 10 -
drivers/gpu/drm/i915/gvt/display.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h | 22 +++-
3 files changed, 10 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f76faa195cb9..d91164d1eb92 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3865,11 +3865,11 @@ static void intel_get_m_n(struct drm_i915_private *i915,
i915_reg_t data_m_reg, i915_reg_t data_n_reg,
i915_reg_t link_m_reg, i915_reg_t link_n_reg)
{
- m_n->link_m = intel_de_read(i915, link_m_reg);
- m_n->link_n = intel_de_read(i915, link_n_reg);
- m_n->gmch_m = intel_de_read(i915, data_m_reg) & ~TU_SIZE_MASK;
- m_n->gmch_n = intel_de_read(i915, data_n_reg);
- m_n->tu = ((intel_de_read(i915, data_m_reg) & TU_SIZE_MASK) >>
TU_SIZE_SHIFT) + 1;
+ m_n->link_m = intel_de_read(i915, link_m_reg) & DATA_LINK_M_N_MASK;
+ m_n->link_n = intel_de_read(i915, link_n_reg) & DATA_LINK_M_N_MASK;
+ m_n->gmch_m = intel_de_read(i915, data_m_reg) & DATA_LINK_M_N_MASK;
+ m_n->gmch_n = intel_de_read(i915, data_n_reg) & DATA_LINK_M_N_MASK;
+ m_n->tu = REG_FIELD_GET(TU_SIZE_MASK, intel_de_read(i915, data_m_reg))
+ 1;
}
static void intel_pch_transcoder_get_m_n(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/gvt/display.c
b/drivers/gpu/drm/i915/gvt/display.c
index 7198d02edc74..3ce88dea525c 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -253,7 +253,7 @@ static void emulate_monitor_status_change(struct intel_vgpu
*vgpu)
* DP link clk 1620 MHz and non-constant_n.
* TODO: calculate DP link symbol clk and stream clk m/n.
*/
- vgpu_vreg_t(vgpu, PIPE_DATA_M1(TRANSCODER_A)) = 63 <<
TU_SIZE_SHIFT;
+ vgpu_vreg_t(vgpu, PIPE_DATA_M1(TRANSCODER_A)) = TU_SIZE(64);
vgpu_vreg_t(vgpu, PIPE_DATA_M1(TRANSCODER_A)) |= 0x5b425e;
vgpu_vreg_t(vgpu, PIPE_DATA_N1(TRANSCODER_A)) = 0x80;
vgpu_vreg_t(vgpu, PIPE_LINK_M1(TRANSCODER_A)) = 0x3cd6e;
@@ -387,7 +387,7 @@ static void emulate_monitor_status_change(struct intel_vgpu
*vgpu)
* DP link clk 1620 MHz and non-constant_n.
* TODO: calculate DP link symbol clk and stream clk m/n.
*/
- vgpu_vreg_t(vgpu, PIPE_DATA_M1(TRANSCODER_A)) = 63 <<
TU_SIZE_SHIFT;
+ vgpu_vreg_t(vgpu, PIPE_DATA_M1(TRANSCODER_A)) = TU_SIZE(64);
vgpu_vreg_t(vgpu, PIPE_DATA_M1(TRANSCODER_A)) |= 0x5b425e;
vgpu_vreg_t(vgpu, PIPE_DATA_N1(TRANSCODER_A)) = 0x80;
vgpu_vreg_t(vgpu, PIPE_LINK_M1(TRANSCODER_A)) = 0x3cd6e;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2e4dd9db63fe..ec48406eb37a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5209,16 +5209,14 @@ enum {
#define _PIPEB_DATA_M_G4X 0x71050
/* Transfer unit size for display port - 1, default is 0x3f (for TU size 64) */
-#define TU_SIZE(x) (((x) - 1) << 25) /* default size 64 */
-#define TU_SIZE_SHIFT 25
-#define TU_SIZE_MASK (0x3f << 25)
+#define TU_SIZE_MASK REG_GENMASK(30, 25)
+#define TU_SIZE(x)REG_FIELD_PREP(TU_SIZE_MASK, (x) - 1) /*
default size 64 */
-#define DATA_LINK_M_N_MASK(0xff)
+#define DATA_LINK_M_N_MASKREG_GENMASK(23, 0)
#define DATA_LINK_N_MAX (0x80)
#define _PIPEA_DATA_N_G4X 0x70054
#define _PIPEB_DATA_N_G4X 0x71054
-#define PIPE_GMCH_DATA_N_MASK(0xff)
/*
* Computing Link M and N values for the Display Port link
@@ -5233,11 +5231,8 @@ enum {
#define _PIPEA_LINK_M_G4X 0x70060
#define _PIPEB_LINK_M_G4X 0x71060
-#define PIPEA_DP_LINK_M_MASK (0xff)
-
#define _PIPEA_LINK_N_G4X 0x70064
#define _PIPEB_LINK_N_G4X 0x71064
-#define PIPEA_DP_LINK_N_MASK (0xff)
#define PIPE_DATA_M_G4X(pipe) _MMIO_PIPE(pipe, _PIPEA_DATA_M_G4X,
_PIPEB_DATA_M_G4X)
#define PIPE_DATA_N_G4X(pipe) _MMIO_PIPE(pipe, _PIPEA_DATA_N_G4X,
_PIPEB_DATA_N_G4X)
@@ -6840,24 +6835,13 @@ enum {
#define _PIPEA_DATA_
[Intel-gfx] [PATCH 1/3] i915/gvt: Introduce the mmio_table.c to support VFIO new mdev API
From: Zhi Wang
To support the new mdev interfaces and the re-factor patches from
Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
initialization path has to be separated into two phases:
a) Early initialization.
The early initialization of GVT requires to be done when loading i915.
Mostly it's because the initial clean HW state needs to be saved before
i915 touches the HW.
b) Late initalization.
This phases of initalization will setup the rest components of GVT-g,
which can be done later when the dedicated module is being loaded.
v5:
- Re-design the mmio table framework. (Chirstoph)
v4:
- Fix the errors of patch checking scripts.
v3:
- Fix the errors when CONFIG_DRM_I915_WERROR is turned on. (Jani)
v2:
- Implement a mmio table instead of generating it by marco in i915. (Jani)
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Vivi Rodrigo
Cc: Zhenyu Wang
Cc: Zhi Wang
Tested-by: Terrence Xu
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/Makefile |2 +-
drivers/gpu/drm/i915/gvt/cmd_parser.c |2 +-
drivers/gpu/drm/i915/gvt/gvt.c| 19 +-
drivers/gpu/drm/i915/gvt/gvt.h| 21 +-
drivers/gpu/drm/i915/gvt/handlers.c | 1878 +
drivers/gpu/drm/i915/gvt/mmio.h |2 -
drivers/gpu/drm/i915/gvt/mmio_table.c | 1386 ++
drivers/gpu/drm/i915/gvt/mmio_table.h | 58 +
drivers/gpu/drm/i915/gvt/reg.h|9 +-
9 files changed, 1796 insertions(+), 1581 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gvt/mmio_table.c
create mode 100644 drivers/gpu/drm/i915/gvt/mmio_table.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26e6736bebb..029e5f5e0955 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -318,7 +318,7 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
i915-y += i915_vgpu.o
ifeq ($(CONFIG_DRM_I915_GVT),y)
-i915-y += intel_gvt.o
+i915-y += intel_gvt.o gvt/mmio_table.o
include $(src)/gvt/Makefile
endif
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index ec18122cc216..e9b5c70bb004 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -3205,7 +3205,7 @@ int intel_gvt_scan_engine_context(struct
intel_vgpu_workload *workload)
static int init_cmd_table(struct intel_gvt *gvt)
{
- unsigned int gen_type = intel_gvt_get_device_type(gvt);
+ unsigned int gen_type = intel_gvt_get_device_type(gvt->gt->i915);
int i;
for (i = 0; i < ARRAY_SIZE(cmd_info); i++) {
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index f0b69e4dcb52..a0243e863613 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -63,23 +63,6 @@ static const struct intel_gvt_ops intel_gvt_ops = {
.emulate_hotplug = intel_vgpu_emulate_hotplug,
};
-static void init_device_info(struct intel_gvt *gvt)
-{
- struct intel_gvt_device_info *info = &gvt->device_info;
- struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
-
- info->max_support_vgpus = 8;
- info->cfg_space_size = PCI_CFG_SPACE_EXP_SIZE;
- info->mmio_size = 2 * 1024 * 1024;
- info->mmio_bar = 0;
- info->gtt_start_offset = 8 * 1024 * 1024;
- info->gtt_entry_size = 8;
- info->gtt_entry_size_shift = 3;
- info->gmadr_bytes_in_cmd = 8;
- info->max_surface_size = 36 * 1024 * 1024;
- info->msi_cap_offset = pdev->msi_cap;
-}
-
static void intel_gvt_test_and_emulate_vblank(struct intel_gvt *gvt)
{
struct intel_vgpu *vgpu;
@@ -208,7 +191,7 @@ int intel_gvt_init_device(struct drm_i915_private *i915)
gvt->gt = to_gt(i915);
i915->gvt = gvt;
- init_device_info(gvt);
+ intel_gvt_init_device_info(i915, &gvt->device_info);
ret = intel_gvt_setup_mmio_info(gvt);
if (ret)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 0ebffc327528..e4513e2ce469 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -40,6 +40,7 @@
#include "debug.h"
#include "hypercall.h"
#include "mmio.h"
+#include "mmio_table.h"
#include "reg.h"
#include "interrupt.h"
#include "gtt.h"
@@ -65,20 +66,6 @@ struct intel_gvt_host {
extern struct intel_gvt_host intel_gvt_host;
-/* Describe per-platform limitations. */
-struct intel_gvt_device_info {
- u32 max_support_vgpus;
- u32 cfg_space_size;
- u32 mmio_size;
- u32 mmio_bar;
- unsigned long msi_cap_offset;
- u32 gtt_start_offset;
- u32 gtt_entry_size;
- u32 gtt_entry_size_shift;
- int gmadr_bytes_in_cmd;
- u32 max_surface_size;
-};
-
/* GM resources owned by a vGPU */
struct intel_vgpu_gm {
u64 aperture_sz;
@@ -239,9 +226,9 @@ struct intel_gvt_fence {
};
/* Special MMIO blocks. */
-struct gvt_mmio_block {
+str
[Intel-gfx] [PATCH 2/3] i915/gvt: save the initial HW state snapshot in i915.
Save the inital HW state snapshot in i915 so that the rest code of GVT-g
can be moved into a dedicated module while it can still get a clean
initial HW state saved at the correct time during the initialization of
i915. The futhrer vGPU created by GVT-g will use this HW state as the
initial HW state.
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Vivi Rodrigo
Cc: Zhenyu Wang
Cc: Zhi Wang
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_gvt.c | 110 ++-
2 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 44c1f98144b4..2a230840cdfa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -606,6 +606,8 @@ struct i915_virtual_gpu {
struct mutex lock; /* serialises sending of g2v_notify command pkts */
bool active;
u32 caps;
+ u32 *initial_mmio;
+ u8 *initial_cfg_space;
};
struct i915_selftest_stash {
diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index cf6e98962d82..a3d8bdb24d3f 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -86,6 +86,103 @@ void intel_gvt_sanitize_options(struct drm_i915_private
*dev_priv)
dev_priv->params.enable_gvt = 0;
}
+static void free_initial_hw_state(struct drm_i915_private *dev_priv)
+{
+ struct i915_virtual_gpu *vgpu = &dev_priv->vgpu;
+
+ vfree(vgpu->initial_mmio);
+ vgpu->initial_mmio = NULL;
+
+ kfree(vgpu->initial_cfg_space);
+ vgpu->initial_cfg_space = NULL;
+}
+
+static void save_mmio(struct intel_gvt_mmio_table_iter *iter, u32 offset,
+ u32 size)
+{
+ struct drm_i915_private *dev_priv = iter->i915;
+ void *mmio = iter->data;
+ u32 start, end, i;
+
+ start = offset;
+ end = offset + size;
+
+ for (i = start; i < end; i += 4) {
+ *(u32 *)(mmio + i) = intel_uncore_read_notrace(
+ to_gt(dev_priv)->uncore, _MMIO(offset));
+ }
+}
+
+static int do_mmio(u32 offset, u16 flags, u32 size, u32 addr_mask,
+ u32 ro_mask, u32 device,
+ struct intel_gvt_mmio_table_iter *iter)
+{
+ if (WARN_ON(!IS_ALIGNED(offset, 4)))
+ return -EINVAL;
+
+ save_mmio(iter, offset, size);
+ return 0;
+}
+
+static int do_mmio_block(u32 offset, u32 size, u32 device,
+struct intel_gvt_mmio_table_iter *iter)
+{
+ if (WARN_ON(!IS_ALIGNED(offset, 4)))
+ return -EINVAL;
+
+ save_mmio(iter, offset, size);
+ return 0;
+}
+
+static int save_inital_hw_state(struct drm_i915_private *dev_priv)
+{
+ struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
+ struct intel_gvt_device_info info;
+ struct i915_virtual_gpu *vgpu = &dev_priv->vgpu;
+ struct intel_gvt_mmio_table_iter iter;
+ void *mem;
+ int i, ret;
+
+ intel_gvt_init_device_info(dev_priv, &info);
+
+ mem = kzalloc(info.cfg_space_size, GFP_KERNEL);
+ if (!mem)
+ return -ENOMEM;
+
+ vgpu->initial_cfg_space = mem;
+
+ for (i = 0; i < PCI_CFG_SPACE_EXP_SIZE; i += 4)
+ pci_read_config_dword(pdev, i, mem + i);
+
+ mem = vzalloc(info.mmio_size);
+ if (!mem) {
+ ret = -ENOMEM;
+ goto err_mmio;
+ }
+
+ vgpu->initial_mmio = mem;
+
+ iter.i915 = dev_priv;
+ iter.data = vgpu->initial_mmio;
+ iter.do_mmio = do_mmio;
+ iter.do_mmio_block = do_mmio_block;
+
+ ret = intel_gvt_iterate_mmio_table(&iter);
+ if (ret)
+ goto err_iterate;
+
+ return 0;
+
+err_iterate:
+ vfree(vgpu->initial_mmio);
+ vgpu->initial_mmio = NULL;
+err_mmio:
+ kfree(vgpu->initial_cfg_space);
+ vgpu->initial_cfg_space = NULL;
+
+ return ret;
+}
+
/**
* intel_gvt_init - initialize GVT components
* @dev_priv: drm i915 private data
@@ -115,15 +212,23 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
return -EIO;
}
+ ret = save_inital_hw_state(dev_priv);
+ if (ret) {
+ drm_dbg(&dev_priv->drm, "Fail to save inital HW state\n");
+ goto err_save_hw_state;
+ }
+
ret = intel_gvt_init_device(dev_priv);
if (ret) {
drm_dbg(&dev_priv->drm, "Fail to init GVT device\n");
- goto bail;
+ goto err_init_device;
}
return 0;
-bail:
+err_init_device:
+ free_initial_hw_state(dev_priv);
+err_save_hw_state:
dev_priv->params.enable_gvt = 0;
return 0;
}
@@ -147,6 +252,7 @@ void intel_gvt_driver_remove(struct drm_i915_private
*dev_priv)
return;
intel_gvt_clean_device(dev_priv);
+ free_initi
[Intel-gfx] [PATCH 3/3] i915/gvt: Use the initial HW state snapshot saved in i915
The code of saving initial HW state snapshot has been moved into i915.
Let the GVT-g core logic use that snapshot.
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Vivi Rodrigo
Cc: Zhenyu Wang
Cc: Zhi Wang
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/gvt/firmware.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c
b/drivers/gpu/drm/i915/gvt/firmware.c
index 1a8274a3f4b1..1d55920bfd42 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -66,22 +66,16 @@ static struct bin_attribute firmware_attr = {
.mmap = NULL,
};
-static int mmio_snapshot_handler(struct intel_gvt *gvt, u32 offset, void *data)
-{
- *(u32 *)(data + offset) = intel_uncore_read_notrace(gvt->gt->uncore,
- _MMIO(offset));
- return 0;
-}
-
static int expose_firmware_sysfs(struct intel_gvt *gvt)
{
struct intel_gvt_device_info *info = &gvt->device_info;
- struct pci_dev *pdev = to_pci_dev(gvt->gt->i915->drm.dev);
+ struct drm_i915_private *i915 = gvt->gt->i915;
+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
struct gvt_firmware_header *h;
void *firmware;
void *p;
unsigned long size, crc32_start;
- int i, ret;
+ int ret;
size = sizeof(*h) + info->mmio_size + info->cfg_space_size;
firmware = vzalloc(size);
@@ -99,17 +93,16 @@ static int expose_firmware_sysfs(struct intel_gvt *gvt)
p = firmware + h->cfg_space_offset;
- for (i = 0; i < h->cfg_space_size; i += 4)
- pci_read_config_dword(pdev, i, p + i);
-
- memcpy(gvt->firmware.cfg_space, p, info->cfg_space_size);
+ memcpy(gvt->firmware.cfg_space, i915->vgpu.initial_cfg_space,
+ info->cfg_space_size);
+ memcpy(p, gvt->firmware.cfg_space, info->cfg_space_size);
p = firmware + h->mmio_offset;
- /* Take a snapshot of hw mmio registers. */
- intel_gvt_for_each_tracked_mmio(gvt, mmio_snapshot_handler, p);
+ memcpy(gvt->firmware.mmio, i915->vgpu.initial_mmio,
+ info->mmio_size);
- memcpy(gvt->firmware.mmio, p, info->mmio_size);
+ memcpy(p, gvt->firmware.mmio, info->mmio_size);
crc32_start = offsetof(struct gvt_firmware_header, crc32) + 4;
h->crc32 = crc32_le(0, firmware + crc32_start, size - crc32_start);
--
2.25.1
Re: [Intel-gfx] [PATCH] drm/i915: Lock dpt_obj around set_cache_level, v2.
On Thu, 2022-01-27 at 13:02 +0100, Maarten Lankhorst wrote:
> Op 26-01-2022 om 13:55 schreef Gwan-gyeong Mun:
> >
> >
> > On 1/26/22 9:37 AM, Maarten Lankhorst wrote:
> > > set_cache_level may unbind the object, which will result in the
> > > below
> > > lockdep splat:
> > > <6> [184.578145] [IGT] kms_addfb_basic: starting subtest addfb25-
> > > framebuffer-vs-set-tiling
> > > <4> [184.578220] [ cut here ]
> > > <4> [184.578221] WARN_ON(debug_locks && !(lock_is_held(&(&((obj)-
> > > >base.resv)->lock.base)->dep_map) != 0))
> > > <4> [184.578237] WARNING: CPU: 6 PID: 5544 at
> > > drivers/gpu/drm/i915/i915_gem.c:123
> > > i915_gem_object_unbind+0x4a9/0x510 [i915]
> > > <4> [184.578323] Modules linked in: vgem drm_shmem_helper
> > > snd_hda_codec_hdmi i915 mei_hdcp x86_pkg_temp_thermal
> > > snd_hda_intel coretemp crct10dif_pclmul snd_intel_dspcfg
> > > crc32_pclmul ttm snd_hda_codec ghash_clmulni_intel snd_hwdep
> > > drm_kms_helper snd_hda_core e1000e mei_me syscopyarea ptp snd_pcm
> > > sysfillrect mei pps_core sysimgblt fb_sys_fops prime_numbers
> > > intel_lpss_pci smsc75xx usbnet mii
> > > <4> [184.578349] CPU: 6 PID: 5544 Comm: kms_addfb_basic Not
> > > tainted 5.16.0-CI-Patchwork_22006+ #1
> > > <4> [184.578351] Hardware name: Intel Corporation Alder Lake
> > > Client Platform/AlderLake-P DDR4 RVP, BIOS
> > > ADLPFWI1.R00.2422.A00.2110131104 10/13/2021
> > > <4> [184.578352] RIP: 0010:i915_gem_object_unbind+0x4a9/0x510
> > > [i915]
> > > <4> [184.578424] Code: 00 be ff ff ff ff 48 8d 78 68 e8 a2 6e 2b
> > > e1 85 c0 0f 85 b1 fb ff ff 48 c7 c6 48 37 9e a0 48 c7 c7 d9 fc a1
> > > a0 e8 a3 54 26 e1 <0f> 0b e9 97 fb ff ff 31 ed 48 8b 5c 24 58 65
> > > 48 33 1c 25 28 00 00
> > > <4> [184.578426] RSP: 0018:c900013b3b68 EFLAGS: 00010286
> > > <4> [184.578428] RAX: RBX: c900013b3bb0 RCX:
> > > 0001
> > > <4> [184.578429] RDX: 8001 RSI: 8230b42d RDI:
> > >
> > > <4> [184.578430] RBP: 888120e1 R08: R09:
> > > c0007fff
> > > <4> [184.578431] R10: 0001 R11: c900013b3980 R12:
> > > 8881176ea740
> > > <4> [184.578432] R13: 888120e1 R14: R15:
> > > 0001
> > > <4> [184.578433] FS: 7f65074f5e40()
> > > GS:8f30() knlGS:
> > > <4> [184.578435] CS: 0010 DS: ES: CR0:
> > > 80050033
> > > <4> [184.578436] CR2: 7fff4420ede8 CR3: 00010c2f2005 CR4:
> > > 00770ee0
> > > <4> [184.578437] PKRU: 5554
> > > <4> [184.578438] Call Trace:
> > > <4> [184.578439]
> > > <4> [184.578440] ? dma_resv_iter_first_unlocked+0x78/0xf0
> > > <4> [184.578447] intel_dpt_create+0x88/0x220 [i915]
> > > <4> [184.578530] intel_framebuffer_init+0x5b8/0x620 [i915]
> > > <4> [184.578612] intel_framebuffer_create+0x3d/0x60 [i915]
> > > <4> [184.578691] intel_user_framebuffer_create+0x18f/0x2c0
> > > [i915]
> > > <4> [184.578775] drm_internal_framebuffer_create+0x36d/0x4c0
> > > <4> [184.578779] drm_mode_addfb2+0x2f/0xd0
> > > <4> [184.578781] ? drm_mode_addfb_ioctl+0x10/0x10
> > > <4> [184.578784] drm_ioctl_kernel+0xac/0x140
> > > <4> [184.578787] drm_ioctl+0x201/0x3d0
> > > <4> [184.578789] ? drm_mode_addfb_ioctl+0x10/0x10
> > > <4> [184.578796] __x64_sys_ioctl+0x6a/0xa0
> > > <4> [184.578800] do_syscall_64+0x37/0xb0
> > > <4> [184.578803] entry_SYSCALL_64_after_hwframe+0x44/0xae
> > > <4> [184.578805] RIP: 0033:0x7f6506736317
> > > <4> [184.578807] Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26
> > > 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8
> > > 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 41 4b 2d
> > > 00 f7 d8 64 89 01 48
> > > <4> [184.578808] RSP: 002b:7fff44211a98 EFLAGS: 0246
> > > ORIG_RAX: 0010
> > > <4> [184.578810] RAX: ffda RBX: 0006 RCX:
> > > 7f6506736317
> > > <4> [184.578811] RDX: 7fff44211b30 RSI: c06864b8 RDI:
> > > 0006
> > > <4> [184.578812] RBP: 7fff44211b30 R08: 7fff44311170 R09:
> > >
> > > <4> [184.578813] R10: 0008 R11: 0246 R12:
> > > c06864b8
> > > <4> [184.578813] R13: 0006 R14: R15:
> > >
> > > <4> [184.578819]
> > > <4> [184.578820] irq event stamp: 47931
> > > <4> [184.578821] hardirqs last enabled at (47937):
> > > [] __up_console_sem+0x62/0x70
> > > <4> [184.578824] hardirqs last disabled at (47942):
> > > [] __up_console_sem+0x47/0x70
> > > <4> [184.578826] softirqs last enabled at (47340):
> > > [] __do_softirq+0x32d/0x493
> > > <4> [184.578828] softirqs last disabled at (47335):
> > > [] irq_exit_rcu+0xa6/0xe0
> > > <4> [184.578830] ---[ end trace f17ec219f892c7d4 ]---
> > >
> > > Changes since v1:
> > > - Fix intel_pin_fb_obj_dpt too.
> > >
> > > Fixes: 0f341974cbc2 ("drm/i915: Add i915_vma_unbind_unlocked, and
> > > tak
Re: [Intel-gfx] [PATCH] drm/i915: Lock dpt_obj around set_cache_level, v2.
On 1/27/22 13:05, Thomas Hellström wrote: The bug on vm_close is a separate bug, and would probably best be fixed in a separate patch. Could I get a r-b on this? It should fix some issues, even if the unbind there is a separate bug. ~Maarten Recognizing that it doesn't fix the vm_close issue, Reviewed-by: Thomas Hellström Oh, BTW should probably carefully review those seemingly unrelated stall warnings from BAT to check whether the newly introduced object lock might stall a workqueue causing those. /Thomas
Re: [Intel-gfx] [PATCH] drm/i915: Lock dpt_obj around set_cache_level, v2.
Op 27-01-2022 om 13:09 schreef Thomas Hellström: > > On 1/27/22 13:05, Thomas Hellström wrote: >> >>> The bug on vm_close is a separate bug, and would probably best be >>> fixed in a separate patch. >>> >>> Could I get a r-b on this? It should fix some issues, even if the >>> unbind there is a separate bug. >>> >>> ~Maarten >>> >> Recognizing that it doesn't fix the vm_close issue, >> >> Reviewed-by: Thomas Hellström > > Oh, BTW should probably carefully review those seemingly unrelated stall > warnings from BAT to check whether the newly introduced object lock might > stall a workqueue causing those. > > /Thomas Which ones? I mostly see ext4 failures, where it doesn't seem to have any i915 lock held at all.
Re: [Intel-gfx] [PATCH] drm/i915: Lock dpt_obj around set_cache_level, v2.
On 1/27/22 13:38, Maarten Lankhorst wrote: Op 27-01-2022 om 13:09 schreef Thomas Hellström: On 1/27/22 13:05, Thomas Hellström wrote: The bug on vm_close is a separate bug, and would probably best be fixed in a separate patch. Could I get a r-b on this? It should fix some issues, even if the unbind there is a separate bug. ~Maarten Recognizing that it doesn't fix the vm_close issue, Reviewed-by: Thomas Hellström Oh, BTW should probably carefully review those seemingly unrelated stall warnings from BAT to check whether the newly introduced object lock might stall a workqueue causing those. /Thomas Which ones? I mostly see ext4 failures, where it doesn't seem to have any i915 lock held at all. Oh, I was looking at v1 version of the patch, but just noticed a hang. Didn't look to carefully at what was the cause. /Thomas
Re: [Intel-gfx] [Linaro-mm-sig] Re: [PATCH 02/19] dma-buf-map: Add helper to initialize second map
Am 27.01.22 um 12:16 schrieb Daniel Vetter:
On Thu, Jan 27, 2022 at 11:21:20AM +0100, Christian König wrote:
Am 27.01.22 um 11:00 schrieb Daniel Vetter:
On Thu, Jan 27, 2022 at 01:33:32AM -0800, Lucas De Marchi wrote:
On Thu, Jan 27, 2022 at 09:57:25AM +0100, Daniel Vetter wrote:
On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
When dma_buf_map struct is passed around, it's useful to be able to
initialize a second map that takes care of reading/writing to an offset
of the original map.
Add a helper that copies the struct and add the offset to the proper
address.
Well what you propose here can lead to all kind of problems and is
rather bad design as far as I can see.
The struct dma_buf_map is only to be filled in by the exporter and
should not be modified in this way by the importer.
humn... not sure if I was clear. There is no importer and exporter here.
Yeah, and exactly that's what I'm pointing out as problem here.
You are using the inter driver framework for something internal to the
driver. That is an absolutely clear NAK!
We could discuss that, but you guys are just sending around patches to do
this without any consensus that this is a good idea.
Uh I suggested this, also we're already using dma_buf_map all over the
place as a convenient abstraction. So imo that's all fine, it should allow
drivers to simplify some code where on igpu it's in normal kernel memory
and on dgpu it's behind some pci bar.
Maybe we should have a better name for that struct (and maybe also a
better place), but way back when we discussed that bikeshed I didn't come
up with anything better really.
I suggest iosys_map since it abstracts access to IO and system memory.
There is a role delegation on filling out and reading a buffer when
that buffer represents a struct layout.
struct bla {
int a;
int b;
int c;
struct foo foo;
struct bar bar;
int d;
}
This implementation allows you to have:
fill_foo(struct dma_buf_map *bla_map) { ... }
fill_bar(struct dma_buf_map *bla_map) { ... }
and the first thing these do is to make sure the map it's pointing to
is relative to the struct it's supposed to write/read. Otherwise you're
suggesting everything to be relative to struct bla, or to do the same
I'm doing it, but IMO more prone to error:
struct dma_buf_map map = *bla_map;
dma_buf_map_incr(map, offsetof(...));
Wrt the issue at hand I think the above is perfectly fine code. The idea
with dma_buf_map is really that it's just a special pointer, so writing
the code exactly as pointer code feels best. Unfortunately you cannot make
them typesafe (because of C), so the code sometimes looks a bit ugly.
Otherwise we could do stuff like container_of and all that with
typechecking in the macros.
I had exactly this code above, but after writting quite a few patches
using it, particularly with functions that have to write to 2 maps (see
patch 6 for example), it felt much better to have something to
initialize correctly from the start
struct dma_buf_map other_map = *bla_map;
/* poor Lucas forgetting dma_buf_map_incr(map, offsetof(...)); */
is error prone and hard to debug since you will be reading/writting
from/to another location rather than exploding
While with the construct below
other_map;
...
other_map = INITIALIZER()
I can rely on the compiler complaining about uninitialized var. And
in most of the cases I can just have this single line in the beggining of the
function when the offset is constant:
struct dma_buf_map other_map = INITIALIZER(bla_map, offsetof(..));
Hm yeah that's a good point that this allows us to rely on the compiler to
check for uninitialized variables.
Maybe include the above (with editing, but keeping the examples) in the
kerneldoc to explain why/how to use this? With that the concept at least
has my
Acked-by: Daniel Vetter
I'll leave it up to you & Christian to find a prettier color choice for
the naming bikeshed.
There is one major issue remaining with this and that is dma_buf_vunmap():
void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
Here we expect the original pointer as returned by dma_buf_map(), otherwise
we vunmap() the wrong area!
For all TTM based driver this doesn't matter since we keep the vmap base
separately in the BO anyway (IIRC), but we had at least one case where this
made boom last year.
Yeah but isn't that the same if it's just a void *?
If you pass the wrong pointer to an unmap function and not exactly what
you go from the map function, then things go boom. This is like
complaining that the following code wont work
u32 *stuff
stuff = kmap_local(some_page);
*stuff++ = 0;
*stuff = 1;
kunmap_locak(stuff);
It's just ... don't do
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix a race between vma / object destruction and unbinding
== Series Details ==
Series: drm/i915: Fix a race between vma / object destruction and unbinding
URL : https://patchwork.freedesktop.org/series/99418/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11150 -> Patchwork_22125
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22125/index.html
Participating hosts (45 -> 41)
--
Additional (1): fi-kbl-soraka
Missing(5): fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510
fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22125 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +8 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22125/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u: [PASS][2] -> [INCOMPLETE][3] ([i915#4547])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11150/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22125/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22125/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22125/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][6] ([i915#1886] / [i915#2291])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22125/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][7] -> [INCOMPLETE][8] ([i915#4785])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11150/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22125/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22125/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u: [PASS][10] -> [DMESG-WARN][11] ([i915#295]) +12
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11150/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22125/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22125/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][13] ([fdo#109271] / [i915#1436] /
[i915#4312])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22125/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-rpls-1}: [INCOMPLETE][14] ([i915#4898]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11150/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22125/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#295]: http
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: delete shadow "ret" variable
== Series Details == Series: drm/i915: delete shadow "ret" variable URL : https://patchwork.freedesktop.org/series/99408/ State : success == Summary == CI Bug Log - changes from CI_DRM_11149_full -> Patchwork_22121_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_22121_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_caching@reads: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/shard-glk3/igt@gem_cach...@reads.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-glk6/igt@gem_cach...@reads.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2410]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/shard-tglb1/igt@gem_ctx_persiste...@many-contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_exec_balancer@parallel: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/shard-iclb4/igt@gem_exec_balan...@parallel.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-iclb8/igt@gem_exec_balan...@parallel.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/shard-iclb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@rcs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/shard-kbl7/igt@gem_exec_fair@basic-n...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-kbl6/igt@gem_exec_fair@basic-n...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fence@basic-wait@bcs0: - shard-kbl: NOTRUN -> [SKIP][12] ([fdo#109271]) +29 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-kbl1/igt@gem_exec_fence@basic-w...@bcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#2190]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-apl1/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-apl7/igt@gem_lmem_swapp...@parallel-random.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][15] ([i915#2658]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-apl8/igt@gem_pr...@exhaustion.html * igt@gem_pxp@verify-pxp-execution-after-suspend-resume: - shard-tglb: NOTRUN -> [SKIP][16] ([i915#4270]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-tglb5/igt@gem_...@verify-pxp-execution-after-suspend-resume.html * igt@gem_userptr_blits@access-control: - shard-iclb: NOTRUN -> [SKIP][17] ([i915#3297]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-iclb6/igt@gem_userptr_bl...@access-control.html * igt@gem_userptr_blits@input-checking: - shard-skl: NOTRUN -> [DMESG-WARN][18] ([i915#4990]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-skl5/igt@gem_userptr_bl...@input-checking.html * igt@gem_userptr_blits@unsync-unmap-after-close: - shard-tglb: NOTRUN -> [SKIP][19] ([i915#3297]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-tglb5/igt@gem_userptr_bl...@unsync-unmap-after-close.html * igt@gem_userptr_blits@vma-merge: - shard-kbl: NOTRUN -> [FAIL][20] ([i915#3318]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-kbl1/igt@gem_userptr_bl...@vma-merge.html - shard-skl: NOTRUN -> [FAIL][21] ([i915#3318]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-skl10/igt@gem_userptr_bl...@vma-merge.html * igt@gen9_exec_parse@allowed-single: - shard-tglb: NOTRUN -> [SKIP][22] ([i915#2527] / [i915#2856]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22121/shard-tglb5
Re: [Intel-gfx] [PATCH 01/19] dma-buf-map: Add read/write helpers
Hi
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
In certain situations it's useful to be able to read or write to an
offset that is calculated by having the memory layout given by a struct
declaration. Usually we are going to read/write a u8, u16, u32 or u64.
Add a pair of macros dma_buf_map_read_field()/dma_buf_map_write_field()
to calculate the offset of a struct member and memcpy the data from/to
the dma_buf_map. We could use readb, readw, readl, readq and the write*
counterparts, however due to alignment issues this may not work on all
architectures. If alignment needs to be checked to call the right
function, it's not possible to decide at compile-time which function to
call: so just leave the decision to the memcpy function that will do
exactly that on IO memory or dereference the pointer.
Cc: Sumit Semwal
Cc: Christian König
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Lucas De Marchi
---
include/linux/dma-buf-map.h | 81 +
1 file changed, 81 insertions(+)
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
index 19fa0b5ae5ec..65e927d9ce33 100644
--- a/include/linux/dma-buf-map.h
+++ b/include/linux/dma-buf-map.h
@@ -6,6 +6,7 @@
#ifndef __DMA_BUF_MAP_H__
#define __DMA_BUF_MAP_H__
+#include
#include
#include
@@ -229,6 +230,46 @@ static inline void dma_buf_map_clear(struct dma_buf_map *map)
}
}
+/**
+ * dma_buf_map_memcpy_to_offset - Memcpy into offset of dma-buf mapping
+ * @dst: The dma-buf mapping structure
+ * @offset:The offset from which to copy
+ * @src: The source buffer
+ * @len: The number of byte in src
+ *
+ * Copies data into a dma-buf mapping with an offset. The source buffer is in
+ * system memory. Depending on the buffer's location, the helper picks the
+ * correct method of accessing the memory.
+ */
+static inline void dma_buf_map_memcpy_to_offset(struct dma_buf_map *dst,
size_t offset,
+ const void *src, size_t len)
+{
+ if (dst->is_iomem)
+ memcpy_toio(dst->vaddr_iomem + offset, src, len);
+ else
+ memcpy(dst->vaddr + offset, src, len);
+}
Please don't add a new function. Rather please add the offset parameter
to dma_buf_map_memcpy_to() and update the callers. There are only two
calls to dma_buf_map_memcpy_to() within the kernel. To make it clear
what the offset applies to, I'd call the parameter 'dst_offset'.
+
+/**
+ * dma_buf_map_memcpy_from_offset - Memcpy from offset of dma-buf mapping into
system memory
+ * @dst: Destination in system memory
+ * @src: The dma-buf mapping structure
+ * @src: The offset from which to copy
+ * @len: The number of byte in src
+ *
+ * Copies data from a dma-buf mapping with an offset. The dest buffer is in
+ * system memory. Depending on the mapping location, the helper picks the
+ * correct method of accessing the memory.
+ */
+static inline void dma_buf_map_memcpy_from_offset(void *dst, const struct
dma_buf_map *src,
+ size_t offset, size_t len)
+{
+ if (src->is_iomem)
+ memcpy_fromio(dst, src->vaddr_iomem + offset, len);
+ else
+ memcpy(dst, src->vaddr + offset, len);
+}
+
With the dma_buf_map_memcpy_to() changes, please just call this function
dma_buf_map_memcpy_from().
/**
* dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
* @dst: The dma-buf mapping structure
@@ -263,4 +304,44 @@ static inline void dma_buf_map_incr(struct dma_buf_map
*map, size_t incr)
map->vaddr += incr;
}
+/**
+ * dma_buf_map_read_field - Read struct member from dma-buf mapping with
+ * arbitrary size and handling un-aligned accesses
+ *
+ * @map__: The dma-buf mapping structure
+ * @type__:The struct to be used containing the field to read
+ * @field__: Member from struct we want to read
+ *
+ * Read a value from dma-buf mapping calculating the offset and size: this
assumes
+ * the dma-buf mapping is aligned with a a struct type__. A single u8, u16, u32
+ * or u64 can be read, based on the offset and size of type__.field__.
+ */
+#define dma_buf_map_read_field(map__, type__, field__) ({
\
+ type__ *t__;
\
+ typeof(t__->field__) val__;
\
+ dma_buf_map_memcpy_from_offset(&val__, map__, offsetof(type__,
field__),\
+ sizeof(t__->field__));
\
+ val__;
\
+})
+
+/**
+ * dma_buf_map_write_field - Write struct member to the dma-buf mapping with
+ * arbitrary size and handling un-ali
Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
When dma_buf_map struct is passed around, it's useful to be able to
initialize a second map that takes care of reading/writing to an offset
of the original map.
Add a helper that copies the struct and add the offset to the proper
address.
Cc: Sumit Semwal
Cc: Christian König
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Lucas De Marchi
---
include/linux/dma-buf-map.h | 29 +
1 file changed, 29 insertions(+)
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
index 65e927d9ce33..3514a859f628 100644
--- a/include/linux/dma-buf-map.h
+++ b/include/linux/dma-buf-map.h
@@ -131,6 +131,35 @@ struct dma_buf_map {
.is_iomem = false, \
}
+/**
+ * DMA_BUF_MAP_INIT_OFFSET - Initializes struct dma_buf_map from another
dma_buf_map
+ * @map_: The dma-buf mapping structure to copy from
+ * @offset:Offset to add to the other mapping
+ *
+ * Initializes a new dma_buf_struct based on another. This is the equivalent
of doing:
+ *
+ * .. code-block: c
+ *
+ * dma_buf_map map = other_map;
+ * dma_buf_map_incr(&map, &offset);
+ *
+ * Example usage:
+ *
+ * .. code-block: c
+ *
+ * void foo(struct device *dev, struct dma_buf_map *base_map)
+ * {
+ * ...
+ * struct dma_buf_map = DMA_BUF_MAP_INIT_OFFSET(base_map,
FIELD_OFFSET);
+ * ...
+ * }
+ */
+#define DMA_BUF_MAP_INIT_OFFSET(map_, offset_) (struct dma_buf_map)\
+ { \
+ .vaddr = (map_)->vaddr + (offset_), \
+ .is_iomem = (map_)->is_iomem,\
+ }
+
It's illegal to access .vaddr with raw pointer. Always use a
dma_buf_memcpy_() interface. So why would you need this macro when you
have dma_buf_memcpy_*() with an offset parameter?
I've also been very careful to distinguish between .vaddr and
.vaddr_iomem, even in places where I wouldn't have to. This macro breaks
the assumption.
Best regards
Thomas
/**
* dma_buf_map_set_vaddr - Sets a dma-buf mapping structure to an address in
system memory
* @map: The dma-buf mapping structure
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: M/N cleanup (rev2)
== Series Details == Series: drm/i915: M/N cleanup (rev2) URL : https://patchwork.freedesktop.org/series/99409/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [RFC PATCH] drm/i915: Remove all frontbuffer tracking calls from the gem code
On Thu, Jan 27, 2022 at 09:20:14AM +0100, Maarten Lankhorst wrote:
> Op 26-01-2022 om 14:09 schreef Jouni Högander:
> > We should now rely on userspace doing dirtyfb. There is no
> > need to have separate frontbuffer tracking hooks in gem code.
> >
> > This patch is removing all frontbuffer tracking calls from the gem
> > code.
> >
> > Cc: Ville Syrjälä
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Signed-off-by: Jouni Högander
> > ---
> > drivers/gpu/drm/i915/display/intel_overlay.c | 2 --
> > drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 2 --
> > drivers/gpu/drm/i915/gem/i915_gem_domain.c | 5
> > drivers/gpu/drm/i915/gem/i915_gem_object.c | 24
> > drivers/gpu/drm/i915/gem/i915_gem_object.h | 16 -
> > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 7 --
> > drivers/gpu/drm/i915/i915_gem.c | 5
> > 7 files changed, 61 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
> > b/drivers/gpu/drm/i915/display/intel_overlay.c
> > index 5358f03b52db..fc2691dac278 100644
> > --- a/drivers/gpu/drm/i915/display/intel_overlay.c
> > +++ b/drivers/gpu/drm/i915/display/intel_overlay.c
> > @@ -809,8 +809,6 @@ static int intel_overlay_do_put_image(struct
> > intel_overlay *overlay,
> > goto out_pin_section;
> > }
> >
> > - i915_gem_object_flush_frontbuffer(new_bo, ORIGIN_DIRTYFB);
> > -
> > if (!overlay->active) {
> > const struct intel_crtc_state *crtc_state =
> > overlay->crtc->config;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> > index 8a248003dfae..115e6d877e38 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> > @@ -20,8 +20,6 @@ static void __do_clflush(struct drm_i915_gem_object *obj)
> > {
> > GEM_BUG_ON(!i915_gem_object_has_pages(obj));
> > drm_clflush_sg(obj->mm.pages);
> > -
> > - i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
> > }
> >
> > static void clflush_work(struct dma_fence_work *base)
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > index 26532c07d467..ab1fc2d930e1 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > @@ -63,7 +63,6 @@ flush_write_domain(struct drm_i915_gem_object *obj,
> > unsigned int flush_domains)
> > }
> > spin_unlock(&obj->vma.lock);
> >
> > - i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
> > break;
> >
> > case I915_GEM_DOMAIN_WC:
> > @@ -615,9 +614,6 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
> > *data,
> > out_unlock:
> > i915_gem_object_unlock(obj);
> >
> > - if (!err && write_domain)
> > - i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
> > -
> > out:
> > i915_gem_object_put(obj);
> > return err;
> > @@ -728,7 +724,6 @@ int i915_gem_object_prepare_write(struct
> > drm_i915_gem_object *obj,
> > }
> >
> > out:
> > - i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
> > obj->mm.dirty = true;
> > /* return with the pages pinned */
> > return 0;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index 1a9e1f940a7d..f7ba66deb923 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -394,30 +394,6 @@ static void i915_gem_free_object(struct drm_gem_object
> > *gem_obj)
> > queue_delayed_work(i915->wq, &i915->mm.free_work, 0);
> > }
> >
> > -void __i915_gem_object_flush_frontbuffer(struct drm_i915_gem_object *obj,
> > -enum fb_op_origin origin)
> > -{
> > - struct intel_frontbuffer *front;
> > -
> > - front = __intel_frontbuffer_get(obj);
> > - if (front) {
> > - intel_frontbuffer_flush(front, origin);
> > - intel_frontbuffer_put(front);
> > - }
> > -}
> > -
> > -void __i915_gem_object_invalidate_frontbuffer(struct drm_i915_gem_object
> > *obj,
> > - enum fb_op_origin origin)
> > -{
> > - struct intel_frontbuffer *front;
> > -
> > - front = __intel_frontbuffer_get(obj);
> > - if (front) {
> > - intel_frontbuffer_invalidate(front, origin);
> > - intel_frontbuffer_put(front);
> > - }
> > -}
> > -
> > static void
> > i915_gem_object_read_from_page_kmap(struct drm_i915_gem_object *obj, u64
> > offset, void *dst, int size)
> > {
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > index 02c37fe4a535..d7a08172b239 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > @@ -578,22 +578,6 @@ void __i915_gem_object
Re: [Intel-gfx] [PATCH 1/3] i915/gvt: Introduce the mmio_table.c to support VFIO new mdev API
What tree is this series against? It doesn't seem to apply to Linus' current tree or 5.17-rc1.
Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map
Hi
Am 27.01.22 um 11:21 schrieb Christian König:
Am 27.01.22 um 11:00 schrieb Daniel Vetter:
On Thu, Jan 27, 2022 at 01:33:32AM -0800, Lucas De Marchi wrote:
On Thu, Jan 27, 2022 at 09:57:25AM +0100, Daniel Vetter wrote:
On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
When dma_buf_map struct is passed around, it's useful to be able to
initialize a second map that takes care of reading/writing to an
offset
of the original map.
Add a helper that copies the struct and add the offset to the
proper
address.
Well what you propose here can lead to all kind of problems and is
rather bad design as far as I can see.
The struct dma_buf_map is only to be filled in by the exporter and
should not be modified in this way by the importer.
humn... not sure if I was clear. There is no importer and
exporter here.
Yeah, and exactly that's what I'm pointing out as problem here.
You are using the inter driver framework for something internal to the
driver. That is an absolutely clear NAK!
We could discuss that, but you guys are just sending around patches
to do
this without any consensus that this is a good idea.
Uh I suggested this, also we're already using dma_buf_map all over the
place as a convenient abstraction. So imo that's all fine, it should
allow
drivers to simplify some code where on igpu it's in normal kernel
memory
and on dgpu it's behind some pci bar.
Maybe we should have a better name for that struct (and maybe also a
better place), but way back when we discussed that bikeshed I didn't
come
up with anything better really.
I suggest iosys_map since it abstracts access to IO and system memory.
There is a role delegation on filling out and reading a buffer when
that buffer represents a struct layout.
struct bla {
int a;
int b;
int c;
struct foo foo;
struct bar bar;
int d;
}
This implementation allows you to have:
fill_foo(struct dma_buf_map *bla_map) { ... }
fill_bar(struct dma_buf_map *bla_map) { ... }
and the first thing these do is to make sure the map it's pointing to
is relative to the struct it's supposed to write/read. Otherwise
you're
suggesting everything to be relative to struct bla, or to do the same
I'm doing it, but IMO more prone to error:
struct dma_buf_map map = *bla_map;
dma_buf_map_incr(map, offsetof(...));
Wrt the issue at hand I think the above is perfectly fine code. The
idea
with dma_buf_map is really that it's just a special pointer, so writing
the code exactly as pointer code feels best. Unfortunately you
cannot make
them typesafe (because of C), so the code sometimes looks a bit ugly.
Otherwise we could do stuff like container_of and all that with
typechecking in the macros.
I had exactly this code above, but after writting quite a few patches
using it, particularly with functions that have to write to 2 maps (see
patch 6 for example), it felt much better to have something to
initialize correctly from the start
struct dma_buf_map other_map = *bla_map;
/* poor Lucas forgetting dma_buf_map_incr(map, offsetof(...)); */
is error prone and hard to debug since you will be reading/writting
from/to another location rather than exploding
While with the construct below
other_map;
...
other_map = INITIALIZER()
I can rely on the compiler complaining about uninitialized var. And
in most of the cases I can just have this single line in the
beggining of the
function when the offset is constant:
struct dma_buf_map other_map = INITIALIZER(bla_map, offsetof(..));
Hm yeah that's a good point that this allows us to rely on the
compiler to
check for uninitialized variables.
Maybe include the above (with editing, but keeping the examples) in the
kerneldoc to explain why/how to use this? With that the concept at least
has my
Acked-by: Daniel Vetter
I'll leave it up to you & Christian to find a prettier color choice for
the naming bikeshed.
There is one major issue remaining with this and that is dma_buf_vunmap():
void dma_buf_vunmap(struct dma_buf *dmabuf, struct dma_buf_map *map);
Here we expect the original pointer as returned by dma_buf_map(),
otherwise we vunmap() the wrong area!
Indeed. It's always been a problem with that API, even when it still
took raw pointers.
The IMHO correct solution would distinguish between a buffer (struct
dma_buf_map) and a pointer into that buffer (struct dma_buf_ptr).
I don't feel like typing that.
Best regards
Thomas
For all TTM based driver this doesn't matter since we keep the vmap base
separately in the BO anyway (IIRC), but we had at least one case where
this made boom last year.
Christian.
-Daniel
Lucas De Marchi
-Daniel
IMO this construct is worse because at a point in time in the
function
the map was pointing to the wrong thing the functio
Re: [Intel-gfx] [PATCH 09/19] dma-buf-map: Add wrapper over memset
Hi
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
Just like memcpy_toio(), there is also need to write a direct value to a
memory block. Add dma_buf_map_memset() to abstract memset() vs memset_io()
Cc: Matt Roper
Cc: Sumit Semwal
Cc: Christian König
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Lucas De Marchi
---
include/linux/dma-buf-map.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
index 3514a859f628..c9fb04264cd0 100644
--- a/include/linux/dma-buf-map.h
+++ b/include/linux/dma-buf-map.h
@@ -317,6 +317,23 @@ static inline void dma_buf_map_memcpy_to(struct
dma_buf_map *dst, const void *sr
memcpy(dst->vaddr, src, len);
}
+/**
+ * dma_buf_map_memset - Memset into dma-buf mapping
+ * @dst: The dma-buf mapping structure
+ * @value: The value to set
+ * @len: The number of bytes to set in dst
+ *
+ * Set value in dma-buf mapping. Depending on the buffer's location, the helper
+ * picks the correct method of accessing the memory.
+ */
+static inline void dma_buf_map_memset(struct dma_buf_map *dst, int value,
size_t len)
+{
+ if (dst->is_iomem)
+ memset_io(dst->vaddr_iomem, value, len);
+ else
+ memset(dst->vaddr, value, len);
+}
Maybe add an offset parameter here.
Best regards
Thomas
+
/**
* dma_buf_map_incr - Increments the address stored in a dma-buf mapping
* @map: The dma-buf mapping structure
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: M/N cleanup (rev2)
== Series Details ==
Series: drm/i915: M/N cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/99409/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11151 -> Patchwork_22126
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22126/index.html
Participating hosts (46 -> 41)
--
Additional (1): fi-icl-u2
Missing(6): bat-adls-5 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-pnv-d510
fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22126 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22126/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@debugfs_test@read_all_entries:
- fi-kbl-soraka: [PASS][2] -> [DMESG-WARN][3] ([i915#1982] /
[i915#262])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11151/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22126/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
* igt@gem_huc_copy@huc-copy:
- fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#2190])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22126/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22126/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][6] ([fdo#111827]) +8 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22126/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: NOTRUN -> [SKIP][7] ([fdo#109278]) +2 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22126/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][8] ([fdo#109285])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22126/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][9] ([i915#3301])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22126/fi-icl-u2/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [DMESG-FAIL][10] ([i915#4957]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11151/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22126/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6: [DMESG-FAIL][12] ([i915#4494] / [i915#4957]) ->
[PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11151/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22126/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
Build changes
-
* Linux: CI_DRM_11151 -> Patchwork_22126
CI-20190529: 20190529
CI_DRM_11151: 627e2885b51ab503a98aa89f0a0bd68416c731fc @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6336: ae2eb9e18bc58a4c45f28cfd80962938198dec3c @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22126: 3e76fda4145c87cdb50479a1dcce612dd06af4b9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3e76fda4145c drm/i915: Always check dp_m2_n2 on pre-bdw
d89ddd51579a drm/i915: Set DP M2/N2 equal to M1/N1 when not doing DRRS
1903fafd4880 drm/i915: Extract can_enable_drrs()
79a7f565dc7f drm/i915: Dump dp_m2_n2 always
bd6c4321ad8a drm/i915: Program FDI RX TUSIZE2
f0bc3753acef drm/i915: Add fdi_m2_n2
8d6349a876d0 drm/i915: Extract {i9xx, ilk}_configure_cpu_transcoder()
952ca77dbfcb
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] i915/gvt: Introduce the mmio_table.c to support VFIO new mdev API
== Series Details ==
Series: series starting with [1/3] i915/gvt: Introduce the mmio_table.c to
support VFIO new mdev API
URL : https://patchwork.freedesktop.org/series/99420/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1d24765d58ce i915/gvt: Introduce the mmio_table.c to support VFIO new mdev API
-:214: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#214: FILE: drivers/gpu/drm/i915/gvt/handlers.c:76:
+static int setup_mmio_handler(struct intel_gvt *gvt,
+ u32 offset, u32 size, u32 device,
-:245: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#245: FILE: drivers/gpu/drm/i915/gvt/handlers.c:95:
+ WARN(1, "assign a handler to a non-tracked mmio %x\n",
+ i);
-:269: WARNING:MACRO_WITH_FLOW_CONTROL: Macros with flow control statements
should be avoided
#269: FILE: drivers/gpu/drm/i915/gvt/handlers.c:2091:
+#define MMIO_F(reg, s, d, r, w) do { \
+ ret = setup_mmio_handler(gvt, i915_mmio_reg_offset(reg), \
+ s, d, r, w); \
if (ret) \
return ret; \
} while (0)
-:301: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'prefix' - possible
side-effects?
#301: FILE: drivers/gpu/drm/i915/gvt/handlers.c:2101:
+#define MMIO_RING_F(prefix, s, d, r, w) do { \
+ MMIO_F(prefix(RENDER_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(BLT_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(GEN6_BSD_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(VEBOX_RING_BASE), s, d, r, w); \
if (HAS_ENGINE(gvt->gt, VCS1)) \
+ MMIO_F(prefix(GEN8_BSD2_RING_BASE), s, d, r, w); \
} while (0)
-:301: CHECK:MACRO_ARG_REUSE: Macro argument reuse 's' - possible side-effects?
#301: FILE: drivers/gpu/drm/i915/gvt/handlers.c:2101:
+#define MMIO_RING_F(prefix, s, d, r, w) do { \
+ MMIO_F(prefix(RENDER_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(BLT_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(GEN6_BSD_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(VEBOX_RING_BASE), s, d, r, w); \
if (HAS_ENGINE(gvt->gt, VCS1)) \
+ MMIO_F(prefix(GEN8_BSD2_RING_BASE), s, d, r, w); \
} while (0)
-:301: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'd' - possible side-effects?
#301: FILE: drivers/gpu/drm/i915/gvt/handlers.c:2101:
+#define MMIO_RING_F(prefix, s, d, r, w) do { \
+ MMIO_F(prefix(RENDER_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(BLT_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(GEN6_BSD_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(VEBOX_RING_BASE), s, d, r, w); \
if (HAS_ENGINE(gvt->gt, VCS1)) \
+ MMIO_F(prefix(GEN8_BSD2_RING_BASE), s, d, r, w); \
} while (0)
-:301: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'r' - possible side-effects?
#301: FILE: drivers/gpu/drm/i915/gvt/handlers.c:2101:
+#define MMIO_RING_F(prefix, s, d, r, w) do { \
+ MMIO_F(prefix(RENDER_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(BLT_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(GEN6_BSD_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(VEBOX_RING_BASE), s, d, r, w); \
if (HAS_ENGINE(gvt->gt, VCS1)) \
+ MMIO_F(prefix(GEN8_BSD2_RING_BASE), s, d, r, w); \
} while (0)
-:301: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'w' - possible side-effects?
#301: FILE: drivers/gpu/drm/i915/gvt/handlers.c:2101:
+#define MMIO_RING_F(prefix, s, d, r, w) do { \
+ MMIO_F(prefix(RENDER_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(BLT_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(GEN6_BSD_RING_BASE), s, d, r, w); \
+ MMIO_F(prefix(VEBOX_RING_BASE), s, d, r, w); \
if (HAS_ENGINE(gvt->gt, VCS1)) \
+ MMIO_F(prefix(GEN8_BSD2_RING_BASE), s, d, r, w); \
} while (0)
-:2034: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#2034: FILE: drivers/gpu/drm/i915/gvt/handlers.c:2407:
+ WARN(1, "dup mmio definition offset %x\n",
+ info->offset);
-:2064: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#2064: FILE: drivers/gpu/drm/i915/gvt/handlers.c:2437:
+ ret = krealloc(block,
+(gvt->mmio.num_mmio_block + 1) * sizeof(*block),
-:2069: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#2069: FILE: drivers/gpu/drm/i915/gvt/handlers.c:2442:
+ gvt->mmio.mmio_block = block = ret;
-:2213: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#2213:
new file mode 100644
-:2218: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#2218: FILE: drivers/gpu/drm/i915/gvt/mmio_table.c:1:
+/*
-:2291: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'd' - possible side-effects?
#2291: FILE: drivers/gpu/drm/i915/gvt/mmio_table.c:74:
+#define MMIO_F(reg, s, f, am, rm, d) do { \
+ if (intel_gvt_get_device_type(iter->i915) & (d)) { \
+ ret = iter->
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] i915/gvt: Introduce the mmio_table.c to support VFIO new mdev API
== Series Details == Series: series starting with [1/3] i915/gvt: Introduce the mmio_table.c to support VFIO new mdev API URL : https://patchwork.freedesktop.org/series/99420/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/adl-n: Add PCH Support for Alder Lake N
== Series Details == Series: drm/i915/adl-n: Add PCH Support for Alder Lake N URL : https://patchwork.freedesktop.org/series/99413/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11149_full -> Patchwork_22123_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22123_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22123_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22123_full: ### IGT changes ### Possible regressions * igt@kms_flip@busy-flip@a-edp1: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/shard-skl6/igt@kms_flip@busy-f...@a-edp1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-skl10/igt@kms_flip@busy-f...@a-edp1.html Known issues Here are the changes found in Patchwork_22123_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/shard-iclb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][5] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-kbl7/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][8] -> [FAIL][9] ([i915#2849]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_fence@basic-wait@bcs0: - shard-kbl: NOTRUN -> [SKIP][10] ([fdo#109271]) +29 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-kbl4/igt@gem_exec_fence@basic-w...@bcs0.html * igt@gem_exec_whisper@basic-fds-forked: - shard-glk: [PASS][11] -> [DMESG-WARN][12] ([i915#118]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11149/shard-glk8/igt@gem_exec_whis...@basic-fds-forked.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-glk7/igt@gem_exec_whis...@basic-fds-forked.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#2190]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-apl7/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@heavy-random: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-apl3/igt@gem_lmem_swapp...@heavy-random.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][15] ([i915#2658]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-apl3/igt@gem_pr...@exhaustion.html * igt@gem_pxp@verify-pxp-execution-after-suspend-resume: - shard-tglb: NOTRUN -> [SKIP][16] ([i915#4270]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-tglb5/igt@gem_...@verify-pxp-execution-after-suspend-resume.html * igt@gem_userptr_blits@access-control: - shard-iclb: NOTRUN -> [SKIP][17] ([i915#3297]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-iclb7/igt@gem_userptr_bl...@access-control.html * igt@gem_userptr_blits@input-checking: - shard-skl: NOTRUN -> [DMESG-WARN][18] ([i915#4990]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-skl4/igt@gem_userptr_bl...@input-checking.html * igt@gem_userptr_blits@unsync-unmap-after-close: - shard-tglb: NOTRUN -> [SKIP][19] ([i915#3297]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22123/shard-tglb5/igt@gem_userptr_bl...@unsync-unmap-after-close.html * igt@gem_userptr_blits@vma-merge: - shard-apl: NOTRUN
Re: [Intel-gfx] [RFC PATCH] drm/i915: Remove all frontbuffer tracking calls from the gem code
On Thu, Jan 27, 2022 at 09:20:14AM +0100, Maarten Lankhorst wrote:
> Op 26-01-2022 om 14:09 schreef Jouni Högander:
> > We should now rely on userspace doing dirtyfb. There is no
> > need to have separate frontbuffer tracking hooks in gem code.
> >
> > This patch is removing all frontbuffer tracking calls from the gem
> > code.
> >
> > Cc: Ville Syrjälä
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Signed-off-by: Jouni Högander
> > ---
> > drivers/gpu/drm/i915/display/intel_overlay.c | 2 --
> > drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 2 --
> > drivers/gpu/drm/i915/gem/i915_gem_domain.c | 5
> > drivers/gpu/drm/i915/gem/i915_gem_object.c | 24
> > drivers/gpu/drm/i915/gem/i915_gem_object.h | 16 -
> > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 7 --
> > drivers/gpu/drm/i915/i915_gem.c | 5
> > 7 files changed, 61 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
> > b/drivers/gpu/drm/i915/display/intel_overlay.c
> > index 5358f03b52db..fc2691dac278 100644
> > --- a/drivers/gpu/drm/i915/display/intel_overlay.c
> > +++ b/drivers/gpu/drm/i915/display/intel_overlay.c
> > @@ -809,8 +809,6 @@ static int intel_overlay_do_put_image(struct
> > intel_overlay *overlay,
> > goto out_pin_section;
> > }
> >
> > - i915_gem_object_flush_frontbuffer(new_bo, ORIGIN_DIRTYFB);
> > -
> > if (!overlay->active) {
> > const struct intel_crtc_state *crtc_state =
> > overlay->crtc->config;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> > index 8a248003dfae..115e6d877e38 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
> > @@ -20,8 +20,6 @@ static void __do_clflush(struct drm_i915_gem_object *obj)
> > {
> > GEM_BUG_ON(!i915_gem_object_has_pages(obj));
> > drm_clflush_sg(obj->mm.pages);
> > -
> > - i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
> > }
> >
> > static void clflush_work(struct dma_fence_work *base)
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > index 26532c07d467..ab1fc2d930e1 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> > @@ -63,7 +63,6 @@ flush_write_domain(struct drm_i915_gem_object *obj,
> > unsigned int flush_domains)
> > }
> > spin_unlock(&obj->vma.lock);
> >
> > - i915_gem_object_flush_frontbuffer(obj, ORIGIN_CPU);
> > break;
> >
> > case I915_GEM_DOMAIN_WC:
> > @@ -615,9 +614,6 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void
> > *data,
> > out_unlock:
> > i915_gem_object_unlock(obj);
> >
> > - if (!err && write_domain)
> > - i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
> > -
> > out:
> > i915_gem_object_put(obj);
> > return err;
> > @@ -728,7 +724,6 @@ int i915_gem_object_prepare_write(struct
> > drm_i915_gem_object *obj,
> > }
> >
> > out:
> > - i915_gem_object_invalidate_frontbuffer(obj, ORIGIN_CPU);
> > obj->mm.dirty = true;
> > /* return with the pages pinned */
> > return 0;
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index 1a9e1f940a7d..f7ba66deb923 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -394,30 +394,6 @@ static void i915_gem_free_object(struct drm_gem_object
> > *gem_obj)
> > queue_delayed_work(i915->wq, &i915->mm.free_work, 0);
> > }
> >
> > -void __i915_gem_object_flush_frontbuffer(struct drm_i915_gem_object *obj,
> > -enum fb_op_origin origin)
> > -{
> > - struct intel_frontbuffer *front;
> > -
> > - front = __intel_frontbuffer_get(obj);
> > - if (front) {
> > - intel_frontbuffer_flush(front, origin);
> > - intel_frontbuffer_put(front);
> > - }
> > -}
> > -
> > -void __i915_gem_object_invalidate_frontbuffer(struct drm_i915_gem_object
> > *obj,
> > - enum fb_op_origin origin)
> > -{
> > - struct intel_frontbuffer *front;
> > -
> > - front = __intel_frontbuffer_get(obj);
> > - if (front) {
> > - intel_frontbuffer_invalidate(front, origin);
> > - intel_frontbuffer_put(front);
> > - }
> > -}
> > -
> > static void
> > i915_gem_object_read_from_page_kmap(struct drm_i915_gem_object *obj, u64
> > offset, void *dst, int size)
> > {
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > index 02c37fe4a535..d7a08172b239 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
> > @@ -578,22 +578,6 @@ void __i915_gem_object
Re: [Intel-gfx] [PATCH 09/19] dma-buf-map: Add wrapper over memset
On Thu, Jan 27, 2022 at 03:54:21PM +0100, Thomas Zimmermann wrote:
Hi
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
Just like memcpy_toio(), there is also need to write a direct value to a
memory block. Add dma_buf_map_memset() to abstract memset() vs memset_io()
Cc: Matt Roper
Cc: Sumit Semwal
Cc: Christian König
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Lucas De Marchi
---
include/linux/dma-buf-map.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
index 3514a859f628..c9fb04264cd0 100644
--- a/include/linux/dma-buf-map.h
+++ b/include/linux/dma-buf-map.h
@@ -317,6 +317,23 @@ static inline void dma_buf_map_memcpy_to(struct
dma_buf_map *dst, const void *sr
memcpy(dst->vaddr, src, len);
}
+/**
+ * dma_buf_map_memset - Memset into dma-buf mapping
+ * @dst: The dma-buf mapping structure
+ * @value: The value to set
+ * @len: The number of bytes to set in dst
+ *
+ * Set value in dma-buf mapping. Depending on the buffer's location, the helper
+ * picks the correct method of accessing the memory.
+ */
+static inline void dma_buf_map_memset(struct dma_buf_map *dst, int value,
size_t len)
+{
+ if (dst->is_iomem)
+ memset_io(dst->vaddr_iomem, value, len);
+ else
+ memset(dst->vaddr, value, len);
+}
Maybe add an offset parameter here.
yep, on v2 I will have 2 APIs, one with and one without offset.
thanks
Lucas De Marchi
Best regards
Thomas
+
/**
* dma_buf_map_incr - Increments the address stored in a dma-buf mapping
* @map: The dma-buf mapping structure
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
Re: [Intel-gfx] [PATCH 09/19] dma-buf-map: Add wrapper over memset
Am 27.01.22 um 16:38 schrieb Lucas De Marchi:
On Thu, Jan 27, 2022 at 03:54:21PM +0100, Thomas Zimmermann wrote:
Hi
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
Just like memcpy_toio(), there is also need to write a direct value to a
memory block. Add dma_buf_map_memset() to abstract memset() vs
memset_io()
Cc: Matt Roper
Cc: Sumit Semwal
Cc: Christian König
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Lucas De Marchi
---
include/linux/dma-buf-map.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
index 3514a859f628..c9fb04264cd0 100644
--- a/include/linux/dma-buf-map.h
+++ b/include/linux/dma-buf-map.h
@@ -317,6 +317,23 @@ static inline void dma_buf_map_memcpy_to(struct
dma_buf_map *dst, const void *sr
memcpy(dst->vaddr, src, len);
}
+/**
+ * dma_buf_map_memset - Memset into dma-buf mapping
+ * @dst: The dma-buf mapping structure
+ * @value: The value to set
+ * @len: The number of bytes to set in dst
+ *
+ * Set value in dma-buf mapping. Depending on the buffer's location,
the helper
+ * picks the correct method of accessing the memory.
+ */
+static inline void dma_buf_map_memset(struct dma_buf_map *dst, int
value, size_t len)
+{
+ if (dst->is_iomem)
+ memset_io(dst->vaddr_iomem, value, len);
+ else
+ memset(dst->vaddr, value, len);
+}
Maybe add an offset parameter here.
yep, on v2 I will have 2 APIs, one with and one without offset.
Please, no. Just add the parameter here and pass 0 if yo don't need it.
Best regards
Thomas
thanks
Lucas De Marchi
Best regards
Thomas
+
/**
* dma_buf_map_incr - Increments the address stored in a dma-buf
mapping
* @map: The dma-buf mapping structure
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] i915/gvt: Introduce the mmio_table.c to support VFIO new mdev API
== Series Details ==
Series: series starting with [1/3] i915/gvt: Introduce the mmio_table.c to
support VFIO new mdev API
URL : https://patchwork.freedesktop.org/series/99420/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11151 -> Patchwork_22127
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22127/index.html
Participating hosts (46 -> 42)
--
Additional (1): fi-icl-u2
Missing(5): bat-adls-5 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22127 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22127/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@gem_huc_copy@huc-copy:
- fi-icl-u2: NOTRUN -> [SKIP][2] ([i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22127/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22127/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][4] ([fdo#111827]) +8 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22127/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: NOTRUN -> [SKIP][5] ([fdo#109278]) +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22127/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][6] ([fdo#109285])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22127/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: [PASS][7] -> [INCOMPLETE][8] ([i915#4547] /
[i915#4838])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11151/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22127/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][9] ([i915#3301])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22127/fi-icl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-skl-6600u: NOTRUN -> [FAIL][10] ([i915#2722] / [i915#4312])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22127/fi-skl-6600u/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][11] ([i915#4494] / [i915#4957]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11151/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22127/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
Warnings
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [DMESG-FAIL][13] ([i915#4957]) -> [DMESG-FAIL][14]
([i915#4494] / [i915#4957])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11151/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22127/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4838]: https://gitlab.freedesktop.org/drm/intel/issues/4838
[i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
Build changes
-
* Linux: CI_DRM_11151 -> Patchwork_22127
CI-20190529: 20190529
CI_DRM_11151: 627e2885b51ab50
