dri-devel December 2011

dri-devel@lists.freedesktop.org

83 participants
552 discussions

[PATCH] drm/radeon/kms: bail on BTC parts if MC ucode is missing
by alexdeucher＠gmail.com 09 Dec '11

09 Dec '11

From: Alex Deucher <alexander.deucher(a)amd.com> We already do this for cayman, need to also do it for BTC parts. The default memory and voltage setup is not adequate for advanced operation. Continuing will result in an unusable display. Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)kernel.org Cc: Jean Delvare <khali(a)linux-fr.org> --- drivers/gpu/drm/radeon/evergreen.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index 3e8054c..93c0348 100644 --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -3468,6 +3468,18 @@ int evergreen_init(struct radeon_device *rdev) evergreen_pcie_gart_fini(rdev); rdev->accel_working = false; } + + /* Don't start up if the MC ucode is missing on BTC parts. + * The default clocks and voltages before the MC ucode + * is loaded are not suffient for advanced operations. + */ + if (ASIC_IS_DCE5(rdev)) { + if (!rdev->mc_fw && !(rdev->flags & RADEON_IS_IGP)) { + DRM_ERROR("radeon: MC ucode required for NI+.\n"); + return -EINVAL; + } + } + return 0; } -- 1.7.3.4

2 1

[PATCH] drm/i915: Clean up multi-threaded forcewake patch
by Keith Packard 09 Dec '11

09 Dec '11

We learned that the ECOBUS register was inside the GT power well, and so *did* need force wake to be read, so it gets removed from the list of 'doesn't need force wake' registers. That means the code reading ECOBUS after forcing the mt_force_wake function to be called needs to use I915_READ_NOTRACE; it doesn't need to do more force wake fun as it's already done it manually. This also adds a comment explaining why the MT forcewake testing code only needs to call mt_forcewake_get/put and not disable RC6 manually -- the ECOBUS read will return 0 if the device is in RC6 and isn't using MT forcewake, causing the test to work correctly. Signed-off-by: Keith Packard <keithp(a)keithp.com> Cc: Jesse Barnes <jbarnes(a)virtuousgeek.org> --- drivers/gpu/drm/i915/i915_drv.c | 7 ------- drivers/gpu/drm/i915/i915_drv.h | 3 +-- drivers/gpu/drm/i915/intel_display.c | 8 +++++++- 3 files changed, 8 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 28836fe..e63a0f0 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -922,13 +922,6 @@ MODULE_AUTHOR(DRIVER_AUTHOR); MODULE_DESCRIPTION(DRIVER_DESC); MODULE_LICENSE("GPL and additional rights"); -/* We give fast paths for the really cool registers */ -#define NEEDS_FORCE_WAKE(dev_priv, reg) \ - (((dev_priv)->info->gen >= 6) && \ - ((reg) < 0x40000) && \ - ((reg) != FORCEWAKE) && \ - ((reg) != ECOBUS)) - #define __i915_read(x, y) \ u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \ u##x val = 0; \ diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 1421118..bbd0604 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1364,8 +1364,7 @@ void __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv); #define NEEDS_FORCE_WAKE(dev_priv, reg) \ (((dev_priv)->info->gen >= 6) && \ ((reg) < 0x40000) && \ - ((reg) != FORCEWAKE) && \ - ((reg) != ECOBUS)) + ((reg) != FORCEWAKE)) #define __i915_read(x, y) \ u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index a03ebf6..5abfc36 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8539,9 +8539,15 @@ static void intel_init_display(struct drm_device *dev) if (IS_IVYBRIDGE(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(ECOBUS); + ecobus = I915_READ_NOTRACE(ECOBUS); __gen6_gt_force_wake_mt_put(dev_priv); mutex_unlock(&dev->struct_mutex); -- 1.7.7.3

1 0

