dri-devel July 2013

dri-devel@lists.freedesktop.org

142 participants
850 discussions

[PATCH] drm/i915: remove unused members from drm_i915_private
by Maarten Lankhorst 10 Jul '13

10 Jul '13

Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> --- diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a416645..d1b1928 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1080,8 +1080,6 @@ typedef struct drm_i915_private { } backlight; /* LVDS info */ - struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */ - struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */ bool no_aux_handshake; struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume 965 */

2 1

[RFC PATCH v4 0/2] Introduce buffer synchronization framework
by Inki Dae 10 Jul '13

10 Jul '13

Hi all, This patch set introduces a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is to provide not only buffer access control to CPU and CPU, and CPU and DMA, and DMA and DMA but also easy-to-use interfaces for device drivers and user application. In addtion, this patch set suggests a way for enhancing performance. to implement generic user mode interface, we have used fcntl system call[4]. As you know, user application sees a buffer object as a dma-buf file descriptor. So fcntl() call with the file descriptor means to lock some buffer region being managed by the dma-buf object. For more detail, you can refer to the dma-buf-sync.txt in Documentation/ Moreover, we had tried to find how we could utilize limited hardware resources more using buffer synchronization mechanism. And finally, we have realized that it could enhance performance using multi threads with this buffer synchronization mechanism: DMA and CPU works individually so CPU could perform other works while DMA is performing some works, and vise versa. However, in the conventional way, that is not easy to do so because DMA operation is depend on CPU operation, and vice versa. Conventional way: User Kernel --------------------------------------------------------------------- CPU writes something to src send the src to driver-------------------------> update DMA register request DMA start(1)---------------------------> DMA start <---------completion signal(2)---------- CPU accesses dst (1) Request DMA start after the CPU access to src buffer is completed. (2) Access dst buffer after DMA access to the dst buffer is completed. On the other hand, if there is something to control buffer access between CPU and DMA? The below shows that: User(thread a) User(thread b) Kernel --------------------------------------------------------------------- send a src to driver----------------------------------> update DMA register lock the src request DMA start(1)----------> CPU acccess to src unlock the src lock src and dst DMA start <-------------completion signal(2)------------- lock dst DMA completion CPU access to dst unlock src and dst unlock DST (1) Try to start DMA operation while CPU is accessing the src buffer. (2) Try CPU access to dst buffer while DMA is accessing the dst buffer. This means that CPU or DMA could do more works. In the same way, we could reduce hand shaking overhead between two processes when those processes need to share a shared buffer. There may be other cases that we could reduce overhead as well. References: [1] http://lwn.net/Articles/470339/ [2] http://lwn.net/Articles/532616/ [3] https://patchwork.kernel.org/patch/2625361/ [4] http://linux.die.net/man/2/fcntl Inki Dae (2): dmabuf-sync: Introduce buffer synchronization framework dma-buf: add lock callback for fcntl system call. Documentation/dma-buf-sync.txt | 283 +++++++++++++++++ drivers/base/Kconfig | 7 + drivers/base/Makefile | 1 + drivers/base/dma-buf.c | 34 ++ drivers/base/dmabuf-sync.c | 661 ++++++++++++++++++++++++++++++++++++++++ include/linux/dma-buf.h | 14 + include/linux/dmabuf-sync.h | 132 ++++++++ include/linux/reservation.h | 9 + 8 files changed, 1141 insertions(+), 0 deletions(-) create mode 100644 Documentation/dma-buf-sync.txt create mode 100644 drivers/base/dmabuf-sync.c create mode 100644 include/linux/dmabuf-sync.h -- 1.7.5.4

1 2

[PATCH] drm/rcar-du: Add missing dependency on CMA
by Mark Brown 10 Jul '13

10 Jul '13

