dri-devel April 2013

dri-devel@lists.freedesktop.org

142 participants
765 discussions

[PATCH] drm/gma500: fix backlight hotkeys behaviour on cedarview netbooks
by Anisse Astier 02 May '13

02 May '13

Backlight hotkeys weren't working before on certain cedartrail laptops. The source of this problem is that the hotkeys' ASLE opregion interrupts were simply ignored. Driver seemed to expect the interrupt to be associated with a pipe, but it wasn't. Accepting the ASLE interrupt without an associated pipe event flag fixes the issue, the backlight code is called when needed, making the brightness keys work properly. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=833597 Reference: http://lists.freedesktop.org/archives/dri-devel/2012-July/025279.html Cc: stable(a)kernel.org Signed-off-by: Anisse Astier <anisse(a)astier.eu> --- drivers/gpu/drm/gma500/psb_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/psb_irq.c b/drivers/gpu/drm/gma500/psb_irq.c index 8652cdf..029eccf 100644 --- a/drivers/gpu/drm/gma500/psb_irq.c +++ b/drivers/gpu/drm/gma500/psb_irq.c @@ -211,7 +211,7 @@ irqreturn_t psb_irq_handler(DRM_IRQ_ARGS) vdc_stat = PSB_RVDC32(PSB_INT_IDENTITY_R); - if (vdc_stat & _PSB_PIPE_EVENT_FLAG) + if (vdc_stat & (_PSB_PIPE_EVENT_FLAG|_PSB_IRQ_ASLE)) dsp_int = 1; /* FIXME: Handle Medfield -- 1.8.1.4

2 4

radeon pm bug?
by Sylvain BERTRAND 01 May '13

01 May '13

Hi, In radeon_atombios.c file, radeon_atombios_parse_power_table_6 function, the power state is selected using the state array index: power_state = (union pplib_power_state *)&state_array->states[i]; The state array has variable sized states which size should be computed as said in the atombios.h file, definition of ATOM_PPLIB_STATE_V2 struct. Bug? regards, -- Sylvain

2 1

[Bug 38856] New: [i915g] SIGSEGV src/gallium/drivers/i915/i915_state.c:511
by bugzilla-daemon＠freedesktop.org 01 May '13

01 May '13

