dri-devel December 2011

dri-devel@lists.freedesktop.org

83 participants
552 discussions

[Bug 43924] New: Test fails during compilation
by bugzilla-daemon＠freedesktop.org 18 Dec '11

18 Dec '11

https://bugs.freedesktop.org/show_bug.cgi?id=43924 Bug #: 43924 Summary: Test fails during compilation Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: libdrm AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: exalowprofile(a)gmail.com ======================================================================= 1 of 11 tests failed Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=DRI ======================================================================= make[3]: *** [check-TESTS] Error 1 make[3]: Leaving directory `/tmp/yaourt-tmp-mariachi/aur-libdrm-git/src/drm-build/tests' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/tmp/yaourt-tmp-mariachi/aur-libdrm-git/src/drm-build/tests' make[1]: *** [check-recursive] Error 1 make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/tmp/yaourt-tmp-mariachi/aur-libdrm-git/src/drm-build/tests' Making check in include make[1]: Entering directory `/tmp/yaourt-tmp-mariachi/aur-libdrm-git/src/drm-build/include' Making check in drm make[2]: Entering directory `/tmp/yaourt-tmp-mariachi/aur-libdrm-git/src/drm-build/include/drm' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/tmp/yaourt-tmp-mariachi/aur-libdrm-git/src/drm-build/include/drm' make[2]: Entering directory `/tmp/yaourt-tmp-mariachi/aur-libdrm-git/src/drm-build/include' make[2]: Nothing to be done for `check-am'. make[2]: Leaving directory `/tmp/yaourt-tmp-mariachi/aur-libdrm-git/src/drm-build/include' make[1]: Leaving directory `/tmp/yaourt-tmp-mariachi/aur-libdrm-git/src/drm-build/include' make: *** [check-recursive] Error 1 make: Target `check' not remade because of errors. I don't know how to read this, and it says to post a bug report so.. I'm using arch linux with latest kernel (64bit) and a core2. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 3

[PATCH] Revert "drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a"
by Keith Packard 16 Dec '11

16 Dec '11