From: Mark Brown <broonie(a)linaro.org> The driver uses CMA APIs so won't link if CMA is not being built. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/gpu/drm/rcar-du/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig index 72887df..e75575a 100644 --- a/drivers/gpu/drm/rcar-du/Kconfig +++ b/drivers/gpu/drm/rcar-du/Kconfig @@ -1,6 +1,6 @@ config DRM_RCAR_DU tristate "DRM Support for R-Car Display Unit" - depends on DRM && ARM + depends on DRM && ARM && CMA select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER select DRM_GEM_CMA_HELPER -- 1.8.3.2

3 3

[PATCH v2] Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb"
by Guenter Roeck 10 Jul '13

10 Jul '13

This patch partially reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970 for IvyBridge CPUs. The original commit results in repeated 'Timed out waiting for forcewake old ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b) with i7-3770K CPU. It ultimately results in a hangup if the system is highly loaded. Reverting the commit for IvyBridge CPUs fixes the issue. Issue a warning if the CPU is IvyBridge and mt forcewake is disabled, since this condition can result in secondary issues. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541 Cc: Jesse Barnes <jbarnes(a)virtuousgeek.org> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala(a)intel.com> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> --- v2: Only revert patch for Ivybridge CPUs Issue info message if mt forcewake is disabled on Ivybridge drivers/gpu/drm/i915/intel_pm.c | 31 ++++++++++++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index aa01128..0392c28 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4510,9 +4510,38 @@ void intel_gt_init(struct drm_device *dev) if (IS_VALLEYVIEW(dev)) { dev_priv->gt.force_wake_get = vlv_force_wake_get; dev_priv->gt.force_wake_put = vlv_force_wake_put; - } else if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) { + } else if (IS_HASWELL(dev)) { dev_priv->gt.force_wake_get = __gen6_gt_force_wake_mt_get; dev_priv->gt.force_wake_put = __gen6_gt_force_wake_mt_put; + } else if (IS_IVYBRIDGE(dev)) { + u32 ecobus; + + /* IVB configs may use multi-threaded forcewake */ + + /* A small trick here - if the bios hasn't configured + * MT forcewake, and if the device is in RC6, then + * force_wake_mt_get will not wake the device and the + * ECOBUS read will return zero. Which will be + * (correctly) interpreted by the test below as MT + * forcewake being disabled. + */ + mutex_lock(&dev->struct_mutex); + __gen6_gt_force_wake_mt_get(dev_priv); + ecobus = I915_READ_NOTRACE(ECOBUS); + __gen6_gt_force_wake_mt_put(dev_priv); + mutex_unlock(&dev->struct_mutex); + + if (ecobus & FORCEWAKE_MT_ENABLE) { + dev_priv->gt.force_wake_get = + __gen6_gt_force_wake_mt_get; + dev_priv->gt.force_wake_put = + __gen6_gt_force_wake_mt_put; + } else { + DRM_INFO("No MT forcewake available on Ivybridge, this can result in issues\n"); + DRM_INFO("when using vblank-synced partial screen updates.\n"); + dev_priv->gt.force_wake_get = __gen6_gt_force_wake_get; + dev_priv->gt.force_wake_put = __gen6_gt_force_wake_put; + } } else if (IS_GEN6(dev)) { dev_priv->gt.force_wake_get = __gen6_gt_force_wake_get; dev_priv->gt.force_wake_put = __gen6_gt_force_wake_put; -- 1.7.9.7

2 1

[Bug 60510] New: AMD Mobility Radeon HD4650 Screen Corruption with DPM
by bugzilla-daemon＠bugzilla.kernel.org 10 Jul '13

10 Jul '13

https://bugzilla.kernel.org/show_bug.cgi?id=60510 Bug ID: 60510 Summary: AMD Mobility Radeon HD4650 Screen Corruption with DPM Product: Drivers Version: 2.5 Kernel Version: 3.10.0-drm-next-20130705 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: yjwong92(a)gmail.com Regression: No I'm testing out the new DPM patches on drm-next-3.11. When there is heavy screen updates (i.e. dragging windows around), screen corruption appears (see video). DPM otherwise works perfectly; system runs cooler and UVD also works perfectly fine. Corruption does not occur with radeon.dpm off. There is nothing unusual in the kernel logs. I can provide more info if requested. Video link: http://www.youtube.com/watch?v=WaWHBckwPpo&feature=youtu.be -- You are receiving this mail because: You are watching the assignee of the bug.

1 7

Adding drm-intel-fixes branch to linux-next
by Daniel Vetter 10 Jul '13

10 Jul '13

Hi Stephen Can you please add the drm-intel-fixes branch to your linux-next tree on top of the for-linux-next branch you've already included from my drm-intel repo at git://people.freedesktop.org/~danvet/drm-intel ? I'm asking since I've merged a patch to -fixes late in the 3.10 cycle and despite that I've let it soak for almost two week in my -fixes branch it readily blew up once 3.10 shipped. I think that the added tester populace of linux-next could have prevented this gaffle. The bug report for reference: https://bugzilla.kernel.org/show_bug.cgi?id=60530 Note that atm for-linux-next points at the same commit as drm-intel-fixes (since we're in the merge window), so adding this branch shouldn't add new conflicts. I just want to be ready after -rc1 is tagged, since then I'll push our feature branch for 3.12 onto for-linux-next, which will kick the patches on -fixes out of linux-next. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

2 1

[PATCH] Revert "drm/i915: unconditionally use mt forcewake on hsw/ivb"
by Guenter Roeck 09 Jul '13

09 Jul '13

This reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970. The commit results in repeated 'Timed out waiting for forcewake old ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b) with i7-3770K CPU. It ultimately results in a hangup if the system is highly loaded. Reverting the commit fixes the issue. While I understand that this should be fixed in the BIOS, a more recent BIOS is not available fron the vendor. If/since no better solution is not available, reverting the patch seems to be the way to go (otherwise me and others with the same problem won't be able to run the upstream kernel on affected boards). Cc: Jesse Barnes <jbarnes(a)virtuousgeek.org> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala(a)intel.com> Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> --- drivers/gpu/drm/i915/intel_pm.c | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index aa01128..5bae9ba 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4510,12 +4510,35 @@ void intel_gt_init(struct drm_device *dev) if (IS_VALLEYVIEW(dev)) { dev_priv->gt.force_wake_get = vlv_force_wake_get; dev_priv->gt.force_wake_put = vlv_force_wake_put; - } else if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) { - dev_priv->gt.force_wake_get = __gen6_gt_force_wake_mt_get; - dev_priv->gt.force_wake_put = __gen6_gt_force_wake_mt_put; - } else if (IS_GEN6(dev)) { + } else if (INTEL_INFO(dev)->gen >= 6) { dev_priv->gt.force_wake_get = __gen6_gt_force_wake_get; dev_priv->gt.force_wake_put = __gen6_gt_force_wake_put; + + /* IVB configs may use multi-threaded forcewake */ + if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) { + u32 ecobus; + + /* A small trick here - if the bios hasn't configured + * MT forcewake, and if the device is in RC6, then + * force_wake_mt_get will not wake the device and the + * ECOBUS read will return zero. Which will be + * (correctly) interpreted by the test below as MT + * forcewake being disabled. + */ + mutex_lock(&dev->struct_mutex); + __gen6_gt_force_wake_mt_get(dev_priv); + ecobus = I915_READ_NOTRACE(ECOBUS); + __gen6_gt_force_wake_mt_put(dev_priv); + mutex_unlock(&dev->struct_mutex); + + if (ecobus & FORCEWAKE_MT_ENABLE) { + DRM_DEBUG_KMS("Using MT version of forcewake\n"); + dev_priv->gt.force_wake_get = + __gen6_gt_force_wake_mt_get; + dev_priv->gt.force_wake_put = + __gen6_gt_force_wake_mt_put; + } + } } INIT_DELAYED_WORK(&dev_priv->rps.delayed_resume_work, intel_gen6_powersave_work); -- 1.7.9.7

