dri-devel January 2012

dri-devel@lists.freedesktop.org

91 participants
570 discussions

[patch] drm/nouveau/dp: nouveau_dp_link_train() returns bool
by Dan Carpenter 15 Jan '12

15 Jan '12

The caller doesn't check the return value, but this function returns a bool so static checkers complain when we return a negative error code. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 9b93b70..dcffd13 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -573,7 +573,7 @@ nouveau_dp_link_train(struct drm_encoder *encoder, u32 datarate) dp.table = nouveau_dp_bios_data(dev, nv_encoder->dcb, &dp.entry); if (!dp.table) - return -EINVAL; + return false; dp.dcb = nv_encoder->dcb; dp.crtc = nv_crtc->index;

1 0

[patch] gma500: change logical negate to bitwise
by Dan Carpenter 15 Jan '12

15 Jan '12

Logical negate is always false here. This was found by Sparse: drivers/gpu/drm/gma500/psb_irq.c:407:17: warning: dubious: x & !y Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/drivers/gpu/drm/gma500/psb_irq.c b/drivers/gpu/drm/gma500/psb_irq.c index 7be802b..4ce680f 100644 --- a/drivers/gpu/drm/gma500/psb_irq.c +++ b/drivers/gpu/drm/gma500/psb_irq.c @@ -404,7 +404,7 @@ void psb_irq_turn_off_dpst(struct drm_device *dev) psb_disable_pipestat(dev_priv, 0, PIPE_DPST_EVENT_ENABLE); pwm_reg = PSB_RVDC32(PWM_CONTROL_LOGIC); - PSB_WVDC32(pwm_reg & !(PWM_PHASEIN_INT_ENABLE), + PSB_WVDC32(pwm_reg & ~PWM_PHASEIN_INT_ENABLE, PWM_CONTROL_LOGIC); pwm_reg = PSB_RVDC32(PWM_CONTROL_LOGIC);

1 0

[PATCH] gpu, drm, sis: Don't return uninitialized variable from sis_driver_load()
by Jesper Juhl 15 Jan '12

15 Jan '12

In sis_driver_load(), the only use of 'ret' is as the return value from the function, unfortunately it is never initialized, so the function just returns garbage when it succeeds. To fix that, remove the variable and just return 0 directly on success. Signed-off-by: Jesper Juhl <jj(a)chaosbits.net> --- drivers/gpu/drm/sis/sis_drv.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) I don't have hardware to test, so it has only been compile tested. diff --git a/drivers/gpu/drm/sis/sis_drv.c b/drivers/gpu/drm/sis/sis_drv.c index 06da063..573220c 100644 --- a/drivers/gpu/drm/sis/sis_drv.c +++ b/drivers/gpu/drm/sis/sis_drv.c @@ -40,7 +40,6 @@ static struct pci_device_id pciidlist[] = { static int sis_driver_load(struct drm_device *dev, unsigned long chipset) { drm_sis_private_t *dev_priv; - int ret; dev_priv = kzalloc(sizeof(drm_sis_private_t), GFP_KERNEL); if (dev_priv == NULL) @@ -50,7 +49,7 @@ static int sis_driver_load(struct drm_device *dev, unsigned long chipset) dev_priv->chipset = chipset; idr_init(&dev->object_name_idr); - return ret; + return 0; } static int sis_driver_unload(struct drm_device *dev) -- 1.7.8.3 -- Jesper Juhl <jj(a)chaosbits.net> http://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please.

2 1

[Bug 44330] New: [i915g, bisected] Grass in Stellarium is not rendered correctly
by bugzilla-daemon＠freedesktop.org 14 Jan '12

14 Jan '12

