dri-devel January 2012

dri-devel@lists.freedesktop.org

91 participants
570 discussions

[PATCH] drm/radeon/kms: Add DDC quirk for ASUS RS400
by alexdeucher＠gmail.com 03 Jan '12

03 Jan '12

From: Alex Deucher <alexander.deucher(a)amd.com> vbios is missing a ddc entry for the DVI-D port. Reported by ponyofdeath on IRC. Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/radeon/radeon_combios.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c index 81fc100..b9ad45e 100644 --- a/drivers/gpu/drm/radeon/radeon_combios.c +++ b/drivers/gpu/drm/radeon/radeon_combios.c @@ -2152,6 +2152,7 @@ static bool radeon_apply_legacy_quirks(struct drm_device *dev, struct radeon_i2c_bus_rec *ddc_i2c, struct radeon_hpd *hpd) { + struct radeon_device *rdev = dev->dev_private; /* Certain IBM chipset RN50s have a BIOS reporting two VGAs, one with VGA DDC and one with CRT2 DDC. - kill the CRT2 DDC one */ @@ -2170,6 +2171,14 @@ static bool radeon_apply_legacy_quirks(struct drm_device *dev, return false; } + /* ASUS RS400 system with missing DVI port DDC */ + if (dev->pdev->device == 0x5A41 && + dev->pdev->subsystem_vendor == 0x1043 && + dev->pdev->subsystem_device == 0x81C8) { + if (*legacy_connector == CONNECTOR_DVI_D_LEGACY) + *ddc_i2c = combios_setup_i2c_bus(rdev, DDC_MONID, 0, 0); + } + return true; } -- 1.7.3.4

2 1

[RFC PATCH 0/9] Remove useless on_each_cpu return value
by Gilad Ben-Yossef 03 Jan '12

03 Jan '12

on_each_cpu() returns as its own return value the return value of smp_call_function(). smp_call_function() in turn returns a hard coded value of zero. Some callers to on_each_cpu() waste cycles and bloat code space by checking the return value to on_each_cpu(), probably for historical reasons. This patch set refactors callers to not test on_each_cpu() (fixed) return value and then refactors on_each_cpu to return void to avoid confusing future users. In other words, this patch aims to delete 18 source code lines while not changing any functionality :-) I tested as best as I could the x86 changes and compiled some of the others, but I don't have access to all the needed hardware for testing. Reviewers and testers welcome! CC: Michal Nazarewicz <mina86(a)mina86.com> CC: David Airlie <airlied(a)linux.ie> CC: dri-devel(a)lists.freedesktop.org CC: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> CC: Paul Mackerras <paulus(a)samba.org> CC: Grant Likely <grant.likely(a)secretlab.ca> CC: Rob Herring <rob.herring(a)calxeda.com> CC: linuxppc-dev(a)lists.ozlabs.org CC: devicetree-discuss(a)lists.ozlabs.org CC: Richard Henderson <rth(a)twiddle.net> CC: Ivan Kokshaysky <ink(a)jurassic.park.msu.ru> CC: Matt Turner <mattst88(a)gmail.com> CC: linux-alpha(a)vger.kernel.org CC: Thomas Gleixner <tglx(a)linutronix.de> CC: Ingo Molnar <mingo(a)redhat.com> CC: "H. Peter Anvin" <hpa(a)zytor.com> CC: x86(a)kernel.org CC: Tony Luck <tony.luck(a)intel.com> CC: Fenghua Yu <fenghua.yu(a)intel.com> CC: linux-ia64(a)vger.kernel.org CC: Will Deacon <will.deacon(a)arm.com> CC: Peter Zijlstra <a.p.zijlstra(a)chello.nl> CC: Arnaldo Carvalho de Melo <acme(a)ghostprotocols.net> CC: Russell King <linux(a)arm.linux.org.uk> CC: linux-arm-kernel(a)lists.infradead.org Gilad Ben-Yossef (9): arm: avoid using on_each_cpu hard coded ret value ia64: avoid using on_each_cpu hard coded ret value x86: avoid using on_each_cpu hard coded ret value alpha: avoid using on_each_cpu hard coded ret value ppc: avoid using on_each_cpu hard coded ret value agp: avoid using on_each_cpu hard coded ret value drm: avoid using on_each_cpu hard coded ret value smp: refactor on_each_cpu to void returning func x86: refactor wbinvd_on_all_cpus to void function arch/alpha/kernel/smp.c | 7 ++----- arch/arm/kernel/perf_event.c | 2 +- arch/ia64/kernel/perfmon.c | 12 ++---------- arch/powerpc/kernel/rtas.c | 3 +-- arch/x86/include/asm/smp.h | 5 ++--- arch/x86/lib/cache-smp.c | 4 ++-- drivers/char/agp/generic.c | 3 +-- drivers/gpu/drm/drm_cache.c | 3 +-- include/linux/smp.h | 7 +++---- kernel/smp.c | 6 ++---- 10 files changed, 17 insertions(+), 35 deletions(-)

