[Intel-gfx] [PATCH 2/2] drm/i915: Protect request peeking with RCU
Since the execlists_active() is no longer protected by the
engine->active.lock, we need to protect the request pointer with RCU to
prevent it being freed as we evaluate whether or not we need to preempt.
Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off
spinlock")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index d2edb527dcb8..010d67f48ad9 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -202,21 +202,26 @@ static void kick_submission(struct intel_engine_cs
*engine,
if (prio <= engine->execlists.queue_priority_hint)
return;
+ rcu_read_lock();
+
/* Nothing currently active? We're overdue for a submission! */
inflight = execlists_active(&engine->execlists);
if (!inflight)
- return;
+ goto unlock;
/*
* If we are already the currently executing context, don't
* bother evaluating if we should preempt ourselves.
*/
if (inflight->hw_context == rq->hw_context)
- return;
+ goto unlock;
engine->execlists.queue_priority_hint = prio;
if (need_preempt(prio, rq_prio(inflight)))
tasklet_hi_schedule(&engine->execlists.tasklet);
+
+unlock:
+ rcu_read_unlock();
}
static void __i915_schedule(struct i915_sched_node *node,
--
2.24.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/gt: Drop false assertion on user_forcewake
The counter is removed from the pm wakeref count, but it remains intact so that we can restore it upon resume. Ergo inside suspend, it may have a value. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_pm.c index 6374744bb65e..060a27d9af34 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c @@ -251,7 +251,6 @@ static void wait_for_suspend(struct intel_gt *gt) intel_gt_set_wedged(gt); } - GEM_BUG_ON(atomic_read(>->user_wakeref)); intel_gt_pm_wait_for_idle(gt); } -- 2.24.0.rc2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH i-g-t v4 1/4] tests/gem_exec_reloc: Don't filter out invalid addresses
Hi Vanshi,
On Thursday, October 31, 2019 5:59:50 PM CET Vanshidhar Konda wrote:
> May be this patch can just be merged with the other patch in this series
> that changes gem_exec_reloc.
Even if both patches are closely related to possibly incorrect alignment in
use, I think each one resolves it own distinct issue, that's why I think they
should be kept separate.
Thanks,
Janusz
> Vanshi
>
> On Thu, Oct 31, 2019 at 04:28:54PM +0100, Janusz Krzysztofik wrote:
> >Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> >addresses for !ppgtt") introduced filtering of addresses possibly
> >occupied by other users of shared GTT. Unfortunately, that filtering
> >doesn't distinguish between actually occupied addresses and otherwise
> >invalid softpin offsets. As soon as incorrect GTT alignment is assumed
> >when running on future backends with possibly larger minimum page
> >sizes, a half of calculated offsets to be tested will be incorrectly
> >detected as occupied by other users and silently skipped instead of
> >reported as a problem. That will significantly distort the intended
> >test pattern.
> >
> >Filter out failing addresses only if not reported as invalid.
> >
> >v2: Skip unavailable addresses only when not running on full PPGTT.
> >v3: Replace the not on full PPGTT requirement for skipping with error
> >code checking.
> >
> >Signed-off-by: Janusz Krzysztofik
> >Cc: Chris Wilson
> >---
> > tests/i915/gem_exec_reloc.c | 12 +---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> >diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
> >index 5f59fe99..423fed8b 100644
> >--- a/tests/i915/gem_exec_reloc.c
> >+++ b/tests/i915/gem_exec_reloc.c
> >@@ -520,7 +520,7 @@ static void basic_range(int fd, unsigned flags)
> > uint64_t gtt_size = gem_aperture_size(fd);
> > const uint32_t bbe = MI_BATCH_BUFFER_END;
> > igt_spin_t *spin = NULL;
> >-int count, n;
> >+int count, n, err;
> >
> > igt_require(gem_has_softpin(fd));
> >
> >@@ -542,8 +542,11 @@ static void basic_range(int fd, unsigned flags)
> > gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
> > execbuf.buffers_ptr = to_user_pointer(&obj[n]);
> > execbuf.buffer_count = 1;
> >-if (__gem_execbuf(fd, &execbuf))
> >+err = __gem_execbuf(fd, &execbuf);
> >+if (err) {
> >+igt_assert(err != -EINVAL);
> > continue;
> >+}
> >
> > igt_debug("obj[%d] handle=%d, address=%llx\n",
> > n, obj[n].handle, (long long)obj[n].offset);
> >@@ -562,8 +565,11 @@ static void basic_range(int fd, unsigned flags)
> > gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
> > execbuf.buffers_ptr = to_user_pointer(&obj[n]);
> > execbuf.buffer_count = 1;
> >-if (__gem_execbuf(fd, &execbuf))
> >+err = __gem_execbuf(fd, &execbuf);
> >+if (err) {
> >+igt_assert(err != -EINVAL);
> > continue;
> >+}
> >
> > igt_debug("obj[%d] handle=%d, address=%llx\n",
> > n, obj[n].handle, (long long)obj[n].offset);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH i-g-t v4 1/4] tests/gem_exec_reloc: Don't filter out invalid addresses
Quoting Janusz Krzysztofik (2019-11-04 09:13:28)
> Hi Chris,
>
> On Friday, November 1, 2019 11:02:45 AM CET Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2019-10-31 15:28:54)
> > > Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> > > addresses for !ppgtt") introduced filtering of addresses possibly
> > > occupied by other users of shared GTT. Unfortunately, that filtering
> > > doesn't distinguish between actually occupied addresses and otherwise
> > > invalid softpin offsets. As soon as incorrect GTT alignment is assumed
> > > when running on future backends with possibly larger minimum page
> > > sizes, a half of calculated offsets to be tested will be incorrectly
> > > detected as occupied by other users and silently skipped instead of
> > > reported as a problem. That will significantly distort the intended
> > > test pattern.
> > >
> > > Filter out failing addresses only if not reported as invalid.
> > >
> > > v2: Skip unavailable addresses only when not running on full PPGTT.
> > > v3: Replace the not on full PPGTT requirement for skipping with error
> > > code checking.
> > >
> > > Signed-off-by: Janusz Krzysztofik
> > > Cc: Chris Wilson
> > > ---
> > > tests/i915/gem_exec_reloc.c | 12 +---
> > > 1 file changed, 9 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
> > > index 5f59fe99..423fed8b 100644
> > > --- a/tests/i915/gem_exec_reloc.c
> > > +++ b/tests/i915/gem_exec_reloc.c
> > > @@ -520,7 +520,7 @@ static void basic_range(int fd, unsigned flags)
> > > uint64_t gtt_size = gem_aperture_size(fd);
> > > const uint32_t bbe = MI_BATCH_BUFFER_END;
> > > igt_spin_t *spin = NULL;
> > > - int count, n;
> > > + int count, n, err;
> > >
> > > igt_require(gem_has_softpin(fd));
> > >
> > > @@ -542,8 +542,11 @@ static void basic_range(int fd, unsigned flags)
> > > gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
> > > execbuf.buffers_ptr = to_user_pointer(&obj[n]);
> > > execbuf.buffer_count = 1;
> > > - if (__gem_execbuf(fd, &execbuf))
> > > + err = __gem_execbuf(fd, &execbuf);
> > > + if (err) {
> >
> > > + igt_assert(err != -EINVAL);
> >
> > I've been thinking about this and I think the right approach is
> >
> > /* Iff using a shared GTT, some of it may be reserved */
> > igt_assert_eq(err, -ENOSPC);
>
> Thanks for your help, I'll follow your approach.
>
> Shouldn't we also use the trick with invalid reloc here to save request
> emission?
Could do. If you move the whole probe out of line so it's not easily
confused with the central point of the test, that'll be great.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/fbdev: Fallback to non tiled mode if all tiles not present
On Thu, Oct 31, 2019 at 02:48:39PM -0700, Manasi Navare wrote:
> In case of tiled displays, if we hotplug just one connector,
> fbcon currently just selects the preferred mode and if it is
> tiled mode then that becomes a problem if rest of the tiles are
> not present.
> So in the fbdev driver on hotplug when we probe the client modeset,
> we we dont find all the connectors for all tiles, then on a connector
> with one tile, just fallback to the first available non tiled mode
> to display over a single connector.
>
> Suggested-by: Ville Syrjälä
> Suggested-by: Dave Airlie
> Cc: Ville Syrjälä
> Cc: Dave Airlie
> Signed-off-by: Manasi Navare
Hm, should we mayb have a slight timeout first to wait for the 2nd
connector? Otherwise lots of flickering going on when plugging in one of
these screens ...
-Daniel
> ---
> drivers/gpu/drm/drm_client_modeset.c | 29
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> b/drivers/gpu/drm/drm_client_modeset.c
> index 895b73f23079..e28a723587db 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -114,6 +114,20 @@ drm_client_find_modeset(struct drm_client_dev *client,
> struct drm_crtc *crtc)
> return NULL;
> }
>
> +static struct drm_display_mode *
> +drm_connector_fallback_non_tiled_mode(struct drm_connector *connector)
> +{
> + struct drm_display_mode *mode;
> +
> + list_for_each_entry(mode, &connector->modes, head) {
> + if (mode->hdisplay == connector->tile_h_size &&
> + mode->vdisplay == connector->tile_v_size)
> + continue;
> + return mode;
> + }
> + return NULL;
> +}
> +
> static struct drm_display_mode *
> drm_connector_has_preferred_mode(struct drm_connector *connector, int width,
> int height)
> {
> @@ -348,8 +362,17 @@ static bool drm_client_target_preferred(struct
> drm_connector **connectors,
> struct drm_connector *connector;
> u64 conn_configured = 0;
> int tile_pass = 0;
> + int num_tiled_conns = 0;
> int i;
>
> + for (i = 0; i < connector_count; i++) {
> + connector = connectors[i];
> + if (!connector->has_tile)
> + continue;
> +
> + num_tiled_conns ++;
> + }
> +
> retry:
> for (i = 0; i < connector_count; i++) {
> connector = connectors[i];
> @@ -394,6 +417,12 @@ static bool drm_client_target_preferred(struct
> drm_connector **connectors,
> connector->base.id, connector->tile_group
> ? connector->tile_group->id : 0);
> modes[i] = drm_connector_has_preferred_mode(connector,
> width, height);
> }
> + if (connector->has_tile &&
> + num_tiled_conns < connector->num_h_tile *
> connector->num_v_tile) {
> + DRM_DEBUG_KMS("Falling back to non tiled mode on
> Connector %d\n",
> + connector->base.id);
> + modes[i] =
> drm_connector_fallback_non_tiled_mode(connector);
> + }
> /* No preferred modes, pick one off the list */
> if (!modes[i] && !list_empty(&connector->modes)) {
> list_for_each_entry(modes[i], &connector->modes, head)
> --
> 2.19.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH i-g-t v4 2/4] lib: Add minimum GTT alignment helper
Hi Chris,
On Friday, November 1, 2019 11:08:45 AM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-10-31 15:28:55)
> > Some tests assume 4kB offset alignment while using softpin. That
> > assumption may be wrong on future GEM backends with possibly larger
> > minimum page sizes. As a result, those tests may either fail on
> > softpin at offsets which are incorrectly aligned, may silently skip
> > such incorrectly aligned addresses assuming them occupied by other
> > users if incorrect detection method is used, or may always succeed
> > when examining invalid use patterns.
> >
> > Provide a helper function that detects minimum GTT alignment. Tests
> > may use it to calculate softpin offsets valid for actually used backing
> > store.
> >
> > v2: Rename the helper, use 'minimum GTT alignment' term across the
> > change (Chris),
> > - use error numbers to distinguish between invalid offsets and
> > addresses occupied by other users, then
> > - simplify the code (Chris).
> >
> > Signed-off-by: Janusz Krzysztofik
> > Cc: Chris Wilson
> > Cc: Daniele Ceraolo Spurio
> > Cc: Stuart Summers
> > ---
> > lib/ioctl_wrappers.c | 46
> > lib/ioctl_wrappers.h | 2 ++
> > 2 files changed, 48 insertions(+)
> >
> > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> > index 628f8b83..f0ef8b2e 100644
> > --- a/lib/ioctl_wrappers.c
> > +++ b/lib/ioctl_wrappers.c
> > @@ -54,6 +54,7 @@
> > #include "intel_io.h"
> > #include "igt_debugfs.h"
> > #include "igt_sysfs.h"
> > +#include "igt_x86.h"
> > #include "config.h"
> >
> > #ifdef HAVE_VALGRIND
> > @@ -1158,6 +1159,51 @@ bool gem_has_softpin(int fd)
> > return has_softpin;
> > }
> >
> > +/**
> > + * gem_gtt_min_alignment_order:
> > + * @fd: open i915 drm file descriptor
> > + *
> > + * This function detects the minimum possible alignment of a soft-pinned
gem
> > + * object allocated from a default backing store. It is useful for
calculating
> > + * correctly aligned softpin offsets.
> > + * Since size order to size conversion (size = 1 << order) is less
trivial
> > + * than the opposite, the function returns the alignment order as more
handy.
> > + *
> > + * Returns:
> > + * Size order of the minimum GTT alignment
> > + */
> > +int gem_gtt_min_alignment_order(int fd)
>
> But not part of ioctl_wrappers.c!
>
> lib/i915/gem_gtt_topology.c? _query.c? _probe.c?
I was thinking about that but couldn't find a good name. I'll use one of your
proposed, thanks.
> > +{
> > + struct drm_i915_gem_exec_object2 obj;
> > + struct drm_i915_gem_execbuffer2 eb;
> > + const uint32_t bbe = MI_BATCH_BUFFER_END;
> > + int order;
> > +
> > + /* no softpin => 4kB page size */
> > + if (!gem_has_softpin(fd))
> > + return 12;
> > +
> > + memset(&obj, 0, sizeof(obj));
> > + memset(&eb, 0, sizeof(eb));
> > +
> > + obj.handle = gem_create(fd, 4096);
> > + obj.flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> > + eb.buffers_ptr = to_user_pointer(&obj);
> > + eb.buffer_count = 1;
> > + gem_write(fd, obj.handle, 0, &bbe, sizeof(bbe));
> > +
> > + for (order = 12; order < 64; order++) {
> > + obj.offset = 1ull << order;
> > + if (__gem_execbuf(fd, &eb) != -EINVAL)
> > + break;
Should I also follow your advice of checking for -ENOSPC here rather than
!-EINVAL?
> > + }
> > + igt_assert(obj.offset < gem_aperture_size(fd));
>
> Hmm, there is one more trick we can apply here: an invalid reloc.
>
> memset(&reloc, 0, sizeof(reloc));
> obj.relocs_ptr = to_user_pointer(&reloc);
> obj.relocation_count = 1;
>
> We first process the buffers, then we process the relocations. So we
> will get the -EINVAL for illegal softpin before we get the -ENOENT for
> invalid reloc handle.
>
> That just saves actually emitting a request.
I like this idea.
Thanks,
Janusz
> -Chris
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH i-g-t v4 2/4] lib: Add minimum GTT alignment helper
Quoting Janusz Krzysztofik (2019-11-04 09:23:12)
> Hi Chris,
>
> On Friday, November 1, 2019 11:08:45 AM CET Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2019-10-31 15:28:55)
> > > Some tests assume 4kB offset alignment while using softpin. That
> > > assumption may be wrong on future GEM backends with possibly larger
> > > minimum page sizes. As a result, those tests may either fail on
> > > softpin at offsets which are incorrectly aligned, may silently skip
> > > such incorrectly aligned addresses assuming them occupied by other
> > > users if incorrect detection method is used, or may always succeed
> > > when examining invalid use patterns.
> > >
> > > Provide a helper function that detects minimum GTT alignment. Tests
> > > may use it to calculate softpin offsets valid for actually used backing
> > > store.
> > >
> > > v2: Rename the helper, use 'minimum GTT alignment' term across the
> > > change (Chris),
> > > - use error numbers to distinguish between invalid offsets and
> > > addresses occupied by other users, then
> > > - simplify the code (Chris).
> > >
> > > Signed-off-by: Janusz Krzysztofik
> > > Cc: Chris Wilson
> > > Cc: Daniele Ceraolo Spurio
> > > Cc: Stuart Summers
> > > ---
> > > lib/ioctl_wrappers.c | 46
> > > lib/ioctl_wrappers.h | 2 ++
> > > 2 files changed, 48 insertions(+)
> > >
> > > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> > > index 628f8b83..f0ef8b2e 100644
> > > --- a/lib/ioctl_wrappers.c
> > > +++ b/lib/ioctl_wrappers.c
> > > @@ -54,6 +54,7 @@
> > > #include "intel_io.h"
> > > #include "igt_debugfs.h"
> > > #include "igt_sysfs.h"
> > > +#include "igt_x86.h"
> > > #include "config.h"
> > >
> > > #ifdef HAVE_VALGRIND
> > > @@ -1158,6 +1159,51 @@ bool gem_has_softpin(int fd)
> > > return has_softpin;
> > > }
> > >
> > > +/**
> > > + * gem_gtt_min_alignment_order:
> > > + * @fd: open i915 drm file descriptor
> > > + *
> > > + * This function detects the minimum possible alignment of a soft-pinned
> gem
> > > + * object allocated from a default backing store. It is useful for
> calculating
> > > + * correctly aligned softpin offsets.
> > > + * Since size order to size conversion (size = 1 << order) is less
> trivial
> > > + * than the opposite, the function returns the alignment order as more
> handy.
> > > + *
> > > + * Returns:
> > > + * Size order of the minimum GTT alignment
> > > + */
> > > +int gem_gtt_min_alignment_order(int fd)
> >
> > But not part of ioctl_wrappers.c!
> >
> > lib/i915/gem_gtt_topology.c? _query.c? _probe.c?
>
> I was thinking about that but couldn't find a good name. I'll use one of
> your
> proposed, thanks.
>
> > > +{
> > > + struct drm_i915_gem_exec_object2 obj;
> > > + struct drm_i915_gem_execbuffer2 eb;
> > > + const uint32_t bbe = MI_BATCH_BUFFER_END;
> > > + int order;
> > > +
> > > + /* no softpin => 4kB page size */
> > > + if (!gem_has_softpin(fd))
> > > + return 12;
> > > +
> > > + memset(&obj, 0, sizeof(obj));
> > > + memset(&eb, 0, sizeof(eb));
> > > +
> > > + obj.handle = gem_create(fd, 4096);
> > > + obj.flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> > > + eb.buffers_ptr = to_user_pointer(&obj);
> > > + eb.buffer_count = 1;
> > > + gem_write(fd, obj.handle, 0, &bbe, sizeof(bbe));
> > > +
> > > + for (order = 12; order < 64; order++) {
> > > + obj.offset = 1ull << order;
> > > + if (__gem_execbuf(fd, &eb) != -EINVAL)
> > > + break;
>
> Should I also follow your advice of checking for -ENOSPC here rather than
> !-EINVAL?
This time we expect EINVAL for the invalid non-aligned offset provided by
the user. -ENOSPC comes later when we fail to evict -- but we will only
try that with a valid GTT node.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Drop false assertion on user_forcewake
Chris Wilson writes: > The counter is removed from the pm wakeref count, but it remains intact > so that we can restore it upon resume. Ergo inside suspend, it may have > a value. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala oh, user_forcewake needs a better name with a verb... > --- > drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c > b/drivers/gpu/drm/i915/gt/intel_gt_pm.c > index 6374744bb65e..060a27d9af34 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c > @@ -251,7 +251,6 @@ static void wait_for_suspend(struct intel_gt *gt) > intel_gt_set_wedged(gt); > } > > - GEM_BUG_ON(atomic_read(>->user_wakeref)); > intel_gt_pm_wait_for_idle(gt); > } > > -- > 2.24.0.rc2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH i-g-t v4 4/4] tests/gem_ctx_shared: Align objects using minimum GTT alignment
Hi Chris, On Friday, November 1, 2019 10:42:18 AM CET Chris Wilson wrote: > Quoting Janusz Krzysztofik (2019-10-31 15:28:57) > > exec-shared-gtt-* subtests use hardcoded values for object size and > > softpin offset, based on 4kB GTT alignment assumption. That may result > > in those subtests failing when run on future backing stores with > > possibly larger minimum page sizes. > > > > Replace hardcoded constants with values calculated from minimum GTT > > alignment of actual backing store the test is running on. > > > > v2: Update helper name, use 'minimum GTT alignment' term across the > > change, adjust variable name. > > > > Signed-off-by: Janusz Krzysztofik > > Cc: Chris Wilson > > --- > > tests/i915/gem_ctx_shared.c | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c > > index 6d8cbcce..1e9c7f78 100644 > > --- a/tests/i915/gem_ctx_shared.c > > +++ b/tests/i915/gem_ctx_shared.c > > @@ -195,6 +195,7 @@ static void exec_shared_gtt(int i915, unsigned int ring) > > uint32_t scratch, *s; > > uint32_t batch, cs[16]; > > uint64_t offset; > > + uint64_t alignment; > > int i; > > > > gem_require_ring(i915, ring); > > @@ -203,7 +204,8 @@ static void exec_shared_gtt(int i915, unsigned int ring) > > clone = gem_context_clone(i915, 0, I915_CONTEXT_CLONE_VM, 0); > > > > /* Find a hole big enough for both objects later */ > > - scratch = gem_create(i915, 16384); > > + alignment = 2 * gem_gtt_min_alignment(i915); alignment = one page for an object + one page for stride > > + scratch = gem_create(i915, 2 * alignment); space reserved = 2 * (one page for an object + one page for stride) > > gem_write(i915, scratch, 0, &bbe, sizeof(bbe)); > > obj.handle = scratch; > > gem_execbuf(i915, &execbuf); > > @@ -246,7 +248,7 @@ static void exec_shared_gtt(int i915, unsigned int ring) > > gem_write(i915, batch, 0, cs, sizeof(cs)); > > > > obj.handle = batch; > > - obj.offset += 8192; /* make sure we don't cause an eviction! */ > > + obj.offset += alignment; /* make sure we don't cause an eviction! */ offset += (one page for an object + one page for stride) > It's 'stride' here. It's leaving a guard page in between, just in case > page coloring demands it. Assuming I correctly understood the intentions here but my implementation is not readable clearly enough, how do you think this should be fixed? How about a comment '/* one page for an object + one page for stride */' above the line where the 'alignment' variable is assigned the value of 2 * minimum GTT alignment? Thanks, Janusz > -Chris > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH i-g-t v4 4/4] tests/gem_ctx_shared: Align objects using minimum GTT alignment
Quoting Janusz Krzysztofik (2019-11-04 09:39:32) > Hi Chris, > > On Friday, November 1, 2019 10:42:18 AM CET Chris Wilson wrote: > > Quoting Janusz Krzysztofik (2019-10-31 15:28:57) > > > exec-shared-gtt-* subtests use hardcoded values for object size and > > > softpin offset, based on 4kB GTT alignment assumption. That may result > > > in those subtests failing when run on future backing stores with > > > possibly larger minimum page sizes. > > > > > > Replace hardcoded constants with values calculated from minimum GTT > > > alignment of actual backing store the test is running on. > > > > > > v2: Update helper name, use 'minimum GTT alignment' term across the > > > change, adjust variable name. > > > > > > Signed-off-by: Janusz Krzysztofik > > > Cc: Chris Wilson > > > --- > > > tests/i915/gem_ctx_shared.c | 6 -- > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c > > > index 6d8cbcce..1e9c7f78 100644 > > > --- a/tests/i915/gem_ctx_shared.c > > > +++ b/tests/i915/gem_ctx_shared.c > > > @@ -195,6 +195,7 @@ static void exec_shared_gtt(int i915, unsigned int > ring) > > > uint32_t scratch, *s; > > > uint32_t batch, cs[16]; > > > uint64_t offset; > > > + uint64_t alignment; > > > int i; > > > > > > gem_require_ring(i915, ring); > > > @@ -203,7 +204,8 @@ static void exec_shared_gtt(int i915, unsigned int > ring) > > > clone = gem_context_clone(i915, 0, I915_CONTEXT_CLONE_VM, 0); > > > > > > /* Find a hole big enough for both objects later */ > > > - scratch = gem_create(i915, 16384); > > > + alignment = 2 * gem_gtt_min_alignment(i915); > > alignment = one page for an object + one page for stride > > > > + scratch = gem_create(i915, 2 * alignment); > > space reserved = 2 * (one page for an object + one page for stride) > > > > gem_write(i915, scratch, 0, &bbe, sizeof(bbe)); > > > obj.handle = scratch; > > > gem_execbuf(i915, &execbuf); > > > @@ -246,7 +248,7 @@ static void exec_shared_gtt(int i915, unsigned int > ring) > > > gem_write(i915, batch, 0, cs, sizeof(cs)); > > > > > > obj.handle = batch; > > > - obj.offset += 8192; /* make sure we don't cause an eviction! */ > > > + obj.offset += alignment; /* make sure we don't cause an eviction! > */ > > offset += (one page for an object + one page for stride) > > > It's 'stride' here. It's leaving a guard page in between, just in case > > page coloring demands it. > > Assuming I correctly understood the intentions here but my implementation > is not readable clearly enough, how do you think this should be fixed? How > about a comment '/* one page for an object + one page for stride */' above > the > line where the 'alignment' variable is assigned the value of 2 * minimum GTT > alignment? I think "stride = 2 * min_alignment()" concisely describes the intent. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Protect request peeking with RCU
Chris Wilson writes:
> Since the execlists_active() is no longer protected by the
> engine->active.lock, we need to protect the request pointer with RCU to
> prevent it being freed as we evaluate whether or not we need to preempt.
>
> Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the
> irq-off spinlock")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_scheduler.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index d2edb527dcb8..010d67f48ad9 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -202,21 +202,26 @@ static void kick_submission(struct intel_engine_cs
> *engine,
> if (prio <= engine->execlists.queue_priority_hint)
> return;
>
> + rcu_read_lock();
> +
> /* Nothing currently active? We're overdue for a submission! */
> inflight = execlists_active(&engine->execlists);
> if (!inflight)
> - return;
> + goto unlock;
>
> /*
>* If we are already the currently executing context, don't
>* bother evaluating if we should preempt ourselves.
>*/
> if (inflight->hw_context == rq->hw_context)
> - return;
> + goto unlock;
>
> engine->execlists.queue_priority_hint = prio;
> if (need_preempt(prio, rq_prio(inflight)))
> tasklet_hi_schedule(&engine->execlists.tasklet);
> +
> +unlock:
> + rcu_read_unlock();
> }
>
> static void __i915_schedule(struct i915_sched_node *node,
> --
> 2.24.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH i-g-t v4 2/4] lib: Add minimum GTT alignment helper
On Monday, November 4, 2019 10:28:37 AM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-11-04 09:23:12)
> > Hi Chris,
> >
> > On Friday, November 1, 2019 11:08:45 AM CET Chris Wilson wrote:
> > > Quoting Janusz Krzysztofik (2019-10-31 15:28:55)
> > > > Some tests assume 4kB offset alignment while using softpin. That
> > > > assumption may be wrong on future GEM backends with possibly larger
> > > > minimum page sizes. As a result, those tests may either fail on
> > > > softpin at offsets which are incorrectly aligned, may silently skip
> > > > such incorrectly aligned addresses assuming them occupied by other
> > > > users if incorrect detection method is used, or may always succeed
> > > > when examining invalid use patterns.
> > > >
> > > > Provide a helper function that detects minimum GTT alignment. Tests
> > > > may use it to calculate softpin offsets valid for actually used backing
> > > > store.
> > > >
> > > > v2: Rename the helper, use 'minimum GTT alignment' term across the
> > > > change (Chris),
> > > > - use error numbers to distinguish between invalid offsets and
> > > > addresses occupied by other users, then
> > > > - simplify the code (Chris).
> > > >
> > > > Signed-off-by: Janusz Krzysztofik
> > > > Cc: Chris Wilson
> > > > Cc: Daniele Ceraolo Spurio
> > > > Cc: Stuart Summers
> > > > ---
> > > > lib/ioctl_wrappers.c | 46
> > > > lib/ioctl_wrappers.h | 2 ++
> > > > 2 files changed, 48 insertions(+)
> > > >
> > > > diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> > > > index 628f8b83..f0ef8b2e 100644
> > > > --- a/lib/ioctl_wrappers.c
> > > > +++ b/lib/ioctl_wrappers.c
> > > > @@ -54,6 +54,7 @@
> > > > #include "intel_io.h"
> > > > #include "igt_debugfs.h"
> > > > #include "igt_sysfs.h"
> > > > +#include "igt_x86.h"
> > > > #include "config.h"
> > > >
> > > > #ifdef HAVE_VALGRIND
> > > > @@ -1158,6 +1159,51 @@ bool gem_has_softpin(int fd)
> > > > return has_softpin;
> > > > }
> > > >
> > > > +/**
> > > > + * gem_gtt_min_alignment_order:
> > > > + * @fd: open i915 drm file descriptor
> > > > + *
> > > > + * This function detects the minimum possible alignment of a
> > > > soft-pinned
> > gem
> > > > + * object allocated from a default backing store. It is useful for
> > calculating
> > > > + * correctly aligned softpin offsets.
> > > > + * Since size order to size conversion (size = 1 << order) is less
> > trivial
> > > > + * than the opposite, the function returns the alignment order as more
> > handy.
> > > > + *
> > > > + * Returns:
> > > > + * Size order of the minimum GTT alignment
> > > > + */
> > > > +int gem_gtt_min_alignment_order(int fd)
> > >
> > > But not part of ioctl_wrappers.c!
> > >
> > > lib/i915/gem_gtt_topology.c? _query.c? _probe.c?
> >
> > I was thinking about that but couldn't find a good name. I'll use one of
> > your
> > proposed, thanks.
> >
> > > > +{
> > > > + struct drm_i915_gem_exec_object2 obj;
> > > > + struct drm_i915_gem_execbuffer2 eb;
> > > > + const uint32_t bbe = MI_BATCH_BUFFER_END;
> > > > + int order;
> > > > +
> > > > + /* no softpin => 4kB page size */
> > > > + if (!gem_has_softpin(fd))
> > > > + return 12;
> > > > +
> > > > + memset(&obj, 0, sizeof(obj));
> > > > + memset(&eb, 0, sizeof(eb));
> > > > +
> > > > + obj.handle = gem_create(fd, 4096);
> > > > + obj.flags = EXEC_OBJECT_PINNED |
> > > > EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> > > > + eb.buffers_ptr = to_user_pointer(&obj);
> > > > + eb.buffer_count = 1;
> > > > + gem_write(fd, obj.handle, 0, &bbe, sizeof(bbe));
> > > > +
> > > > + for (order = 12; order < 64; order++) {
> > > > + obj.offset = 1ull << order;
> > > > + if (__gem_execbuf(fd, &eb) != -EINVAL)
> > > > + break;
> >
> > Should I also follow your advice of checking for -ENOSPC here rather than
> > !-EINVAL?
>
> This time we expect EINVAL for the invalid non-aligned offset provided by
> the user. -ENOSPC comes later when we fail to evict -- but we will only
> try that with a valid GTT node.
OK, I thought that was more about proper handling of possible error codes
other than -EINVAL or -ENOSPC.
Thanks,
Janusz
> -Chris
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH i-g-t v4 1/4] tests/gem_exec_reloc: Don't filter out invalid addresses
Hi Chris,
On Friday, November 1, 2019 11:02:45 AM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-10-31 15:28:54)
> > Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
> > addresses for !ppgtt") introduced filtering of addresses possibly
> > occupied by other users of shared GTT. Unfortunately, that filtering
> > doesn't distinguish between actually occupied addresses and otherwise
> > invalid softpin offsets. As soon as incorrect GTT alignment is assumed
> > when running on future backends with possibly larger minimum page
> > sizes, a half of calculated offsets to be tested will be incorrectly
> > detected as occupied by other users and silently skipped instead of
> > reported as a problem. That will significantly distort the intended
> > test pattern.
> >
> > Filter out failing addresses only if not reported as invalid.
> >
> > v2: Skip unavailable addresses only when not running on full PPGTT.
> > v3: Replace the not on full PPGTT requirement for skipping with error
> > code checking.
> >
> > Signed-off-by: Janusz Krzysztofik
> > Cc: Chris Wilson
> > ---
> > tests/i915/gem_exec_reloc.c | 12 +---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
> > index 5f59fe99..423fed8b 100644
> > --- a/tests/i915/gem_exec_reloc.c
> > +++ b/tests/i915/gem_exec_reloc.c
> > @@ -520,7 +520,7 @@ static void basic_range(int fd, unsigned flags)
> > uint64_t gtt_size = gem_aperture_size(fd);
> > const uint32_t bbe = MI_BATCH_BUFFER_END;
> > igt_spin_t *spin = NULL;
> > - int count, n;
> > + int count, n, err;
> >
> > igt_require(gem_has_softpin(fd));
> >
> > @@ -542,8 +542,11 @@ static void basic_range(int fd, unsigned flags)
> > gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
> > execbuf.buffers_ptr = to_user_pointer(&obj[n]);
> > execbuf.buffer_count = 1;
> > - if (__gem_execbuf(fd, &execbuf))
> > + err = __gem_execbuf(fd, &execbuf);
> > + if (err) {
>
> > + igt_assert(err != -EINVAL);
>
> I've been thinking about this and I think the right approach is
>
> /* Iff using a shared GTT, some of it may be reserved */
> igt_assert_eq(err, -ENOSPC);
Thanks for your help, I'll follow your approach.
Shouldn't we also use the trick with invalid reloc here to save request
emission?
Thanks,
Janusz
>
> > continue;
> > + }
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Display WA2006604312 is needed from ICL onwards
WA2006604312 is listed for devices from Icelake onward.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e29e80ae5698..71ac4fe5fb47 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5981,7 +5981,7 @@ static bool needs_scalerclk_wa(struct drm_i915_private
*dev_priv,
const struct intel_crtc_state *crtc_state)
{
/* Wa_2006604312:icl */
- if (crtc_state->scaler_state.scaler_users > 0 && IS_ICELAKE(dev_priv))
+ if (crtc_state->scaler_state.scaler_users > 0 && INTEL_GEN(dev_priv) >=
11)
return true;
return false;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH V7 1/6] mdev: class id support
Mdev bus only supports vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
the first driver could be virtio-mdev. This means we need to add
device class id support in bus match method to pair the mdev device
and mdev driver correctly.
So this patch adds id_table to mdev_driver and class_id for mdev
device with the match method for mdev bus.
Reviewed-by: Parav Pandit
Signed-off-by: Jason Wang
---
.../driver-api/vfio-mediated-device.rst | 5
drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
drivers/s390/cio/vfio_ccw_ops.c | 1 +
drivers/s390/crypto/vfio_ap_ops.c | 1 +
drivers/vfio/mdev/mdev_core.c | 16
drivers/vfio/mdev/mdev_driver.c | 25 +++
drivers/vfio/mdev/mdev_private.h | 1 +
drivers/vfio/mdev/vfio_mdev.c | 6 +
include/linux/mdev.h | 8 ++
include/linux/mod_devicetable.h | 8 ++
samples/vfio-mdev/mbochs.c| 1 +
samples/vfio-mdev/mdpy.c | 1 +
samples/vfio-mdev/mtty.c | 1 +
13 files changed, 75 insertions(+)
diff --git a/Documentation/driver-api/vfio-mediated-device.rst
b/Documentation/driver-api/vfio-mediated-device.rst
index 25eb7d5b834b..6709413bee29 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -102,12 +102,14 @@ structure to represent a mediated device's driver::
* @probe: called when new device created
* @remove: called when device removed
* @driver: device driver structure
+ * @id_table: the ids serviced by this driver
*/
struct mdev_driver {
const char *name;
int (*probe) (struct device *dev);
void (*remove) (struct device *dev);
struct device_driverdriver;
+const struct mdev_class_id *id_table;
};
A mediated bus driver for mdev should use this structure in the function calls
@@ -170,6 +172,9 @@ that a driver should use to unregister itself with the mdev
core driver::
extern void mdev_unregister_device(struct device *dev);
+It is also required to specify the class_id in create() callback through::
+
+ int mdev_set_class(struct mdev_device *mdev, u16 id);
Mediated Device Management Interface Through sysfs
==
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 343d79c1cb7e..6420f0dbd31b 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -678,6 +678,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
dev_name(mdev_dev(mdev)));
ret = 0;
+ mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
out:
return ret;
}
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index f0d71ab77c50..cf2c013ae32f 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -129,6 +129,7 @@ static int vfio_ccw_mdev_create(struct kobject *kobj,
struct mdev_device *mdev)
private->sch->schid.ssid,
private->sch->schid.sch_no);
+ mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
return 0;
}
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 5c0f53c6dde7..07c31070afeb 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -343,6 +343,7 @@ static int vfio_ap_mdev_create(struct kobject *kobj, struct
mdev_device *mdev)
list_add(&matrix_mdev->node, &matrix_dev->mdev_list);
mutex_unlock(&matrix_dev->lock);
+ mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
return 0;
}
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index b558d4cfd082..d23ca39e3be6 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -45,6 +45,16 @@ void mdev_set_drvdata(struct mdev_device *mdev, void *data)
}
EXPORT_SYMBOL(mdev_set_drvdata);
+/* Specify the class for the mdev device, this must be called during
+ * create() callback.
+ */
+void mdev_set_class(struct mdev_device *mdev, u16 id)
+{
+ WARN_ON(mdev->class_id);
+ mdev->class_id = id;
+}
+EXPORT_SYMBOL(mdev_set_class);
+
struct device *mdev_dev(struct mdev_device *mdev)
{
return &mdev->dev;
@@ -324,6 +334,12 @@ int mdev_device_create(struct kobject *kobj,
if (ret)
goto ops_create_fail;
+ if (!mdev->class_id) {
+ ret = -EINVAL;
+ dev_warn(dev, "mdev vendor driver failed to specify device
class\n");
+ goto add_fail;
+ }
+
ret = device_add(&mdev->dev);
if (ret)
goto add_fail;
diff --
[Intel-gfx] [PATCH V7 2/6] modpost: add support for mdev class id
Add support to parse mdev class id table.
Reviewed-by: Parav Pandit
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/vfio_mdev.c | 2 ++
scripts/mod/devicetable-offsets.c | 3 +++
scripts/mod/file2alias.c | 11 +++
3 files changed, 16 insertions(+)
diff --git a/drivers/vfio/mdev/vfio_mdev.c b/drivers/vfio/mdev/vfio_mdev.c
index 38431e9ef7f5..a6641cd8b5a3 100644
--- a/drivers/vfio/mdev/vfio_mdev.c
+++ b/drivers/vfio/mdev/vfio_mdev.c
@@ -125,6 +125,8 @@ static const struct mdev_class_id vfio_id_table[] = {
{ 0 },
};
+MODULE_DEVICE_TABLE(mdev, vfio_id_table);
+
static struct mdev_driver vfio_mdev_driver = {
.name = "vfio_mdev",
.probe = vfio_mdev_probe,
diff --git a/scripts/mod/devicetable-offsets.c
b/scripts/mod/devicetable-offsets.c
index 054405b90ba4..6cbb1062488a 100644
--- a/scripts/mod/devicetable-offsets.c
+++ b/scripts/mod/devicetable-offsets.c
@@ -231,5 +231,8 @@ int main(void)
DEVID(wmi_device_id);
DEVID_FIELD(wmi_device_id, guid_string);
+ DEVID(mdev_class_id);
+ DEVID_FIELD(mdev_class_id, id);
+
return 0;
}
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index c91eba751804..45f1c22f49be 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1335,6 +1335,16 @@ static int do_wmi_entry(const char *filename, void
*symval, char *alias)
return 1;
}
+/* looks like: "mdev:cN" */
+static int do_mdev_entry(const char *filename, void *symval, char *alias)
+{
+ DEF_FIELD(symval, mdev_class_id, id);
+
+ sprintf(alias, "mdev:c%02X", id);
+ add_wildcard(alias);
+ return 1;
+}
+
/* Does namelen bytes of name exactly match the symbol? */
static bool sym_is(const char *name, unsigned namelen, const char *symbol)
{
@@ -1407,6 +1417,7 @@ static const struct devtable devtable[] = {
{"typec", SIZE_typec_device_id, do_typec_entry},
{"tee", SIZE_tee_client_device_id, do_tee_entry},
{"wmi", SIZE_wmi_device_id, do_wmi_entry},
+ {"mdev", SIZE_mdev_class_id, do_mdev_entry},
};
/* Create MODULE_ALIAS() statements.
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH V7 0/6] mdev based hardware virtio offloading support
Hi all: There are hardwares that can do virtio datapath offloading while having its own control path. This path tries to implement a mdev based unified API to support using kernel virtio driver to drive those devices. This is done by introducing a new mdev transport for virtio (virtio_mdev) and register itself as a new kind of mdev driver. Then it provides a unified way for kernel virtio driver to talk with mdev device implementation. Though the series only contains kernel driver support, the goal is to make the transport generic enough to support userspace drivers. This means vhost-mdev[1] could be built on top as well by resuing the transport. A sample driver is also implemented which simulate a virito-net loopback ethernet device on top of vringh + workqueue. This could be used as a reference implementation for real hardware driver. Also a real ICF VF driver was also posted here[2] which is a good reference for vendors who is interested in their own virtio datapath offloading product. Consider mdev framework only support VFIO device and driver right now, this series also extend it to support other types. This is done through introducing class id to the device and pairing it with id_talbe claimed by the driver. On top, this seris also decouple device specific parents ops out of the common ones. Pktgen test was done with virito-net + mvnet loop back device. Please review. [1] https://lkml.org/lkml/2019/10/31/440 [2] https://lkml.org/lkml/2019/10/15/1226 Changes from V5: - use dev_warn() instead of WARN(1) when class id is not set - validate id_table before trying to do matching between device and driver - add wildcard for modpost script - use unique name for id_table - move get_mdev_features() to be the first member of virtio_device_ops and more comments for it - typo fixes for the comments above virtio_mdev_ops Changes from V4: - keep mdev_set_class() for the device that doesn't use device ops - use union for device ops pointer in mdev_device - introduce class specific helper for getting is device ops - use WARN_ON instead of BUG_ON in mdev_set_virtio_ops - explain details of get_mdev_features() and get_vendor_id() - distinguish the optional virito device ops from mandatory ones and make get_generation() optional - rename vfio_mdev.h to vfio_mdev_ops.h, rename virito_mdev.h to virtio_mdev_ops.h - don't abuse version fileds in virtio_mdev structure, use features instead - fix warning during device remove - style & docs tweaks and typo fixes Changes from V3: - document that class id (device ops) must be specified in create() - add WARN() when trying to set class_id when it has already set - add WARN() when class_id is not specified in create() and correctly return an error in this case - correct the prototype of mdev_set_class() in the doc - add documention of mdev_set_class() - remove the unnecessary "class_id_fail" label when class id is not specified in create() - convert id_table in vfio_mdev to const - move mdev_set_class and its friends after mdev_uuid() - suqash the patch of bus uevent into patch of introducing class id - tweak the words in the docs per Cornelia suggestion - tie class_id and device ops through class specific initialization routine like mdev_set_vfio_ops() - typos fixes in the docs of virtio-mdev callbacks - document the usage of virtqueues in struct virtio_mdev_device - remove the useless vqs array in struct virtio_mdev_device - rename MDEV_ID_XXX to MDEV_CLASS_ID_XXX Changes from V2: - fail when class_id is not specified - drop the vringh patch - match the doc to the code - tweak the commit log - move device_ops from parent to mdev device - remove the unused MDEV_ID_VHOST Changes from V1: - move virtio_mdev.c to drivers/virtio - store class_id in mdev_device instead of mdev_parent - store device_ops in mdev_device instead of mdev_parent - reorder the patch, vringh fix comes first - really silent compiling warnings - really switch to use u16 for class_id - uevent and modpost support for mdev class_id - vraious tweaks per comments from Parav Changes from RFC-V2: - silent compile warnings on some specific configuration - use u16 instead u8 for class id - reseve MDEV_ID_VHOST for future vhost-mdev work - introduce "virtio" type for mvnet and make "vhost" type for future work - add entries in MAINTAINER - tweak and typos fixes in commit log Changes from RFC-V1: - rename device id to class id - add docs for class id and device specific ops (device_ops) - split device_ops into seperate headers - drop the mdev_set_dma_ops() - use device_ops to implement the transport API, then it's not a part of UAPI any more - use GFP_ATOMIC in mvnet sample device and other tweaks - set_vring_base/get_vring_base support for mvnet device Jason Wang (6): mdev: class id support modpost: add support for mdev class id mdev: introduce device specific ops mdev: introduce virtio device and its device ops virtio: introduce a mdev based transport docs: sample d
[Intel-gfx] [PATCH V7 5/6] virtio: introduce a mdev based transport
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.
A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the device with
mdev based config ops. This means it is a software transport between
mdev driver and mdev device. The transport was implemented through
device specific ops which is a part of mdev_parent_ops now.
Signed-off-by: Jason Wang
---
drivers/virtio/Kconfig | 7 +
drivers/virtio/Makefile | 1 +
drivers/virtio/virtio_mdev.c | 413 +++
3 files changed, 421 insertions(+)
create mode 100644 drivers/virtio/virtio_mdev.c
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 078615cf2afc..8d18722ab572 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -43,6 +43,13 @@ config VIRTIO_PCI_LEGACY
If unsure, say Y.
+config VIRTIO_MDEV_DEVICE
+ tristate "VIRTIO driver for Mediated devices"
+ depends on VFIO_MDEV && VIRTIO
+ default n
+ help
+ VIRTIO based driver for Mediated devices.
+
config VIRTIO_PMEM
tristate "Support for virtio pmem driver"
depends on VIRTIO
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 3a2b5c5dcf46..ebc7fa15ae82 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
+obj-$(CONFIG_VIRTIO_MDEV_DEVICE) += virtio_mdev.o
diff --git a/drivers/virtio/virtio_mdev.c b/drivers/virtio/virtio_mdev.c
new file mode 100644
index ..70b8462fd3b5
--- /dev/null
+++ b/drivers/virtio/virtio_mdev.c
@@ -0,0 +1,413 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * VIRTIO based driver for Mediated device
+ *
+ * Copyright (c) 2019, Red Hat. All rights reserved.
+ * Author: Jason Wang
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR "Red Hat Corporation"
+#define DRIVER_DESC "VIRTIO based driver for Mediated device"
+
+#define to_virtio_mdev_device(dev) \
+ container_of(dev, struct virtio_mdev_device, vdev)
+
+struct virtio_mdev_device {
+ struct virtio_device vdev;
+ struct mdev_device *mdev;
+ u64 features;
+
+ /* The lock to protect virtqueue list */
+ spinlock_t lock;
+ /* List of virtio_mdev_vq_info */
+ struct list_head virtqueues;
+};
+
+struct virtio_mdev_vq_info {
+ /* the actual virtqueue */
+ struct virtqueue *vq;
+
+ /* the list node for the virtqueues list */
+ struct list_head node;
+};
+
+static struct mdev_device *vm_get_mdev(struct virtio_device *vdev)
+{
+ struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev);
+ struct mdev_device *mdev = vm_dev->mdev;
+
+ return mdev;
+}
+
+static void virtio_mdev_get(struct virtio_device *vdev, unsigned offset,
+ void *buf, unsigned len)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_device_ops *ops = mdev_get_virtio_ops(mdev);
+
+ ops->get_config(mdev, offset, buf, len);
+}
+
+static void virtio_mdev_set(struct virtio_device *vdev, unsigned offset,
+ const void *buf, unsigned len)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_device_ops *ops = mdev_get_virtio_ops(mdev);
+
+ ops->set_config(mdev, offset, buf, len);
+}
+
+static u32 virtio_mdev_generation(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_device_ops *ops = mdev_get_virtio_ops(mdev);
+
+ if (ops->get_generation)
+ return ops->get_generation(mdev);
+
+ return 0;
+}
+
+static u8 virtio_mdev_get_status(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_device_ops *ops = mdev_get_virtio_ops(mdev);
+
+ return ops->get_status(mdev);
+}
+
+static void virtio_mdev_set_status(struct virtio_device *vdev, u8 status)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_device_ops *ops = mdev_get_virtio_ops(mdev);
+
+ return ops->set_status(mdev, status);
+}
+
+static void virtio_mdev_reset(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_device_ops *ops = mdev_get_virtio_ops(mdev);
+
+ return ops->set_status(mdev, 0);
+}
+
+static bool virtio_mdev_notify(struct virtqueue *vq)
+{
+ struct mdev_device *mdev = vm_get_mdev(vq->vd
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Drop false assertion on user_forcewake
== Series Details == Series: drm/i915/gt: Drop false assertion on user_forcewake URL : https://patchwork.freedesktop.org/series/68922/ State : success == Summary == CI Bug Log - changes from CI_DRM_7247_full -> Patchwork_15119_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_15119_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vcs1-clean: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276] / [fdo#112080]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/shard-iclb1/igt@gem_ctx_isolat...@vcs1-clean.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/shard-iclb5/igt@gem_ctx_isolat...@vcs1-clean.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/shard-iclb4/igt@gem_exec_paral...@vcs1-fds.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +6 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/shard-iclb7/igt@gem_exec_sched...@preempt-other-chain-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_tiled_swapping@non-threaded: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108686]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/shard-apl6/igt@gem_tiled_swapp...@non-threaded.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/shard-apl8/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_userptr_blits@map-fixed-invalidate-busy: - shard-snb: [PASS][9] -> [DMESG-WARN][10] ([fdo#111870]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/shard-snb2/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/shard-snb6/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html * igt@kms_color@pipe-b-ctm-0-75: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([fdo#106107]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/shard-skl9/igt@kms_co...@pipe-b-ctm-0-75.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/shard-skl2/igt@kms_co...@pipe-b-ctm-0-75.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/shard-apl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103166]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-x.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/shard-iclb2/igt@kms_psr2...@frontbuffer.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/shard-iclb5/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/shard-iclb5/igt@kms_psr@psr2_cursor_render.html * igt@prime_vgem@wait-bsd2: - shard-iclb:
[Intel-gfx] [PATCH V7 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to make sure HVA is used
directly as the IOVA. This should be sufficient for kernel virtio
driver to work.
Only 'virtio' type is supported right now. I plan to add 'vhost' type
on top which requires some virtual IOMMU implemented in this sample
driver.
Signed-off-by: Jason Wang
---
MAINTAINERS| 1 +
samples/Kconfig| 7 +
samples/vfio-mdev/Makefile | 1 +
samples/vfio-mdev/mvnet.c | 691 +
4 files changed, 700 insertions(+)
create mode 100644 samples/vfio-mdev/mvnet.c
diff --git a/MAINTAINERS b/MAINTAINERS
index f661d13344d6..35e9204d5c68 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17248,6 +17248,7 @@ F: include/linux/virtio*.h
F: include/uapi/linux/virtio_*.h
F: drivers/crypto/virtio/
F: mm/balloon_compaction.c
+F: samples/vfio-mdev/mvnet.c
VIRTIO BLOCK AND SCSI DRIVERS
M: "Michael S. Tsirkin"
diff --git a/samples/Kconfig b/samples/Kconfig
index c8dacb4dda80..a1a1ca2c00b7 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -131,6 +131,13 @@ config SAMPLE_VFIO_MDEV_MDPY
mediated device. It is a simple framebuffer and supports
the region display interface (VFIO_GFX_PLANE_TYPE_REGION).
+config SAMPLE_VIRTIO_MDEV_NET
+tristate "Build virtio mdev net example mediated device sample code --
loadable modules only"
+ depends on VIRTIO_MDEV_DEVICE && VHOST_RING && m
+ help
+ Build a networking sample device for use as a virtio
+ mediated device.
+
config SAMPLE_VFIO_MDEV_MDPY_FB
tristate "Build VFIO mdpy example guest fbdev driver -- loadable module
only"
depends on FB && m
diff --git a/samples/vfio-mdev/Makefile b/samples/vfio-mdev/Makefile
index 10d179c4fdeb..f34af90ed0a0 100644
--- a/samples/vfio-mdev/Makefile
+++ b/samples/vfio-mdev/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_SAMPLE_VFIO_MDEV_MTTY) += mtty.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY) += mdpy.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY_FB) += mdpy-fb.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MBOCHS) += mbochs.o
+obj-$(CONFIG_SAMPLE_VIRTIO_MDEV_NET) += mvnet.o
diff --git a/samples/vfio-mdev/mvnet.c b/samples/vfio-mdev/mvnet.c
new file mode 100644
index ..e8d84462ae47
--- /dev/null
+++ b/samples/vfio-mdev/mvnet.c
@@ -0,0 +1,691 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Mediated virtual virtio-net device driver.
+ *
+ * Copyright (c) 2019, Red Hat Inc. All rights reserved.
+ * Author: Jason Wang
+ *
+ * Sample driver that creates mdev device that simulates ethernet loopback
+ * device.
+ *
+ * Usage:
+ *
+ * # modprobe virtio_mdev
+ * # modprobe mvnet
+ * # cd /sys/devices/virtual/mvnet/mvnet/mdev_supported_types/mvnet-virtio
+ * # echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > ./create
+ * # cd devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
+ * # ls -d virtio0
+ * virtio0
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define VERSION_STRING "0.1"
+#define DRIVER_AUTHOR "Red Hat Corporation"
+
+#define MVNET_CLASS_NAME "mvnet"
+#define MVNET_NAME "mvnet"
+
+/*
+ * Global Structures
+ */
+
+static struct mvnet_dev {
+ struct class*vd_class;
+ struct idr vd_idr;
+ struct device dev;
+} mvnet_dev;
+
+struct mvnet_virtqueue {
+ struct vringh vring;
+ struct vringh_kiov iov;
+ unsigned short head;
+ bool ready;
+ u64 desc_addr;
+ u64 device_addr;
+ u64 driver_addr;
+ u32 num;
+ void *private;
+ irqreturn_t (*cb)(void *data);
+};
+
+#define MVNET_QUEUE_ALIGN PAGE_SIZE
+#define MVNET_QUEUE_MAX 256
+#define MVNET_DEVICE_ID 0x1
+#define MVNET_VENDOR_ID 0
+
+u64 mvnet_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
+(1ULL << VIRTIO_F_VERSION_1) |
+(1ULL << VIRTIO_F_IOMMU_PLATFORM);
+
+/* State of each mdev device */
+struct mvnet_state {
+ struct mvnet_virtqueue vqs[2];
+ struct work_struct work;
+ spinlock_t lock;
+ struct mdev_device *mdev;
+ struct virtio_net_config config;
+ void *buffer;
+ u32 status;
+ u32 generation;
+ u64 features;
+ struct list_head next;
+};
+
+static struct mutex mdev_list_lock;
+static struct list_head mdev_devices_list;
+
+static void mvnet_queue_ready(struct mvnet_state *mvnet, unsigned int idx)
+{
+ struct mvnet_virtqueue *vq = &mvnet->vqs[idx];
+ int ret;
+
+ ret = vringh_init_kern(&vq->vring, mvnet_features, MVNET_QUEUE_MAX,
+ false, (struct vring_desc *)vq->desc_addr,
+ (struct vring_avail *)vq->driver_addr,
+
[Intel-gfx] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=
Dear Linux folks, On the Dell XPS 13 9380 with Debian Sid/unstable with Linux 5.3.7 resuming0with Dell’s Thunderbolt TB16 dock connected, Linux spews the errors below. ``` [0.00] Linux version 5.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 20191008 (Debian 9.2.1-9)) #1 SMP Debian 5.3.7-1 (2019-10-19) […] [1.596619] pci :00:1f.3: Adding to iommu group 12 [ 14.536274] snd_hda_intel :00:1f.3: enabling device ( -> 0002) [ 14.544100] snd_hda_intel :00:1f.3: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 14.760751] input: HDA Intel PCH Headphone Mic as /devices/pci:00/:00:1f.3/sound/card0/input16 [ 14.760790] input: HDA Intel PCH HDMI as /devices/pci:00/:00:1f.3/sound/card0/input17 [ 156.614284] snd_hda_intel :00:1f.3: No response from codec, disabling MSI: last cmd=0x20270503 [ 157.622232] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20270503 [ 158.626371] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20370503 [ 159.634102] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x201f0500 [ 161.678121] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20270503 [ 162.682272] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20370503 [ 163.694234] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x201f0500 [ 165.730142] snd_hda_intel :00:1f.3: No response from codec, resetting bus: last cmd=0x20270503 […] ``` In the bug report *[Intel Ice Lake, snd-hda-intel, HDMI] "No response from codec" (after display hotplug?)* [1], note it’s a different model, Takashi comments that this is a Thunderbolt or i915 issue. Please tell me, how to debug this further. Kind regards, Paul [1]: https://bugzilla.kernel.org/show_bug.cgi?id=205229 "205229 - [Intel Ice Lake, snd-hda-intel, HDMI] "No response from codec" (after display hotplug?)" [0.463803] pci :3f:00.0: PME# supported from D3cold [0.464089] pci :3e:01.0: PCI bridge to [bus 3f] [0.464111] pci :3e:01.0: bridge window [mem 0xc400-0xc40f] [0.464220] pci :3e:04.0: PCI bridge to [bus 40-6d] [0.464241] pci :3e:04.0: bridge window [mem 0xc410-0xd9ff] [0.464256] pci :3e:04.0: bridge window [mem 0x8000-0xa9ff 64bit pref] [0.464560] pci :6e:00.0: [1344:5410] type 00 class 0x010802 [0.464583] pci :6e:00.0: reg 0x10: [mem 0xdc30-0xdc303fff 64bit] [0.464870] pci :00:1d.4: PCI bridge to [bus 6e] [0.464873] pci :00:1d.4: bridge window [mem 0xdc30-0xdc3f] [0.468165] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 10 11 12 14 15) *0 [0.468218] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 10 11 12 14 15) *1 [0.468269] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 10 11 12 14 15) *0 [0.468320] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 10 11 12 14 15) *0 [0.468371] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 10 11 12 14 15) *0 [0.468422] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 10 11 12 14 15) *0 [0.468473] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 10 11 12 14 15) *0 [0.468524] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 10 11 12 14 15) *0 [0.482170] ACPI: EC: interrupt unblocked [0.482180] ACPI: EC: event unblocked [0.482196] ACPI: \_SB_.PCI0.LPCB.ECDV: GPE=0x6e, EC_CMD/EC_SC=0x934, EC_DATA=0x930 [0.482197] ACPI: \_SB_.PCI0.LPCB.ECDV: Boot DSDT EC used to handle transactions and events [0.482653] pci :00:02.0: vgaarb: setting as boot VGA device [0.482653] pci :00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [0.482653] pci :00:02.0: vgaarb: bridge control possible [0.482653] vgaarb: loaded [0.482752] EDAC MC: Ver: 3.0.0 [0.483874] Registered efivars operations [0.483874] PCI: Using ACPI for IRQ routing [0.519201] PCI: pci_cache_line_size set to 64 bytes [0.519918] e820: reserve RAM buffer [mem 0x0009e000-0x0009] [0.519919] e820: reserve RAM buffer [mem 0x2a059000-0x2bff] [0.519920] e820: reserve RAM buffer [mem 0x3a927000-0x3bff] [0.519920] e820: reserve RAM buffer [mem 0x48e0-0x4bff] [0.519921] e820: reserve RAM buffer [mem 0x4ae80-0x4afff] [0.520127] hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0, 0, 0, 0, 0 [0.520129] hpet0: 8 comparators, 64-bit 24.00 MHz counter [0.521960] clocksource: Switched to clocksource tsc-early [0.528569] VFS: Disk quotas dquot_6.6.0 [0.528579] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [0.528668] AppArmor: AppArmor Filesystem Enabled [0.528677] pnp: PnP ACPI init [0.528744] system 00:00: [mem 0x4000-0x403f] could not be reserved [0.528747] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active) [
Re: [Intel-gfx] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=
Hi, On Mon, Nov 04, 2019 at 01:57:54PM +0100, Paul Menzel wrote: > Dear Linux folks, > > > On the Dell XPS 13 9380 with Debian Sid/unstable with Linux 5.3.7 > resuming0with Dell’s Thunderbolt TB16 dock connected, Linux spews > the errors below. I have this machine here so can try to reproduce it as well. > ``` > [0.00] Linux version 5.3.0-1-amd64 (debian-ker...@lists.debian.org) > (gcc version 9.2.1 20191008 (Debian 9.2.1-9)) #1 SMP Debian 5.3.7-1 > (2019-10-19) > […] > [1.596619] pci :00:1f.3: Adding to iommu group 12 > [ 14.536274] snd_hda_intel :00:1f.3: enabling device ( -> 0002) > [ 14.544100] snd_hda_intel :00:1f.3: bound :00:02.0 (ops > i915_audio_component_bind_ops [i915]) > [ 14.760751] input: HDA Intel PCH Headphone Mic as > /devices/pci:00/:00:1f.3/sound/card0/input16 > [ 14.760790] input: HDA Intel PCH HDMI as > /devices/pci:00/:00:1f.3/sound/card0/input17 > [ 156.614284] snd_hda_intel :00:1f.3: No response from codec, disabling > MSI: last cmd=0x20270503 > [ 157.622232] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x20270503 > [ 158.626371] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x20370503 > [ 159.634102] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x201f0500 > [ 161.678121] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x20270503 > [ 162.682272] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x20370503 > [ 163.694234] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x201f0500 > [ 165.730142] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x20270503 > […] > ``` > > In the bug report *[Intel Ice Lake, snd-hda-intel, HDMI] "No > response from codec" (after display hotplug?)* [1], note it’s a > different model, Takashi comments that this is a Thunderbolt or > i915 issue. :00:1f.3 is on PCH so not sure how it could be related to Thunderbolt, well or i915 for that matter. > Please tell me, how to debug this further. Unfortunately I don't know much about the HDA driver so can't really suggest anything. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=
On Mon, 04 Nov 2019 14:10:24 +0100, Mika Westerberg wrote: > > Hi, > > On Mon, Nov 04, 2019 at 01:57:54PM +0100, Paul Menzel wrote: > > Dear Linux folks, > > > > > > On the Dell XPS 13 9380 with Debian Sid/unstable with Linux 5.3.7 > > resuming0with Dell’s Thunderbolt TB16 dock connected, Linux spews > > the errors below. > > I have this machine here so can try to reproduce it as well. > > > ``` > > [0.00] Linux version 5.3.0-1-amd64 (debian-ker...@lists.debian.org) > > (gcc version 9.2.1 20191008 (Debian 9.2.1-9)) #1 SMP Debian 5.3.7-1 > > (2019-10-19) > > […] > > [1.596619] pci :00:1f.3: Adding to iommu group 12 > > [ 14.536274] snd_hda_intel :00:1f.3: enabling device ( -> 0002) > > [ 14.544100] snd_hda_intel :00:1f.3: bound :00:02.0 (ops > > i915_audio_component_bind_ops [i915]) > > [ 14.760751] input: HDA Intel PCH Headphone Mic as > > /devices/pci:00/:00:1f.3/sound/card0/input16 > > [ 14.760790] input: HDA Intel PCH HDMI as > > /devices/pci:00/:00:1f.3/sound/card0/input17 > > [ 156.614284] snd_hda_intel :00:1f.3: No response from codec, > > disabling MSI: last cmd=0x20270503 > > [ 157.622232] snd_hda_intel :00:1f.3: No response from codec, > > resetting bus: last cmd=0x20270503 > > [ 158.626371] snd_hda_intel :00:1f.3: No response from codec, > > resetting bus: last cmd=0x20370503 > > [ 159.634102] snd_hda_intel :00:1f.3: No response from codec, > > resetting bus: last cmd=0x201f0500 > > [ 161.678121] snd_hda_intel :00:1f.3: No response from codec, > > resetting bus: last cmd=0x20270503 > > [ 162.682272] snd_hda_intel :00:1f.3: No response from codec, > > resetting bus: last cmd=0x20370503 > > [ 163.694234] snd_hda_intel :00:1f.3: No response from codec, > > resetting bus: last cmd=0x201f0500 > > [ 165.730142] snd_hda_intel :00:1f.3: No response from codec, > > resetting bus: last cmd=0x20270503 > > […] > > ``` > > > > In the bug report *[Intel Ice Lake, snd-hda-intel, HDMI] "No > > response from codec" (after display hotplug?)* [1], note it’s a > > different model, Takashi comments that this is a Thunderbolt or > > i915 issue. > > :00:1f.3 is on PCH so not sure how it could be related to > Thunderbolt, well or i915 for that matter. It's the HD-audio controller PCI device and both HDMI and onboard codecs are on that bus. HDMI codec a shadow device of GPU, so it has a strong dependency on i915 GPU driver. The power of HD-audio bus and codec is controlled over DRM audio component ops, so the power-on must have been notified to GPU side, but still something seems missing. ANd, with the dock, the other parties come to play into the game, so it becomes more complex... thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add for_each_port() and use it
On Fri, 01 Nov 2019, Ville Syrjälä wrote:
> On Fri, Nov 01, 2019 at 03:43:33PM +0200, Jani Nikula wrote:
>> Add another for_each style macro to the pile of custom looping macros.
>>
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Thanks, pushed.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/display/intel_bios.c| 8
>> drivers/gpu/drm/i915/display/intel_display.h | 7 +--
>> 2 files changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
>> b/drivers/gpu/drm/i915/display/intel_bios.c
>> index 63c1bd4c2954..a03f56b7b4ef 100644
>> --- a/drivers/gpu/drm/i915/display/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
>> @@ -1246,7 +1246,7 @@ static enum port get_port_by_ddc_pin(struct
>> drm_i915_private *i915, u8 ddc_pin)
>> const struct ddi_vbt_port_info *info;
>> enum port port;
>>
>> -for (port = PORT_A; port < I915_MAX_PORTS; port++) {
>> +for_each_port(port) {
>> info = &i915->vbt.ddi_port_info[port];
>>
>> if (info->child && ddc_pin == info->alternate_ddc_pin)
>> @@ -1297,7 +1297,7 @@ static enum port get_port_by_aux_ch(struct
>> drm_i915_private *i915, u8 aux_ch)
>> const struct ddi_vbt_port_info *info;
>> enum port port;
>>
>> -for (port = PORT_A; port < I915_MAX_PORTS; port++) {
>> +for_each_port(port) {
>> info = &i915->vbt.ddi_port_info[port];
>>
>> if (info->child && aux_ch == info->alternate_aux_channel)
>> @@ -1722,7 +1722,7 @@ init_vbt_defaults(struct drm_i915_private *dev_priv)
>> !HAS_PCH_SPLIT(dev_priv));
>> DRM_DEBUG_KMS("Set default to SSC at %d kHz\n",
>> dev_priv->vbt.lvds_ssc_freq);
>>
>> -for (port = PORT_A; port < I915_MAX_PORTS; port++) {
>> +for_each_port(port) {
>> struct ddi_vbt_port_info *info =
>> &dev_priv->vbt.ddi_port_info[port];
>>
>> @@ -1736,7 +1736,7 @@ init_vbt_missing_defaults(struct drm_i915_private
>> *dev_priv)
>> {
>> enum port port;
>>
>> -for (port = PORT_A; port < I915_MAX_PORTS; port++) {
>> +for_each_port(port) {
>> struct ddi_vbt_port_info *info =
>> &dev_priv->vbt.ddi_port_info[port];
>> enum phy phy = intel_port_to_phy(dev_priv, port);
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
>> b/drivers/gpu/drm/i915/display/intel_display.h
>> index 355c50088589..4522ef167a91 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.h
>> +++ b/drivers/gpu/drm/i915/display/intel_display.h
>> @@ -333,8 +333,11 @@ enum phy_fia {
>> (__s) < RUNTIME_INFO(__dev_priv)->num_sprites[(__p)]; \
>> (__s)++)
>>
>> -#define for_each_port_masked(__port, __ports_mask) \
>> -for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++) \
>> +#define for_each_port(__port) \
>> +for ((__port) = PORT_A; (__port) < I915_MAX_PORTS; (__port)++)
>> +
>> +#define for_each_port_masked(__port, __ports_mask) \
>> +for_each_port(__port) \
>> for_each_if((__ports_mask) & BIT(__port))
>>
>> #define for_each_phy_masked(__phy, __phys_mask) \
>> --
>> 2.20.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Drop false assertion on user_forcewake
== Series Details ==
Series: drm/i915/gt: Drop false assertion on user_forcewake
URL : https://patchwork.freedesktop.org/series/68922/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7247 -> Patchwork_15119
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/index.html
Known issues
Here are the changes found in Patchwork_15119 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload-with-fault-injection:
- fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/fi-bxt-dsi/igt@i915_module_l...@reload-with-fault-injection.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/fi-bxt-dsi/igt@i915_module_l...@reload-with-fault-injection.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-icl-u3: [INCOMPLETE][3] ([fdo#107713] / [fdo#109100]) ->
[PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
- fi-icl-u2: [INCOMPLETE][5] ([fdo#107713] / [fdo#109100]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
* igt@gem_ctx_switch@rcs0:
- {fi-icl-y}: [INCOMPLETE][7] ([fdo#107713]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/fi-icl-y/igt@gem_ctx_swi...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/fi-icl-y/igt@gem_ctx_swi...@rcs0.html
* igt@i915_selftest@live_requests:
- {fi-tgl-u}: [INCOMPLETE][9] ([fdo#112057]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7247/fi-tgl-u/igt@i915_selftest@live_requests.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/fi-tgl-u/igt@i915_selftest@live_requests.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
[fdo#109644]: https://bugs.freedesktop.org/show_bug.cgi?id=109644
[fdo#110464]: https://bugs.freedesktop.org/show_bug.cgi?id=110464
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111678]: https://bugs.freedesktop.org/show_bug.cgi?id=111678
[fdo#112057]: https://bugs.freedesktop.org/show_bug.cgi?id=112057
[fdo#112205]: https://bugs.freedesktop.org/show_bug.cgi?id=112205
Participating hosts (50 -> 44)
--
Additional (2): fi-tgl-y fi-icl-dsi
Missing(8): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bwr-2160
fi-ctg-p8600 fi-gdg-551 fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7247 -> Patchwork_15119
CI-20190529: 20190529
CI_DRM_7247: 2008426992017b0b2fa4b8bfef0a837086fe4322 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5259: 6237a45d8699b2ccb4512e222ce6c94a1c77f83b @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15119: 2e7d4d2528baccce7f3593fce645f1e179ac5683 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2e7d4d2528ba drm/i915/gt: Drop false assertion on user_forcewake
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15119/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Reset CSB pointers by mmio as well
Sometimes Icelake forgets to reset the CSB pointers on a GPU reset,
leading to carry on updating the old tail of the buffer.
<0>[ 618.138490] i915_sel-56363d..1 673425465us : trace_ports: vecs0:
submit { 14de2:504, 0:0 }
<0>[ 618.138490] i915_sel-56363 673425493us : intel_engine_reset:
vecs0 flags=100
<0>[ 618.138490] i915_sel-56363 673425493us : execlists_reset_prepare:
vecs0: depth<-0
<0>[ 618.138490] i915_sel-56363 673425493us : intel_engine_stop_cs:
vecs0
<0>[ 618.138490] i915_sel-56363 673425523us : __intel_gt_reset:
engine_mask=40
<0>[ 618.138490] i915_sel-56363 673425568us : execlists_reset: vecs0
<0>[ 618.138490] i915_sel-56363d..1 673425568us : process_csb: vecs0
cs-irq head=1, tail=2
<0>[ 618.138490] i915_sel-56363d..1 673425568us : process_csb: vecs0
csb[2]: status=0x0001:0x4000
<0>[ 618.138490] i915_sel-56363d..1 673425569us : trace_ports: vecs0:
promote { 14de2:504*, 0:0 }
<0>[ 618.138490] i915_sel-56363d..1 673425570us : __i915_request_reset:
vecs0 rq=14de2:504, guilty? yes
<0>[ 618.138490] i915_sel-56363d..1 673425571us : __execlists_reset: vecs0
replay {head:2de0, tail:2e48}
<0>[ 618.138490] i915_sel-56363d..1 673425572us : __i915_request_unsubmit:
vecs0 fence 14de2:504, current 503
<0>[ 618.138490] i915_sel-56363 673435544us :
intel_engine_cancel_stop_cs: vecs0
<0>[ 618.138490] i915_sel-56363 673435544us : process_csb: vecs0
cs-irq head=11, tail=11
<0>[ 618.138490] i915_sel-56363d..1 673435545us : __i915_request_submit:
vecs0 fence 14de2:504, current 503
<0>[ 618.138490] i915_sel-56363d..1 673435546us :
__execlists_submission_tasklet: vecs0: queue_priority_hint:-2147483648,
submit:yes
<0>[ 618.138490] i915_sel-56363d..1 673435548us : trace_ports: vecs0:
submit { 14de2:504*, 0:0 }
<0>[ 618.138490] i915_sel-56363 673435549us : execlists_reset_finish:
vecs0: depth->0
<0>[ 618.138490] ksoftirq-21 2..s. 673435592us : process_csb: vecs0
cs-irq head=11, tail=3
<0>[ 618.138490] ksoftirq-21 2..s. 673435593us : process_csb: vecs0
csb[0]: status=0x0001:0x4000
<0>[ 618.138490] ksoftirq-21 2..s. 673435594us : trace_ports: vecs0:
promote { 14de2:504*, 0:0 }
<0>[ 618.138490] ksoftirq-21 2..s. 673435596us : process_csb: vecs0
csb[1]: status=0x0018:0x4040
<0>[ 618.138490] ksoftirq-21 2..s. 673435597us : trace_ports: vecs0:
completed { 14de2:504*, 0:0 }
<0>[ 618.138490] ksoftirq-21 2..s. 673435612us : process_csb:
process_csb:2188 GEM_BUG_ON(!i915_request_completed(*execlists->active) &&
!reset_in_progress(execlists))
After the reset, we do another clflush before checking the CSB to be
sure we see whatever was left in the CSB prior to the reset. So it is
unlikely to be an incoherent view of the CSB, and more likely that
Icelake didn't reset its pointers.
References: 582a6f90aa0d ("drm/i915/execlists: Add a paranoid flush of the CSB
pointers upon reset")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 8d79a965f341..b869a9c7b3c6 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2996,6 +2996,14 @@ static void reset_csb_pointers(struct intel_engine_cs
*engine)
WRITE_ONCE(*execlists->csb_write, reset_value);
wmb(); /* Make sure this is visible to HW (paranoia?) */
+ /*
+* Sometimes Icelakes forgets to reset its pointers on a GPU reset.
+* Bludgeon them with a mmio update to be sure.
+*/
+ ENGINE_WRITE(engine, RING_CONTEXT_STATUS_PTR,
+reset_value << 8 | reset_value);
+ ENGINE_POSTING_READ(engine, RING_CONTEXT_STATUS_PTR);
+
invalidate_csb_entries(&execlists->csb_status[0],
&execlists->csb_status[reset_value]);
}
--
2.24.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/5] drm/dsi: clean up DSI data type definitions
Hi all, I'd really appreciate some (non-Intel) acks or reviews on this
series. Don't feel comfortable merging it otherwise. It should be fairly
straightforward stuff as long as you have some DSI specs handy.
BR,
Jani.
On Mon, 28 Oct 2019, Jani Nikula wrote:
> Rename picture parameter set (it's a long packet, not a long write) and
> compression mode (it's not a DCS command) enumerations according to the
> DSI specification. Order the types according to the spec. Use tabs
> instead of spaces for indentation. Use all lower case for hex.
>
> Cc: Vandita Kulkarni
> Reviewed-by: Vandita Kulkarni
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_mipi_dsi.c | 4 ++--
> include/video/mipi_display.h | 10 +-
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index bd2498bbd74a..f237d80828c3 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -373,6 +373,7 @@ bool mipi_dsi_packet_format_is_short(u8 type)
> case MIPI_DSI_V_SYNC_END:
> case MIPI_DSI_H_SYNC_START:
> case MIPI_DSI_H_SYNC_END:
> + case MIPI_DSI_COMPRESSION_MODE:
> case MIPI_DSI_END_OF_TRANSMISSION:
> case MIPI_DSI_COLOR_MODE_OFF:
> case MIPI_DSI_COLOR_MODE_ON:
> @@ -387,7 +388,6 @@ bool mipi_dsi_packet_format_is_short(u8 type)
> case MIPI_DSI_DCS_SHORT_WRITE:
> case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
> case MIPI_DSI_DCS_READ:
> - case MIPI_DSI_DCS_COMPRESSION_MODE:
> case MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE:
> return true;
> }
> @@ -406,11 +406,11 @@ EXPORT_SYMBOL(mipi_dsi_packet_format_is_short);
> bool mipi_dsi_packet_format_is_long(u8 type)
> {
> switch (type) {
> - case MIPI_DSI_PPS_LONG_WRITE:
> case MIPI_DSI_NULL_PACKET:
> case MIPI_DSI_BLANKING_PACKET:
> case MIPI_DSI_GENERIC_LONG_WRITE:
> case MIPI_DSI_DCS_LONG_WRITE:
> + case MIPI_DSI_PICTURE_PARAMETER_SET:
> case MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20:
> case MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24:
> case MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16:
> diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
> index cba57a678daf..79fd71cf4934 100644
> --- a/include/video/mipi_display.h
> +++ b/include/video/mipi_display.h
> @@ -17,6 +17,9 @@ enum {
> MIPI_DSI_H_SYNC_START = 0x21,
> MIPI_DSI_H_SYNC_END = 0x31,
>
> + MIPI_DSI_COMPRESSION_MODE = 0x07,
> + MIPI_DSI_END_OF_TRANSMISSION= 0x08,
> +
> MIPI_DSI_COLOR_MODE_OFF = 0x02,
> MIPI_DSI_COLOR_MODE_ON = 0x12,
> MIPI_DSI_SHUTDOWN_PERIPHERAL= 0x22,
> @@ -35,18 +38,15 @@ enum {
>
> MIPI_DSI_DCS_READ = 0x06,
>
> - MIPI_DSI_DCS_COMPRESSION_MODE = 0x07,
> - MIPI_DSI_PPS_LONG_WRITE = 0x0A,
> -
> MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
>
> - MIPI_DSI_END_OF_TRANSMISSION= 0x08,
> -
> MIPI_DSI_NULL_PACKET= 0x09,
> MIPI_DSI_BLANKING_PACKET= 0x19,
> MIPI_DSI_GENERIC_LONG_WRITE = 0x29,
> MIPI_DSI_DCS_LONG_WRITE = 0x39,
>
> + MIPI_DSI_PICTURE_PARAMETER_SET = 0x0a,
> +
> MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20= 0x0c,
> MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24= 0x1c,
> MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16= 0x2c,
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/4] drm/i915/dsc: rename functions for consistency
Use intel_dsc_ prefix. No functional changes.
Cc: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index ac10736a076a..b23ba8d108db 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -501,8 +501,8 @@ intel_dsc_power_domain(const struct intel_crtc_state
*crtc_state)
return POWER_DOMAIN_TRANSCODER(cpu_transcoder);
}
-static void intel_configure_pps_for_dsc_encoder(struct intel_encoder *encoder,
- const struct intel_crtc_state
*crtc_state)
+static void intel_dsc_pps_configure(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
@@ -901,8 +901,8 @@ static void intel_configure_pps_for_dsc_encoder(struct
intel_encoder *encoder,
}
}
-static void intel_dp_write_dsc_pps_sdp(struct intel_encoder *encoder,
- const struct intel_crtc_state
*crtc_state)
+static void intel_dsc_dp_pps_write(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
{
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -937,9 +937,9 @@ void intel_dsc_enable(struct intel_encoder *encoder,
intel_display_power_get(dev_priv,
intel_dsc_power_domain(crtc_state));
- intel_configure_pps_for_dsc_encoder(encoder, crtc_state);
+ intel_dsc_pps_configure(encoder, crtc_state);
- intel_dp_write_dsc_pps_sdp(encoder, crtc_state);
+ intel_dsc_dp_pps_write(encoder, crtc_state);
if (crtc_state->cpu_transcoder == TRANSCODER_EDP) {
dss_ctl1_reg = DSS_CTL1;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915/dsc: split out encoder specific parts from DSC compute params
Split out the DP specific parts, making it easier to add DSI specific
configuration. Also move the encoder specific parts towards the end, to
allow overriding generic configuration if needed. This also improves
clarity by making it clear the encoder independent configuration does
not depend on the encoder specific parts.
v2: Rebase
Cc: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/i915/display/intel_vdsc.c | 68 ++-
drivers/gpu/drm/i915/display/intel_vdsc.h | 5 +-
3 files changed, 45 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index fe1d683eab28..9e9593965a9a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2132,7 +2132,7 @@ static int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
}
}
- ret = intel_dp_compute_dsc_params(intel_dp, pipe_config);
+ ret = intel_dsc_compute_params(&dig_port->base, pipe_config);
if (ret < 0) {
DRM_DEBUG_KMS("Cannot compute valid DSC parameters for Input
Bpp = %d "
"Compressed BPP = %d\n",
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index f1df654369a7..ac10736a076a 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -335,32 +335,14 @@ static const struct rc_parameters *get_rc_params(u16
compressed_bpp,
return &rc_parameters[row_index][column_index];
}
-int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
- struct intel_crtc_state *pipe_config)
+/* Values filled from DSC Sink DPCD */
+static int intel_dsc_dp_compute_params(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config)
{
+ struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
struct drm_dsc_config *vdsc_cfg = &pipe_config->dsc.config;
- u16 compressed_bpp = pipe_config->dsc.compressed_bpp;
- const struct rc_parameters *rc_params;
- u8 i = 0;
- u8 line_buf_depth = 0;
+ u8 line_buf_depth;
- vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
- vdsc_cfg->pic_height = pipe_config->hw.adjusted_mode.crtc_vdisplay;
- vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
-pipe_config->dsc.slice_count);
- /*
-* Slice Height of 8 works for all currently available panels. So start
-* with that if pic_height is an integral multiple of 8.
-* Eventually add logic to try multiple slice heights.
-*/
- if (vdsc_cfg->pic_height % 8 == 0)
- vdsc_cfg->slice_height = 8;
- else if (vdsc_cfg->pic_height % 4 == 0)
- vdsc_cfg->slice_height = 4;
- else
- vdsc_cfg->slice_height = 2;
-
- /* Values filled from DSC Sink DPCD */
vdsc_cfg->dsc_version_major =
(intel_dp->dsc_dpcd[DP_DSC_REV - DP_DSC_SUPPORT] &
DP_DSC_MAJOR_MASK) >> DP_DSC_MAJOR_SHIFT;
@@ -377,6 +359,7 @@ int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
DRM_DEBUG_KMS("DSC Sink Line Buffer Depth invalid\n");
return -EINVAL;
}
+
if (vdsc_cfg->dsc_version_minor == 2)
vdsc_cfg->line_buf_depth = (line_buf_depth ==
DSC_1_2_MAX_LINEBUF_DEPTH_BITS) ?
DSC_1_2_MAX_LINEBUF_DEPTH_VAL : line_buf_depth;
@@ -384,13 +367,42 @@ int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
vdsc_cfg->line_buf_depth = (line_buf_depth >
DSC_1_1_MAX_LINEBUF_DEPTH_BITS) ?
DSC_1_1_MAX_LINEBUF_DEPTH_BITS : line_buf_depth;
+ vdsc_cfg->block_pred_enable =
+ intel_dp->dsc_dpcd[DP_DSC_BLK_PREDICTION_SUPPORT -
DP_DSC_SUPPORT] &
+ DP_DSC_BLK_PREDICTION_IS_SUPPORTED;
+
+ return 0;
+}
+
+int intel_dsc_compute_params(struct intel_encoder *encoder,
+struct intel_crtc_state *pipe_config)
+{
+ struct drm_dsc_config *vdsc_cfg = &pipe_config->dsc.config;
+ u16 compressed_bpp = pipe_config->dsc.compressed_bpp;
+ const struct rc_parameters *rc_params;
+ u8 i = 0;
+ int ret;
+
+ vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
+ vdsc_cfg->pic_height = pipe_config->hw.adjusted_mode.crtc_vdisplay;
+ vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
+pipe_config->dsc.slice_count);
+ /*
+* Slice Height of 8 works for all currently available panels. So start
+* with that if pic_height is an integral multiple of 8.
+* Eventually add logic to try multiple slice heights.
+
[Intel-gfx] [PATCH v2 2/4] drm/i915/dsc: clean up rc parameter table access
Use a simple pointer to the relevant element instead of duplicating the
array subscription. No functional changes.
Cc: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 55 ---
1 file changed, 30 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 763f1d7208e9..f1df654369a7 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -53,7 +53,7 @@ struct rc_parameters {
* Selected Rate Control Related Parameter Recommended Values
* from DSC_v1.11 spec & C Model release: DSC_model_20161212
*/
-static const struct rc_parameters rc_params[][MAX_COLUMN_INDEX] = {
+static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
{
/* 6BPP/8BPC */
{ 768, 15, 6144, 3, 13, 11, 11, {
@@ -319,14 +319,29 @@ static int get_column_index_for_rc_params(u8
bits_per_component)
}
}
+static const struct rc_parameters *get_rc_params(u16 compressed_bpp,
+u8 bits_per_component)
+{
+ int row_index, column_index;
+
+ row_index = get_row_index_for_rc_params(compressed_bpp);
+ if (row_index < 0)
+ return NULL;
+
+ column_index = get_column_index_for_rc_params(bits_per_component);
+ if (column_index < 0)
+ return NULL;
+
+ return &rc_parameters[row_index][column_index];
+}
+
int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config)
{
struct drm_dsc_config *vdsc_cfg = &pipe_config->dsc.config;
u16 compressed_bpp = pipe_config->dsc.compressed_bpp;
+ const struct rc_parameters *rc_params;
u8 i = 0;
- int row_index = 0;
- int column_index = 0;
u8 line_buf_depth = 0;
vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
@@ -399,39 +414,29 @@ int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
vdsc_cfg->rc_buf_thresh[13] = 0x7D;
}
- row_index = get_row_index_for_rc_params(compressed_bpp);
- column_index =
- get_column_index_for_rc_params(vdsc_cfg->bits_per_component);
-
- if (row_index < 0 || column_index < 0)
+ rc_params = get_rc_params(compressed_bpp, vdsc_cfg->bits_per_component);
+ if (!rc_params)
return -EINVAL;
- vdsc_cfg->first_line_bpg_offset =
- rc_params[row_index][column_index].first_line_bpg_offset;
- vdsc_cfg->initial_xmit_delay =
- rc_params[row_index][column_index].initial_xmit_delay;
- vdsc_cfg->initial_offset =
- rc_params[row_index][column_index].initial_offset;
- vdsc_cfg->flatness_min_qp =
- rc_params[row_index][column_index].flatness_min_qp;
- vdsc_cfg->flatness_max_qp =
- rc_params[row_index][column_index].flatness_max_qp;
- vdsc_cfg->rc_quant_incr_limit0 =
- rc_params[row_index][column_index].rc_quant_incr_limit0;
- vdsc_cfg->rc_quant_incr_limit1 =
- rc_params[row_index][column_index].rc_quant_incr_limit1;
+ vdsc_cfg->first_line_bpg_offset = rc_params->first_line_bpg_offset;
+ vdsc_cfg->initial_xmit_delay = rc_params->initial_xmit_delay;
+ vdsc_cfg->initial_offset = rc_params->initial_offset;
+ vdsc_cfg->flatness_min_qp = rc_params->flatness_min_qp;
+ vdsc_cfg->flatness_max_qp = rc_params->flatness_max_qp;
+ vdsc_cfg->rc_quant_incr_limit0 = rc_params->rc_quant_incr_limit0;
+ vdsc_cfg->rc_quant_incr_limit1 = rc_params->rc_quant_incr_limit1;
for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
vdsc_cfg->rc_range_params[i].range_min_qp =
-
rc_params[row_index][column_index].rc_range_params[i].range_min_qp;
+ rc_params->rc_range_params[i].range_min_qp;
vdsc_cfg->rc_range_params[i].range_max_qp =
-
rc_params[row_index][column_index].rc_range_params[i].range_max_qp;
+ rc_params->rc_range_params[i].range_max_qp;
/*
* Range BPG Offset uses 2's complement and is only a 6 bits. So
* mask it to get only 6 bits.
*/
vdsc_cfg->rc_range_params[i].range_bpg_offset =
-
rc_params[row_index][column_index].rc_range_params[i].range_bpg_offset &
+ rc_params->rc_range_params[i].range_bpg_offset &
DSC_RANGE_BPG_OFFSET_MASK;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/4] drm/i915/dsc: make parameter arrays const
No need for them to be mutable.
Cc: Manasi Navare
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 9cb36f855f07..763f1d7208e9 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -33,7 +33,7 @@ enum COLUMN_INDEX_BPC {
#define DSC_SUPPORTED_VERSION_MIN 1
/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
-static u16 rc_buf_thresh[] = {
+static const u16 rc_buf_thresh[] = {
896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
7744, 7872, 8000, 8064
};
@@ -53,7 +53,7 @@ struct rc_parameters {
* Selected Rate Control Related Parameter Recommended Values
* from DSC_v1.11 spec & C Model release: DSC_model_20161212
*/
-static struct rc_parameters rc_params[][MAX_COLUMN_INDEX] = {
+static const struct rc_parameters rc_params[][MAX_COLUMN_INDEX] = {
{
/* 6BPP/8BPC */
{ 768, 15, 6144, 3, 13, 11, 11, {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Display WA2006604312 is needed from ICL onwards
== Series Details ==
Series: drm/i915: Display WA2006604312 is needed from ICL onwards
URL : https://patchwork.freedesktop.org/series/68932/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7252 -> Patchwork_15120
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15120/index.html
Known issues
Here are the changes found in Patchwork_15120 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-icl-u3: [DMESG-WARN][1] ([fdo#107724]) -> [PASS][2] +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7252/fi-icl-u3/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15120/fi-icl-u3/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_blt:
- fi-bsw-nick:[DMESG-FAIL][3] ([fdo#112176]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7252/fi-bsw-nick/igt@i915_selftest@live_blt.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15120/fi-bsw-nick/igt@i915_selftest@live_blt.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][5] ([fdo#111407]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7252/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15120/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111593]: https://bugs.freedesktop.org/show_bug.cgi?id=111593
[fdo#112176]: https://bugs.freedesktop.org/show_bug.cgi?id=112176
Participating hosts (53 -> 44)
--
Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-bwr-2160 fi-ctg-p8600 fi-gdg-551 fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7252 -> Patchwork_15120
CI-20190529: 20190529
CI_DRM_7252: 1971e2dbb8626482b7ed182d6e96a6810020b95e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5259: 6237a45d8699b2ccb4512e222ce6c94a1c77f83b @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15120: 0b832c14eb762d27aab421365d64720dd0428ffa @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0b832c14eb76 drm/i915: Display WA2006604312 is needed from ICL onwards
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15120/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Reset CSB pointers by mmio as well
Chris Wilson writes:
> Sometimes Icelake forgets to reset the CSB pointers on a GPU reset,
> leading to carry on updating the old tail of the buffer.
>
> <0>[ 618.138490] i915_sel-56363d..1 673425465us : trace_ports: vecs0:
> submit { 14de2:504, 0:0 }
> <0>[ 618.138490] i915_sel-56363 673425493us : intel_engine_reset:
> vecs0 flags=100
> <0>[ 618.138490] i915_sel-56363 673425493us :
> execlists_reset_prepare: vecs0: depth<-0
> <0>[ 618.138490] i915_sel-56363 673425493us : intel_engine_stop_cs:
> vecs0
> <0>[ 618.138490] i915_sel-56363 673425523us : __intel_gt_reset:
> engine_mask=40
> <0>[ 618.138490] i915_sel-56363 673425568us : execlists_reset: vecs0
> <0>[ 618.138490] i915_sel-56363d..1 673425568us : process_csb: vecs0
> cs-irq head=1, tail=2
> <0>[ 618.138490] i915_sel-56363d..1 673425568us : process_csb: vecs0
> csb[2]: status=0x0001:0x4000
> <0>[ 618.138490] i915_sel-56363d..1 673425569us : trace_ports: vecs0:
> promote { 14de2:504*, 0:0 }
> <0>[ 618.138490] i915_sel-56363d..1 673425570us : __i915_request_reset:
> vecs0 rq=14de2:504, guilty? yes
> <0>[ 618.138490] i915_sel-56363d..1 673425571us : __execlists_reset:
> vecs0 replay {head:2de0, tail:2e48}
> <0>[ 618.138490] i915_sel-56363d..1 673425572us :
> __i915_request_unsubmit: vecs0 fence 14de2:504, current 503
> <0>[ 618.138490] i915_sel-56363 673435544us :
> intel_engine_cancel_stop_cs: vecs0
> <0>[ 618.138490] i915_sel-56363 673435544us : process_csb: vecs0
> cs-irq head=11, tail=11
> <0>[ 618.138490] i915_sel-56363d..1 673435545us : __i915_request_submit:
> vecs0 fence 14de2:504, current 503
> <0>[ 618.138490] i915_sel-56363d..1 673435546us :
> __execlists_submission_tasklet: vecs0: queue_priority_hint:-2147483648,
> submit:yes
> <0>[ 618.138490] i915_sel-56363d..1 673435548us : trace_ports: vecs0:
> submit { 14de2:504*, 0:0 }
> <0>[ 618.138490] i915_sel-56363 673435549us :
> execlists_reset_finish: vecs0: depth->0
> <0>[ 618.138490] ksoftirq-21 2..s. 673435592us : process_csb: vecs0
> cs-irq head=11, tail=3
> <0>[ 618.138490] ksoftirq-21 2..s. 673435593us : process_csb: vecs0
> csb[0]: status=0x0001:0x4000
> <0>[ 618.138490] ksoftirq-21 2..s. 673435594us : trace_ports: vecs0:
> promote { 14de2:504*, 0:0 }
> <0>[ 618.138490] ksoftirq-21 2..s. 673435596us : process_csb: vecs0
> csb[1]: status=0x0018:0x4040
> <0>[ 618.138490] ksoftirq-21 2..s. 673435597us : trace_ports: vecs0:
> completed { 14de2:504*, 0:0 }
> <0>[ 618.138490] ksoftirq-21 2..s. 673435612us : process_csb:
> process_csb:2188 GEM_BUG_ON(!i915_request_completed(*execlists->active) &&
> !reset_in_progress(execlists))
>
> After the reset, we do another clflush before checking the CSB to be
> sure we see whatever was left in the CSB prior to the reset. So it is
> unlikely to be an incoherent view of the CSB, and more likely that
> Icelake didn't reset its pointers.
>
> References: 582a6f90aa0d ("drm/i915/execlists: Add a paranoid flush of the
> CSB pointers upon reset")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 8d79a965f341..b869a9c7b3c6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -2996,6 +2996,14 @@ static void reset_csb_pointers(struct intel_engine_cs
> *engine)
> WRITE_ONCE(*execlists->csb_write, reset_value);
> wmb(); /* Make sure this is visible to HW (paranoia?) */
>
> + /*
> + * Sometimes Icelakes forgets to reset its pointers on a GPU reset.
> + * Bludgeon them with a mmio update to be sure.
> + */
> + ENGINE_WRITE(engine, RING_CONTEXT_STATUS_PTR,
> + reset_value << 8 | reset_value);
> + ENGINE_POSTING_READ(engine, RING_CONTEXT_STATUS_PTR);
> +
Big hammer indeed. Next one is that we assert the reset value
and check that first one after reset comes out with 0x0?
Reviewed-by: Mika Kuoppala
> invalidate_csb_entries(&execlists->csb_status[0],
> &execlists->csb_status[reset_value]);
> }
> --
> 2.24.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Reset CSB pointers by mmio as well
Quoting Mika Kuoppala (2019-11-04 14:27:21)
> Chris Wilson writes:
>
> > Sometimes Icelake forgets to reset the CSB pointers on a GPU reset,
> > leading to carry on updating the old tail of the buffer.
> >
> > <0>[ 618.138490] i915_sel-56363d..1 673425465us : trace_ports: vecs0:
> > submit { 14de2:504, 0:0 }
> > <0>[ 618.138490] i915_sel-56363 673425493us : intel_engine_reset:
> > vecs0 flags=100
> > <0>[ 618.138490] i915_sel-56363 673425493us :
> > execlists_reset_prepare: vecs0: depth<-0
> > <0>[ 618.138490] i915_sel-56363 673425493us :
> > intel_engine_stop_cs: vecs0
> > <0>[ 618.138490] i915_sel-56363 673425523us : __intel_gt_reset:
> > engine_mask=40
> > <0>[ 618.138490] i915_sel-56363 673425568us : execlists_reset:
> > vecs0
> > <0>[ 618.138490] i915_sel-56363d..1 673425568us : process_csb: vecs0
> > cs-irq head=1, tail=2
> > <0>[ 618.138490] i915_sel-56363d..1 673425568us : process_csb: vecs0
> > csb[2]: status=0x0001:0x4000
> > <0>[ 618.138490] i915_sel-56363d..1 673425569us : trace_ports: vecs0:
> > promote { 14de2:504*, 0:0 }
> > <0>[ 618.138490] i915_sel-56363d..1 673425570us :
> > __i915_request_reset: vecs0 rq=14de2:504, guilty? yes
> > <0>[ 618.138490] i915_sel-56363d..1 673425571us : __execlists_reset:
> > vecs0 replay {head:2de0, tail:2e48}
> > <0>[ 618.138490] i915_sel-56363d..1 673425572us :
> > __i915_request_unsubmit: vecs0 fence 14de2:504, current 503
> > <0>[ 618.138490] i915_sel-56363 673435544us :
> > intel_engine_cancel_stop_cs: vecs0
> > <0>[ 618.138490] i915_sel-56363 673435544us : process_csb: vecs0
> > cs-irq head=11, tail=11
> > <0>[ 618.138490] i915_sel-56363d..1 673435545us :
> > __i915_request_submit: vecs0 fence 14de2:504, current 503
> > <0>[ 618.138490] i915_sel-56363d..1 673435546us :
> > __execlists_submission_tasklet: vecs0: queue_priority_hint:-2147483648,
> > submit:yes
> > <0>[ 618.138490] i915_sel-56363d..1 673435548us : trace_ports: vecs0:
> > submit { 14de2:504*, 0:0 }
> > <0>[ 618.138490] i915_sel-56363 673435549us :
> > execlists_reset_finish: vecs0: depth->0
> > <0>[ 618.138490] ksoftirq-21 2..s. 673435592us : process_csb: vecs0
> > cs-irq head=11, tail=3
> > <0>[ 618.138490] ksoftirq-21 2..s. 673435593us : process_csb: vecs0
> > csb[0]: status=0x0001:0x4000
> > <0>[ 618.138490] ksoftirq-21 2..s. 673435594us : trace_ports: vecs0:
> > promote { 14de2:504*, 0:0 }
> > <0>[ 618.138490] ksoftirq-21 2..s. 673435596us : process_csb: vecs0
> > csb[1]: status=0x0018:0x4040
> > <0>[ 618.138490] ksoftirq-21 2..s. 673435597us : trace_ports: vecs0:
> > completed { 14de2:504*, 0:0 }
> > <0>[ 618.138490] ksoftirq-21 2..s. 673435612us : process_csb:
> > process_csb:2188 GEM_BUG_ON(!i915_request_completed(*execlists->active) &&
> > !reset_in_progress(execlists))
> >
> > After the reset, we do another clflush before checking the CSB to be
> > sure we see whatever was left in the CSB prior to the reset. So it is
> > unlikely to be an incoherent view of the CSB, and more likely that
> > Icelake didn't reset its pointers.
> >
> > References: 582a6f90aa0d ("drm/i915/execlists: Add a paranoid flush of the
> > CSB pointers upon reset")
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 8d79a965f341..b869a9c7b3c6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -2996,6 +2996,14 @@ static void reset_csb_pointers(struct
> > intel_engine_cs *engine)
> > WRITE_ONCE(*execlists->csb_write, reset_value);
> > wmb(); /* Make sure this is visible to HW (paranoia?) */
> >
> > + /*
> > + * Sometimes Icelakes forgets to reset its pointers on a GPU reset.
> > + * Bludgeon them with a mmio update to be sure.
> > + */
> > + ENGINE_WRITE(engine, RING_CONTEXT_STATUS_PTR,
> > + reset_value << 8 | reset_value);
> > + ENGINE_POSTING_READ(engine, RING_CONTEXT_STATUS_PTR);
> > +
>
> Big hammer indeed. Next one is that we assert the reset value
> and check that first one after reset comes out with 0x0?
Yeah, I was thinking about that. Didn't seem trivial since it's not
always a single event. Plus then rare reset code is then spreading into
the hotpath :(
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH i-g-t v4 2/4] lib: Add minimum GTT alignment helper
Hi Vanshi,
On Thursday, October 31, 2019 5:58:31 PM CET Vanshidhar Konda wrote:
> On Thu, Oct 31, 2019 at 04:28:55PM +0100, Janusz Krzysztofik wrote:
> >Some tests assume 4kB offset alignment while using softpin. That
> >assumption may be wrong on future GEM backends with possibly larger
> >minimum page sizes. As a result, those tests may either fail on
> >softpin at offsets which are incorrectly aligned, may silently skip
> >such incorrectly aligned addresses assuming them occupied by other
> >users if incorrect detection method is used, or may always succeed
> >when examining invalid use patterns.
> >
> >Provide a helper function that detects minimum GTT alignment. Tests
> >may use it to calculate softpin offsets valid for actually used backing
> >store.
> >
> >v2: Rename the helper, use 'minimum GTT alignment' term across the
> >change (Chris),
> > - use error numbers to distinguish between invalid offsets and
> >addresses occupied by other users, then
> > - simplify the code (Chris).
> >
> >Signed-off-by: Janusz Krzysztofik
> >Cc: Chris Wilson
> >Cc: Daniele Ceraolo Spurio
> >Cc: Stuart Summers
> >---
> > lib/ioctl_wrappers.c | 46
> > lib/ioctl_wrappers.h | 2 ++
> > 2 files changed, 48 insertions(+)
> >
> >diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> >index 628f8b83..f0ef8b2e 100644
> >--- a/lib/ioctl_wrappers.c
> >+++ b/lib/ioctl_wrappers.c
> >@@ -54,6 +54,7 @@
> > #include "intel_io.h"
> > #include "igt_debugfs.h"
> > #include "igt_sysfs.h"
> >+#include "igt_x86.h"
> > #include "config.h"
> >
> > #ifdef HAVE_VALGRIND
> >@@ -1158,6 +1159,51 @@ bool gem_has_softpin(int fd)
> > return has_softpin;
> > }
> >
> >+/**
> >+ * gem_gtt_min_alignment_order:
> >+ * @fd: open i915 drm file descriptor
> >+ *
> >+ * This function detects the minimum possible alignment of a soft-pinned gem
> >+ * object allocated from a default backing store. It is useful for
> >calculating
> >+ * correctly aligned softpin offsets.
> >+ * Since size order to size conversion (size = 1 << order) is less trivial
> >+ * than the opposite, the function returns the alignment order as more
> >handy.
> >+ *
> >+ * Returns:
> >+ * Size order of the minimum GTT alignment
> >+ */
> >+int gem_gtt_min_alignment_order(int fd)
> >+{
> >+struct drm_i915_gem_exec_object2 obj;
> >+struct drm_i915_gem_execbuffer2 eb;
> >+const uint32_t bbe = MI_BATCH_BUFFER_END;
> >+int order;
> >+
> >+/* no softpin => 4kB page size */
> >+if (!gem_has_softpin(fd))
> >+return 12;
> >+
> >+memset(&obj, 0, sizeof(obj));
> >+memset(&eb, 0, sizeof(eb));
> >+
> >+obj.handle = gem_create(fd, 4096);
> >+obj.flags = EXEC_OBJECT_PINNED | EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
> >+eb.buffers_ptr = to_user_pointer(&obj);
> >+eb.buffer_count = 1;
> >+gem_write(fd, obj.handle, 0, &bbe, sizeof(bbe));
>
> I think it will be safer to create a new context to execute this
> execbuffer. For a new context the address space should be empty reducing
> the chance that there is another object mapped by the caller of the
> helper function at the address we start testing.
AFAICU, that shouldn't matter. Object attributes are validated and possibly
-EINVAL is returned already before an eviction is possibly attempted. The
algorithm assumes an offset is valid if any error code other than -EINVAL
(including no error) is returned.
Thanks,
Janusz
>
> Otherwise it looks good to me.
>
> Vanshi
>
> >+
> >+for (order = 12; order < 64; order++) {
> >+obj.offset = 1ull << order;
> >+if (__gem_execbuf(fd, &eb) != -EINVAL)
> >+break;
> >+}
> >+igt_assert(obj.offset < gem_aperture_size(fd));
> >+
> >+gem_close(fd, obj.handle);
> >+igt_debug("minimum GTT alignment is %#llx\n", (long long)obj.offset);
> >+return order;
> >+}
> >+
> > /**
> > * gem_has_exec_fence:
> > * @fd: open i915 drm file descriptor
> >diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
> >index 03211c97..c8d57a7c 100644
> >--- a/lib/ioctl_wrappers.h
> >+++ b/lib/ioctl_wrappers.h
> >@@ -138,6 +138,8 @@ uint64_t gem_aperture_size(int fd);
> > uint64_t gem_global_aperture_size(int fd);
> > uint64_t gem_mappable_aperture_size(void);
> > bool gem_has_softpin(int fd);
> >+int gem_gtt_min_alignment_order(int fd);
> >+#define gem_gtt_min_alignment(fd) (1ull << gem_gtt_min_alignment_order(fd))
> > bool gem_has_exec_fence(int fd);
> >
> > /* check functions which auto-skip tests by calling igt_skip() */
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=
On Mon, Nov 04, 2019 at 02:19:21PM +0100, Takashi Iwai wrote: > On Mon, 04 Nov 2019 14:10:24 +0100, > Mika Westerberg wrote: > > > > Hi, > > > > On Mon, Nov 04, 2019 at 01:57:54PM +0100, Paul Menzel wrote: > > > Dear Linux folks, > > > > > > > > > On the Dell XPS 13 9380 with Debian Sid/unstable with Linux 5.3.7 > > > resuming0with Dell’s Thunderbolt TB16 dock connected, Linux spews > > > the errors below. > > > > I have this machine here so can try to reproduce it as well. > > > > > ``` > > > [0.00] Linux version 5.3.0-1-amd64 > > > (debian-ker...@lists.debian.org) (gcc version 9.2.1 20191008 (Debian > > > 9.2.1-9)) #1 SMP Debian 5.3.7-1 (2019-10-19) > > > […] > > > [1.596619] pci :00:1f.3: Adding to iommu group 12 > > > [ 14.536274] snd_hda_intel :00:1f.3: enabling device ( -> 0002) > > > [ 14.544100] snd_hda_intel :00:1f.3: bound :00:02.0 (ops > > > i915_audio_component_bind_ops [i915]) > > > [ 14.760751] input: HDA Intel PCH Headphone Mic as > > > /devices/pci:00/:00:1f.3/sound/card0/input16 > > > [ 14.760790] input: HDA Intel PCH HDMI as > > > /devices/pci:00/:00:1f.3/sound/card0/input17 > > > [ 156.614284] snd_hda_intel :00:1f.3: No response from codec, > > > disabling MSI: last cmd=0x20270503 > > > [ 157.622232] snd_hda_intel :00:1f.3: No response from codec, > > > resetting bus: last cmd=0x20270503 > > > [ 158.626371] snd_hda_intel :00:1f.3: No response from codec, > > > resetting bus: last cmd=0x20370503 > > > [ 159.634102] snd_hda_intel :00:1f.3: No response from codec, > > > resetting bus: last cmd=0x201f0500 > > > [ 161.678121] snd_hda_intel :00:1f.3: No response from codec, > > > resetting bus: last cmd=0x20270503 > > > [ 162.682272] snd_hda_intel :00:1f.3: No response from codec, > > > resetting bus: last cmd=0x20370503 > > > [ 163.694234] snd_hda_intel :00:1f.3: No response from codec, > > > resetting bus: last cmd=0x201f0500 > > > [ 165.730142] snd_hda_intel :00:1f.3: No response from codec, > > > resetting bus: last cmd=0x20270503 > > > […] > > > ``` > > > > > > In the bug report *[Intel Ice Lake, snd-hda-intel, HDMI] "No > > > response from codec" (after display hotplug?)* [1], note it’s a > > > different model, Takashi comments that this is a Thunderbolt or > > > i915 issue. > > > > :00:1f.3 is on PCH so not sure how it could be related to > > Thunderbolt, well or i915 for that matter. > > It's the HD-audio controller PCI device and both HDMI and onboard > codecs are on that bus. HDMI codec a shadow device of GPU, so it has > a strong dependency on i915 GPU driver. The power of HD-audio bus and > codec is controlled over DRM audio component ops, so the power-on must > have been notified to GPU side, but still something seems missing. > ANd, with the dock, the other parties come to play into the game, so > it becomes more complex... OK, thanks for explaining. Then I guess i915 may be related. However, that traffic for sure does not go over Thunderbolt fabric (PCIe and DP does). ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/execlists: Reset CSB pointers by mmio as well
== Series Details ==
Series: drm/i915/execlists: Reset CSB pointers by mmio as well
URL : https://patchwork.freedesktop.org/series/68945/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
238a6baf4572 drm/i915/execlists: Reset CSB pointers by mmio as well
-:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#9:
<0>[ 618.138490] i915_sel-56363d..1 673425465us : trace_ports: vecs0:
submit { 14de2:504, 0:0 }
-:39: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 582a6f90aa0d
("drm/i915/execlists: Add a paranoid flush of the CSB pointers upon reset")'
#39:
References: 582a6f90aa0d ("drm/i915/execlists: Add a paranoid flush of the CSB
pointers upon reset")
total: 1 errors, 1 warnings, 0 checks, 14 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=
On Mon, 04 Nov 2019 15:58:25 +0100, Mika Westerberg wrote: > > On Mon, Nov 04, 2019 at 02:19:21PM +0100, Takashi Iwai wrote: > > On Mon, 04 Nov 2019 14:10:24 +0100, > > Mika Westerberg wrote: > > > > > > Hi, > > > > > > On Mon, Nov 04, 2019 at 01:57:54PM +0100, Paul Menzel wrote: > > > > Dear Linux folks, > > > > > > > > > > > > On the Dell XPS 13 9380 with Debian Sid/unstable with Linux 5.3.7 > > > > resuming0with Dell’s Thunderbolt TB16 dock connected, Linux spews > > > > the errors below. > > > > > > I have this machine here so can try to reproduce it as well. > > > > > > > ``` > > > > [0.00] Linux version 5.3.0-1-amd64 > > > > (debian-ker...@lists.debian.org) (gcc version 9.2.1 20191008 (Debian > > > > 9.2.1-9)) #1 SMP Debian 5.3.7-1 (2019-10-19) > > > > […] > > > > [1.596619] pci :00:1f.3: Adding to iommu group 12 > > > > [ 14.536274] snd_hda_intel :00:1f.3: enabling device ( -> > > > > 0002) > > > > [ 14.544100] snd_hda_intel :00:1f.3: bound :00:02.0 (ops > > > > i915_audio_component_bind_ops [i915]) > > > > [ 14.760751] input: HDA Intel PCH Headphone Mic as > > > > /devices/pci:00/:00:1f.3/sound/card0/input16 > > > > [ 14.760790] input: HDA Intel PCH HDMI as > > > > /devices/pci:00/:00:1f.3/sound/card0/input17 > > > > [ 156.614284] snd_hda_intel :00:1f.3: No response from codec, > > > > disabling MSI: last cmd=0x20270503 > > > > [ 157.622232] snd_hda_intel :00:1f.3: No response from codec, > > > > resetting bus: last cmd=0x20270503 > > > > [ 158.626371] snd_hda_intel :00:1f.3: No response from codec, > > > > resetting bus: last cmd=0x20370503 > > > > [ 159.634102] snd_hda_intel :00:1f.3: No response from codec, > > > > resetting bus: last cmd=0x201f0500 > > > > [ 161.678121] snd_hda_intel :00:1f.3: No response from codec, > > > > resetting bus: last cmd=0x20270503 > > > > [ 162.682272] snd_hda_intel :00:1f.3: No response from codec, > > > > resetting bus: last cmd=0x20370503 > > > > [ 163.694234] snd_hda_intel :00:1f.3: No response from codec, > > > > resetting bus: last cmd=0x201f0500 > > > > [ 165.730142] snd_hda_intel :00:1f.3: No response from codec, > > > > resetting bus: last cmd=0x20270503 > > > > […] > > > > ``` > > > > > > > > In the bug report *[Intel Ice Lake, snd-hda-intel, HDMI] "No > > > > response from codec" (after display hotplug?)* [1], note it’s a > > > > different model, Takashi comments that this is a Thunderbolt or > > > > i915 issue. > > > > > > :00:1f.3 is on PCH so not sure how it could be related to > > > Thunderbolt, well or i915 for that matter. > > > > It's the HD-audio controller PCI device and both HDMI and onboard > > codecs are on that bus. HDMI codec a shadow device of GPU, so it has > > a strong dependency on i915 GPU driver. The power of HD-audio bus and > > codec is controlled over DRM audio component ops, so the power-on must > > have been notified to GPU side, but still something seems missing. > > ANd, with the dock, the other parties come to play into the game, so > > it becomes more complex... > > OK, thanks for explaining. Then I guess i915 may be related. However, > that traffic for sure does not go over Thunderbolt fabric (PCIe and DP > does). Well, here HDMI codec I meant is for both HDMI and DP. Its audio device is common for both display types. thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/5] drm/dsi: clean up DSI data type definitions
On Mon, Oct 28, 2019 at 05:00:43PM +0200, Jani Nikula wrote:
> Rename picture parameter set (it's a long packet, not a long write) and
> compression mode (it's not a DCS command) enumerations according to the
> DSI specification. Order the types according to the spec. Use tabs
> instead of spaces for indentation. Use all lower case for hex.
>
> Cc: Vandita Kulkarni
> Reviewed-by: Vandita Kulkarni
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_mipi_dsi.c | 4 ++--
> include/video/mipi_display.h | 10 +-
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index bd2498bbd74a..f237d80828c3 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -373,6 +373,7 @@ bool mipi_dsi_packet_format_is_short(u8 type)
> case MIPI_DSI_V_SYNC_END:
> case MIPI_DSI_H_SYNC_START:
> case MIPI_DSI_H_SYNC_END:
> + case MIPI_DSI_COMPRESSION_MODE:
> case MIPI_DSI_END_OF_TRANSMISSION:
> case MIPI_DSI_COLOR_MODE_OFF:
> case MIPI_DSI_COLOR_MODE_ON:
> @@ -387,7 +388,6 @@ bool mipi_dsi_packet_format_is_short(u8 type)
> case MIPI_DSI_DCS_SHORT_WRITE:
> case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
> case MIPI_DSI_DCS_READ:
> - case MIPI_DSI_DCS_COMPRESSION_MODE:
> case MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE:
> return true;
> }
> @@ -406,11 +406,11 @@ EXPORT_SYMBOL(mipi_dsi_packet_format_is_short);
> bool mipi_dsi_packet_format_is_long(u8 type)
> {
> switch (type) {
> - case MIPI_DSI_PPS_LONG_WRITE:
> case MIPI_DSI_NULL_PACKET:
> case MIPI_DSI_BLANKING_PACKET:
> case MIPI_DSI_GENERIC_LONG_WRITE:
> case MIPI_DSI_DCS_LONG_WRITE:
> + case MIPI_DSI_PICTURE_PARAMETER_SET:
> case MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20:
> case MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24:
> case MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16:
> diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
> index cba57a678daf..79fd71cf4934 100644
> --- a/include/video/mipi_display.h
> +++ b/include/video/mipi_display.h
> @@ -17,6 +17,9 @@ enum {
> MIPI_DSI_H_SYNC_START = 0x21,
> MIPI_DSI_H_SYNC_END = 0x31,
>
> + MIPI_DSI_COMPRESSION_MODE = 0x07,
> + MIPI_DSI_END_OF_TRANSMISSION= 0x08,
> +
> MIPI_DSI_COLOR_MODE_OFF = 0x02,
> MIPI_DSI_COLOR_MODE_ON = 0x12,
> MIPI_DSI_SHUTDOWN_PERIPHERAL= 0x22,
> @@ -35,18 +38,15 @@ enum {
>
> MIPI_DSI_DCS_READ = 0x06,
>
> - MIPI_DSI_DCS_COMPRESSION_MODE = 0x07,
> - MIPI_DSI_PPS_LONG_WRITE = 0x0A,
> -
> MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
>
> - MIPI_DSI_END_OF_TRANSMISSION= 0x08,
> -
> MIPI_DSI_NULL_PACKET= 0x09,
> MIPI_DSI_BLANKING_PACKET= 0x19,
> MIPI_DSI_GENERIC_LONG_WRITE = 0x29,
> MIPI_DSI_DCS_LONG_WRITE = 0x39,
>
> + MIPI_DSI_PICTURE_PARAMETER_SET = 0x0a,
> +
> MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20= 0x0c,
> MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24= 0x1c,
> MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16= 0x2c,
Looks good to me. I haven't specifically checked that the order matches
that in the specification, but given that it's not really ordered in any
sane way in the first place (or perhaps I'm too stupid to see the logic)
I don't really mind about the order.
Took me a while to find the specification. You might want to mention in
the commit message that some of these enumerations are only available in
the DSI 2 specification because I was looking at 1.2 first. Anyway, the
enumerations and names match what's in the spec, so:
Reviewed-by: Thierry Reding
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/5] drm/dsi: add missing DSI data types
On Mon, Oct 28, 2019 at 05:00:44PM +0200, Jani Nikula wrote:
> Add execute queue and compressed pixel stream packet data types for
> completeness.
>
> Cc: Vandita Kulkarni
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/drm_mipi_dsi.c | 2 ++
> include/video/mipi_display.h | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index f237d80828c3..3f33f02571fd 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -388,6 +388,7 @@ bool mipi_dsi_packet_format_is_short(u8 type)
> case MIPI_DSI_DCS_SHORT_WRITE:
> case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
> case MIPI_DSI_DCS_READ:
> + case MIPI_DSI_EXECUTE_QUEUE:
> case MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE:
> return true;
> }
> @@ -411,6 +412,7 @@ bool mipi_dsi_packet_format_is_long(u8 type)
> case MIPI_DSI_GENERIC_LONG_WRITE:
> case MIPI_DSI_DCS_LONG_WRITE:
> case MIPI_DSI_PICTURE_PARAMETER_SET:
> + case MIPI_DSI_COMPRESSED_PIXEL_STREAM:
> case MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20:
> case MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24:
> case MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR16:
> diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
> index 79fd71cf4934..6b6390dfa203 100644
> --- a/include/video/mipi_display.h
> +++ b/include/video/mipi_display.h
> @@ -37,6 +37,7 @@ enum {
> MIPI_DSI_DCS_SHORT_WRITE_PARAM = 0x15,
>
> MIPI_DSI_DCS_READ = 0x06,
> + MIPI_DSI_EXECUTE_QUEUE = 0x16,
>
> MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE = 0x37,
>
> @@ -46,6 +47,7 @@ enum {
> MIPI_DSI_DCS_LONG_WRITE = 0x39,
>
> MIPI_DSI_PICTURE_PARAMETER_SET = 0x0a,
> + MIPI_DSI_COMPRESSED_PIXEL_STREAM= 0x0b,
>
> MIPI_DSI_LOOSELY_PACKED_PIXEL_STREAM_YCBCR20= 0x0c,
> MIPI_DSI_PACKED_PIXEL_STREAM_YCBCR24= 0x1c,
Actually, it looks like the ordering is by lowest-significant nibble
first, then by highest-significant nibble, so maybe there's some logic
to this after all.
Hmm... that's mostly true, except for 0x07 and 0x08... anyway, the new
enumeration values and names match the specification, so:
Reviewed-by: Thierry Reding
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_shared: Use the supplied ring for smoketest
Allow the subtests that want to limit the test to a single engine, to
limit the test to a single engine.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
tests/i915/gem_ctx_shared.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c
index 6d8cbcce2..4d9ffafce 100644
--- a/tests/i915/gem_ctx_shared.c
+++ b/tests/i915/gem_ctx_shared.c
@@ -740,8 +740,12 @@ static void smoketest(int i915, unsigned ring, unsigned
timeout)
uint32_t *ptr;
nengine = 0;
- for_each_physical_engine(e, i915)
- engines[nengine++] = eb_ring(e);
+ if (ring == -1) {
+ for_each_physical_engine(e, i915)
+ engines[nengine++] = eb_ring(e);
+ } else {
+ engines[nengine++] = ring;
+ }
igt_require(nengine);
scratch = gem_create(i915, 4096);
--
2.24.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/5] drm/dsi: add missing DSI DCS commands
On Mon, Oct 28, 2019 at 05:00:45PM +0200, Jani Nikula wrote:
> Update from the DCS specification.
>
> Cc: Vandita Kulkarni
> Signed-off-by: Jani Nikula
> ---
> include/video/mipi_display.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
> index 6b6390dfa203..928f8c4b6658 100644
> --- a/include/video/mipi_display.h
> +++ b/include/video/mipi_display.h
> @@ -79,7 +79,9 @@ enum {
> enum {
> MIPI_DCS_NOP= 0x00,
> MIPI_DCS_SOFT_RESET = 0x01,
> + MIPI_DCS_GET_COMPRESSION_MODE = 0x03,
> MIPI_DCS_GET_DISPLAY_ID = 0x04,
> + MIPI_DCS_GET_ERROR_COUNT_ON_DSI = 0x05,
> MIPI_DCS_GET_RED_CHANNEL= 0x06,
> MIPI_DCS_GET_GREEN_CHANNEL = 0x07,
> MIPI_DCS_GET_BLUE_CHANNEL = 0x08,
> @@ -94,6 +96,8 @@ enum {
> MIPI_DCS_EXIT_SLEEP_MODE= 0x11,
> MIPI_DCS_ENTER_PARTIAL_MODE = 0x12,
> MIPI_DCS_ENTER_NORMAL_MODE = 0x13,
> + MIPI_DCS_GET_IMAGE_CHECKSUM_RGB = 0x14,
> + MIPI_DCS_GET_IMAGE_CHECKSUM_CT = 0x15,
> MIPI_DCS_EXIT_INVERT_MODE = 0x20,
> MIPI_DCS_ENTER_INVERT_MODE = 0x21,
> MIPI_DCS_SET_GAMMA_CURVE= 0x26,
> @@ -105,6 +109,7 @@ enum {
> MIPI_DCS_WRITE_LUT = 0x2D,
> MIPI_DCS_READ_MEMORY_START = 0x2E,
> MIPI_DCS_SET_PARTIAL_AREA = 0x30,
> + MIPI_DCS_SET_PARTIAL_COLUMNS= 0x31,
> MIPI_DCS_SET_SCROLL_AREA= 0x33,
> MIPI_DCS_SET_TEAR_OFF = 0x34,
> MIPI_DCS_SET_TEAR_ON= 0x35,
> @@ -114,7 +119,10 @@ enum {
> MIPI_DCS_ENTER_IDLE_MODE= 0x39,
> MIPI_DCS_SET_PIXEL_FORMAT = 0x3A,
> MIPI_DCS_WRITE_MEMORY_CONTINUE = 0x3C,
> + MIPI_DCS_SET_3D_CONTROL = 0x3D,
> MIPI_DCS_READ_MEMORY_CONTINUE = 0x3E,
> + MIPI_DCS_GET_3D_CONTROL = 0x3F,
> + MIPI_DCS_SET_VSYNC_TIMING = 0x40,
> MIPI_DCS_SET_TEAR_SCANLINE = 0x44,
> MIPI_DCS_GET_SCANLINE = 0x45,
> MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51, /* MIPI DCS 1.3 */
> @@ -126,7 +134,9 @@ enum {
> MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E,/* MIPI DCS 1.3 */
> MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F,/* MIPI DCS 1.3 */
> MIPI_DCS_READ_DDB_START = 0xA1,
> + MIPI_DCS_READ_PPS_START = 0xA2,
> MIPI_DCS_READ_DDB_CONTINUE = 0xA8,
> + MIPI_DCS_READ_PPS_CONTINUE = 0xA9,
> };
>
> /* MIPI DCS pixel formats */
> --
> 2.20.1
I only have a copy of DCS 1.2, which doesn't seem to have these values.
Let me see if I can find a more updated version.
Thierry
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: update rawclk also on resume
On Fri, Nov 01, 2019 at 04:20:24PM +0200, Jani Nikula wrote:
> Since CNP it's possible for rawclk to have two different values, 19.2
> and 24 MHz. If the value indicated by SFUSE_STRAP register is different
> from the power on default for PCH_RAWCLK_FREQ, we'll end up having a
> mismatch between the rawclk hardware and software states after
> suspend/resume. On previous platforms this used to work by accident,
> because the power on defaults worked just fine.
>
> Update the rawclk also on resume. The natural place to do this would be
> intel_modeset_init_hw(), however VLV/CHV need it done before
> intel_power_domains_init_hw(). Thus put it there even if it feels
> slightly out of place.
>
> v2: Call intel_update_rawclck() in intel_power_domains_init_hw() for all
> platforms (Ville).
>
> Reported-by: Shawn Lee
> Cc: Shawn Lee
> Cc: Ville Syrjala
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display_power.c | 3 +++
> drivers/gpu/drm/i915/i915_drv.c| 3 ---
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 707ac110e271..ce1b64f4dd44 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -5015,6 +5015,9 @@ void intel_power_domains_init_hw(struct
> drm_i915_private *i915, bool resume)
>
> power_domains->initializing = true;
>
> + /* Must happen before power domain init on VLV/CHV */
> + intel_update_rawclk(i915);
> +
> if (INTEL_GEN(i915) >= 11) {
> icl_display_core_init(i915, resume);
> } else if (IS_CANNONLAKE(i915)) {
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3340485c12e3..71944399dcfc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -296,9 +296,6 @@ static int i915_driver_modeset_probe(struct
> drm_i915_private *i915)
> if (ret)
> goto cleanup_vga_client;
>
> - /* must happen before intel_power_domains_init_hw() on VLV/CHV */
> - intel_update_rawclk(i915);
> -
> intel_power_domains_init_hw(i915, false);
>
> intel_csr_ucode_init(i915);
> --
> 2.20.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Reset CSB pointers by mmio as well
== Series Details ==
Series: drm/i915/execlists: Reset CSB pointers by mmio as well
URL : https://patchwork.freedesktop.org/series/68945/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7252 -> Patchwork_15121
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15121/index.html
Known issues
Here are the changes found in Patchwork_15121 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7252/fi-icl-u3/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15121/fi-icl-u3/igt@gem_exec_susp...@basic-s3.html
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-icl-u3: [DMESG-WARN][3] ([fdo#107724]) -> [PASS][4] +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7252/fi-icl-u3/igt@gem_exec_susp...@basic-s4-devices.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15121/fi-icl-u3/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_blt:
- fi-bsw-nick:[DMESG-FAIL][5] ([fdo#112176]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7252/fi-bsw-nick/igt@i915_selftest@live_blt.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15121/fi-bsw-nick/igt@i915_selftest@live_blt.html
* igt@kms_prop_blob@basic:
- {fi-icl-u4}:[DMESG-WARN][7] ([fdo#105602]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7252/fi-icl-u4/igt@kms_prop_b...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15121/fi-icl-u4/igt@kms_prop_b...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#112176]: https://bugs.freedesktop.org/show_bug.cgi?id=112176
Participating hosts (53 -> 44)
--
Additional (1): fi-hsw-4770r
Missing(10): fi-ilk-m540 fi-tgl-u2 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-gdg-551 fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7252 -> Patchwork_15121
CI-20190529: 20190529
CI_DRM_7252: 1971e2dbb8626482b7ed182d6e96a6810020b95e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5259: 6237a45d8699b2ccb4512e222ce6c94a1c77f83b @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15121: 238a6baf4572de2b3aad79732229834d1a475ec2 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
238a6baf4572 drm/i915/execlists: Reset CSB pointers by mmio as well
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15121/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_ctx_shared: Use the supplied ring for smoketest
Chris Wilson writes:
> Allow the subtests that want to limit the test to a single engine, to
> limit the test to a single engine.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> tests/i915/gem_ctx_shared.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c
> index 6d8cbcce2..4d9ffafce 100644
> --- a/tests/i915/gem_ctx_shared.c
> +++ b/tests/i915/gem_ctx_shared.c
> @@ -740,8 +740,12 @@ static void smoketest(int i915, unsigned ring, unsigned
> timeout)
> uint32_t *ptr;
>
> nengine = 0;
> - for_each_physical_engine(e, i915)
> - engines[nengine++] = eb_ring(e);
> + if (ring == -1) {
> + for_each_physical_engine(e, i915)
> + engines[nengine++] = eb_ring(e);
> + } else {
> + engines[nengine++] = ring;
> + }
> igt_require(nengine);
>
> scratch = gem_create(i915, 4096);
> --
> 2.24.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 i-g-t 0/4] Add support for testing writeback connectors
On Mon, Oct 21, 2019 at 09:54:48PM -0300, Rodrigo Siqueira wrote: > Hi, Hi Rodrigo, The whole series looks good to me, you can add my Reviewed-by tag if you want. Do you plan to push the patches into igt? Best regards, Liviu > > A couple of months ago, I updated and re-submitted a patchset made by > Brian Starkey and Liviu Dudau for adding a writeback connectors test to > IGT. It is important to highlight that DRM already have writeback > connectors support, which is a way to expose in DRM the hardware > functionality from display engines that allows writing back into memory > the result of the DE's composition of supported planes. > > After I resubmitted the patchset, Simon Ser provides a long and detailed > review for all of the patches (thanks Simon). As a result, I finally had > time to go through all the details and prepare this new version. Follows > some notes: > > 1. Patchset author > > Brian Starkey is the original author of this patchset, and I'm just > trying to upstream his changes. Note that during this patch submission, > the mail server from google going to overwrite Brian's mail by mine; > this happens on the mail server side for avoiding malicious users to > send emails as someone else. Note that I could spend time figuring out > how to fix it, but I think this is not worth since I can fix it during > the merge process (if it got accepted). > > 2. Drop the clone commits from the series > > After Simon's review, we decided to drop the last two patches of the > original series since it was related to cloning output, and VKMS does > not support it yet. However, after we finish with this series, I can try > to take a look at this feature or maybe propose it as a GSoC/Outreachy > project. > > 3. Changes > > Most of the changes happened in the second patch. > > Thanks > > Brian Starkey (4): > lib/igt_kms: Add writeback support > kms_writeback: Add initial writeback tests > lib: Add function to hash a framebuffer > kms_writeback: Add writeback-check-output > > lib/igt_fb.c | 68 +++ > lib/igt_fb.h | 2 + > lib/igt_kms.c | 59 ++ > lib/igt_kms.h | 6 + > tests/Makefile.sources | 1 + > tests/kms_writeback.c | 413 + > tests/meson.build | 1 + > 7 files changed, 550 insertions(+) > create mode 100644 tests/kms_writeback.c > > -- > 2.23.0 -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm/i915/dsc: make parameter arrays const
== Series Details ==
Series: series starting with [v2,1/4] drm/i915/dsc: make parameter arrays const
URL : https://patchwork.freedesktop.org/series/68947/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7252 -> Patchwork_15122
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15122/index.html
Known issues
Here are the changes found in Patchwork_15122 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@bad-flink:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7252/fi-icl-u3/igt@gem_flink_ba...@bad-flink.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15122/fi-icl-u3/igt@gem_flink_ba...@bad-flink.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-icl-u2: [PASS][3] -> [FAIL][4] ([fdo#109570])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7252/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15122/fi-icl-u2/igt@kms_chamel...@hdmi-crc-fast.html
Possible fixes
* igt@i915_selftest@live_blt:
- fi-bsw-nick:[DMESG-FAIL][5] ([fdo#112176]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7252/fi-bsw-nick/igt@i915_selftest@live_blt.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15122/fi-bsw-nick/igt@i915_selftest@live_blt.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][7] ([fdo#111407]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7252/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15122/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@prime_busy@basic-wait-before-default:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7252/fi-icl-u3/igt@prime_b...@basic-wait-before-default.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15122/fi-icl-u3/igt@prime_b...@basic-wait-before-default.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109570]: https://bugs.freedesktop.org/show_bug.cgi?id=109570
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#54]: https://bugs.freedesktop.org/show_bug.cgi?id=54
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#112176]: https://bugs.freedesktop.org/show_bug.cgi?id=112176
Participating hosts (53 -> 44)
--
Additional (1): fi-hsw-4770r
Missing(10): fi-ilk-m540 fi-tgl-u2 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-gdg-551 fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7252 -> Patchwork_15122
CI-20190529: 20190529
CI_DRM_7252: 1971e2dbb8626482b7ed182d6e96a6810020b95e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5259: 6237a45d8699b2ccb4512e222ce6c94a1c77f83b @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15122: b16942c497da373471965a7690a85984f40fa6f7 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b16942c497da drm/i915/dsc: rename functions for consistency
2af3d02f2d66 drm/i915/dsc: split out encoder specific parts from DSC compute
params
2a4d66cb0f24 drm/i915/dsc: clean up rc parameter table access
cf1310fbefdc drm/i915/dsc: make parameter arrays const
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15122/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Display WA2006604312 is needed from ICL onwards
On Mon, Nov 04, 2019 at 01:50:09PM +0200, Juha-Pekka Heikkila wrote:
> WA2006604312 is listed for devices from Icelake onward.
The "Project" column on bspec #33450 does list EHL, however I don't see
it actually listed on the dedicated EHL WA page (bspec #33451) or the
TGL WA page (bspec #52890).
I'm not sure which page we're supposed to trust for EHL (personally I'd
trust the EHL page more than the ICL page when it comes to EHL), but it
doesn't look like this should apply to TGL/gen12 as far as I can see?
Matt
>
> Signed-off-by: Juha-Pekka Heikkila
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e29e80ae5698..71ac4fe5fb47 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5981,7 +5981,7 @@ static bool needs_scalerclk_wa(struct drm_i915_private
> *dev_priv,
> const struct intel_crtc_state *crtc_state)
> {
> /* Wa_2006604312:icl */
> - if (crtc_state->scaler_state.scaler_users > 0 && IS_ICELAKE(dev_priv))
> + if (crtc_state->scaler_state.scaler_users > 0 && INTEL_GEN(dev_priv) >=
> 11)
> return true;
>
> return false;
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/todo: Add entry to remove load/unload hooks
On Thu, Oct 24, 2019 at 12:35:52PM +0200, Thierry Reding wrote: > On Wed, Oct 23, 2019 at 04:49:53PM +0200, Daniel Vetter wrote: > > They're midlayer, broken, and because of the old gunk, we can't fix > > them. For examples see the various checks in drm_mode_object.c against > > dev->registered, which cannot be enforced if the driver still uses the > > load hook. > > > > Unfortunately our biggest driver still uses load/unload, so this would > > be really great to get fixed. > > > > Cc: Alex Deucher > > Cc: Harry Wentland > > Signed-off-by: Daniel Vetter > > --- > > Documentation/gpu/todo.rst | 17 + > > 1 file changed, 17 insertions(+) > > Reminds me that I need to still do that for Tegra: > > Reviewed-by: Thierry Reding Both patches applied, thanks for taking a look. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v5 3/4] tests/gem_exec_reloc: Calculate offsets from minimum GTT alignment
The basic-range subtest assumes 4kB alignment while calculating softpin
offsets. On future backends with possibly larger minimum page sizes
the test will fail as a half of calculated offsets to be tested will be
incorrectly aligned.
Replace hardcoded constants corresponding to the assumed 4kB page size
with variables initialized with actual minimum GTT alignment size and
order.
v2: Simplify the code by reversing the size->order conversion,
- drop irrelevant modifications of requested object sizes.
v3: Reword commit message after removal of patch "Don't filter out
addresses on full PPGTT" from the series,
- initialize page size order with an actual minimum returned by a new
helper (inspired by Chris).
v4: Update the helper name, use the term 'minimum GTT alignment' across
the change, adjust variable names,
- refresh the commit message on top of the reintroduced patch that
fixes invalid offsets incorrectly assumed as occupied.
Signed-off-by: Janusz Krzysztofik
Cc: Katarzyna Dec
Cc: Stuart Summers
Reviewed-by: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index e46a4df7..a2a04343 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -521,14 +521,16 @@ static void basic_range(int fd, unsigned flags)
uint64_t gtt_size = gem_aperture_size(fd);
const uint32_t bbe = MI_BATCH_BUFFER_END;
igt_spin_t *spin = NULL;
+ int alignment_order = gem_gtt_min_alignment_order(fd);
+ uint64_t alignment = 1ull << alignment_order;
int count, n, err;
igt_require(gem_has_softpin(fd));
- for (count = 12; gtt_size >> (count + 1); count++)
+ for (count = alignment_order; gtt_size >> (count + 1); count++)
;
- count -= 12;
+ count -= alignment_order;
memset(obj, 0, sizeof(obj));
memset(reloc, 0, sizeof(reloc));
@@ -537,7 +539,7 @@ static void basic_range(int fd, unsigned flags)
n = 0;
for (int i = 0; i <= count; i++) {
obj[n].handle = gem_create(fd, 4096);
- obj[n].offset = (1ull << (i + 12)) - 4096;
+ obj[n].offset = (1ull << (i + alignment_order)) - alignment;
obj[n].offset = gen8_canonical_address(obj[n].offset);
obj[n].flags = EXEC_OBJECT_PINNED |
EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
err = gem_gtt_validate_object(fd, &obj[n]);
@@ -558,7 +560,7 @@ static void basic_range(int fd, unsigned flags)
}
for (int i = 1; i < count; i++) {
obj[n].handle = gem_create(fd, 4096);
- obj[n].offset = 1ull << (i + 12);
+ obj[n].offset = 1ull << (i + alignment_order);
obj[n].offset = gen8_canonical_address(obj[n].offset);
obj[n].flags = EXEC_OBJECT_PINNED |
EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
err = gem_gtt_validate_object(fd, &obj[n]);
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v5 0/4] Calculate softpin offsets from minimum GTT alignment
Some tests assume 4kB page size while using softpin. That assumption may be wrong on future GEM backends with possibly larger minimum page sizes. As a result, those tests may either fail on softpin at offsets which are incorrectly aligned, may silently skip such incorrectly aligned addresses assuming them occupied by other users, or may always succeed when examining invalid use patterns. Provide a helper function that detects minimum page size and returns the size order. Use it in test which perform softpin to calculate offsets suitable for actually used backing store. Changelog: v2: Don't skip failing offsets only when on full PPGTT, - simplify the code by reversing the size->order conversion, - drop irrelevant modifications of requested object sizes. v3: Drop patch 1/2 "Don't filter out addresses when on PPGTT" - I don't know how to detect if the kernel is interfering with the user's GTT, - introduce patch 1/4 "lib: Move redundant local helpers to lib/", subsequent patch will use the helper, - introduce patch 2/4 "lib: Add GEM minimum page size helper", subsequent patches will use the new helper (inspired by Chris), - in former patch 2/2, now 3/4, initialize page size order with an actual minimum returned by the new helper (inspired by Chris), - add a new fix for gem_ctx_shared test (patch 4/4). v4: Rename the helper, use 'minimum GTT alignment' term across the changes (Chris), - update variable names accordingly, - use error numbers to distinguish between invalid offsets and addresses occupied by other users, then - simplify the helper code (Chris), - drop no longer required patch 1/4 "lib: Move redundant local helpers to lib/", - reintroduce former patch 1/2 as 1/4 "tests/gem_exec_reloc: Don't filter out invalid addresses" with the former not on full PPGTT requirement for skipping now replaced with error code checking. v5: Put the helper code under lib/i915/, not in lib/ioctl_wrappers.c (Chris), - validate objects with an invalid reloc applied so execbuf requests called only for validation purposes are actually not emitted to GPU (Chris), - move object validation code to a separate helper, - promote the former patch 2/4 as 1/4 so the new helper is available for use by the former patch 1/4, now 2/4, - silently skip only those offsets which have been explicitly reported as overlapping with shared GTT reserved space, not simply all which raise failures other than -EINVAL (Chris), - as an implementation of moving the probe out of line so it's not easily confused with the central point of the test (Chris), use object validation library helper just introduced, - name the variable 'stride', not 'alignment', it better reflects its purpose (Chris). Janusz Krzysztofik (4): lib/i915: Add minimum GTT alignment helper tests/gem_exec_reloc: Don't filter out invalid addresses tests/gem_exec_reloc: Calculate offsets from minimum GTT alignment tests/gem_ctx_shared: Align objects using minimum GTT alignment lib/Makefile.sources| 2 + lib/i915/gem_gtt_topology.c | 118 lib/i915/gem_gtt_topology.h | 36 +++ lib/meson.build | 1 + tests/i915/gem_ctx_shared.c | 7 ++- tests/i915/gem_exec_reloc.c | 31 ++ 6 files changed, 180 insertions(+), 15 deletions(-) create mode 100644 lib/i915/gem_gtt_topology.c create mode 100644 lib/i915/gem_gtt_topology.h -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v5 1/4] lib/i915: Add minimum GTT alignment helper
Some tests assume 4kB offset alignment while using softpin. That
assumption may be wrong on future GEM backends with possibly larger
minimum page sizes. As a result, those tests may either fail on
softpin at offsets which are incorrectly aligned, may silently skip
such incorrectly aligned addresses assuming them occupied by other
users, or may always succeed when examining invalid use patterns.
Provide a helper function that detects minimum GTT alignment. Tests
may use it to calculate softpin offsets valid on actually used backing
store.
Also expose a new object validation helper just created, it may be
useful for checking if a shared GTT address is not reserved, for
example.
v2: Rename the helper, use 'minimum GTT alignment' term across the
change (Chris),
- use error numbers to distinguish between invalid offsets and
addresses occupied by other users,
- simplify the code (Chris).
v3: Put the code under lib/i915/, not in lib/ioctl_wrappers.c (Chris),
- validate objects with an invalid reloc applied so execbuf requests
called only for validation purposes are actually not emitted to GPU
(Chris),
- move object validation code to a separate helper.
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Stuart Summers
---
lib/Makefile.sources| 2 +
lib/i915/gem_gtt_topology.c | 118
lib/i915/gem_gtt_topology.h | 36 +++
lib/meson.build | 1 +
4 files changed, 157 insertions(+)
create mode 100644 lib/i915/gem_gtt_topology.c
create mode 100644 lib/i915/gem_gtt_topology.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 34e0c012..975200fc 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -7,6 +7,8 @@ lib_source_list = \
i915/gem_context.h \
i915/gem_engine_topology.c \
i915/gem_engine_topology.h \
+ i915/gem_gtt_topology.c \
+ i915/gem_gtt_topology.h \
i915/gem_scheduler.c\
i915/gem_scheduler.h\
i915/gem_submission.c \
diff --git a/lib/i915/gem_gtt_topology.c b/lib/i915/gem_gtt_topology.c
new file mode 100644
index ..427f0c14
--- /dev/null
+++ b/lib/i915/gem_gtt_topology.c
@@ -0,0 +1,118 @@
+/*
+ * Copyright © 2019 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+
+#include "i915_drm.h"
+
+#include "igt_core.h"
+#include "intel_reg.h"
+#include "ioctl_wrappers.h"
+
+#include "i915/gem_gtt_topology.h"
+
+/**
+ * gem_gtt_validate_object:
+ * @fd: open i915 drm file descriptor
+ *
+ * This function verifies validity of GEM object attributes. For example,
+ * it is useful for validation of the object softpin offset.
+ *
+ * Returns:
+ * 0 on success, negative error code returned by GEM_EXECBUF IOCTL on failure
+ */
+
+int gem_gtt_validate_object(int fd, struct drm_i915_gem_exec_object2 *obj)
+{
+ struct drm_i915_gem_relocation_entry reloc;
+ struct drm_i915_gem_execbuffer2 execbuf;
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uintptr_t old_reloc;
+ int old_count, err;
+
+ memset(&reloc, 0, sizeof(reloc));
+ memset(&execbuf, 0, sizeof(execbuf));
+
+ /* use invalid reloc to save request emission */
+ old_reloc = obj->relocs_ptr;
+ old_count = obj->relocation_count;
+ obj->relocs_ptr = to_user_pointer(&reloc);
+ obj->relocation_count = 1;
+ gem_write(fd, obj->handle, 0, &bbe, sizeof(bbe));
+
+ execbuf.buffers_ptr = to_user_pointer(obj);
+ execbuf.buffer_count = 1;
+
+ err = __gem_execbuf(fd, &execbuf);
+ if (err == -ENOENT) {
+ /* suppress -ENOENT we get for invalid reloc handle */
+ err = 0;
+ }
+
+ obj->relocs_ptr = old_reloc;
+ obj->relocation_count = old_count;
+
+ return err;
+}
[Intel-gfx] [PATCH i-g-t v5 4/4] tests/gem_ctx_shared: Align objects using minimum GTT alignment
exec-shared-gtt-* subtests use hardcoded values for object size and softpin offset, based on 4kB GTT alignment assumption. That may result in those subtests failing when run on future backing stores with possibly larger minimum page sizes. Replace hardcoded constants with values calculated from minimum GTT alignment of actual backing store the test is running on. v2: Update helper name, use 'minimum GTT alignment' term across the change, adjust variable name. v3: Name the variable 'stride', not 'alignment', it better reflects its purpose (Chris). Signed-off-by: Janusz Krzysztofik Reviewed-by: Chris Wilson --- tests/i915/gem_ctx_shared.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c index f7852482..cb726b4d 100644 --- a/tests/i915/gem_ctx_shared.c +++ b/tests/i915/gem_ctx_shared.c @@ -41,6 +41,7 @@ #include "igt_rand.h" #include "igt_vgem.h" #include "sync_file.h" +#include "i915/gem_gtt_topology.c" #define LO 0 #define HI 1 @@ -195,6 +196,7 @@ static void exec_shared_gtt(int i915, unsigned int ring) uint32_t scratch, *s; uint32_t batch, cs[16]; uint64_t offset; + uint64_t stride; int i; gem_require_ring(i915, ring); @@ -203,7 +205,8 @@ static void exec_shared_gtt(int i915, unsigned int ring) clone = gem_context_clone(i915, 0, I915_CONTEXT_CLONE_VM, 0); /* Find a hole big enough for both objects later */ - scratch = gem_create(i915, 16384); + stride = 2 * gem_gtt_min_alignment(i915); + scratch = gem_create(i915, 2 * stride); gem_write(i915, scratch, 0, &bbe, sizeof(bbe)); obj.handle = scratch; gem_execbuf(i915, &execbuf); @@ -246,7 +249,7 @@ static void exec_shared_gtt(int i915, unsigned int ring) gem_write(i915, batch, 0, cs, sizeof(cs)); obj.handle = batch; - obj.offset += 8192; /* make sure we don't cause an eviction! */ + obj.offset += stride; /* make sure we don't cause an eviction! */ execbuf.rsvd1 = clone; if (gen > 3 && gen < 6) execbuf.flags |= I915_EXEC_SECURE; -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v5 2/4] tests/gem_exec_reloc: Don't filter out invalid addresses
Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
addresses for !ppgtt") introduced filtering of addresses possibly
occupied by other users of shared GTT. Unfortunately, that filtering
doesn't distinguish between actually occupied addresses and otherwise
invalid softpin offsets. If incorrect GTT alignment will be assumed
when running on future backends with possibly larger minimum page
sizes, a half of calculated offsets to be tested will be incorrectly
detected as occupied by other users and silently skipped instead of
reported as a problem. That will significantly distort the intended
test pattern.
Filter out failing addresses only if reported as occupied.
v2: Skip unavailable addresses only when not running on full PPGTT.
v3: Replace the not on full PPGTT requirement for skipping with error
code checking.
v4: Silently skip only those offsets which have been explicitly
reported as overlapping with shared GTT reserved space, not simply
all which raise failures other than -EINVAL (Chris),
- as an implementation of moving the probe out of line so it's not
easily confused with the central point of the test (Chris), use
object validation library helper just introduced.
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index fdd9661d..e46a4df7 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -23,6 +23,7 @@
#include "igt.h"
#include "igt_dummyload.h"
+#include "i915/gem_gtt_topology.c"
IGT_TEST_DESCRIPTION("Basic sanity check of execbuf-ioctl relocations.");
@@ -520,7 +521,7 @@ static void basic_range(int fd, unsigned flags)
uint64_t gtt_size = gem_aperture_size(fd);
const uint32_t bbe = MI_BATCH_BUFFER_END;
igt_spin_t *spin = NULL;
- int count, n;
+ int count, n, err;
igt_require(gem_has_softpin(fd));
@@ -539,11 +540,12 @@ static void basic_range(int fd, unsigned flags)
obj[n].offset = (1ull << (i + 12)) - 4096;
obj[n].offset = gen8_canonical_address(obj[n].offset);
obj[n].flags = EXEC_OBJECT_PINNED |
EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
- gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
- execbuf.buffers_ptr = to_user_pointer(&obj[n]);
- execbuf.buffer_count = 1;
- if (__gem_execbuf(fd, &execbuf))
+ err = gem_gtt_validate_object(fd, &obj[n]);
+ if (err) {
+ /* Iff using a shared GTT, some of it may be reserved */
+ igt_assert_eq(err, -ENOSPC);
continue;
+ }
igt_debug("obj[%d] handle=%d, address=%llx\n",
n, obj[n].handle, (long long)obj[n].offset);
@@ -559,11 +561,12 @@ static void basic_range(int fd, unsigned flags)
obj[n].offset = 1ull << (i + 12);
obj[n].offset = gen8_canonical_address(obj[n].offset);
obj[n].flags = EXEC_OBJECT_PINNED |
EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
- gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
- execbuf.buffers_ptr = to_user_pointer(&obj[n]);
- execbuf.buffer_count = 1;
- if (__gem_execbuf(fd, &execbuf))
+ err = gem_gtt_validate_object(fd, &obj[n]);
+ if (err) {
+ /* Iff using a shared GTT, some of it may be reserved */
+ igt_assert_eq(err, -ENOSPC);
continue;
+ }
igt_debug("obj[%d] handle=%d, address=%llx\n",
n, obj[n].handle, (long long)obj[n].offset);
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] snd_hda_intel 0000:00:1f.3: No response from codec, resetting bus: last cmd=
Hi Paul, On Mon, Nov 04, 2019 at 01:57:54PM +0100, Paul Menzel wrote: > On the Dell XPS 13 9380 with Debian Sid/unstable with Linux 5.3.7 > resuming0with Dell’s Thunderbolt TB16 dock connected, Linux spews > the errors below. > > ``` > [0.00] Linux version 5.3.0-1-amd64 (debian-ker...@lists.debian.org) > (gcc version 9.2.1 20191008 (Debian 9.2.1-9)) #1 SMP Debian 5.3.7-1 > (2019-10-19) > […] > [1.596619] pci :00:1f.3: Adding to iommu group 12 > [ 14.536274] snd_hda_intel :00:1f.3: enabling device ( -> 0002) > [ 14.544100] snd_hda_intel :00:1f.3: bound :00:02.0 (ops > i915_audio_component_bind_ops [i915]) > [ 14.760751] input: HDA Intel PCH Headphone Mic as > /devices/pci:00/:00:1f.3/sound/card0/input16 > [ 14.760790] input: HDA Intel PCH HDMI as > /devices/pci:00/:00:1f.3/sound/card0/input17 > [ 156.614284] snd_hda_intel :00:1f.3: No response from codec, disabling > MSI: last cmd=0x20270503 > [ 157.622232] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x20270503 > [ 158.626371] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x20370503 > [ 159.634102] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x201f0500 > [ 161.678121] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x20270503 > [ 162.682272] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x20370503 > [ 163.694234] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x201f0500 > [ 165.730142] snd_hda_intel :00:1f.3: No response from codec, resetting > bus: last cmd=0x20270503 > […] > ``` Debian's 5.3.0-1-amd64 has a corrupted signature on the snd-hda-codec-hdmi module which prevents the module from loading and causes these errors. Further details here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942881 Workaround: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942881#20 -- Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] lockdep: add might_lock_nested()
Necessary to annotate functions where we might acquire a
mutex_lock_nested() or similar. Needed by i915.
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Daniel Vetter
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: linux-ker...@vger.kernel.org
---
include/linux/lockdep.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index e0eca94e58c8..c4155436e6fc 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -628,6 +628,13 @@ do {
\
lock_acquire(&(lock)->dep_map, 0, 0, 1, 1, NULL, _THIS_IP_);\
lock_release(&(lock)->dep_map, 0, _THIS_IP_); \
} while (0)
+# define might_lock_nested(lock, subclass) \
+do { \
+ typecheck(struct lockdep_map *, &(lock)->dep_map); \
+ lock_acquire(&(lock)->dep_map, subclass, 0, 1, 1, NULL, \
+_THIS_IP_);\
+ lock_release(&(lock)->dep_map, 0, _THIS_IP_); \
+} while (0)
#define lockdep_assert_irqs_enabled() do {\
WARN_ONCE(debug_locks && !current->lockdep_recursion && \
@@ -650,6 +657,7 @@ do {
\
#else
# define might_lock(lock) do { } while (0)
# define might_lock_read(lock) do { } while (0)
+# define might_lock_nested(lock, subclass) do { } while (0)
# define lockdep_assert_irqs_enabled() do { } while (0)
# define lockdep_assert_irqs_disabled() do { } while (0)
# define lockdep_assert_in_irq() do { } while (0)
--
2.24.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Switch obj->mm.lock lockdep annotations on its head
The trouble with having a plain nesting flag for locks which do not
naturally nest (unlike block devices and their partitions, which is
the original motivation for nesting levels) is that lockdep will
never spot a true deadlock if you screw up.
This patch is an attempt at trying better, by highlighting a bit more
the actual nature of the nesting that's going on. Essentially we have
two kinds of objects:
- objects without pages allocated, which cannot be on any lru and are
hence inaccessible to the shrinker.
- objects which have pages allocated, which are on an lru, and which
the shrinker can decide to throw out.
For the former type of object, memory allcoations while holding
obj->mm.lock are permissible. For the latter they are not. And
get/put_pages transitions between the two types of objects.
This is still not entirely fool-proof since the rules might chance.
But as long as we run such a code ever at runtime lockdep should be
able to observe the inconsistency and complain (like with any other
lockdep class that we've split up in multiple classes). But there are
a few clear benefits:
- We can drop the nesting flag parameter from
__i915_gem_object_put_pages, because that function by definition is
never going allocate memory, and calling it on an object which
doesn't have its pages allocated would be a bug.
- We strictly catch more bugs, since there's not only one place in the
entire tree which is annotated with the special class. All the
other places that had explicit lockdep nesting annotations we're now
going to leave up to lockdep again.
- Specifically this catches stuff like calling get_pages from
put_pages (which isn't really a good idea, if we can call put_pages
so could the shrinker). I've seen patches do exactly that.
Of course I fully expect CI will show me for the fool I am with this
one here :-)
v2: There can only be one (lockdep only has a cache for the first
subclass, not for deeper ones, and we don't want to make these locks
even slower). Still separate enums for better documentation.
Real fix: don forget about phys objs and pin_map(), and fix the
shrinker to have the right annotations ... silly me.
v3: Forgot usertptr too ...
v4: Improve comment for pages_pin_count, drop the IMPORTANT comment
and instead prime lockdep (Chris).
v5: Appease checkpatch, no double empty lines (Chris)
v6: More rebasing over selftest changes. Also somehow I forgot to
push this patch :-/
Also format comments consistently while at it.
Cc: Chris Wilson
Cc: "Tang, CQ"
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson (v5)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 17 ++---
.../gpu/drm/i915/gem/i915_gem_object_types.h| 6 +-
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 9 -
drivers/gpu/drm/i915/gem/i915_gem_phys.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c| 5 ++---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 4 ++--
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 14 +++---
.../drm/i915/selftests/intel_memory_region.c| 4 ++--
9 files changed, 48 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index a50296cce0d8..078d515d72c0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -22,6 +22,8 @@
*
*/
+#include
+
#include "display/intel_frontbuffer.h"
#include "gt/intel_gt.h"
#include "i915_drv.h"
@@ -52,6 +54,14 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
{
__mutex_init(&obj->mm.lock, "obj->mm.lock", key);
+ if (IS_ENABLED(CONFIG_LOCKDEP)) {
+ mutex_lock_nested(&obj->mm.lock, I915_MM_GET_PAGES);
+ fs_reclaim_acquire(GFP_KERNEL);
+ might_lock(&obj->mm.lock);
+ fs_reclaim_release(GFP_KERNEL);
+ mutex_unlock(&obj->mm.lock);
+ }
+
spin_lock_init(&obj->vma.lock);
INIT_LIST_HEAD(&obj->vma.list);
@@ -186,7 +196,7 @@ static void __i915_gem_free_objects(struct drm_i915_private
*i915,
GEM_BUG_ON(!list_empty(&obj->lut_list));
atomic_set(&obj->mm.pages_pin_count, 0);
- __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
+ __i915_gem_object_put_pages(obj);
GEM_BUG_ON(i915_gem_object_has_pages(obj));
bitmap_free(obj->bit_17);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 458cd51331f1..edaf7126a84d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -319,11 +319,22 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object
*obj)
enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
[Intel-gfx] [PATCH 3/3] drm/i915: use might_lock_nested in get_pages annotation
So strictly speaking the existing annotation is also ok, because we
have a chain of
obj->mm.lock#I915_MM_GET_PAGES -> fs_reclaim -> obj->mm.lock
(the shrinker cannot get at an object while we're in get_pages, hence
this is safe). But it's confusing, so try to take the right subclass
of the lock.
This does a bit reduce our lockdep based checking, but then it's also
less fragile, in case we ever change the nesting around.
Signed-off-by: Daniel Vetter
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 36 +++---
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index edaf7126a84d..e5750d506cc9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -271,10 +271,27 @@ void __i915_gem_object_set_pages(struct
drm_i915_gem_object *obj,
int i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
+enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
+ I915_MM_NORMAL = 0,
+ /*
+* Only used by struct_mutex, when called "recursively" from
+* direct-reclaim-esque. Safe because there is only every one
+* struct_mutex in the entire system.
+*/
+ I915_MM_SHRINKER = 1,
+ /*
+* Used for obj->mm.lock when allocating pages. Safe because the object
+* isn't yet on any LRU, and therefore the shrinker can't deadlock on
+* it. As soon as the object has pages, obj->mm.lock nests within
+* fs_reclaim.
+*/
+ I915_MM_GET_PAGES = 1,
+};
+
static inline int __must_check
i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
{
- might_lock(&obj->mm.lock);
+ might_lock_nested(&obj->mm.lock, I915_MM_GET_PAGES);
if (atomic_inc_not_zero(&obj->mm.pages_pin_count))
return 0;
@@ -317,23 +334,6 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object
*obj)
__i915_gem_object_unpin_pages(obj);
}
-enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */
- I915_MM_NORMAL = 0,
- /*
-* Only used by struct_mutex, when called "recursively" from
-* direct-reclaim-esque. Safe because there is only every one
-* struct_mutex in the entire system.
-*/
- I915_MM_SHRINKER = 1,
- /*
-* Used for obj->mm.lock when allocating pages. Safe because the object
-* isn't yet on any LRU, and therefore the shrinker can't deadlock on
-* it. As soon as the object has pages, obj->mm.lock nests within
-* fs_reclaim.
-*/
- I915_MM_GET_PAGES = 1,
-};
-
int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
void i915_gem_object_truncate(struct drm_i915_gem_object *obj);
void i915_gem_object_writeback(struct drm_i915_gem_object *obj);
--
2.24.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
Full audit of everyone:
- i915, radeon, amdgpu should be clean per their maintainers.
- vram helpers should be fine, they don't do command submission, so
really no business holding struct_mutex while doing copy_*_user. But
I haven't checked them all.
- panfrost seems to dma_resv_lock only in panfrost_job_push, which
looks clean.
- v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
copying from/to userspace happens all in v3d_lookup_bos which is
outside of the critical section.
- vmwgfx has a bunch of ioctls that do their own copy_*_user:
- vmw_execbuf_process: First this does some copies in
vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
Then comes the usual ttm reserve/validate sequence, then actual
submission/fencing, then unreserving, and finally some more
copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
details, but looks all safe.
- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
seen, seems to only create a fence and copy it out.
- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
found there.
Summary: vmwgfx seems to be fine too.
- virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
copying from userspace before even looking up objects through their
handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
- qxl only has qxl_execbuffer_ioctl, which calls into
qxl_process_single_command. There's a lovely comment before the
__copy_from_user_inatomic that the slowpath should be copied from
i915, but I guess that never happened. Try not to be unlucky and get
your CS data evicted between when it's written and the kernel tries
to read it. The only other copy_from_user is for relocs, but those
are done before qxl_release_reserve_list(), which seems to be the
only thing reserving buffers (in the ttm/dma_resv sense) in that
code. So looks safe.
- A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
everywhere and needs to be fixed up.
v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
dma_resv lock of a different object already. Christian mentioned that
ttm core does this too for ghost objects. intel-gfx-ci highlighted
that i915 has similar issues.
Unfortunately we can't do this in the usual module init functions,
because kernel threads don't have an ->mm - we have to wait around for
some user thread to do this.
Solution is to spawn a worker (but only once). It's horrible, but it
works.
v3: We can allocate mm! (Chris). Horrible worker hack out, clean
initcall solution in.
v4: Annotate with __init (Rob Herring)
Cc: Rob Herring
Cc: Alex Deucher
Cc: Christian König
Cc: Chris Wilson
Cc: Thomas Zimmermann
Cc: Rob Herring
Cc: Tomeu Vizoso
Cc: Eric Anholt
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Ben Skeggs
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
Reviewed-by: Christian König
Reviewed-by: Chris Wilson
Tested-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/dma-buf/dma-resv.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 709002515550..a05ff542be22 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -34,6 +34,7 @@
#include
#include
+#include
/**
* DOC: Reservation Object Overview
@@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
kfree_rcu(list, rcu);
}
+#if IS_ENABLED(CONFIG_LOCKDEP)
+static void __init dma_resv_lockdep(void)
+{
+ struct mm_struct *mm = mm_alloc();
+ struct dma_resv obj;
+
+ if (!mm)
+ return;
+
+ dma_resv_init(&obj);
+
+ down_read(&mm->mmap_sem);
+ ww_mutex_lock(&obj.lock, NULL);
+ fs_reclaim_acquire(GFP_KERNEL);
+ fs_reclaim_release(GFP_KERNEL);
+ ww_mutex_unlock(&obj.lock);
+ up_read(&mm->mmap_sem);
+
+ mmput(mm);
+}
+subsys_initcall(dma_resv_lockdep);
+#endif
+
/**
* dma_resv_init - initialize a reservation object
* @obj: the reservation object
--
2.24.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and we can just lock the buffer.
Assuming I didn't screw up anything with my audit of course.
v2:
- Dont forget wu_mutex (Christian König)
- Keep the mmap_sem-less wait optimization (Thomas)
- Use _lock_interruptible to be good citizens (Thomas)
v3: Rebase over fault handler helperification.
Reviewed-by: Christian König (v2)
Reviewed-by: Thomas Hellström (v2)
Signed-off-by: Daniel Vetter
Cc: Christian Koenig
Cc: Huang Rui
Cc: Gerd Hoffmann
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 36 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
drivers/gpu/drm/ttm/ttm_bo_vm.c | 18 +---
include/drm/ttm/ttm_bo_api.h | 4
4 files changed, 5 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 8d91b0428af1..5df596fb0280 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -161,7 +161,6 @@ static void ttm_bo_release_list(struct kref *list_kref)
dma_fence_put(bo->moving);
if (!ttm_bo_uses_embedded_gem_object(bo))
dma_resv_fini(&bo->base._resv);
- mutex_destroy(&bo->wu_mutex);
bo->destroy(bo);
ttm_mem_global_free(&ttm_mem_glob, acc_size);
}
@@ -1299,7 +1298,6 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
INIT_LIST_HEAD(&bo->ddestroy);
INIT_LIST_HEAD(&bo->swap);
INIT_LIST_HEAD(&bo->io_reserve_lru);
- mutex_init(&bo->wu_mutex);
bo->bdev = bdev;
bo->type = type;
bo->num_pages = num_pages;
@@ -1903,37 +1901,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
while (ttm_bo_swapout(&ttm_bo_glob, &ctx) == 0);
}
EXPORT_SYMBOL(ttm_bo_swapout_all);
-
-/**
- * ttm_bo_wait_unreserved - interruptible wait for a buffer object to become
- * unreserved
- *
- * @bo: Pointer to buffer
- */
-int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
-{
- int ret;
-
- /*
-* In the absense of a wait_unlocked API,
-* Use the bo::wu_mutex to avoid triggering livelocks due to
-* concurrent use of this function. Note that this use of
-* bo::wu_mutex can go away if we change locking order to
-* mmap_sem -> bo::reserve.
-*/
- ret = mutex_lock_interruptible(&bo->wu_mutex);
- if (unlikely(ret != 0))
- return -ERESTARTSYS;
- if (!dma_resv_is_locked(bo->base.resv))
- goto out_unlock;
- ret = dma_resv_lock_interruptible(bo->base.resv, NULL);
- if (ret == -EINTR)
- ret = -ERESTARTSYS;
- if (unlikely(ret != 0))
- goto out_unlock;
- dma_resv_unlock(bo->base.resv);
-
-out_unlock:
- mutex_unlock(&bo->wu_mutex);
- return ret;
-}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 6b0883a1776e..2b0e5a088da0 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -504,7 +504,6 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
INIT_LIST_HEAD(&fbo->base.lru);
INIT_LIST_HEAD(&fbo->base.swap);
INIT_LIST_HEAD(&fbo->base.io_reserve_lru);
- mutex_init(&fbo->base.wu_mutex);
fbo->base.moving = NULL;
drm_vma_node_reset(&fbo->base.base.vma_node);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 11863fbdd5d6..91466cfb6f16 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -128,30 +128,22 @@ static unsigned long ttm_bo_io_mem_pfn(struct
ttm_buffer_object *bo,
vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
struct vm_fault *vmf)
{
- /*
-* Work around locking order reversal in fault / nopfn
-* between mmap_sem and bo_reserve: Perform a trylock operation
-* for reserve, and if it fails, retry the fault after waiting
-* for the buffer to become unreserved.
-*/
if (unlikely(!dma_resv_trylock(bo->base.resv))) {
if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
ttm_bo_get(bo);
up_read(&vmf->vma->vm_mm->mmap_sem);
- (void) ttm_bo_wait_unreserved(bo);
+ if (!dma_resv_lock_interruptible(bo->base.resv,
+NULL))
+ dma_resv_unlock(bo->base.resv);
ttm_bo_put(bo);
}
return VM_FAULT_RETRY;
}
- /*
-* If we'd want to change locking order to
-* mmap_sem -> bo::reserve, we'd use
[Intel-gfx] [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl
We can't copy_*_user while holding reservations, that will (soon even
for nouveau) lead to deadlocks. And it breaks the cross-driver
contract around dma_resv.
Fix this by adding a slowpath for when we need relocations, and by
pushing the writeback of the new presumed offsets to the very end.
Aside from "it compiles" entirely untested unfortunately.
Signed-off-by: Daniel Vetter
Cc: Ilia Mirkin
Cc: Maarten Lankhorst
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 57 ++-
1 file changed, 38 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 1324c19f4e5c..05ec8edd6a8b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -484,12 +484,9 @@ validate_init(struct nouveau_channel *chan, struct
drm_file *file_priv,
static int
validate_list(struct nouveau_channel *chan, struct nouveau_cli *cli,
- struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo,
- uint64_t user_pbbo_ptr)
+ struct list_head *list, struct drm_nouveau_gem_pushbuf_bo *pbbo)
{
struct nouveau_drm *drm = chan->drm;
- struct drm_nouveau_gem_pushbuf_bo __user *upbbo =
- (void __force __user *)(uintptr_t)user_pbbo_ptr;
struct nouveau_bo *nvbo;
int ret, relocs = 0;
@@ -533,10 +530,6 @@ validate_list(struct nouveau_channel *chan, struct
nouveau_cli *cli,
b->presumed.offset = nvbo->bo.offset;
b->presumed.valid = 0;
relocs++;
-
- if (copy_to_user(&upbbo[nvbo->pbbo_index].presumed,
-&b->presumed, sizeof(b->presumed)))
- return -EFAULT;
}
}
@@ -547,8 +540,8 @@ static int
nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
struct drm_file *file_priv,
struct drm_nouveau_gem_pushbuf_bo *pbbo,
-uint64_t user_buffers, int nr_buffers,
-struct validate_op *op, int *apply_relocs)
+int nr_buffers,
+struct validate_op *op, bool *apply_relocs)
{
struct nouveau_cli *cli = nouveau_cli(file_priv);
int ret;
@@ -565,7 +558,7 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
return ret;
}
- ret = validate_list(chan, cli, &op->list, pbbo, user_buffers);
+ ret = validate_list(chan, cli, &op->list, pbbo);
if (unlikely(ret < 0)) {
if (ret != -ERESTARTSYS)
NV_PRINTK(err, cli, "validating bo list\n");
@@ -605,16 +598,12 @@ u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
static int
nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
struct drm_nouveau_gem_pushbuf *req,
+ struct drm_nouveau_gem_pushbuf_reloc *reloc,
struct drm_nouveau_gem_pushbuf_bo *bo)
{
- struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
int ret = 0;
unsigned i;
- reloc = u_memcpya(req->relocs, req->nr_relocs, sizeof(*reloc));
- if (IS_ERR(reloc))
- return PTR_ERR(reloc);
-
for (i = 0; i < req->nr_relocs; i++) {
struct drm_nouveau_gem_pushbuf_reloc *r = &reloc[i];
struct drm_nouveau_gem_pushbuf_bo *b;
@@ -693,11 +682,13 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
struct nouveau_drm *drm = nouveau_drm(dev);
struct drm_nouveau_gem_pushbuf *req = data;
struct drm_nouveau_gem_pushbuf_push *push;
+ struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
struct drm_nouveau_gem_pushbuf_bo *bo;
struct nouveau_channel *chan = NULL;
struct validate_op op;
struct nouveau_fence *fence = NULL;
- int i, j, ret = 0, do_reloc = 0;
+ int i, j, ret = 0;
+ bool do_reloc = false;
if (unlikely(!abi16))
return -ENOMEM;
@@ -755,7 +746,8 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
}
/* Validate buffer list */
- ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo, req->buffers,
+revalidate:
+ ret = nouveau_gem_pushbuf_validate(chan, file_priv, bo,
req->nr_buffers, &op, &do_reloc);
if (ret) {
if (ret != -ERESTARTSYS)
@@ -765,7 +757,18 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
/* Apply any relocations that are required */
if (do_reloc) {
- ret = nouveau_gem_pushbuf_reloc_apply(cli, req, bo);
+ if (!reloc) {
+ validate_fini(&op
Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
On Mon, Nov 04, 2019 at 06:37:59PM +0100, Daniel Vetter wrote:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
> really no business holding struct_mutex while doing copy_*_user. But
> I haven't checked them all.
>
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> looks clean.
>
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> copying from/to userspace happens all in v3d_lookup_bos which is
> outside of the critical section.
>
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> - vmw_execbuf_process: First this does some copies in
> vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> Then comes the usual ttm reserve/validate sequence, then actual
> submission/fencing, then unreserving, and finally some more
> copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> details, but looks all safe.
> - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> seen, seems to only create a fence and copy it out.
> - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> found there.
> Summary: vmwgfx seems to be fine too.
>
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> copying from userspace before even looking up objects through their
> handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>
> - qxl only has qxl_execbuffer_ioctl, which calls into
> qxl_process_single_command. There's a lovely comment before the
> __copy_from_user_inatomic that the slowpath should be copied from
> i915, but I guess that never happened. Try not to be unlucky and get
> your CS data evicted between when it's written and the kernel tries
> to read it. The only other copy_from_user is for relocs, but those
> are done before qxl_release_reserve_list(), which seems to be the
> only thing reserving buffers (in the ttm/dma_resv sense) in that
> code. So looks safe.
>
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> everywhere and needs to be fixed up.
>
> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> dma_resv lock of a different object already. Christian mentioned that
> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> that i915 has similar issues.
>
> Unfortunately we can't do this in the usual module init functions,
> because kernel threads don't have an ->mm - we have to wait around for
> some user thread to do this.
>
> Solution is to spawn a worker (but only once). It's horrible, but it
> works.
>
> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> initcall solution in.
>
> v4: Annotate with __init (Rob Herring)
>
> Cc: Rob Herring
> Cc: Alex Deucher
> Cc: Christian König
> Cc: Chris Wilson
> Cc: Thomas Zimmermann
> Cc: Rob Herring
> Cc: Tomeu Vizoso
> Cc: Eric Anholt
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Ben Skeggs
> Cc: "VMware Graphics"
> Cc: Thomas Hellstrom
> Reviewed-by: Christian König
> Reviewed-by: Chris Wilson
> Tested-by: Chris Wilson
> Signed-off-by: Daniel Vetter
I lost the r-b from Thomas on the last round:
Reviewed-by: Thomas Hellstrom
> ---
> drivers/dma-buf/dma-resv.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 709002515550..a05ff542be22 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>
> #include
> #include
> +#include
>
> /**
> * DOC: Reservation Object Overview
> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
> kfree_rcu(list, rcu);
> }
>
> +#if IS_ENABLED(CONFIG_LOCKDEP)
> +static void __init dma_resv_lockdep(void)
> +{
> + struct mm_struct *mm = mm_alloc();
> + struct dma_resv obj;
> +
> + if (!mm)
> + return;
> +
> + dma_resv_init(&obj);
> +
> + down_read(&mm->mmap_sem);
> + ww_mutex_lock(&obj.lock, NULL);
> + fs_reclaim_acquire(GFP_KERNEL);
> + fs_reclaim_release(GFP_KERNEL);
> + ww_mutex_unlock(&obj.lock);
> + up_read(&mm->mmap_sem);
> +
> + mmput(mm);
> +}
> +subsys_initcall(dma_resv_lockdep);
> +#endif
> +
> /**
> * dma_resv_init - initialize a reservation object
> * @obj: the reservation object
> --
> 2.24.0.rc2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/16] drm/i915/gem: Distinguish each object type
On Tue, Oct 22, 2019 at 03:30:13PM +0100, Matthew Auld wrote: > On Mon, 21 Oct 2019 at 09:03, Chris Wilson wrote: > > > > Separate each object class into a separate lock type to avoid lockdep > > cross-contamination between paths (i.e. userptr!). > > > > Signed-off-by: Chris Wilson > > Cc: Matthew Auld > > As per the explanation you gave on IRC, makes sense. > Reviewed-by: Matthew Auld It would be really lovely if such explanations would make it from ephemeral irc onto something more permanent like mailing lists, or even better, commit messages :-) So, why do we need this? I'm wondering since aside from userptr we'll have to unify how locking for bo works longer term (with all the dma_buf/ww_mutex stuff going on), not make it more distinct. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/fbdev: Fallback to non tiled mode if all tiles not present
On Mon, Nov 04, 2019 at 07:48:26PM +1000, David Airlie wrote: > On Mon, Nov 4, 2019 at 7:18 PM Daniel Vetter wrote: > > > > On Thu, Oct 31, 2019 at 02:48:39PM -0700, Manasi Navare wrote: > > > In case of tiled displays, if we hotplug just one connector, > > > fbcon currently just selects the preferred mode and if it is > > > tiled mode then that becomes a problem if rest of the tiles are > > > not present. > > > So in the fbdev driver on hotplug when we probe the client modeset, > > > we we dont find all the connectors for all tiles, then on a connector > > > with one tile, just fallback to the first available non tiled mode > > > to display over a single connector. > > > > > > Suggested-by: Ville Syrjälä > > > Suggested-by: Dave Airlie > > > Cc: Ville Syrjälä > > > Cc: Dave Airlie > > > Signed-off-by: Manasi Navare > > > > Hm, should we mayb have a slight timeout first to wait for the 2nd > > connector? Otherwise lots of flickering going on when plugging in one of > > these screens ... > > Not really, > > There are 3 scenarios with the multi-cable tiled monitors. and > non-resizeable fbdev. > > a) it's plugged in at boot. both cables are detected, fbdev gets a > full tiled mode. > b) it's not plugged in at boot, the user starts plugging it in, fbdev > was inited via the panel or another monitor. fbdev won't resize. > c) it's half plugged in at boot, then you get a non-tiled mode, and > fbdev can't resize to tiled anyways. > > Also plugging in one of these multi-cable monitors piecemeal is going > to take multiple seconds for the user to do physical cable plugging. Uh. I guess fbdev ftl, oh well. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Display WA2006604312 is needed from ICL onwards
On 4.11.2019 18.32, Matt Roper wrote:
On Mon, Nov 04, 2019 at 01:50:09PM +0200, Juha-Pekka Heikkila wrote:
WA2006604312 is listed for devices from Icelake onward.
The "Project" column on bspec #33450 does list EHL, however I don't see
it actually listed on the dedicated EHL WA page (bspec #33451) or the
TGL WA page (bspec #52890).
I'm not sure which page we're supposed to trust for EHL (personally I'd
trust the EHL page more than the ICL page when it comes to EHL), but it
doesn't look like this should apply to TGL/gen12 as far as I can see?
Hi Matt,
I agree it is bit of a mess what's documented where. For Gen12 I was
looking on #52887.. "I'm almost quite confident there was mention also
somewhere else.." Now looking if #52890 is the current version on
what's valid for gen12 you're correct and we can forget this WA.
Trybot results for this patch look more useful than what's coming for
this intel-gfx patch
https://patchwork.freedesktop.org/series/68871/
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5256/index.html?hosts=icl%7Ctgl
In any case it doesn't seem to make any difference on test results.
/Juha-Pekka
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e29e80ae5698..71ac4fe5fb47 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5981,7 +5981,7 @@ static bool needs_scalerclk_wa(struct drm_i915_private
*dev_priv,
const struct intel_crtc_state *crtc_state)
{
/* Wa_2006604312:icl */
- if (crtc_state->scaler_state.scaler_users > 0 && IS_ICELAKE(dev_priv))
+ if (crtc_state->scaler_state.scaler_users > 0 && INTEL_GEN(dev_priv) >=
11)
return true;
return false;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
Am 04.11.19 um 18:37 schrieb Daniel Vetter:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
>really no business holding struct_mutex while doing copy_*_user. But
>I haven't checked them all.
>
> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
>looks clean.
>
> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
>copying from/to userspace happens all in v3d_lookup_bos which is
>outside of the critical section.
>
> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
>- vmw_execbuf_process: First this does some copies in
> vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> Then comes the usual ttm reserve/validate sequence, then actual
> submission/fencing, then unreserving, and finally some more
> copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> details, but looks all safe.
>- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> seen, seems to only create a fence and copy it out.
>- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> found there.
>Summary: vmwgfx seems to be fine too.
>
> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
>copying from userspace before even looking up objects through their
>handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
>
> - qxl only has qxl_execbuffer_ioctl, which calls into
>qxl_process_single_command. There's a lovely comment before the
>__copy_from_user_inatomic that the slowpath should be copied from
>i915, but I guess that never happened. Try not to be unlucky and get
>your CS data evicted between when it's written and the kernel tries
>to read it. The only other copy_from_user is for relocs, but those
>are done before qxl_release_reserve_list(), which seems to be the
>only thing reserving buffers (in the ttm/dma_resv sense) in that
>code. So looks safe.
>
> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
>usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
>everywhere and needs to be fixed up.
>
> v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> dma_resv lock of a different object already. Christian mentioned that
> ttm core does this too for ghost objects. intel-gfx-ci highlighted
> that i915 has similar issues.
>
> Unfortunately we can't do this in the usual module init functions,
> because kernel threads don't have an ->mm - we have to wait around for
> some user thread to do this.
>
> Solution is to spawn a worker (but only once). It's horrible, but it
> works.
>
> v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> initcall solution in.
>
> v4: Annotate with __init (Rob Herring)
>
> Cc: Rob Herring
> Cc: Alex Deucher
> Cc: Christian König
> Cc: Chris Wilson
> Cc: Thomas Zimmermann
> Cc: Rob Herring
> Cc: Tomeu Vizoso
> Cc: Eric Anholt
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Ben Skeggs
> Cc: "VMware Graphics"
> Cc: Thomas Hellstrom
> Reviewed-by: Christian König
> Reviewed-by: Chris Wilson
> Tested-by: Chris Wilson
> Signed-off-by: Daniel Vetter
What's holding you back to commit that?
Christian.
> ---
> drivers/dma-buf/dma-resv.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> index 709002515550..a05ff542be22 100644
> --- a/drivers/dma-buf/dma-resv.c
> +++ b/drivers/dma-buf/dma-resv.c
> @@ -34,6 +34,7 @@
>
> #include
> #include
> +#include
>
> /**
>* DOC: Reservation Object Overview
> @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list *list)
> kfree_rcu(list, rcu);
> }
>
> +#if IS_ENABLED(CONFIG_LOCKDEP)
> +static void __init dma_resv_lockdep(void)
> +{
> + struct mm_struct *mm = mm_alloc();
> + struct dma_resv obj;
> +
> + if (!mm)
> + return;
> +
> + dma_resv_init(&obj);
> +
> + down_read(&mm->mmap_sem);
> + ww_mutex_lock(&obj.lock, NULL);
> + fs_reclaim_acquire(GFP_KERNEL);
> + fs_reclaim_release(GFP_KERNEL);
> + ww_mutex_unlock(&obj.lock);
> + up_read(&mm->mmap_sem);
> +
> + mmput(mm);
> +}
> +subsys_initcall(dma_resv_lockdep);
> +#endif
> +
> /**
>* dma_resv_init - initialize a reservation object
>* @obj: the reservation object
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: Switch obj->mm.lock lockdep annotations on its head
== Series Details ==
Series: series starting with [1/3] drm/i915: Switch obj->mm.lock lockdep
annotations on its head
URL : https://patchwork.freedesktop.org/series/68956/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c495bd921770 drm/i915: Switch obj->mm.lock lockdep annotations on its head
-:345: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 213 lines checked
ffcadad25d96 lockdep: add might_lock_nested()
-:24: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#24: FILE: include/linux/lockdep.h:631:
+# define might_lock_nested(lock, subclass) ^I^I^I^I\$
-:24: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'lock' - possible
side-effects?
#24: FILE: include/linux/lockdep.h:631:
+# define might_lock_nested(lock, subclass) \
+do { \
+ typecheck(struct lockdep_map *, &(lock)->dep_map); \
+ lock_acquire(&(lock)->dep_map, subclass, 0, 1, 1, NULL, \
+_THIS_IP_);\
+ lock_release(&(lock)->dep_map, 0, _THIS_IP_); \
+} while (0)
-:41: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 2 warnings, 1 checks, 20 lines checked
db49a54b7b5c drm/i915: use might_lock_nested in get_pages annotation
-:80: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch
author 'Daniel Vetter '
total: 0 errors, 1 warnings, 0 checks, 51 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Wait for both engines to complete before resubmitting
As the scratch buf is shared between the two requests on both engines, we need to wait for both to finish using the buffer before we reset it. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin --- tests/i915/gem_exec_balancer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c index e52f5df95..70c4529b4 100644 --- a/tests/i915/gem_exec_balancer.c +++ b/tests/i915/gem_exec_balancer.c @@ -840,7 +840,7 @@ static void bonded_slice(int i915) gem_execbuf(i915, &eb); close(eb.rsvd2); - gem_sync(i915, obj[2].handle); + gem_sync(i915, obj[0].handle); } *stop = 1; -- 2.24.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Switch obj->mm.lock lockdep annotations on its head
== Series Details ==
Series: series starting with [1/3] drm/i915: Switch obj->mm.lock lockdep
annotations on its head
URL : https://patchwork.freedesktop.org/series/68956/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7258 -> Patchwork_15123
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/index.html
Known issues
Here are the changes found in Patchwork_15123 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@double-flink:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
* igt@i915_selftest@live_blt:
- fi-bsw-n3050: [PASS][3] -> [DMESG-FAIL][4] ([fdo#112176])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-bsw-n3050/igt@i915_selftest@live_blt.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/fi-bsw-n3050/igt@i915_selftest@live_blt.html
* igt@i915_selftest@live_gem_contexts:
- fi-bsw-nick:[PASS][5] -> [INCOMPLETE][6] ([fdo# 111542])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-bsw-nick/igt@i915_selftest@live_gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/fi-bsw-nick/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_hangcheck:
- fi-hsw-4770r: [PASS][7] -> [DMESG-FAIL][8] ([fdo#111991])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/fi-hsw-4770r/igt@i915_selftest@live_hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][9] -> [DMESG-WARN][10] ([fdo#102614])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* {igt@gem_exec_suspend@basic-s0}:
- fi-bsw-kefka: [DMESG-WARN][11] ([fdo#112120]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-bsw-kefka/igt@gem_exec_susp...@basic-s0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/fi-bsw-kefka/igt@gem_exec_susp...@basic-s0.html
* igt@gem_flink_basic@basic:
- fi-icl-u3: [DMESG-WARN][13] ([fdo#107724] / [fdo#112052 ]) ->
[PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@gem_flink_ba...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/fi-icl-u3/igt@gem_flink_ba...@basic.html
* igt@prime_busy@basic-before-default:
- fi-icl-u3: [DMESG-WARN][15] ([fdo#107724]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@prime_b...@basic-before-default.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/fi-icl-u3/igt@prime_b...@basic-before-default.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][17] ([fdo#111407]) -> [FAIL][18] ([fdo#111045]
/ [fdo#111096])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo# 111542]: https://bugs.freedesktop.org/show_bug.cgi?id= 111542
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#54]: https://bugs.freedesktop.org/show_bug.cgi?id=54
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111991]: https://bugs.freedesktop.org/show_bug.cgi?id=111991
[fdo#112052 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112052
[fdo#112057]: https://bugs.freedesktop.org/show_bug.cgi?id=112057
[fdo#112120]: https://bugs.freedesktop.org/show_bug.cgi?id=112120
[fdo#112176]: https://bugs.freedesktop.org/show_bug.cgi?id=112176
Parti
Re: [Intel-gfx] [PATCH i-g-t v5 2/4] tests/gem_exec_reloc: Don't filter out invalid addresses
On Mon, Nov 04, 2019 at 06:13:28PM +0100, Janusz Krzysztofik wrote:
Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
addresses for !ppgtt") introduced filtering of addresses possibly
occupied by other users of shared GTT. Unfortunately, that filtering
doesn't distinguish between actually occupied addresses and otherwise
invalid softpin offsets. If incorrect GTT alignment will be assumed
when running on future backends with possibly larger minimum page
sizes, a half of calculated offsets to be tested will be incorrectly
detected as occupied by other users and silently skipped instead of
reported as a problem. That will significantly distort the intended
test pattern.
Filter out failing addresses only if reported as occupied.
v2: Skip unavailable addresses only when not running on full PPGTT.
v3: Replace the not on full PPGTT requirement for skipping with error
code checking.
v4: Silently skip only those offsets which have been explicitly
reported as overlapping with shared GTT reserved space, not simply
all which raise failures other than -EINVAL (Chris),
- as an implementation of moving the probe out of line so it's not
easily confused with the central point of the test (Chris), use
object validation library helper just introduced.
Signed-off-by: Janusz Krzysztofik
Cc: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index fdd9661d..e46a4df7 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -23,6 +23,7 @@
#include "igt.h"
#include "igt_dummyload.h"
+#include "i915/gem_gtt_topology.c"
IGT_TEST_DESCRIPTION("Basic sanity check of execbuf-ioctl relocations.");
@@ -520,7 +521,7 @@ static void basic_range(int fd, unsigned flags)
uint64_t gtt_size = gem_aperture_size(fd);
const uint32_t bbe = MI_BATCH_BUFFER_END;
igt_spin_t *spin = NULL;
- int count, n;
+ int count, n, err;
igt_require(gem_has_softpin(fd));
@@ -539,11 +540,12 @@ static void basic_range(int fd, unsigned flags)
obj[n].offset = (1ull << (i + 12)) - 4096;
obj[n].offset = gen8_canonical_address(obj[n].offset);
obj[n].flags = EXEC_OBJECT_PINNED |
EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
- gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
- execbuf.buffers_ptr = to_user_pointer(&obj[n]);
- execbuf.buffer_count = 1;
- if (__gem_execbuf(fd, &execbuf))
+ err = gem_gtt_validate_object(fd, &obj[n]);
Would it be better to name this function as
gem_gtt_validate_object_offset? From the earlier code is it was easy to
see that the intention of the test was to use gem_execbuf to map the
object to the offset. From the new method name unless I check the code
it's not straight forward that we are just checking the offset.
+ if (err) {
+ /* Iff using a shared GTT, some of it may be reserved */
Nit-pick: If, not Iff
+ igt_assert_eq(err, -ENOSPC);
continue;
+ }
igt_debug("obj[%d] handle=%d, address=%llx\n",
n, obj[n].handle, (long long)obj[n].offset);
@@ -559,11 +561,12 @@ static void basic_range(int fd, unsigned flags)
obj[n].offset = 1ull << (i + 12);
obj[n].offset = gen8_canonical_address(obj[n].offset);
obj[n].flags = EXEC_OBJECT_PINNED |
EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
- gem_write(fd, obj[n].handle, 0, &bbe, sizeof(bbe));
- execbuf.buffers_ptr = to_user_pointer(&obj[n]);
- execbuf.buffer_count = 1;
- if (__gem_execbuf(fd, &execbuf))
+ err = gem_gtt_validate_object(fd, &obj[n]);
+ if (err) {
+ /* Iff using a shared GTT, some of it may be reserved */
Nit-pick: If, not Iff
+ igt_assert_eq(err, -ENOSPC);
continue;
+ }
igt_debug("obj[%d] handle=%d, address=%llx\n",
n, obj[n].handle, (long long)obj[n].offset);
--
Other than the above comments, looks good to me.
Reviewed-by: Vanshidhar Konda
Vanshi
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v5 3/4] tests/gem_exec_reloc: Calculate offsets from minimum GTT alignment
On Mon, Nov 04, 2019 at 06:13:29PM +0100, Janusz Krzysztofik wrote:
The basic-range subtest assumes 4kB alignment while calculating softpin
offsets. On future backends with possibly larger minimum page sizes
the test will fail as a half of calculated offsets to be tested will be
incorrectly aligned.
Replace hardcoded constants corresponding to the assumed 4kB page size
with variables initialized with actual minimum GTT alignment size and
order.
v2: Simplify the code by reversing the size->order conversion,
- drop irrelevant modifications of requested object sizes.
v3: Reword commit message after removal of patch "Don't filter out
addresses on full PPGTT" from the series,
- initialize page size order with an actual minimum returned by a new
helper (inspired by Chris).
v4: Update the helper name, use the term 'minimum GTT alignment' across
the change, adjust variable names,
- refresh the commit message on top of the reintroduced patch that
fixes invalid offsets incorrectly assumed as occupied.
Signed-off-by: Janusz Krzysztofik
Cc: Katarzyna Dec
Cc: Stuart Summers
Reviewed-by: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index e46a4df7..a2a04343 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -521,14 +521,16 @@ static void basic_range(int fd, unsigned flags)
uint64_t gtt_size = gem_aperture_size(fd);
const uint32_t bbe = MI_BATCH_BUFFER_END;
igt_spin_t *spin = NULL;
+ int alignment_order = gem_gtt_min_alignment_order(fd);
+ uint64_t alignment = 1ull << alignment_order;
int count, n, err;
igt_require(gem_has_softpin(fd));
- for (count = 12; gtt_size >> (count + 1); count++)
+ for (count = alignment_order; gtt_size >> (count + 1); count++)
;
- count -= 12;
+ count -= alignment_order;
memset(obj, 0, sizeof(obj));
memset(reloc, 0, sizeof(reloc));
@@ -537,7 +539,7 @@ static void basic_range(int fd, unsigned flags)
n = 0;
for (int i = 0; i <= count; i++) {
obj[n].handle = gem_create(fd, 4096);
- obj[n].offset = (1ull << (i + 12)) - 4096;
+ obj[n].offset = (1ull << (i + alignment_order)) - alignment;
obj[n].offset = gen8_canonical_address(obj[n].offset);
obj[n].flags = EXEC_OBJECT_PINNED |
EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
err = gem_gtt_validate_object(fd, &obj[n]);
@@ -558,7 +560,7 @@ static void basic_range(int fd, unsigned flags)
}
for (int i = 1; i < count; i++) {
obj[n].handle = gem_create(fd, 4096);
- obj[n].offset = 1ull << (i + 12);
+ obj[n].offset = 1ull << (i + alignment_order);
obj[n].offset = gen8_canonical_address(obj[n].offset);
obj[n].flags = EXEC_OBJECT_PINNED |
EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
err = gem_gtt_validate_object(fd, &obj[n]);
--
2.21.0
Reviewed-by: Vanshidhar Konda
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v5 4/4] tests/gem_ctx_shared: Align objects using minimum GTT alignment
On Mon, Nov 04, 2019 at 06:13:30PM +0100, Janusz Krzysztofik wrote: exec-shared-gtt-* subtests use hardcoded values for object size and softpin offset, based on 4kB GTT alignment assumption. That may result in those subtests failing when run on future backing stores with possibly larger minimum page sizes. Replace hardcoded constants with values calculated from minimum GTT alignment of actual backing store the test is running on. v2: Update helper name, use 'minimum GTT alignment' term across the change, adjust variable name. v3: Name the variable 'stride', not 'alignment', it better reflects its purpose (Chris). Signed-off-by: Janusz Krzysztofik Reviewed-by: Chris Wilson --- tests/i915/gem_ctx_shared.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/tests/i915/gem_ctx_shared.c b/tests/i915/gem_ctx_shared.c index f7852482..cb726b4d 100644 --- a/tests/i915/gem_ctx_shared.c +++ b/tests/i915/gem_ctx_shared.c @@ -41,6 +41,7 @@ #include "igt_rand.h" #include "igt_vgem.h" #include "sync_file.h" +#include "i915/gem_gtt_topology.c" #define LO 0 #define HI 1 @@ -195,6 +196,7 @@ static void exec_shared_gtt(int i915, unsigned int ring) uint32_t scratch, *s; uint32_t batch, cs[16]; uint64_t offset; + uint64_t stride; int i; gem_require_ring(i915, ring); @@ -203,7 +205,8 @@ static void exec_shared_gtt(int i915, unsigned int ring) clone = gem_context_clone(i915, 0, I915_CONTEXT_CLONE_VM, 0); /* Find a hole big enough for both objects later */ - scratch = gem_create(i915, 16384); + stride = 2 * gem_gtt_min_alignment(i915); + scratch = gem_create(i915, 2 * stride); gem_write(i915, scratch, 0, &bbe, sizeof(bbe)); obj.handle = scratch; gem_execbuf(i915, &execbuf); @@ -246,7 +249,7 @@ static void exec_shared_gtt(int i915, unsigned int ring) gem_write(i915, batch, 0, cs, sizeof(cs)); obj.handle = batch; - obj.offset += 8192; /* make sure we don't cause an eviction! */ + obj.offset += stride; /* make sure we don't cause an eviction! */ execbuf.rsvd1 = clone; if (gen > 3 && gen < 6) execbuf.flags |= I915_EXEC_SECURE; -- 2.21.0 Reviewed-by: Vanshidhar Konda ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
On Mon, Nov 04, 2019 at 08:01:09PM +, Koenig, Christian wrote:
> Am 04.11.19 um 18:37 schrieb Daniel Vetter:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >really no business holding struct_mutex while doing copy_*_user. But
> >I haven't checked them all.
> >
> > - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >looks clean.
> >
> > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >copying from/to userspace happens all in v3d_lookup_bos which is
> >outside of the critical section.
> >
> > - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >- vmw_execbuf_process: First this does some copies in
> > vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> > Then comes the usual ttm reserve/validate sequence, then actual
> > submission/fencing, then unreserving, and finally some more
> > copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> > details, but looks all safe.
> >- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> > seen, seems to only create a fence and copy it out.
> >- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> > found there.
> >Summary: vmwgfx seems to be fine too.
> >
> > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >copying from userspace before even looking up objects through their
> >handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >
> > - qxl only has qxl_execbuffer_ioctl, which calls into
> >qxl_process_single_command. There's a lovely comment before the
> >__copy_from_user_inatomic that the slowpath should be copied from
> >i915, but I guess that never happened. Try not to be unlucky and get
> >your CS data evicted between when it's written and the kernel tries
> >to read it. The only other copy_from_user is for relocs, but those
> >are done before qxl_release_reserve_list(), which seems to be the
> >only thing reserving buffers (in the ttm/dma_resv sense) in that
> >code. So looks safe.
> >
> > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >everywhere and needs to be fixed up.
> >
> > v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
> > dma_resv lock of a different object already. Christian mentioned that
> > ttm core does this too for ghost objects. intel-gfx-ci highlighted
> > that i915 has similar issues.
> >
> > Unfortunately we can't do this in the usual module init functions,
> > because kernel threads don't have an ->mm - we have to wait around for
> > some user thread to do this.
> >
> > Solution is to spawn a worker (but only once). It's horrible, but it
> > works.
> >
> > v3: We can allocate mm! (Chris). Horrible worker hack out, clean
> > initcall solution in.
> >
> > v4: Annotate with __init (Rob Herring)
> >
> > Cc: Rob Herring
> > Cc: Alex Deucher
> > Cc: Christian König
> > Cc: Chris Wilson
> > Cc: Thomas Zimmermann
> > Cc: Rob Herring
> > Cc: Tomeu Vizoso
> > Cc: Eric Anholt
> > Cc: Dave Airlie
> > Cc: Gerd Hoffmann
> > Cc: Ben Skeggs
> > Cc: "VMware Graphics"
> > Cc: Thomas Hellstrom
> > Reviewed-by: Christian König
> > Reviewed-by: Chris Wilson
> > Tested-by: Chris Wilson
> > Signed-off-by: Daniel Vetter
>
> What's holding you back to commit that?
The nouveau patch, can't push this one without also fixing nouveau :-/
-Daniel
>
> Christian.
>
> > ---
> > drivers/dma-buf/dma-resv.c | 24
> > 1 file changed, 24 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index 709002515550..a05ff542be22 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -34,6 +34,7 @@
> >
> > #include
> > #include
> > +#include
> >
> > /**
> >* DOC: Reservation Object Overview
> > @@ -95,6 +96,29 @@ static void dma_resv_list_free(struct dma_resv_list
> > *list)
> > kfree_rcu(list, rcu);
> > }
> >
> > +#if IS_ENABLED(CONFIG_LOCKDEP)
> > +static void __init dma_resv_lockdep(void)
> > +{
> > + struct mm_struct *mm = mm_alloc();
> > + struct dma_resv obj;
> > +
> > + if (!mm)
> > + return;
> > +
> > + dma_resv_init(&obj);
> > +
> > + down_read(&mm->mmap_sem);
> > + ww_mutex_lock(&obj.lock, NULL);
> > + fs_reclaim_acquire(GFP_KERNEL);
> > + fs_reclaim_release(GFP_KERNEL);
> > + ww_mutex_unlock(&obj.lock);
> > + up_read(&mm->mmap_sem);
> > +
> > + mmput(mm);
> > +}
> > +subsys_initcall(dma_resv_lockdep);
> > +#endif
> > +
> > /**
> >* dma_resv_init - initialize a reservation object
> >* @obj: the reservation object
>
> ___
> dri
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] dma_resv: prime lockdep annotations
== Series Details == Series: series starting with [1/3] dma_resv: prime lockdep annotations URL : https://patchwork.freedesktop.org/series/68958/ State : warning == Summary == $ dim checkpatch origin/drm-tip 294603555e6b dma_resv: prime lockdep annotations -:77: WARNING:BAD_SIGN_OFF: Duplicate signature #77: Cc: Rob Herring -:83: WARNING:BAD_SIGN_OFF: email address '"VMware Graphics" ' might be better as 'VMware Graphics ' #83: Cc: "VMware Graphics" -:124: ERROR:TRAILING_WHITESPACE: trailing whitespace #124: FILE: drivers/dma-buf/dma-resv.c:116: +^I$ -:132: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 1 errors, 3 warnings, 0 checks, 36 lines checked f7e2f05f6fa0 drm/nouveau: slowpath for pushbuf ioctl -:155: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 122 lines checked 88df22c347f9 drm/ttm: remove ttm_bo_wait_unreserved -:27: WARNING:BAD_SIGN_OFF: email address '"VMware Graphics" ' might be better as 'VMware Graphics ' #27: Cc: "VMware Graphics" -:168: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 2 warnings, 0 checks, 81 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/fbdev: Fallback to non tiled mode if all tiles not present
On Mon, Nov 04, 2019 at 07:48:26PM +1000, David Airlie wrote: > On Mon, Nov 4, 2019 at 7:18 PM Daniel Vetter wrote: > > > > On Thu, Oct 31, 2019 at 02:48:39PM -0700, Manasi Navare wrote: > > > In case of tiled displays, if we hotplug just one connector, > > > fbcon currently just selects the preferred mode and if it is > > > tiled mode then that becomes a problem if rest of the tiles are > > > not present. > > > So in the fbdev driver on hotplug when we probe the client modeset, > > > we we dont find all the connectors for all tiles, then on a connector > > > with one tile, just fallback to the first available non tiled mode > > > to display over a single connector. > > > > > > Suggested-by: Ville Syrjälä > > > Suggested-by: Dave Airlie > > > Cc: Ville Syrjälä > > > Cc: Dave Airlie > > > Signed-off-by: Manasi Navare > > > > Hm, should we mayb have a slight timeout first to wait for the 2nd > > connector? Otherwise lots of flickering going on when plugging in one of > > these screens ... > > Not really, > > There are 3 scenarios with the multi-cable tiled monitors. and > non-resizeable fbdev. > > a) it's plugged in at boot. both cables are detected, fbdev gets a > full tiled mode. Yes this works as expected > b) it's not plugged in at boot, the user starts plugging it in, fbdev > was inited via the panel or another monitor. fbdev won't resize. > c) it's half plugged in at boot, then you get a non-tiled mode, and > fbdev can't resize to tiled anyways. In b and c, when its booted with only 1 cable connected and/or hotplugged only one cable after boot, I fallback to fisrt available non tiled mode, does that sound good? > > Also plugging in one of these multi-cable monitors piecemeal is going > to take multiple seconds for the user to do physical cable plugging. So still good with ignoring the second hotplug completely? However i donno where in the fb helper to stop passing the modeset down after the drm_fb_helper_hotplug_event() Any suggestions? Regards Manasi > > Dave. > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] dma_resv: prime lockdep annotations
== Series Details ==
Series: series starting with [1/3] dma_resv: prime lockdep annotations
URL : https://patchwork.freedesktop.org/series/68958/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7258 -> Patchwork_15124
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/index.html
Known issues
Here are the changes found in Patchwork_15124 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@double-flink:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +2
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-icl-u3/igt@gem_flink_ba...@double-flink.html
Possible fixes
* {igt@gem_exec_suspend@basic-s0}:
- fi-bsw-kefka: [DMESG-WARN][3] ([fdo#112120]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-bsw-kefka/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-bsw-kefka/igt@gem_exec_susp...@basic-s0.html
* igt@gem_flink_basic@basic:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724] / [fdo#112052 ]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@gem_flink_ba...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-icl-u3/igt@gem_flink_ba...@basic.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][7] ([fdo#111407]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@prime_busy@basic-before-default:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/fi-icl-u3/igt@prime_b...@basic-before-default.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/fi-icl-u3/igt@prime_b...@basic-before-default.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111699]: https://bugs.freedesktop.org/show_bug.cgi?id=111699
[fdo#112052 ]: https://bugs.freedesktop.org/show_bug.cgi?id=112052
[fdo#112120]: https://bugs.freedesktop.org/show_bug.cgi?id=112120
Participating hosts (52 -> 44)
--
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-bwr-2160 fi-ctg-p8600 fi-gdg-551 fi-byt-clapper
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7258 -> Patchwork_15124
CI-20190529: 20190529
CI_DRM_7258: 51b92cc0826a46a2b6de4abee3edecb216bf0419 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5261: 6c3bae1455c373c49fe744ea037e33b11e8daf1e @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15124: 88df22c347f93b3fc5582f4132ecd283ccb89804 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
88df22c347f9 drm/ttm: remove ttm_bo_wait_unreserved
f7e2f05f6fa0 drm/nouveau: slowpath for pushbuf ioctl
294603555e6b dma_resv: prime lockdep annotations
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15124/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V7 1/6] mdev: class id support
On Mon, 4 Nov 2019 20:39:47 +0800
Jason Wang wrote:
> Mdev bus only supports vfio driver right now, so it doesn't implement
> match method. But in the future, we may add drivers other than vfio,
> the first driver could be virtio-mdev. This means we need to add
> device class id support in bus match method to pair the mdev device
> and mdev driver correctly.
>
> So this patch adds id_table to mdev_driver and class_id for mdev
> device with the match method for mdev bus.
>
> Reviewed-by: Parav Pandit
> Signed-off-by: Jason Wang
> ---
> .../driver-api/vfio-mediated-device.rst | 5
> drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
> drivers/s390/cio/vfio_ccw_ops.c | 1 +
> drivers/s390/crypto/vfio_ap_ops.c | 1 +
> drivers/vfio/mdev/mdev_core.c | 16
> drivers/vfio/mdev/mdev_driver.c | 25 +++
> drivers/vfio/mdev/mdev_private.h | 1 +
> drivers/vfio/mdev/vfio_mdev.c | 6 +
> include/linux/mdev.h | 8 ++
> include/linux/mod_devicetable.h | 8 ++
> samples/vfio-mdev/mbochs.c| 1 +
> samples/vfio-mdev/mdpy.c | 1 +
> samples/vfio-mdev/mtty.c | 1 +
> 13 files changed, 75 insertions(+)
>
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst
> b/Documentation/driver-api/vfio-mediated-device.rst
> index 25eb7d5b834b..6709413bee29 100644
> --- a/Documentation/driver-api/vfio-mediated-device.rst
> +++ b/Documentation/driver-api/vfio-mediated-device.rst
> @@ -102,12 +102,14 @@ structure to represent a mediated device's driver::
>* @probe: called when new device created
>* @remove: called when device removed
>* @driver: device driver structure
> + * @id_table: the ids serviced by this driver
>*/
> struct mdev_driver {
>const char *name;
>int (*probe) (struct device *dev);
>void (*remove) (struct device *dev);
>struct device_driverdriver;
> + const struct mdev_class_id *id_table;
> };
>
> A mediated bus driver for mdev should use this structure in the function
> calls
> @@ -170,6 +172,9 @@ that a driver should use to unregister itself with the
> mdev core driver::
>
> extern void mdev_unregister_device(struct device *dev);
>
> +It is also required to specify the class_id in create() callback through::
> +
> + int mdev_set_class(struct mdev_device *mdev, u16 id);
>
> Mediated Device Management Interface Through sysfs
> ==
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 343d79c1cb7e..6420f0dbd31b 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -678,6 +678,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct
> mdev_device *mdev)
>dev_name(mdev_dev(mdev)));
> ret = 0;
>
> + mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
> out:
> return ret;
> }
> diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
> index f0d71ab77c50..cf2c013ae32f 100644
> --- a/drivers/s390/cio/vfio_ccw_ops.c
> +++ b/drivers/s390/cio/vfio_ccw_ops.c
> @@ -129,6 +129,7 @@ static int vfio_ccw_mdev_create(struct kobject *kobj,
> struct mdev_device *mdev)
> private->sch->schid.ssid,
> private->sch->schid.sch_no);
>
> + mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
> return 0;
> }
>
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index 5c0f53c6dde7..07c31070afeb 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -343,6 +343,7 @@ static int vfio_ap_mdev_create(struct kobject *kobj,
> struct mdev_device *mdev)
> list_add(&matrix_mdev->node, &matrix_dev->mdev_list);
> mutex_unlock(&matrix_dev->lock);
>
> + mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
> return 0;
> }
>
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index b558d4cfd082..d23ca39e3be6 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -45,6 +45,16 @@ void mdev_set_drvdata(struct mdev_device *mdev, void *data)
> }
> EXPORT_SYMBOL(mdev_set_drvdata);
>
> +/* Specify the class for the mdev device, this must be called during
> + * create() callback.
> + */
Standard non-networking multi-line comment style please, ie.
/*
* Multi-
* line
* comment
*/
Thanks,
Alex
> +void mdev_set_class(struct mdev_device *mdev, u16 id)
> +{
> + WARN_ON(mdev->class_id);
> + mdev->class_id = id;
> +}
> +EXPORT_SYMBOL(mdev_set_class);
> +
> struct device *mdev_dev(struct mdev_device *mdev)
> {
> return &mdev->dev;
> @@ -324,6 +334,12 @@ int mdev_device_
Re: [Intel-gfx] [PATCH V7 3/6] mdev: introduce device specific ops
On Mon, 4 Nov 2019 20:39:49 +0800
Jason Wang wrote:
> Currently, except for the create and remove, the rest of
> mdev_parent_ops is designed for vfio-mdev driver only and may not help
> for kernel mdev driver. With the help of class id, this patch
> introduces device specific callbacks inside mdev_device
> structure. This allows different set of callback to be used by
> vfio-mdev and virtio-mdev.
>
> Reviewed-by: Parav Pandit
> Signed-off-by: Jason Wang
> ---
> .../driver-api/vfio-mediated-device.rst | 35 +
> MAINTAINERS | 1 +
> drivers/gpu/drm/i915/gvt/kvmgt.c | 18 ---
> drivers/s390/cio/vfio_ccw_ops.c | 18 ---
> drivers/s390/crypto/vfio_ap_ops.c | 14 +++--
> drivers/vfio/mdev/mdev_core.c | 25 -
> drivers/vfio/mdev/mdev_private.h | 5 ++
> drivers/vfio/mdev/vfio_mdev.c | 37 ++---
> include/linux/mdev.h | 43 ---
> include/linux/mdev_vfio_ops.h | 52 +++
> samples/vfio-mdev/mbochs.c| 20 ---
> samples/vfio-mdev/mdpy.c | 20 ---
> samples/vfio-mdev/mtty.c | 18 ---
> 13 files changed, 206 insertions(+), 100 deletions(-)
> create mode 100644 include/linux/mdev_vfio_ops.h
>
> diff --git a/Documentation/driver-api/vfio-mediated-device.rst
> b/Documentation/driver-api/vfio-mediated-device.rst
> index 6709413bee29..e35f1f8f946e 100644
> --- a/Documentation/driver-api/vfio-mediated-device.rst
> +++ b/Documentation/driver-api/vfio-mediated-device.rst
> @@ -152,15 +152,6 @@ callbacks per mdev parent device, per mdev type, or any
> other categorization.
> Vendor drivers are expected to be fully asynchronous in this respect or
> provide their own internal resource protection.)
>
> -The callbacks in the mdev_parent_ops structure are as follows:
> -
> -* open: open callback of mediated device
> -* close: close callback of mediated device
> -* ioctl: ioctl callback of mediated device
> -* read : read emulation callback
> -* write: write emulation callback
> -* mmap: mmap emulation callback
> -
> A driver should use the mdev_parent_ops structure in the function call to
> register itself with the mdev core driver::
>
> @@ -172,10 +163,34 @@ that a driver should use to unregister itself with the
> mdev core driver::
>
> extern void mdev_unregister_device(struct device *dev);
>
> -It is also required to specify the class_id in create() callback through::
> +As multiple types of mediated devices may be supported, class id needs
> +to be specified in the create callback(). This could be done
> +explicitly for the device that does not use on mdev bus for its
> +operation through:
>
> int mdev_set_class(struct mdev_device *mdev, u16 id);
>
> +For the device that uses on the mdev bus for its operation, the class
> +should provide helper function to set class id and device specific
> +ops. E.g for vfio-mdev devices, the function to be called is::
> +
> + int mdev_set_vfio_ops(struct mdev_device *mdev,
> + const struct mdev_vfio_device_ops *vfio_ops);
> +
> +The class id (set by this function to MDEV_CLASS_ID_VFIO) is used to
> +match a device with an mdev driver via its id table. The device
> +specific callbacks (specified in *vfio_ops) are obtainable via
> +mdev_get_vfio_ops() (for use by the mdev bus driver). A vfio-mdev
> +device (class id MDEV_CLASS_ID_VFIO) uses the following
> +device-specific ops:
> +
> +* open: open callback of vfio mediated device
> +* close: close callback of vfio mediated device
> +* ioctl: ioctl callback of vfio mediated device
> +* read : read emulation callback
> +* write: write emulation callback
> +* mmap: mmap emulation callback
> +
> Mediated Device Management Interface Through sysfs
> ==
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cba1095547fd..f661d13344d6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17121,6 +17121,7 @@ S:Maintained
> F: Documentation/driver-api/vfio-mediated-device.rst
> F: drivers/vfio/mdev/
> F: include/linux/mdev.h
> +F: include/linux/mdev_vfio_ops.h
> F: samples/vfio-mdev/
>
> VFIO PLATFORM DRIVER
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 6420f0dbd31b..662f3a672372 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -42,6 +42,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -643,6 +644,8 @@ static void kvmgt_put_vfio_device(void *vgpu)
> vfio_device_put(((struct intel_vgpu *)vgpu)->vdev.vfio_device);
> }
>
> +static const struct mdev_vfio_device_ops intel_vfio_vgpu_dev_ops;
> +
> static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
> {
>
Re: [Intel-gfx] [PATCH V7 4/6] mdev: introduce virtio device and its device ops
On Mon, 4 Nov 2019 20:39:50 +0800
Jason Wang wrote:
> This patch implements basic support for mdev driver that supports
> virtio transport for kernel virtio driver.
>
> Signed-off-by: Jason Wang
> ---
> drivers/vfio/mdev/mdev_core.c| 20
> drivers/vfio/mdev/mdev_private.h | 2 +
> include/linux/mdev.h | 6 ++
> include/linux/mdev_virtio_ops.h | 166 +++
> 4 files changed, 194 insertions(+)
> create mode 100644 include/linux/mdev_virtio_ops.h
>
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> index 8d579d7ed82f..95ee4126ff9c 100644
> --- a/drivers/vfio/mdev/mdev_core.c
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -76,6 +76,26 @@ const struct mdev_vfio_device_ops
> *mdev_get_vfio_ops(struct mdev_device *mdev)
> }
> EXPORT_SYMBOL(mdev_get_vfio_ops);
>
> +/* Specify the virtio device ops for the mdev device, this
> + * must be called during create() callback for virtio mdev device.
> + */
Comment style.
> +void mdev_set_virtio_ops(struct mdev_device *mdev,
> + const struct mdev_virtio_device_ops *virtio_ops)
> +{
> + mdev_set_class(mdev, MDEV_CLASS_ID_VIRTIO);
> + mdev->virtio_ops = virtio_ops;
> +}
> +EXPORT_SYMBOL(mdev_set_virtio_ops);
> +
> +/* Get the virtio device ops for the mdev device. */
> +const struct mdev_virtio_device_ops *
> +mdev_get_virtio_ops(struct mdev_device *mdev)
> +{
> + WARN_ON(mdev->class_id != MDEV_CLASS_ID_VIRTIO);
> + return mdev->virtio_ops;
> +}
> +EXPORT_SYMBOL(mdev_get_virtio_ops);
> +
> struct device *mdev_dev(struct mdev_device *mdev)
> {
> return &mdev->dev;
> diff --git a/drivers/vfio/mdev/mdev_private.h
> b/drivers/vfio/mdev/mdev_private.h
> index 411227373625..2c74dd032409 100644
> --- a/drivers/vfio/mdev/mdev_private.h
> +++ b/drivers/vfio/mdev/mdev_private.h
> @@ -11,6 +11,7 @@
> #define MDEV_PRIVATE_H
>
> #include
> +#include
>
> int mdev_bus_register(void);
> void mdev_bus_unregister(void);
> @@ -38,6 +39,7 @@ struct mdev_device {
> u16 class_id;
> union {
> const struct mdev_vfio_device_ops *vfio_ops;
> + const struct mdev_virtio_device_ops *virtio_ops;
> };
> };
>
> diff --git a/include/linux/mdev.h b/include/linux/mdev.h
> index 9e37506d1987..f3d75a60c2b5 100644
> --- a/include/linux/mdev.h
> +++ b/include/linux/mdev.h
> @@ -17,6 +17,7 @@
>
> struct mdev_device;
> struct mdev_vfio_device_ops;
> +struct mdev_virtio_device_ops;
>
> /*
> * Called by the parent device driver to set the device which represents
> @@ -112,6 +113,10 @@ void mdev_set_class(struct mdev_device *mdev, u16 id);
> void mdev_set_vfio_ops(struct mdev_device *mdev,
> const struct mdev_vfio_device_ops *vfio_ops);
> const struct mdev_vfio_device_ops *mdev_get_vfio_ops(struct mdev_device
> *mdev);
> +void mdev_set_virtio_ops(struct mdev_device *mdev,
> + const struct mdev_virtio_device_ops *virtio_ops);
> +const struct mdev_virtio_device_ops *
> +mdev_get_virtio_ops(struct mdev_device *mdev);
>
> extern struct bus_type mdev_bus_type;
>
> @@ -127,6 +132,7 @@ struct mdev_device *mdev_from_dev(struct device *dev);
>
> enum {
> MDEV_CLASS_ID_VFIO = 1,
> + MDEV_CLASS_ID_VIRTIO = 2,
> /* New entries must be added here */
> };
>
> diff --git a/include/linux/mdev_virtio_ops.h b/include/linux/mdev_virtio_ops.h
> new file mode 100644
> index ..0dcae7fa31e5
> --- /dev/null
> +++ b/include/linux/mdev_virtio_ops.h
> @@ -0,0 +1,166 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Virtio mediated device driver
> + *
> + * Copyright 2019, Red Hat Corp.
> + * Author: Jason Wang
> + */
> +#ifndef MDEV_VIRTIO_OPS_H
> +#define MDEV_VIRTIO_OPS_H
> +
> +#include
> +#include
> +#include
> +
> +#define VIRTIO_MDEV_DEVICE_API_STRING"virtio-mdev"
> +#define VIRTIO_MDEV_F_VERSION_1 0x1
> +
> +struct virtio_mdev_callback {
> + irqreturn_t (*callback)(void *data);
> + void *private;
> +};
> +
> +/**
> + * struct mdev_virtio_device_ops - Structure to be registered for each
> + * mdev device to register the device for virtio/vhost drivers.
> + *
> + * The device ops that is supported by VIRTIO_MDEV_F_VERSION_1, the
> + * callbacks are mandatory unless explicity mentioned.
> + *
> + * @get_mdev_features: Get a set of bits that demonstrate
> + * the capability of the mdev device. New
> + * feature bits must be added when
> + * introducing new device ops. This
> + * allows the device ops to be extended
> + * (one feature could have N new ops).
> + * @mdev: mediated device
> + * Returns the mdev features (API) support by
> + * the device.
I still don't see the point of VIRTIO_MDEV_F_V
Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/dsc: make parameter arrays const
On Mon, Nov 04, 2019 at 04:14:36PM +0200, Jani Nikula wrote:
> No need for them to be mutable.
>
> Cc: Manasi Navare
> Signed-off-by: Jani Nikula
Agree that these params are constants
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_vdsc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 9cb36f855f07..763f1d7208e9 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -33,7 +33,7 @@ enum COLUMN_INDEX_BPC {
> #define DSC_SUPPORTED_VERSION_MIN1
>
> /* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
> -static u16 rc_buf_thresh[] = {
> +static const u16 rc_buf_thresh[] = {
> 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
> 7744, 7872, 8000, 8064
> };
> @@ -53,7 +53,7 @@ struct rc_parameters {
> * Selected Rate Control Related Parameter Recommended Values
> * from DSC_v1.11 spec & C Model release: DSC_model_20161212
> */
> -static struct rc_parameters rc_params[][MAX_COLUMN_INDEX] = {
> +static const struct rc_parameters rc_params[][MAX_COLUMN_INDEX] = {
> {
> /* 6BPP/8BPC */
> { 768, 15, 6144, 3, 13, 11, 11, {
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/dsc: rename functions for consistency
On Mon, Nov 04, 2019 at 04:14:39PM +0200, Jani Nikula wrote:
> Use intel_dsc_ prefix. No functional changes.
>
> Cc: Manasi Navare
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_vdsc.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index ac10736a076a..b23ba8d108db 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -501,8 +501,8 @@ intel_dsc_power_domain(const struct intel_crtc_state
> *crtc_state)
> return POWER_DOMAIN_TRANSCODER(cpu_transcoder);
> }
>
> -static void intel_configure_pps_for_dsc_encoder(struct intel_encoder
> *encoder,
> - const struct intel_crtc_state
> *crtc_state)
> +static void intel_dsc_pps_configure(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> @@ -901,8 +901,8 @@ static void intel_configure_pps_for_dsc_encoder(struct
> intel_encoder *encoder,
> }
> }
>
> -static void intel_dp_write_dsc_pps_sdp(struct intel_encoder *encoder,
> -const struct intel_crtc_state
> *crtc_state)
> +static void intel_dsc_dp_pps_write(struct intel_encoder *encoder,
> +const struct intel_crtc_state *crtc_state)
This function writes pps header and packs pps payload, if that also applies to
dsi dsc
then we can get rid of the _dp in this function.
if it doesnt apply, the rename looks good to me and in that case:
Reviewed-by: Manasi Navare
Manasi
> {
> struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> @@ -937,9 +937,9 @@ void intel_dsc_enable(struct intel_encoder *encoder,
> intel_display_power_get(dev_priv,
> intel_dsc_power_domain(crtc_state));
>
> - intel_configure_pps_for_dsc_encoder(encoder, crtc_state);
> + intel_dsc_pps_configure(encoder, crtc_state);
>
> - intel_dp_write_dsc_pps_sdp(encoder, crtc_state);
> + intel_dsc_dp_pps_write(encoder, crtc_state);
>
> if (crtc_state->cpu_transcoder == TRANSCODER_EDP) {
> dss_ctl1_reg = DSS_CTL1;
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/dsc: split out encoder specific parts from DSC compute params
On Mon, Nov 04, 2019 at 04:14:38PM +0200, Jani Nikula wrote:
> Split out the DP specific parts, making it easier to add DSI specific
> configuration. Also move the encoder specific parts towards the end, to
> allow overriding generic configuration if needed. This also improves
> clarity by making it clear the encoder independent configuration does
> not depend on the encoder specific parts.
>
> v2: Rebase
>
> Cc: Manasi Navare
> Signed-off-by: Jani Nikula
The splitting looks good and def more organized in terms of DPCD vs pipe config
DSC params
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_vdsc.c | 68 ++-
> drivers/gpu/drm/i915/display/intel_vdsc.h | 5 +-
> 3 files changed, 45 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index fe1d683eab28..9e9593965a9a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2132,7 +2132,7 @@ static int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> }
> }
>
> - ret = intel_dp_compute_dsc_params(intel_dp, pipe_config);
> + ret = intel_dsc_compute_params(&dig_port->base, pipe_config);
> if (ret < 0) {
> DRM_DEBUG_KMS("Cannot compute valid DSC parameters for Input
> Bpp = %d "
> "Compressed BPP = %d\n",
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index f1df654369a7..ac10736a076a 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -335,32 +335,14 @@ static const struct rc_parameters *get_rc_params(u16
> compressed_bpp,
> return &rc_parameters[row_index][column_index];
> }
>
> -int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
> - struct intel_crtc_state *pipe_config)
> +/* Values filled from DSC Sink DPCD */
> +static int intel_dsc_dp_compute_params(struct intel_encoder *encoder,
> +struct intel_crtc_state *pipe_config)
> {
> + struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> struct drm_dsc_config *vdsc_cfg = &pipe_config->dsc.config;
> - u16 compressed_bpp = pipe_config->dsc.compressed_bpp;
> - const struct rc_parameters *rc_params;
> - u8 i = 0;
> - u8 line_buf_depth = 0;
> + u8 line_buf_depth;
>
> - vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
> - vdsc_cfg->pic_height = pipe_config->hw.adjusted_mode.crtc_vdisplay;
> - vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
> - pipe_config->dsc.slice_count);
> - /*
> - * Slice Height of 8 works for all currently available panels. So start
> - * with that if pic_height is an integral multiple of 8.
> - * Eventually add logic to try multiple slice heights.
> - */
> - if (vdsc_cfg->pic_height % 8 == 0)
> - vdsc_cfg->slice_height = 8;
> - else if (vdsc_cfg->pic_height % 4 == 0)
> - vdsc_cfg->slice_height = 4;
> - else
> - vdsc_cfg->slice_height = 2;
> -
> - /* Values filled from DSC Sink DPCD */
> vdsc_cfg->dsc_version_major =
> (intel_dp->dsc_dpcd[DP_DSC_REV - DP_DSC_SUPPORT] &
>DP_DSC_MAJOR_MASK) >> DP_DSC_MAJOR_SHIFT;
> @@ -377,6 +359,7 @@ int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
> DRM_DEBUG_KMS("DSC Sink Line Buffer Depth invalid\n");
> return -EINVAL;
> }
> +
> if (vdsc_cfg->dsc_version_minor == 2)
> vdsc_cfg->line_buf_depth = (line_buf_depth ==
> DSC_1_2_MAX_LINEBUF_DEPTH_BITS) ?
> DSC_1_2_MAX_LINEBUF_DEPTH_VAL : line_buf_depth;
> @@ -384,13 +367,42 @@ int intel_dp_compute_dsc_params(struct intel_dp
> *intel_dp,
> vdsc_cfg->line_buf_depth = (line_buf_depth >
> DSC_1_1_MAX_LINEBUF_DEPTH_BITS) ?
> DSC_1_1_MAX_LINEBUF_DEPTH_BITS : line_buf_depth;
>
> + vdsc_cfg->block_pred_enable =
> + intel_dp->dsc_dpcd[DP_DSC_BLK_PREDICTION_SUPPORT -
> DP_DSC_SUPPORT] &
> + DP_DSC_BLK_PREDICTION_IS_SUPPORTED;
> +
> + return 0;
> +}
> +
> +int intel_dsc_compute_params(struct intel_encoder *encoder,
> + struct intel_crtc_state *pipe_config)
> +{
> + struct drm_dsc_config *vdsc_cfg = &pipe_config->dsc.config;
> + u16 compressed_bpp = pipe_config->dsc.compressed_bpp;
> + const struct rc_parameters *rc_params;
> + u8 i = 0;
> + int ret;
> +
> + vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
> + vdsc_cfg->pic_height = pipe_config->hw.adjusted_mode.crtc_vdisplay;
> + vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_wi
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/dsc: clean up rc parameter table access
On Mon, Nov 04, 2019 at 04:14:37PM +0200, Jani Nikula wrote:
> Use a simple pointer to the relevant element instead of duplicating the
> array subscription. No functional changes.
>
> Cc: Manasi Navare
> Signed-off-by: Jani Nikula
Thank you for the cleanup and optimizations in this patch,
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_vdsc.c | 55 ---
> 1 file changed, 30 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 763f1d7208e9..f1df654369a7 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -53,7 +53,7 @@ struct rc_parameters {
> * Selected Rate Control Related Parameter Recommended Values
> * from DSC_v1.11 spec & C Model release: DSC_model_20161212
> */
> -static const struct rc_parameters rc_params[][MAX_COLUMN_INDEX] = {
> +static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
> {
> /* 6BPP/8BPC */
> { 768, 15, 6144, 3, 13, 11, 11, {
> @@ -319,14 +319,29 @@ static int get_column_index_for_rc_params(u8
> bits_per_component)
> }
> }
>
> +static const struct rc_parameters *get_rc_params(u16 compressed_bpp,
> + u8 bits_per_component)
> +{
> + int row_index, column_index;
> +
> + row_index = get_row_index_for_rc_params(compressed_bpp);
> + if (row_index < 0)
> + return NULL;
> +
> + column_index = get_column_index_for_rc_params(bits_per_component);
> + if (column_index < 0)
> + return NULL;
> +
> + return &rc_parameters[row_index][column_index];
> +}
> +
> int intel_dp_compute_dsc_params(struct intel_dp *intel_dp,
> struct intel_crtc_state *pipe_config)
> {
> struct drm_dsc_config *vdsc_cfg = &pipe_config->dsc.config;
> u16 compressed_bpp = pipe_config->dsc.compressed_bpp;
> + const struct rc_parameters *rc_params;
> u8 i = 0;
> - int row_index = 0;
> - int column_index = 0;
> u8 line_buf_depth = 0;
>
> vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
> @@ -399,39 +414,29 @@ int intel_dp_compute_dsc_params(struct intel_dp
> *intel_dp,
> vdsc_cfg->rc_buf_thresh[13] = 0x7D;
> }
>
> - row_index = get_row_index_for_rc_params(compressed_bpp);
> - column_index =
> - get_column_index_for_rc_params(vdsc_cfg->bits_per_component);
> -
> - if (row_index < 0 || column_index < 0)
> + rc_params = get_rc_params(compressed_bpp, vdsc_cfg->bits_per_component);
> + if (!rc_params)
> return -EINVAL;
>
> - vdsc_cfg->first_line_bpg_offset =
> - rc_params[row_index][column_index].first_line_bpg_offset;
> - vdsc_cfg->initial_xmit_delay =
> - rc_params[row_index][column_index].initial_xmit_delay;
> - vdsc_cfg->initial_offset =
> - rc_params[row_index][column_index].initial_offset;
> - vdsc_cfg->flatness_min_qp =
> - rc_params[row_index][column_index].flatness_min_qp;
> - vdsc_cfg->flatness_max_qp =
> - rc_params[row_index][column_index].flatness_max_qp;
> - vdsc_cfg->rc_quant_incr_limit0 =
> - rc_params[row_index][column_index].rc_quant_incr_limit0;
> - vdsc_cfg->rc_quant_incr_limit1 =
> - rc_params[row_index][column_index].rc_quant_incr_limit1;
> + vdsc_cfg->first_line_bpg_offset = rc_params->first_line_bpg_offset;
> + vdsc_cfg->initial_xmit_delay = rc_params->initial_xmit_delay;
> + vdsc_cfg->initial_offset = rc_params->initial_offset;
> + vdsc_cfg->flatness_min_qp = rc_params->flatness_min_qp;
> + vdsc_cfg->flatness_max_qp = rc_params->flatness_max_qp;
> + vdsc_cfg->rc_quant_incr_limit0 = rc_params->rc_quant_incr_limit0;
> + vdsc_cfg->rc_quant_incr_limit1 = rc_params->rc_quant_incr_limit1;
>
> for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
> vdsc_cfg->rc_range_params[i].range_min_qp =
> -
> rc_params[row_index][column_index].rc_range_params[i].range_min_qp;
> + rc_params->rc_range_params[i].range_min_qp;
> vdsc_cfg->rc_range_params[i].range_max_qp =
> -
> rc_params[row_index][column_index].rc_range_params[i].range_max_qp;
> + rc_params->rc_range_params[i].range_max_qp;
> /*
>* Range BPG Offset uses 2's complement and is only a 6 bits. So
>* mask it to get only 6 bits.
>*/
> vdsc_cfg->rc_range_params[i].range_bpg_offset =
> -
> rc_params[row_index][column_index].rc_range_params[i].range_bpg_offset &
> + rc_params->rc_range_params[i].range_bpg_offset &
> DSC_RANGE_BPG_OFFSET_MASK;
> }
>
> --
> 2.20.1
>
___
Re: [Intel-gfx] [PATCH V7 1/6] mdev: class id support
On 2019/11/5 上午5:50, Alex Williamson wrote:
On Mon, 4 Nov 2019 20:39:47 +0800
Jason Wang wrote:
Mdev bus only supports vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
the first driver could be virtio-mdev. This means we need to add
device class id support in bus match method to pair the mdev device
and mdev driver correctly.
So this patch adds id_table to mdev_driver and class_id for mdev
device with the match method for mdev bus.
Reviewed-by: Parav Pandit
Signed-off-by: Jason Wang
---
.../driver-api/vfio-mediated-device.rst | 5
drivers/gpu/drm/i915/gvt/kvmgt.c | 1 +
drivers/s390/cio/vfio_ccw_ops.c | 1 +
drivers/s390/crypto/vfio_ap_ops.c | 1 +
drivers/vfio/mdev/mdev_core.c | 16
drivers/vfio/mdev/mdev_driver.c | 25 +++
drivers/vfio/mdev/mdev_private.h | 1 +
drivers/vfio/mdev/vfio_mdev.c | 6 +
include/linux/mdev.h | 8 ++
include/linux/mod_devicetable.h | 8 ++
samples/vfio-mdev/mbochs.c| 1 +
samples/vfio-mdev/mdpy.c | 1 +
samples/vfio-mdev/mtty.c | 1 +
13 files changed, 75 insertions(+)
diff --git a/Documentation/driver-api/vfio-mediated-device.rst
b/Documentation/driver-api/vfio-mediated-device.rst
index 25eb7d5b834b..6709413bee29 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -102,12 +102,14 @@ structure to represent a mediated device's driver::
* @probe: called when new device created
* @remove: called when device removed
* @driver: device driver structure
+ * @id_table: the ids serviced by this driver
*/
struct mdev_driver {
const char *name;
int (*probe) (struct device *dev);
void (*remove) (struct device *dev);
struct device_driverdriver;
+const struct mdev_class_id *id_table;
};
A mediated bus driver for mdev should use this structure in the function calls
@@ -170,6 +172,9 @@ that a driver should use to unregister itself with the mdev
core driver::
extern void mdev_unregister_device(struct device *dev);
+It is also required to specify the class_id in create() callback through::
+
+ int mdev_set_class(struct mdev_device *mdev, u16 id);
Mediated Device Management Interface Through sysfs
==
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 343d79c1cb7e..6420f0dbd31b 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -678,6 +678,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
dev_name(mdev_dev(mdev)));
ret = 0;
+ mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
out:
return ret;
}
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index f0d71ab77c50..cf2c013ae32f 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -129,6 +129,7 @@ static int vfio_ccw_mdev_create(struct kobject *kobj,
struct mdev_device *mdev)
private->sch->schid.ssid,
private->sch->schid.sch_no);
+ mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
return 0;
}
diff --git a/drivers/s390/crypto/vfio_ap_ops.c b/drivers/s390/crypto/vfio_ap_ops.c
index 5c0f53c6dde7..07c31070afeb 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -343,6 +343,7 @@ static int vfio_ap_mdev_create(struct kobject *kobj, struct
mdev_device *mdev)
list_add(&matrix_mdev->node, &matrix_dev->mdev_list);
mutex_unlock(&matrix_dev->lock);
+ mdev_set_class(mdev, MDEV_CLASS_ID_VFIO);
return 0;
}
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index b558d4cfd082..d23ca39e3be6 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -45,6 +45,16 @@ void mdev_set_drvdata(struct mdev_device *mdev, void *data)
}
EXPORT_SYMBOL(mdev_set_drvdata);
+/* Specify the class for the mdev device, this must be called during
+ * create() callback.
+ */
Standard non-networking multi-line comment style please, ie.
/*
* Multi-
* line
* comment
*/
Thanks,
Alex
Will fix.
Thanks
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V7 3/6] mdev: introduce device specific ops
On 2019/11/5 上午5:50, Alex Williamson wrote:
EXPORT_SYMBOL(mdev_set_drvdata);
+
Extra whitespace
/* Specify the class for the mdev device, this must be called during
- * create() callback.
- */
+ * create() callback explicitly or implicity through the helpers
s/implicity/implicitly/
+ * provided by each class. */
void mdev_set_class(struct mdev_device *mdev, u16 id)
{
WARN_ON(mdev->class_id);
@@ -55,6 +56,26 @@ void mdev_set_class(struct mdev_device *mdev, u16 id)
}
EXPORT_SYMBOL(mdev_set_class);
+/* Specify the mdev device to be a VFIO mdev device, and set VFIO
+ * device ops for it. This must be called from the create() callback
+ * for VFIO mdev device.
+ */
Comment style. Thanks,
Will fix them all.
Thanks
Alex
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V7 4/6] mdev: introduce virtio device and its device ops
On 2019/11/5 上午5:50, Alex Williamson wrote:
On Mon, 4 Nov 2019 20:39:50 +0800
Jason Wang wrote:
This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/mdev_core.c| 20
drivers/vfio/mdev/mdev_private.h | 2 +
include/linux/mdev.h | 6 ++
include/linux/mdev_virtio_ops.h | 166 +++
4 files changed, 194 insertions(+)
create mode 100644 include/linux/mdev_virtio_ops.h
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 8d579d7ed82f..95ee4126ff9c 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -76,6 +76,26 @@ const struct mdev_vfio_device_ops *mdev_get_vfio_ops(struct
mdev_device *mdev)
}
EXPORT_SYMBOL(mdev_get_vfio_ops);
+/* Specify the virtio device ops for the mdev device, this
+ * must be called during create() callback for virtio mdev device.
+ */
Comment style.
Will fix.
+void mdev_set_virtio_ops(struct mdev_device *mdev,
+const struct mdev_virtio_device_ops *virtio_ops)
+{
+ mdev_set_class(mdev, MDEV_CLASS_ID_VIRTIO);
+ mdev->virtio_ops = virtio_ops;
+}
+EXPORT_SYMBOL(mdev_set_virtio_ops);
+
+/* Get the virtio device ops for the mdev device. */
+const struct mdev_virtio_device_ops *
+mdev_get_virtio_ops(struct mdev_device *mdev)
+{
+ WARN_ON(mdev->class_id != MDEV_CLASS_ID_VIRTIO);
+ return mdev->virtio_ops;
+}
+EXPORT_SYMBOL(mdev_get_virtio_ops);
+
struct device *mdev_dev(struct mdev_device *mdev)
{
return &mdev->dev;
diff --git a/drivers/vfio/mdev/mdev_private.h b/drivers/vfio/mdev/mdev_private.h
index 411227373625..2c74dd032409 100644
--- a/drivers/vfio/mdev/mdev_private.h
+++ b/drivers/vfio/mdev/mdev_private.h
@@ -11,6 +11,7 @@
#define MDEV_PRIVATE_H
#include
+#include
int mdev_bus_register(void);
void mdev_bus_unregister(void);
@@ -38,6 +39,7 @@ struct mdev_device {
u16 class_id;
union {
const struct mdev_vfio_device_ops *vfio_ops;
+ const struct mdev_virtio_device_ops *virtio_ops;
};
};
diff --git a/include/linux/mdev.h b/include/linux/mdev.h
index 9e37506d1987..f3d75a60c2b5 100644
--- a/include/linux/mdev.h
+++ b/include/linux/mdev.h
@@ -17,6 +17,7 @@
struct mdev_device;
struct mdev_vfio_device_ops;
+struct mdev_virtio_device_ops;
/*
* Called by the parent device driver to set the device which represents
@@ -112,6 +113,10 @@ void mdev_set_class(struct mdev_device *mdev, u16 id);
void mdev_set_vfio_ops(struct mdev_device *mdev,
const struct mdev_vfio_device_ops *vfio_ops);
const struct mdev_vfio_device_ops *mdev_get_vfio_ops(struct mdev_device
*mdev);
+void mdev_set_virtio_ops(struct mdev_device *mdev,
+const struct mdev_virtio_device_ops *virtio_ops);
+const struct mdev_virtio_device_ops *
+mdev_get_virtio_ops(struct mdev_device *mdev);
extern struct bus_type mdev_bus_type;
@@ -127,6 +132,7 @@ struct mdev_device *mdev_from_dev(struct device *dev);
enum {
MDEV_CLASS_ID_VFIO = 1,
+ MDEV_CLASS_ID_VIRTIO = 2,
/* New entries must be added here */
};
diff --git a/include/linux/mdev_virtio_ops.h b/include/linux/mdev_virtio_ops.h
new file mode 100644
index ..0dcae7fa31e5
--- /dev/null
+++ b/include/linux/mdev_virtio_ops.h
@@ -0,0 +1,166 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Virtio mediated device driver
+ *
+ * Copyright 2019, Red Hat Corp.
+ * Author: Jason Wang
+ */
+#ifndef MDEV_VIRTIO_OPS_H
+#define MDEV_VIRTIO_OPS_H
+
+#include
+#include
+#include
+
+#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
+#define VIRTIO_MDEV_F_VERSION_1 0x1
+
+struct virtio_mdev_callback {
+ irqreturn_t (*callback)(void *data);
+ void *private;
+};
+
+/**
+ * struct mdev_virtio_device_ops - Structure to be registered for each
+ * mdev device to register the device for virtio/vhost drivers.
+ *
+ * The device ops that is supported by VIRTIO_MDEV_F_VERSION_1, the
+ * callbacks are mandatory unless explicity mentioned.
+ *
+ * @get_mdev_features: Get a set of bits that demonstrate
+ * the capability of the mdev device. New
+ * feature bits must be added when
+ * introducing new device ops. This
+ * allows the device ops to be extended
+ * (one feature could have N new ops).
+ * @mdev: mediated device
+ * Returns the mdev features (API) support by
+ * the device.
I still don't see the point of VIRTIO_MDEV_F_VERSION_1. In what case
would it not be set?
It's a must for current driver implementation.
What would it indicate to the caller i
Re: [Intel-gfx] [PATCH V7 4/6] mdev: introduce virtio device and its device ops
On Tue, 5 Nov 2019 11:52:41 +0800
Jason Wang wrote:
> On 2019/11/5 上午5:50, Alex Williamson wrote:
> > On Mon, 4 Nov 2019 20:39:50 +0800
> > Jason Wang wrote:
> >
> >> This patch implements basic support for mdev driver that supports
> >> virtio transport for kernel virtio driver.
> >>
> >> Signed-off-by: Jason Wang
> >> ---
> >> drivers/vfio/mdev/mdev_core.c| 20
> >> drivers/vfio/mdev/mdev_private.h | 2 +
> >> include/linux/mdev.h | 6 ++
> >> include/linux/mdev_virtio_ops.h | 166 +++
> >> 4 files changed, 194 insertions(+)
> >> create mode 100644 include/linux/mdev_virtio_ops.h
> >>
> >> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> >> index 8d579d7ed82f..95ee4126ff9c 100644
> >> --- a/drivers/vfio/mdev/mdev_core.c
> >> +++ b/drivers/vfio/mdev/mdev_core.c
> >> @@ -76,6 +76,26 @@ const struct mdev_vfio_device_ops
> >> *mdev_get_vfio_ops(struct mdev_device *mdev)
> >> }
> >> EXPORT_SYMBOL(mdev_get_vfio_ops);
> >>
> >> +/* Specify the virtio device ops for the mdev device, this
> >> + * must be called during create() callback for virtio mdev device.
> >> + */
> > Comment style.
>
>
> Will fix.
>
>
> >
> >> +void mdev_set_virtio_ops(struct mdev_device *mdev,
> >> + const struct mdev_virtio_device_ops *virtio_ops)
> >> +{
> >> + mdev_set_class(mdev, MDEV_CLASS_ID_VIRTIO);
> >> + mdev->virtio_ops = virtio_ops;
> >> +}
> >> +EXPORT_SYMBOL(mdev_set_virtio_ops);
> >> +
> >> +/* Get the virtio device ops for the mdev device. */
> >> +const struct mdev_virtio_device_ops *
> >> +mdev_get_virtio_ops(struct mdev_device *mdev)
> >> +{
> >> + WARN_ON(mdev->class_id != MDEV_CLASS_ID_VIRTIO);
> >> + return mdev->virtio_ops;
> >> +}
> >> +EXPORT_SYMBOL(mdev_get_virtio_ops);
> >> +
> >> struct device *mdev_dev(struct mdev_device *mdev)
> >> {
> >>return &mdev->dev;
> >> diff --git a/drivers/vfio/mdev/mdev_private.h
> >> b/drivers/vfio/mdev/mdev_private.h
> >> index 411227373625..2c74dd032409 100644
> >> --- a/drivers/vfio/mdev/mdev_private.h
> >> +++ b/drivers/vfio/mdev/mdev_private.h
> >> @@ -11,6 +11,7 @@
> >> #define MDEV_PRIVATE_H
> >>
> >> #include
> >> +#include
> >>
> >> int mdev_bus_register(void);
> >> void mdev_bus_unregister(void);
> >> @@ -38,6 +39,7 @@ struct mdev_device {
> >>u16 class_id;
> >>union {
> >>const struct mdev_vfio_device_ops *vfio_ops;
> >> + const struct mdev_virtio_device_ops *virtio_ops;
> >>};
> >> };
> >>
> >> diff --git a/include/linux/mdev.h b/include/linux/mdev.h
> >> index 9e37506d1987..f3d75a60c2b5 100644
> >> --- a/include/linux/mdev.h
> >> +++ b/include/linux/mdev.h
> >> @@ -17,6 +17,7 @@
> >>
> >> struct mdev_device;
> >> struct mdev_vfio_device_ops;
> >> +struct mdev_virtio_device_ops;
> >>
> >> /*
> >>* Called by the parent device driver to set the device which represents
> >> @@ -112,6 +113,10 @@ void mdev_set_class(struct mdev_device *mdev, u16 id);
> >> void mdev_set_vfio_ops(struct mdev_device *mdev,
> >> const struct mdev_vfio_device_ops *vfio_ops);
> >> const struct mdev_vfio_device_ops *mdev_get_vfio_ops(struct mdev_device
> >> *mdev);
> >> +void mdev_set_virtio_ops(struct mdev_device *mdev,
> >> + const struct mdev_virtio_device_ops *virtio_ops);
> >> +const struct mdev_virtio_device_ops *
> >> +mdev_get_virtio_ops(struct mdev_device *mdev);
> >>
> >> extern struct bus_type mdev_bus_type;
> >>
> >> @@ -127,6 +132,7 @@ struct mdev_device *mdev_from_dev(struct device *dev);
> >>
> >> enum {
> >>MDEV_CLASS_ID_VFIO = 1,
> >> + MDEV_CLASS_ID_VIRTIO = 2,
> >>/* New entries must be added here */
> >> };
> >>
> >> diff --git a/include/linux/mdev_virtio_ops.h
> >> b/include/linux/mdev_virtio_ops.h
> >> new file mode 100644
> >> index ..0dcae7fa31e5
> >> --- /dev/null
> >> +++ b/include/linux/mdev_virtio_ops.h
> >> @@ -0,0 +1,166 @@
> >> +/* SPDX-License-Identifier: GPL-2.0-only */
> >> +/*
> >> + * Virtio mediated device driver
> >> + *
> >> + * Copyright 2019, Red Hat Corp.
> >> + * Author: Jason Wang
> >> + */
> >> +#ifndef MDEV_VIRTIO_OPS_H
> >> +#define MDEV_VIRTIO_OPS_H
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
> >> +#define VIRTIO_MDEV_F_VERSION_1 0x1
> >> +
> >> +struct virtio_mdev_callback {
> >> + irqreturn_t (*callback)(void *data);
> >> + void *private;
> >> +};
> >> +
> >> +/**
> >> + * struct mdev_virtio_device_ops - Structure to be registered for each
> >> + * mdev device to register the device for virtio/vhost drivers.
> >> + *
> >> + * The device ops that is supported by VIRTIO_MDEV_F_VERSION_1, the
> >> + * callbacks are mandatory unless explicity mentioned.
> >> + *
> >> + * @get_mdev_features:Get a set of bits that demonstrate
> >> + *
Re: [Intel-gfx] [PATCH V7 4/6] mdev: introduce virtio device and its device ops
On 2019/11/5 下午12:39, Alex Williamson wrote:
On Tue, 5 Nov 2019 11:52:41 +0800
Jason Wang wrote:
On 2019/11/5 上午5:50, Alex Williamson wrote:
On Mon, 4 Nov 2019 20:39:50 +0800
Jason Wang wrote:
This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/mdev_core.c| 20
drivers/vfio/mdev/mdev_private.h | 2 +
include/linux/mdev.h | 6 ++
include/linux/mdev_virtio_ops.h | 166 +++
4 files changed, 194 insertions(+)
create mode 100644 include/linux/mdev_virtio_ops.h
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 8d579d7ed82f..95ee4126ff9c 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -76,6 +76,26 @@ const struct mdev_vfio_device_ops *mdev_get_vfio_ops(struct
mdev_device *mdev)
}
EXPORT_SYMBOL(mdev_get_vfio_ops);
+/* Specify the virtio device ops for the mdev device, this
+ * must be called during create() callback for virtio mdev device.
+ */
Comment style.
Will fix.
+void mdev_set_virtio_ops(struct mdev_device *mdev,
+const struct mdev_virtio_device_ops *virtio_ops)
+{
+ mdev_set_class(mdev, MDEV_CLASS_ID_VIRTIO);
+ mdev->virtio_ops = virtio_ops;
+}
+EXPORT_SYMBOL(mdev_set_virtio_ops);
+
+/* Get the virtio device ops for the mdev device. */
+const struct mdev_virtio_device_ops *
+mdev_get_virtio_ops(struct mdev_device *mdev)
+{
+ WARN_ON(mdev->class_id != MDEV_CLASS_ID_VIRTIO);
+ return mdev->virtio_ops;
+}
+EXPORT_SYMBOL(mdev_get_virtio_ops);
+
struct device *mdev_dev(struct mdev_device *mdev)
{
return &mdev->dev;
diff --git a/drivers/vfio/mdev/mdev_private.h b/drivers/vfio/mdev/mdev_private.h
index 411227373625..2c74dd032409 100644
--- a/drivers/vfio/mdev/mdev_private.h
+++ b/drivers/vfio/mdev/mdev_private.h
@@ -11,6 +11,7 @@
#define MDEV_PRIVATE_H
#include
+#include
int mdev_bus_register(void);
void mdev_bus_unregister(void);
@@ -38,6 +39,7 @@ struct mdev_device {
u16 class_id;
union {
const struct mdev_vfio_device_ops *vfio_ops;
+ const struct mdev_virtio_device_ops *virtio_ops;
};
};
diff --git a/include/linux/mdev.h b/include/linux/mdev.h
index 9e37506d1987..f3d75a60c2b5 100644
--- a/include/linux/mdev.h
+++ b/include/linux/mdev.h
@@ -17,6 +17,7 @@
struct mdev_device;
struct mdev_vfio_device_ops;
+struct mdev_virtio_device_ops;
/*
* Called by the parent device driver to set the device which represents
@@ -112,6 +113,10 @@ void mdev_set_class(struct mdev_device *mdev, u16 id);
void mdev_set_vfio_ops(struct mdev_device *mdev,
const struct mdev_vfio_device_ops *vfio_ops);
const struct mdev_vfio_device_ops *mdev_get_vfio_ops(struct mdev_device
*mdev);
+void mdev_set_virtio_ops(struct mdev_device *mdev,
+const struct mdev_virtio_device_ops *virtio_ops);
+const struct mdev_virtio_device_ops *
+mdev_get_virtio_ops(struct mdev_device *mdev);
extern struct bus_type mdev_bus_type;
@@ -127,6 +132,7 @@ struct mdev_device *mdev_from_dev(struct device *dev);
enum {
MDEV_CLASS_ID_VFIO = 1,
+ MDEV_CLASS_ID_VIRTIO = 2,
/* New entries must be added here */
};
diff --git a/include/linux/mdev_virtio_ops.h b/include/linux/mdev_virtio_ops.h
new file mode 100644
index ..0dcae7fa31e5
--- /dev/null
+++ b/include/linux/mdev_virtio_ops.h
@@ -0,0 +1,166 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Virtio mediated device driver
+ *
+ * Copyright 2019, Red Hat Corp.
+ * Author: Jason Wang
+ */
+#ifndef MDEV_VIRTIO_OPS_H
+#define MDEV_VIRTIO_OPS_H
+
+#include
+#include
+#include
+
+#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
+#define VIRTIO_MDEV_F_VERSION_1 0x1
+
+struct virtio_mdev_callback {
+ irqreturn_t (*callback)(void *data);
+ void *private;
+};
+
+/**
+ * struct mdev_virtio_device_ops - Structure to be registered for each
+ * mdev device to register the device for virtio/vhost drivers.
+ *
+ * The device ops that is supported by VIRTIO_MDEV_F_VERSION_1, the
+ * callbacks are mandatory unless explicity mentioned.
+ *
+ * @get_mdev_features: Get a set of bits that demonstrate
+ * the capability of the mdev device. New
+ * feature bits must be added when
+ * introducing new device ops. This
+ * allows the device ops to be extended
+ * (one feature could have N new ops).
+ * @mdev: mediated device
+ * Returns the mdev features (API) support by
+ * the device.
I still don't see the point of VIRTIO_MDEV_F_
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/dsc: rename functions for consistency
On Mon, 04 Nov 2019, Manasi Navare wrote:
> On Mon, Nov 04, 2019 at 04:14:39PM +0200, Jani Nikula wrote:
>> Use intel_dsc_ prefix. No functional changes.
>>
>> Cc: Manasi Navare
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/display/intel_vdsc.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
>> b/drivers/gpu/drm/i915/display/intel_vdsc.c
>> index ac10736a076a..b23ba8d108db 100644
>> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
>> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
>> @@ -501,8 +501,8 @@ intel_dsc_power_domain(const struct intel_crtc_state
>> *crtc_state)
>> return POWER_DOMAIN_TRANSCODER(cpu_transcoder);
>> }
>>
>> -static void intel_configure_pps_for_dsc_encoder(struct intel_encoder
>> *encoder,
>> -const struct intel_crtc_state
>> *crtc_state)
>> +static void intel_dsc_pps_configure(struct intel_encoder *encoder,
>> +const struct intel_crtc_state *crtc_state)
>> {
>> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>> @@ -901,8 +901,8 @@ static void intel_configure_pps_for_dsc_encoder(struct
>> intel_encoder *encoder,
>> }
>> }
>>
>> -static void intel_dp_write_dsc_pps_sdp(struct intel_encoder *encoder,
>> - const struct intel_crtc_state
>> *crtc_state)
>> +static void intel_dsc_dp_pps_write(struct intel_encoder *encoder,
>> + const struct intel_crtc_state *crtc_state)
>
> This function writes pps header and packs pps payload, if that also applies
> to dsi dsc
> then we can get rid of the _dp in this function.
>
> if it doesnt apply, the rename looks good to me and in that case:
It's slightly different for DSI. You'll see. ;)
>
> Reviewed-by: Manasi Navare
Thanks.
BR,
Jani.
>
> Manasi
>
>> {
>> struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
>> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>> @@ -937,9 +937,9 @@ void intel_dsc_enable(struct intel_encoder *encoder,
>> intel_display_power_get(dev_priv,
>> intel_dsc_power_domain(crtc_state));
>>
>> -intel_configure_pps_for_dsc_encoder(encoder, crtc_state);
>> +intel_dsc_pps_configure(encoder, crtc_state);
>>
>> -intel_dp_write_dsc_pps_sdp(encoder, crtc_state);
>> +intel_dsc_dp_pps_write(encoder, crtc_state);
>>
>> if (crtc_state->cpu_transcoder == TRANSCODER_EDP) {
>> dss_ctl1_reg = DSS_CTL1;
>> --
>> 2.20.1
>>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: Switch obj->mm.lock lockdep annotations on its head
== Series Details ==
Series: series starting with [1/3] drm/i915: Switch obj->mm.lock lockdep
annotations on its head
URL : https://patchwork.freedesktop.org/series/68956/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7258_full -> Patchwork_15123_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_15123_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_15123_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_15123_full:
### IGT changes ###
Possible regressions
* igt@i915_selftest@mock_hugepages:
- shard-kbl: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl6/igt@i915_selftest@mock_hugepages.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/shard-kbl3/igt@i915_selftest@mock_hugepages.html
- shard-skl: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-skl7/igt@i915_selftest@mock_hugepages.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/shard-skl9/igt@i915_selftest@mock_hugepages.html
- shard-glk: [PASS][5] -> [DMESG-WARN][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-glk6/igt@i915_selftest@mock_hugepages.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/shard-glk5/igt@i915_selftest@mock_hugepages.html
- shard-iclb: [PASS][7] -> [DMESG-WARN][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb7/igt@i915_selftest@mock_hugepages.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/shard-iclb3/igt@i915_selftest@mock_hugepages.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@mock_hugepages:
- {shard-tglb}: [PASS][9] -> [DMESG-WARN][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-tglb5/igt@i915_selftest@mock_hugepages.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/shard-tglb2/igt@i915_selftest@mock_hugepages.html
Known issues
Here are the changes found in Patchwork_15123_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112080]) +15 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb2/igt@gem_b...@busy-vcs1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/shard-iclb7/igt@gem_b...@busy-vcs1.html
* igt@gem_ctx_isolation@vcs1-dirty-create:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109276] /
[fdo#112080]) +2 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_ctx_isolat...@vcs1-dirty-create.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/shard-iclb3/igt@gem_ctx_isolat...@vcs1-dirty-create.html
* igt@gem_eio@in-flight-suspend:
- shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-kbl2/igt@gem_...@in-flight-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/shard-kbl2/igt@gem_...@in-flight-suspend.html
* igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#110854])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb2/igt@gem_exec_balan...@smoke.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/shard-iclb6/igt@gem_exec_balan...@smoke.html
* igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#112146]) +5 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb5/igt@gem_exec_sched...@in-order-bsd.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/shard-iclb4/igt@gem_exec_sched...@in-order-bsd.html
* igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109276]) +21 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15123/shard-iclb3/igt@gem_exec_sched...@independent-bsd2.html
* igt@gem_mmap_gtt@hang:
- shard-snb: [PASS][23] -> [INCOMPLETE][24] ([fdo#105411])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7258/shard-snb4/igt@gem_mmap_...@hang.html
[24]:
htt
Re: [Intel-gfx] [PATCH v2] drm/i915: update rawclk also on resume
On Mon, 04 Nov 2019, Ville Syrjälä wrote:
> On Fri, Nov 01, 2019 at 04:20:24PM +0200, Jani Nikula wrote:
>> Since CNP it's possible for rawclk to have two different values, 19.2
>> and 24 MHz. If the value indicated by SFUSE_STRAP register is different
>> from the power on default for PCH_RAWCLK_FREQ, we'll end up having a
>> mismatch between the rawclk hardware and software states after
>> suspend/resume. On previous platforms this used to work by accident,
>> because the power on defaults worked just fine.
>>
>> Update the rawclk also on resume. The natural place to do this would be
>> intel_modeset_init_hw(), however VLV/CHV need it done before
>> intel_power_domains_init_hw(). Thus put it there even if it feels
>> slightly out of place.
>>
>> v2: Call intel_update_rawclck() in intel_power_domains_init_hw() for all
>> platforms (Ville).
>>
>> Reported-by: Shawn Lee
>> Cc: Shawn Lee
>> Cc: Ville Syrjala
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Thanks for the testing and review, pushed to dinq.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/display/intel_display_power.c | 3 +++
>> drivers/gpu/drm/i915/i915_drv.c| 3 ---
>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
>> b/drivers/gpu/drm/i915/display/intel_display_power.c
>> index 707ac110e271..ce1b64f4dd44 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
>> @@ -5015,6 +5015,9 @@ void intel_power_domains_init_hw(struct
>> drm_i915_private *i915, bool resume)
>>
>> power_domains->initializing = true;
>>
>> +/* Must happen before power domain init on VLV/CHV */
>> +intel_update_rawclk(i915);
>> +
>> if (INTEL_GEN(i915) >= 11) {
>> icl_display_core_init(i915, resume);
>> } else if (IS_CANNONLAKE(i915)) {
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 3340485c12e3..71944399dcfc 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -296,9 +296,6 @@ static int i915_driver_modeset_probe(struct
>> drm_i915_private *i915)
>> if (ret)
>> goto cleanup_vga_client;
>>
>> -/* must happen before intel_power_domains_init_hw() on VLV/CHV */
>> -intel_update_rawclk(i915);
>> -
>> intel_power_domains_init_hw(i915, false);
>>
>> intel_csr_ucode_init(i915);
>> --
>> 2.20.1
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