https://bugs.freedesktop.org/show_bug.cgi?id=44330 Bug #: 44330 Summary: [i915g, bisected] Grass in Stellarium is not rendered correctly Classification: Unclassified Product: Mesa Version: git Platform: All OS/Version: All Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: pavel.ondracka(a)email.cz Created attachment 54986 --> https://bugs.freedesktop.org/attachment.cgi?id=54986 screenshot Grass in stellarium is supposed to change brightness according to the time of day. Some part of it is working however circle in the middle is bright all the time. b50d250e02457f367c195ee1808b061e0dfe2d00 is the first bad commit commit b50d250e02457f367c195ee1808b061e0dfe2d00 Author: Stéphane Marchesin <marcheu(a)chromium.org> Date: Thu Dec 22 18:17:54 2011 -0800 i915g: Only apply the optimization to output vars. This is a bit overkill, but otherwise we need to rename subsequent uses, which is a future TODO. Reported by CME. Stellarium 0.11.1 Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) OpenGL renderer string: Gallium 0.4 on i915 (chipset: 945G) OpenGL version string: 2.0 Mesa 7.12-devel (git-141d961) OpenGL shading language version string: 1.20 Kernel: 3.1.6-1.fc16.i686 Libdrm: 2.4.27-2.fc16 X.Org X Server 1.11.3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[PATCH] drm/i915: paper over missed irq issues with force wake voodoo
by Daniel Vetter 14 Jan '12

14 Jan '12