https://bugs.freedesktop.org/show_bug.cgi?id=38856 Summary: [i915g] SIGSEGV src/gallium/drivers/i915/i915_state.c:511 Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: vlee(a)vmware.com mesa: f8fcaf0215f0434baf13bb5c45545c58f97846b6 (master) chipset: 945GM (Intel GMA 950) system architecture: i686 xserver-xorg-video-intel: 2:2.14.0-4ubuntu7.1 libdrm-intel1: 2.4.23-1ubuntu6 kernel version: 2.6.38-8-generic Linux distribution: Ubuntu 11.04 i386 Run piglit fbo-copyteximage test. $ ./bin/fbo-copyteximage -auto Probe at (73,73) Expected: 1.000000 0.000000 0.000000 Observed: 0.000000 0.000000 1.000000 Probe at (200,73) Expected: 0.000000 1.000000 0.000000 Observed: 1.000000 0.000000 0.000000 Probe at (73,200) Expected: 0.000000 0.000000 1.000000 Observed: 1.000000 1.000000 1.000000 Segmentation fault (core dumped) Core was generated by `./bin/fbo-copyteximage -auto'. Program terminated with signal 11, Segmentation fault. #0 __libc_free (mem=0x3f800000) at malloc.c:3709 3709 malloc.c: No such file or directory. in malloc.c (gdb) bt #0 __libc_free (mem=0x3f800000) at malloc.c:3709 #1 0x01134a96 in i915_delete_fs_state (pipe=0x94343f8, shader=0x94f66d8) at src/gallium/drivers/i915/i915_state.c:511 #2 0x0115b2d9 in aaline_delete_fs_state (pipe=0x94343f8, fs=0x94f5398) at src/gallium/auxiliary/draw/draw_pipe_aaline.c:880 #3 0x01188635 in util_blitter_destroy (blitter=0x94bd360) at src/gallium/auxiliary/util/u_blitter.c:251 #4 0x011310df in i915_destroy (pipe=0x94343f8) at src/gallium/drivers/i915/i915_context.c:105 #5 0x0196f29f in st_destroy_context (st=0x9500598) at src/mesa/state_tracker/st_context.c:261 #6 0x018a7ce1 in st_context_destroy (stctxi=0x9500598) at src/mesa/state_tracker/st_manager.c:651 #7 0x018a34fc in dri_destroy_context (cPriv=0x942df90) at src/gallium/state_trackers/dri/drm/dri_context.c:135 #8 0x0120ea80 in driDestroyContext (pcp=0x942df90) at src/mesa/drivers/dri/common/dri_util.c:588 #9 0x002d45a0 in dri2_destroy_context (context=0x942ed50) at dri2_glx.c:129 #10 0x002aecf0 in glx_display_free (priv=0x942cad0) at glxext.c:220 #11 0x002aed7c in __glXCloseDisplay (dpy=0x9422028, codes=0x942cd5c) at glxext.c:265 #12 0x00583ccb in XCloseDisplay () from /usr/lib/i386-linux-gnu/libX11.so.6 #13 0x003a3693 in fgDeinitialize () at freeglut_init.c:488 #14 0x003a6997 in glutMainLoop () at freeglut_main.c:1533 #15 0x0806b2df in main (argc=1, argv=0xbf9cd2b4) at piglit/tests/util/piglit-framework.c:116 (gdb) frame 1 #1 0x01134a96 in i915_delete_fs_state (pipe=0x94343f8, shader=0x94f66d8) at src/gallium/drivers/i915/i915_state.c:511 511 FREE(ifs->program); (gdb) print ifs->program $1 = (uint *) 0x3f800000 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 4

Re: abuse of dumb ioctls in exynos
by Dave Airlie 30 Apr '13

30 Apr '13

> The reason we (currently) use the dumb buffer interface is because it > does pretty much exactly what we need it to, as we only want linear > RGB buffers: Except in the cases where it doesn't do what you want, and possibly in the future where it does less of what you want. You've started on a slippery slope, and I'm stopping you before you make things worse. You are going to have to get SoC kernel drivers to add an ioctl that you can use, if you insist on trying to mangle all the different code paths into a single userspace driver, then you are going to take a lot of pain. Its the old helper library vs midlayer, you are inventing a DDX midlayer when you should be inventing a DDX helper library. > On Mali & probably other tiled-based GPUs, the back buffer only gets > written once per frame, when the GPU writes its on-die tile buffer to > system memory. As such, we don't need the complicated memory layouts > immediate mode renders do to improve cache efficiency, etc. On one 3D core, the problem is the driver seems to be wanted to be used across at least omap and exynos, and I assume others will happen as time progresses. > What's more, the 2D hardware typically found on SoCs we're targeting > isn't advanced enough to implement all of the EXA operations and > frequently falls back to software rendering, which only works with > linear RGB buffers. Don't worry about implementing all of EXA, you really probably only want fill/copy for what you are doing. > we must therefore allocate from a contiguous ION heap. By allocating > via the DUMB interface and specifying a scanout hint, we can leave > that decision to the DRM driver and keep userspace entirely generic. > The other reason to go with DUMB rather than ION was because ION > wasn't upstream. Just ask the drm driver directly, no dumb ioctl, no ion. Not sure what the problem is. > Would you mind elaborating a little on this? I assume you're not talking > about libkms? What operations would be performed by this driver which > would need to be abstracted in userspace which aren't already nicely > abstracted by KMS? Once we have a new library of some description, I > assume you're suggesting we modify armsoc to use it? That seems a good > idea as it also means we can use that to implement the HWComposer HAL > on Android and thus use the same driver code can be used with minimal > changes on X11, Android, Wayland, Mir and whatever other new window > system comes along. That's really the point I'm trying to get to. No not libkms, nothing like it. More as Rob said the drmmode code is probably the truly common code, and just write a DDX per SoC. Really anything else you do is going to lull people into a false sense of how much work there is. Distros want to ship a distro that can support all ARM boards at once, they don't want have 15 armsoc builds with different configure flags. Stop and think about how Linux distro downstream might use this. Dave.

