dri-devel October 2011

dri-devel@lists.freedesktop.org

82 participants
530 discussions

[PATCH] drm: serialize access to debugs_nodes.list
by Marcin Slusarz 09 Nov '11

09 Nov '11

Nouveau, when configured with debugfs, creates debugfs files for every channel, so structure holding list of files needs to be protected from simultaneous changes by multiple threads. Without this patch it's possible to hit kernel oops in drm_debugfs_remove_files just by running a couple of xterms with looped glxinfo. Signed-off-by: Marcin Slusarz <marcin.slusarz(a)gmail.com> --- drivers/gpu/drm/drm_debugfs.c | 5 +++++ include/drm/drmP.h | 1 + 2 files changed, 6 … [View More]

2 5

Re:[mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.
by Chen Jie 08 Nov '11

08 Nov '11

Hi, Add more information. We got occasionally "GPU lockup" after resuming from suspend(on mipsel platform with a mips64 compatible CPU and rs780e, the kernel is 3.1.0-rc8 64bit). Related kernel message: /* return from STR */ [ 156.152343] radeon 0000:01:05.0: WB enabled [ 156.187500] [drm] ring test succeeded in 0 usecs [ 156.187500] [drm] ib test succeeded in 0 usecs [ 156.398437] ata2: SATA link down (SStatus 0 SControl 300) [ 156.398437] ata3: SATA link down (SStatus 0 SControl 300) [… [View More] 156.398437] ata4: SATA link down (SStatus 0 SControl 300) [ 156.578125] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 156.597656] ata1.00: configured for UDMA/133 [ 156.613281] usb 1-5: reset high speed USB device number 4 using ehci_hcd [ 157.027343] usb 3-2: reset low speed USB device number 2 using ohci_hcd [ 157.609375] usb 3-3: reset low speed USB device number 3 using ohci_hcd [ 157.683593] r8169 0000:02:00.0: eth0: link up [ 165.621093] PM: resume of devices complete after 9679.556 msecs [ 165.628906] Restarting tasks ... done. [ 177.085937] radeon 0000:01:05.0: GPU lockup CP stall for more than 10019msec [ 177.089843] ------------[ cut here ]------------ [ 177.097656] WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:267 radeon_fence_wait+0x25c/0x33c() [ 177.105468] GPU lockup (waiting for 0x000013C3 last fence id 0x000013AD) [ 177.113281] Modules linked in: psmouse serio_raw [ 177.117187] Call Trace: [ 177.121093] [<ffffffff806f3e7c>] dump_stack+0x8/0x34 [ 177.125000] [<ffffffff8022e4f4>] warn_slowpath_common+0x78/0xa0 [ 177.132812] [<ffffffff8022e5b8>] warn_slowpath_fmt+0x38/0x44 [ 177.136718] [<ffffffff80522ed8>] radeon_fence_wait+0x25c/0x33c [ 177.144531] [<ffffffff804e9e70>] ttm_bo_wait+0x108/0x220 [ 177.148437] [<ffffffff8053b478>] radeon_gem_wait_idle_ioctl+0x80/0x114 [ 177.156250] [<ffffffff804d2fe8>] drm_ioctl+0x2e4/0x3fc [ 177.160156] [<ffffffff805a1820>] radeon_kms_compat_ioctl+0x28/0x38 [ 177.167968] [<ffffffff80311a04>] compat_sys_ioctl+0x120/0x35c [ 177.171875] [<ffffffff80211d18>] handle_sys+0x118/0x138 [ 177.179687] ---[ end trace 92f63d998efe4c6d ]--- [ 177.187500] radeon 0000:01:05.0: GPU softreset [ 177.191406] radeon 0000:01:05.0: R_008010_GRBM_STATUS=0xF57C2030 [ 177.195312] radeon 0000:01:05.0: R_008014_GRBM_STATUS2=0x00111103 [ 177.203125] radeon 0000:01:05.0: R_000E50_SRBM_STATUS=0x20023040 [ 177.363281] radeon 0000:01:05.0: Wait for MC idle timedout ! [ 177.367187] radeon 0000:01:05.0: R_008020_GRBM_SOFT_RESET=0x00007FEE [ 177.390625] radeon 0000:01:05.0: R_008020_GRBM_SOFT_RESET=0x00000001 [ 177.414062] radeon 0000:01:05.0: R_008010_GRBM_STATUS=0xA0003030 [ 177.417968] radeon 0000:01:05.0: R_008014_GRBM_STATUS2=0x00000003 [ 177.425781] radeon 0000:01:05.0: R_000E50_SRBM_STATUS=0x2002B040 [ 177.433593] radeon 0000:01:05.0: GPU reset succeed [ 177.605468] radeon 0000:01:05.0: Wait for MC idle timedout ! [ 177.761718] radeon 0000:01:05.0: Wait for MC idle timedout ! [ 177.804687] radeon 0000:01:05.0: WB enabled [ 178.000000] [drm:r600_ring_test] *ERROR* radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD) [ 178.007812] [drm:r600_resume] *ERROR* r600 startup failed on resume [ 178.988281] [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(5). [ 178.996093] [drm:radeon_cs_ioctl] *ERROR* Failed to schedule IB ! [ 179.003906] [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(6). ... What may cause a "GPU lockup"? Why reset didn't work? Any idea? BTW, one question: I got 'RADEON_IS_PCI | RADEON_IS_IGP' in rdev->flags, which causes need_dma32 was set. Is it correct? (drivers/char/agp is not available on mips, could that be the reason?) [ 177.179687]在 2011年9月28日下午3:23， <chenhc(a)lemote.com>写道： > Hi Alex, > > When we do STR (S3) with a RS780E radeon card on MIPS platform. "GPU > reset" may happen after resume (the possibility is about 5%). After that, > X is unusuable. > > We know there is a "ring test" at system resume time and GPU reset time. > Whether GPU reset happens, the "ring test" at system resume time is always > successful. But the "ring test" at GPU reset time usually fails. > > We use the latest kernel (3.1.0-RC8 from git) and X.org is 7.6. > > Any ideas? > > Best regards, > Huacai Chen > > Regards, - Chen Jie [View Less]

5 6

DRM planes and new fb creation ioctl
by Jesse Barnes 03 Nov '11

03 Nov '11

I've given up waiting for someone to implement support for these ioctls on another platform before they're merged, but I have received a lot of feedback on the interfaces, and it sounds like they're ok. I've also fixed all the remaining issues I'm aware of on SNB platforms and things are working well, so I'm just going to push them out. (Note IVB support is still missing a few bits for scaling and such; I'll fix those up when I get back home and can test on IVB again.) One change you may … [View More]

6 33

[Bug 41592] New: [Radeon] The display often freezes with gnome-shell 3.2
by bugzilla-daemon＠freedesktop.org 02 Nov '11

02 Nov '11

https://bugs.freedesktop.org/show_bug.cgi?id=41592 Summary: [Radeon] The display often freezes with gnome-shell 3.2 Product: Mesa Version: 7.11 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: mirandir(a)orange.fr Since the Gnome 3.… [View More]

1 21

[PATCH] drm/radeon: set hpd polarity at init time so hotplug detect works
by j.glisse＠gmail.com 02 Nov '11

02 Nov '11

From: Jerome Glisse <jglisse(a)redhat.com> Polarity needs to be set accordingly to connector status (connected or disconnected). Set it up at module init so first hotplug works reliably no matter what is the initial set of connector. Signed-off-by: Jerome Glisse <jglisse(a)redhat.com> cc: stable(a)kernel.org --- drivers/gpu/drm/radeon/radeon_connectors.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/… [View More]

3 4

[PATCH] vmwgfx: Reinstate the update_layout ioctl
by Thomas Hellstrom 02 Nov '11

02 Nov '11

We need to redefine a connector as "connected" if it matches a window in the host preferred GUI layout. Otherwise "smart" window managers would turn on Xorg outputs that we don't want to be on. This reinstates the update_layout and adds the following information to the modesetting system. a) Connection status <-> Equivalent to real hardware connection status b) Preferred mode <-> Equivalent to real hardware reading EDID c) Host window position <-> Equivalent to a real … [View More]hardware scanout address dynamic register. It should be noted that there is no assumption here about what should be displayed and where. Only how to access the host windows. This also bumps minor to signal availability of the new IOCTL. Based on code originally written by Jakob Bornecrantz Signed-off-by: Thomas Hellstrom <thellstrom(a)vmware.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 6 +++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 6 ++- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 66 ++++++++++++++++++++++++++++++++++- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 9 ++++- include/drm/vmwgfx_drm.h | 51 +++++++++++++-------------- 5 files changed, 107 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index b8eb8cd..0bc20c1 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -103,6 +103,9 @@ #define DRM_IOCTL_VMW_PRESENT_READBACK \ DRM_IOW(DRM_COMMAND_BASE + DRM_VMW_PRESENT_READBACK, \ struct drm_vmw_present_readback_arg) +#define DRM_IOCTL_VMW_UPDATE_LAYOUT \ + DRM_IOW(DRM_COMMAND_BASE + DRM_VMW_UPDATE_LAYOUT, \ + struct drm_vmw_update_layout_arg) /** * The core DRM version of this macro doesn't account for @@ -165,6 +168,9 @@ static struct drm_ioctl_desc vmw_ioctls[] = { VMW_IOCTL_DEF(VMW_PRESENT_READBACK, vmw_present_readback_ioctl, DRM_MASTER | DRM_AUTH | DRM_UNLOCKED), + VMW_IOCTL_DEF(VMW_UPDATE_LAYOUT, + vmw_kms_update_layout_ioctl, + DRM_MASTER | DRM_UNLOCKED), }; static struct pci_device_id vmw_pci_id_list[] = { diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h index 30589d0..8cca91a 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h @@ -40,9 +40,9 @@ #include "ttm/ttm_module.h" #include "vmwgfx_fence.h" -#define VMWGFX_DRIVER_DATE "20111008" +#define VMWGFX_DRIVER_DATE "20111025" #define VMWGFX_DRIVER_MAJOR 2 -#define VMWGFX_DRIVER_MINOR 2 +#define VMWGFX_DRIVER_MINOR 3 #define VMWGFX_DRIVER_PATCHLEVEL 0 #define VMWGFX_FILE_PAGE_OFFSET 0x00100000 #define VMWGFX_FIFO_STATIC_SIZE (1024*1024) @@ -633,6 +633,8 @@ int vmw_kms_readback(struct vmw_private *dev_priv, struct drm_vmw_fence_rep __user *user_fence_rep, struct drm_vmw_rect *clips, uint32_t num_clips); +int vmw_kms_update_layout_ioctl(struct drm_device *dev, void *data, + struct drm_file *file_priv); /** * Overlay control - vmwgfx_overlay.c diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index 8b14dfd..f9a0f98 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -1517,6 +1517,8 @@ int vmw_du_update_layout(struct vmw_private *dev_priv, unsigned num, du->pref_width = rects[du->unit].w; du->pref_height = rects[du->unit].h; du->pref_active = true; + du->gui_x = rects[du->unit].x; + du->gui_y = rects[du->unit].y; } else { du->pref_width = 800; du->pref_height = 600; @@ -1572,12 +1574,14 @@ vmw_du_connector_detect(struct drm_connector *connector, bool force) uint32_t num_displays; struct drm_device *dev = connector->dev; struct vmw_private *dev_priv = vmw_priv(dev); + struct vmw_display_unit *du = vmw_connector_to_du(connector); mutex_lock(&dev_priv->hw_mutex); num_displays = vmw_read(dev_priv, SVGA_REG_NUM_DISPLAYS); mutex_unlock(&dev_priv->hw_mutex); - return ((vmw_connector_to_du(connector)->unit < num_displays) ? + return ((vmw_connector_to_du(connector)->unit < num_displays && + du->pref_active) ? connector_status_connected : connector_status_disconnected); } @@ -1723,3 +1727,63 @@ int vmw_du_connector_set_property(struct drm_connector *connector, { return 0; } + + +int vmw_kms_update_layout_ioctl(struct drm_device *dev, void *data, + struct drm_file *file_priv) +{ + struct vmw_private *dev_priv = vmw_priv(dev); + struct drm_vmw_update_layout_arg *arg = + (struct drm_vmw_update_layout_arg *)data; + struct vmw_master *vmaster = vmw_master(file_priv->master); + void __user *user_rects; + struct drm_vmw_rect *rects; + unsigned rects_size; + int ret; + int i; + struct drm_mode_config *mode_config = &dev->mode_config; + + ret = ttm_read_lock(&vmaster->lock, true); + if (unlikely(ret != 0)) + return ret; + + if (!arg->num_outputs) { + struct drm_vmw_rect def_rect = {0, 0, 800, 600}; + vmw_du_update_layout(dev_priv, 1, &def_rect); + goto out_unlock; + } + + rects_size = arg->num_outputs * sizeof(struct drm_vmw_rect); + rects = kzalloc(rects_size, GFP_KERNEL); + if (unlikely(!rects)) { + ret = -ENOMEM; + goto out_unlock; + } + + user_rects = (void __user *)(unsigned long)arg->rects; + ret = copy_from_user(rects, user_rects, rects_size); + if (unlikely(ret != 0)) { + DRM_ERROR("Failed to get rects.\n"); + ret = -EFAULT; + goto out_free; + } + + for (i = 0; i < arg->num_outputs; ++i) { + if (rects->x < 0 || + rects->y < 0 || + rects->x + rects->w > mode_config->max_width || + rects->y + rects->h > mode_config->max_height) { + DRM_ERROR("Invalid GUI layout.\n"); + ret = -EINVAL; + goto out_free; + } + } + + vmw_du_update_layout(dev_priv, arg->num_outputs, rects); + +out_free: + kfree(rects); +out_unlock: + ttm_read_unlock(&vmaster->lock); + return ret; +} diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h index db0b901..815cf99 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h @@ -96,6 +96,12 @@ struct vmw_display_unit { unsigned pref_height; bool pref_active; struct drm_display_mode *pref_mode; + + /* + * Gui positioning + */ + int gui_x; + int gui_y; }; #define vmw_crtc_to_du(x) \ @@ -126,8 +132,7 @@ int vmw_du_connector_fill_modes(struct drm_connector *connector, int vmw_du_connector_set_property(struct drm_connector *connector, struct drm_property *property, uint64_t val); -int vmw_du_update_layout(struct vmw_private *dev_priv, unsigned num, - struct drm_vmw_rect *rects); + /* * Legacy display unit functions - vmwgfx_ldu.c diff --git a/include/drm/vmwgfx_drm.h b/include/drm/vmwgfx_drm.h index cd7cd81..bcb0912 100644 --- a/include/drm/vmwgfx_drm.h +++ b/include/drm/vmwgfx_drm.h @@ -54,7 +54,7 @@ #define DRM_VMW_FENCE_EVENT 17 #define DRM_VMW_PRESENT 18 #define DRM_VMW_PRESENT_READBACK 19 - +#define DRM_VMW_UPDATE_LAYOUT 20 /*************************************************************************/ /** @@ -552,31 +552,6 @@ struct drm_vmw_get_3d_cap_arg { /*************************************************************************/ /** - * DRM_VMW_UPDATE_LAYOUT - Update layout - * - * Updates the preferred modes and connection status for connectors. The - * command conisits of one drm_vmw_update_layout_arg pointing out a array - * of num_outputs drm_vmw_rect's. - */ - -/** - * struct drm_vmw_update_layout_arg - * - * @num_outputs: number of active - * @rects: pointer to array of drm_vmw_rect - * - * Input argument to the DRM_VMW_UPDATE_LAYOUT Ioctl. - */ - -struct drm_vmw_update_layout_arg { - uint32_t num_outputs; - uint32_t pad64; - uint64_t rects; -}; - - -/*************************************************************************/ -/** * DRM_VMW_FENCE_WAIT * * Waits for a fence object to signal. The wait is interruptible, so that @@ -788,4 +763,28 @@ struct drm_vmw_present_readback_arg { uint64_t clips_ptr; uint64_t fence_rep; }; + +/*************************************************************************/ +/** + * DRM_VMW_UPDATE_LAYOUT - Update layout + * + * Updates the preferred modes and connection status for connectors. The + * command consists of one drm_vmw_update_layout_arg pointing to an array + * of num_outputs drm_vmw_rect's. + */ + +/** + * struct drm_vmw_update_layout_arg + * + * @num_outputs: number of active connectors + * @rects: pointer to array of drm_vmw_rect cast to an uint64_t + * + * Input argument to the DRM_VMW_UPDATE_LAYOUT Ioctl. + */ +struct drm_vmw_update_layout_arg { + uint32_t num_outputs; + uint32_t pad64; + uint64_t rects; +}; + #endif -- 1.7.4.4 [View Less]

1 1

[PATCH] agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set
by Keith Packard 01 Nov '11

01 Nov '11

Kernels with no iommu support cannot ever need the Ironlake work-around, so never enable it in that case. Might be better to completely remove the work-around from the kernel in this case? Signed-off-by: Keith Packard <keithp(a)keithp.com> Cc: Ben Widawsky <ben(a)bwidawsk.net> --- Here's a shorter patch which just elides the body of the needs_idle_maps functions drivers/char/agp/intel-gtt.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/… [View More]

4 5

[PATCH] TTM DMA pool v2.1
by Konrad Rzeszutek Wilk 01 Nov '11

01 Nov '11

[.. and this is what I said in v1 post]: Way back in January this patchset: http://lists.freedesktop.org/archives/dri-devel/2011-January/006905.html was merged in, but pieces of it had to be reverted b/c they did not work properly under PowerPC, ARM, and when swapping out pages to disk. After a bit of discussion on the mailing list http://marc.info/?i=4D769726.2030307@shipmail.org I started working on it, but got waylaid by other things .. and finally I am able to post the RFC patches. There … [View More]was a lot of discussion about it and I am not sure if I captured everybody's thoughts - if I did not - that is _not_ intentional - it has just been quite some time.. Anyhow .. the patches explore what the "lib/dmapool.c" does - which is to have a DMA pool that the device has associated with. I kind of married that code along with drivers/gpu/drm/ttm/ttm_page_alloc.c to create a TTM DMA pool code. The end result is DMA pool with extra features: can do write-combine, uncached, writeback (and tracks them and sets back to WB when freed); tracks "cached" pages that don't really need to be returned to a pool; and hooks up to the shrinker code so that the pools can be shrunk. If you guys think this set of patches make sense - my future plans were 1) Get this in large crowd of testing .. and if it works for a kernel release 2) to move a bulk of this in the lib/dmapool.c (I spoke with Matthew Wilcox about it and he is OK as long as I don't introduce performance regressions). But before I do any of that a second set of eyes taking a look at these patches would be most welcome. In regards to testing, I've been running them non-stop for the last month. (and found some issues which I've fixed up) - and been quite happy with how they work. Michel (thanks!) took a spin of the patches on his PowerPC and they did not cause any regressions (wheew). The patches are also located in a git tree: git://oss.oracle.com/git/kwilk/xen.git devel/ttm.dma_pool.v2.1 Konrad Rzeszutek Wilk (11): swiotlb: Expose swiotlb_nr_tlb function to modules nouveau/radeon: Set coherent DMA mask ttm/radeon/nouveau: Check the DMA address from TTM against known value. ttm: Wrap ttm_[put|get]_pages and extract GFP_* and caching states from 'struct ttm_tt' ttm: Get rid of temporary scaffolding ttm/driver: Expand ttm_backend_func to include two overrides for TTM page pool. ttm: Do not set the ttm->be to NULL before calling the TTM page pool to free pages. ttm: Provide DMA aware TTM page pool code. ttm: Add 'no_dma' parameter to turn the TTM DMA pool off during runtime. nouveau/ttm/dma: Enable the TTM DMA pool if device can only do 32-bit DMA. radeon/ttm/dma: Enable the TTM DMA pool if the device can only do 32-bit. drivers/gpu/drm/nouveau/nouveau_debugfs.c | 1 + drivers/gpu/drm/nouveau/nouveau_mem.c | 5 + drivers/gpu/drm/nouveau/nouveau_sgdma.c | 8 +- drivers/gpu/drm/radeon/radeon_device.c | 6 + drivers/gpu/drm/radeon/radeon_gart.c | 4 +- drivers/gpu/drm/radeon/radeon_ttm.c | 19 +- drivers/gpu/drm/ttm/Makefile | 3 + drivers/gpu/drm/ttm/ttm_memory.c | 5 + drivers/gpu/drm/ttm/ttm_page_alloc.c | 108 ++- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1446 +++++++++++++++++++++++++++++ drivers/gpu/drm/ttm/ttm_tt.c | 21 +- drivers/xen/swiotlb-xen.c | 2 +- include/drm/ttm/ttm_bo_driver.h | 31 + include/drm/ttm/ttm_page_alloc.h | 53 +- include/linux/swiotlb.h | 2 +- lib/swiotlb.c | 5 +- 16 files changed, 1637 insertions(+), 82 deletions(-) [View Less]

5 22

[PATCH] Improvements in edid detection timings (final)
by Eugeni Dodonov 01 Nov '11

01 Nov '11

Those are two identical fixes for improving EDID detection timings, which also fix extremely slow xrandr queries in case of phantom outputs (https://bugs.freedesktop.org/show_bug.cgi?id=41059) The first fix is a small change to drm_edid, which prevents it from talking to non-existent adapters by detecting them faster. The second fix replicates the first one within the i915 driver. It does the same thing, but without touching core DRM files. Those are some of the testing results from our QA … [View More]team: Regressions and functional testing: Machine+ports result Ironlake(mobile) eDP/VGA pass Ironlake(desktop) DP/VGA pass Ironlake(mobile) LVDS/VGA/DP pass G45(desktop) VGA/HDMI pass Pineview(mobile) LVDS/VGA pass xrandr performance: Without patch with patch E6510(Ironlake mobile) 0.119 0.111 PK1(Ironlake desktop) 0.101 0.080 T410b(Ironlake mobile) 0.406 0.114 G45b( G45 desktop) 0.121 0.091 Pnv1(Pineview mobile) 0.043 0.040 Those are the results for machines affected by phantom outputs issue, based on fd.o #41059 feedback: xrandr performance: Without patch with patch System 1 0.840 0.290 System 2 0.690 0.140 System 3 0.315 0.280 System 4 0.175 0.140 System 6 (original issue) 4s 0.184 We have observed no regressions in any cases, and performance improvements of 20-30% for edid detection timing. Combining it with the results obtained at https://bugs.freedesktop.org/show_bug.cgi?id=41059, besides those improvements it also improves xrandr timing by up to 20x in the worst case of phantom outputs. I believe that the better way to fix this is via the drm_get_edid() fix, as it is a one-line fix and could benefit all other chipsets. And we won't have to reinvent the wheel with intel_drm_get_edid, which only duplicates the existent functionality with no additional benefits. Could we have any feedback or reviewed-by or from non-intel drm maintainers? Thanks! Eugeni Dodonov (2): Give up on edid retries when i2c tells us that bus is not there Check if the bus is valid prior to discovering edid. drivers/gpu/drm/drm_edid.c | 5 ++++ drivers/gpu/drm/i915/intel_crt.c | 46 ++++++++++++++++++------------------ drivers/gpu/drm/i915/intel_dp.c | 4 +- drivers/gpu/drm/i915/intel_drv.h | 3 +- drivers/gpu/drm/i915/intel_hdmi.c | 4 +- drivers/gpu/drm/i915/intel_i2c.c | 42 ++++++++++++++++++++++++++++++++ drivers/gpu/drm/i915/intel_lvds.c | 2 +- drivers/gpu/drm/i915/intel_modes.c | 29 +---------------------- drivers/gpu/drm/i915/intel_sdvo.c | 4 +- 9 files changed, 80 insertions(+), 59 deletions(-) -- 1.7.7 [View Less]

8 23

[PATCH v4] drm: do not sleep on vblank while holding a mutex
by Ilija Hadzic 31 Oct '11

31 Oct '11

drm_wait_vblank must be DRM_UNLOCKED because otherwise it will grab the drm_global_mutex and then go to sleep until the vblank event it is waiting for. That can wreck havoc in the windowing system because if one process issues this ioctl, it will block all other processes for the duration of all vblanks between the current and the one it is waiting for. In some cases it can block the entire windowing system. v2: incorporate comments received from Daniel Vetter and Michel Daenzer. v3/v4: … [View More]

2 1

← Newer
1
...
33
34
35
36
37
38
39
...
53
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2011