dri-devel February 2013

dri-devel@lists.freedesktop.org

130 participants
696 discussions

[PATCH 00/16] [RFC] drm fb helper cleanups
by Daniel Vetter 13 Feb '13

13 Feb '13

Hi all, This series is mostly just a bit of fallout from my modeset locking rework which just landed, and some other things I've noticed while rearchitecting the modeset infrastructure for i915.k in 3.7. First two patches are for omapdrm, but included here since they depend upon the locking rework in drm-next. Dunno what to do with these patches, so I'll just drop them here. Rob, you really need to put the finishing touches on omapdrm and move it out of staging! The remainder just mostly cleans up the fb helper interfaces and how the helper code calls down into drivers. Icing on the cake is a good doc update. I'm rather happy with what the fbdev helper code now looks like after this. A few areas with potential for improvement remain though: - Locking around setup/teardown smells a bit fishy, but that ties in with the fbdev setup locking (which is insane) and the drm core setup locking (which is riddled with legacy stuff and also ripe for some overhaul). I think most of pertaining the fbdev emulation is safe though. - Much worse is the situation around the panic, sysrq and kdbg handlers - those simply grab no locks at all. Safe for the ->blank callback, which may not sleep since it can be called while the kernel panics in interrupt context. Bug spotted by Konstantin Khlebnikov, I've only simplified his originally proposed patch a bit. - The fb helpers have their own special interface for handling gamma/luts. I've looked a bit at the code, and I'm pretty sure this can be reworked to only use the real kms interfaces for updating the gamma table. That would leave the fb helpers with ->best_encoder and ->fb_probe as the two only special interfaces. But reworking the gamma code is a bit of work, so I've postponed it for now. Comments, flames, reviews and testing highly welcome. Cheers, Daniel Daniel Vetter (16): omapdrm: only take crtc->mutex in crtc callbacks omapdrm: simply locking in the fb debugfs file drm: review locking for drm_fb_helper_restore_fbdev_mode drm/fb-helper: kill drm_fb_helper_restore drm/fb-helper: unexport drm_fb_helper_panic drm/fb-helper: inline drm_fb_helper_single_add_all_connectors drm/fb-helper: unexport drm_fb_helper_single_fb_probe drm/tegra: don't set up initial fbcon config twice drm/fb-helper: don't disable everything in initial_config drm/i915: rip out helper->disable noop functions drm/fb-helper: fixup up set_config semantics drm/fb-helper: directly call set_par from the hotplug handler drm/fb-helper: streamline drm_fb_helper_single_fb_probe drm/<drivers>: simplify ->fb_probe callback drm/fb-helper: improve kerneldoc drm/fb-helper: don't sleep for screen unblank when an oopps is in progress drivers/gpu/drm/ast/ast_fb.c | 26 +--- drivers/gpu/drm/cirrus/cirrus_fbdev.c | 26 +--- drivers/gpu/drm/drm_fb_cma_helper.c | 27 +--- drivers/gpu/drm/drm_fb_helper.c | 216 +++++++++++++++++++++-------- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 40 +----- drivers/gpu/drm/gma500/framebuffer.c | 14 +- drivers/gpu/drm/i915/intel_crt.c | 1 - drivers/gpu/drm/i915/intel_ddi.c | 1 - drivers/gpu/drm/i915/intel_display.c | 20 +-- drivers/gpu/drm/i915/intel_dp.c | 1 - drivers/gpu/drm/i915/intel_drv.h | 1 - drivers/gpu/drm/i915/intel_dvo.c | 1 - drivers/gpu/drm/i915/intel_fb.c | 23 +-- drivers/gpu/drm/i915/intel_hdmi.c | 1 - drivers/gpu/drm/i915/intel_lvds.c | 1 - drivers/gpu/drm/i915/intel_sdvo.c | 1 - drivers/gpu/drm/i915/intel_tv.c | 1 - drivers/gpu/drm/mgag200/mgag200_fb.c | 26 +--- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 27 +--- drivers/gpu/drm/radeon/radeon_fb.c | 25 +--- drivers/gpu/drm/tegra/fb.c | 4 - drivers/gpu/drm/udl/udl_fb.c | 26 +--- drivers/staging/omapdrm/omap_crtc.c | 12 +- drivers/staging/omapdrm/omap_debugfs.c | 14 -- drivers/staging/omapdrm/omap_fbdev.c | 21 +-- include/drm/drm_fb_helper.h | 5 - 26 files changed, 227 insertions(+), 334 deletions(-) -- 1.7.10.4