2 2

[Bug 66651] New: RV730: Screen flicker with radeon.pdm=1
by bugzilla-daemon＠freedesktop.org 09 Jul '13

09 Jul '13

https://bugs.freedesktop.org/show_bug.cgi?id=66651 Priority: medium Bug ID: 66651 Assignee: dri-devel(a)lists.freedesktop.org Summary: RV730: Screen flicker with radeon.pdm=1 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: tball(a)io.dk Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 82126 --> https://bugs.freedesktop.org/attachment.cgi?id=82126&action=edit Dmesg Hello I am testing the new dpm code on my RV730 card: $ lspci -v 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV730/M96 [Mobility Radeon HD 4650/5165] (prog-if 00 [VGA controller]) Subsystem: COMPAL Electronics Inc Device 003e Flags: bus master, fast devsel, latency 0, IRQ 50 Memory at d0000000 (32-bit, prefetchable) [size=256M] I/O ports at 2000 [size=256] Memory at cfef0000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at cfe00000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: radeon The screen constantly flickers, everytime I interact with the computer like moving the mouse og touching the keyboard. If I don't interact the computer, the flickering is alot less. If I boot without radeon.dpm=1, the flicker dissapears. The flickering is best descripted as if the screen is jumping up and down very fast. Using the latest ucode for my card: - R700_rlc.bin - RV730_smc.bin - RV730_pfp.bin Using Xorg edgers in Ubuntu 13.04. Using Ubuntu drm-next kernel: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/2013-07-04-saucy/ Git: 69163ea82732894e8c1e17df4010372ed078efdd Attached dmesg, but there is no errors to be seen. -- You are receiving this mail because: You are the assignee for the bug.