2 3

[PATCH] [RFC] mutex: w/w mutex slowpath debugging
by Daniel Vetter 30 Apr '13

30 Apr '13

Injects EDEADLK conditions at pseudo-random interval, with exponential backoff up to UINT_MAX (to ensure that every lock operation still completes in a reasonable time). This way we can test the wound slowpath even for ww mutex users where contention is never expected, and the ww deadlock avoidance algorithm is only needed for correctness against malicious userspace. An example would be protecting kernel modesetting properties, which thanks to single-threaded X isn't really expected to contend, ever. I've looked into using the CONFIG_FAULT_INJECTION infrastructure, but decided against it for two reasons: - EDEADLK handling is mandatory for ww mutex users and should never affect the outcome of a syscall. This is in contrast to -ENOMEM injection. So fine configurability isn't required. - The fault injection framework only allows to set a simple probability for failure. Now the probability that a ww mutex acquire stage with N locks will never complete (due to too many injected EDEADLK backoffs) is zero. But the expected number of ww_mutex_lock operations for the completely uncontended case would be O(exp(N)). The per-acuiqire ctx exponential backoff solution choosen here only results in O(log N) overhead due to injection and so O(log N * N) lock operations. This way we can fail with high probability (and so have good test coverage even for fancy backoff and lock acquisition paths) without running into patalogical cases. Note that EDEADLK will only ever be injected when we managed to acquire the lock. This prevents any behaviour changes for users which rely on the EALREADY semantics. v2: Drop the cargo-culted __sched (I should read docs next time around) and annotate the non-debug case with inline to prevent gcc from doing something horrible. Cc: Steven Rostedt <rostedt(a)goodmis.org> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- include/linux/mutex.h | 8 ++++++++ kernel/mutex.c | 32 ++++++++++++++++++++++++++++++++ lib/Kconfig.debug | 10 ++++++++++ 3 files changed, 50 insertions(+) diff --git a/include/linux/mutex.h b/include/linux/mutex.h index 004f863..82d56ec 100644 --- a/include/linux/mutex.h +++ b/include/linux/mutex.h @@ -93,6 +93,10 @@ struct ww_acquire_ctx { #ifdef CONFIG_DEBUG_LOCK_ALLOC struct lockdep_map dep_map; #endif +#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH + unsigned deadlock_inject_interval; + unsigned deadlock_inject_countdown; +#endif }; struct ww_mutex { @@ -278,6 +282,10 @@ static inline void ww_acquire_init(struct ww_acquire_ctx *ctx, &ww_class->acquire_key, 0); mutex_acquire(&ctx->dep_map, 0, 0, _RET_IP_); #endif +#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH + ctx->deadlock_inject_interval = ctx->stamp & 0xf; + ctx->deadlock_inject_countdown = ctx->deadlock_inject_interval; +#endif } /** diff --git a/kernel/mutex.c b/kernel/mutex.c index 66807c7..816fdfc 100644 --- a/kernel/mutex.c +++ b/kernel/mutex.c @@ -827,6 +827,36 @@ int __sched mutex_trylock(struct mutex *lock) EXPORT_SYMBOL(mutex_trylock); #ifndef CONFIG_DEBUG_LOCK_ALLOC + +#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH +static int +ww_mutex_deadlock_injection(struct ww_mutex *lock, struct ww_acquire_ctx *ctx) +{ + if (ctx->deadlock_inject_countdown-- == 0) { + tmp = ctx->deadlock_inject_interval; + if (tmp > UINT_MAX/4) + tmp = UINT_MAX; + else + tmp = tmp*2 + tmp + tmp/2; + + ctx->deadlock_inject_interval = tmp; + ctx->deadlock_inject_countdown = tmp; + + ww_mutex_unlock(lock); + + return -EDEADLK; + } + + return 0; +} +#else +static inline int +ww_mutex_deadlock_injection(struct ww_mutex *lock, struct ww_acquire_ctx *ctx) +{ + return 0; +} +#endif + int __sched ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ctx) { @@ -839,6 +869,7 @@ ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ctx) if (likely(!ret)) { ww_mutex_set_context_fastpath(lock, ctx); mutex_set_owner(&lock->base); + return ww_mutex_deadlock_injection(lock, ctx); } else ret = __ww_mutex_lock_slowpath(lock, ctx); return ret; @@ -857,6 +888,7 @@ ww_mutex_lock_interruptible(struct ww_mutex *lock, struct ww_acquire_ctx *ctx) if (likely(!ret)) { ww_mutex_set_context_fastpath(lock, ctx); mutex_set_owner(&lock->base); + return ww_mutex_deadlock_injection(lock, ctx); } else ret = __ww_mutex_lock_interruptible_slowpath(lock, ctx); return ret; diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 28be08c..8c41f73 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -547,6 +547,16 @@ config DEBUG_MUTEXES This feature allows mutex semantics violations to be detected and reported. +config DEBUG_WW_MUTEX_SLOWPATH + bool "Wait/wound mutex debugging: Slowpath testing" + depends on DEBUG_KERNEL + help + This feature enables slowpath testing for w/w mutex users by + injecting additional -EDEADLK wound/backoff cases. Together with + the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this + will test all possible w/w mutex interface abuse with the + exception of simply not acquiring all the required locks. + config DEBUG_LOCK_ALLOC bool "Lock debugging: detect incorrect freeing of live locks" depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT -- 1.7.10.4