Two things seem to do the trick on my ivb machine here: - prevent the gt from powering down while waiting for seqno notification interrupts by grabbing the force_wake in get_irq (and dropping it in put_irq again). - ordering writes from the ring's CS by reading a CS register, ACTHD seems to work. Only the blt&bsd ring on ivb seem to be massively affected by this, but for paranoia do this dance also on the render ring and on snb (i.e. all gpus with forcewake). Tested with Eric's glCopyPixels loop which without this patch scores a missed irq every few seconds. This patch needs my forcewake rework to use a spinlock instead of dev->struct_mutex. After crawling through docs a lot I've found the following nugget: Internal doc "SNB GT PM Programming Guide", Section 4.3.1: "GT does not generate interrupts while in RC6 (by design)" So it looks like rc6 and irq generation are indeed related. v2: Improve the comment per Eugeni Dodonov's suggestion. v3: Add the documentation snipped. Also restrict the w/a to ivb only for -fixes, as suggested by Keith Packard. Cc: stable(a)kernel.org Cc: Eric Anholt <eric(a)anholt.net> Cc: Kenneth Graunke <kenneth(a)whitecape.org> Cc: Eugeni Dodonov <eugeni.dodonov(a)intel.com> Tested-by: Eugeni Dodonov <eugeni.dodonov(a)intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov(a)intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- drivers/gpu/drm/i915/intel_ringbuffer.c | 27 +++++++++++++++++++++++++-- 1 files changed, 25 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index cf6e159..b2d9583 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -631,6 +631,19 @@ render_ring_add_request(struct intel_ring_buffer *ring, } static u32 +gen6_ring_get_seqno(struct intel_ring_buffer *ring) +{ + struct drm_device *dev = ring->dev; + + /* Workaround to force correct ordering between irq and seqno writes on + * ivb (and maybe also on snb) by reading from a CS register (like + * ACTHD) before reading the status page. */ + if (IS_GEN7(dev)) + intel_ring_get_active_head(ring); + return intel_read_status_page(ring, I915_GEM_HWS_INDEX); +} + +static u32 ring_get_seqno(struct intel_ring_buffer *ring) { return intel_read_status_page(ring, I915_GEM_HWS_INDEX); @@ -795,6 +808,12 @@ gen6_ring_get_irq(struct intel_ring_buffer *ring, u32 gflag, u32 rflag) if (!dev->irq_enabled) return false; + /* It looks like we need to prevent the gt from suspending while waiting + * for an notifiy irq, otherwise irqs seem to get lost on at least the + * blt/bsd rings on ivb. */ + if (IS_GEN7(dev)) + gen6_gt_force_wake_get(dev_priv); + spin_lock(&ring->irq_lock); if (ring->irq_refcount++ == 0) { ring->irq_mask &= ~rflag; @@ -819,6 +838,9 @@ gen6_ring_put_irq(struct intel_ring_buffer *ring, u32 gflag, u32 rflag) ironlake_disable_irq(dev_priv, gflag); } spin_unlock(&ring->irq_lock); + + if (IS_GEN7(dev)) + gen6_gt_force_wake_put(dev_priv); } static bool @@ -1329,7 +1351,7 @@ static const struct intel_ring_buffer gen6_bsd_ring = { .write_tail = gen6_bsd_ring_write_tail, .flush = gen6_ring_flush, .add_request = gen6_add_request, - .get_seqno = ring_get_seqno, + .get_seqno = gen6_ring_get_seqno, .irq_get = gen6_bsd_ring_get_irq, .irq_put = gen6_bsd_ring_put_irq, .dispatch_execbuffer = gen6_ring_dispatch_execbuffer, @@ -1388,7 +1410,7 @@ static const struct intel_ring_buffer gen6_blt_ring = { .write_tail = ring_write_tail, .flush = blt_ring_flush, .add_request = gen6_add_request, - .get_seqno = ring_get_seqno, + .get_seqno = gen6_ring_get_seqno, .irq_get = blt_ring_get_irq, .irq_put = blt_ring_put_irq, .dispatch_execbuffer = gen6_ring_dispatch_execbuffer, @@ -1410,6 +1432,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev) ring->flush = gen6_render_ring_flush; ring->irq_get = gen6_render_ring_get_irq; ring->irq_put = gen6_render_ring_put_irq; + ring->get_seqno = gen6_ring_get_seqno; } else if (IS_GEN5(dev)) { ring->add_request = pc_render_add_request; ring->get_seqno = pc_render_get_seqno; -- 1.7.8.2

1 0

render error beginning with kernel 2.6.38
by russellbell＠gmail.com 13 Jan '12

13 Jan '12

Beginning with kernel version 2.6.38 (and not 2.6.37.5), continuing to 3.1.8, at boot I get: kernel: render error detected, EIR: 0x00000010 kernel: IPEIR: 0x00000000 kernel: IPEHR: 0x00000000 kernel: INSTDONE: 0xfffffffe kernel: INSTPS: 0x00000000 kernel: INSTDONE1: 0xffffffff kernel: ACTHD: 0x00000000 kernel: page table error kernel: PGTBL_ER: 0x00000001 kernel: [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking It happened with no previous kernels (and still doesn't). As near as I can tell this causes no problem. I'd like to know what it means. I've diffed all the files in drivers/gpu/drm/i915 between versions 2.6.37.5 and 2.6.38. If no one knows what this is about I would appreciate information about how to narrow down what causes it. For instance, is it unlikely to be in the gem stuff? The gem stuff is a large portion of the difference.

1 0

[Bug 44757] New: one wrong triangle on the balls in foobillard
by bugzilla-daemon＠freedesktop.org 13 Jan '12

13 Jan '12

https://bugs.freedesktop.org/show_bug.cgi?id=44757 Bug #: 44757 Summary: one wrong triangle on the balls in foobillard Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: aaalmosss(a)gmail.com The balls are rendered in two passes: the first one with the base image, and the second one with a spheremap (the "shininess"). The second pass is wrong for one triangle, it is too bright. It's always the same one, but the balls have random rotation initially. I checked it with apitrace, and after the first pass the framebuffer looks good, but not after the second pass (glCallList(21) draws the ball). It is not the same as bug 3267, because the spheremap is applied, but incorrectly. There is a distance-based LOD of the balls, and not all detail levels have this problem, just detail=4 and detail=7. You can set this somewhere around the line "if( detail<0 ) detail=0;" ball.c. The problem is reproducible on r300g, r600g, llvmpipe, but not on nvidia blob. I couldn't find any obvious error in the application's code, but I'm not very experienced in OpenGL. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[Bug 22576] [KMS] mesa demo spectex broken on rv280
by bugzilla-daemon＠freedesktop.org 13 Jan '12

13 Jan '12

https://bugs.freedesktop.org/show_bug.cgi?id=22576 --- Comment #17 from smoki <smoki00790(a)gmail.com> 2012-01-13 06:01:06 PST --- Bug is here with kernel 3.1.8, xserver 1.10.4 and git from whole stack. Load UMS and mesa 7.5.2 to fix lighting, reboot into KMS with current mesa and lighting is fixed... until power off:(. -- 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] WARNING: at drivers/gpu/drm/i915/intel_display.c:901 assert_panel_unlocked
by Tom Gundersen 13 Jan '12

13 Jan '12

Hi guys, I have been experiencing problems with suspend/resume on my ThinkPad x60 for some time (sorry for being vague, I forget when it started). With 3.1 it seems to behave much better (no crashes). The problems I'm still seeing is that sometimes the computer does not suspend when closing the lid, but manually using "pm-suspend" always works. Opening the lid again after a failed suspend causes it to flicker briefly and then continue working as before. I receive the following warning in dmesg (after both successful and unsuccessful suspends): [24395.487631] ------------[ cut here ]------------ [24395.487659] WARNING: at drivers/gpu/drm/i915/intel_display.c:901 assert_panel_unlocked.isra.22+0x242/0x280 [i915]() [24395.487664] Hardware name: 1706GMG [24395.487667] panel assertion failure, pipe B regs locked [24395.487671] Modules linked in: ext2 msr cpufreq_stats ext4 mbcache jbd2 microcode sbs sbshc max6650 coretemp kvm_intel kvm acpi_cpufreq freq_table mperf i915 drm_kms_helper cryptd drm aes_x86_64 iTCO_wdt aes_generic ecb iTCO_vendor_support btusb bluetooth crc16 mmc_block e1000e thinkpad_acpi uhci_hcd firewire_ohci firewire_core intel_agp pata_acpi i2c_algo_bit arc4 sdhci_pci sdhci snd_hda_codec_analog ata_generic intel_gtt snd_hda_intel snd_hda_codec iwl3945 iwl_legacy i2c_i801 snd_hwdep snd_pcm ehci_hcd snd_timer mac80211 snd psmouse mmc_core i2c_core processor video nvram ata_piix usbcore thermal ac button battery evdev soundcore cfg80211 snd_page_alloc serio_raw crc_itu_t rfkill autofs4 btrfs zlib_deflate crc32c libcrc32c sd_mod ahci libahci libata scsi_mod [24395.487772] Pid: 7975, comm: kworker/u:5 Tainted: G W 3.1.1-1-ARCH #1 [24395.487777] Call Trace: [24395.487791] [<ffffffff81061b9f>] warn_slowpath_common+0x7f/0xc0 [24395.487798] [<ffffffff81061c96>] warn_slowpath_fmt+0x46/0x50 [24395.487814] [<ffffffffa0563d42>] assert_panel_unlocked.isra.22+0x242/0x280 [i915] [24395.487830] [<ffffffffa056d686>] i9xx_crtc_enable+0xa6/0x4c0 [i915] [24395.487838] [<ffffffff8122f754>] ? snprintf+0x34/0x40 [24395.487852] [<ffffffffa056daae>] i9xx_crtc_commit+0xe/0x10 [i915] [24395.487861] [<ffffffffa0394019>] drm_crtc_helper_set_mode+0x3b9/0x4f0 [drm_kms_helper] [24395.487873] [<ffffffffa03941c3>] drm_helper_resume_force_mode+0x73/0x160 [drm_kms_helper] [24395.487887] [<ffffffffa040dc73>] ? drm_irq_install+0x153/0x260 [drm] [24395.487899] [<ffffffffa051b1aa>] i915_drm_thaw+0xca/0x110 [i915] [24395.487909] [<ffffffffa051b4ee>] i915_resume+0x4e/0x80 [i915] [24395.487927] [<ffffffffa051b536>] i915_pm_resume+0x16/0x20 [i915] [24395.487931] [<ffffffff8124da76>] pci_pm_resume+0x76/0xd0 [24395.487936] [<ffffffff812f7717>] pm_op+0xe7/0x1c0 [24395.487939] [<ffffffff812f7baf>] device_resume+0x9f/0x140 [24395.487943] [<ffffffff8108cb20>] ? async_schedule+0x20/0x20 [24395.487946] [<ffffffff812f7c71>] async_resume+0x21/0x50 [24395.487949] [<ffffffff8108cb9f>] async_run_entry_fn+0x7f/0x180 [24395.487953] [<ffffffff8107eff6>] process_one_work+0x116/0x4d0 [24395.487956] [<ffffffff8107f98e>] worker_thread+0x15e/0x350 [24395.487959] [<ffffffff8107f830>] ? manage_workers.isra.29+0x230/0x230 [24395.487962] [<ffffffff8108462c>] kthread+0x8c/0xa0 [24395.487966] [<ffffffff8140c5b4>] kernel_thread_helper+0x4/0x10 [24395.487969] [<ffffffff810845a0>] ? kthread_worker_fn+0x190/0x190 [24395.487972] [<ffffffff8140c5b0>] ? gs_change+0x13/0x13 [24395.487974] ---[ end trace 1d476bd6e1af4e33 ]--- The kernel is mostly unpatched, but the few patches it has (as well as its .config) can be found here: <http://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/l…>. Please let me know if you require more information. Thanks for your time, Tom

3 2

[git pull] some fixes for -rc1
by Dave Airlie 13 Jan '12

13 Jan '12

Hi Linus, misc fixes for -rc1, fix the dma-buf Kconfig, two nouveau fixes I've tested locally on optimus laptop and they seem to fix the problem off turning the GPU off properly when asked. I've booted this specifc tree only as far as the autofs hang I've mentioned, but the gpu driver comes up fine, and there is nothing really scary in this lot. Dave. The following changes since commit 099469502f62fbe0d7e4f0b83a2f22538367f734: Merge branch 'akpm' (aka "Andrew's patch-bomb, take two") (2012-01-12 20:42:54 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes Alan Cox (1): gma500: Discard modes that don't fit in stolen memory Alex Deucher (1): drm/radeon/kms/ni: fix packet2 handling for VM IB parser Ben Skeggs (1): drm: bump DRM_CONNECTOR_MAX_ENCODER from 2 to 3 Dave Airlie (1): dma-buf: drop option text so users don't select it. Jean Delvare (1): drm/radeon/kms: Fix module parameter description format Konrad Rzeszutek Wilk (1): ttm/dma: Remove the WARN() which is not useful. Michel Dänzer (1): radeon: Call pci_clear_master() instead of open-coding it. Peter Lekensteyn (2): nouveau: properly check for _DSM function support nouveau: Support Optimus models for vga_switcheroo Sumit Semwal (1): dma-buf: Documentation update for Kconfig select Documentation/dma-buf-sharing.txt | 4 ++ drivers/base/Kconfig | 2 +- drivers/gpu/drm/gma500/cdv_intel_crt.c | 6 ++ drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 14 ++--- drivers/gpu/drm/gma500/oaktrail_hdmi.c | 6 ++ drivers/gpu/drm/gma500/psb_intel_sdvo.c | 6 ++ drivers/gpu/drm/nouveau/nouveau_acpi.c | 79 +++++++++++++++++++++++------- drivers/gpu/drm/nouveau/nouveau_drv.h | 2 + drivers/gpu/drm/nouveau/nouveau_state.c | 1 + drivers/gpu/drm/radeon/evergreen_cs.c | 3 +- drivers/gpu/drm/radeon/r100.c | 4 +- drivers/gpu/drm/radeon/radeon_drv.c | 2 +- drivers/gpu/drm/radeon/rs600.c | 13 +---- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 5 +- include/drm/drm_crtc.h | 2 +- 15 files changed, 102 insertions(+), 47 deletions(-)

1 0

← Newer
1
...
47
48
49
50
51
52
53
...
57
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2012