dri-devel August 2012

dri-devel@lists.freedesktop.org

145 participants
811 discussions

[PATCH] nouveau: avoid excessive gart aperture for on-board cards
by Michele Ballabio 19 Aug '12

19 Aug '12

Commit d0f3c7e41d30859a638083654002b9b6faf7f67b ("drm/nouveau: give a slightly larger pci(e)gart aperture on all chipsets") removed a test: that caused an 8x increase in gart aperture, instead of a 2x one, for on-board cards >= NV_40. Signed-off-by: Michele Ballabio <barra_cuda(a)katamail.com> --- Hi, in Linux 3.5.x I experienced some crashes of the X server, and noticed from the boot that while the gart aperture in 3.4.x was 64MB, in 3.5.x became 512MB. So I came out with this quick patch: this seems to work, since X did not crash anymore (and I tried quite hard to), but I'm not sure if it is the right fix. drivers/gpu/drm/nouveau/nouveau_sgdma.c | 2 +- 1 file modificato, 1 inserzione(+). 1 rimozione(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c b/drivers/gpu/drm/nouveau/nouveau_sgdma.c index 38483a0..ebc27f7 100644 --- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c +++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c @@ -341,7 +341,7 @@ nouveau_sgdma_init(struct drm_device *dev) u32 aper_size, align; int ret; - if (dev_priv->card_type >= NV_40) + if (dev_priv->card_type >= NV_40 && pci_is_pcie(dev->pdev)) aper_size = 512 * 1024 * 1024; else aper_size = 128 * 1024 * 1024; -- 1.7.11.1

1 0

[PATCH] r600g: fix allocation of MSAA surfaces on r600-r700
by Marek Olšák 19 Aug '12

19 Aug '12

