Re: [Mesa-dev] [RFC 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
śr., 19 maj 2021 o 01:41 Matthew Brost napisał(a):
>
> Add entry fpr i915 new parallel submission uAPI plan.
s/fpr/for/
>
> v2:
> (Daniel Vetter):
> - Expand logical order explaination
> - Add dummy header
> - Only allow N BBs in execbuf IOCTL
> - Configure parallel submission per slot not per gem context
>
> Cc: Tvrtko Ursulin
> Cc: Tony Ye
> CC: Carl Zhang
> Cc: Daniel Vetter
> Cc: Jason Ekstrand
> Signed-off-by: Matthew Brost
> ---
> Documentation/gpu/rfc/i915_parallel_execbuf.h | 144 ++
> Documentation/gpu/rfc/i915_scheduler.rst | 53 ++-
> 2 files changed, 196 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
>
> diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h
> b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> new file mode 100644
> index ..8c64b983ccad
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> @@ -0,0 +1,144 @@
> +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
> i915_context_engines_parallel_submit */
> +
> +/*
> + * i915_context_engines_parallel_submit:
> + *
> + * Setup a slot to allow multiple BBs to be submitted in a single execbuf
> IOCTL.
> + * Those BBs will then be scheduled to run on the GPU in parallel. Multiple
> + * hardware contexts are created internally in the i915 run these BBs. Once a
> + * slot is configured for N BBs only N BBs can be submitted in each execbuf
> + * IOCTL and this is implict behavior (e.g. the user doesn't tell the execbuf
> + * IOCTL there are N BBs, the execbuf IOCTL know how many BBs there are
> based on
> + * the slots configuration).
> + *
> + * Their are two currently defined ways to control the placement of the
s/Their/There/
> + * hardware contexts on physical engines: default behavior (no flags) and
> + * I915_PARALLEL_IMPLICT_BONDS (a flag). More flags may be added the in the
IMPLICIT? This typo is repeated multiple times
s/the in the/in the/
> + * future as new hardware / use cases arise. Details of how to use this
> + * interface below above the flags.
"below above"? :)
> + *
> + * Returns -EINVAL if hardware context placement configuration invalid or if
> the
is invalid
> + * placement configuration isn't supported on the platform / submission
> + * interface.
> + * Returns -ENODEV if extension isn't supported on the platform / submission
> + * inteface.
> + */
> +struct i915_context_engines_parallel_submit {
> + struct i915_user_extension base;
> +
> + __u16 engine_index; /* slot for parallel engine */
> + __u16 width;/* number of contexts per parallel engine */
> + __u16 num_siblings; /* number of siblings per context */
> + __u16 mbz16;
> +/*
> + * Default placement behvavior (currently unsupported):
behavior
> + *
> + * Rather than restricting parallel submission to a single class with a
> + * logically contiguous placement (I915_PARALLEL_IMPLICT_BONDS), add a mode
> that
> + * enables parallel submission across multiple engine classes. In this case
> each
> + * context's logical engine mask indicates where that context can placed. It
> is
can be placed
> + * implied in this mode that all contexts have mutual exclusive placement
> (e.g.
> + * if one context is running CS0 no other contexts can run on CS0).
> + *
> + * Example 1 pseudo code:
> + * CSX[Y] = engine class X, logical instance Y
> + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> + * set_engines(INVALID)
> + * set_parallel(engine_index=0, width=2, num_siblings=2,
> + * engines=CS0[0],CS0[1],CS1[0],CS1[1])
> + *
> + * Results in the following valid placements:
> + * CS0[0], CS1[0]
> + * CS0[0], CS1[1]
> + * CS0[1], CS1[0]
> + * CS0[1], CS1[1]
> + *
> + * This can also be though of as 2 virtual engines:
thought
(This typo repeats multiple times)
> + * VE[0] = CS0[0], CS0[1]
> + * VE[1] = CS1[0], CS1[1]
> + *
> + * Example 2 pseudo code:
> + * CS[X] = generic engine of same class, logical instance X
> + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> + * set_engines(INVALID)
> + * set_parallel(engine_index=0, width=2, num_siblings=3,
> + * engines=CS[0],CS[1],CS[2],CS[0],CS[1],CS[2])
> + *
> + * Results in the following valid placements:
> + * CS[0], CS[1]
> + * CS[0], CS[2]
> + * CS[1], CS[0]
> + * CS[1], CS[2]
> + * CS[2], CS[0]
> + * CS[2], CS[1]
> + *
> + *
> + * This can also be though of as 2 virtual engines:
> + * VE[0] = CS[0], CS[1], CS[2]
> + * VE[1] = CS[0], CS[1], CS[2]
> +
> + * This enables a use case where all engines are created equally, we don't
> care
> + * where they are scheduled, we just want a certain number of resources, for
> + * those resources to be scheduled in parallel, and possibly across multiple
> + * engine classes.
> + */
> +
> +/*
> + * I915_PARALLEL_IMPLICT_BONDS - Create implict bonds between each context.
> + * Each context must have the same number
[libdrm PATCH 2/2] configure.ac: don't detect disabled options dependencies
On Tue, Jan 19, 2016 at 10:26:16AM +0200, Emil Velikov wrote:
> Hi Marcin,
>
> On 9 January 2016 at 17:05, Marcin Ålusarz
> wrote:
> > Currently with --disable-amdgpu --disable-valgrind --disable-cairo-tests
> > cunit, valgrind and cairo are still detected.
> >
> Doesn't this patch make 1/2 obsolete ?
Yes, more or less. Both patches fix the issue I was seeing.
>
> > Signed-off-by: Marcin Ålusarz
>
> Reviewed-by: Emil Velikov
>
> > ---
> > configure.ac | 36 ++--
> > 1 file changed, 22 insertions(+), 14 deletions(-)
> >
> > diff --git a/configure.ac b/configure.ac
> > index c8c4ace..cc44e3f 100644
> > --- a/configure.ac
> > +++ b/configure.ac
>
> > @@ -400,7 +404,9 @@ AC_ARG_ENABLE([cairo-tests],
> >[AS_HELP_STRING([--enable-cairo-tests],
> >[Enable support for Cairo rendering in tests
> > (default: auto)])],
> >[CAIRO=$enableval], [CAIRO=auto])
> > -PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
> > +if test "x$CAIRO" != xno; then
> > + PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
> > +fi
> Namely: if we have disable-cairo-tests, the module will never be
> checked, thus CAIRO_{CFLAGS,LIBS} will be empty. Obviously the user
> can explicitly sets the CAIRO_* variables, in which case they're
> cutting the branch they're standing on.
>
> Please let me know if you'd prefer to have 1/2 regardless (or if I
> missed something)
I thought it would be better to have cairo build flags guarded by global
HAVE_CAIRO flag. If you want to apply just this patch, that's fine by me.
>
> Thank you for sorting these.
Thanks,
Marcin
[libdrm PATCH 2/2] configure.ac: don't detect disabled options dependencies
Currently with --disable-amdgpu --disable-valgrind --disable-cairo-tests
cunit, valgrind and cairo are still detected.
Signed-off-by: Marcin Ålusarz
---
configure.ac | 36 ++--
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/configure.ac b/configure.ac
index c8c4ace..cc44e3f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -359,19 +359,23 @@ if test "x$RADEON" = xyes; then
AC_DEFINE(HAVE_RADEON, 1, [Have radeon support])
fi
-# Detect cunit library
-PKG_CHECK_MODULES([CUNIT], [cunit >= 2.1], [have_cunit=yes], [have_cunit=no])
-# If pkg-config does not find cunit, check it using AC_CHECK_LIB. We
-# do this because Debian (Ubuntu) lacks pkg-config file for cunit.
-# fixed in 2.1-2.dfsg-3:
http://anonscm.debian.org/cgit/collab-maint/cunit.git/commit/?h=debian
-if test "x${have_cunit}" = "xno"; then
- AC_CHECK_LIB([cunit], [CU_initialize_registry], [have_cunit=yes],
[have_cunit=no])
- if test "x${have_cunit}" = "xyes"; then
- CUNIT_LIBS="-lcunit"
- CUNIT_CFLAGS=""
- AC_SUBST([CUNIT_LIBS])
- AC_SUBST([CUNIT_CFLAGS])
+if test "x$AMDGPU" != xno; then
+ # Detect cunit library
+ PKG_CHECK_MODULES([CUNIT], [cunit >= 2.1], [have_cunit=yes],
[have_cunit=no])
+ # If pkg-config does not find cunit, check it using AC_CHECK_LIB. We
+ # do this because Debian (Ubuntu) lacks pkg-config file for cunit.
+ # fixed in 2.1-2.dfsg-3:
http://anonscm.debian.org/cgit/collab-maint/cunit.git/commit/?h=debian
+ if test "x${have_cunit}" = "xno"; then
+ AC_CHECK_LIB([cunit], [CU_initialize_registry],
[have_cunit=yes], [have_cunit=no])
+ if test "x${have_cunit}" = "xyes"; then
+ CUNIT_LIBS="-lcunit"
+ CUNIT_CFLAGS=""
+ AC_SUBST([CUNIT_LIBS])
+ AC_SUBST([CUNIT_CFLAGS])
+ fi
fi
+else
+ have_cunit=no
fi
AM_CONDITIONAL(HAVE_CUNIT, [test "x$have_cunit" != "xno"])
@@ -400,7 +404,9 @@ AC_ARG_ENABLE([cairo-tests],
[AS_HELP_STRING([--enable-cairo-tests],
[Enable support for Cairo rendering in tests
(default: auto)])],
[CAIRO=$enableval], [CAIRO=auto])
-PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
+if test "x$CAIRO" != xno; then
+ PKG_CHECK_MODULES(CAIRO, cairo, [HAVE_CAIRO=yes], [HAVE_CAIRO=no])
+fi
AC_MSG_CHECKING([whether to enable Cairo tests])
if test "x$CAIRO" = xauto; then
CAIRO="$HAVE_CAIRO"
@@ -445,7 +451,9 @@ AC_ARG_ENABLE(valgrind,
[AS_HELP_STRING([--enable-valgrind],
[Build libdrm with valgrind support (default:
auto)])],
[VALGRIND=$enableval], [VALGRIND=auto])
-PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes],
[have_valgrind=no])
+if test "x$VALGRIND" != xno; then
+ PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes],
[have_valgrind=no])
+fi
AC_MSG_CHECKING([whether to enable Valgrind support])
if test "x$VALGRIND" = xauto; then
VALGRIND="$have_valgrind"
--
2.1.4
[libdrm PATCH 1/2] tests: don't link to libcairo when it was disabled
Currently it's possible to have non-empty CAIRO_LIBS (because cairo was (mis)detected) and HAVE_CAIRO=0 (because user supplied --disable-cairo-tests). Signed-off-by: Marcin Ålusarz --- tests/kms/Makefile.am | 9 +++-- tests/modetest/Makefile.am | 5 - tests/util/Makefile.am | 2 ++ 3 files changed, 13 insertions(+), 3 deletions(-) diff --git a/tests/kms/Makefile.am b/tests/kms/Makefile.am index 6645af7..1003829 100644 --- a/tests/kms/Makefile.am +++ b/tests/kms/Makefile.am @@ -30,7 +30,12 @@ noinst_PROGRAMS = \ endif kms_steal_crtc_SOURCES = kms-steal-crtc.c -kms_steal_crtc_LDADD = libkms-test.la ../util/libutil.la $(CAIRO_LIBS) +kms_steal_crtc_LDADD = libkms-test.la ../util/libutil.la kms_universal_planes_SOURCES = kms-universal-planes.c -kms_universal_planes_LDADD = libkms-test.la $(CAIRO_LIBS) +kms_universal_planes_LDADD = libkms-test.la + +if HAVE_CAIRO +kms_steal_crtc_LDADD += $(CAIRO_LIBS) +kms_universal_planes_LDADD += $(CAIRO_LIBS) +endif diff --git a/tests/modetest/Makefile.am b/tests/modetest/Makefile.am index 25ce372..40dad3e 100644 --- a/tests/modetest/Makefile.am +++ b/tests/modetest/Makefile.am @@ -20,7 +20,10 @@ modetest_SOURCES = $(MODETEST_FILES) modetest_LDADD = \ $(top_builddir)/libdrm.la \ $(top_builddir)/tests/util/libutil.la \ - $(CAIRO_LIBS) \ -lpthread +if HAVE_CAIRO +modetest_LDADD += $(CAIRO_LIBS) +endif + EXTRA_DIST = Android.mk diff --git a/tests/util/Makefile.am b/tests/util/Makefile.am index f8e0b17..f366f26 100644 --- a/tests/util/Makefile.am +++ b/tests/util/Makefile.am @@ -7,7 +7,9 @@ libutil_la_CPPFLAGS = \ -I$(top_srcdir)/include/drm \ -I$(top_srcdir) +if HAVE_CAIRO libutil_la_CFLAGS = \ $(CAIRO_CFLAGS) +endif libutil_la_SOURCES = $(UTIL_FILES) -- 2.1.4
oops in reservation_object_wait_timeout_rcu
BUG: unable to handle kernel paging request at c90003161018 IP: [] reservation_object_wait_timeout_rcu+0x35c/0x580 PGD 13a89a067 PUD 13a89b067 PMD 136735067 PTE 0 Oops: [#1] PREEMPT SMP Modules linked in: ctr ccm rfcomm bnep arc4 iwldvm mac80211 binfmt_misc iwlwifi cfg80211 rtsx_usb uvcvideo btusb btbcm btintel bluetooth videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common snd_hda_codec_hdmi videodev snd_hda_codec_idt snd_hda_codec_generic dell_wmi snd_hda_intel sparse_keymap dell_laptop dcdbas snd_hda_controller snd_hda_codec x86_pkg_temp_thermal coretemp snd_hwdep snd_pcm snd_hda_core microcode snd_seq_midi snd_seq_midi_event serio_raw snd_rawmidi snd_seq snd_timer snd_seq_device snd lpc_ich soundcore parport_pc ppdev lp parport hid_generic nouveau mxm_wmi ttm i915 psmouse i2c_algo_bit drm_kms_helper ahci libahci usbhid drm hid wmi video CPU: 1 PID: 920 Comm: Xorg Not tainted 4.1.2+ #57 Hardware name: Dell Inc. Inspiron 7720/04M3YM, BIOS A07 08/16/2012 task: 880136dec2c0 ti: 880136de4000 task.ti: 880136de4000 RIP: 0010:[] [] reservation_object_wait_timeout_rcu+0x35c/0x580 RSP: 0018:880136de7c78 EFLAGS: 00010246 RAX: c90003161000 RBX: 8800ab123b00 RCX: ab123200 RDX: ab123200 RSI: RDI: 81c5be00 RBP: 880136de7cd8 R08: R09: R10: R11: 880136de7d80 R12: R13: 1d4c R14: c326 R15: 88003290a1b8 FS: 7f29a7237980() GS:88013f24() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: c90003161018 CR3: 32cf8000 CR4: 001407e0 Stack: 8157ce70 8800336a8898 000136de7ca8 88003290a250 88004711ce40 00020190a3f0 880136de7cd8 fff0 88003290a000 88003290a3f0 0082 Call Trace: [] ? reservation_object_wait_timeout_rcu+0xa0/0x580 [] nouveau_gem_ioctl_cpu_prep+0x6d/0x190 [nouveau] [] ? might_fault+0x8b/0xa0 [] drm_ioctl+0x1a5/0x6b0 [drm] [] ? trace_hardirqs_on+0xd/0x10 [] ? _raw_spin_unlock_irqrestore+0x42/0x80 [] nouveau_drm_ioctl+0x72/0xd0 [nouveau] [] do_vfs_ioctl+0x308/0x540 [] ? __fget+0x5/0x210 [] ? __fget_light+0x2a/0xa0 [] SyS_ioctl+0x81/0xa0 [] system_call_fastpath+0x16/0x73 Code: d5 a1 81 be c7 03 00 00 48 c7 c7 25 d0 a1 81 c6 05 d0 66 7a 00 01 e8 34 eb b8 ff e9 f5 fd ff ff 0f 1f 80 00 00 00 00 48 8b 43 08 <48> 8b 40 18 48 85 c0 0f 84 c7 fd ff ff 48 89 df ff d0 84 c0 0f RIP [] reservation_object_wait_timeout_rcu+0x35c/0x580 RSP CR2: c90003161018 ---[ end trace c4e9ff6a0281167a ]--- Happened once, while I was "testing" Portal.
[Intel-gfx] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:1262!
On Sun, Jan 04, 2015 at 08:45:58PM +, Chris Wilson wrote: > On Sun, Jan 04, 2015 at 03:33:05PM +0100, Marcin Ålusarz wrote: > > [432102.923209] kernel BUG at drivers/gpu/drm/i915/i915_gem.c:1262! > > [432102.923237] invalid opcode: [#1] PREEMPT SMP > > [432102.923262] Modules linked in: uas usb_storage dm_crypt ctr ccm arc4 > > iwldvm mac80211 iwlwifi cfg80211 rfcomm bnep uvcvideo rtsx_usb > > videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev > > snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic dell_laptop > > dell_wmi sparse_keymap snd_hda_intel snd_hda_controller snd_hda_codec > > dcdbas btusb snd_hwdep snd_pcm bluetooth snd_seq_midi snd_seq_midi_event > > x86_pkg_temp_thermal snd_rawmidi snd_seq coretemp ghash_clmulni_intel > > cryptd snd_timer snd_seq_device microcode snd soundcore serio_raw lpc_ich > > mac_hid parport_pc ppdev lp parport binfmt_misc hid_generic usbhid hid > > nouveau i915 psmouse mxm_wmi ttm i2c_algo_bit ahci libahci drm_kms_helper > > drm wmi video > > [432102.923617] CPU: 2 PID: 45 Comm: kswapd0 Tainted: GW > > 3.17.0 #50 > > [432102.923650] Hardware name: Dell Inc. Inspiron 7720/04M3YM, > > BIOS A07 08/16/2012 > > [432102.923685] task: 88013766a130 ti: 8801376c8000 task.ti: > > 8801376c8000 > > [432102.923719] RIP: 0010:[] [] > > i915_wait_seqno+0x7c/0xa0 [i915] > > [432102.923781] RSP: 0018:8801376cbaf8 EFLAGS: 00010246 > > [432102.923804] RAX: 0001 RBX: 88003287 RCX: > > 0018 > > [432102.923835] RDX: 88008d033908 RSI: 005c4f93 RDI: > > 880032872680 > > [432102.923870] RBP: 8801376cbb18 R08: R09: > > > > [432102.923901] R10: R11: ea402c80 R12: > > 880032872680 > > [432102.923932] R13: 88008d032c00 R14: 0001 R15: > > 88003287 > > [432102.923966] FS: () GS:88013f28() > > knlGS: > > [432102.924002] CS: 0010 DS: ES: CR0: 80050033 > > [432102.924030] CR2: 7f3d465dc000 CR3: 000102ada000 CR4: > > 001407e0 > > [432102.924073] Stack: > > [432102.924087] 88008d032c00 88008d032cf0 88008d032c00 > > 88003287 > > [432102.924133] 8801376cbb30 a0123627 88008d032c00 > > 8801376cbb48 > > [432102.924169] a0123664 880104b4b000 8801376cbb78 > > a0126e48 > > [432102.924205] Call Trace: > > [432102.924238] [] > > i915_gem_object_wait_rendering+0x37/0x60 [i915] > > [432102.924287] [] > > i915_gem_object_finish_gpu.part.53+0x14/0x30 [i915] > > [432102.924339] [] i915_vma_unbind+0x118/0x240 [i915] > > [432102.924380] [] __i915_gem_shrink+0x1ec/0x2c0 [i915] > > [432102.924422] [] i915_gem_shrinker_scan+0x68/0xa0 > > [i915] > > [432102.924465] [] shrink_slab_node+0x138/0x2f0 > > [432102.924494] [] ? shrink_slab+0x3f/0x160 > > [432102.924521] [] shrink_slab+0x8b/0x160 > > [432102.924548] [] balance_pgdat+0x388/0x5a0 > > [432102.924575] [] kswapd+0x180/0x470 > > [432102.924601] [] ? prepare_to_wait_event+0x110/0x110 > > [432102.924635] [] ? balance_pgdat+0x5a0/0x5a0 > > [432102.924670] [] kthread+0xfc/0x120 > > [432102.924693] [] ? kthread_create_on_node+0x230/0x230 > > [432102.924730] [] ret_from_fork+0x7c/0xb0 > > [432102.924755] [] ? kthread_create_on_node+0x230/0x230 > > [432102.924786] Code: 0f 1f 80 00 00 00 00 8b 93 a0 9d 00 00 41 0f b6 ce 44 > > 89 ee 4c 89 e7 45 31 c9 45 31 c0 e8 ed ea ff ff 5b 41 5c 41 5d 41 5e 5d c3 > > <0f> 0b 45 84 f6 74 13 8b 83 a0 9d 00 00 c1 f8 1f 83 e0 06 83 e8 > > [432102.924965] RIP [] i915_wait_seqno+0x7c/0xa0 [i915] > > [432102.925104] RSP > > [432102.935737] ---[ end trace 95ef281295f96d84 ]--- > > > > It's BUG_ON(!mutex_is_locked(>struct_mutex)) in i915_wait_seqno. > > Warnings are from WARN_ON(!mutex_is_locked(>struct_mutex)) in > > intel_fb_obj_invalidate. > > > > dev->struct_mutex is locked from i915_gem_shrinker_scan, so something > > unlocks > > it when we reach intel_fb_obj_invalidate/i915_wait_seqno. > > What does 'grep DEBUG_MUTEXES .config' say? CONFIG_DEBUG_MUTEXES=y full config: http://people.freedesktop.org/~mslusarz/config.txt Marcin
kernel BUG at drivers/gpu/drm/i915/i915_gem.c:1262!
[432102.922022] [ cut here ] [432102.922173] WARNING: CPU: 2 PID: 45 at drivers/gpu/drm/i915/intel_display.c:8979 intel_fb_obj_invalidate+0xdb/0xe0 [i915]() [432102.922178] Modules linked in: uas usb_storage dm_crypt ctr ccm arc4 iwldvm mac80211 iwlwifi cfg80211 rfcomm bnep uvcvideo rtsx_usb videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic dell_laptop dell_wmi sparse_keymap snd_hda_intel snd_hda_controller snd_hda_codec dcdbas btusb snd_hwdep snd_pcm bluetooth snd_seq_midi snd_seq_midi_event x86_pkg_temp_thermal snd_rawmidi snd_seq coretemp ghash_clmulni_intel cryptd snd_timer snd_seq_device microcode snd soundcore serio_raw lpc_ich mac_hid parport_pc ppdev lp parport binfmt_misc hid_generic usbhid hid nouveau i915 psmouse mxm_wmi ttm i2c_algo_bit ahci libahci drm_kms_helper drm wmi video [432102.922241] CPU: 2 PID: 45 Comm: kswapd0 Not tainted 3.17.0 #50 [432102.922243] Hardware name: Dell Inc. Inspiron 7720/04M3YM, BIOS A07 08/16/2012 [432102.922246] 0009 8801376cba60 81707891 [432102.922251] 8801376cba98 8109832d 88000aef3200 880034486000 [432102.922256] 88003287 88003287 8801376cbaa8 [432102.922261] Call Trace: [432102.922272] [] dump_stack+0x4e/0x7a [432102.922277] [] warn_slowpath_common+0x7d/0xa0 [432102.922281] [] warn_slowpath_null+0x1a/0x20 [432102.922299] [] intel_fb_obj_invalidate+0xdb/0xe0 [i915] [432102.922314] [] i915_gem_object_set_to_cpu_domain+0x9e/0x1f0 [i915] [432102.922328] [] i915_gem_object_put_pages_gtt+0x31/0x1a0 [i915] [432102.922342] [] i915_gem_object_put_pages+0xb5/0x140 [i915] [432102.922356] [] __i915_gem_shrink+0x1f9/0x2c0 [i915] [432102.922369] [] i915_gem_shrinker_scan+0x68/0xa0 [i915] [432102.922376] [] shrink_slab_node+0x138/0x2f0 [432102.922379] [] ? shrink_slab+0x3f/0x160 [432102.922382] [] shrink_slab+0x8b/0x160 [432102.922386] [] balance_pgdat+0x388/0x5a0 [432102.922389] [] kswapd+0x180/0x470 [432102.922394] [] ? prepare_to_wait_event+0x110/0x110 [432102.922397] [] ? balance_pgdat+0x5a0/0x5a0 [432102.922401] [] kthread+0xfc/0x120 [432102.922405] [] ? kthread_create_on_node+0x230/0x230 [432102.922410] [] ret_from_fork+0x7c/0xb0 [432102.922413] [] ? kthread_create_on_node+0x230/0x230 [432102.922415] ---[ end trace 95ef281295f96d81 ]--- [432102.922431] [ cut here ] [432102.922465] WARNING: CPU: 2 PID: 45 at drivers/gpu/drm/i915/intel_display.c:8979 intel_fb_obj_invalidate+0xdb/0xe0 [i915]() [432102.922468] Modules linked in: uas usb_storage dm_crypt ctr ccm arc4 iwldvm mac80211 iwlwifi cfg80211 rfcomm bnep uvcvideo rtsx_usb videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic dell_laptop dell_wmi sparse_keymap snd_hda_intel snd_hda_controller snd_hda_codec dcdbas btusb snd_hwdep snd_pcm bluetooth snd_seq_midi snd_seq_midi_event x86_pkg_temp_thermal snd_rawmidi snd_seq coretemp ghash_clmulni_intel cryptd snd_timer snd_seq_device microcode snd soundcore serio_raw lpc_ich mac_hid parport_pc ppdev lp parport binfmt_misc hid_generic usbhid hid nouveau i915 psmouse mxm_wmi ttm i2c_algo_bit ahci libahci drm_kms_helper drm wmi video [432102.922523] CPU: 2 PID: 45 Comm: kswapd0 Tainted: GW 3.17.0 #50 [432102.922526] Hardware name: Dell Inc. Inspiron 7720/04M3YM, BIOS A07 08/16/2012 [432102.922528] 0009 8801376cba60 81707891 [432102.922532] 8801376cba98 8109832d 88008d032400 880034486000 [432102.922536] 88003287 88003287 8801376cbaa8 [432102.922539] Call Trace: [432102.922546] [] dump_stack+0x4e/0x7a [432102.922550] [] warn_slowpath_common+0x7d/0xa0 [432102.922552] [] warn_slowpath_null+0x1a/0x20 [432102.922586] [] intel_fb_obj_invalidate+0xdb/0xe0 [i915] [432102.922606] [] i915_gem_object_set_to_cpu_domain+0x9e/0x1f0 [i915] [432102.922623] [] i915_gem_object_put_pages_gtt+0x31/0x1a0 [i915] [432102.922637] [] i915_gem_object_put_pages+0xb5/0x140 [i915] [432102.922652] [] __i915_gem_shrink+0x1f9/0x2c0 [i915] [432102.922669] [] i915_gem_shrinker_scan+0x68/0xa0 [i915] [432102.922679] [] shrink_slab_node+0x138/0x2f0 [432102.922682] [] ? shrink_slab+0x3f/0x160 [432102.922685] [] shrink_slab+0x8b/0x160 [432102.922688] [] balance_pgdat+0x388/0x5a0 [432102.922691] [] kswapd+0x180/0x470 [432102.922696] [] ? prepare_to_wait_event+0x110/0x110 [432102.922698] [] ? balance_pgdat+0x5a0/0x5a0 [432102.922705] [] kthread+0xfc/0x120 [432102.922710] [] ? kthread_create_on_node+0x230/0x230 [432102.922715] [] ret_from_fork+0x7c/0xb0 [432102.922719] [] ? kthread_create_on_node+0x230/0x230 [432102.922722] ---[ end trace 95ef281295f96d82 ]--- [432102.922850] [ cut here ]
v3.17, i915 vs nouveau: possible recursive locking detected
=
[ INFO: possible recursive locking detected ]
3.17.0 #50 Not tainted
-
Xorg/1170 is trying to acquire lock:
(>struct_mutex){+.+.+.}, at: []
i915_gem_unmap_dma_buf+0x33/0xc0 [i915]
but task is already holding lock:
(>struct_mutex){+.+.+.}, at: []
drm_gem_object_handle_unreference_unlocked+0xca/0x120 [drm]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(>struct_mutex);
lock(>struct_mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
1 lock held by Xorg/1170:
#0: (>struct_mutex){+.+.+.}, at: []
drm_gem_object_handle_unreference_unlocked+0xca/0x120 [drm]
stack backtrace:
CPU: 1 PID: 1170 Comm: Xorg Not tainted 3.17.0 #50
Hardware name: Dell Inc. Inspiron 7720/04M3YM, BIOS A07 08/16/2012
82606b80 880136e27b00 81707891 82606b80
880136e27bb8 810e0e4f 00020200c795
0001 004ec276 0300
Call Trace:
[] dump_stack+0x4e/0x7a
[] __lock_acquire+0x194f/0x19e0
[] lock_acquire+0x91/0x120
[] ? i915_gem_unmap_dma_buf+0x33/0xc0 [i915]
[] ? i915_gem_unmap_dma_buf+0x33/0xc0 [i915]
[] mutex_lock_nested+0x54/0x3d0
[] ? i915_gem_unmap_dma_buf+0x33/0xc0 [i915]
[] ? mark_held_locks+0x6a/0x90
[] i915_gem_unmap_dma_buf+0x33/0xc0 [i915]
[] dma_buf_unmap_attachment+0x22/0x40
[] drm_prime_gem_destroy+0x22/0x40 [drm]
[] nouveau_gem_object_del+0x3b/0x60 [nouveau]
[] drm_gem_object_free+0x27/0x30 [drm]
[] drm_gem_object_handle_unreference_unlocked+0xe4/0x120
[drm]
[] drm_gem_handle_delete+0xba/0x110 [drm]
[] drm_gem_close_ioctl+0x25/0x30 [drm]
[] drm_ioctl+0x1ec/0x660 [drm]
[] ? __pm_runtime_resume+0x32/0x60
[] ? _raw_spin_unlock_irqrestore+0x5d/0x70
[] ? trace_hardirqs_on_caller+0xfd/0x1c0
[] ? trace_hardirqs_on+0xd/0x10
[] ? _raw_spin_unlock_irqrestore+0x42/0x70
[] nouveau_drm_ioctl+0x54/0xc0 [nouveau]
[] do_vfs_ioctl+0x300/0x520
[] ? __fget+0xad/0xe0
[] ? __fget+0x5/0xe0
[] SyS_ioctl+0x81/0xa0
[] system_call_fastpath+0x1a/0x1f
[PATCH] fence: dma-buf cross-device synchronization (v13)
2013/8/15 Maarten Lankhorst :
> A fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device. For example, userspace can call page_flip ioctl to display the
> next frame of graphics after kicking the GPU but while the GPU is still
> rendering. The display device sharing the buffer with the GPU would
> attach a callback to get notified when the GPU's rendering-complete IRQ
> fires, to update the scan-out address of the display, without having to
> wake up userspace.
>
> A driver must allocate a fence context for each execution ring that can
> run in parallel. The function for this takes an argument with how many
> contexts to allocate:
> + fence_context_alloc()
>
> A fence is transient, one-shot deal. It is allocated and attached
> to one or more dma-buf's. When the one that attached it is done, with
> the pending operation, it can signal the fence:
> + fence_signal()
>
> To have a rough approximation whether a fence is fired, call:
> + fence_is_signaled()
>
> The dma-buf-mgr handles tracking, and waiting on, the fences associated
> with a dma-buf.
>
> The one pending on the fence can add an async callback:
> + fence_add_callback()
>
> The callback can optionally be cancelled with:
> + fence_remove_callback()
>
> To wait synchronously, optionally with a timeout:
> + fence_wait()
> + fence_wait_timeout()
>
> A default software-only implementation is provided, which can be used
> by drivers attaching a fence to a buffer when they have no other means
> for hw sync. But a memory backed fence is also envisioned, because it
> is common that GPU's can write to, or poll on some memory location for
> synchronization. For example:
>
> fence = custom_get_fence(...);
> if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
> dma_buf *fence_buf = fence->sync_buf;
> get_dma_buf(fence_buf);
>
> ... tell the hw the memory location to wait ...
> custom_wait_on(fence_buf, fence->seqno_ofs, fence->seqno);
> } else {
> /* fall-back to sw sync * /
> fence_add_callback(fence, my_cb);
> }
>
> On SoC platforms, if some other hw mechanism is provided for synchronizing
> between IP blocks, it could be supported as an alternate implementation
> with it's own fence ops in a similar way.
>
> enable_signaling callback is used to provide sw signaling in case a cpu
> waiter is requested or no compatible hardware signaling could be used.
>
> The intention is to provide a userspace interface (presumably via eventfd)
> later, to be used in conjunction with dma-buf's mmap support for sw access
> to buffers (or for userspace apps that would prefer to do their own
> synchronization).
>
> v1: Original
> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
> that dma-fence didn't need to care about the sw->hw signaling path
> (it can be handled same as sw->sw case), and therefore the fence->ops
> can be simplified and more handled in the core. So remove the signal,
> add_callback, cancel_callback, and wait ops, and replace with a simple
> enable_signaling() op which can be used to inform a fence supporting
> hw->hw signaling that one or more devices which do not support hw
> signaling are waiting (and therefore it should enable an irq or do
> whatever is necessary in order that the CPU is notified when the
> fence is passed).
> v3: Fix locking fail in attach_fence() and get_fence()
> v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
> we decided that we need to be able to attach one fence to N dma-buf's,
> so using the list_head in dma-fence struct would be problematic.
> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some
> comments
> about checking if fence fired or not. This is broken by design.
> waitqueue_active during destruction is now fatal, since the signaller
> should be holding a reference in enable_signalling until it signalled
> the fence. Pass the original dma_fence_cb along, and call __remove_wait
> in the dma_fence_callback handler, so that no cleanup needs to be
> performed.
> v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
> fence wasn't signaled yet, for example for hardware fences that may
> choose to signal blindly.
> v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
> header and fixed include mess. dma-fence.h now includes dma-buf.h
> All members are now initialized, so kmalloc can be used for
> allocating a dma-fence. More documentation added.
> v9: Change compiler bitfields to flags, change return type of
> enable_signaling to bool. Rework dma_fence_wait. Added
> dma_fence_is_signaled and dma_fence_wait_timeout.
> s/dma// and change exports to non GPL. Added fence_is_signaled and
>
Re: [PATCH] fence: dma-buf cross-device synchronization (v13)
2013/8/15 Maarten Lankhorst maarten.lankho...@canonical.com:
A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering. The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.
A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
+ fence_context_alloc()
A fence is transient, one-shot deal. It is allocated and attached
to one or more dma-buf's. When the one that attached it is done, with
the pending operation, it can signal the fence:
+ fence_signal()
To have a rough approximation whether a fence is fired, call:
+ fence_is_signaled()
The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.
The one pending on the fence can add an async callback:
+ fence_add_callback()
The callback can optionally be cancelled with:
+ fence_remove_callback()
To wait synchronously, optionally with a timeout:
+ fence_wait()
+ fence_wait_timeout()
A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync. But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization. For example:
fence = custom_get_fence(...);
if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = fence-sync_buf;
get_dma_buf(fence_buf);
... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, fence-seqno_ofs, fence-seqno);
} else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
}
On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.
enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.
The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).
v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw-hw signaling path
(it can be handled same as sw-sw case), and therefore the fence-ops
can be simplified and more handled in the core. So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw-hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some
comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb-func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override default
wait operation.
v10:
[PATCH V3] get_maintainer: use filename-only regex match for Tegra
11 mar 2013 21:19, "Stephen Warren" napisa?(a):
>
> From: Stephen Warren
>
> Create a new N: entry type in MAINTAINERS which performs a regex match
> against filenames; either those extracted from patch +++ or --- lines,
> or those specified on the command-line using the -f option.
>
> This provides the same benefits as using a K: regex option to match a
> set of filenames (see commit eb90d08 "get_maintainer: allow keywords to
> match filenames"), but without the disadvantage that "random" file
> content, such as comments, will ever match the regex. Hence, revert most
> of that commit.
>
> Switch the Tegra entry from using K: to N:
>
> Reported-by: Marcin Slusarz
> Suggested-by: Joe Perches
> Signed-off-by: Stephen Warren
> ---
> v2: Corrected typo in MAINTAINERS documentation
> v3: Squash 3 patches into one.
> ---
> MAINTAINERS | 14 --
> scripts/get_maintainer.pl |2 +-
> 2 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9561658..e68a07a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -90,6 +90,9 @@ Descriptions of section entries:
>F: drivers/net/* all files in drivers/net, but not below
>F: */net/* all files in "any top level directory"/net
>One pattern per line. Multiple F: lines acceptable.
> + N: Files and directories with regex patterns.
> + N: [^a-z]tegra all files whose patch contains the word
tegra
s/patch/path/ ?
> + One pattern per line. Multiple N: lines acceptable.
> X: Files and directories that are NOT maintained, same rules as F:
>Files exclusions are tested before file matches.
>Can be useful for excluding a specific subdirectory, for
instance:
> @@ -97,13 +100,12 @@ Descriptions of section entries:
>X: net/ipv6/
>matches all files in and below net excluding net/ipv6/
> K: Keyword perl extended regex pattern to match content in a
> - patch or file, or an affected filename. For instance:
> + patch or file. For instance:
>K: of_get_profile
> - matches patch or file content, or filenames, that contain
> - "of_get_profile"
> + matches patches or files that contain "of_get_profile"
>K: \b(printk|pr_(info|err))\b
> - matches patch or file content, or filenames, that contain
one or
> - more of the words printk, pr_info or pr_err
> + matches patches or files that contain one or more of the
words
> + printk, pr_info or pr_err
>One regex pattern per line. Multiple K: lines acceptable.
>
> Note: For the hard of thinking, this list is meant to remain in
alphabetical
> @@ -7848,7 +7850,7 @@ L:linux-tegra at vger.kernel.org
> Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
> T: git git://
git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
> S: Supported
> -K: (?i)[^a-z]tegra
> +N: [^a-z]tegra
>
> TEHUTI ETHERNET DRIVER
> M: Andy Gospodarek
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index ce4cc83..5e4fb14 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -611,7 +611,7 @@ sub get_maintainers {
> $hash{$tvi} = $value_pd;
> }
> }
> - } elsif ($type eq 'K') {
> + } elsif ($type eq 'N') {
> if ($file =~ m/$value/x) {
> $hash{$tvi} = 0;
> }
> --
> 1.7.10.4
>
-- next part --
An HTML attachment was scrubbed...
URL:
Re: [PATCH V3] get_maintainer: use filename-only regex match for Tegra
11 mar 2013 21:19, Stephen Warren swar...@wwwdotorg.org napisał(a):
From: Stephen Warren swar...@nvidia.com
Create a new N: entry type in MAINTAINERS which performs a regex match
against filenames; either those extracted from patch +++ or --- lines,
or those specified on the command-line using the -f option.
This provides the same benefits as using a K: regex option to match a
set of filenames (see commit eb90d08 get_maintainer: allow keywords to
match filenames), but without the disadvantage that random file
content, such as comments, will ever match the regex. Hence, revert most
of that commit.
Switch the Tegra entry from using K: to N:
Reported-by: Marcin Slusarz marcin.slus...@gmail.com
Suggested-by: Joe Perches j...@perches.com
Signed-off-by: Stephen Warren swar...@nvidia.com
---
v2: Corrected typo in MAINTAINERS documentation
v3: Squash 3 patches into one.
---
MAINTAINERS | 14 --
scripts/get_maintainer.pl |2 +-
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9561658..e68a07a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -90,6 +90,9 @@ Descriptions of section entries:
F: drivers/net/* all files in drivers/net, but not below
F: */net/* all files in any top level directory/net
One pattern per line. Multiple F: lines acceptable.
+ N: Files and directories with regex patterns.
+ N: [^a-z]tegra all files whose patch contains the word
tegra
s/patch/path/ ?
+ One pattern per line. Multiple N: lines acceptable.
X: Files and directories that are NOT maintained, same rules as F:
Files exclusions are tested before file matches.
Can be useful for excluding a specific subdirectory, for
instance:
@@ -97,13 +100,12 @@ Descriptions of section entries:
X: net/ipv6/
matches all files in and below net excluding net/ipv6/
K: Keyword perl extended regex pattern to match content in a
- patch or file, or an affected filename. For instance:
+ patch or file. For instance:
K: of_get_profile
- matches patch or file content, or filenames, that contain
- of_get_profile
+ matches patches or files that contain of_get_profile
K: \b(printk|pr_(info|err))\b
- matches patch or file content, or filenames, that contain
one or
- more of the words printk, pr_info or pr_err
+ matches patches or files that contain one or more of the
words
+ printk, pr_info or pr_err
One regex pattern per line. Multiple K: lines acceptable.
Note: For the hard of thinking, this list is meant to remain in
alphabetical
@@ -7848,7 +7850,7 @@ L:linux-te...@vger.kernel.org
Q: http://patchwork.ozlabs.org/project/linux-tegra/list/
T: git git://
git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git
S: Supported
-K: (?i)[^a-z]tegra
+N: [^a-z]tegra
TEHUTI ETHERNET DRIVER
M: Andy Gospodarek a...@greyhouse.net
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index ce4cc83..5e4fb14 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -611,7 +611,7 @@ sub get_maintainers {
$hash{$tvi} = $value_pd;
}
}
- } elsif ($type eq 'K') {
+ } elsif ($type eq 'N') {
if ($file =~ m/$value/x) {
$hash{$tvi} = 0;
}
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Pretty print out the reason for rejecting the mode
2011/4/5 Chris Wilson :
> Signed-off-by: Chris Wilson
> ---
> ?drivers/gpu/drm/drm_modes.c | ? 52 +-
> ?1 files changed, 50 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 25bf873..b3e07ac 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -853,6 +853,52 @@ void drm_mode_validate_clocks(struct drm_device *dev,
> ?}
> ?EXPORT_SYMBOL(drm_mode_validate_clocks);
>
> +static const char *mode_status_to_string(enum drm_mode_status status)
> +{
> + ? ? ? const char *strings[] = {
+ static?
> + ? ? ? ? ? ? ? [MODE_OK] = "OK",
> + ? ? ? ? ? ? ? [MODE_HSYNC] = "hsync out of range",
> + ? ? ? ? ? ? ? [MODE_VSYNC] = "vsync out of range",
> + ? ? ? ? ? ? ? [MODE_H_ILLEGAL] = "illegal horizontal timings",
> + ? ? ? ? ? ? ? [MODE_V_ILLEGAL] = "illegal vertical timings",
> + ? ? ? ? ? ? ? [MODE_BAD_WIDTH] = "requires an unsupported linepitch",
> + ? ? ? ? ? ? ? [MODE_NOMODE] = "no mode with a maching name",
s/maching/matching/
> + ? ? ? ? ? ? ? [MODE_NO_INTERLACE] = "interlaced mode not supported",
> + ? ? ? ? ? ? ? [MODE_NO_DBLESCAN] = "doublescan mode not supported",
> + ? ? ? ? ? ? ? [MODE_NO_VSCAN] = "multiscan mode not supported",
> + ? ? ? ? ? ? ? [MODE_MEM] = "insufficient video memory",
> + ? ? ? ? ? ? ? [MODE_VIRTUAL_X] = "mode width too large for specified
> virtual size",
> + ? ? ? ? ? ? ? [MODE_VIRTUAL_Y] = "mode height too large for specified
> virtual size",
> + ? ? ? ? ? ? ? [MODE_MEM_VIRT] = "insufficient video memory given virtual
> size",
> + ? ? ? ? ? ? ? [MODE_NOCLOCK] = "no fixed clock available",
> + ? ? ? ? ? ? ? [MODE_CLOCK_HIGH] = "clock required is too high",
> + ? ? ? ? ? ? ? [MODE_CLOCK_LOW] = "clock required is too low",
> + ? ? ? ? ? ? ? [MODE_CLOCK_RANGE] = "clock/mode isn't in a ClockRange",
> + ? ? ? ? ? ? ? [MODE_BAD_HVALUE] = "horizontal timing was out of range",
> + ? ? ? ? ? ? ? [MODE_BAD_VVALUE] = "vertical timing was out of range",
> + ? ? ? ? ? ? ? [MODE_BAD_VSCAN] = "VScan value out of range",
> + ? ? ? ? ? ? ? [MODE_HSYNC_NARROW] = "horizontal sync too narrow",
> + ? ? ? ? ? ? ? [MODE_HSYNC_WIDE] = "horizontal sync too wide",
> + ? ? ? ? ? ? ? [MODE_HBLANK_NARROW] = "horizontal blanking too narrow",
> + ? ? ? ? ? ? ? [MODE_HBLANK_WIDE] = "horizontal blanking too wide",
> + ? ? ? ? ? ? ? [MODE_VSYNC_NARROW] = "vertical sync too narrow",
> + ? ? ? ? ? ? ? [MODE_VSYNC_WIDE] = "vertical sync too wide",
> + ? ? ? ? ? ? ? [MODE_VBLANK_NARROW] = "vertical blanking too narrow",
> + ? ? ? ? ? ? ? [MODE_VBLANK_WIDE] = "vertical blanking too wide",
> + ? ? ? ? ? ? ? [MODE_PANEL] = "exceeds panel dimensions",
> + ? ? ? ? ? ? ? [MODE_INTERLACE_WIDTH] = "width too large for interlaced
> mode",
> + ? ? ? ? ? ? ? [MODE_ONE_WIDTH] = "only one width is supported",
> + ? ? ? ? ? ? ? [MODE_ONE_HEIGHT] = "only one height is supported",
> + ? ? ? ? ? ? ? [MODE_ONE_SIZE] = "only one resolution is supported",
> + ? ? ? ? ? ? ? [MODE_NO_REDUCED] = "monitor doesn't accept reduced blanking",
> + ? ? ? };
> +
> + ? ? ? if ((unsigned)status > ARRAY_SIZE(strings))
> -> >=
> + ? ? ? ? ? ? ? return "unknown";
> +
> + ? ? ? return strings[status];
> +}
> +
> ?/**
> ?* drm_mode_prune_invalid - remove invalid modes from mode list
> ?* @dev: DRM device
> @@ -876,8 +922,10 @@ void drm_mode_prune_invalid(struct drm_device *dev,
> ? ? ? ? ? ? ? ? ? ? ? ?list_del(>head);
> ? ? ? ? ? ? ? ? ? ? ? ?if (verbose) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?drm_mode_debug_printmodeline(mode);
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DRM_DEBUG_KMS("Not using %s mode %d\n",
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? mode->name, mode->status);
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DRM_DEBUG_KMS("Not using %s mode: %s [%d]\n",
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? mode->name,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> mode_status_to_string(mode->status),
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? mode->status);
> ? ? ? ? ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ? ? ? ? ?drm_mode_destroy(dev, mode);
> ? ? ? ? ? ? ? ?}
> --
Re: [PATCH] drm: Pretty print out the reason for rejecting the mode
2011/4/5 Chris Wilson ch...@chris-wilson.co.uk:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/drm_modes.c | 52 +-
1 files changed, 50 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 25bf873..b3e07ac 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -853,6 +853,52 @@ void drm_mode_validate_clocks(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_mode_validate_clocks);
+static const char *mode_status_to_string(enum drm_mode_status status)
+{
+ const char *strings[] = {
+ static?
+ [MODE_OK] = OK,
+ [MODE_HSYNC] = hsync out of range,
+ [MODE_VSYNC] = vsync out of range,
+ [MODE_H_ILLEGAL] = illegal horizontal timings,
+ [MODE_V_ILLEGAL] = illegal vertical timings,
+ [MODE_BAD_WIDTH] = requires an unsupported linepitch,
+ [MODE_NOMODE] = no mode with a maching name,
s/maching/matching/
+ [MODE_NO_INTERLACE] = interlaced mode not supported,
+ [MODE_NO_DBLESCAN] = doublescan mode not supported,
+ [MODE_NO_VSCAN] = multiscan mode not supported,
+ [MODE_MEM] = insufficient video memory,
+ [MODE_VIRTUAL_X] = mode width too large for specified
virtual size,
+ [MODE_VIRTUAL_Y] = mode height too large for specified
virtual size,
+ [MODE_MEM_VIRT] = insufficient video memory given virtual
size,
+ [MODE_NOCLOCK] = no fixed clock available,
+ [MODE_CLOCK_HIGH] = clock required is too high,
+ [MODE_CLOCK_LOW] = clock required is too low,
+ [MODE_CLOCK_RANGE] = clock/mode isn't in a ClockRange,
+ [MODE_BAD_HVALUE] = horizontal timing was out of range,
+ [MODE_BAD_VVALUE] = vertical timing was out of range,
+ [MODE_BAD_VSCAN] = VScan value out of range,
+ [MODE_HSYNC_NARROW] = horizontal sync too narrow,
+ [MODE_HSYNC_WIDE] = horizontal sync too wide,
+ [MODE_HBLANK_NARROW] = horizontal blanking too narrow,
+ [MODE_HBLANK_WIDE] = horizontal blanking too wide,
+ [MODE_VSYNC_NARROW] = vertical sync too narrow,
+ [MODE_VSYNC_WIDE] = vertical sync too wide,
+ [MODE_VBLANK_NARROW] = vertical blanking too narrow,
+ [MODE_VBLANK_WIDE] = vertical blanking too wide,
+ [MODE_PANEL] = exceeds panel dimensions,
+ [MODE_INTERLACE_WIDTH] = width too large for interlaced
mode,
+ [MODE_ONE_WIDTH] = only one width is supported,
+ [MODE_ONE_HEIGHT] = only one height is supported,
+ [MODE_ONE_SIZE] = only one resolution is supported,
+ [MODE_NO_REDUCED] = monitor doesn't accept reduced blanking,
+ };
+
+ if ((unsigned)status ARRAY_SIZE(strings))
- =
+ return unknown;
+
+ return strings[status];
+}
+
/**
* drm_mode_prune_invalid - remove invalid modes from mode list
* @dev: DRM device
@@ -876,8 +922,10 @@ void drm_mode_prune_invalid(struct drm_device *dev,
list_del(mode-head);
if (verbose) {
drm_mode_debug_printmodeline(mode);
- DRM_DEBUG_KMS(Not using %s mode %d\n,
- mode-name, mode-status);
+ DRM_DEBUG_KMS(Not using %s mode: %s [%d]\n,
+ mode-name,
+
mode_status_to_string(mode-status),
+ mode-status);
}
drm_mode_destroy(dev, mode);
}
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
