dri-devel February 2013

dri-devel@lists.freedesktop.org

130 participants
696 discussions

[Bug 49531] New: Powering down inactive GPU while running X causes NULL pointer dereference
by bugzilla-daemon＠bugzilla.kernel.org 17 Feb '13

17 Feb '13

https://bugzilla.kernel.org/show_bug.cgi?id=49531 Summary: Powering down inactive GPU while running X causes NULL pointer dereference Product: Drivers Version: 2.5 Kernel Version: 3.7.0-rc2+ Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: e-mail(a)date.by CC: alexdeucher(a)gmail.com Regression: No Created an attachment (id=84841) --> (https://bugzilla.kernel.org/attachment.cgi?id=84841) /var/log/syslog On my muxed hybrid system (Lenovo IdeaPad U455) vga_switcheroo works fine if X is not running. But if both GPUs are powered and X is running, then when i try to power down inactive GPU with # echo OFF > /sys/kernel/debug/vgaswitcheroo/switch kernel crashes after a couple of minutes. There is an error message in the /var/log/syslog: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa046812b>] r600_pcie_gart_tlb_flush+0xeb/0x110 [radeon] PGD 8d24c067 PUD 8d24b067 PMD 0 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 pcmcia pcmcia_core xfs exportfs ext2 mbcache cpufreq_ondemand mperf lp parport_pc parport fuse uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media btusb bluetooth joydev brcmsmac radeon cordic brcmutil mac80211 ttm drm_kms_helper snd_hda_codec_hdmi snd_hda_codec_conexant drm cfg80211 snd_hda_intel agpgart snd_hda_codec snd_hwdep sp5100_tco ohci_hcd i2c_piix4 powernow_k8 ideapad_laptop i2c_algo_bit psmouse sparse_keymap snd_pcm ehci_hcd i2c_core processor freq_table rfkill thermal bcma rtc_cmos atl1c snd_page_alloc serio_raw k8temp thermal_sys snd_timer shpchp button battery snd soundcore hwmon evdev ac loop btrfs [last unloaded: pcmcia_core] CPU 0 Pid: 2291, comm: X Not tainted 3.7.0-rc2+ #70 LENOVO 20046 /AMD CRB RIP: 0010:[<ffffffffa046812b>] [<ffffffffa046812b>] r600_pcie_gart_tlb_flush+0xeb/0x110 [radeon] RSP: 0018:ffff8800894d1918 EFLAGS: 00010282 RAX: ffffc90001322f34 RBX: 0000000000000000 RCX: 00000000aadfb000 RDX: 0000000000000000 RSI: 0000000000002f34 RDI: ffff8800aad18000 RBP: ffff8800894d1928 R08: 00000000dfffffff R09: 00000000000000d0 R10: 0000000000031cd5 R11: 0000000000000000 R12: ffff8800aad18000 R13: 0000000000000219 R14: 0000000000000219 R15: 0000000000000000 FS: 00007f8819d618c0(0000) GS:ffff8800afa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000008d18d000 CR4: 00000000000007f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process X (pid: 2291, threadinfo ffff8800894d0000, task ffff88008d128000) Stack: ffff8800aad18000 0000000000000219 ffff8800894d1958 ffffffffa043d365 ffff8800896f1580 ffff8800894d1bc8 0000000000000000 ffff8800894d1bc8 ffff8800894d1968 ffffffffa043a98a ffff8800894d1988 ffffffffa01ef097 Call Trace: [<ffffffffa043d365>] radeon_gart_unbind+0xa5/0xe0 [radeon] [<ffffffffa043a98a>] radeon_ttm_backend_unbind+0x1a/0x20 [radeon] [<ffffffffa01ef097>] ttm_tt_unbind+0x27/0x40 [ttm] [<ffffffffa01f36e6>] ttm_bo_move_memcpy+0x266/0x580 [ttm] [<ffffffffa043b693>] radeon_bo_move+0xd3/0x180 [radeon] [<ffffffffa01f0f46>] ttm_bo_handle_move_mem+0x216/0x3f0 [ttm] [<ffffffffa01f1d10>] ? ttm_bo_mem_space+0x180/0x360 [ttm] [<ffffffffa01f2032>] ttm_bo_move_buffer+0x142/0x150 [ttm] [<ffffffffa01f20dc>] ttm_bo_validate+0x9c/0x120 [ttm] [<ffffffffa043c24a>] radeon_bo_pin_restricted+0x10a/0x1b0 [radeon] [<ffffffffa0449eab>] radeon_crtc_cursor_set+0x9b/0x4a0 [radeon] [<ffffffffa037e788>] ? drm_mode_object_find+0x68/0x90 [drm] [<ffffffffa0382425>] drm_mode_cursor_ioctl+0x105/0x160 [drm] [<ffffffffa0372443>] drm_ioctl+0x4c3/0x570 [drm] [<ffffffffa0382320>] ? drm_mode_setcrtc+0x5a0/0x5a0 [drm] [<ffffffff8154b07c>] ? __do_page_fault+0x25c/0x4b0 [<ffffffff8115e7e0>] do_vfs_ioctl+0x90/0x570 [<ffffffff8114d71b>] ? rw_verify_area+0x4b/0xf0 [<ffffffff81057d67>] ? __set_task_blocked+0x37/0x80 [<ffffffff8154748e>] ? _raw_spin_unlock_irq+0xe/0x20 [<ffffffff8105a322>] ? __set_current_blocked+0x52/0x60 [<ffffffff8115ed51>] sys_ioctl+0x91/0xb0 [<ffffffff8154f899>] system_call_fastpath+0x16/0x1b Code: c1 e8 04 83 f8 02 74 2a 85 c0 74 cc 5b 41 5c 5d c3 0f 1f 80 00 00 00 00 31 d2 be 34 2f 00 00 48 8b 9f 98 03 00 00 e8 e5 37 ff ff <8b> 03 e9 4a ff ff ff 48 c7 c7 f0 9f 4b a0 31 c0 e8 f3 5d 0d e1 RIP [<ffffffffa046812b>] r600_pcie_gart_tlb_flush+0xeb/0x110 [radeon] RSP <ffff8800894d1918> CR2: 0000000000000000 ---[ end trace 4363d7f2115bb109 ]--- -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 7