--- radeon/radeon_surface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c index 892dca6..98f4aaf 100644 --- a/radeon/radeon_surface.c +++ b/radeon/radeon_surface.c @@ -165,7 +165,7 @@ static void surf_minify(struct radeon_surface *surf, surf->level[level].nblk_z = ALIGN(surf->level[level].nblk_z, zalign); surf->level[level].offset = offset; - surf->level[level].pitch_bytes = surf->level[level].nblk_x * surf->bpe; + surf->level[level].pitch_bytes = surf->level[level].nblk_x * surf->bpe * surf->nsamples; surf->level[level].slice_size = surf->level[level].pitch_bytes * surf->level[level].nblk_y; surf->bo_size = offset + surf->level[level].slice_size * surf->level[level].nblk_z * surf->array_size; -- 1.7.9.5

2 1

[Bug 46181] New: No Brightness control-nouveau
by bugzilla-daemon＠bugzilla.kernel.org 19 Aug '12

19 Aug '12

https://bugzilla.kernel.org/show_bug.cgi?id=46181 Summary: No Brightness control-nouveau Product: Drivers Version: 2.5 Kernel Version: 3.4.9-1-ARCH 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: jujojujo_2003(a)yahoo.co.in Regression: No I completely have no brightness control on my laptop(M17 r3 3D verison). dmesg log is spammed with the following message every few seconds , [ 589.813022] Raw EDID: [ 589.813032] 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813037] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813041] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813045] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813050] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813054] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813058] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.813062] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 589.815666] Raw EDID: [ 589.815669] 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815673] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815677] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815682] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815686] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815690] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815695] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.815699] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 589.818304] Raw EDID: [ 589.818308] 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818312] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818316] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818321] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818325] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818329] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818333] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.818337] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 589.820946] Raw EDID: [ 589.820949] 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820953] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820958] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820962] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820966] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820970] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820975] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 589.820979] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc [ 589.820987] nouveau 0000:01:00.0: eDP-1: Ignoring invalid EDID block 1. -- 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 1

[Bug 53348] [855gm] GPU hang whilst playing Imperialism 2 under wine
by bugzilla-daemon＠freedesktop.org 18 Aug '12

18 Aug '12

https://bugs.freedesktop.org/show_bug.cgi?id=53348 Yunrui Hu <hyrathb(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hyrathb(a)gmail.com --- Comment #3 from Yunrui Hu <hyrathb(a)gmail.com> 2012-08-18 14:08:01 UTC --- (In reply to comment #2) > I can confirm this. > I suffer from the same problem with the same chip(i855).The terminal output and > dmesg show the same thing as Bruno's. > The only difference is the game.I haven't tried > Imperialism 2 or other games,but both Warcraft3 and Heroes of Might & Magic3 > can cause this problem. > Please let me know if I can help. -- 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 53348] [855gm] GPU hang whilst playing Imperialism 2 under wine
by bugzilla-daemon＠freedesktop.org 18 Aug '12

18 Aug '12

https://bugs.freedesktop.org/show_bug.cgi?id=53348 --- Comment #2 from Yunrui Hu <hyrathb(a)gmail.com> 2012-08-18 14:03:11 UTC --- I can confirm this. I suffer from the same problem with the same chip(i855).The terminal output and dmesg show the same thing as Bruno's. The only difference is the game.I don't know whether I haven't tried Imperialism 2 or other games,but both Warcraft3 and Heroes of Might & Magic3 can cause this problem. Please let me know if I can help. -- 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

[UDL] general protection fault in fb_deferred_io_mkwrite()
by Thomas Meyer 18 Aug '12

18 Aug '12

Hi, guilty driver is probably udl_fb.c any ideas? [ 42.890551] open /dev/fb1 user=1 fb_info=ffff880130e0a800 count=1 [ 42.890585] released /dev/fb1 user=1 count=0 [ 42.890702] open /dev/fb1 user=1 fb_info=ffff880130e0a800 count=1 [ 43.053034] type=1400 audit(1344698343.496:9): avc: denied { execmem } for pid=631 comm="java" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=process [ 43.093084] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [ 43.140051] [drm] write mode info 144 [ 43.140786] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 43.164482] asix 2-1.3:1.0: eth1: link down [ 44.791884] asix 2-1.3:1.0: eth1: link up, 100Mbps, full-duplex, lpa 0x41E1 [ 45.289464] general protection fault: 0000 [#1] [ 45.289512] CPU 0 [ 45.289529] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_usb_audio snd_usbmidi_lib snd_rawmidi udl syscopyarea sysfillrect sysimgblt asix uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev usbnet snd_seq_device drm_usb arc4 btusb iwlwifi bluetooth snd_hda_codec_hdmi acer_wmi joydev mac80211 snd_hda_codec_realtek cfg80211 acerhdf atl1c snd_hda_intel sparse_keymap pcspkr snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd rfkill soundcore wmi kvm_intel kvm ipv6 [last unloaded: scsi_wait_scan] [ 45.290003] [ 45.290003] Pid: 629, comm: X Not tainted 3.5.1 #3 Acer Aspire 1810T/JM11-MS [ 45.290003] RIP: 0010:[<ffffffff8123becc>] [<ffffffff8123becc>] fb_deferred_io_mkwrite+0xdc/0xf0 [ 45.290003] RSP: 0000:ffff880138e93c98 EFLAGS: 00010246 [ 45.290003] RAX: 7672645f6e6f6564 RBX: ffffea0004bd6180 RCX: 0000000000000036 [ 45.290003] RDX: ffff88013369b460 RSI: ffff880138e93cf8 RDI: ffff880130e0a800 [ 45.290003] RBP: ffff880138e93cb8 R08: 0c00000000000000 R09: a80012f586000000 [ 45.290003] R10: 57ffd70a7ebd6180 R11: 0000003ccd37a850 R12: ffff880130e0a800 [ 45.290003] R13: ffff88013369b448 R14: ffff88013369b440 R15: 0000000000000000 [ 45.290003] FS: 00007f981237a8c0(0000) GS:ffffffff8168a000(0000) knlGS:0000000000000000 [ 45.290003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 45.290003] CR2: 00007f9810821010 CR3: 000000012f191000 CR4: 00000000000407f0 [ 45.290003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 45.290003] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 45.290003] Process X (pid: 629, threadinfo ffff880138e92000, task ffff880130c16b50) [ 45.290003] Stack: [ 45.290003] ffff880130f37dc8 0000000000000001 ffff88013b2049c0 ffffea0004bd6180 [ 45.290003] ffff880138e93d48 ffffffff810b658c ffff880138e93d48 ffffffff810b740a [ 45.290003] ffff88012f183210 00007f9810821010 ffff880127c23420 0000000030c16b50 [ 45.290003] Call Trace: [ 45.290003] [<ffffffff810b658c>] __do_fault+0xbc/0x420 [ 45.290003] [<ffffffff810b740a>] ? do_wp_page.isra.77+0x2aa/0x640 [ 45.290003] [<ffffffff810b8acc>] handle_pte_fault+0x8c/0x7f0 [ 45.290003] [<ffffffff8103b3f0>] ? __send_signal.part.24+0x130/0x300 [ 45.290003] [<ffffffff810264aa>] ? pte_alloc_one+0x1a/0x40 [ 45.290003] [<ffffffff810b9948>] handle_mm_fault+0x208/0x2c0 [ 45.290003] [<ffffffff814c0543>] do_page_fault+0x143/0x490 [ 45.290003] [<ffffffff8104fe85>] ? check_preempt_curr+0x85/0xa0 [ 45.290003] [<ffffffff81052a2a>] ? __dequeue_entity+0x2a/0x50 [ 45.290003] [<ffffffff81052fee>] ? pick_next_task_fair+0x6e/0x180 [ 45.290003] [<ffffffff814bc6ad>] ? __schedule+0x22d/0x500 [ 45.290003] [<ffffffff814bd72f>] page_fault+0x1f/0x30 [ 45.290003] Code: 89 0a 4c 89 ef e8 35 fd 27 00 49 8b 36 49 8d bc 24 90 02 00 00 e8 95 66 e0 ff 5b b8 00 02 00 00 41 5c 41 5d 41 5e 5d c3 4c 89 e7 <ff> d0 e9 5e ff ff ff 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 [ 45.290003] RIP [<ffffffff8123becc>] fb_deferred_io_mkwrite+0xdc/0xf0 [ 45.290003] RSP <ffff880138e93c98> [ 45.316388] ---[ end trace d4732d5a0bf375fa ]--- [ 45.347642] released /dev/fb1 user=1 count=0 [ 45.454869] open /dev/fb1 user=1 fb_info=ffff880130e0a800 count=1 [ 45.454903] released /dev/fb1 user=1 count=0 [ 45.455020] open /dev/fb1 user=1 fb_info=ffff880130e0a800 count=1 [ 45.456389] [drm] write mode info 144 [ 45.631358] [drm] write mode info 144 [ 45.632075] general protection fault: 0000 [#2] [ 45.632121] CPU 0 [ 45.632139] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_usb_audio snd_usbmidi_lib snd_rawmidi udl syscopyarea sysfillrect sysimgblt asix uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev usbnet snd_seq_device drm_usb arc4 btusb iwlwifi bluetooth snd_hda_codec_hdmi acer_wmi joydev mac80211 snd_hda_codec_realtek cfg80211 acerhdf atl1c snd_hda_intel sparse_keymap pcspkr snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd rfkill soundcore wmi kvm_intel kvm ipv6 [last unloaded: scsi_wait_scan] [ 45.633336] [ 45.633336] Pid: 836, comm: X Tainted: G D 3.5.1 #3 Acer Aspire 1810T/JM11-MS [ 45.633336] RIP: 0010:[<ffffffff8123becc>] [<ffffffff8123becc>] fb_deferred_io_mkwrite+0xdc/0xf0 [ 45.633336] RSP: 0000:ffff880126559c98 EFLAGS: 00010246 [ 45.633336] RAX: 006f732e61786562 RBX: ffffea0004bd6180 RCX: 0000000000000036 [ 45.633336] RDX: ffff8801265482e0 RSI: ffff880126559cf8 RDI: ffff880130e0a800 [ 45.633336] RBP: ffff880126559cb8 R08: 0c00000000000000 R09: a80012f586000000 [ 45.633336] R10: 57ffd70a7ebd6180 R11: 0000003ccd37a850 R12: ffff880130e0a800 [ 45.633336] R13: ffff8801265482c8 R14: ffff8801265482c0 R15: 0000000000000000 [ 45.633336] FS: 00007f06d7a628c0(0000) GS:ffffffff8168a000(0000) knlGS:0000000000000000 [ 45.633336] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 45.633336] CR2: 00007f06d5f09010 CR3: 000000012f138000 CR4: 00000000000407f0 [ 45.633336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 45.633336] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 45.633336] Process X (pid: 836, threadinfo ffff880126558000, task ffff8801264dd290) [ 45.633336] Stack: [ 45.633336] ffff880127c64738 0000000000000001 ffff880138db5040 ffffea0004bd6180 [ 45.633336] ffff880126559d48 ffffffff810b658c ffff880126559d48 ffffffff810b740a [ 45.633336] ffff880126581210 00007f06d5f09010 ffff880126574578 00000000264dd290 [ 45.633336] Call Trace: [ 45.633336] [<ffffffff810b658c>] __do_fault+0xbc/0x420 [ 45.633336] [<ffffffff810b740a>] ? do_wp_page.isra.77+0x2aa/0x640 [ 45.633336] [<ffffffff810b8acc>] handle_pte_fault+0x8c/0x7f0 [ 45.633336] [<ffffffff8103b3f0>] ? __send_signal.part.24+0x130/0x300 [ 45.633336] [<ffffffff810264aa>] ? pte_alloc_one+0x1a/0x40 [ 45.633336] [<ffffffff810b9948>] handle_mm_fault+0x208/0x2c0 [ 45.633336] [<ffffffff814c0543>] do_page_fault+0x143/0x490 [ 45.633336] [<ffffffff8104fe85>] ? check_preempt_curr+0x85/0xa0 [ 45.633336] [<ffffffff81052a2a>] ? __dequeue_entity+0x2a/0x50 [ 45.633336] [<ffffffff81052fee>] ? pick_next_task_fair+0x6e/0x180 [ 45.633336] [<ffffffff814bc6ad>] ? __schedule+0x22d/0x500 [ 45.633336] [<ffffffff814bd72f>] page_fault+0x1f/0x30 [ 45.633336] Code: 89 0a 4c 89 ef e8 35 fd 27 00 49 8b 36 49 8d bc 24 90 02 00 00 e8 95 66 e0 ff 5b b8 00 02 00 00 41 5c 41 5d 41 5e 5d c3 4c 89 e7 <ff> d0 e9 5e ff ff ff 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 [ 45.633336] RIP [<ffffffff8123becc>] fb_deferred_io_mkwrite+0xdc/0xf0 [ 45.633336] RSP <ffff880126559c98> [ 45.711547] ---[ end trace d4732d5a0bf375fb ]--- [ 45.720961] released /dev/fb1 user=1 count=0 [ 45.756516] open /dev/fb1 user=1 fb_info=ffff880130e0a800 count=1 [ 45.756550] released /dev/fb1 user=1 count=0 [ 45.756632] open /dev/fb1 user=1 fb_info=ffff880130e0a800 count=1 [ 45.758195] [drm] write mode info 144 [ 45.994657] [drm] write mode info 144

2 2

[Bug 4804] endless loop in dri_utils.c
by bugzilla-daemon＠freedesktop.org 18 Aug '12

18 Aug '12

https://bugs.freedesktop.org/show_bug.cgi?id=4804 Matt Turner <mattst88(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #2 from Matt Turner <mattst88(a)gmail.com> 2012-08-18 05:26:04 UTC --- DRI-1 code is long dead. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[PATCH 0/7] drm/i915: IVB FDI B/C fixes and misc cleanups
by Keith Packard 17 Aug '12

17 Aug '12

This is the complete set of patches that yield a working 3-pipe mode setting configuration on my test machines. It does not make DPMS work, so I still need to figure that out. As the DPMS paths are almost entirely different from mode setting (whose crazy idea was that, anyway?), that may take a bit more time. I've managed to reproduce this bug with only two monitors just by forcing them onto FDI B/C, but only with 1920x1080 and larger modes: $ xrandr --output VGA1 --off --output DP1 --off $ xrandr --output VGA1 --auto --crtc 1 $ xrandr --output DP1 --auto --crtc 2 That works about 50% of the time on the original kernel. If it works, you can just try a couple of different modes to see if you can get it to fail. Just use reasonably large modes -- 640x480 has never failed for me. I'd love to know why $ xrandr --output DP1 --mode 1600x1200 --crtc 2 Finally, the X server has a terrible bug in the RandR code. It computes a desired initial configuration, and if that fails in any way, it refuses to start at all. So, if you connect three monitors that all require separate PLLs, then you get two monitors lit up, the third one fails and the X server aborts. Need to fix that so that if *any* monitors light up, the X server will keep going. *** The patches: *** [PATCH 1/7] drm/i915: Allow VGA on CRTC 2 Silly hold-over from the bad-old PLL sharing code. [PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge Here's the patch which rejects modes that the FDI B/C lane sharing hardware can't support. This only affects modes larger than 1920x1200 though as that mode and smaller all fit in two FDI lanes. I ran across this while testing with a 2560x1200 monitor. [PATCH 3/7] drm/i915: Delay between FDI link training tries. Clear This seems like a sensible change in the FDI link training code -- gives the FDI hardware time to adapt to changes in the signalling. But, as I've never seen FDI fail to train, I'm not sure it's useful. [PATCH 4/7] drm/i915: Check display_bpc against max_fdi_bpp after This mostly just cleans up some debug messages by moving various BPP computations around. "should" have no effect on the hardware. [PATCH 5/7] drm/i915: Pipe-C only configurations would not get SR Just happened across this obvious bug while reading through the driver. [PATCH 6/7] drm/i915: Disable FDI RX before FDI TX The specs don't say which order to do this in, but it doesn't make sense to do these in the current order. With this in place, I saw mode setting errors reduced quite a bit, but not gone. [PATCH 7/7] drm/i915: Merge FDI RX reg writes during training This may be the only patch necessary to get mode setting working on FDI-B/C, it ensures that error correction is always turned on during link training. The old code left error correction disabled as there was no posting read after setting that. I'm hoping this explains why the problem wasn't reliably reproducible -- the problem depended on how long the write waited to get to the hardware. I haven't done enough testing of this patch in isolation to know if this is true or not. -keith

3 17

DRM/V4L2 buffer sharing (was: Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org)
by Sylwester Nawrocki 17 Aug '12

17 Aug '12

Hi Laurent, On 08/15/2012 11:09 PM, Laurent Pinchart wrote: > On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote: >> On 08/15/2012 12:06 AM, Laurent Pinchart wrote: >>> On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote: >>>> On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote: >>>>> This one requires more testing: >>>>> >>>>> May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API >>>>> http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki >>>>> <s.nawrocki(a)samsung.com> >>>> >>>> Hmm, this is not valid any more. Tomasz just posted a new patch series >>>> that adds DMABUF importer and exporter feature altogether. >>>> >>>> [PATCHv8 00/26] Integration of videobuf2 with DMABUF >>>> >>>> I guess we need someone else to submit test patches for other H/W than >>>> just Samsung SoCs. I'm not sure if we've got enough resources to port >>>> this to other hardware. We have been using these features internally for >>>> some time already. It's been 2 kernel releases and I can see only Ack >>>> tags from Laurent on Tomasz's patch series, hence it seems there is no >>>> wide interest in DMABUF support in V4L2 and this patch series is probably >>>> going to stay in a fridge for another few kernel releases. >>> >>> What would be required to push it to v3.7 ? >> >> Mauro requested more test coverage on that, which is understood since this >> is a fairly important API enhancement and the V4L2 video overlay API >> replacement. >> >> We need DMABUF support added at some webcam driver and a DRM driver with >> prime support (or some V4L2 output driver), I guess it would be best to >> have that in a PC environment. It looks like i915/radeon/nouveau drivers >> already have prime support. > > uvcvideo has recently been moved to videobuf2, using vb2_vmalloc. I can easily > test that, except that I have no idea how to export buffers on the i915 side > when X is running. Have you looked into that ? All right. Yes, I'm also not sure yet how to do it. I tried it on a laptop with i915 driver, but in the running system drmModeGetResources() just fails with EPERM. I've CCed dri-devel, so hopefully someone can shed some light on this. >> The DRM driver could be an exporter of buffers that would be passed to the >> webcam driver. >> >> And except the kernel patches we would need a test application, similar >> to that one: >> http://git.infradead.org/users/kmpark/public-apps/blob/a7e755629a74a7ac13788 >> 2032a0f7b2480fa1490:/v4l2-drm-example/dmabuf-sharing.c >> >> I haven't been closely following the DMABUF APIs development, I think >> Tomasz could provide more details on that. >> >> It's likely I'll get around and prepare a test case as outlined above in >> coming days. Anyway, it would be appreciated if someone else could give this >> patch series a try. > > I've previously tested the patches on Renesas hardware, exporting buffers on > the FBDEV side and importing them on the V4L2 side. We thus have test results > for two different platforms, albeit all ARM-based. I guess ARM is where those APIs will be used mostly, still it would be helpful to have easier reproducible test environment. -- Thanks, Sylwester

3 2

[PATCH] drm/radeon: avoid turning off spread spectrum for used pll
by j.glisse＠gmail.com 17 Aug '12

17 Aug '12

From: Jerome Glisse <jglisse(a)redhat.com> If spread spectrum is enabled and in use for a given pll we should not turn it off as it will lead to turning off display for crtc that use the pll (this behavior was observed on chelsea edp). Signed-off-by: Jerome Glisse <jglisse(a)redhat.com> --- drivers/gpu/drm/radeon/atombios_crtc.c | 25 +++++++++++++++++++++---- 1 files changed, 21 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index c6fcb5b..cb18813 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -444,11 +444,28 @@ union atom_enable_ss { static void atombios_crtc_program_ss(struct radeon_device *rdev, int enable, int pll_id, + int crtc_id, struct radeon_atom_ss *ss) { + unsigned i; int index = GetIndexIntoMasterTable(COMMAND, EnableSpreadSpectrumOnPPLL); union atom_enable_ss args; + if (!enable) { + for (i = 0; i < 6; i++) { + if (rdev->mode_info.crtcs[i] && + rdev->mode_info.crtcs[i]->enabled && + i != crtc_id && + pll_id == rdev->mode_info.crtcs[i]->pll_id) { + /* one other crtc is using this pll don't turn + * off spread spectrum as it might turn off + * display on active crtc + */ + return; + } + } + } + memset(&args, 0, sizeof(args)); if (ASIC_IS_DCE5(rdev)) { @@ -1028,7 +1045,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, struct drm_display_mode radeon_compute_pll_legacy(pll, adjusted_clock, &pll_clock, &fb_div, &frac_fb_div, &ref_div, &post_div); - atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id, &ss); + atombios_crtc_program_ss(rdev, ATOM_DISABLE, radeon_crtc->pll_id, radeon_crtc->crtc_id, &ss); atombios_crtc_program_pll(crtc, radeon_crtc->crtc_id, radeon_crtc->pll_id, encoder_mode, radeon_encoder->encoder_id, mode->clock, @@ -1051,7 +1068,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, struct drm_display_mode ss.step = step_size; } - atombios_crtc_program_ss(rdev, ATOM_ENABLE, radeon_crtc->pll_id, &ss); + atombios_crtc_program_ss(rdev, ATOM_ENABLE, radeon_crtc->pll_id, radeon_crtc->crtc_id, &ss); } } @@ -1572,11 +1589,11 @@ void radeon_atom_disp_eng_pll_init(struct radeon_device *rdev) ASIC_INTERNAL_SS_ON_DCPLL, rdev->clock.default_dispclk); if (ss_enabled) - atombios_crtc_program_ss(rdev, ATOM_DISABLE, ATOM_DCPLL, &ss); + atombios_crtc_program_ss(rdev, ATOM_DISABLE, ATOM_DCPLL, -1, &ss); /* XXX: DCE5, make sure voltage, dispclk is high enough */ atombios_crtc_set_disp_eng_pll(rdev, rdev->clock.default_dispclk); if (ss_enabled) - atombios_crtc_program_ss(rdev, ATOM_ENABLE, ATOM_DCPLL, &ss); + atombios_crtc_program_ss(rdev, ATOM_ENABLE, ATOM_DCPLL, -1, &ss); } } -- 1.7.1

3 3

← Newer
1
...
59
60
61
62
63
64
65
...
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