6 43

[PATCH] drm/radeon: Catch reservation deadlock on same buffer with different handle v2
by j.glisse＠gmail.com 13 Feb '13

13 Feb '13

From: Jerome Glisse <jglisse(a)redhat.com> This patch print a warning message when trying to reserve same buffer twice in same cs ioctl (because the buffer is known by userspace under 2 different handle). It does not try to fix the issue like : https://patchwork.kernel.org/patch/1812991/ Just to make this case easier to debug. v2: Make message a debug one not an error Cc: stable(a)vger.kernel.org Signed-off-by: Jerome Glisse <jglisse(a)redhat.com> --- drivers/gpu/drm/radeon/radeon_object.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index d3aface..624ea8c 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -355,6 +355,18 @@ int radeon_bo_list_validate(struct list_head *head) r = ttm_eu_reserve_buffers(head); if (unlikely(r != 0)) { + if (r == -EDEADLK) { + /* this is not a GPU lockup, ttm_eu_reserve_buffers + * can not trigger detection of GPU lockup. This is + * a dead lock trying to reserve the same buffer again + * probably because the buffer is know as 2 different + * handle by userspace. Print a warning message so + * that we know what's going on. + */ + DRM_DEBUG("Dead lock reserving buffer (one buffer is know by userspace under 2 different handle)\n"); + /* Do not return -EDEADLK to avoid useless GPU reset */ + return -EINVAL; + } return r; } list_for_each_entry(lobj, head, tv.head) { -- 1.7.11.7

1 0

[PATCH] drm/radeon: Catch reservation deadlock on same buffer with different handle
by j.glisse＠gmail.com 13 Feb '13

13 Feb '13

From: Jerome Glisse <jglisse(a)redhat.com> This patch print a warning message when trying to reserve same buffer twice in same cs ioctl (because the buffer is known by userspace under 2 different handle). It does not try to fix the issue like : https://patchwork.kernel.org/patch/1812991/ Just to make this case easier to debug. Cc: stable(a)vger.kernel.org Signed-off-by: Jerome Glisse <jglisse(a)redhat.com> --- drivers/gpu/drm/radeon/radeon_object.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index d3aface..e40743d 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -355,6 +355,18 @@ int radeon_bo_list_validate(struct list_head *head) r = ttm_eu_reserve_buffers(head); if (unlikely(r != 0)) { + if (r == -EDEADLK) { + /* this is not a GPU lockup, ttm_eu_reserve_buffers + * can not trigger detection of GPU lockup. This is + * a dead lock trying to reserve the same buffer again + * probably because the buffer is know as 2 different + * handle by userspace. Print a warning message so + * that we know what's going on. + */ + DRM_ERROR("Dead lock reserving buffer (one buffer is know by userspace under 2 different handle)\n"); + /* Do not return -EDEADLK to avoid useless GPU reset */ + return -EINVAL; + } return r; } list_for_each_entry(lobj, head, tv.head) { -- 1.7.11.7

1 0

[Bug 60224] New: Radeon hd6770 graphics artifacts in team fortress 2 with 3.8 kernel
by bugzilla-daemon＠freedesktop.org 13 Feb '13

13 Feb '13

https://bugs.freedesktop.org/show_bug.cgi?id=60224 Priority: medium Bug ID: 60224 Assignee: dri-devel(a)lists.freedesktop.org Summary: Radeon hd6770 graphics artifacts in team fortress 2 with 3.8 kernel Severity: normal Classification: Unclassified OS: All Reporter: pontostroy(a)gmail.com Hardware: Other Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 74130 --> https://bugs.freedesktop.org/attachment.cgi?id=74130&action=edit tf2 mesa, libdrm, ddx from git 1:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Juniper XT [AMD Radeon HD 6000 Series] With kernel <3.8 all looks fine. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[PATCH] drm: Fix a typo in the struct drm_plane_funcs documentation
by Damien Lespiau 13 Feb '13