[PATCH] drm/i915: Set i9xx lvds clock limits according to specifications
by Patrik Jakobsson 16 Feb '13

16 Feb '13

The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9. Since we do all calculations based on them being register values (which are subtracted by 2) we need to specify them accordingly. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson(a)gmail.com> --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0dfecaf..4f6c594 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -168,8 +168,8 @@ static const intel_limit_t intel_limits_i9xx_lvds = { .vco = { .min = 1400000, .max = 2800000 }, .n = { .min = 1, .max = 6 }, .m = { .min = 70, .max = 120 }, - .m1 = { .min = 10, .max = 22 }, - .m2 = { .min = 5, .max = 9 }, + .m1 = { .min = 8, .max = 18 }, + .m2 = { .min = 3, .max = 7 }, .p = { .min = 7, .max = 98 }, .p1 = { .min = 1, .max = 8 }, .p2 = { .dot_limit = 112000, -- 1.7.10.4

4 10

3.8.0-rc7, nouveau, possible recursive locking, nouveau_instobj_create_ and nv50_disp_data_ctor
by Denys Fedoryshchenko 16 Feb '13

16 Feb '13

Hi Booted on Toshiba laptop, x86_64, NVIDIA Corporation GT218 [GeForce 310M], latest rc, and got this. Please let me know if you need additional information. [ 16.595094] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 16.595096] [TTM] Initializing pool allocator [ 16.595147] [TTM] Initializing DMA pool allocator [ 16.600363] nouveau [ DRM] VRAM: 512 MiB [ 16.600367] nouveau [ DRM] GART: 512 MiB [ 16.600387] nouveau [ DRM] BIT BIOS found [ 16.600391] nouveau [ DRM] Bios version 70.18.5f.00 [ 16.600394] nouveau [ DRM] TMDS table version 2.0 [ 16.600397] nouveau [ DRM] DCB version 4.0 [ 16.600400] nouveau [ DRM] DCB outp 00: 01000323 00010034 [ 16.600419] nouveau [ DRM] DCB outp 01: 02011300 00000000 [ 16.600421] nouveau [ DRM] DCB outp 02: 08022382 00020010 [ 16.600424] nouveau [ DRM] DCB conn 00: 00000040 [ 16.600427] nouveau [ DRM] DCB conn 01: 00000100 [ 16.600430] nouveau [ DRM] DCB conn 02: 00002261 [ 16.677661] [ 16.678006] ============================================= [ 16.678006] [ INFO: possible recursive locking detected ] [ 16.678006] 3.8.0-rc7-lap #1 Tainted: G W [ 16.678006] --------------------------------------------- [ 16.678006] udevd/1236 is trying to acquire lock: [ 16.678006] (&subdev->mutex){+.+.+.}, at: [<ffffffffa0291ca4>] nouveau_instobj_create_+0x3c/0x7a [nouveau] [ 16.678006] [ 16.678006] but task is already holding lock: [ 16.678006] (&subdev->mutex){+.+.+.}, at: [<ffffffffa02993be>] nv50_disp_data_ctor+0x40/0xaf [nouveau] [ 16.678006] [ 16.678006] other info that might help us debug this: [ 16.678006] Possible unsafe locking scenario: [ 16.678006] [ 16.678006] CPU0 [ 16.678006] ---- [ 16.678006] lock(&subdev->mutex); [ 16.678006] lock(&subdev->mutex); [ 16.678006] [ 16.678006] *** DEADLOCK *** [ 16.678006] [ 16.678006] May be due to missing lock nesting notation [ 16.678006] [ 16.678006] 4 locks held by udevd/1236: [ 16.678006] #0: (&__lockdep_no_validate__){......}, at: [<ffffffff812daaf4>] device_lock+0xf/0x11 [ 16.678006] #1: (&__lockdep_no_validate__){......}, at: [<ffffffff812daaf4>] device_lock+0xf/0x11 [ 16.678006] #2: (drm_global_mutex){+.+.+.}, at: [<ffffffff812c6fa7>] drm_get_pci_dev+0xb9/0x265 [ 16.678006] #3: (&subdev->mutex){+.+.+.}, at: [<ffffffffa02993be>] nv50_disp_data_ctor+0x40/0xaf [nouveau] [ 16.678006] [ 16.678006] stack backtrace: [ 16.678006] Pid: 1236, comm: udevd Tainted: G W 3.8.0-rc7-lap #1 [ 16.678006] Call Trace: [ 16.678006] [<ffffffff81070969>] __lock_acquire+0xaa2/0xebc [ 16.678006] [<ffffffff81077bd4>] ? __module_text_address+0xd/0x5a [ 16.678006] [<ffffffff8107b745>] ? is_module_text_address+0x1d/0x29 [ 16.678006] [<ffffffff810711a4>] lock_acquire+0x7e/0x94 [ 16.678006] [<ffffffffa0291ca4>] ? nouveau_instobj_create_+0x3c/0x7a [nouveau] [ 16.678006] [<ffffffff815372a3>] __mutex_lock_common+0x5c/0x379 [ 16.678006] [<ffffffffa0291ca4>] ? nouveau_instobj_create_+0x3c/0x7a [nouveau] [ 16.678006] [<ffffffffa0291ca4>] ? nouveau_instobj_create_+0x3c/0x7a [nouveau] [ 16.678006] [<ffffffff815376bb>] mutex_lock_nested+0x3b/0x40 [ 16.678006] [<ffffffffa0291ca4>] nouveau_instobj_create_+0x3c/0x7a [nouveau] [ 16.678006] [<ffffffffa029275b>] nv50_instobj_ctor+0x45/0xde [nouveau] [ 16.678006] [<ffffffffa027c893>] nouveau_object_ctor+0x28/0x9c [nouveau] [ 16.678006] [<ffffffffa029259c>] nv50_instmem_alloc+0x21/0x23 [nouveau] [ 16.678006] [<ffffffffa027b3af>] nouveau_gpuobj_create_+0xaa/0x22a [nouveau] [ 16.678006] [<ffffffff810715e6>] ? trace_hardirqs_on_caller+0x121/0x158 [ 16.678006] [<ffffffffa027a366>] nouveau_engctx_create_+0xaf/0x199 [nouveau] [ 16.678006] [<ffffffffa029940a>] nv50_disp_data_ctor+0x8c/0xaf [nouveau] [ 16.678006] [<ffffffffa027db0d>] ? nouveau_subdev_reset+0x52/0x56 [nouveau] [ 16.678006] [<ffffffffa027c893>] nouveau_object_ctor+0x28/0x9c [nouveau] [ 16.678006] [<ffffffffa027d0a3>] nouveau_object_new+0x129/0x1fb [nouveau] [ 16.678006] [<ffffffffa02f2458>] nv50_display_create+0x158/0x7c4 [nouveau] [ 16.678006] [<ffffffff81045117>] ? __cancel_work_timer+0x81/0xaf [ 16.678006] [<ffffffff81045132>] ? __cancel_work_timer+0x9c/0xaf [ 16.678006] [<ffffffffa02e16b5>] nouveau_display_create+0x40a/0x466 [nouveau] [ 16.678006] [<ffffffffa02d4d7c>] nouveau_drm_load+0x245/0x4c0 [nouveau] [ 16.678006] [<ffffffff812d9092>] ? device_register+0x19/0x1e [ 16.678006] [<ffffffff812c5db0>] ? drm_get_minor+0x226/0x280 [ 16.678006] [<ffffffff812c7048>] drm_get_pci_dev+0x15a/0x265 [ 16.678006] [<ffffffff8123d7a0>] ? __pci_set_master+0x1f/0x67 [ 16.678006] [<ffffffffa02d47b5>] nouveau_drm_probe+0x1dd/0x201 [nouveau] [ 16.678006] [<ffffffff81240de3>] local_pci_probe+0x39/0x61 [ 16.678006] [<ffffffff81241ce5>] pci_device_probe+0x63/0x8d [ 16.678006] [<ffffffff812dae6e>] ? driver_sysfs_add+0x6b/0x90 [ 16.678006] [<ffffffff812db172>] driver_probe_device+0xab/0x1c4 [ 16.678006] [<ffffffff812db2d5>] __driver_attach+0x4a/0x6b [ 16.678006] [<ffffffff812db28b>] ? driver_probe_device+0x1c4/0x1c4 [ 16.678006] [<ffffffff812d9a0e>] bus_for_each_dev+0x57/0x84 [ 16.678006] [<ffffffff812dae01>] driver_attach+0x19/0x1b [ 16.678006] [<ffffffff812da8c4>] bus_add_driver+0xa8/0x1fa [ 16.678006] [<ffffffff812db7c5>] driver_register+0x8e/0x108 [ 16.678006] [<ffffffff81241df3>] __pci_register_driver+0x5f/0x64 [ 16.678006] [<ffffffff812c71d8>] drm_pci_init+0x85/0xea [ 16.678006] [<ffffffffa0335000>] ? 0xffffffffa0334fff [ 16.678006] [<ffffffffa0335000>] ? 0xffffffffa0334fff [ 16.678006] [<ffffffffa033504d>] nouveau_drm_init+0x4d/0x4f [nouveau] [ 16.678006] [<ffffffff81000232>] do_one_initcall+0x7a/0x130 [ 16.678006] [<ffffffff8107acd4>] load_module+0x168b/0x19c0 [ 16.678006] [<ffffffff8107863d>] ? free_notes_attrs+0x46/0x46 [ 16.678006] [<ffffffff8107b0b2>] sys_init_module+0xa9/0xab [ 16.678006] [<ffffffff8153ef96>] system_call_fastpath+0x1a/0x1f [ 16.776320] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 16.777184] [drm] No driver support for vblank timestamp query. [ 16.778029] nouveau [ DRM] ACPI backlight interface available, not registering our own --- Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.

2 1

[PATCH v2 0/5] drm/tegra: Miscellaneous enhancements
by Thierry Reding 15 Feb '13

15 Feb '13

[Rebased on v3.8-rc3 to avoid a conflict in drivers/gpu/drm/tegra/drm.h] Hi, This patch series introduces a number of useful features for the Tegra DRM driver. The first patch allows VBLANK support to be used in drivers that don't or can't use DRIVER_HAVE_IRQ for interrupt support. Patch 2 adds support for the additional two planes available on Tegra hardware, while patch 3 implement .mode_set_base() to allow for some nice speed up when changing the framebuffer without actually changing the resolution. Patch 4 adds VBLANK support and finally patch 5 builds on it to provide the page-flipping IOCTL. Thierry Thierry Reding (5): drm: Allow vblank support without DRIVER_HAVE_IRQ drm/tegra: Add plane support drm/tegra: Implement .mode_set_base() drm/tegra: Implement VBLANK support drm/tegra: Implement page-flipping support drivers/gpu/drm/drm_irq.c | 5 +- drivers/gpu/drm/tegra/dc.c | 475 ++++++++++++++++++++++++++++++++++---------- drivers/gpu/drm/tegra/dc.h | 2 +- drivers/gpu/drm/tegra/drm.c | 53 +++++ drivers/gpu/drm/tegra/drm.h | 37 ++++ 5 files changed, 461 insertions(+), 111 deletions(-) -- 1.8.1

9 41

[PATCH] drm: tegra: don't depend on OF
by Stephen Warren 15 Feb '13

15 Feb '13

From: Stephen Warren <swarren(a)nvidia.com> ARCH_TEGRA always enabled OF, so there's no need for any driver to depend on it. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- drivers/gpu/drm/tegra/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig index be1daf7..15974ae 100644 --- a/drivers/gpu/drm/tegra/Kconfig +++ b/drivers/gpu/drm/tegra/Kconfig @@ -1,6 +1,6 @@ config DRM_TEGRA tristate "NVIDIA Tegra DRM" - depends on DRM && OF && ARCH_TEGRA + depends on DRM && ARCH_TEGRA select DRM_KMS_HELPER select DRM_GEM_CMA_HELPER select DRM_KMS_CMA_HELPER -- 1.7.10.4

2 1

Fwd:
by Miguel Botón 15 Feb '13

15 Feb '13

http://www.urquattro.it/000_Old/3izmlv.php?s=lf ------------------------------------------------------------------------------ The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 0

[PATCH] drm: don't add inferred modes for monitors that don't support them
by Paulo Zanoni 15 Feb '13

15 Feb '13

From: Paulo Zanoni <paulo.r.zanoni(a)intel.com> If bit 0 of the features byte (0x18) is set to 0, then, according to the EDID spec, "the display is non-continuous frequency (multi-mode) and is only specified to accept the video timing formats that are listed in Base EDID and certain Extension Blocks". For more information, please see the EDID spec, check the notes of the table that explains the "Feature Support" byte (18h) and also the notes on the tables of the section that explains "Display Range Limits & Additional Timing Description Definition (tag #FDh)". Cc: Adam Jackson <ajax(a)redhat.com> Cc: stable(a)vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729 Signed-off-by: Paulo Zanoni <paulo.r.zanoni(a)intel.com> --- drivers/gpu/drm/drm_edid.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) I still need to ask some specific people to test the patch, but I believe it is correct. diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index a3a3b61..6a003b6 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -2053,7 +2053,8 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) num_modes += add_cvt_modes(connector, edid); num_modes += add_standard_modes(connector, edid); num_modes += add_established_modes(connector, edid); - num_modes += add_inferred_modes(connector, edid); + if (edid->features & DRM_EDID_FEATURE_DEFAULT_GTF) + num_modes += add_inferred_modes(connector, edid); num_modes += add_cea_modes(connector, edid); if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75)) -- 1.7.10.4