[Bug 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
by bugzilla-daemon＠freedesktop.org 09 Dec '11

09 Dec '11

https://bugs.freedesktop.org/show_bug.cgi?id=35460 --- Comment #17 from Chris Wilson <chris(a)chris-wilson.co.uk> 2011-12-09 07:25:13 PST --- No, we don't buffer cursors. A single cursor bo is updated every time its image changes. (Whilst possible, I don't it is an interesting optimisation to cache the bo for a variety of cursors.) This could just be a bad bit of RAM, bad cache, or signs of incoherency... Can you retry Daniel's original overkill patch and see if this corruption ever turns up? Though I think we can safely say that the current mb is an improvement. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901
by bugzilla-daemon＠freedesktop.org 09 Dec '11

09 Dec '11

https://bugs.freedesktop.org/show_bug.cgi?id=35460 --- Comment #16 from Bruno <bonbons67(a)internet.lu> 2011-12-09 06:46:26 PST --- (In reply to comment #15 and comment #14 with attachment 53954) > > use wmb to flush the wc cache > > Running for a week now with this patch instead of the other one and have not > seen cursor corruptions. Well, today I had the 8-pixel-line curruption on a cursor and interestingly it survived cursor switches between enlightenment (colorful arrow - corrupted) and gnumeric (cell '+' cursor), but passing over claws-mail caused enlightenment cursor to no have corruption enymore. Does the hardware store multiple cursors or somehow have multiple cursor buffers around which can get corrupted and remain corrupted (double-buffering on cursors)? Bruno -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

Re: [Intel-gfx] [PATCH] drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a
by Bobby Powers 09 Dec '11

09 Dec '11

On Tue, Dec 6, 2011 at 12:43 PM, Ben Widawsky <ben(a)bwidawsk.net> wrote: > On Tue, Dec 06, 2011 at 12:12:33PM +0100, Daniel Vetter wrote: >> The recursion loop goes retire_requests->unbind->gpu_idle->retire_reqeusts. >> >> Every time we go through this we need a >> - active object that can be retired >> - and there are no other references to that object than the one from >> the active list, so that it gets unbound and freed immediately. >> Otherwise the recursion stops. So the recursion is only limited by the >> number of objects that fit these requirements sitting in the active list >> any time retire_request is called. >> >> Issue exercised by tests/gem_unref_active_buffers from i-g-t. >> >> There's been a decent bikeshed discussion whether it wouldn't be >> better to pass around a flag, but imo this is o.k. for such a limited >> case that only supports a w/a. >> >> Signed-Off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> >> Reviewed-by: Chris Wilson <chris@chris-wilson> # we built better >> bikesheds, but this keeps the rain off for now >> --- > > What about: > http://lists.freedesktop.org/archives/intel-gfx/2011-October/012984.html > > > Did someone prove that doesn't work? This patch caused hard lockups for me after ~35 minutes of casual use (twice). I've attached the oopses. I'm running a Fedora 16 machine, Lenovo T420 (i5-2540M w/ VT-d enabled), and at each time had a Windows 7 KVM guest idling (not sure if that is relevant). With this patch reverted, I've had ~ 6 hours of oops free uptime. Let me know what additional information I can provide, or if there is anything I can test to help narrow the issue down. yours, Bobby ~~~ [bpowers@fina linux]$ lspci 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04) 00:1a.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4) 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b4) 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b4) 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4) 00:1d.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset Family LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04) 03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 (rev 34) 0d:00.0 System peripheral: Ricoh Co Ltd Device e823 (rev 08) 0d:00.3 FireWire (IEEE 1394): Ricoh Co Ltd FireWire Host Controller (rev 04) [bpowers@fina linux]$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz stepping : 7 microcode : 0x18 cpu MHz : 800.000 cache size : 3072 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips : 5184.24 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: [3 other processors omitted]

1 2

[PATCH] drm: Change order to turn off the crtc and plane with fb cleanup
by Joonyoung Shim 09 Dec '11

09 Dec '11

Ths plane is enabled after the crtc is setted first, so first turn off the plane than the crtc. If not, it can occur some side effects because it may have to use any information of crtc when turns off the plane. Signed-off-by: Joonyoung Shim <jy0922.shim(a)samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park(a)samsung.com> --- drivers/gpu/drm/drm_crtc.c | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index e2c9386..73eeace 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -329,6 +329,15 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb) struct drm_mode_set set; int ret; + list_for_each_entry(plane, &dev->mode_config.plane_list, head) { + if (plane->fb == fb) { + /* should turn off the plane */ + ret = plane->funcs->disable_plane(plane); + if (ret) + DRM_ERROR("failed to disable plane with busy fb\n"); + } + } + /* remove from any CRTC */ list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) { if (crtc->fb == fb) { @@ -342,15 +351,6 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb) } } - list_for_each_entry(plane, &dev->mode_config.plane_list, head) { - if (plane->fb == fb) { - /* should turn off the crtc */ - ret = plane->funcs->disable_plane(plane); - if (ret) - DRM_ERROR("failed to disable plane with busy fb\n"); - } - } - drm_mode_object_put(dev, &fb->base); list_del(&fb->head); dev->mode_config.num_fb--; -- 1.7.5.4

1 0

[PATCH] drm/vmwgfx: fix incorrect VRAM size check in vmw_kms_fb_create()
by Xi Wang 08 Dec '11

08 Dec '11

The commit e133e737 didn't correctly fix the overflow issue. - unsigned int required_size; + u64 required_size; ... required_size = mode_cmd->pitch * mode_cmd->height; - if (unlikely(required_size > dev_priv->vram_size)) { + if (unlikely(required_size > (u64) dev_priv->vram_size)) { Since pitch and height are u32, their product is still 32-bit and would overflow. Converting the result to u64 cannot help. A correct way is to convert pitch and height to u64 before the multiplication. required_size = (u64)mode_cmd->pitch * (u64)mode_cmd->height; This fix calls vmw_kms_validate_mode_vram() for validation. Signed-off-by: Xi Wang <xi.wang(a)gmail.com> Cc: Thomas Hellstrom <thellstrom(a)vmware.com> Cc: Dave Airlie <airlied(a)redhat.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index 37d4054..582a4d7 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -1003,7 +1003,6 @@ static struct drm_framebuffer *vmw_kms_fb_create(struct drm_device *dev, struct vmw_surface *surface = NULL; struct vmw_dma_buffer *bo = NULL; struct ttm_base_object *user_obj; - u64 required_size; int ret; /** @@ -1012,8 +1011,9 @@ static struct drm_framebuffer *vmw_kms_fb_create(struct drm_device *dev, * requested framebuffer. */ - required_size = mode_cmd->pitch * mode_cmd->height; - if (unlikely(required_size > (u64) dev_priv->vram_size)) { + if (!vmw_kms_validate_mode_vram(dev_priv, + mode_cmd->pitch, + mode_cmd->height)) { DRM_ERROR("VRAM size is too small for requested mode.\n"); return ERR_PTR(-ENOMEM); } -- 1.7.5.4