1 7

[PATCH 0/5] kill omap_gem_helpers
by Rob Clark 09 Jul '13

09 Jul '13

Move omap_gem_helpers to core, since I'll need some of the same helpers for msm driver. Also update udl and gma500 to use the helpers. Possibly i915 could as well, although it does some more sophisticated things so I'll leave that for now. Rob Clark (5): drm/gem: add drm_gem_create_mmap_offset_size() drm/gem: add shmem get/put page helpers drm/gma500: use gem get/put page helpers drm/udl: use gem get/put page helpers drm/omap: kill omap_gem_helpers.c drivers/gpu/drm/drm_gem.c | 119 +++++++++++++++++++- drivers/gpu/drm/gma500/gtt.c | 38 +------ drivers/gpu/drm/omapdrm/Makefile | 3 - drivers/gpu/drm/omapdrm/omap_gem.c | 8 +- drivers/gpu/drm/omapdrm/omap_gem_helpers.c | 169 ----------------------------- drivers/gpu/drm/udl/udl_gem.c | 44 +------- include/drm/drmP.h | 5 + 7 files changed, 136 insertions(+), 250 deletions(-) delete mode 100644 drivers/gpu/drm/omapdrm/omap_gem_helpers.c -- 1.8.1.4

4 11

[Bug 60517] New: Xorg crash loops after upgrade to kernel 3.10.
by bugzilla-daemon＠bugzilla.kernel.org 09 Jul '13

09 Jul '13

https://bugzilla.kernel.org/show_bug.cgi?id=60517 Bug ID: 60517 Summary: Xorg crash loops after upgrade to kernel 3.10. Product: Drivers Version: 2.5 Kernel Version: 3.10 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: knut.tidemann(a)gmail.com Regression: No Created attachment 106807 --> https://bugzilla.kernel.org/attachment.cgi?id=106807&action=edit Xorg.log I'm running Arch linux and after I updated and rebooted due to kernel 3.10 hitting the Testing repository I've experienced many X.org crashes du to bus errors. I've attached both my X.org log file and a dmesg output. The crash it self happens (seemingly) random, but after the first crash it crashes again right after I log into KDE. Probably when desktop effects are started. I have a Radeon HD 5670 card, and I run mesa from git with daily updates. I've also tried out the new UVD acceleration and got the error that is displayed in the kernel log. -- You are receiving this mail because: You are watching the assignee of the bug.

1 5

← Newer
1
...
74
75
76
77
78
79
80
...
85
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2013