3 2

[PATCH] drm: make frame duration time calculation more precise
by Daniel Kurtz 15 Feb '13

15 Feb '13

It is a bit more precise to compute the total number of pixels first and then divide, rather than multiplying the line pixel count by the already-rounded line duration. Signed-off-by: Daniel Kurtz <djkurtz(a)chromium.org> --- drivers/gpu/drm/drm_irq.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 19c01ca..05c91e0 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -505,6 +505,7 @@ void drm_calc_timestamping_constants(struct drm_crtc *crtc) /* Valid dotclock? */ if (dotclock > 0) { + int frame_size; /* Convert scanline length in pixels and video dot clock to * line duration, frame duration and pixel duration in * nanoseconds: @@ -512,7 +513,10 @@ void drm_calc_timestamping_constants(struct drm_crtc *crtc) pixeldur_ns = (s64) div64_u64(1000000000, dotclock); linedur_ns = (s64) div64_u64(((u64) crtc->hwmode.crtc_htotal * 1000000000), dotclock); - framedur_ns = (s64) crtc->hwmode.crtc_vtotal * linedur_ns; + frame_size = crtc->hwmode.crtc_htotal * + crtc->hwmode.crtc_vtotal; + framedur_ns = (s64) div64_u64((u64) frame_size * 1000000000, + dotclock); } else DRM_ERROR("crtc %d: Can't calculate constants, dotclock = 0!\n", crtc->base.id); -- 1.7.7.3

1 2

Including drm-intel tree to linux-next
by Daniel Vetter 15 Feb '13

15 Feb '13

Hi Steven, Since about a year ago we've switched drm/i915 to buffer around 2 weeks worth of patches so that we can do decent QA before breaking everyone's tree when things land in Dave's drm-next. But that also means we'll miss out a bit in the integration testing -next provides, which did hurt a bit in recent efforts. Hence can you please include git://people.freedesktop.org/~danvet/drm-intel drm-intel-next-queued into linux-next? Probably best to merge it after drm-next. Note that drm-intel-next are the QA'ed chunks I send off to Dave. Also, any mailing lists I'm supposed to follow? And if possible please cc intel-gfx(a)lists.freedesktop.org besides dri-devel/lkml when conflicts with that tree pop up (you won't get moderation spam any more, we've fixed that up). Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

4 6

[PATCH v5 0/1] Add display-timing node parsing to exynos drm fimd
by Vikas Sajjan 15 Feb '13

15 Feb '13

Add display-timing node parsing to drm fimd and depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. changes since v4: - addressed comments from Paul Menzel <paulepanter(a)users.sourceforge.net>, to modify the commit message changes since v3: - addressed comments from Sean Paul <seanpaul(a)chromium.org>, to modify the return values and print messages. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev->dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma <r.sh.open(a)gmail.com>) changes since v1: - addressed comments from Sean Paul <seanpaul(a)chromium.org> Vikas Sajjan (1): video: drm: exynos: Add display-timing node parsing using video helper function drivers/gpu/drm/exynos/exynos_drm_fimd.c | 41 +++++++++++++++++++++++++++--- 1 file changed, 37 insertions(+), 4 deletions(-) -- 1.7.9.5

4 5

← Newer
1
...
54
55
56
57
58
59
60
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2013