This reverts commit eb1711bb94991e93669c5a1b5f84f11be2d51ea1. This patch has been reported by two people to cause memory corruption and application crashes. It exists solely to fix a problem with the VT-d workarounds for Ironlake. I would back those out as well as without this change, that work-around causes an infinite recursion for anyone foolish enough to actually try VT-d for graphics. So, without this patch, and when using VT-d for graphics on Ironlake, people will experience infinite recursion crashes. With this patch, we get memory corruption on all systems. Cc: dri-devel(a)lists.freedesktop.org Cc: Daniel Vetter <daniel(a)ffwll.ch> Reported-by: Alex Villacís Lasso <a_villacis(a)palosanto.com> Reported-by: Dirk Hohndel <dirk(a)hohndel.org> Signed-off-by: Keith Packard <keithp(a)keithp.com> --- drivers/gpu/drm/i915/i915_gem.c | 7 +------ 1 files changed, 1 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 60ff1b6..8359dc7 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2026,13 +2026,8 @@ i915_wait_request(struct intel_ring_buffer *ring, * to handle this, the waiter on a request often wants an associated * buffer to have made it to the inactive list, and we would need * a separate wait queue to handle that. - * - * To avoid a recursion with the ilk VT-d workaround (that calls - * gpu_idle when unbinding objects with interruptible==false) don't - * retire requests in that case (because it might call unbind if the - * active list holds the last reference to the object). */ - if (ret == 0 && dev_priv->mm.interruptible) + if (ret == 0) i915_gem_retire_requests_ring(ring); return ret; -- 1.7.7.3

1 0

Memory corruption starting in i915 code, in 3.2-rc5
by Alex Villacís Lasso 16 Dec '11

16 Dec '11

My system is a Fedora 16 x86_64 running self-compiled vanilla kernel (.config attached for -rc5). I am getting an apparent memory corruption that starts since linux 3.2-rc5. No such corruption was noticed in 3.2-rc4. On the first instance, I eventually got a NULL pointer dereference and the screen went black, the keyboard was unresponsive, and I had to hard-reboot the machine. On the second instance, I managed to reboot the machine normally. The full message log is attached. An extract of the first WARNING: Dec 11 00:38:47 karlalex kernel: [ 2016.175191] ------------[ cut here ]------------ Dec 11 00:38:47 karlalex kernel: [ 2016.175200] WARNING: at lib/list_debug.c:30 __list_add+0x66/0x7f() Dec 11 00:38:47 karlalex kernel: [ 2016.175202] Hardware name: OEM Dec 11 00:38:47 karlalex kernel: [ 2016.175204] list_add corruption. prev->next should be next (ffff8800799756c0), but was ffff88005d42dcb0. (prev=ffff88005b278eb0). Dec 11 00:38:47 karlalex kernel: [ 2016.175206] Modules linked in: tcp_lp fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat vboxpci(O) xt_CHECKSUM vboxnetadp(O) vboxnetflt(O) iptable_mangle tun bridge stp llc vboxdrv(O) lockd ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep ppdev snd_seq snd_seq_device snd_pcm snd_timer snd soundcore microcode snd_page_alloc pcspkr i2c_i801 iTCO_wdt iTCO_vendor_support r8169 mii uinput parport_pc parport floppy sunrpc i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] Dec 11 00:38:47 karlalex kernel: [ 2016.175254] Pid: 1868, comm: gnome-shell Tainted: G O 3.2.0-rc5 #18 Dec 11 00:38:47 karlalex kernel: [ 2016.175256] Call Trace: Dec 11 00:38:47 karlalex kernel: [ 2016.175263] [<ffffffff8105a3e8>] warn_slowpath_common+0x83/0x9b Dec 11 00:38:47 karlalex kernel: [ 2016.175266] [<ffffffff8105a4a3>] warn_slowpath_fmt+0x46/0x48 Dec 11 00:38:47 karlalex kernel: [ 2016.175270] [<ffffffff810502f2>] ? get_parent_ip+0xe/0x3e Dec 11 00:38:47 karlalex kernel: [ 2016.175273] [<ffffffff812418ef>] __list_add+0x66/0x7f Dec 11 00:38:47 karlalex kernel: [ 2016.175290] [<ffffffffa007560f>] list_move_tail+0x27/0x2c [i915] Dec 11 00:38:47 karlalex kernel: [ 2016.175301] [<ffffffffa00757cb>] i915_gem_retire_requests_ring+0xef/0x177 [i915] Dec 11 00:38:47 karlalex kernel: [ 2016.175312] [<ffffffffa0076cbc>] i915_wait_request+0x401/0x447 [i915] Dec 11 00:38:47 karlalex kernel: [ 2016.175316] [<ffffffff810502f2>] ? get_parent_ip+0xe/0x3e Dec 11 00:38:47 karlalex kernel: [ 2016.175318] [<ffffffff810502f2>] ? get_parent_ip+0xe/0x3e Dec 11 00:38:47 karlalex kernel: [ 2016.175321] [<ffffffff810502f2>] ? get_parent_ip+0xe/0x3e Dec 11 00:38:47 karlalex kernel: [ 2016.175333] [<ffffffffa0076d33>] i915_gem_object_wait_rendering+0x31/0x33 [i915] Dec 11 00:38:47 karlalex kernel: [ 2016.175344] [<ffffffffa0077db2>] i915_gem_object_set_to_gtt_domain+0x53/0xd6 [i915] Dec 11 00:38:47 karlalex kernel: [ 2016.175355] [<ffffffffa0077ec8>] i915_gem_set_domain_ioctl+0x93/0xcb [i915] Dec 11 00:38:47 karlalex kernel: [ 2016.175368] [<ffffffffa001d78a>] drm_ioctl+0x2bf/0x397 [drm] Dec 11 00:38:47 karlalex kernel: [ 2016.175371] [<ffffffff811ee50b>] ? avc_has_perm_flags+0x61/0x7a Dec 11 00:38:47 karlalex kernel: [ 2016.175383] [<ffffffffa0077e35>] ? i915_gem_object_set_to_gtt_domain+0xd6/0xd6 [i915] Dec 11 00:38:47 karlalex kernel: [ 2016.175386] [<ffffffff811ef0a5>] ? inode_has_perm+0x32/0x34 Dec 11 00:38:47 karlalex kernel: [ 2016.175389] [<ffffffff811ef14e>] ? file_has_perm+0xa7/0xc9 Dec 11 00:38:47 karlalex kernel: [ 2016.175394] [<ffffffff8113f1bb>] do_vfs_ioctl+0x415/0x456 Dec 11 00:38:47 karlalex kernel: [ 2016.175397] [<ffffffff8113f252>] sys_ioctl+0x56/0x7c Dec 11 00:38:47 karlalex kernel: [ 2016.175402] [<ffffffff814deb02>] system_call_fastpath+0x16/0x1b Dec 11 00:38:47 karlalex kernel: [ 2016.175404] ---[ end trace 9a493f8550a2caf6 ]--- Dec 11 00:38:47 karlalex kernel: [ 2016.428775] ------------[ cut here ]------------ Both times, I had just turned on the machine and booted with -rc5. The first time, I rebooted into the stock kernel, then into -rc5 again, and I did not get any corruption. It seems that having just turned on the machine (as opposed to hard/soft rebooting) has something to do with this, but I could be wrong. Output of lspci -v is attached. Virtualbox module is compiled and loaded, but never used in either case. This module is also loaded in -rc4 and caused no problems for me.