2 4

[Bug 42131] New: Problem with resizing OpenGL windows when using XCB
by bugzilla-daemon＠freedesktop.org 03 Jan '12

03 Jan '12

https://bugs.freedesktop.org/show_bug.cgi?id=42131 Bug #: 42131 Summary: Problem with resizing OpenGL windows when using XCB Classification: Unclassified 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: nilschrbrause(a)googlemail.com Created attachment 52651 --> https://bugs.freedesktop.org/attachment.cgi?id=52651 Test program demonstrating the problem The attached program creates a window using XCB and draws a rectangle inside it using OpenGL. When using indirect software rendering (LIBGL_ALWAYS_INDIRECT=1), everything works as expected. But when using the R600 Gallium3D driver, the OpenGL view port doesn't seem to get resized properly and the window contents get screwed up. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[PATCH] drm/radeon/kms: disable writeback on pre-R300 asics
by alexdeucher＠gmail.com 03 Jan '12

03 Jan '12

From: Alex Deucher <alexander.deucher(a)amd.com> We often end up missing fences on older asics with writeback enabled which leads to delays in the userspace accel code, so just disable it by default on those asics. Reported-by: Helge Deller <deller(a)gmx.de> Reported-by: Dave Airlie <airlied(a)redhat.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/radeon/radeon_device.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 5fcf135..420db65 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -228,8 +228,11 @@ int radeon_wb_init(struct radeon_device *rdev) if (radeon_no_wb == 1) rdev->wb.enabled = false; else { - /* often unreliable on AGP */ if (rdev->flags & RADEON_IS_AGP) { + /* often unreliable on AGP */ + rdev->wb.enabled = false; + } else if (rdev->family < CHIP_R300) { + /* often unreliable on pre-r300 */ rdev->wb.enabled = false; } else { rdev->wb.enabled = true; -- 1.7.3.4

1 0

[git pull] drm fix
by Dave Airlie 03 Jan '12

03 Jan '12

Hi Linus, just a small fix for a possible oops in radeon. Dave. The following changes since commit 115e8e705e4be071b9e06ff72578e3b603f2ba65: Merge branch 'devicetree/merge' of git://git.secretlab.ca/git/linux-2.6 (2012-01-02 12:34:03 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alexander Müller (1): drm/radeon/kms/atom: fix possible segfault in pm setup drivers/gpu/drm/radeon/radeon_atombios.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-)

1 0

radeon_atrm_get_bios() seems to be quite slow
by Petr Štetiar 02 Jan '12

02 Jan '12

Hi, for some time (I don't remember since when) I'm experiencing quite strange long boot times on my laptop. I've tracked it down to the GPU init code, namely to function radeon_atrm_get_bios(). This function takes about 25-30 seconds to complete on my laptop on every reboot. I believe that it's not normal, nor expected behaviour, so I've added some debug printks in the code as can be seen in attached patch and the damn slow boot can be seen in attached dmesg log also. I would like to note, that if I rmmod/modprobe radeon module after that long boot, it takes about 2 seconds to complete. To me it seems, like some issue in acpi_evaluate_object() but I'm not sure 100% yet. Does anyone have any clue what could be happening there? I'm running vanilla 3.1.6 if it matters. Thanks a lot for any pointers. -- ynezz

1 0

GPU hung with Linux-3.2-rc6
by Udo Steinberg 02 Jan '12

02 Jan '12

Hi, With Linux-3.2-rc6 I'm frequently seeing GPU hangs when large amounts of text scroll in an xterm, such as when extracting a tar archive. Such as this one (note the timestamps): [22865.157750] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [22865.157763] [drm:kick_ring] *ERROR* Kicking stuck semaphore on render ring [22871.165992] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [22871.166008] [drm:kick_ring] *ERROR* Kicking stuck semaphore on render ring [22877.417902] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [22877.417915] [drm:kick_ring] *ERROR* Kicking stuck semaphore on render ring [22883.426132] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [22883.426146] [drm:kick_ring] *ERROR* Kicking stuck semaphore on render ring These hangs did not occur with Linux 3.1 or they were so infrequent that I didn't notice them. The machine is an x220 laptop with SNB CPU. The kernel command line contains: i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 Note that VT-d is enabled in the BIOS, but the kernel is compiled without IOMMU support. Because the IOMMU is not enabled, I'm inclined to think that this problem is not VT-d related. Cheers, - Udo

4 11

[Bug 43964] Rendering is distorded in Penumbra Overture game
by bugzilla-daemon＠freedesktop.org 02 Jan '12

02 Jan '12

https://bugs.freedesktop.org/show_bug.cgi?id=43964 Laurent carlier <lordheavym(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |NOTABUG --- Comment #5 from Laurent carlier <lordheavym(a)gmail.com> 2012-01-02 10:34:36 PST --- Fixed the problem, it happened because of mismatch with included libstdc++ and system one (indirect rendering was in use). -- 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 0/3] drm/omap: updates for addfb2 and plane support
by Rob Clark 02 Jan '12

02 Jan '12

From: Rob Clark <rob(a)ti.com> The first patch updates omapdrm for API changes introduced when addfb2 support (for multi-planar fb's) was added (in drm-next). The next patch adds drm plane (overlay) support, with CRTCs using private plane objects to avoid code duplication between the CRTC and plane. (This depends on the "drm: add support for private planes" patch.) The final patch adds support for YUV and multi-planar YUV formats. This updated patch set rebases on drm-next as of today, and removes an internal helper function in favor of the new drm_format_num_planes() helper. These patches replace the last patchset sent on 15 Dec 2011. Rob Clark (3): drm/omap: drm API update: addfb2 drm/omap: add drm_plane support drm/omap: multiplanar and YUV support drivers/staging/omapdrm/Makefile | 1 + drivers/staging/omapdrm/omap_crtc.c | 191 +++++--------------- drivers/staging/omapdrm/omap_drv.c | 53 ++++-- drivers/staging/omapdrm/omap_drv.h | 46 ++++- drivers/staging/omapdrm/omap_fb.c | 224 +++++++++++++++++------ drivers/staging/omapdrm/omap_fbdev.c | 55 ++++-- drivers/staging/omapdrm/omap_gem.c | 5 + drivers/staging/omapdrm/omap_plane.c | 329 ++++++++++++++++++++++++++++++++++ drivers/staging/omapdrm/omap_priv.h | 12 +- 9 files changed, 665 insertions(+), 251 deletions(-) create mode 100644 drivers/staging/omapdrm/omap_plane.c -- 1.7.5.4

3 7

[PATCH 1/3] drm/omap: add ywrap module param
by Rob Clark 01 Jan '12

01 Jan '12

From: Rob Clark <rob(a)ti.com> Can be set at boot or module load time to prevent YWRAP scrolling from being enabled. Signed-off-by: Rob Clark <rob(a)ti.com> --- drivers/staging/omapdrm/omap_fbdev.c | 15 ++++++++++----- 1 files changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/staging/omapdrm/omap_fbdev.c b/drivers/staging/omapdrm/omap_fbdev.c index d8962e8..093ae2f 100644 --- a/drivers/staging/omapdrm/omap_fbdev.c +++ b/drivers/staging/omapdrm/omap_fbdev.c @@ -22,6 +22,10 @@ #include "drm_crtc.h" #include "drm_fb_helper.h" +MODULE_PARM_DESC(ywrap, "Enable ywrap scrolling (omap44xx and later, default 'y')"); +static bool ywrap_enabled = true; +module_param_named(ywrap, ywrap_enabled, bool, 0644); + /* * fbdev funcs, to implement legacy fbdev interface on top of drm driver */ @@ -32,6 +36,7 @@ struct omap_fbdev { struct drm_fb_helper base; struct drm_framebuffer *fb; struct drm_gem_object *bo; + bool ywrap_enabled; }; static void omap_fbdev_flush(struct fb_info *fbi, int x, int y, int w, int h); @@ -75,14 +80,12 @@ static int omap_fbdev_pan_display(struct fb_var_screeninfo *var, { struct drm_fb_helper *helper = get_fb(fbi); struct omap_fbdev *fbdev = to_omap_fbdev(helper); - struct omap_drm_private *priv; int npages; if (!helper) goto fallback; - priv = helper->dev->dev_private; - if (!priv->has_dmm) + if (!fbdev->ywrap_enabled) goto fallback; /* DMM roll shifts in 4K pages: */ @@ -152,7 +155,8 @@ static int omap_fbdev_create(struct drm_fb_helper *helper, mode_cmd.width * ((mode_cmd.bpp + 7) / 8), mode_cmd.width, mode_cmd.bpp); - if (priv->has_dmm) { + fbdev->ywrap_enabled = priv->has_dmm && ywrap_enabled; + if (fbdev->ywrap_enabled) { /* need to align pitch to page size if using DMM scrolling */ mode_cmd.pitch = ALIGN(mode_cmd.pitch, PAGE_SIZE); } @@ -218,12 +222,13 @@ static int omap_fbdev_create(struct drm_fb_helper *helper, /* if we have DMM, then we can use it for scrolling by just * shuffling pages around in DMM rather than doing sw blit. */ - if (priv->has_dmm) { + if (fbdev->ywrap_enabled) { DRM_INFO("Enabling DMM ywrap scrolling\n"); fbi->flags |= FBINFO_HWACCEL_YWRAP | FBINFO_READS_FAST; fbi->fix.ywrapstep = 1; } + DBG("par=%p, %dx%d", fbi->par, fbi->var.xres, fbi->var.yres); DBG("allocated %dx%d fb", fbdev->fb->width, fbdev->fb->height); -- 1.7.5.4

3 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2012