1 0

[PATCH 0/6] drm: drm_rect and clipping for intel sprite planes v2
by ville.syrjala＠linux.intel.com 30 Apr '13

30 Apr '13

Here's the latest version of my plane clipping stuff. I think it should be ready for merging. Laurent reviewed the first patch, and Chris reviewed the whole set. I didn't hear any bikeshedding about the location of the drm_rect stuff from anyone, so I'm assuming it's all good. Ville Syrjälä (6): drm: Add struct drm_rect and assorted utility functions drm: Add drm_rect_calc_{hscale, vscale}() utility functions drm: Add drm_rect_debug_print() drm: Add drm_rect_equals() drm/i915: Implement proper clipping for video sprites drm/i915: Relax the sprite scaling limits checks Documentation/DocBook/drm.tmpl | 2 + drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/drm_rect.c | 295 ++++++++++++++++++++++++++++++++++++ drivers/gpu/drm/i915/intel_sprite.c | 202 ++++++++++++++++++------ include/drm/drm_rect.h | 160 +++++++++++++++++++ 5 files changed, 615 insertions(+), 47 deletions(-) create mode 100644 drivers/gpu/drm/drm_rect.c create mode 100644 include/drm/drm_rect.h

2 7

[Bug 26345] [845G] CPU/GPU incoherency
by bugzilla-daemon＠freedesktop.org 30 Apr '13

30 Apr '13

https://bugs.freedesktop.org/show_bug.cgi?id=26345 --- Comment #160 from Jani Nikula <jani.nikula(a)intel.com> --- (In reply to comment #159) > Something is broken in the 3.8 kernel. When I'm using it, the colour depth > is low, and my system freezes when I try to suspend the computer. I don't > know if it caused by the applied workaround or not, but the problem gone if > I downgrade to kernel version 3.7. Please file a new bug with a detailed description of your symptoms instead of cluttering this one. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 26345] [845G] CPU/GPU incoherency
by bugzilla-daemon＠freedesktop.org 30 Apr '13