5 10

[PULL] drm-intel-fixes (drm/i915 driver)
by Keith Packard 16 Dec '11

16 Dec '11

A few regression fixes: * eDP panels with too few lanes need 6bpc modes * older machine backlights going black * divide-by-zero crash when reading a /sys file Quirks for a couple of machines: * No lvds panel on a desktop ASUS machine * Light up the second LVDS on the Libretto W105 Two more Ivybridge changes: * Use Multi-threaded force-wake where enabled by the BIOS * Light up eDP panels Finally, this enables RC6 and semaphores, unconditionally on Ivybridge. On Sandybridge, these are enabled when VTd isn't in use. We've been wanting to do this for a long time, and instead of turning this on for RC1 and hoping things worked out, we spent time working directly with people who reported problems and discovered that RC6 and Semaphores cannot be enabled when VTd is in use (even VTd for non-gfx devices). There's a patch here which exports a value from the iommu code letting us know when VTd is active so that RC6 and semaphores can be disabled. That patch has been ok'd by David Woodhouse, although he's not very happy about it. Matthew Garrett wanted to write a second patch that disabled VTd by default on SNB machines, which would enable RC6 and semaphores more often. The following changes since commit f10cdea68b70bd85706baed0decab59618f9c353: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest (2011-11-23 09:50:42 -0800) are available in the git repository at: git://people.freedesktop.org/~keithp/linux drm-intel-fixes Adam Jackson (2): drm/i915: no-lvds quirk for ASUS AT5NM10T-I drm/i915/dp: Dither down to 6bpc if it makes the mode fit Chris Wilson (1): drm/i915/sdvo: Include LVDS panels for the IS_DIGITAL check Eugeni Dodonov (3): drm/i915: prevent division by zero when asking for chipset power iommu: Export intel_iommu_enabled to signal when iommu is in use drm/i915: enable semaphores on per-device defaults Jesse Barnes (1): drm/i915: don't set unpin_work if vblank_get fails Keith Packard (4): drm/i915: add multi-threaded forcewake support drm/i915: Hook up Ivybridge eDP drm/i915: Treat pre-gen4 backlight duty cycle value consistently drm/i915: By default, enable RC6 on IVB and SNB when reasonable Paulo Zanoni (2): drm/i915: set the right SDVO transcoder for CPT drm/i915: add PCH info to i915_capabilities drivers/gpu/drm/i915/i915_debugfs.c | 1 + drivers/gpu/drm/i915/i915_dma.c | 10 ++ drivers/gpu/drm/i915/i915_drv.c | 43 ++++++-- drivers/gpu/drm/i915/i915_drv.h | 18 +++- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 19 +++- drivers/gpu/drm/i915/i915_reg.h | 30 ++++- drivers/gpu/drm/i915/intel_display.c | 89 +++++++++++++-- drivers/gpu/drm/i915/intel_dp.c | 173 +++++++++++++++++++++------- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_lvds.c | 8 ++ drivers/gpu/drm/i915/intel_panel.c | 16 +-- drivers/gpu/drm/i915/intel_sdvo.c | 36 ++++-- drivers/iommu/intel-iommu.c | 5 + include/linux/dma_remapping.h | 2 + 14 files changed, 361 insertions(+), 90 deletions(-) -- keith.packard(a)intel.com