1 0

[PATCH 0/2] omap/drm: dmm/tiler support for GEM buffers
by Rob Clark 08 Dec '11

08 Dec '11

From: Rob Clark <rob(a)ti.com> Support for DMM and tiled buffers. The DMM/TILER block in omap4+ SoC provides support for remapping physically discontiguous buffers for various DMA initiators (DSS, IVAHD, etc) which do not otherwise support non-physically contiguous buffers, as well as providing support for tiled buffers. See the descriptions in the following two patches for more details. Andy Gross (1): drm/omap: DMM/TILER support for OMAP4+ platform Rob Clark (1): drm/omap: add GEM support for tiled/dmm buffers drivers/staging/omapdrm/Makefile | 10 +- drivers/staging/omapdrm/TODO | 6 + drivers/staging/omapdrm/omap_dmm_priv.h | 187 ++++++++ drivers/staging/omapdrm/omap_dmm_tiler.c | 672 ++++++++++++++++++++++++++ drivers/staging/omapdrm/omap_dmm_tiler.h | 130 +++++ drivers/staging/omapdrm/omap_drm.h | 2 +- drivers/staging/omapdrm/omap_drv.c | 27 +- drivers/staging/omapdrm/omap_drv.h | 3 + drivers/staging/omapdrm/omap_fb.c | 2 +- drivers/staging/omapdrm/omap_gem.c | 432 ++++++++++++++++-- drivers/staging/omapdrm/omap_gem_helpers.c | 55 +++ drivers/staging/omapdrm/omap_priv.h | 7 +- drivers/staging/omapdrm/tcm-sita.c | 703 ++++++++++++++++++++++++++++ drivers/staging/omapdrm/tcm-sita.h | 95 ++++ drivers/staging/omapdrm/tcm.h | 326 +++++++++++++ 15 files changed, 2609 insertions(+), 48 deletions(-) create mode 100644 drivers/staging/omapdrm/omap_dmm_priv.h create mode 100644 drivers/staging/omapdrm/omap_dmm_tiler.c create mode 100644 drivers/staging/omapdrm/omap_dmm_tiler.h create mode 100644 drivers/staging/omapdrm/tcm-sita.c create mode 100644 drivers/staging/omapdrm/tcm-sita.h create mode 100644 drivers/staging/omapdrm/tcm.h -- 1.7.5.4

4 8

[Bug 26345] [845G] CPU/GPU incoherency
by bugzilla-daemon＠freedesktop.org 08 Dec '11

08 Dec '11

https://bugs.freedesktop.org/show_bug.cgi?id=26345 Mike Ranweiler <mjr(a)linux.vnet.ibm.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjr(a)linux.vnet.ibm.com --- Comment #141 from Mike Ranweiler <mjr(a)linux.vnet.ibm.com> 2011-12-08 10:35:22 PST --- Hi, I've hit this too with: 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03) I tried the patch in comment #138 against 3.2.0-rc4, and I had similar results as comment #139 - the display wasn't usable. Is there anything else I can try? I have the system readily available. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[patch] drm/ttm: fix condition (and vs or)
by Dan Carpenter 08 Dec '11

08 Dec '11

The "if (!p && !p->dev)" condition isn't right because || was intended instead of &&. But actually, "p" is the list cursor and so it's always non-NULL and we can just remove that bit. We can remove the another similar check as well. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c index 6678abc..1cf4c2c 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c @@ -930,10 +930,8 @@ static int ttm_dma_pool_get_num_unused_pages(void) unsigned total = 0; mutex_lock(&_manager->lock); - list_for_each_entry(p, &_manager->pools, pools) { - if (p) - total += p->pool->npages_free; - } + list_for_each_entry(p, &_manager->pools, pools) + total += p->pool->npages_free; mutex_unlock(&_manager->lock); return total; } @@ -1023,7 +1021,7 @@ static int ttm_dma_pool_mm_shrink(struct shrinker *shrink, list_for_each_entry(p, &_manager->pools, pools) { unsigned nr_free; - if (!p && !p->dev) + if (!p->dev) continue; if (shrink_pages == 0) break;

4 3

← Newer
1
...
48
49
50
51
52
53
54
55
56
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2011