dri-devel August 2012

dri-devel@lists.freedesktop.org

145 participants
811 discussions

v3.5 Oops in i2c_algo_bit.c:bit_xfer+0x23/0x870: i915 or i2c?
by George Spelvin 13 Aug '12

13 Aug '12

I'm trying to run a v3.5 kernel (plus some -stable patches from Ted Ts'o) on an Ubuntu system. Things are generally working except for the following Oops on each boot, which prevents the graphics system from loading. [ 36.187972] [drm] Initialized drm 1.1.0 20060810 [ 36.230306] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround [ 36.487606] i915 0000:00:02.0: setting latency timer to 64 [ 36.555464] [drm] GMBUS [i915 gmbus ssc] timed out, falling back to bit banging on pin 0 [ 36.555490] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 [ 36.555626] IP: [<ffffffffa01807b3>] bit_xfer+0x23/0x870 [i2c_algo_bit] [ 36.555701] PGD 212cb0067 PUD 212caf067 PMD 0 [ 36.555803] Oops: 0000 [#1] SMP [ 36.555885] CPU 3 [ 36.555907] Modules linked in: snd_seq_midi joydev i915(+) snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper snd_timer snd_seq_device kvm_intel drm kvm snd serio_raw soundcore i2c_algo_bit snd_page_alloc lpc_ich video mei microcode mac_hid eeprom it87 hwmon_vid coretemp lp parport raid10 raid456 async_pq async_xor firewire_ohci firewire_core xor async_memcpy async_raid6_recov hid_microsoft floppy crc_itu_t r8169 pata_jmicron usbhid hid mptsas mptscsih mptbase scsi_transport_sas raid6_pq async_tx raid1 raid0 multipath linear [ 36.557232] [ 36.557271] Pid: 623, comm: modprobe Not tainted 3.5.0 #3 Gigabyte Technology Co., Ltd. H57M-USB3/H57M-USB3 [ 36.557398] RIP: 0010:[<ffffffffa01807b3>] [<ffffffffa01807b3>] bit_xfer+0x23/0x870 [i2c_algo_bit] [ 36.557493] RSP: 0000:ffff880212c6d648 EFLAGS: 00010296 [ 36.557544] RAX: ffff88021222c030 RBX: ffff880212c6d7e8 RCX: 0000000000000000 [ 36.557599] RDX: 0000000000000001 RSI: ffff880212c6d7e8 RDI: ffff88021222c030 [ 36.557655] RBP: ffff880212c6d6c8 R08: 0000000000000402 R09: 0000000000000000 [ 36.557710] R10: 0000000000000000 R11: 0000000000000006 R12: 0000000000000001 [ 36.557766] R13: ffff880212c6dfd8 R14: 0000000000000001 R15: ffff88021222c030 [ 36.557822] FS: 00007f5a7b85b700(0000) GS:ffff88021fcc0000(0000) knlGS:0000000000000000 [ 36.557899] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 36.557950] CR2: 0000000000000028 CR3: 0000000212cad000 CR4: 00000000000007e0 [ 36.558006] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 36.558062] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 36.558119] Process modprobe (pid: 623, threadinfo ffff880212c6c000, task ffff88020fdf5b80) [ 36.558197] Stack: [ 36.558239] 0000000000000001 ffff880212c6dfd8 0000000000000001 000000011222c000 [ 36.558380] ffff880212c6d6c8 ffffffff8166341e ffff88020ff6ca72 000c510c00000018 [ 36.558523] ffff880212c6d6d8 ffff880212c6d698 0000000000000082 ffff880212c6d7e8 [ 36.558671] Call Trace: [ 36.558719] [<ffffffff8166341e>] ? printk+0x61/0x63 [ 36.558790] [<ffffffffa02e5a0b>] gmbus_xfer+0x56b/0x6f0 [i915] [ 36.558847] [<ffffffff814ee7dc>] i2c_transfer+0x9c/0xe0 [ 36.558899] [<ffffffff811be91b>] ? ep_poll_callback+0x10b/0x150 [ 36.558953] [<ffffffff814ee976>] i2c_smbus_xfer_emulated+0x156/0x5d0 [ 36.559010] [<ffffffff81321d25>] ? idr_get_empty_slot+0x115/0x320 [ 36.559064] [<ffffffff814eefb3>] i2c_smbus_xfer+0x113/0x130 [ 36.559118] [<ffffffff8166e51e>] ? _raw_spin_lock+0xe/0x20 [ 36.559173] [<ffffffff81642fd9>] ? klist_next+0x89/0x110 [ 36.559225] [<ffffffff814ef61b>] i2c_default_probe+0xeb/0x130 [ 36.559279] [<ffffffff814ee18b>] ? i2c_check_addr_busy+0x3b/0x60 [ 36.559332] [<ffffffff814f077b>] i2c_do_add_adapter+0x1bb/0x290 [ 36.559382] [<ffffffff811ed1cb>] ? sysfs_do_create_link+0xeb/0x200 [ 36.559433] [<ffffffff81411897>] ? put_device+0x17/0x20 [ 36.559482] [<ffffffff814f0880>] ? __process_new_driver+0x30/0x30 [ 36.559535] [<ffffffff814f0892>] __process_new_adapter+0x12/0x20 [ 36.559590] [<ffffffff814140ee>] bus_for_each_drv+0x4e/0xa0 [ 36.559642] [<ffffffff814f029d>] i2c_register_adapter+0x16d/0x270 [ 36.559696] [<ffffffff814f0443>] i2c_add_adapter+0xa3/0xb0 [ 36.559759] [<ffffffffa02e5cfc>] intel_setup_gmbus+0xcc/0x1f0 [i915] [ 36.559821] [<ffffffffa02a938c>] i915_driver_load+0x2ac/0xb90 [i915] [ 36.559882] [<ffffffffa03f1b41>] ? drm_get_minor+0x261/0x300 [drm] [ 36.559940] [<ffffffffa03f4236>] drm_get_pci_dev+0x186/0x2d0 [drm] [ 36.559995] [<ffffffff8103c3e9>] ? default_spin_lock_flags+0x9/0x10 [ 36.560060] [<ffffffffa02f2142>] i915_pci_probe+0x16/0x20 [i915] [ 36.560115] [<ffffffff813522ac>] local_pci_probe+0x5c/0xd0 [ 36.560168] [<ffffffff81352431>] pci_device_probe+0x111/0x120 [ 36.560221] [<ffffffff81415ede>] driver_probe_device+0x7e/0x220 [ 36.560274] [<ffffffff8141612b>] __driver_attach+0xab/0xb0 [ 36.560327] [<ffffffff81416080>] ? driver_probe_device+0x220/0x220 [ 36.560375] [<ffffffff81414195>] bus_for_each_dev+0x55/0x90 [ 36.560421] [<ffffffffa0323000>] ? 0xffffffffa0322fff [ 36.560470] [<ffffffff814158de>] driver_attach+0x1e/0x20 [ 36.560522] [<ffffffff81415598>] bus_add_driver+0x198/0x270 [ 36.560573] [<ffffffffa0323000>] ? 0xffffffffa0322fff [ 36.560625] [<ffffffff814167f7>] driver_register+0x77/0x150 [ 36.560677] [<ffffffffa0323000>] ? 0xffffffffa0322fff [ 36.560729] [<ffffffff8135110e>] __pci_register_driver+0x5e/0xe0 [ 36.560784] [<ffffffffa0323000>] ? 0xffffffffa0322fff [ 36.560839] [<ffffffffa03f449a>] drm_pci_init+0x11a/0x130 [drm] [ 36.560892] [<ffffffffa0323000>] ? 0xffffffffa0322fff [ 36.560949] [<ffffffffa032308b>] i915_init+0x8b/0x8d [i915] [ 36.561004] [<ffffffff8100212a>] do_one_initcall+0x12a/0x180 [ 36.561057] [<ffffffff810af280>] sys_init_module+0x10b0/0x1f40 [ 36.561111] [<ffffffff810ab760>] ? free_notes_attrs+0x60/0x60 [ 36.561165] [<ffffffff81676769>] system_call_fastpath+0x16/0x1b [ 36.561218] Code: 5d c3 45 31 ff eb e9 90 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 58 66 66 66 66 90 48 8b 4f 18 49 89 ff 48 89 f3 89 55 9c <48> 8b 41 28 48 89 4d 90 48 85 c0 74 0c ff d0 85 c0 89 c1 0f 88 [ 36.562478] RIP [<ffffffffa01807b3>] bit_xfer+0x23/0x870 [i2c_algo_bit] [ 36.562544] RSP <ffff880212c6d648> [ 36.562584] CR2: 0000000000000028 [ 36.562667] ---[ end trace f73eb7bcfaa57c45 ]--- As far as I can tell, the passed i2c_adap->algo_data is NULL, so the fetch of adap->pre_xfer is oopsing. Unfortunately, I'm trying to run ext4 + metadata_csum, which requires 3.5+patches. I don't see anything relevant on the mailing list. Do any DRM hackers have any ideas what's up? System is an i3-530 with 8GiB of RAM. (Its primary job is file server, but the display also gets used sometime.) Thanks!

4 5

[PATCH V2] drm/radeon: Include swiotlb.h if SWIOTLB configured.
by Huacai Chen 13 Aug '12

13 Aug '12

When SWIOTLB is configured, if without this patch kernel compilation fails with such error messages: drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_populate': drivers/gpu/drm/radeon/radeon_ttm.c:606:2: error: implicit declaration of function 'swiotlb_nr_tbl' drivers/gpu/drm/radeon/radeon_ttm.c:607:3: warning: passing argument 2 of 'ttm_dma_populate' from incompatible pointer type include/drm/ttm/ttm_page_alloc.h:81:12: note: expected 'struct device *' but argument is of type 'struct device *' drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_tt_unpopulate': drivers/gpu/drm/radeon/radeon_ttm.c:653:3: warning: passing argument 2 of 'ttm_dma_unpopulate' from incompatible pointer type include/drm/ttm/ttm_page_alloc.h:82:13: note: expected 'struct device *' but argument is of type 'struct device *' V2: 1, Add compilation error messages; 2, Make the From: address the same as Signed-off-by address. Signed-off-by: Huacai Chen <chenhc(a)lemote.com> Signed-off-by: Hongliang Tao <taohl(a)lemote.com> Signed-off-by: Hua Yan <yanh(a)lemote.com> Cc: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5b71c71..fc3ac22 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -41,6 +41,10 @@ #include "radeon_reg.h" #include "radeon.h" +#ifdef CONFIG_SWIOTLB +#include <linux/swiotlb.h> +#endif + #define DRM_FILE_PAGE_OFFSET (0x100000000ULL >> PAGE_SHIFT) static int radeon_ttm_debugfs_init(struct radeon_device *rdev); -- 1.7.7.3

2 1

[PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
by Huacai Chen 13 Aug '12

13 Aug '12

When SWIOTLB is configured, if without this patch kernel compilation fails. Signed-off-by: Huacai Chen <chenhc(a)lemote.com> Signed-off-by: Hongliang Tao <taohl(a)lemote.com> Signed-off-by: Hua Yan <yanh(a)lemote.com> Cc: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5b71c71..fc3ac22 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -41,6 +41,10 @@ #include "radeon_reg.h" #include "radeon.h" +#ifdef CONFIG_SWIOTLB +#include <linux/swiotlb.h> +#endif + #define DRM_FILE_PAGE_OFFSET (0x100000000ULL >> PAGE_SHIFT) static int radeon_ttm_debugfs_init(struct radeon_device *rdev); -- 1.7.7.3

2 5

3.4.0 -> 3.5.0 bad rendering effects on radeon
by Andrea 12 Aug '12

12 Aug '12

Hi, I use Fedora 17 and as soon as kernel 3.5 has been distributed, I get very bad rendering artifacts on my laptop. The laptop is a Thinkpad R50 with a radeon graphics card 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 02) It is not a new laptop, about 8 years old. I've opened a bug at Fedora where you can see 2 pictures of what happens. https://bugzilla.redhat.com/show_bug.cgi?id=845639 Reading the mailing list, I cannot understand if this problem has already been reported. I've tried to bisect but I've hit a series of unbootable kernels. "git bisect visualize" currently shows the log between BAD: be122ab Merge tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6 GOOD: c10e408 i915: Add option to bypass vbt table. where I can see a lot of drm related changes. Regards

1 0

3.6-rc1 breaks my laptop graphics (intel)
by Greg KH 12 Aug '12

12 Aug '12

Hi Daniel. The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the i915 driver initializes itself. I bisected this down to commit 24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the blc controller on the right pipe), and when I revert that, and also a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't forget the PCH backlight registers) which depended on the first patch, my laptop works just fine. Below is the combined revert. Any thoughts? Any patch I can try out? thanks, greg k-h ------ Subject: drm/i915: revert 24ded204429fa0f5501d37c63ee35c555c0b75ee and a4f32fc3a37e982fffce8ec583643990ff288419 24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the blc controller on the right pipe) breaks the boot for my laptop, so revert it, and a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't forget the PCH backlight registers) which depended on it. Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 8435355..4e786f2 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -383,8 +383,7 @@ extern u32 intel_panel_get_max_backlight(struct drm_device *dev); extern u32 intel_panel_get_backlight(struct drm_device *dev); extern void intel_panel_set_backlight(struct drm_device *dev, u32 level); extern int intel_panel_setup_backlight(struct drm_device *dev); -extern void intel_panel_enable_backlight(struct drm_device *dev, - enum pipe pipe); +extern void intel_panel_enable_backlight(struct drm_device *dev); extern void intel_panel_disable_backlight(struct drm_device *dev); extern void intel_panel_destroy_backlight(struct drm_device *dev); extern enum drm_connector_status intel_panel_detect(struct drm_device *dev); diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index e05c0d3..6547904 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -71,7 +71,6 @@ static struct intel_lvds *intel_attached_lvds(struct drm_connector *connector) static void intel_lvds_enable(struct intel_lvds *intel_lvds) { struct drm_device *dev = intel_lvds->base.base.dev; - struct intel_crtc *intel_crtc = to_intel_crtc(intel_lvds->base.base.crtc); struct drm_i915_private *dev_priv = dev->dev_private; u32 ctl_reg, lvds_reg, stat_reg; @@ -108,7 +107,7 @@ static void intel_lvds_enable(struct intel_lvds *intel_lvds) if (wait_for((I915_READ(stat_reg) & PP_ON) != 0, 1000)) DRM_ERROR("timed out waiting for panel to power on\n"); - intel_panel_enable_backlight(dev, intel_crtc->pipe); + intel_panel_enable_backlight(dev); } static void intel_lvds_disable(struct intel_lvds *intel_lvds) @@ -1079,14 +1078,35 @@ bool intel_lvds_init(struct drm_device *dev) goto failed; out: - /* - * Unlock registers and just - * leave them unlocked - */ if (HAS_PCH_SPLIT(dev)) { + u32 pwm; + + pipe = (I915_READ(PCH_LVDS) & LVDS_PIPEB_SELECT) ? 1 : 0; + + /* make sure PWM is enabled and locked to the LVDS pipe */ + pwm = I915_READ(BLC_PWM_CPU_CTL2); + if (pipe == 0 && (pwm & BLM_PIPE_B)) + I915_WRITE(BLC_PWM_CPU_CTL2, pwm & ~BLM_PWM_ENABLE); + if (pipe) + pwm |= BLM_PIPE_B; + else + pwm &= ~BLM_PIPE_B; + I915_WRITE(BLC_PWM_CPU_CTL2, pwm | BLM_PWM_ENABLE); + + pwm = I915_READ(BLC_PWM_PCH_CTL1); + pwm |= BLM_PCH_PWM_ENABLE; + I915_WRITE(BLC_PWM_PCH_CTL1, pwm); + /* + * Unlock registers and just + * leave them unlocked + */ I915_WRITE(PCH_PP_CONTROL, I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS); } else { + /* + * Unlock registers and just + * leave them unlocked + */ I915_WRITE(PP_CONTROL, I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS); } diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 10c7d39..7180cc8 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -287,24 +287,9 @@ void intel_panel_disable_backlight(struct drm_device *dev) dev_priv->backlight_enabled = false; intel_panel_actually_set_backlight(dev, 0); - - if (INTEL_INFO(dev)->gen >= 4) { - uint32_t reg, tmp; - - reg = HAS_PCH_SPLIT(dev) ? BLC_PWM_CPU_CTL2 : BLC_PWM_CTL2; - - I915_WRITE(reg, I915_READ(reg) & ~BLM_PWM_ENABLE); - - if (HAS_PCH_SPLIT(dev)) { - tmp = I915_READ(BLC_PWM_PCH_CTL1); - tmp &= ~BLM_PCH_PWM_ENABLE; - I915_WRITE(BLC_PWM_PCH_CTL1, tmp); - } - } } -void intel_panel_enable_backlight(struct drm_device *dev, - enum pipe pipe) +void intel_panel_enable_backlight(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; @@ -313,40 +298,6 @@ void intel_panel_enable_backlight(struct drm_device *dev, dev_priv->backlight_enabled = true; intel_panel_actually_set_backlight(dev, dev_priv->backlight_level); - - if (INTEL_INFO(dev)->gen >= 4) { - uint32_t reg, tmp; - - reg = HAS_PCH_SPLIT(dev) ? BLC_PWM_CPU_CTL2 : BLC_PWM_CTL2; - - - tmp = I915_READ(reg); - - /* Note that this can also get called through dpms changes. And - * we don't track the backlight dpms state, hence check whether - * we have to do anything first. */ - if (tmp & BLM_PWM_ENABLE) - return; - - if (dev_priv->num_pipe == 3) - tmp &= ~BLM_PIPE_SELECT_IVB; - else - tmp &= ~BLM_PIPE_SELECT; - - tmp |= BLM_PIPE(pipe); - tmp &= ~BLM_PWM_ENABLE; - - I915_WRITE(reg, tmp); - POSTING_READ(reg); - I915_WRITE(reg, tmp | BLM_PWM_ENABLE); - - if (HAS_PCH_SPLIT(dev)) { - tmp = I915_READ(BLC_PWM_PCH_CTL1); - tmp |= BLM_PCH_PWM_ENABLE; - tmp &= ~BLM_PCH_OVERRIDE_ENABLE; - I915_WRITE(BLC_PWM_PCH_CTL1, tmp); - } - } } static void intel_panel_init_backlight(struct drm_device *dev)

2 4

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
by bugzilla-daemon＠freedesktop.org 12 Aug '12

12 Aug '12

https://bugs.freedesktop.org/show_bug.cgi?id=26891 headwall <hedvall(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hedvall(a)gmail.com --- Comment #33 from headwall <hedvall(a)gmail.com> 2012-08-12 17:52:10 UTC --- I tried the VFCT patch on a Mac Pro 1,1, and it gives me a kernel panic. I can't really give any details on it because the screen output is garbled. The previous patch with adding the video ROM to the kernel works, but without X support. Should the VFCT table show up in /sys/firmware/acpi/tables? If so, the Mac doesn't support this method. Does anyone know what Darwin/OSX does to get the ROM? -- 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

How to find out modeline without attaching actual device?
by Paul Menzel 12 Aug '12

12 Aug '12

Dear Linux folks, regarding modelines problems with some TVs [1] and EDID quirks, Ian sent nice patches for [2], is there a way to test what modeline the DRM subsystem would choose without actually attaching the device? The problem is, the TV is at a different place and I rarely have access to it. So it would be great if I could just use some kind of simulator and pass the EDID to it, what connector it is on (though this should not matter) and I get the calculated modeline as a result. This should be enough since I already know what modeline works. Thanks, Paul [1] https://bugs.freedesktop.org/show_bug.cgi?id=26294 [2] http://lists.freedesktop.org/archives/dri-devel/2012-August/026264.html

2 1

[PATCH 1/3] gma500: Fix comment mispelling in cdv_intel_limits definition.
by Forest Bond 12 Aug '12

12 Aug '12

From: Forest Bond <forest.bond(a)rapidrollout.com> Signed-off-by: Forest Bond <forest.bond(a)rapidrollout.com> --- drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c b/drivers/gpu/drm/gma500/cdv_intel_display.c index a68509b..883a9f3 100644 --- a/drivers/gpu/drm/gma500/cdv_intel_display.c +++ b/drivers/gpu/drm/gma500/cdv_intel_display.c @@ -65,7 +65,7 @@ struct cdv_intel_limit_t { #define CDV_LIMIT_DAC_HDMI_96 3 static const struct cdv_intel_limit_t cdv_intel_limits[] = { - { /* CDV_SIGNLE_LVDS_96MHz */ + { /* CDV_SINGLE_LVDS_96MHz */ .dot = {.min = 20000, .max = 115500}, .vco = {.min = 1800000, .max = 3600000}, .n = {.min = 2, .max = 6}, -- 1.7.0.4

2 4

[ANNOUNCE] libdrm 2.4.38
by Marek Olšák 12 Aug '12

12 Aug '12

Alex Deucher (2): radeon: add some missing evergreen pci ids radeon: add some new SI pci ids Chris Wilson (1): intel: Bail gracefully if we encounter an unknown Intel device Cooper Yuan (1): libdrm/exynos: padding gem_mmap structure to 64-bit aligned Damien Lespiau (1): intel: Remove two unused variables Dave Airlie (4): libdrm: add missing caps from kernel to drm.h libdrm: add prime fd->handle and handle->fd interfaces libdrm/nouveau: add prime handle->bo and bo->handle support. intel: add prime interface for getting/setting a prime bo. (v4) Eric Anholt (4): intel: Quiet valgrind warnings in context creation. Drop "-Wunsafe-loop-optimizations". intel: Import updated i915_drm.h. intel: Add a function for the new register read ioctl. Kenneth Graunke (1): intel: Change context create failure message to from fprintf to DBG(). Laurent Pinchart (8): modetest: Unify buffer allocation modetest: Add SMPTE test pattern modetest: Add test pattern support for missing packed YUV formats modetest: Add test pattern support for missing planar YUV formats modetest: Add test pattern support for missing RGB formats modetest: Move connector and plane parsing to separate functions modetest: Make frame buffer format configurable on the command line modeset: Split buffer allocation to a separate file Lauri Kasanen (1): intel: Fix build failure in test_decode.c Marek Olšák (6): radeon: simplify ZS buffer checking on r600 radeon: optimize allocation for depth w/o stencil and stencil w/o depth on EG radeon: force 2D tiling for MSAA surfaces radeon: tweak TILE_SPLIT for MSAA surfaces tests/modetest: fix distcheck configure: bump version for 2.4.38 release Paulo Zanoni (1): intel: add more Haswell PCI IDs Rob Clark (5): omap: clarify dmabuf file descriptor ownership omap: add API to import bo's from dmabuf fd's omap: add refcnting and handle tracking intel: fix build error modetest: fix uninitialized fourcc git tag: libdrm-2.4.38 http://dri.freedesktop.org/www/libdrm/libdrm-2.4.38.tar.bz2 MD5: 8018e0bce5059cee05d855503d262cce libdrm-2.4.38.tar.bz2 SHA1: 21718ddb8be71bc74845a33c2b4fbda1de942e16 libdrm-2.4.38.tar.bz2 SHA256: a7caec55c945f7f8dec55fea9200391a168298bcdc4cb9a93c976e748193171a libdrm-2.4.38.tar.bz2 http://dri.freedesktop.org/www/libdrm/libdrm-2.4.38.tar.gz MD5: 9aa553e543d716f2f9b9405274c5d9c3 libdrm-2.4.38.tar.gz SHA1: 8a98f0332b33d647918cc8c4bf41fbe1e21a15cb libdrm-2.4.38.tar.gz SHA256: 75d586a5a989a572e63a8f1252a51dfee4cdeb0146f8b9fe5ecd1b6844e85a20 libdrm-2.4.38.tar.gz

2 2

[drm-intel:drm-intel-next-queued 62/62] drivers/gpu/drm/i915/i915_debugfs.c:1959:6: warning: unused variable 'ret'
by Fengguang Wu 12 Aug '12

12 Aug '12

Hi Daniel, FYI, there are new compile warnings show up in tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued head: ffedf4590c151968e7881e0bbf340da648dfd072 commit: ffedf4590c151968e7881e0bbf340da648dfd072 [62/62] drm/i915: don't grab dev->struct_mutex for userspace forcewak config: x86_64-allmodconfig (attached as .config) All error/warnings: drivers/gpu/drm/i915/i915_debugfs.c: In function 'i915_forcewake_open': drivers/gpu/drm/i915/i915_debugfs.c:1959:6: warning: unused variable 'ret' [-Wunused-variable] vim +1959 drivers/gpu/drm/i915/i915_debugfs.c 1956 { 1957 struct drm_device *dev = inode->i_private; 1958 struct drm_i915_private *dev_priv = dev->dev_private; > 1959 int ret; 1960 1961 if (INTEL_INFO(dev)->gen < 6) 1962 return 0; --- 0-DAY kernel build testing backend Open Source Technology Centre Fengguang Wu <wfg(a)linux.intel.com> Intel Corporation

2 1

← Newer
1
...
67
68
69
70
71
72
73
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2012