30 Apr '13

https://bugs.freedesktop.org/show_bug.cgi?id=26345 --- Comment #159 from György Balló <ballogy(a)freestart.hu> --- Something is broken in the 3.8 kernel. When I'm using it, the colour depth is low, and my system freezes when I try to suspend the computer. I don't know if it caused by the applied workaround or not, but the problem gone if I downgrade to kernel version 3.7. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] mgag200 code cleanup patches
by Christopher Harvey 29 Apr '13

29 Apr '13

I submitted these a while ago, but I think they got lost in the mailing list. Just wanted to make sure they get a shot at the merge window. thanks, Christopher Harvey (3): drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth drm/mgag200: Pass driver specific mga_device in driver functions drm/mgag200: Remove extra variable assigns drivers/gpu/drm/mgag200/mgag200_fb.c | 3 --- drivers/gpu/drm/mgag200/mgag200_main.c | 2 -- drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++---- 3 files changed, 3 insertions(+), 9 deletions(-) -- 1.8.1.5

3 6

[PATCH] drm/radeon: fix UPLL_REF_DIV_MASK definition
by Christian König 29 Apr '13

29 Apr '13

From: Christian König <christian.koenig(a)amd.com> Stupid copy & paste error over all generations. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/radeon/evergreend.h | 2 +- drivers/gpu/drm/radeon/rv770d.h | 2 +- drivers/gpu/drm/radeon/sid.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreend.h b/drivers/gpu/drm/radeon/evergreend.h index d9a0054..75c0563 100644 --- a/drivers/gpu/drm/radeon/evergreend.h +++ b/drivers/gpu/drm/radeon/evergreend.h @@ -59,7 +59,7 @@ # define UPLL_SLEEP_MASK 0x00000002 # define UPLL_BYPASS_EN_MASK 0x00000004 # define UPLL_CTLREQ_MASK 0x00000008 -# define UPLL_REF_DIV_MASK 0x001F0000 +# define UPLL_REF_DIV_MASK 0x003F0000 # define UPLL_VCO_MODE_MASK 0x00000200 # define UPLL_CTLACK_MASK 0x40000000 # define UPLL_CTLACK2_MASK 0x80000000 diff --git a/drivers/gpu/drm/radeon/rv770d.h b/drivers/gpu/drm/radeon/rv770d.h index 6a52b20..85b1626 100644 --- a/drivers/gpu/drm/radeon/rv770d.h +++ b/drivers/gpu/drm/radeon/rv770d.h @@ -45,7 +45,7 @@ # define UPLL_BYPASS_EN_MASK 0x00000004 # define UPLL_CTLREQ_MASK 0x00000008 # define UPLL_REF_DIV(x) ((x) << 16) -# define UPLL_REF_DIV_MASK 0x001F0000 +# define UPLL_REF_DIV_MASK 0x003F0000 # define UPLL_CTLACK_MASK 0x40000000 # define UPLL_CTLACK2_MASK 0x80000000 #define CG_UPLL_FUNC_CNTL_2 0x71c diff --git a/drivers/gpu/drm/radeon/sid.h b/drivers/gpu/drm/radeon/sid.h index 042b91d..222877b 100644 --- a/drivers/gpu/drm/radeon/sid.h +++ b/drivers/gpu/drm/radeon/sid.h @@ -36,7 +36,7 @@ # define UPLL_BYPASS_EN_MASK 0x00000004 # define UPLL_CTLREQ_MASK 0x00000008 # define UPLL_VCO_MODE_MASK 0x00000600 -# define UPLL_REF_DIV_MASK 0x001F0000 +# define UPLL_REF_DIV_MASK 0x003F0000 # define UPLL_CTLACK_MASK 0x40000000 # define UPLL_CTLACK2_MASK 0x80000000 #define CG_UPLL_FUNC_CNTL_2 0x638 -- 1.7.10.4

3 2

← Newer
1
...
45
46
47
48
49
50
51
...
77
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2013