13 Feb '13

Signed-off-by: Damien Lespiau <damien.lespiau(a)intel.com> --- include/drm/drm_crtc.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index e90c8dc..b248382 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -659,7 +659,7 @@ struct drm_plane_funcs { * @gamma_store: gamma correction table * @enabled: enabled flag * @funcs: helper functions - * @helper_private: storage for drver layer + * @helper_private: storage for driver layer * @properties: property tracking for this plane */ struct drm_plane { -- 1.7.7.5

1 0

[PATCH] Revert "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S"
by Daniel Vetter 13 Feb '13

13 Feb '13

This reverts commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b. The quirk cause a regression, and it looks like the original bug was simply a lack of FIFO bandwidth on the i915G of the reporter. Which should eventually be fixed as soon as we get around to implemented DSPARB FIFO reassignment on gen 3. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52281 Cc: stable(a)vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- drivers/gpu/drm/drm_edid.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 5a3770f..39919f2 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -87,9 +87,6 @@ static struct edid_quirk { int product_id; u32 quirks; } edid_quirk_list[] = { - /* ASUS VW222S */ - { "ACI", 0x22a2, EDID_QUIRK_FORCE_REDUCED_BLANKING }, - /* Acer AL1706 */ { "ACR", 44358, EDID_QUIRK_PREFER_LARGE_60 }, /* Acer F51 */ -- 1.7.10.4

3 3

[next-20130204] nouveau: lockdep warning (not the same as the subdev lockdep warning)
by Peter Hurley 13 Feb '13

13 Feb '13

Got this lockdep warning straightaway during boot: [ 7.435890] ============================================= [ 7.435891] [ INFO: possible recursive locking detected ] [ 7.435893] 3.8.0-next-20130204+pcipatch-xeon+lockdep #20130204+pcipatch Not tainted [ 7.435893] --------------------------------------------- [ 7.435895] modprobe/255 is trying to acquire lock: [ 7.435942] (&dmac->lock){+.+...}, at: [<ffffffffa01767c3>] evo_wait+0x43/0xf0 [nouveau] [ 7.435942] [ 7.435942] but task is already holding lock: [ 7.435964] (&dmac->lock){+.+...}, at: [<ffffffffa01767c3>] evo_wait+0x43/0xf0 [nouveau] [ 7.435964] [ 7.435964] other info that might help us debug this: [ 7.435965] Possible unsafe locking scenario: [ 7.435965] [ 7.435966] CPU0 [ 7.435967] ---- [ 7.435968] lock(&dmac->lock); [ 7.435970] lock(&dmac->lock); [ 7.435970] [ 7.435970] *** DEADLOCK *** [ 7.435970] [ 7.435971] May be due to missing lock nesting notation [ 7.435971] [ 7.435973] 9 locks held by modprobe/255: [ 7.435979] #0: (&__lockdep_no_validate__){......}, at: [<ffffffff814ce26b>] __driver_attach+0x5b/0xb0 [ 7.435982] #1: (&__lockdep_no_validate__){......}, at: [<ffffffff814ce279>] __driver_attach+0x69/0xb0 [ 7.436001] #2: (drm_global_mutex){+.+.+.}, at: [<ffffffffa0065e6d>] drm_get_pci_dev+0xbd/0x2a0 [drm] [ 7.436012] #3: (registration_lock){+.+.+.}, at: [<ffffffff81402855>] register_framebuffer+0x25/0x2f0 [ 7.436016] #4: (&fb_info->lock){+.+.+.}, at: [<ffffffff81401736>] lock_fb_info+0x26/0x60 [ 7.436023] #5: ((fb_notifier_list).rwsem){.+.+.+}, at: [<ffffffff81096466>] __blocking_notifier_call_chain+0x56/0xc0 [ 7.436035] #6: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa0069d6a>] drm_modeset_lock_all+0x2a/0x70 [drm] [ 7.436046] #7: (&crtc->mutex){+.+.+.}, at: [<ffffffffa0069d94>] drm_modeset_lock_all+0x54/0x70 [drm] [ 7.436068] #8: (&dmac->lock){+.+...}, at: [<ffffffffa01767c3>] evo_wait+0x43/0xf0 [nouveau] [ 7.436068] [ 7.436068] stack backtrace: [ 7.436070] Pid: 255, comm: modprobe Not tainted 3.8.0-next-20130204+pcipatch-xeon+lockdep #20130204+pcipatch [ 7.436072] Call Trace: [ 7.436077] [<ffffffff810d0e87>] __lock_acquire+0x697/0x1a80 [ 7.436080] [<ffffffff810d28f1>] lock_acquire+0xa1/0x200 [ 7.436100] [<ffffffffa01767c3>] ? evo_wait+0x43/0xf0 [nouveau] [ 7.436121] [<ffffffffa01767c3>] ? evo_wait+0x43/0xf0 [nouveau] [ 7.436125] [<ffffffff817946d3>] mutex_lock_nested+0x63/0x3a0 [ 7.436145] [<ffffffffa01767c3>] ? evo_wait+0x43/0xf0 [nouveau] [ 7.436148] [<ffffffff8179490e>] ? mutex_lock_nested+0x29e/0x3a0 [ 7.436168] [<ffffffffa01767c3>] ? evo_wait+0x43/0xf0 [nouveau] [ 7.436170] [<ffffffff810d32ef>] ? mark_held_locks+0xaf/0x110 [ 7.436190] [<ffffffffa01767c3>] evo_wait+0x43/0xf0 [nouveau] [ 7.436212] [<ffffffffa0176d3c>] evo_sync+0x5c/0xf0 [nouveau] [ 7.436233] [<ffffffffa0178e7d>] nv50_display_flip_next+0x5ad/0x5c0 [nouveau] Regards, Peter Hurley

1 0

Multiple parents in device driver model and Common Display Framework (CDF)
by Marcus Lorentzon 13 Feb '13

13 Feb '13

Hi Greg, at FOSDEM we had a session on CDF (Common Display Framework). You can read more details about this in the posts from Laurent Pinchart on dridevel: http://lists.freedesktop.org/archives/dri-devel/2012-November/030888.html http://lists.freedesktop.org/archives/dri-devel/2013-February/034576.html Adding Arnd in CC since he has guided me in the device driver model before. One design issue came up and Rob/Daniel proposed asking you for guidance. Here is some background to the issue. In CDF we are trying to get some common code between all the embedded panels (and maybe also some eDP/DVI/HDMI encoders). Target user is KMS encoder/connector "drivers" in DRM on ARM, Intel, SuperH (or others). CDF consist of two major APIs (dev ops). One API for display controller to use for controlling the display and one API for display driver to use to access the data/video/control bus master/host. Much like any device hooked into some kernel framework. Here is a small overview of the parts and APIs. KMS API: display controller drv access ---> CDF API: Display/Encoder/Panel drv access ---> Data/Control bus API: bus drv (often the same drv as display controller - panel bus host) The issue is related to the latter bus API. The bus is a combination of I2C/SPI/DBI/DSI/DPI busses. I2C and SPI I guess you know. DBI and a command version of DSI are MIPI standard command mode interfaces (DBI - Display Bus Interface, DSI - Display Serial Interface), which means they are combined control and data busses (much like I2C). Then there is DPI (Display Parallel Interface) and DSI video mode version which are MIPI standard video mode data busses. They are used to send pixel data to the display. DPI is a pure one directional data bus, but DSI can be used to send commands as well so it can be used as a control interface, even during video data streaming (it is a packet protocol). Now we have some different types of panels which are attached on a combination of busses: a) control:DBI, data:DBI b) control:I2C/SPI, data:I2C/SPI c) control:static setup, data:DPI d) control:I2C/SPI, data:DPI e) control:DSI, data:DSI f) control:I2C, data:DSI g) control:DSI+I2C, data:DSI As you could guess, g) is our issue. We have a device family that has two control bus attachments and one data bus. The kernel device/driver model only supports a single parent device which is normally the bus device. We will write drivers for all device types a-g implementing the CDF API. Those with only I2C/SPI bus attachemnt will of course be I2C drivers registered to CDF, same probably goes for DBI and DSI panels if we create a new bus type for them (if not - platform devices). But the CDF drivers still need some way to access the bus/host operations. So we will have to create an API for the exposed operations possible for the MIPI type busses (DBI/DSI/DPI), some control and some data bus related. For this problem we have discussed a few solutions, which is where we need your guidance: 1) Due to the fact there is no support for multiple parents in the device driver model and the fact that there are no DSI/DBI busses in the kernel, Tomi has come up with a sort of logical parent device for displays (see video source section, top section is "CDF API"): http://gitorious.org/linux-omap-dss2/linux/blobs/work/dss-dev-model-cdf/inc… Pros: Simple, easy to implement, merging all bus types into one logical bus (simplicity) Cons: Diverging from device driver model, merging all bus types into one logical bus (scalability, maintainability), has to make a copy of many things already in device driver model (pm, enumeration, registration, relations, ...), solution only really needed for one special type (g) 2) Another solution discussed at FOSDEM is to make full use of the device driver model. This would include adding the MIPI DBI/DSI bus types to the kernel. Add a full featured DSI/DBI API for devices attached on those busses (functionally the same APIs as for video source, but split into the actual bus types). Have display controller/host implement DBI/DSI bus ops. And finally register display as DBI/DSI device on the respective bus. For displays of type g) this could mean having two devices, one I2C device and one DSI device (this is the major objection to using the device driver model). Pros: Device driver model is well understood which will make it easier to understand for new CDF developers. Only g) type of panels will diverge from driver model (multi parents) Cons: Two struct device for g) type displays (one per bus), slightly more code to create the busses than a simple video source 3) Daniel V hinted that multiple parents (or multiple busses) is something that has been discussed as a limitation of device driver model before. And that maybe now was the time to fix that or at least sort out how to handle it. Pros: If possible to solve, probably the way to go, since it will eliminate the need of 1) and 2) that where created to work around the driver model limitation with multi parent Cons: Out of scope for CDF project, needs device driver model resources to fix 4) A combination of 1) and 2). Use video source solution for type g) devices and device driver model for the rest. Pros: See above, each CDF driver can choose the model that fits that driver the best Cons: See above, similar displays might have CDF drivers that look very different, still forces hosts to implement video source API So, what option do you prefer if any? Any comment on 3) and what has been said so far on multiple bus HW designs? /BR /Marcus

5 7

compositing broken in -next (idr bug)
by Jiri Slaby 12 Feb '13

12 Feb '13

Hi, this commit in -next causes my KDE to get stuck while starting. I see only the splash screen. If I disable effects by alt-shift-f12, it continues. I bisected it to this commit: commit 430440fce7da4ad52c2af06a04a5132e5d19faaf Author: Tejun Heo <tj(a)kernel.org> Date: Thu Feb 7 12:31:37 2013 +1100 drm: convert to idr_alloc() More concretely to the change in drm_gem_flink_ioctl. If I revert solely that one, it works again. Maybe I'm blind, but I do not see why... Well I see a bug in there, but that is not the root cause -- there is a missing call to idr_preload_end. Of course, that one only leaves preemption disabled forever. What I tried with no effect is this: --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -453,7 +453,8 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data, spin_lock(&dev->object_name_lock); if (!obj->name) { ret = idr_alloc(&dev->object_name_idr, obj, 1, 0, GFP_NOWAIT); - obj->name = ret; + if (ret >= 0) + obj->name = ret; args->name = (uint64_t) obj->name; spin_unlock(&dev->object_name_lock); @@ -469,6 +470,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data, } err: + idr_preload_end(); drm_gem_object_unreference_unlocked(obj); return ret; } thanks, -- js suse labs

2 5

Re: linux-next: Tree for Feb 12 (drm_pci.c)
by Randy Dunlap 12 Feb '13

12 Feb '13

On 02/11/13 21:09, Stephen Rothwell wrote: > Hi all, > > Changes since 20130211: > when CONFIG_PCI is not enabled (on x86_64): CC [M] drivers/gpu/drm/drm_pci.o drivers/gpu/drm/drm_pci.c: In function 'drm_pcie_get_speed_cap_mask': drivers/gpu/drm/drm_pci.c:485:2: error: implicit declaration of function 'pcie_capability_read_dword' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[4]: *** [drivers/gpu/drm/drm_pci.o] Error 1 -- ~Randy

2 1

← Newer
1
...
56
57
58
59
60
61
62
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2013