1 0

Re: [mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.
by chenhc＠lemote.com 16 Dec '11

16 Dec '11

> On Don, 2011-12-08 at 19:35 +0800, chenhc(a)lemote.com wrote: >> >> I found CP_RB_WPTR has changed when "ring test failed", so I think CP is >> active, but what it get from ring buffer is wrong. > > CP_RB_WPTR is normally only changed by the CPU after adding commands to > the ring buffer, so I'm afraid that may not be a valid conclusion. > > I'm sorry, I've made a spelling mistake. In fact, CP_RB_RPTR and CP_RB_WPTR both changed, so I think CP is active. >> Then, I want to know whether there is a way to check the content that >> GPU get from ring buffer. > > See the r100_debugfs_cp_csq_fifo() function, which generates the output > for /sys/kernel/debug/dri/0/r100_cp_csq_fifo. > Hmmm, I don't think this function can be used by r600 (or write a similar one for R600), because I haven't found CSQ registers in r600 code. > >> BTW, when I use "echo shutdown > /sys/power/disk; echo disk > >> /sys/power/state" to do a hibernation, there will be occasionally "GPU >> reset" just like suspend. However, if I use "echo reboot > >> /sys/power/disk; echo disk > /sys/power/state" to do a hibernation and >> wakeup automatically, there is no "GPU reset" after hundreds of tests. >> What does this imply? Power loss cause something break? > > Yeah, it sounds like the resume code doesn't properly re-initialize > something that's preserved on a warm boot but lost on a cold boot. > > > -- > Earthling Michel D

3 2

[Bug 42808] New: Xserver fails to start with NI Seymour XT
by bugzilla-daemon＠freedesktop.org 16 Dec '11

16 Dec '11

https://bugs.freedesktop.org/show_bug.cgi?id=42808 Bug #: 42808 Summary: Xserver fails to start with NI Seymour XT Classification: Unclassified Product: Mesa Version: unspecified Platform: x86 (IA32) OS/Version: All Status: NEW Severity: critical Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: hysvats(a)gmail.com Created attachment 53392 --> https://bugs.freedesktop.org/attachment.cgi?id=53392 Xorg.log Driver Stack Details: ========================= 1) Kernel- 3.0.0-12-generice-pae 2) Libdrm-2.4.27 3) Mesa-master 4) Xorg-server-1.10.0 5) xf86-video-ati-master System Environment: =================== NoteBook - Dell Inspiron with Seymour XT(6760) O.S. - Ubuntu-11.10 (32 bit) CPU - Intel Sandy Bridge @ 2.2GHz Steps to Reproduce: =================== starx fails with : (EE) No devices detected -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 8

[PATCH] drm/nouveau: Use vsprintf extension %pV
by Joe Perches 16 Dec '11

16 Dec '11

Using %pV can save text. Replace NV_PRINTK macro with nv_printk and use of vsprintf extension %pV. Convert the NV_<LEVEL> macros to use nv_printk and neaten them too. Saves ~45KB or ~5% of total code space for nouveau. $ size drivers/gpu/drm/nouveau/built-in.o* text data bss dec hex filename 781185 25499 176860 983544 f01f8 drivers/gpu/drm/nouveau/built-in.o.new 820650 25499 184356 1030505 fb969 drivers/gpu/drm/nouveau/built-in.o.old Signed-off-by: Joe Perches <joe(a)perches.com> --- Modified resend of https://lkml.org/lkml/2011/6/28/505 drivers/gpu/drm/nouveau/nouveau_dp.c | 9 ++-- drivers/gpu/drm/nouveau/nouveau_drv.c | 20 ++++++++++ drivers/gpu/drm/nouveau/nouveau_drv.h | 67 +++++++++++++++++++------------- 3 files changed, 65 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index de5efe7..087ede3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -33,10 +33,11 @@ /****************************************************************************** * aux channel util functions *****************************************************************************/ -#define AUX_DBG(fmt, args...) do { \ - if (nouveau_reg_debug & NOUVEAU_REG_DEBUG_AUXCH) { \ - NV_PRINTK(KERN_DEBUG, dev, "AUXCH(%d): " fmt, ch, ##args); \ - } \ +#define AUX_DBG(fmt, ...) \ +do { \ + if (nouveau_reg_debug & NOUVEAU_REG_DEBUG_AUXCH) \ + nv_printk(dev, KERN_DEBUG, "AUXCH(%d): " fmt, \ + ch, ##__VA_ARGS__); \ } while (0) #define AUX_ERR(fmt, args...) NV_ERROR(dev, "AUXCH(%d): " fmt, ch, ##args) diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c b/drivers/gpu/drm/nouveau/nouveau_drv.c index f0a60af..0eed2a9 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.c +++ b/drivers/gpu/drm/nouveau/nouveau_drv.c @@ -494,3 +494,23 @@ module_exit(nouveau_exit); MODULE_AUTHOR(DRIVER_AUTHOR); MODULE_DESCRIPTION(DRIVER_DESC); MODULE_LICENSE("GPL and additional rights"); + +int nv_printk(const struct drm_device *drm_dev, + const char *level, const char *format, ...) +{ + struct va_format vaf; + va_list args; + int r; + + va_start(args, format); + + vaf.fmt = format; + vaf.va = &args; + + r = printk("%s[" DRM_NAME "] " DRIVER_NAME " %s: %pV", + level, pci_name(drm_dev->pdev), &vaf); + + va_end(args); + + return r; +} diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h index dfddb7e..80f49d4 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.h +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h @@ -1537,37 +1537,48 @@ extern void nv_wo32(struct nouveau_gpuobj *, u32 offset, u32 val); * Logging * Argument d is (struct drm_device *). */ -#define NV_PRINTK(level, d, fmt, arg...) \ - printk(level "[" DRM_NAME "] " DRIVER_NAME " %s: " fmt, \ - pci_name(d->pdev), ##arg) + +extern __attribute__ ((format (printf, 3, 4))) +int nv_printk(const struct drm_device *drm_dev, + const char *level, const char *format, ...); + #ifndef NV_DEBUG_NOTRACE -#define NV_DEBUG(d, fmt, arg...) do { \ - if (drm_debug & DRM_UT_DRIVER) { \ - NV_PRINTK(KERN_DEBUG, d, "%s:%d - " fmt, __func__, \ - __LINE__, ##arg); \ - } \ +#define NV_DEBUG(d, fmt, ...) \ +do { \ + if (drm_debug & DRM_UT_DRIVER) { \ + nv_printk(d, KERN_DEBUG, "%s:%d - " fmt, \ + __func__, __LINE__, ##__VA_ARGS__); \ + } \ } while (0) -#define NV_DEBUG_KMS(d, fmt, arg...) do { \ - if (drm_debug & DRM_UT_KMS) { \ - NV_PRINTK(KERN_DEBUG, d, "%s:%d - " fmt, __func__, \ - __LINE__, ##arg); \ - } \ +#define NV_DEBUG_KMS(d, fmt, ...) \ +do { \ + if (drm_debug & DRM_UT_KMS) { \ + nv_printk(d, KERN_DEBUG, "%s:%d - " fmt, \ + __func__, __LINE__, ##__VA_ARGS__); \ + } \ } while (0) #else -#define NV_DEBUG(d, fmt, arg...) do { \ - if (drm_debug & DRM_UT_DRIVER) \ - NV_PRINTK(KERN_DEBUG, d, fmt, ##arg); \ +#define NV_DEBUG(d, fmt, ...) \ +do { \ + if (drm_debug & DRM_UT_DRIVER) \ + nv_printk(d, KERN_DEBUG, fmt, ##__VA_ARGS__); \ } while (0) -#define NV_DEBUG_KMS(d, fmt, arg...) do { \ - if (drm_debug & DRM_UT_KMS) \ - NV_PRINTK(KERN_DEBUG, d, fmt, ##arg); \ +#define NV_DEBUG_KMS(d, fmt, ...) \ +do { \ + if (drm_debug & DRM_UT_KMS) \ + nv_printk(d, KERN_DEBUG, fmt, ##__VA_ARGS__); \ } while (0) #endif -#define NV_ERROR(d, fmt, arg...) NV_PRINTK(KERN_ERR, d, fmt, ##arg) -#define NV_INFO(d, fmt, arg...) NV_PRINTK(KERN_INFO, d, fmt, ##arg) -#define NV_TRACEWARN(d, fmt, arg...) NV_PRINTK(KERN_NOTICE, d, fmt, ##arg) -#define NV_TRACE(d, fmt, arg...) NV_PRINTK(KERN_INFO, d, fmt, ##arg) -#define NV_WARN(d, fmt, arg...) NV_PRINTK(KERN_WARNING, d, fmt, ##arg) +#define NV_ERROR(d, fmt, ...) \ + nv_printk(d, KERN_ERR, fmt, ##__VA_ARGS__) +#define NV_INFO(d, fmt, ...) \ + nv_printk(d, KERN_INFO, fmt, ##__VA_ARGS__) +#define NV_TRACEWARN(d, fmt, ...) \ + nv_printk(d, KERN_NOTICE, fmt, ##__VA_ARGS__) +#define NV_TRACE(d, fmt, ...) \ + nv_printk(d, KERN_INFO, fmt, ##__VA_ARGS__) +#define NV_WARN(d, fmt, ...) \ + nv_printk(d, KERN_WARNING, fmt, ##__VA_ARGS__) /* nouveau_reg_debug bitmask */ enum { @@ -1584,9 +1595,11 @@ enum { NOUVEAU_REG_DEBUG_AUXCH = 0x400 }; -#define NV_REG_DEBUG(type, dev, fmt, arg...) do { \ - if (nouveau_reg_debug & NOUVEAU_REG_DEBUG_##type) \ - NV_PRINTK(KERN_DEBUG, dev, "%s: " fmt, __func__, ##arg); \ +#define NV_REG_DEBUG(type, dev, fmt, ...) \ +do { \ + if (nouveau_reg_debug & NOUVEAU_REG_DEBUG_##type) \ + nv_printk(dev, KERN_DEBUG, "%s: " fmt, \ + __func__, ##__VA_ARGS__); \ } while (0) static inline bool -- 1.7.8.111.gad25c.dirty

1 0

[PATCH] drm: call connector dpms fxn, when setting config
by Rob Clark 15 Dec '11

15 Dec '11

From: Rob Clark <rob(a)ti.com> Call connector->funcs->dpms(DPMS_ON) rather than just setting connector->dpms = DPMS_ON. This ensures that if the connector has something to do to enable the output (rather than just using drm_helper_connector_dpms helper directly), that this happens at bootup. This solves an issue with connectors not getting enabled from fbcon_init() when the driver is loaded. Signed-off-by: Rob Clark <rob(a)ti.com> --- drivers/gpu/drm/drm_crtc_helper.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index d2619d7..2f1ec7c 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -710,7 +710,7 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set) for (i = 0; i < set->num_connectors; i++) { DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS on\n", set->connectors[i]->base.id, drm_get_connector_name(set->connectors[i])); - set->connectors[i]->dpms = DRM_MODE_DPMS_ON; + set->connectors[i]->funcs->dpms(set->connectors[i], DRM_MODE_DPMS_ON); } } drm_helper_disable_unused_functions(dev); -- 1.7.5.4

2 1

[PATCH] drm/omap: fix for connectors not enabled at bootup
by Rob Clark 15 Dec '11

15 Dec '11

From: Rob Clark <rob(a)ti.com> The connector's dpms fxn is only triggered by userspace. When the driver is loaded and detected displays configured, drm core only calls the crtc and encoder's dpms functions. Signed-off-by: Rob Clark <rob(a)ti.com> --- Arguably, this could be called a work-around, and instead drm core should call connector's dpms functions and rely on drm_helper_connector_dpms to call encoder and crtc dpms functions. If people think it is better to fix this in drm core, and don't mind me making that change, then I will do that instead. drivers/staging/omapdrm/omap_connector.c | 15 ++------------- drivers/staging/omapdrm/omap_drv.h | 1 + drivers/staging/omapdrm/omap_encoder.c | 16 ++++++++++++++++ 3 files changed, 19 insertions(+), 13 deletions(-) diff --git a/drivers/staging/omapdrm/omap_connector.c b/drivers/staging/omapdrm/omap_connector.c index 6177f30..1c1db90 100644 --- a/drivers/staging/omapdrm/omap_connector.c +++ b/drivers/staging/omapdrm/omap_connector.c @@ -74,20 +74,13 @@ static inline void copy_timings_drm_to_omap(struct omap_video_timings *timings, timings->vbp = mode->vtotal - mode->vsync_end; } -static void omap_connector_dpms(struct drm_connector *connector, int mode) +void omap_connector_dpms(struct drm_connector *connector, int mode) { struct omap_connector *omap_connector = to_omap_connector(connector); struct omap_dss_device *dssdev = omap_connector->dssdev; - int old_dpms; DBG("%s: %d", dssdev->name, mode); - old_dpms = connector->dpms; - - /* from off to on, do from crtc to connector */ - if (mode < old_dpms) - drm_helper_connector_dpms(connector, mode); - if (mode == DRM_MODE_DPMS_ON) { /* store resume info for suspended displays */ switch (dssdev->state) { @@ -109,10 +102,6 @@ static void omap_connector_dpms(struct drm_connector *connector, int mode) } else { /* TODO */ } - - /* from on to off, do from connector to crtc */ - if (mode > old_dpms) - drm_helper_connector_dpms(connector, mode); } enum drm_connector_status omap_connector_detect( @@ -378,7 +367,7 @@ struct drm_encoder *omap_connector_attached_encoder( } static const struct drm_connector_funcs omap_connector_funcs = { - .dpms = omap_connector_dpms, + .dpms = drm_helper_connector_dpms, .detect = omap_connector_detect, .fill_modes = drm_helper_probe_single_connector_modes, .destroy = omap_connector_destroy, diff --git a/drivers/staging/omapdrm/omap_drv.h b/drivers/staging/omapdrm/omap_drv.h index 263057a..8dd7d74 100644 --- a/drivers/staging/omapdrm/omap_drv.h +++ b/drivers/staging/omapdrm/omap_drv.h @@ -73,6 +73,7 @@ void omap_connector_mode_set(struct drm_connector *connector, struct drm_display_mode *mode); void omap_connector_flush(struct drm_connector *connector, int x, int y, int w, int h); +void omap_connector_dpms(struct drm_connector *connector, int mode); struct drm_framebuffer *omap_framebuffer_create(struct drm_device *dev, struct drm_file *file, struct drm_mode_fb_cmd *mode_cmd); diff --git a/drivers/staging/omapdrm/omap_encoder.c b/drivers/staging/omapdrm/omap_encoder.c index 06c52cb..af39dc3 100644 --- a/drivers/staging/omapdrm/omap_encoder.c +++ b/drivers/staging/omapdrm/omap_encoder.c @@ -44,7 +44,23 @@ static void omap_encoder_destroy(struct drm_encoder *encoder) static void omap_encoder_dpms(struct drm_encoder *encoder, int mode) { struct omap_encoder *omap_encoder = to_omap_encoder(encoder); + struct drm_device *dev = encoder->dev; + struct omap_drm_private *priv = dev->dev_private; + int i; + DBG("%s: %d", omap_encoder->mgr->name, mode); + + /* Note: the connector DPMS fxn is only called from userspace + * ioctl, and not at bootup. But the encoder dpms function is. + * Ensure that our connector gets notified of the DPMS state + * change: + */ + for (i = 0; i < priv->num_connectors; i++) { + struct drm_connector *connector = priv->connectors[i]; + if (connector->encoder == encoder) { + omap_connector_dpms(connector, mode); + } + } } static bool omap_encoder_mode_fixup(struct drm_encoder *encoder, -- 1.7.5.4

2 2

Re: [mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.
by chenhc＠lemote.com 15 Dec '11

15 Dec '11

Thank you for your reply. I found CP_RB_WPTR has changed when "ring test failed", so I think CP is active, but what it get from ring buffer is wrong. Then, I want to know whether there is a way to check the content that GPU get from ring buffer. BTW, when I use "echo shutdown > /sys/power/disk; echo disk > /sys/power/state" to do a hibernation, there will be occasionally "GPU reset" just like suspend. However, if I use "echo reboot > /sys/power/disk; echo disk > /sys/power/state" to do a hibernation and wakeup automatically, there is no "GPU reset" after hundreds of tests. What does this imply? Power loss cause something break? Best regards, Huacai Chen > 2011/12/7 <chenhc(a)lemote.com>: >> When "MC timeout" happens at GPU reset, we found the 12th and 13th >> bits of R_000E50_SRBM_STATUS is 1. From kernel code we found these >> two bits are like this: >> #define G_000E50_MCDX_BUSY(x) (((x) >> 12) & 1) >> #define G_000E50_MCDW_BUSY(x) (((x) >> 13) & 1) >> >> Could you please tell me what does they mean? And if possible, > > They refer to sub-blocks in the memory controller. I don't really > know off hand what the name mean. > >> I want to know the functionalities of these 5 registers in detail: >> #define R_000E60_SRBM_SOFT_RESET 0x0E60 >> #define R_000E50_SRBM_STATUS 0x0E50 >> #define R_008020_GRBM_SOFT_RESET 0x8020 >> #define R_008010_GRBM_STATUS 0x8010 >> #define R_008014_GRBM_STATUS2 0x8014 >> >> A bit more info: If I reset the MC after resetting CP (this is what >> Linux-2.6.34 does, but removed since 2.6.35), then "MC timeout" will >> disappear, but there is still "ring test failed". > > The bits are defined in r600d.h. As to the acronyms: > BIF - Bus InterFace > CG - clocks > DC - Display Controller > GRBM - Graphics block (3D engine) > HDP - Host Data Path (CPU access to vram via the PCI BAR) > IH, RLC - Interrupt controller > MC - Memory controller > ROM - ROM > SEM - semaphore controller > > When you reset the MC, you will probably have to reset just about > everything else since most blocks depend on the MC for access to > memory. If you do reset the MC, you should do it at prior to calling > asic_init so you make sure all the hw gets re-initialized properly. > Additionally, you should probably reset the GRBM either via > SRBM_SOFT_RESET or the individual sub-blocks via GRBM_SOFT_RESET. > > Alex > >> >> Huacai Chen >> >>> 2011/11/8 <chenhc(a)lemote.com>: >>>> And, I want to know something: >>>> 1, Does GPU use MC to access GTT? >>> >>> Yes. All GPU clients (display, 3D, etc.) go through the MC to access >>> memory (vram or gart). >>> >>>> 2, What can cause MC timeout？ >>> >>> Lots of things. Some GPU client still active, some GPU client hung or >>> not properly initialized. >>> >>> Alex >>> >>>> >>>>> Hi, >>>>> >>>>> Some status update. >>>>> 在 2011年9月29日下午5:17，Chen Jie <chenj(a)lemote.com> 写道： >>>>>> 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) >>>>>> [ 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) >>>>> After pinned ring in VRAM, it warned an ib test failure. It seems >>>>> something wrong with accessing through GTT. >>>>> >>>>> We dump gart table just after stopped cp, and compare gart table with >>>>> the dumped one just after r600_pcie_gart_enable, and don't find any >>>>> difference. >>>>> >>>>> Any idea? >>>>> >>>>>> [ 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). >>>>>> ... >>>>> >>>>> >>>>> >>>>> Regards, >>>>> -- Chen Jie >>>>> >>>> >>>> >>>> >>> >> >> >> >

2 1

← Newer
1
...
44
45
46
47
48
49
50
...
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