[Bug 34495] Selecting objects in Blender 2.56 slow with gallium r600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=34495 --- Comment #65 from Lars G --- Tried the new branch now. Selecting/moving is nice and fast in blender, but somehow i get no textures displayed on the objects. This is with radeon hd 6320 (e-450 apu) built against llvm-git, using blender-git. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek wrote: > On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek wrote: >> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek wrote: >>> On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson >>> wrote: On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote: > On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson > wrote: > > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: > >> After a logout from my "BROKEN" Unity-2D session - the login-screen > >> for LightDM seems to be OK. > >> Then entering my Unity-2D desktop is OK - no screen corruptions. > > > > What hardware and display do you have? > > It's a Samsung ultrabook with SandyBridge CPU. > > [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD > Graphics 3000 using LVDS. > - Sedat - > > P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. Did that make a difference? It shouldn't if the error is occuring before X even starts... >>> >>> NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my >>> Xorg.log :-). >>> >>> As said logging out of Unity-2D and entering LightDM greeter - screen is >>> fine. >>> Starting again a Unity-2D session - no screen corruption, too. >>> >>> - Sedat - >> >> Some more testing: >> >> [1] With my X stack: >> >> FIRST BAD: next-20130812 >> LAST GOOD: next-20130809 >> >> [2] With Ubuntu's X stack: >> >> next-20130813 is OK (Xorg.log attached) >> > > drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack > no problems). > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit commit 5456fe3882812aba251886e36fe55bfefb8e8829 Author: Chris Wilson Date: Thu Aug 8 14:41:07 2013 +0100 drm/i915: Allocate LLC ringbuffers from stolen As stolen objects now behave identically (wrt to default LLC cacheing) as their normal system counterparts, we no longer have to differentiate our usage for ringbuffers. So allocate them from stolen on SNB+ as well. Signed-off-by: Chris Wilson Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers See also attached files! - Sedat - git bisect start # good: [d4e4ab86bcba5a72779c43dc1459f71fea3d89c8] Linux 3.11-rc5 git bisect good d4e4ab86bcba5a72779c43dc1459f71fea3d89c8 # bad: [5b79c8eb1b61d499ca70cc3e4e2ced7822209876] Merge branch 'drm-intel-nightly' into 3.11.0-rc5-iniza-small git bisect bad 5b79c8eb1b61d499ca70cc3e4e2ced7822209876 # good: [36f2d1f151215c48d902947d64b86dc5ab277e19] drm/i915: rip out legacy encoder->mode_set callback git bisect good 36f2d1f151215c48d902947d64b86dc5ab277e19 # good: [c35426d2bc25b242ee2a9a7a1d62634be1e86bb0] drm/i915: Split plane watermark parameters into a separate struct git bisect good c35426d2bc25b242ee2a9a7a1d62634be1e86bb0 # good: [32c913e4369ce7bd1d16a9b6983f7b8975c13f5a] Merge tag 'drm-intel-next-2013-07-26-fixed' of git://people.freedesktop.org/~danvet/drm-intel into drm-next git bisect good 32c913e4369ce7bd1d16a9b6983f7b8975c13f5a # good: [d46f1c3f1372e3a72fab97c60480aa4a1084387f] drm/i915: Allow the GPU to cache stolen memory git bisect good d46f1c3f1372e3a72fab97c60480aa4a1084387f # bad: [b8a1868b10bb4fe7fb7d283da5d56064b1a189f4] drm/i915: Allow the user to set bo into the DISPLAY cache domain git bisect bad b8a1868b10bb4fe7fb7d283da5d56064b1a189f4 # bad: [a698a20e8cf9a946b0a491cb58ff96c0b4332d08] i915: Fix SDVO potentially turning off randomly git bisect bad a698a20e8cf9a946b0a491cb58ff96c0b4332d08 # bad: [8d2d9e6517d95d2bfa35dfa650330cf0b591d7e1] drm/i915: Only do a chipset flush after a clflush git bisect bad 8d2d9e6517d95d2bfa35dfa650330cf0b591d7e1 # bad: [5456fe3882812aba251886e36fe55bfefb8e8829] drm/i915: Allocate LLC ringbuffers from stolen git bisect bad 5456fe3882812aba251886e36fe55bfefb8e8829 # first bad commit: [5456fe3882812aba251886e36fe55bfefb8e8829] drm/i915: Allocate LLC ringbuffers from stolen commit 5456fe3882812aba251886e36fe55bfefb8e8829 Author: Chris Wilson Date: Thu Aug 8 14:41:07 2013 +0100 drm/i915: Allocate LLC ringbuffers from stolen As stolen objects now behave identically (wrt to default LLC cacheing) as their normal system counterparts, we no longer have to differentiate our usage for ringbuffers. So allocate them from stolen on SNB+ as well. Signed-off-by: Chris Wilson Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) commit 5456fe3882812aba251886e36fe55bfefb8e8829 Author: Chris Wilson Date: Thu Aug 8 14:41:07 2013 +0100 drm/i915: Allocate LLC ringbuffers from stolen As stolen objects now behave identically (wrt to default LLC cacheing) as
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek wrote: > On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek wrote: >> On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek wrote: >>> On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek wrote: On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson wrote: > On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote: >> On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson >> wrote: >> > On Tue, Aug 13, 2013 at 11:35:53AM +0200, Sedat Dilek wrote: >> >> After a logout from my "BROKEN" Unity-2D session - the login-screen >> >> for LightDM seems to be OK. >> >> Then entering my Unity-2D desktop is OK - no screen corruptions. >> > >> > What hardware and display do you have? >> >> It's a Samsung ultrabook with SandyBridge CPU. >> >> [ 333.291] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD >> Graphics 3000 > > using LVDS. > >> - Sedat - >> >> P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. > > Did that make a difference? It shouldn't if the error is occuring before > X even starts... NO, was just confused not seeing "GT2" (HD-3000 was new to me) in my Xorg.log :-). As said logging out of Unity-2D and entering LightDM greeter - screen is fine. Starting again a Unity-2D session - no screen corruption, too. - Sedat - >>> >>> Some more testing: >>> >>> [1] With my X stack: >>> >>> FIRST BAD: next-20130812 >>> LAST GOOD: next-20130809 >>> >>> [2] With Ubuntu's X stack: >>> >>> next-20130813 is OK (Xorg.log attached) >>> >> >> drm-intel-nightly is also BAD with my X stack (with Ubuntu's X stack >> no problems). >> > > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: > > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit > commit 5456fe3882812aba251886e36fe55bfefb8e8829 > Author: Chris Wilson > Date: Thu Aug 8 14:41:07 2013 +0100 > > drm/i915: Allocate LLC ringbuffers from stolen > > As stolen objects now behave identically (wrt to default LLC cacheing) > as their normal system counterparts, we no longer have to differentiate > our usage for ringbuffers. So allocate them from stolen on SNB+ as well. > > Signed-off-by: Chris Wilson > Reviewed-by: Ville Syrjälä > Signed-off-by: Daniel Vetter > > :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers > > See also attached files! > With the attached revert-patch my system is OK (with my customized X stack). - Sedat - 0001-Revert-drm-i915-Allocate-LLC-ringbuffers-from-stolen.patch Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson wrote: > On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote: >> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek wrote: >> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: >> > >> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit >> > commit 5456fe3882812aba251886e36fe55bfefb8e8829 >> > Author: Chris Wilson >> > Date: Thu Aug 8 14:41:07 2013 +0100 >> > >> > drm/i915: Allocate LLC ringbuffers from stolen >> > >> > As stolen objects now behave identically (wrt to default LLC cacheing) >> > as their normal system counterparts, we no longer have to differentiate >> > our usage for ringbuffers. So allocate them from stolen on SNB+ as >> > well. >> > >> > Signed-off-by: Chris Wilson >> > Reviewed-by: Ville Syrjälä >> > Signed-off-by: Daniel Vetter >> > >> > :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 >> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers >> > >> > See also attached files! >> > >> >> With the attached revert-patch my system is OK (with my customized X stack). > > No indication of a GPU hang? I'm puzzled as to how this ends up with the > scanout being misread. > > cat /sys/kernel/debug/dri/0/i915_gem_stolen > cat /sys/kernel/debug/dri/0/i915_gem_framebuffer > > would be interesting. With revert-patch applied: $ sudo cat /sys/kernel/debug/dri/0/i915_gem_stolen Stolen: 88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) Total 1 objects, 4227072 bytes, 4227072 GTT size $ sudo cat /sys/kernel/debug/dri/0/i915_gem_framebuffer fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 88007f6f5080: pXg 5120KiB 36 02 124873 124873 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) (blitter ring) - Sedat - ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Fwd: Re: kernel reporting of radeon/workqueue on 3.10.6 build
FYI: the error snapshout below was generated on a vanilla linux 3.10.6 kernel build. I have not bisected the kernel to find the appropiate delta (not git capable on principal machine) Original Message Subject: Re: kernel reporting of radeon/workqueue on 3.10.6 build Date: Tue, 13 Aug 2013 14:42:33 +0200 From: Christian König To: Markham Dickey CC: Hi, you should probably send this message to the dri-devel (dri-devel@lists.freedesktop.org) list or open up a bugreport on freedesktop.org. Have you already tried to bisect this problem? Regards, Christian. Am 12.08.2013 22:56, schrieb Markham Dickey: > Hello > I extracted your names from a kernel log of updates applied to 3.10.6 > Note some problem first emerged in the 3.10.5 distro > > Here is a excised log > > > > > [ 10.949651] agpgart: Detected VIA PT800 chipset > [ 10.958558] agpgart-via :00:00.0: AGP aperture is 128M @ 0xd000 > [ 13.345422] [drm] Initialized drm 1.1.0 20060810 > > [ 13.928083] [drm] radeon kernel modesetting enabled. > [ 13.929277] [drm] initializing kernel modesetting (RV100 > 0x1002:0x5159 0x1092:0x0280). > [ 13.929308] [drm] register mmio base: 0xE100 > [ 13.929310] [drm] register mmio size: 65536 > [ 13.929597] agpgart-via :00:00.0: AGP 2.0 bridge > [ 13.929614] agpgart-via :00:00.0: putting AGP V2 device into 4x mode > [ 13.929670] radeon :01:00.0: putting AGP V2 device into 4x mode > [ 13.929676] radeon :01:00.0: GTT: 128M 0xD000 - 0xD7FF > [ 13.929686] radeon :01:00.0: VRAM: 128M 0xD800 - > 0xDFFF (32M used) > [ 13.929954] [drm] Detected VRAM RAM=128M, BAR=128M > [ 13.929961] [drm] RAM width 64bits DDR > [ 13.930716] [TTM] Zone kernel: Available graphics memory: 447492 kiB > [ 13.930720] [TTM] Zone highmem: Available graphics memory: 517096 kiB > [ 13.930723] [TTM] Initializing pool allocator > [ 13.930769] [drm] radeon: 32M of VRAM memory ready > [ 13.930774] [drm] radeon: 128M of GTT memory ready. > [ 13.952452] radeon :01:00.0: WB disabled > [ 13.952464] radeon :01:00.0: fence driver on ring 0 use gpu addr > 0xd000 and cpu addr 0xf801 > [ 13.952470] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). > [ 13.952473] [drm] Driver supports precise vblank timestamp query. > [ 13.952481] [ cut here ] > [ 13.952493] WARNING: at kernel/workqueue.c:1365 > __queue_work+0x146/0x183() > [ 13.952496] Modules linked in: radeon(+) fbcon tileblit font bitblit > softcursor snd_pcm_oss snd_mixer_oss ttm drm_kms_helper drm fb fbdev > ath5k(+) snd_pcm hwmon ath snd_page_alloc snd_mpu401_uart snd_seq_oss > mac80211 backlight snd_seq_midi i2c_algo_bit cfg80211 snd_rawmidi > snd_seq_midi_event snd_seq snd_timer snd_seq_device psmouse i2c_viapro > snd soundcore cfbcopyarea parport_pc cfbimgblt rfkill cfbfillrect > via_agp parport i2c_core microcode binfmt_misc > [ 13.952548] CPU: 0 PID: 500 Comm: modprobe Not tainted 3.10.6-rad #1 > [ 13.952551] Hardware name: VIA Technologies, Inc. > P4X400-8235/P4X400-8235, BIOS 6.00 PG 11/19/2003 > [ 13.952555] f550bb3c c12b781c f550bb64 c10210c6 > c139bb89 c139cc1a > [ 13.952562] 0555 c1030ef3 c1030ef3 f6d7a500 f680f500 f691f0ec > f550bb74 c10210fa > [ 13.952568] 0009 f550bba4 c1030ef3 c14c5ba0 f550bbb0 > c10225d4 c14dccb8 > [ 13.952576] Call Trace: > [ 13.952586] [] dump_stack+0x16/0x18 > [ 13.952593] [] warn_slowpath_common+0x59/0x70 > [ 13.952598] [] ? __queue_work+0x146/0x183 > [ 13.952603] [] ? __queue_work+0x146/0x183 > [ 13.952608] [] warn_slowpath_null+0x1d/0x1f > [ 13.952613] [] __queue_work+0x146/0x183 > [ 13.952618] [] ? console_unlock+0x2ea/0x2f2 > [ 13.952623] [] queue_work_on+0x1a/0x28 > [ 13.952676] [] r100_irq_process+0x174/0x1ed [radeon] > [ 13.952714] [] radeon_driver_irq_preinstall_kms+0x8c/0x90 > [radeon] > [ 13.952735] [] drm_irq_install+0xc4/0x1d0 [drm] > [ 13.952751] [] ? drm_vblank_init+0x190/0x1cf [drm] > [ 13.952788] [] radeon_irq_kms_init+0xed/0x178 [radeon] > [ 13.952826] [] r100_startup+0x1a2/0x1e4 [radeon] > [ 13.952864] [] r100_init+0x2dc/0x336 [radeon] > [ 13.952895] [] radeon_device_init+0x4fc/0x5eb [radeon] > [ 13.952924] [] ? cail_mc_write+0x17/0x17 [radeon] > [ 13.952955] [] radeon_driver_load_kms+0x85/0xdd [radeon] > [ 13.952972] [] drm_get_pci_dev+0x13a/0x233 [drm] > [ 13.953002] [] radeon_pci_probe+0x7d/0x8b [radeon] > [ 13.953010] [] pci_device_probe+0x56/0x8e > [ 13.953019] [] driver_probe_device+0x83/0x188 > [ 13.953024] [] ? pci_match_device+0x72/0x77 > [ 13.953029] [] __driver_attach+0x47/0x63 > [ 13.953035] [] bus_for_each_dev+0x3c/0x66 > [ 13.953039] [] driver_attach+0x17/0x19 > [ 13.953044] [] ? driver_probe_device+0x188/0x188 > [ 13.953049] [] bus_add_driver+0xbf/0x1d0 > [ 13.953055] [] driver_register
Radeon: DPM suspend/hibernete error
Hello, I'm testing linux-3.11-rc5 with my radeon graphics card HD 6470M. Finally hibernate and suspend mode started working without hangs. But now I see this error message in dmesg before notebook it hibernated or suspended: [drm:rv770_stop_dpm] *ERROR* Could not force DPM to low. Is this ERROR message big problem? Can you look at it? Note that suspend/resume and hibernation working fine. Thank you very much for DPM & UVD support! -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek wrote: > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson > wrote: >> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote: >>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek wrote: >>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: >>> > >>> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit >>> > commit 5456fe3882812aba251886e36fe55bfefb8e8829 >>> > Author: Chris Wilson >>> > Date: Thu Aug 8 14:41:07 2013 +0100 >>> > >>> > drm/i915: Allocate LLC ringbuffers from stolen >>> > >>> > As stolen objects now behave identically (wrt to default LLC cacheing) >>> > as their normal system counterparts, we no longer have to >>> > differentiate >>> > our usage for ringbuffers. So allocate them from stolen on SNB+ as >>> > well. >>> > >>> > Signed-off-by: Chris Wilson >>> > Reviewed-by: Ville Syrjälä >>> > Signed-off-by: Daniel Vetter >>> > >>> > :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 >>> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers >>> > >>> > See also attached files! >>> > >>> >>> With the attached revert-patch my system is OK (with my customized X stack). >> >> No indication of a GPU hang? I'm puzzled as to how this ends up with the >> scanout being misread. >> >> cat /sys/kernel/debug/dri/0/i915_gem_stolen >> cat /sys/kernel/debug/dri/0/i915_gem_framebuffer >> >> would be interesting. > > With revert-patch applied: > > $ sudo cat /sys/kernel/debug/dri/0/i915_gem_stolen > Stolen: >88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) > (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) > (stolen: ) (p mappable) > Total 1 objects, 4227072 bytes, 4227072 GTT size > > $ sudo cat /sys/kernel/debug/dri/0/i915_gem_framebuffer > fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj > 88007f6f5200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) > (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) > (stolen: ) (p mappable) > user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj > 88007f6f5080: pXg 5120KiB 36 02 124873 124873 0 uncached dirty > (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, > size: 0050) (p mappable) (blitter ring) > Attached both outputs with GOOD and BAD (BROKEN) kernel. - Sedat - fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880074492e40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 880074492840: pXg 5120KiB 36 02 158126 158126 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) (blitter ring) fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880073995200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: 0006) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 8800736d8e00: pXg 5120KiB 36 02 -737 -737 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 0047a000, size: 0050) (p mappable) (blitter ring) Stolen: 880074492e40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: ) (p mappable) Total 1 objects, 4227072 bytes, 4227072 GTT size Stolen: 880073995c80: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 1000, size: 0002) (stolen: ) (p mappable) 880073995800: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00023000, size: 0002) (stolen: 0002) (p mappable) 880073995500: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00044000, size: 0002) (stolen: 0004) (p mappable) 880073995200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 00072000, size: 00408000) (stolen: 0006) (p mappable) Total 4 objects, 4620288 bytes, 4620288 GTT size ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 7:13 PM, Chris Wilson wrote: > On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote: >> On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek wrote: >> > On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson >> > wrote: >> >> On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote: >> >>> On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek >> >>> wrote: >> >>> > I have bisected the issue on Linux v3.11-rc5 + drm-intel-nightly: >> >>> > >> >>> > 5456fe3882812aba251886e36fe55bfefb8e8829 is the first bad commit >> >>> > commit 5456fe3882812aba251886e36fe55bfefb8e8829 >> >>> > Author: Chris Wilson >> >>> > Date: Thu Aug 8 14:41:07 2013 +0100 >> >>> > >> >>> > drm/i915: Allocate LLC ringbuffers from stolen >> >>> > >> >>> > As stolen objects now behave identically (wrt to default LLC >> >>> > cacheing) >> >>> > as their normal system counterparts, we no longer have to >> >>> > differentiate >> >>> > our usage for ringbuffers. So allocate them from stolen on SNB+ as >> >>> > well. >> >>> > >> >>> > Signed-off-by: Chris Wilson >> >>> > Reviewed-by: Ville Syrjälä >> >>> > Signed-off-by: Daniel Vetter >> >>> > >> >>> > :04 04 de063a052f39095f4d2f51b49caef9f827df41e8 >> >>> > 1c819aa5501a9fcc9912a5c7c037c71b9b9e9a6b M drivers >> >>> > >> >>> > See also attached files! >> >>> > >> >>> >> >>> With the attached revert-patch my system is OK (with my customized X >> >>> stack). >> >> >> >> No indication of a GPU hang? I'm puzzled as to how this ends up with the >> >> scanout being misread. >> >> >> >> cat /sys/kernel/debug/dri/0/i915_gem_stolen >> >> cat /sys/kernel/debug/dri/0/i915_gem_framebuffer >> >> >> >> would be interesting. > >> Attached both outputs with GOOD and BAD (BROKEN) kernel. > > ggtt offset is the same for both setups, the only difference between the > two is the location of fbcon in stolen memory. > > Can you please attach the output of intel_reg_dumper for good/bad? It's > a long shot... > > Speaking of long shots, try this (slightly different to the earlier patch): > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index a21f935..37ad772 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -1850,6 +1850,9 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev, > BUG(); > } > > + if (obj->stolen && INTEL_INFO(dev)->gen >= 6) > + alignment = 256 * 1024; > + > /* Note that the w/a also requires 64 PTE of padding following the > * bo. We currently fill all unused PTE with the shadow page and so > * we should always have valid PTE following the scanout preventing > > > -- Files attached. - Sedat - fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 88010c54fe40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 0008, size: 00408000) (stolen: 0006) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 88010c54fcc0: pXg 5120KiB 36 02 -591 -591 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 00488000, size: 0050) (p mappable) (blitter ring) fbcon size: 1366 x 768, depth 24, 32 bpp, refcount 2, obj 880073fca200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 0008, size: 00408000) (stolen: ) (p mappable) user size: 1366 x 768, depth 24, 32 bpp, refcount 3, obj 880118928b40: pXg 5120KiB 36 02 -12 -12 0 uncached dirty (name: 3) (pinned x 1) (display) (fence: 0) (ggtt offset: 00488000, size: 0050) (p mappable) (blitter ring) Stolen: 880072c39c80: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 1000, size: 0002) (stolen: ) (p mappable) 880072c39800: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00023000, size: 0002) (stolen: 0002) (p mappable) 880072c39500: p g 128KiB 40 40 0 0 0 snooped or LLC dirty (pinned x 1) (ggtt offset: 00044000, size: 0002) (stolen: 0004) (p mappable) 88010c54fe40: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 0008, size: 00408000) (stolen: 0006) (p mappable) Total 4 objects, 4620288 bytes, 4620288 GTT size Stolen: 880073fca200: p g 4128KiB 77 00 0 0 0 uncached (name: 1) (pinned x 1) (display) (ggtt offset: 0008, size: 00408000) (stolen: ) (p mappable) Total 1 objects, 4227072 bytes, 4227072 GTT size ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Remove drm_mode_validate_clocks
This function is unused.
Signed-off-by: Stéphane Marchesin
Reviewed-by: David Herrmann
---
drivers/gpu/drm/drm_modes.c | 37 -
include/drm/drm_crtc.h | 3 ---
2 files changed, 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a6729bf..504a602 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -923,43 +923,6 @@ void drm_mode_validate_size(struct drm_device *dev,
EXPORT_SYMBOL(drm_mode_validate_size);
/**
- * drm_mode_validate_clocks - validate modes against clock limits
- * @dev: DRM device
- * @mode_list: list of modes to check
- * @min: minimum clock rate array
- * @max: maximum clock rate array
- * @n_ranges: number of clock ranges (size of arrays)
- *
- * LOCKING:
- * Caller must hold a lock protecting @mode_list.
- *
- * Some code may need to check a mode list against the clock limits of the
- * device in question. This function walks the mode list, testing to make
- * sure each mode falls within a given range (defined by @min and @max
- * arrays) and sets @mode->status as needed.
- */
-void drm_mode_validate_clocks(struct drm_device *dev,
- struct list_head *mode_list,
- int *min, int *max, int n_ranges)
-{
- struct drm_display_mode *mode;
- int i;
-
- list_for_each_entry(mode, mode_list, head) {
- bool good = false;
- for (i = 0; i < n_ranges; i++) {
- if (mode->clock >= min[i] && mode->clock <= max[i]) {
- good = true;
- break;
- }
- }
- if (!good)
- mode->status = MODE_CLOCK_RANGE;
- }
-}
-EXPORT_SYMBOL(drm_mode_validate_clocks);
-
-/**
* drm_mode_prune_invalid - remove invalid modes from mode list
* @dev: DRM device
* @mode_list: list of modes to check
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index fa12a2f..32e0820 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -930,9 +930,6 @@ extern void drm_mode_list_concat(struct list_head *head,
extern void drm_mode_validate_size(struct drm_device *dev,
struct list_head *mode_list,
int maxX, int maxY, int maxPitch);
-extern void drm_mode_validate_clocks(struct drm_device *dev,
-struct list_head *mode_list,
-int *min, int *max, int n_ranges);
extern void drm_mode_prune_invalid(struct drm_device *dev,
struct list_head *mode_list, bool verbose);
extern void drm_mode_sort(struct list_head *mode_list);
--
1.8.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
>> wrote:
>> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> >> Files attached.
>> >
>> > Can you also please attach a full dmesg so I can check for anything
>> > unusual?
>> >
>
> Nothing scarred me on a couple of read throughs.
>
> What happens if you try:
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 112c5e1..9828d9b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev, u32
> size)
> return NULL;
>
> ret = drm_mm_insert_node(&dev_priv->mm.stolen, stolen, size,
> -4096, DRM_MM_SEARCH_DEFAULT);
> +1024*1024, DRM_MM_SEARCH_DEFAULT);
> if (ret) {
> kfree(stolen);
> return NULL;
>
> --
Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
from the top).
On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
So-to-say 3/4 "blind".
- Sedat -
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson wrote:
> On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson
>> wrote:
>> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
>> >> wrote:
>> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> >> >> Files attached.
>> >> >
>> >> > Can you also please attach a full dmesg so I can check for anything
>> >> > unusual?
>> >> >
>> >
>> > Nothing scarred me on a couple of read throughs.
>> >
>> > What happens if you try:
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > index 112c5e1..9828d9b 100644
>> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device *dev,
>> > u32 size)
>> > return NULL;
>> >
>> > ret = drm_mm_insert_node(&dev_priv->mm.stolen, stolen, size,
>> > -4096, DRM_MM_SEARCH_DEFAULT);
>> > +1024*1024, DRM_MM_SEARCH_DEFAULT);
>> > if (ret) {
>> > kfree(stolen);
>> > return NULL;
>> >
>> > --
>>
>> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
>> from the top).
>> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
>> So-to-say 3/4 "blind".
>
> That implies that the scanout is always reading from the base of stolen.
> Can you grab intel_reg_dumper so that I can check what values the
> transcoder is set to?
>
> At the moment, I am guessing that the display never sees the updated
> surface offset and so persists with the value programmed by the BIOS -
> which will be 0 and set to the base of stolen memory in the GTT. A
> drm.debug=6 dmesg would help here as well.
>
> If you forced a mode change, I think that too would restore the output.
With which kernel? Vanilla next-20130813? With any of your patches?
- Sedat -
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 10:33 PM, Sedat Dilek wrote:
> On Tue, Aug 13, 2013 at 10:25 PM, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 10:20 PM, Chris Wilson
>> wrote:
>>> On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson
wrote:
> On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
>> On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson
>> wrote:
>> > On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
>> >> On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson
>> >> wrote:
>> >> > On Tue, Aug 13, 2013 at 07:53:25PM +0200, Sedat Dilek wrote:
>> >> >> Files attached.
>> >> >
>> >> > Can you also please attach a full dmesg so I can check for anything
>> >> > unusual?
>> >> >
>> >
>> > Nothing scarred me on a couple of read throughs.
>> >
>> > What happens if you try:
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > index 112c5e1..9828d9b 100644
>> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> > @@ -284,7 +284,7 @@ i915_gem_object_create_stolen(struct drm_device
>> > *dev, u32 size)
>> > return NULL;
>> >
>> > ret = drm_mm_insert_node(&dev_priv->mm.stolen, stolen, size,
>> > -4096, DRM_MM_SEARCH_DEFAULT);
>> > +1024*1024, DRM_MM_SEARCH_DEFAULT);
>> > if (ret) {
>> > kfree(stolen);
>> > return NULL;
>> >
>> > --
>>
>> Now, 2/3 till 3/4 of my LightDM greeter screen is a black bar (seen
>> from the top).
>> On the bottom I can read "Ubuntu 12.04 LTS" with the known background.
>> So-to-say 3/4 "blind".
>
> That implies that the scanout is always reading from the base of stolen.
> Can you grab intel_reg_dumper so that I can check what values the
> transcoder is set to?
>
> At the moment, I am guessing that the display never sees the updated
> surface offset and so persists with the value programmed by the BIOS -
> which will be 0 and set to the base of stolen memory in the GTT. A
> drm.debug=6 dmesg would help here as well.
>
> If you forced a mode change, I think that too would restore the output.
With which kernel? Vanilla next-20130813? With any of your patches?
>>>
>>> Any but the working one ;-)
>>
>> Damn Gmail, they switched again the UI, f***.
>>
>> This is d-i-n with Revert "drm/i915: Allocate LLC ringbuffers from
>> stolen" <--- "working one" (no screen corruptions).
>>
>> - Sedat -
>
> Vanilla next-20130813 after 1st login and logout-unity2d-plus-relogin-lightdm.
> The diff might be interesting as the 2nd login makes the issue go away.
>
intel_reg_dumper output attached.
- Sedat -
PGETBL_CTL: 0x
GEN6_INSTDONE_1: 0xfffe
GEN6_INSTDONE_2: 0x
CPU_VGACNTRL: 0x8000 (disabled)
DIGITAL_PORT_HOTPLUG_CNTRL: 0x
RR_HW_CTL: 0x (low 0, high 0)
FDI_PLL_BIOS_0: 0x
FDI_PLL_BIOS_1: 0x
FDI_PLL_BIOS_2: 0x
DISPLAY_PORT_PLL_BIOS_0: 0x
DISPLAY_PORT_PLL_BIOS_1: 0x
DISPLAY_PORT_PLL_BIOS_2: 0x
FDI_PLL_FREQ_CTL: 0x
PIPEACONF: 0xc000 (enabled, active, pf-pd, rotate 0,
8bpc)
HTOTAL_A: 0x05cd0555 (1366 active, 1486 total)
HBLANK_A: 0x05cd0555 (1366 start, 1486 end)
HSYNC_A: 0x05a50585 (1414 start, 1446 end)
VTOTAL_A: 0x031702ff (768 active, 792 total)
VBLANK_A: 0x031702ff (768 start, 792 end)
VSYNC_A: 0x03060301 (770 start, 775 end)
VSYNCSHIFT_A: 0x
PIPEASRC: 0x055502ff (1366, 768)
PIPEA_DATA_M1: 0x7e32468a (TU 64, val 0x32468a 3294858)
PIPEA_DATA_N1: 0x0040 (val 0x40 4194304)
PIPEA_DATA_M2: 0x (TU 1, val 0x0 0)
PIPEA_DATA_N2: 0x (val 0x0 0)
PIPEA_LINK_M1: 0x00021845 (val 0x21845 137285)
PIPEA_LINK_N1: 0x0008 (val 0x8 524288)
PIPEA_LINK_M2: 0x (val 0x0 0)
PIPEA_LINK_N2: 0x (val 0x0 0)
DSPACNTR: 0xd8004400 (enabled)
DSPABASE: 0x
DSPASTRIDE: 0x1600 (88)
DSPASURF: 0x0047a000
DSPATILEOFF: 0x (0, 0)
PIPEBCONF: 0x (disabled, inactive, pf-pd, rotate
0, 8bp
[PATCH] i915: Add a Kconfig option to turn on i915.preliminary_hw_support by default
When building kernels for a preliminary hardware target, having to add a kernel command-line option can prove inconvenient. Add a Kconfig option that changes the default of this option to 1. Signed-off-by: Josh Triplett --- I dropped the indication of the default in the module parameter documentation, but I could also change it to show the default for the current kernel via ifdef. drivers/gpu/drm/Kconfig | 9 + drivers/gpu/drm/i915/i915_drv.c | 4 ++-- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index a7c54c8..35d57ed 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -168,6 +168,15 @@ config DRM_I915_KMS the driver to bind to PCI devices, which precludes loading things like intelfb. +config DRM_I915_PRELIMINARY_HW_SUPPORT + bool "Enable preliminary support for prerelease Intel hardware by default" + depends on DRM_I915 + help + Choose this option if you have prerelease Intel hardware and want the + i915 driver to support it by default. You can enable such support at + runtime with the module option i915.preliminary_hw_support=1; this + option changes the default for that module option. + config DRM_MGA tristate "Matrox g200/g400" depends on DRM && PCI diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 45b3c03..594e06c 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -118,10 +118,10 @@ module_param_named(i915_enable_ppgtt, i915_enable_ppgtt, int, 0600); MODULE_PARM_DESC(i915_enable_ppgtt, "Enable PPGTT (default: true)"); -unsigned int i915_preliminary_hw_support __read_mostly = 0; +unsigned int i915_preliminary_hw_support __read_mostly = IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT); module_param_named(preliminary_hw_support, i915_preliminary_hw_support, int, 0600); MODULE_PARM_DESC(preliminary_hw_support, - "Enable preliminary hardware support. (default: false)"); + "Enable preliminary hardware support."); int i915_disable_power_well __read_mostly = 1; module_param_named(disable_power_well, i915_disable_power_well, int, 0600); -- 1.8.4.rc2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 00/19] Common Display Framework
On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart wrote: > Hi everybody, > > Here's the third RFC of the Common Display Framework. > > I won't repeat all the background information from the versions one and two > here, you can read it at http://lwn.net/Articles/512363/ and > http://lwn.net/Articles/526965/. > > This RFC isn't final. Given the high interest in CDF and the urgent tasks that > kept delaying the next version of the patch set, I've decided to release v3 > before completing all parts of the implementation. Known missing items are > > - documentation: kerneldoc and this cover letter should provide basic > information, more extensive documentation will likely make it to v4. > > - pipeline configuration and control: generic code to configure and control > display pipelines (in a nutshell, translating high-level mode setting and > DPMS calls to low-level entity operations) is missing. Video and stream > control operations have been carried over from v2, but will need to be > revised for v4. > > - DSI support: I still have no DSI hardware I can easily test the code on. tbh, I kinda think that DSI and bridge chips are the things we should focus on first.. that seems what is most important for current and new hardware. Back-filling to handle older/simpler panels can be done later. > > Special thanks go to > > - Renesas for inviting me to LinuxCon Japan 2013 where I had the opportunity > to validate the CDF v3 concepts with Alexandre Courbot (NVidia) and Tomasz > Figa (Samsung). > > - Tomi Valkeinen (TI) for taking the time to deeply brainstorm v3 with me. > > - Linaro for inviting me to Linaro Connect Europe 2013, the discussions we had > there greatly helped moving CDF forward. > > - And of course all the developers who showed interest in CDF and spent time > sharing ideas, reviewing patches and testing code. > > I have to confess I was a bit lost and discouraged after all the CDF-related > meetings during which we have discussed how to move from v2 to v3. With every > meeting I was hoping to run the implementation through use cases of various > interesting parties and narrow down the scope of the huge fuzzy beast that CDF > was. With every meeting the scope actually broadened, with no clear path at > sight anywhere. > > Earlier this year I was about to drop one of the requirements on which I had > based CDF v2: sharing drivers between DRM/KMS and V4L2. With only two HDMI > transmitters as use cases for that feature (with only out-of-tree drivers so > far), I just thought the involved completely wasn't worth it and that I should > implement CDF v3 as a DRM/KMS-only helper framework. However, a seemingly > unrelated discussion with Xilinx developers showed me that hybrid SoC-FPGA > platforms such as the Xilinx Zynq 7000 have a larger library of IP cores that > can be used in camera capture pipelines and in display pipelines. The two use > cases suddenly became tens or even hundreds of use cases that I couldn't > ignore anymore. Hmm, I'm still not really convinced ;-) Or maybe, put another way, I still think we should still optimize for the common case. I mean I'm sure you *can* design hw that has an LVDS->DP bridge in the capture path, and if you had something like an FPGA where that was cheap to do maybe you even would (for fun). But if in the real world, there are only one or two cases of actual hw using the same bridge in a capture pipeline which is normally used in display pipelines, then duplicating some small bit of code for that abnormal case if it makes things easier for the common case, seems like a reasonable trade-off to me. I mean, take a DSI panel driver, for example.. anything but a trivial panel driver, you are going to want to expose some custom properties on the connector for controlling non-standard features. So you end up with both cdf_foo for the common part, and drm_foo for gluing in the properties. And now these two parts which otherwise would be one, end up having to stay in sync merged through different trees, etc. It seems a lot like making my life more difficult for a fairly hypothetical gain ;-) Or, take an hdmi or DP bridge. To use any of the common infrastructure/helpers in drm, you end up implementing a generic interface, where both the producer and consumer is inside drm. Which just seems a bit pointless and extra hoops to jump through. Especially when we discover that we need to extend/enhance the common interface outside of drm to make it work. (I'm thinking of display_entity_control_ops::get_modes() here, but I'm sure there are more examples.) And I think we'll run into similar issues with display_entity_control_ops::set_state(), since the on<->off sequencing can get hairy when the upstream/downstream entity is fed a clk by the downstream/upstream entity. And similarly, I think we'll go through a few revisions of DSI panel/bus params before we have everything that everyone needs. (Don't get me wrong.. if we were starting from scratch
Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
On Fri, Aug 9, 2013 at 1:14 PM, Laurent Pinchart
wrote:
> MIPI DBI is a configurable-width parallel display bus that transmits
> commands and data.
>
> Add a new DBI Linux bus type that implements the usual bus
> infrastructure (including devices and drivers (un)registration and
> matching, and bus configuration and access functions).
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/video/display/Kconfig| 8 ++
> drivers/video/display/Makefile | 1 +
> drivers/video/display/mipi-dbi-bus.c | 234
> +++
> include/video/display.h | 4 +
> include/video/mipi-dbi-bus.h | 125 +++
> 5 files changed, 372 insertions(+)
> create mode 100644 drivers/video/display/mipi-dbi-bus.c
> create mode 100644 include/video/mipi-dbi-bus.h
>
> diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
> index 1d533e7..f7532c1 100644
> --- a/drivers/video/display/Kconfig
> +++ b/drivers/video/display/Kconfig
> @@ -2,3 +2,11 @@ menuconfig DISPLAY_CORE
> tristate "Display Core"
> ---help---
> Support common display framework for graphics devices.
> +
> +if DISPLAY_CORE
> +
> +config DISPLAY_MIPI_DBI
> + tristate
> + default n
> +
> +endif # DISPLAY_CORE
> diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
> index b907aad..59022d2 100644
> --- a/drivers/video/display/Makefile
> +++ b/drivers/video/display/Makefile
> @@ -1,3 +1,4 @@
> display-y := display-core.o \
>display-notifier.o
> obj-$(CONFIG_DISPLAY_CORE) += display.o
> +obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
> diff --git a/drivers/video/display/mipi-dbi-bus.c
> b/drivers/video/display/mipi-dbi-bus.c
> new file mode 100644
> index 000..791fb4d
> --- /dev/null
> +++ b/drivers/video/display/mipi-dbi-bus.c
> @@ -0,0 +1,234 @@
> +/*
> + * MIPI DBI Bus
> + *
> + * Copyright (C) 2012 Renesas Solutions Corp.
> + *
> + * Contacts: Laurent Pinchart
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/*
> -
> + * Bus operations
> + */
> +
> +int mipi_dbi_set_data_width(struct mipi_dbi_device *dev, unsigned int width)
> +{
> + if (width != 8 && width != 16)
> + return -EINVAL;
> +
> + dev->data_width = width;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(mipi_dbi_set_data_width);
> +
> +int mipi_dbi_write_command(struct mipi_dbi_device *dev, u16 cmd)
> +{
> + return dev->bus->ops->write_command(dev->bus, dev, cmd);
> +}
> +EXPORT_SYMBOL_GPL(mipi_dbi_write_command);
> +
> +int mipi_dbi_write_data(struct mipi_dbi_device *dev, const u8 *data,
> + size_t len)
> +{
> + return dev->bus->ops->write_data(dev->bus, dev, data, len);
> +}
> +EXPORT_SYMBOL_GPL(mipi_dbi_write_data);
> +
> +int mipi_dbi_read_data(struct mipi_dbi_device *dev, u8 *data, size_t len)
> +{
> + return dev->bus->ops->read_data(dev->bus, dev, data, len);
> +}
> +EXPORT_SYMBOL_GPL(mipi_dbi_read_data);
> +
> +/*
> -
> + * Bus type
> + */
> +
> +static const struct mipi_dbi_device_id *
> +mipi_dbi_match_id(const struct mipi_dbi_device_id *id,
> + struct mipi_dbi_device *dev)
> +{
> + while (id->name[0]) {
> + if (strcmp(dev->name, id->name) == 0) {
> + dev->id_entry = id;
> + return id;
> + }
> + id++;
> + }
> + return NULL;
> +}
> +
> +static int mipi_dbi_match(struct device *_dev, struct device_driver *_drv)
> +{
> + struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
> + struct mipi_dbi_driver *drv = to_mipi_dbi_driver(_drv);
> +
> + if (drv->id_table)
> + return mipi_dbi_match_id(drv->id_table, dev) != NULL;
> +
> + return (strcmp(dev->name, _drv->name) == 0);
> +}
> +
> +static ssize_t modalias_show(struct device *_dev, struct device_attribute *a,
> +char *buf)
> +{
> + struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
> + int len = snprintf(buf, PAGE_SIZE, MIPI_DBI_MODULE_PREFIX "%s\n",
> + dev->name);
> +
> + return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
> +}
> +
> +static struct device_attribute mipi_dbi_dev_attrs[] = {
> + __ATTR_RO(modalias),
> + __ATTR_NULL,
> +};
> +
> +static int mipi_dbi_uevent(struct device *_dev, struct kobj_uevent_env *env)
> +{
>
[PATCH 3/4] drm: WARN when removing unallocated node
The conditional is usually a recoverable driver bug, and so WARNing, and preventing the drm_mm code from doing potential damage (BUG) is desirable. This issue was hit and fixed twice while developing the i915 multiple address space code. The first fix is the patch just before this, and is hit on an not frequently occuring error path. Another was fixed during patch iteration, so it's hard to see from the patch: commit c6cfb325677ea6305fb19acf3a4d14ea267f923e Author: Ben Widawsky Date: Fri Jul 5 14:41:06 2013 -0700 drm/i915: Embed drm_mm_node in i915 gem obj >From the intel-gfx mailing list, we discussed this: References: <20130705191235.ga3...@bwidawsk.net> Cc: Dave Airlie CC: Acked-by: Chris Wilson Signed-off-by: Ben Widawsky --- drivers/gpu/drm/drm_mm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c index aded1e1..af93cc5 100644 --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -254,6 +254,9 @@ void drm_mm_remove_node(struct drm_mm_node *node) struct drm_mm *mm = node->mm; struct drm_mm_node *prev_node; + if (WARN_ON(!node->allocated)) + return; + BUG_ON(node->scanned_block || node->scanned_prev_free || node->scanned_next_free); -- 1.8.3.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60741] When using the 3.10 kernel, System boot is blocked on the udev stage because of loading the radeon DRM module
https://bugzilla.kernel.org/show_bug.cgi?id=60741 --- Comment #5 from Eastern Heart --- (In reply to Alex Deucher from comment #4) > Might be a duplicate of bug 60674. Can you try the patch on that bug? If > that doesn't help, can you bisect? I cannot try now... And I cannot even boot, not incorrect display! I said, my boot paused when start the kernel radeon module. Sorry. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60741] When using the 3.10 kernel, System boot is blocked on the udev stage because of loading the radeon DRM module
https://bugzilla.kernel.org/show_bug.cgi?id=60741 --- Comment #6 from Alex Deucher --- (In reply to Eastern Heart from comment #5) > I cannot try now... And I cannot even boot, not incorrect display! > I said, my boot paused when start the kernel radeon module. > Sorry. The patch is still be relevant, you may just have different symptoms on your system. Without the patch garbage gets written to certain registers which may cause the card to hang or cause display problems, or nothing at all depending on what registers are written to. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60741] When using the 3.10 kernel, System boot is blocked on the udev stage because of loading the radeon DRM module
https://bugzilla.kernel.org/show_bug.cgi?id=60741 --- Comment #7 from Eastern Heart --- (In reply to Alex Deucher from comment #6) > (In reply to Eastern Heart from comment #5) > > I cannot try now... And I cannot even boot, not incorrect display! > > I said, my boot paused when start the kernel radeon module. > > Sorry. > > The patch is still be relevant, you may just have different symptoms on your > system. Without the patch garbage gets written to certain registers which > may cause the card to hang or cause display problems, or nothing at all > depending on what registers are written to. Although I haven't apply this patch, can I ask: will this patch be merged to linux-3.10.7? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60741] When using the 3.10 kernel, System boot is blocked on the udev stage because of loading the radeon DRM module
https://bugzilla.kernel.org/show_bug.cgi?id=60741 --- Comment #8 from Alex Deucher --- (In reply to Eastern Heart from comment #7) > > Although I haven't apply this patch, can I ask: will this patch be merged to > linux-3.10.7? It should make it's way to 3.10 eventually. I'm not sure which 3.10.x version it will end up in. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67876] linux v4.11-rc1 many drm:radeon_ttm_backend_bind ERROR failed to bind 2025 pages issued during boot
https://bugs.freedesktop.org/show_bug.cgi?id=67876 --- Comment #4 from jim.cro...@gmail.com --- So Ive apparently got bad rlc firmware from last Dec: [jimc@groucho ~]$ sum radeon-fw/* /lib/firmware/radeon/CEDAR_* | sort 05888 3 /lib/firmware/radeon/CEDAR_rlc.bin 23436 3 radeon-fw/CEDAR_rlc.bin 3591324 /lib/firmware/radeon/CEDAR_smc.bin 3591324 radeon-fw/CEDAR_smc.bin 45275 6 /lib/firmware/radeon/CEDAR_me.bin 45275 6 radeon-fw/CEDAR_me.bin 55341 5 /lib/firmware/radeon/CEDAR_pfp.bin 55341 5 radeon-fw/CEDAR_pfp.bin [jimc@groucho ~]$ ll /lib/firmware/radeon/CEDAR_* -rw-r--r--. 1 root root 5504 Dec 23 2012 /lib/firmware/radeon/CEDAR_me.bin -rw-r--r--. 1 root root 4480 Dec 23 2012 /lib/firmware/radeon/CEDAR_pfp.bin -rw-r--r--. 1 root root 3072 Dec 23 2012 /lib/firmware/radeon/CEDAR_rlc.bin -rw-rw-r--. 1 root root 23888 Aug 7 15:18 /lib/firmware/radeon/CEDAR_smc.bin The odd errors I saw now have a "usual suspect", I'll reboot with rc5 but still missing fw to see what bootlog looks like, then update that fw, and reboot again. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm: exynos: hdmi: Add dt support for hdmiphy settings
As I mentioned already on internal messenger, you first may need discuss
with Rahul Sharma who is preparing hdmiphy patch set.
The patch set will move all hdmiphy related codes from hdmi to hdmiphy
driver. So we may need a separated hdmiphy node, not in hdmi node. And it'd
better to move the hdmiphy config data to the hdmiphy driver.
Thanks,
Inki Dae
2013/8/13 Shirish S
> This patch adds dt support to hdmiphy config settings
> as it is board specific and depends on the signal pattern
> of board.
>
> Signed-off-by: Shirish S
> ---
> .../devicetree/bindings/video/exynos_hdmi.txt | 18 +-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 191
> +++-
> 2 files changed, 80 insertions(+), 129 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 323983b..fb8a643 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -12,7 +12,11 @@ Required properties:
> a) phandle of the gpio controller node.
> b) pin number within the gpio controller.
> c) optional flags and pull up/down.
> -
> +- hdmiphy_confs: following information about the hdmiphy conf settings.
> +a) "nr_confs" specifies the number of pixel clocks supported.
> + b) "confX: confX" specifies the phy configuration settings,
> + "clock-frequency" specifies the pixel clock
> + "conf" specifies the setting for the corresponding pixel
> clock
> Example:
>
> hdmi {
> @@ -20,4 +24,16 @@ Example:
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 1>;
> + hdmiphy_confs {
> + nr_confs = <1>;
> + conf0: conf0 {
> + clock-frequency = <2520>;
> + conf = /bits/ 8 <
> + 0x01 0x51 0x2A 0x75 0x40 0x01 0x00
> 0x08
> + 0x82 0x80 0xfc 0xd8 0x45 0xa0 0xac
> 0x80
> + 0x08 0x80 0x11 0x04 0x02 0x22 0x44
> 0x86
> + 0x54 0xf4 0x24 0x00 0x00 0x00 0x01
> 0x80
> + >;
> + };
> + }
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2f5c694..cb929ff 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -179,6 +179,11 @@ struct hdmi_conf_regs {
> } conf;
> };
>
> +struct hdmiphy_config {
> + int pixel_clock;
> + u8 conf[32];
> +};
> +
> struct hdmi_context {
> struct device *dev;
> struct drm_device *drm_dev;
> @@ -199,16 +204,14 @@ struct hdmi_context {
>
> struct hdmi_resources res;
>
> + struct hdmiphy_config *confs;
> + int nr_confs;
> +
> int hpd_gpio;
>
> enum hdmi_type type;
> };
>
> -struct hdmiphy_config {
> - int pixel_clock;
> - u8 conf[32];
> -};
> -
> /* list of phy config settings */
> static const struct hdmiphy_config hdmiphy_v13_configs[] = {
> {
> @@ -258,126 +261,6 @@ static const struct hdmiphy_config
> hdmiphy_v13_configs[] = {
> },
> };
>
> -static const struct hdmiphy_config hdmiphy_v14_configs[] = {
> - {
> - .pixel_clock = 2520,
> - .conf = {
> - 0x01, 0x51, 0x2A, 0x75, 0x40, 0x01, 0x00, 0x08,
> - 0x82, 0x80, 0xfc, 0xd8, 0x45, 0xa0, 0xac, 0x80,
> - 0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> - 0x54, 0xf4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> - },
> - },
> - {
> - .pixel_clock = 2700,
> - .conf = {
> - 0x01, 0xd1, 0x22, 0x51, 0x40, 0x08, 0xfc, 0x20,
> - 0x98, 0xa0, 0xcb, 0xd8, 0x45, 0xa0, 0xac, 0x80,
> - 0x06, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> - 0x54, 0xe4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> - },
> - },
> - {
> - .pixel_clock = 27027000,
> - .conf = {
> - 0x01, 0xd1, 0x2d, 0x72, 0x40, 0x64, 0x12, 0x08,
> - 0x43, 0xa0, 0x0e, 0xd9, 0x45, 0xa0, 0xac, 0x80,
> - 0x08, 0x80, 0x11, 0x04, 0x02, 0x22, 0x44, 0x86,
> - 0x54, 0xe3, 0x24, 0x00, 0x00, 0x00, 0x01, 0x00,
> - },
> - },
> - {
> - .pixel_clock = 3600,
> - .conf = {
> - 0x01, 0x51,
Re: [PATCH 1/3] drm/edid: add a helper function to extract the speaker allocation data block
On Tue, Aug 13, 2013 at 05:01:38PM -0400, Alex Deucher wrote:
> This adds a helper function to extract the speaker allocation
> data block from the EDID. This data block describes what speakers
> are present on the display device.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_edid.c | 50
> ++
> include/drm/drm_edid.h | 1 +
> 2 files changed, 51 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 70fc133..bc16c80 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2735,6 +2735,56 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
> **sads)
> EXPORT_SYMBOL(drm_edid_to_sad);
>
> /**
> + * drm_edid_to_speaker_allocation - extracts Speaker Allocation Data Blocks
> from EDID
> + * @edid: EDID to parse
> + * @sadb: pointer to the speaker block
> + *
> + * Looks for CEA EDID block and extracts the Speaker Allocation Data Block
> from it.
> + *
> + * Return number of found Speaker Allocation Blocks or negative number on
> error.
> + */
> +int drm_edid_to_speaker_allocation(struct edid *edid, u8 *sadb)
> +{
> + int count = 0;
> + int i, start, end, dbl;
> + u8 *cea;
Can be const.
> +
> + cea = drm_find_cea_extension(edid);
> + if (!cea) {
> + DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
> + return -ENOENT;
> + }
> +
> + if (cea_revision(cea) < 3) {
> + DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
> + return -ENOTSUPP;
> + }
> +
> + if (cea_db_offsets(cea, &start, &end)) {
> + DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
> + return -EPROTO;
> + }
> +
> + for_each_cea_db(cea, i, start, end) {
> + u8 *db = &cea[i];
Also const.
> +
> + if (cea_db_tag(db) == SPEAKER_BLOCK) {
> + dbl = cea_db_payload_len(db);
> +
> + /* Speaker Allocation Data Block */
> + if (dbl >= 1) {
CEA-861-E says the length must be exactly 3. Maybe we should be
strict with this check?
Also the second payload byte also contains three valid bits. Do
we not care about those speakers?
> + *sadb = db[1];
> + count = 1;
> + break;
> + }
> + }
> + }
> +
> + return count;
> +}
> +EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
> +
> +/**
> * drm_av_sync_delay - HDMI/DP sink audio-video sync delay in millisecond
> * @connector: connector associated with the HDMI/DP sink
> * @mode: the display mode
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index fc481fc..22d7985 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -259,6 +259,7 @@ struct hdmi_avi_infoframe;
>
> void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
> int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
> +int drm_edid_to_speaker_allocation(struct edid *edid, u8 *sadb);
> int drm_av_sync_delay(struct drm_connector *connector,
> struct drm_display_mode *mode);
> struct drm_connector *drm_select_eld(struct drm_encoder *encoder,
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nvc0-/ltcg: fix ltcg memory initialization after suspend
Some registers were not initialized in init, this causes them to be
uninitialized after suspend.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c | 35 ++---
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c
b/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c
index 01da47bda..61e9a9b 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c
@@ -30,8 +30,9 @@ struct nvc0_ltcg_priv {
struct nouveau_ltcg base;
u32 part_nr;
u32 subp_nr;
- struct nouveau_mm tags;
u32 num_tags;
+ u32 tag_base;
+ struct nouveau_mm tags;
struct nouveau_mm_node *tag_ram;
};
@@ -117,10 +118,6 @@ nvc0_ltcg_init_tag_ram(struct nouveau_fb *pfb, struct
nvc0_ltcg_priv *priv)
u32 tag_size, tag_margin, tag_align;
int ret;
- nv_wr32(priv, 0x17e8d8, priv->part_nr);
- if (nv_device(pfb)->card_type >= NV_E0)
- nv_wr32(priv, 0x17e000, priv->part_nr);
-
/* tags for 1/4 of VRAM should be enough (8192/4 per GiB of VRAM) */
priv->num_tags = (pfb->ram->size >> 17) / 4;
if (priv->num_tags > (1 << 17))
@@ -152,7 +149,7 @@ nvc0_ltcg_init_tag_ram(struct nouveau_fb *pfb, struct
nvc0_ltcg_priv *priv)
tag_base += tag_align - 1;
ret = do_div(tag_base, tag_align);
- nv_wr32(priv, 0x17e8d4, tag_base);
+ priv->tag_base = tag_base;
}
ret = nouveau_mm_init(&priv->tags, 0, priv->num_tags, 1);
@@ -182,8 +179,6 @@ nvc0_ltcg_ctor(struct nouveau_object *parent, struct
nouveau_object *engine,
}
priv->subp_nr = nv_rd32(priv, 0x17e8dc) >> 28;
- nv_mask(priv, 0x17e820, 0x0010, 0x); /* INTR_EN &= ~0x10 */
-
ret = nvc0_ltcg_init_tag_ram(pfb, priv);
if (ret)
return ret;
@@ -209,13 +204,35 @@ nvc0_ltcg_dtor(struct nouveau_object *object)
nouveau_ltcg_destroy(ltcg);
}
+static int
+nvc0_ltcg_init(struct nouveau_object *object)
+{
+ struct nouveau_ltcg *ltcg = (struct nouveau_ltcg *)object;
+ struct nvc0_ltcg_priv *priv = (struct nvc0_ltcg_priv *)ltcg;
+ int ret;
+
+ ret = nouveau_ltcg_init(ltcg);
+ if (ret)
+ return ret;
+
+ nv_mask(priv, 0x17e820, 0x0010, 0x); /* INTR_EN &= ~0x10 */
+
+ nv_wr32(priv, 0x17e8d8, priv->part_nr);
+ if (nv_device(ltcg)->card_type >= NV_E0)
+ nv_wr32(priv, 0x17e000, priv->part_nr);
+
+ nv_wr32(priv, 0x17e8d4, priv->tag_base);
+
+ return 0;
+}
+
struct nouveau_oclass
nvc0_ltcg_oclass = {
.handle = NV_SUBDEV(LTCG, 0xc0),
.ofuncs = &(struct nouveau_ofuncs) {
.ctor = nvc0_ltcg_ctor,
.dtor = nvc0_ltcg_dtor,
- .init = _nouveau_ltcg_init,
+ .init = nvc0_ltcg_init,
.fini = _nouveau_ltcg_fini,
},
};
--
1.8.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68085] Xorg crash in do_winsys_init
https://bugs.freedesktop.org/show_bug.cgi?id=68085 --- Comment #2 from Michel Dänzer --- Looks like swrast_dri.so is picking up driDriverAPI from radeonsi_dri.so. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/4] drm: WARN when removing unallocated node
On Tue, Aug 13, 2013 at 06:09:08PM -0700, Ben Widawsky wrote: > The conditional is usually a recoverable driver bug, and so WARNing, and > preventing the drm_mm code from doing potential damage (BUG) is > desirable. > > This issue was hit and fixed twice while developing the i915 multiple > address space code. The first fix is the patch just before this, and is > hit on an not frequently occuring error path. Another was fixed during > patch iteration, so it's hard to see from the patch: > > commit c6cfb325677ea6305fb19acf3a4d14ea267f923e > Author: Ben Widawsky > Date: Fri Jul 5 14:41:06 2013 -0700 > > drm/i915: Embed drm_mm_node in i915 gem obj > > From the intel-gfx mailing list, we discussed this: > References: <20130705191235.ga3...@bwidawsk.net> > > Cc: Dave Airlie > CC: > Acked-by: Chris Wilson > Signed-off-by: Ben Widawsky Patches 2&3 of this series are merged to dinq, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67790] error message on suspend and hibernate: *ERROR* Could not force DPM to low
https://bugs.freedesktop.org/show_bug.cgi?id=67790 Pali Rohár changed: What|Removed |Added Summary|error message on suspend: |error message on suspend |*ERROR* Could not force DPM |and hibernate: *ERROR* |to low |Could not force DPM to low --- Comment #1 from Pali Rohár --- I see same error message in dmesg with kernel 3.11-rc5 when my notebook is suspending or hibernating. But suspend and hibernate working fine. I have Radeon HD 6470M card. [drm:rv770_stop_dpm] *ERROR* Could not force DPM to low. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/12] drm: Add a helper to forge HDMI vendor infoframes
More typo fallout:
On Wednesday 14 August 2013 00:17:27 Damien Lespiau wrote:
> This can then be used by DRM drivers to setup their vendor infoframes.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_edid.c | 36
> include/drm/drm_edid.h | 4
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9a07a33..83e1202 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3262,3 +3262,39 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
> hdmi_avi_infoframe *frame,
> return 0;
> }
> EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
> +
> +/**
> + * drm_hdmi_vendor_infoframe_from_display_mode() - fill an HDMI infoframe
> with
> + * data from a DRM display mode
> + * @frame: HDMI vendor infoframe
> + * @mode: DRM display mode
> + *
> + * Note that there's is a need to send HDMI vendor infoframes only when
> using a
> + * 4k or stereoscopic 3D mode. So when giving any other mode as input this
> + * function will return -EINVAL, error that can be safely ignored.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int
> +drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_hdmi_infoframe
> *frame,
> + const struct drm_display_mode *mode)
> +{
> + int err;
> + u8 vic;
> +
> + if (!frame || !mode)
> + return -EINVAL;
> +
> + vic = drm_match_hmdi_mode(mode);
Should be hdmi again.
> + if (!vic)
> + return -EINVAL;
> +
> + err = hdmi_hdmi_infoframe_init(frame);
> + if (err < 0)
> + return err;
> +
> + frame->vic = vic;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_hdmi_vendor_infoframe_from_display_mode);
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: HDMI 4k support v2
On Wednesday 14 August 2013 00:17:16 Damien Lespiau wrote: > Following up the first instance of this series: > http://lists.freedesktop.org/archives/dri-devel/2013-August/043125.html > > Here is a v2 with Ville's review pass and a few additions: > - Alternate clock modes for 4k resolutions > - HDMI vendor specific infoframe support in drivers/video/hdmi.c > - Enabling of those vendor specific infoframes in the i915 driver > > Along the way, a tegra patch was needed for a small consolidation of the code > packing vendor specific infoframes. This patch has only been compile-tested. > > On Intel, it's possible to read back the programmed infoframe buffers with > intel-gpu-tools' intel_infoframe and this gives: > > Vendor InfoFrame: > - frequency: every vsync > - raw: > f4050181 000c0347 0320 > > 004c > > - vendor Id: 0x000c03 (HDMI) > - video format: 0x001 > - HDMI VIC: 3 > > after a $ xrandr --output HDMI1 --mode 3840x2160 -r 24 > > With the typos fixed, feel free to add: Reviewed-by: Simon Farnsworth -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com signature.asc Description: This is a digitally signed message part. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/12] drm/edid: Fix add_cea_modes() style issues
On Wed, Aug 14, 2013 at 12:17:18AM +0100, Damien Lespiau wrote:
> A few styles issues have crept in here, fix them before touching this
> code again.
>
> v2: constify arguments that can be (Ville Syrjälä)
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_edid.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e014785..9e9b6ed 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2301,7 +2301,7 @@ add_detailed_modes(struct drm_connector *connector,
> struct edid *edid,
> /*
> * Search EDID for CEA extension block.
> */
> -static u8 *drm_find_cea_extension(struct edid *edid)
> +static u8 *drm_find_cea_extension(const struct edid *edid)
This guy still casts away the const internally. Not sure if something
will complain about that. So maybe just drop this bit for now.
A long time ago I posted a big contify everything in drm_edid.c patch,
and it did in a way that didn't ad new warnings even w/ -Wcast-qual.
Maybe I should resurrect it.
> {
> u8 *edid_ext = NULL;
> int i;
> @@ -2441,10 +2441,11 @@ add_alternate_cea_modes(struct drm_connector
> *connector, struct edid *edid)
> }
>
> static int
> -do_cea_modes (struct drm_connector *connector, u8 *db, u8 len)
> +do_cea_modes(struct drm_connector *connector, const u8 *db, u8 len)
> {
> struct drm_device *dev = connector->dev;
> - u8 * mode, cea_mode;
> + const u8 *mode;
> + u8 cea_mode;
> int modes = 0;
>
> for (mode = db; mode < db + len; mode++) {
> @@ -2499,10 +2500,10 @@ cea_db_offsets(const u8 *cea, int *start, int *end)
> for ((i) = (start); (i) < (end) && (i) +
> cea_db_payload_len(&(cea)[(i)]) < (end); (i) +=
> cea_db_payload_len(&(cea)[(i)]) + 1)
>
> static int
> -add_cea_modes(struct drm_connector *connector, struct edid *edid)
> +add_cea_modes(struct drm_connector *connector, const struct edid *edid)
> {
> - u8 * cea = drm_find_cea_extension(edid);
> - u8 * db, dbl;
> + u8 *cea = drm_find_cea_extension(edid);
> + u8 *db, dbl;
cea and db could be const here.
> int modes = 0;
>
> if (cea && cea_revision(cea) >= 3) {
> @@ -2516,7 +2517,7 @@ add_cea_modes(struct drm_connector *connector, struct
> edid *edid)
> dbl = cea_db_payload_len(db);
>
> if (cea_db_tag(db) == VIDEO_BLOCK)
> - modes += do_cea_modes (connector, db+1, dbl);
> + modes += do_cea_modes(connector, db + 1, dbl);
> }
> }
>
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/12] drm/edid: Parse the HDMI CEA block and look for 4k modes
Minor typo - feel free to ignore:
On Wednesday 14 August 2013 00:17:19 Damien Lespiau wrote:
> HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.
>
> With this commit, we now parse this block and expose the 4k modes that
> we find there.
>
> v2: Fix the "4096x2160" string (nice catch!), add comments about
> do_hdmi_vsdb_modes() arguments and make it clearer that offset is
> relative to the end of the required fields of the HDMI VSDB
> (Ville Syrjälä)
>
> Signed-off-by: Damien Lespiau
> Tested-by: Cancan Feng
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
> ---
> drivers/gpu/drm/drm_edid.c | 124
> +++--
> 1 file changed, 109 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9e9b6ed..0faa08e 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2465,6 +2495,68 @@ do_cea_modes(struct drm_connector *connector, const u8
> *db, u8 len)
> return modes;
> }
>
> +/*
> + * do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
> + * @connector: connector corresponding to the HDMI sink
> + * @db: start of the CEA vendor specific block
> + * @len: length of the CEA block payload, ie. one can access up to db[len]
> + *
> + * Parses the HDMI VSDB looking for modes to add to @connector.
> + */
> +static int
> +do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
> +{
> + struct drm_device *dev = connector->dev;
> + int modes = 0, offset = 0, i;
> + u8 vic_len;
> +
> + if (len < 8)
> + goto out;
> +
> + /* no HDMI_Video_Present */
> + if (!(db[8] & (1 << 5)))
> + goto out;
> +
> + /* Latency_Fields_Present */
> + if (db[8] & (1 << 7))
> + offset += 2;
> +
> + /* I_Latency_Fields_Present */
> + if (db[8] & (1 << 6))
> + offset += 2;
> +
> + /* the declared length is not long enough for the 2 first bytes
> + * of additional video format capabilities */
> + offset += 2;
> + if (len < (8 + offset))
> + goto out;
> +
> + vic_len = db[8 + offset] >> 5;
> +
> + for (i = 0; i < vic_len && len >= (9 + offset + i); i++) {
> + struct drm_display_mode *newmode;
> + u8 vic;
> +
> + vic = db[9 + offset + i];
> +
> + vic--; /* VICs start at 1 */
> + if (vic >= ARRAY_SIZE(edid_4k_modes)) {
> + DRM_ERROR("Unknow HDMI VIC: %d\n", vic);
^^
Missing "n" - should be Unknown
> + continue;
> + }
> +
> + newmode = drm_mode_duplicate(dev, &edid_4k_modes[vic]);
> + if (!newmode)
> + continue;
> +
> + drm_mode_probed_add(connector, newmode);
> + modes++;
> + }
> +
> +out:
> + return modes;
> +}
> +
> static int
> cea_db_payload_len(const u8 *db)
> {
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 04/12] drm: Add support for alternate clocks of 4k modes
On Wed, Aug 14, 2013 at 12:17:20AM +0100, Damien Lespiau wrote:
> Suggested-by: Ville Syrjälä
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_edid.c | 68
> ++
> 1 file changed, 62 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0faa08e..606335f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2409,6 +2409,54 @@ u8 drm_match_cea_mode(const struct drm_display_mode
> *to_match)
> }
> EXPORT_SYMBOL(drm_match_cea_mode);
>
> +/*
> + * Calculate the alternate clock for HDMI modes (those from the HDMI vendor
> + * specific block).
> + *
> + * It's almost like cea_mode_alternate_clock(), we just need to add an
> + * exception for the VIC 4 mode (4096x2160@24Hz): no alternate clock for this
> + * one.
> + */
> +static unsigned int
> +hdmi_mode_alternate_clock(const struct drm_display_mode *hdmi_mode)
> +{
> + if (hdmi_mode->vdisplay == 4096 && hdmi_mode->hdisplay == 2160)
> + return hdmi_mode->clock;
> +
> + return cea_mode_alternate_clock(hdmi_mode);
> +}
> +
> +/*
> + * drm_match_cea_mode - look for a HDMI mode matching given mode
^^^
Fix that, and you get:
Reviewed-by: Ville Syrjälä
> + * @to_match: display mode
> + *
> + * An HDMI mode is one defined in the HDMI vendor specific block.
> + *
> + * Returns the HDMI Video ID (VIC) of the mode or 0 if it isn't one.
> + */
> +static u8 drm_match_hmdi_mode(const struct drm_display_mode *to_match)
> +{
> + u8 mode;
> +
> + if (!to_match->clock)
> + return 0;
> +
> + for (mode = 0; mode < ARRAY_SIZE(edid_4k_modes); mode++) {
> + const struct drm_display_mode *hdmi_mode = &edid_4k_modes[mode];
> + unsigned int clock1, clock2;
> +
> + /* Make sure to also match alternate clocks */
> + clock1 = hdmi_mode->clock;
> + clock2 = hdmi_mode_alternate_clock(hdmi_mode);
> +
> + if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
> + KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
> + drm_mode_equal_no_clocks(to_match, hdmi_mode))
> + return mode + 1;
> + }
> + return 0;
> +}
> +
> static int
> add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid)
> {
> @@ -2426,18 +2474,26 @@ add_alternate_cea_modes(struct drm_connector
> *connector, struct edid *edid)
>* with the alternate clock for certain CEA modes.
>*/
> list_for_each_entry(mode, &connector->probed_modes, head) {
> - const struct drm_display_mode *cea_mode;
> + const struct drm_display_mode *cea_mode = NULL;
> struct drm_display_mode *newmode;
> - u8 cea_mode_idx = drm_match_cea_mode(mode) - 1;
> + u8 mode_idx = drm_match_cea_mode(mode) - 1;
> unsigned int clock1, clock2;
>
> - if (cea_mode_idx >= ARRAY_SIZE(edid_cea_modes))
> - continue;
> + if (mode_idx < ARRAY_SIZE(edid_cea_modes)) {
> + cea_mode = &edid_cea_modes[mode_idx];
> + clock2 = cea_mode_alternate_clock(cea_mode);
> + } else {
> + mode_idx = drm_match_hmdi_mode(mode) - 1;
> + if (mode_idx < ARRAY_SIZE(edid_4k_modes)) {
> + cea_mode = &edid_4k_modes[mode_idx];
> + clock2 = hdmi_mode_alternate_clock(cea_mode);
> + }
> + }
>
> - cea_mode = &edid_cea_modes[cea_mode_idx];
> + if (!cea_mode)
> + continue;
>
> clock1 = cea_mode->clock;
> - clock2 = cea_mode_alternate_clock(cea_mode);
>
> if (clock1 == clock2)
> continue;
> --
> 1.8.3.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 06/12] video/hdmi: Derive the bar data valid bit from the bar data fields
On Wed, Aug 14, 2013 at 12:17:22AM +0100, Damien Lespiau wrote:
> Just like:
>
> Author: Damien Lespiau
> Date: Mon Aug 12 11:53:24 2013 +0100
>
> video/hdmi: Don't let the user of this API create invalid infoframes
>
> But this time for the horizontal/vertical bar data present bits.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/video/hdmi.c | 5 +++--
> include/linux/hdmi.h | 2 --
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index e36da36..ac84215 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -101,10 +101,11 @@ ssize_t hdmi_avi_infoframe_pack(struct
> hdmi_avi_infoframe *frame, void *buffer,
> if (frame->active_aspect & 0xf)
> ptr[0] |= BIT(4);
>
> - if (frame->horizontal_bar_valid)
> + /* Bit 3 and 2 indicate if we transmit horizontal/vertical bar data */
> + if (frame->top_bar || frame->bottom_bar)
> ptr[0] |= BIT(3);
>
> - if (frame->vertical_bar_valid)
> + if (frame->left_bar || frame->right_bar)
> ptr[0] |= BIT(2);
Technically top=0,bottom=0 or left=0,right=0 is a valid bar setup,
but it would indicate that the entire picture is made up of the
bottom/right bar. I guess no one would really want to use such a
setup, and even if they do, they could just use some N!=0 for
both bars to achieve the same effect. So we don't seem to lose
anything by doing this.
Reviewed-by: Ville Syrjälä
>
> ptr[1] = ((frame->colorimetry & 0x3) << 6) |
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 931474c6..b98340b 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -109,8 +109,6 @@ struct hdmi_avi_infoframe {
> unsigned char version;
> unsigned char length;
> enum hdmi_colorspace colorspace;
> - bool horizontal_bar_valid;
> - bool vertical_bar_valid;
> enum hdmi_scan_mode scan_mode;
> enum hdmi_colorimetry colorimetry;
> enum hdmi_picture_aspect picture_aspect;
> --
> 1.8.3.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/12] drm: Add support for alternate clocks of 4k modes
A few minor things:
On Wednesday 14 August 2013 00:17:20 Damien Lespiau wrote:
> Suggested-by: Ville Syrjälä
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/drm_edid.c | 68
> ++
> 1 file changed, 62 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0faa08e..606335f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2409,6 +2409,54 @@ u8 drm_match_cea_mode(const struct drm_display_mode
> *to_match)
> }
> EXPORT_SYMBOL(drm_match_cea_mode);
>
> +/*
> + * Calculate the alternate clock for HDMI modes (those from the HDMI vendor
> + * specific block).
> + *
> + * It's almost like cea_mode_alternate_clock(), we just need to add an
> + * exception for the VIC 4 mode (4096x2160@24Hz): no alternate clock for this
> + * one.
> + */
> +static unsigned int
> +hdmi_mode_alternate_clock(const struct drm_display_mode *hdmi_mode)
> +{
> + if (hdmi_mode->vdisplay == 4096 && hdmi_mode->hdisplay == 2160)
> + return hdmi_mode->clock;
> +
> + return cea_mode_alternate_clock(hdmi_mode);
> +}
> +
> +/*
> + * drm_match_cea_mode - look for a HDMI mode matching given mode
Here we document drm_match_cea_mode, but the function is drm_match_hdmi_mode.
> + * @to_match: display mode
> + *
> + * An HDMI mode is one defined in the HDMI vendor specific block.
> + *
> + * Returns the HDMI Video ID (VIC) of the mode or 0 if it isn't one.
> + */
> +static u8 drm_match_hmdi_mode(const struct drm_display_mode *to_match)
Surely should be hdmi, not hmdi?
> +{
> + u8 mode;
> +
> + if (!to_match->clock)
> + return 0;
> +
> + for (mode = 0; mode < ARRAY_SIZE(edid_4k_modes); mode++) {
> + const struct drm_display_mode *hdmi_mode = &edid_4k_modes[mode];
> + unsigned int clock1, clock2;
> +
> + /* Make sure to also match alternate clocks */
> + clock1 = hdmi_mode->clock;
> + clock2 = hdmi_mode_alternate_clock(hdmi_mode);
> +
> + if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
> + KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
> + drm_mode_equal_no_clocks(to_match, hdmi_mode))
> + return mode + 1;
> + }
> + return 0;
> +}
> +
> static int
> add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid)
> {
> @@ -2426,18 +2474,26 @@ add_alternate_cea_modes(struct drm_connector
> *connector, struct edid *edid)
>* with the alternate clock for certain CEA modes.
>*/
> list_for_each_entry(mode, &connector->probed_modes, head) {
> - const struct drm_display_mode *cea_mode;
> + const struct drm_display_mode *cea_mode = NULL;
> struct drm_display_mode *newmode;
> - u8 cea_mode_idx = drm_match_cea_mode(mode) - 1;
> + u8 mode_idx = drm_match_cea_mode(mode) - 1;
> unsigned int clock1, clock2;
>
> - if (cea_mode_idx >= ARRAY_SIZE(edid_cea_modes))
> - continue;
> + if (mode_idx < ARRAY_SIZE(edid_cea_modes)) {
> + cea_mode = &edid_cea_modes[mode_idx];
> + clock2 = cea_mode_alternate_clock(cea_mode);
> + } else {
> + mode_idx = drm_match_hmdi_mode(mode) - 1;
Same typo here - hmdi for hdmi.
> + if (mode_idx < ARRAY_SIZE(edid_4k_modes)) {
> + cea_mode = &edid_4k_modes[mode_idx];
> + clock2 = hdmi_mode_alternate_clock(cea_mode);
> + }
> + }
>
> - cea_mode = &edid_cea_modes[cea_mode_idx];
> + if (!cea_mode)
> + continue;
>
> clock1 = cea_mode->clock;
> - clock2 = cea_mode_alternate_clock(cea_mode);
>
> if (clock1 == clock2)
> continue;
>
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/12] video/hdmi: Introduce helpers for the HDMI vendor specific infoframe
On Wed, Aug 14, 2013 at 12:17:23AM +0100, Damien Lespiau wrote:
> Provide the programming model than the other infoframe types.
>
> The generic _pack() function can't handle those yet as we need to move
> the vendor OUI in the generic hdmi_vendor_infoframe structure to know
> which kind of vendor infoframe we are dealing with.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/video/hdmi.c | 82
>
> include/linux/hdmi.h | 25
> 2 files changed, 107 insertions(+)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index ac84215..2059f7b 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -286,6 +286,88 @@ ssize_t hdmi_audio_infoframe_pack(struct
> hdmi_audio_infoframe *frame,
> EXPORT_SYMBOL(hdmi_audio_infoframe_pack);
>
> /**
> + * hdmi_hdmi_infoframe_init() - initialize an HDMI vendor infoframe
> + * @frame: HDMI vendor infoframe
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_hdmi_infoframe_init(struct hdmi_hdmi_infoframe *frame)
> +{
> + memset(frame, 0, sizeof(*frame));
> +
> + frame->type = HDMI_INFOFRAME_TYPE_VENDOR;
> + frame->version = 1;
> + frame->length = 5; /* we can hardcode the size for now as we don't
> + support neither 3D_Ext_Data nor 3D_Metadata_* */
> +
> + /* 0 is a valid value for s3d_struct, so we use a special "not set"
> + * value */
> + frame->s3d_struct = HDMI_3D_STRUCTURE_INVALID;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(hdmi_hdmi_infoframe_init);
> +
> +/**
> + * hdmi_hmdi_infoframe_pack() - write a HDMI vendor infoframe to binary
> buffer
> + * @frame: HDMI infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Packs the information contained in the @frame structure into a binary
> + * representation that can be written into the corresponding controller
> + * registers. Also computes the checksum as required by section 5.3.5 of
> + * the HDMI 1.4 specification.
> + *
> + * Returns the number of bytes packed into the binary buffer or a negative
> + * error code on failure.
> + */
> +ssize_t hdmi_hdmi_infoframe_pack(struct hdmi_hdmi_infoframe *frame,
> + void *buffer, size_t size)
> +{
> + u8 *ptr = buffer;
> + size_t length;
> +
> + /* empty info frame */
> + if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
> + return -EINVAL;
> +
> + /* only one of those can be supplied */
> + if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
> + return -EINVAL;
> +
> + length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> +
> + if (size < length)
> + return -ENOSPC;
> +
> + memset(buffer, 0, size);
> +
> + ptr[0] = frame->type;
> + ptr[1] = frame->version;
> + ptr[2] = frame->length;
> + ptr[3] = 0; /* checksum */
> +
> + /* HDMI OUI */
> + ptr[4] = 0x03;
> + ptr[5] = 0x0c;
> + ptr[6] = 0x00;
> +
> + if (frame->vic) {
> + ptr[7] = 0x1 << 5; /* video format */
> + ptr[8] = frame->vic;
> + } else {
> + ptr[7] = 0x2 << 5; /* video format */
> + ptr[8] = (frame->s3d_struct & 0xf) << 4;
> + }
> +
> + hdmi_infoframe_checksum(buffer, length);
> +
> + return length;
> +}
> +EXPORT_SYMBOL(hdmi_hdmi_infoframe_pack);
> +
> +/**
> * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary
> *buffer
> * @frame: HDMI vendor infoframe
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index b98340b..f5098a8 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -234,11 +234,36 @@ struct hdmi_vendor_infoframe {
> ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,
> void *buffer, size_t size);
>
> +enum hdmi_3d_structure {
> + HDMI_3D_STRUCTURE_INVALID = -1,
> + HDMI_3D_STRUCTURE_FRAME_PACKING = 0,
> + HDMI_3D_STRUCTURE_FIELD_ALTERNATIVE,
> + HDMI_3D_STRUCTURE_LINE_ALTERNATIVE,
> + HDMI_3D_STRUCTURE_SIDE_BY_SIDE_FULL,
> + HDMI_3D_STRUCTURE_L_DEPTH,
> + HDMI_3D_STRUCTURE_L_DEPTH_GFX_GFX_DEPTH,
> + HDMI_3D_STRUCTURE_TOP_BOTTOM,
TOP_AND_BOTTOM maybe?
> + HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF,
The value of this should be 8. Also according to the spec
we must send 3d_ext_data when when 3d_structure >= 8, so
either we need a bit more code, or we need to disallow
3d_structure >= 8 for the time being.
> +};
> +
> +struct hdmi_hdmi_infoframe {
> + enum hdmi_infoframe_type type;
> + unsigned char version;
> + unsigned char length;
> + u8 vic;
> + enum hdmi_3d_structure s3d_struct;
> +};
> +
> +int hdmi_hdmi_infoframe_init(struct hdmi_hdmi_infoframe *frame);
> +ssize_t hdmi_hdmi_infoframe_pack(struct hdmi_hdmi_infoframe *frame,
> +
Re: [Intel-gfx] [PATCH 10/12] video/hdmi: Hook the HDMI vendor infoframe with the generic _pack()
On Wed, Aug 14, 2013 at 12:17:26AM +0100, Damien Lespiau wrote:
> With this last bit, hdmi_infoframe_pack() is now able to pack any
> infoframe we support.
>
> At the same time, because it's impractical to make two commits out of
> this, we get rid of the version that encourages the open coding of the
> vendor infoframe packing. We can do so because the only user of this API
> has been ported in:
>
> Author: Damien Lespiau
> Date: Mon Aug 12 18:08:37 2013 +0100
>
> gpu: host1x: Port the HDMI vendor infoframe code the common helpers
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/video/hdmi.c | 45 +
> include/linux/hdmi.h | 24
> 2 files changed, 21 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 2059f7b..073f005 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -300,6 +300,7 @@ int hdmi_hdmi_infoframe_init(struct hdmi_hdmi_infoframe
> *frame)
> frame->length = 5; /* we can hardcode the size for now as we don't
> support neither 3D_Ext_Data nor 3D_Metadata_* */
>
> + frame->oui = HDMI_IDENTIFIER;
> /* 0 is a valid value for s3d_struct, so we use a special "not set"
>* value */
> frame->s3d_struct = HDMI_3D_STRUCTURE_INVALID;
> @@ -367,46 +368,18 @@ ssize_t hdmi_hdmi_infoframe_pack(struct
> hdmi_hdmi_infoframe *frame,
> }
> EXPORT_SYMBOL(hdmi_hdmi_infoframe_pack);
>
> -/**
> - * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary
> - *buffer
> - * @frame: HDMI vendor infoframe
> - * @buffer: destination buffer
> - * @size: size of buffer
> - *
> - * Packs the information contained in the @frame structure into a binary
> - * representation that can be written into the corresponding controller
> - * registers. Also computes the checksum as required by section 5.3.5 of
> - * the HDMI 1.4 specification.
> - *
> - * Returns the number of bytes packed into the binary buffer or a negative
> - * error code on failure.
> +/*
> + * hdmi_vendor_infoframe_pack() - write a vendor infoframe to binary buffer
> */
> -ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,
> -void *buffer, size_t size)
> +static ssize_t hdmi_vendor_infoframe_pack(union hdmi_vendor_infoframe *frame,
> + void *buffer, size_t size)
> {
> - u8 *ptr = buffer;
> - size_t length;
> -
> - length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> -
> - if (size < length)
> - return -ENOSPC;
> -
> - memset(buffer, 0, size);
> -
> - ptr[0] = frame->type;
> - ptr[1] = frame->version;
> - ptr[2] = frame->length;
> - ptr[3] = 0; /* checksum */
> -
> - memcpy(&ptr[HDMI_INFOFRAME_HEADER_SIZE], frame->data, frame->length);
> -
> - hdmi_infoframe_checksum(buffer, length);
> + /* we only know about HDMI vendor infoframes */
> + if (frame->any.oui != HDMI_IDENTIFIER)
> + return -EINVAL;
>
> - return length;
> + return hdmi_hdmi_infoframe_pack(&frame->hdmi, buffer, size);
> }
> -EXPORT_SYMBOL(hdmi_vendor_infoframe_pack);
>
> /**
> * hdmi_infoframe_pack() - write a HDMI infoframe to binary buffer
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 53bbf0d..5c572e9 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -225,16 +225,6 @@ int hdmi_audio_infoframe_init(struct
> hdmi_audio_infoframe *frame);
> ssize_t hdmi_audio_infoframe_pack(struct hdmi_audio_infoframe *frame,
> void *buffer, size_t size);
>
> -struct hdmi_vendor_infoframe {
> - enum hdmi_infoframe_type type;
> - unsigned char version;
> - unsigned char length;
> - u8 data[27];
> -};
> -
> -ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,
> -void *buffer, size_t size);
> -
> enum hdmi_3d_structure {
> HDMI_3D_STRUCTURE_INVALID = -1,
> HDMI_3D_STRUCTURE_FRAME_PACKING = 0,
> @@ -251,6 +241,7 @@ struct hdmi_hdmi_infoframe {
> enum hdmi_infoframe_type type;
> unsigned char version;
> unsigned char length;
> + int oui;
unsigned perhaps? Same deal below in the 'any' struct.
Doesn't really matter I guess, so w/ or w/o that change:
Reviewed-by: Ville Syrjälä
> u8 vic;
> enum hdmi_3d_structure s3d_struct;
> };
> @@ -259,12 +250,21 @@ int hdmi_hdmi_infoframe_init(struct hdmi_hdmi_infoframe
> *frame);
> ssize_t hdmi_hdmi_infoframe_pack(struct hdmi_hdmi_infoframe *frame,
>void *buffer, size_t size);
>
> +union hdmi_vendor_infoframe {
> + struct {
> + enum hdmi_infoframe_type type;
> + unsigned char version;
> + unsigned char length;
> + int oui;
> + } any;
> + struct hdmi_hdmi_infofr
Re: [PATCH 08/12] gpu: host1x: Port the HDMI vendor infoframe code the common helpers
On Wed, Aug 14, 2013 at 12:17:24AM +0100, Damien Lespiau wrote:
> I just wrote the bits to define and pack HDMI vendor specific infoframe.
> Port the host1x driver to use those so I can refactor the infoframe code
> a bit more.
>
> Cc: Thierry Reding
> Cc: Terje Bergström
> Cc: linux-te...@vger.kernel.org
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/host1x/drm/hdmi.c | 24
> 1 file changed, 4 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
> index 01097da..b548918 100644
> --- a/drivers/gpu/host1x/drm/hdmi.c
> +++ b/drivers/gpu/host1x/drm/hdmi.c
> @@ -539,7 +539,7 @@ static void tegra_hdmi_setup_audio_infoframe(struct
> tegra_hdmi *hdmi)
>
> static void tegra_hdmi_setup_stereo_infoframe(struct tegra_hdmi *hdmi)
> {
> - struct hdmi_vendor_infoframe frame;
> + struct hdmi_hdmi_infoframe frame;
> unsigned long value;
> u8 buffer[10];
> ssize_t err;
> @@ -551,26 +551,10 @@ static void tegra_hdmi_setup_stereo_infoframe(struct
> tegra_hdmi *hdmi)
> return;
> }
>
> - memset(&frame, 0, sizeof(frame));
> + hdmi_hdmi_infoframe_init(&frame);
> + frame.s3d_struct = HDMI_3D_STRUCTURE_FRAME_PACKING;
>
> - frame.type = HDMI_INFOFRAME_TYPE_VENDOR;
> - frame.version = 0x01;
> - frame.length = 6;
This changes the length of the infoframe from 6 to 5, which is enough
for "frame packing", but maybe the commit msg should still mention that
small detail.
> -
> - frame.data[0] = 0x03; /* regid0 */
> - frame.data[1] = 0x0c; /* regid1 */
> - frame.data[2] = 0x00; /* regid2 */
> - frame.data[3] = 0x02 << 5; /* video format */
> -
> - /* TODO: 74 MHz limit? */
> - if (1) {
> - frame.data[4] = 0x00 << 4; /* 3D structure */
> - } else {
> - frame.data[4] = 0x08 << 4; /* 3D structure */
> - frame.data[5] = 0x00 << 4; /* 3D ext. data */
> - }
> -
> - err = hdmi_vendor_infoframe_pack(&frame, buffer, sizeof(buffer));
> + err = hdmi_hdmi_infoframe_pack(&frame, buffer, sizeof(buffer));
> if (err < 0) {
> dev_err(hdmi->dev, "failed to pack vendor infoframe: %zd\n",
> err);
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 07/12] video/hdmi: Introduce helpers for the HDMI vendor specific infoframe
On Wed, Aug 14, 2013 at 12:17:23AM +0100, Damien Lespiau wrote:
> Provide the programming model than the other infoframe types.
>
> The generic _pack() function can't handle those yet as we need to move
> the vendor OUI in the generic hdmi_vendor_infoframe structure to know
> which kind of vendor infoframe we are dealing with.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/video/hdmi.c | 82
>
> include/linux/hdmi.h | 25
> 2 files changed, 107 insertions(+)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index ac84215..2059f7b 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -286,6 +286,88 @@ ssize_t hdmi_audio_infoframe_pack(struct
> hdmi_audio_infoframe *frame,
> EXPORT_SYMBOL(hdmi_audio_infoframe_pack);
>
> /**
> + * hdmi_hdmi_infoframe_init() - initialize an HDMI vendor infoframe
> + * @frame: HDMI vendor infoframe
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_hdmi_infoframe_init(struct hdmi_hdmi_infoframe *frame)
> +{
> + memset(frame, 0, sizeof(*frame));
> +
> + frame->type = HDMI_INFOFRAME_TYPE_VENDOR;
> + frame->version = 1;
> + frame->length = 5; /* we can hardcode the size for now as we don't
> + support neither 3D_Ext_Data nor 3D_Metadata_* */
> +
> + /* 0 is a valid value for s3d_struct, so we use a special "not set"
> + * value */
> + frame->s3d_struct = HDMI_3D_STRUCTURE_INVALID;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(hdmi_hdmi_infoframe_init);
> +
> +/**
> + * hdmi_hmdi_infoframe_pack() - write a HDMI vendor infoframe to binary
> buffer
Another hmdi typo that wasn't spotted yet :)
> + * @frame: HDMI infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Packs the information contained in the @frame structure into a binary
> + * representation that can be written into the corresponding controller
> + * registers. Also computes the checksum as required by section 5.3.5 of
> + * the HDMI 1.4 specification.
> + *
> + * Returns the number of bytes packed into the binary buffer or a negative
> + * error code on failure.
> + */
> +ssize_t hdmi_hdmi_infoframe_pack(struct hdmi_hdmi_infoframe *frame,
> + void *buffer, size_t size)
> +{
> + u8 *ptr = buffer;
> + size_t length;
> +
> + /* empty info frame */
> + if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
> + return -EINVAL;
> +
> + /* only one of those can be supplied */
> + if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
> + return -EINVAL;
> +
> + length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> +
> + if (size < length)
> + return -ENOSPC;
> +
> + memset(buffer, 0, size);
> +
> + ptr[0] = frame->type;
> + ptr[1] = frame->version;
> + ptr[2] = frame->length;
> + ptr[3] = 0; /* checksum */
> +
> + /* HDMI OUI */
> + ptr[4] = 0x03;
> + ptr[5] = 0x0c;
> + ptr[6] = 0x00;
> +
> + if (frame->vic) {
> + ptr[7] = 0x1 << 5; /* video format */
> + ptr[8] = frame->vic;
> + } else {
> + ptr[7] = 0x2 << 5; /* video format */
> + ptr[8] = (frame->s3d_struct & 0xf) << 4;
> + }
> +
> + hdmi_infoframe_checksum(buffer, length);
> +
> + return length;
> +}
> +EXPORT_SYMBOL(hdmi_hdmi_infoframe_pack);
> +
> +/**
> * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary
> *buffer
> * @frame: HDMI vendor infoframe
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index b98340b..f5098a8 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -234,11 +234,36 @@ struct hdmi_vendor_infoframe {
> ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,
> void *buffer, size_t size);
>
> +enum hdmi_3d_structure {
> + HDMI_3D_STRUCTURE_INVALID = -1,
> + HDMI_3D_STRUCTURE_FRAME_PACKING = 0,
> + HDMI_3D_STRUCTURE_FIELD_ALTERNATIVE,
> + HDMI_3D_STRUCTURE_LINE_ALTERNATIVE,
> + HDMI_3D_STRUCTURE_SIDE_BY_SIDE_FULL,
> + HDMI_3D_STRUCTURE_L_DEPTH,
> + HDMI_3D_STRUCTURE_L_DEPTH_GFX_GFX_DEPTH,
> + HDMI_3D_STRUCTURE_TOP_BOTTOM,
> + HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF,
> +};
> +
> +struct hdmi_hdmi_infoframe {
> + enum hdmi_infoframe_type type;
> + unsigned char version;
> + unsigned char length;
> + u8 vic;
> + enum hdmi_3d_structure s3d_struct;
> +};
> +
> +int hdmi_hdmi_infoframe_init(struct hdmi_hdmi_infoframe *frame);
> +ssize_t hdmi_hdmi_infoframe_pack(struct hdmi_hdmi_infoframe *frame,
> + void *buffer, size_t size);
> +
> union hdmi_infoframe {
> struct hdmi_any_infoframe any;
> struct hdmi_avi_infoframe avi;
> struct hdmi_spd_i
Re: HDMI 4k support v2
On Wed, Aug 14, 2013 at 12:17:16AM +0100, Damien Lespiau wrote: > Following up the first instance of this series: > http://lists.freedesktop.org/archives/dri-devel/2013-August/043125.html > > Here is a v2 with Ville's review pass and a few additions: > - Alternate clock modes for 4k resolutions > - HDMI vendor specific infoframe support in drivers/video/hdmi.c > - Enabling of those vendor specific infoframes in the i915 driver The patches I didn't explicitly comment on (01,05,09,12 by my reckoning) are: Reviewed-by: Ville Syrjälä > Along the way, a tegra patch was needed for a small consolidation of the code > packing vendor specific infoframes. This patch has only been compile-tested. > > On Intel, it's possible to read back the programmed infoframe buffers with > intel-gpu-tools' intel_infoframe and this gives: > > Vendor InfoFrame: > - frequency: every vsync > - raw: > f4050181 000c0347 0320 > > 004c > > - vendor Id: 0x000c03 (HDMI) > - video format: 0x001 > - HDMI VIC: 3 > > after a $ xrandr --output HDMI1 --mode 3840x2160 -r 24 > > -- > Damien > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67530] VDPAU state tracker reports wrong codec level
https://bugs.freedesktop.org/show_bug.cgi?id=67530 Christian König changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Christian König --- Just commited the fix to master, please retest and close if solved. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm/i2c: tda998x: fix EDID reading on TDA19988 devices
On Wed, Aug 14, 2013 at 8:16 AM, Russell King - ARM Linux wrote: > On Tue, Aug 06, 2013 at 12:20:11AM +0200, Sebastian Hesselbarth wrote: >> From: Russell King >> >> TDA19988 devices need their RAM enabled in order to read EDID >> information. Add support for this. >> >> Signed-off-by: Russell King >> Tested-by: Sebastian Hesselbarth > > There was some debate about whether this is needed or not. It seems that > if I don't run the NXP driver, it isn't needed, but if I have run the > NXP driver, then yes it is. As it seems to do no harm, I think it's fine > to be submitted. just fwiw, I had noticed before that (at least on the beaglebone-black), nxp doesn't necessarily get reset when doing a warm reboot. So booting a kernel w/ NXP driver, and then rebooting w/ upstream kernel and tda998x should probably hit this same scenario. Better to not assume too much about the state of the tda when the driver is loaded, so I think this patch is a good idea. Signed-off-by: Rob Clark BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] Add dt support for exynos hdmiphy settings
Hi Shirish, On Tuesday 13 of August 2013 12:39:27 Shirish S wrote: > For various revision of chipset if the signal pattern is changed for > every board, then the phy setting need to be updated correspondingly by > measuring the signal. > With the hdmiphy settings fixed in the driver the only way currently is > to either add a new structure or add compile time option. > To avoid this, we can move the same to dt, wherin we can have different > dt files for every revision. This patchset can be considered as an > initiative towards achieving the same for exynos 5250 and can be later > extended to future chipsets. > Also this patchset moves the entire structure to dt file as-is in the > driver and hence we can find all the hex values, which are not logically > explained similar to driver. > > Shirish S (3): > ARM: dts: smdk5250: Add hdmi phy settings > ARM: dts: arndale: Add hdmi phy settings > drm: exynos: hdmi: Add dt support for hdmiphy settings > > .../devicetree/bindings/video/exynos_hdmi.txt | 18 +- > arch/arm/boot/dts/exynos5250-arndale.dts | 120 > arch/arm/boot/dts/exynos5250-smdk5250.dts | 120 > drivers/gpu/drm/exynos/exynos_hdmi.c | 191 > +++- 4 files changed, 320 insertions(+), 129 > deletions(-) Since this series is related to Exynos platform files, please also Cc the linux-samsung-soc mailing list and Kukjin Kim. Same goes for device tree bindings. If you change anything related to device tree, you need to post your patches to devicet...@vger.kernel.org mailing list. Ccing device tree maintainers is also a good practice. Please resend this series with above two issues addressed. Best regards, Tomasz ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67876] linux v4.11-rc1 many drm:radeon_ttm_backend_bind ERROR failed to bind 2025 pages issued during boot
https://bugs.freedesktop.org/show_bug.cgi?id=67876 --- Comment #5 from Alex Deucher --- The rlc ucode was updated for UVD support. You need the newer rlc ucode if you want to use UVD. But either version should work if you don't need UVD. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/7] DRM: Remove gem_init_object() and friends
Hi This series removes any access to gem_obj->driver_private from all drivers and then drops drm_gem_object_alloc() with its ->gem_init_object() driver callback. All this is only needed if a gem object is not embedded into the driver's bo. However, all drivers (except for nouveau, see patch #6) embed the objects. No need to allow dynamic allocations, anymore. Patches #1 to #5 are trivial and only remove dead code. Patch #6 converts nouveau to embed gem objects into nouveau_bo. I tested this on my nv50 and it runs fine. Patch #7 drops gem_init_object() from all drivers as it is unused and the callbacks are all empty (or BUG()). And the diff-stat looks pretty nice, too. Cheers David David Herrmann (7): drm/ast: remove unused driver_private access drm/mgag200: remove unused driver_private access drm/cirrus: remove unused driver_private access drm/qxl: remove unused object_pin/unpin() helpers drm/radeon: remove stale gem->driver_private access drm/nouveau: embed gem object in nouveau_bo drm: kill ->gem_init_object() and friends drivers/gpu/drm/ast/ast_drv.c | 1 - drivers/gpu/drm/ast/ast_drv.h | 1 - drivers/gpu/drm/ast/ast_main.c| 6 - drivers/gpu/drm/ast/ast_ttm.c | 1 - drivers/gpu/drm/cirrus/cirrus_drv.c | 1 - drivers/gpu/drm/cirrus/cirrus_drv.h | 1 - drivers/gpu/drm/cirrus/cirrus_main.c | 6 - drivers/gpu/drm/cirrus/cirrus_ttm.c | 1 - drivers/gpu/drm/drm_gem.c | 29 - drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 - drivers/gpu/drm/exynos/exynos_drm_gem.c | 5 drivers/gpu/drm/exynos/exynos_drm_gem.h | 3 --- drivers/gpu/drm/gma500/gem.c | 5 drivers/gpu/drm/gma500/psb_drv.c | 1 - drivers/gpu/drm/gma500/psb_drv.h | 1 - drivers/gpu/drm/i915/i915_drv.c | 1 - drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_gem.c | 7 -- drivers/gpu/drm/mgag200/mgag200_drv.c | 1 - drivers/gpu/drm/mgag200/mgag200_drv.h | 1 - drivers/gpu/drm/mgag200/mgag200_main.c| 6 - drivers/gpu/drm/mgag200/mgag200_ttm.c | 1 - drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 +-- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +- drivers/gpu/drm/nouveau/nouveau_bo.h | 5 +++- drivers/gpu/drm/nouveau/nouveau_display.c | 10 drivers/gpu/drm/nouveau/nouveau_drm.c | 1 - drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 42 +-- drivers/gpu/drm/nouveau/nouveau_gem.h | 3 +-- drivers/gpu/drm/nouveau/nouveau_prime.c | 10 +--- drivers/gpu/drm/omapdrm/omap_drv.c| 1 - drivers/gpu/drm/omapdrm/omap_drv.h| 1 - drivers/gpu/drm/omapdrm/omap_gem.c| 5 drivers/gpu/drm/qxl/qxl_drv.c | 1 - drivers/gpu/drm/qxl/qxl_drv.h | 4 --- drivers/gpu/drm/qxl/qxl_gem.c | 32 --- drivers/gpu/drm/qxl/qxl_object.c | 1 - drivers/gpu/drm/radeon/radeon_drv.c | 2 -- drivers/gpu/drm/radeon/radeon_gem.c | 7 -- drivers/gpu/drm/radeon/radeon_object.c| 1 - drivers/gpu/drm/radeon/radeon_prime.c | 1 - drivers/gpu/drm/udl/udl_drv.c | 1 - drivers/gpu/drm/udl/udl_drv.h | 1 - drivers/gpu/drm/udl/udl_gem.c | 7 -- include/drm/drmP.h| 5 46 files changed, 37 insertions(+), 193 deletions(-) -- 1.8.3.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] drm/ast: remove unused driver_private access
gem_bo->driver_private is never read by ast nor DRM core. No need to set it. Besides, drm core clears it during setup, anyway. Cc: Dave Airlie Signed-off-by: David Herrmann --- drivers/gpu/drm/ast/ast_ttm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c index 98d6708..cf1c833 100644 --- a/drivers/gpu/drm/ast/ast_ttm.c +++ b/drivers/gpu/drm/ast/ast_ttm.c @@ -321,7 +321,6 @@ int ast_bo_create(struct drm_device *dev, int size, int align, return ret; } - astbo->gem.driver_private = NULL; astbo->bo.bdev = &ast->ttm.bdev; ast_ttm_placement(astbo, TTM_PL_FLAG_VRAM | TTM_PL_FLAG_SYSTEM); -- 1.8.3.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] drm/mgag200: remove unused driver_private access
gem_bo->driver_private is never read by mgag200 nor DRM core. No need to set it. Besides, drm core clears it during setup, anyway. Cc: Dave Airlie Signed-off-by: David Herrmann --- drivers/gpu/drm/mgag200/mgag200_ttm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c b/drivers/gpu/drm/mgag200/mgag200_ttm.c index 3acb2b0..6cf3fa0 100644 --- a/drivers/gpu/drm/mgag200/mgag200_ttm.c +++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c @@ -321,7 +321,6 @@ int mgag200_bo_create(struct drm_device *dev, int size, int align, return ret; } - mgabo->gem.driver_private = NULL; mgabo->bo.bdev = &mdev->ttm.bdev; mgag200_ttm_placement(mgabo, TTM_PL_FLAG_VRAM | TTM_PL_FLAG_SYSTEM); -- 1.8.3.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm/cirrus: remove unused driver_private access
gem_bo->driver_private is never read by cirrus nor DRM core. No need to set it. Besides, drm core clears it during setup, anyway. Cc: Dave Airlie Signed-off-by: David Herrmann --- drivers/gpu/drm/cirrus/cirrus_ttm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c b/drivers/gpu/drm/cirrus/cirrus_ttm.c index 0047012..bf8a506 100644 --- a/drivers/gpu/drm/cirrus/cirrus_ttm.c +++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c @@ -326,7 +326,6 @@ int cirrus_bo_create(struct drm_device *dev, int size, int align, return ret; } - cirrusbo->gem.driver_private = NULL; cirrusbo->bo.bdev = &cirrus->ttm.bdev; cirrus_ttm_placement(cirrusbo, TTM_PL_FLAG_VRAM | TTM_PL_FLAG_SYSTEM); -- 1.8.3.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/7] drm/qxl: remove unused object_pin/unpin() helpers
These two helpers are unused. Remove them. They rely on
gem_obj->driver_private, which is set to NULL during setup. As this field
isn't used by the driver, anymore, we can remove this assignment as well.
Cc: Dave Airlie
Signed-off-by: David Herrmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 3 ---
drivers/gpu/drm/qxl/qxl_gem.c| 26 --
drivers/gpu/drm/qxl/qxl_object.c | 1 -
3 files changed, 30 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index afd09d4..77bfed4 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -396,9 +396,6 @@ int qxl_gem_object_create(struct qxl_device *qdev, int size,
bool discardable, bool kernel,
struct qxl_surface *surf,
struct drm_gem_object **obj);
-int qxl_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain,
- uint64_t *gpu_addr);
-void qxl_gem_object_unpin(struct drm_gem_object *obj);
int qxl_gem_object_create_with_handle(struct qxl_device *qdev,
struct drm_file *file_priv,
u32 domain,
diff --git a/drivers/gpu/drm/qxl/qxl_gem.c b/drivers/gpu/drm/qxl/qxl_gem.c
index a235693..31fd4c3 100644
--- a/drivers/gpu/drm/qxl/qxl_gem.c
+++ b/drivers/gpu/drm/qxl/qxl_gem.c
@@ -101,32 +101,6 @@ int qxl_gem_object_create_with_handle(struct qxl_device
*qdev,
return 0;
}
-int qxl_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain,
- uint64_t *gpu_addr)
-{
- struct qxl_bo *qobj = obj->driver_private;
- int r;
-
- r = qxl_bo_reserve(qobj, false);
- if (unlikely(r != 0))
- return r;
- r = qxl_bo_pin(qobj, pin_domain, gpu_addr);
- qxl_bo_unreserve(qobj);
- return r;
-}
-
-void qxl_gem_object_unpin(struct drm_gem_object *obj)
-{
- struct qxl_bo *qobj = obj->driver_private;
- int r;
-
- r = qxl_bo_reserve(qobj, false);
- if (likely(r == 0)) {
- qxl_bo_unpin(qobj);
- qxl_bo_unreserve(qobj);
- }
-}
-
int qxl_gem_object_open(struct drm_gem_object *obj, struct drm_file *file_priv)
{
return 0;
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index 1191fe7..7ff7cbf 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -97,7 +97,6 @@ int qxl_bo_create(struct qxl_device *qdev,
kfree(bo);
return r;
}
- bo->gem_base.driver_private = NULL;
bo->type = domain;
bo->pin_count = 0;
bo->surface_id = 0;
--
1.8.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm/radeon: remove stale gem->driver_private access
This field is never read. No need to set it in radeon. Besides, DRM gem core clears it during setup, anyway. Cc: Dave Airlie Cc: Alex Deucher Signed-off-by: David Herrmann --- drivers/gpu/drm/radeon/radeon_object.c | 1 - drivers/gpu/drm/radeon/radeon_prime.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 2020bf4..c0fa4aa 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -142,7 +142,6 @@ int radeon_bo_create(struct radeon_device *rdev, return r; } bo->rdev = rdev; - bo->gem_base.driver_private = NULL; bo->surface_reg = -1; INIT_LIST_HEAD(&bo->list); INIT_LIST_HEAD(&bo->va); diff --git a/drivers/gpu/drm/radeon/radeon_prime.c b/drivers/gpu/drm/radeon/radeon_prime.c index 65b9eab..2007456 100644 --- a/drivers/gpu/drm/radeon/radeon_prime.c +++ b/drivers/gpu/drm/radeon/radeon_prime.c @@ -68,7 +68,6 @@ struct drm_gem_object *radeon_gem_prime_import_sg_table(struct drm_device *dev, RADEON_GEM_DOMAIN_GTT, sg, &bo); if (ret) return ERR_PTR(ret); - bo->gem_base.driver_private = bo; mutex_lock(&rdev->gem.mutex); list_add_tail(&bo->list, &rdev->gem.objects); -- 1.8.3.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/nouveau: embed gem object in nouveau_bo
There is no reason to keep the gem object separately allocated. nouveau is
the last user of gem_obj->driver_private, so if we embed it, we can get
rid of 8bytes per gem-object.
The implementation follows the radeon driver. bo->gem is only valid, iff
the bo was created via the gem helpers _and_ iff the user holds a valid
gem reference. That is, as the gem object holds a reference to the
nouveau_bo. If you use nouveau_ref() to gain a bo reference, you are not
guaranteed to also hold a gem reference. The gem object might get
destroyed after the last user drops the gem-ref via
drm_gem_object_unreference(). Use drm_gem_object_reference() to gain a
gem-reference.
For debugging, we can use bo->gem.filp != NULL to test whether a gem-bo is
valid. However, this shouldn't be used for real functionality to avoid
gem-internal dependencies.
Note that the implementation follows the previous style. However, we no
longer can check for bo->gem != NULL to test for a valid gem object. This
wasn't done before, so we should be safe now.
Cc: Ben Skeggs
Cc: Maarten Lankhorst
Cc: Martin Peres
Signed-off-by: David Herrmann
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.h | 5 -
drivers/gpu/drm/nouveau/nouveau_display.c | 10 -
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 36 +++
drivers/gpu/drm/nouveau/nouveau_gem.h | 2 +-
drivers/gpu/drm/nouveau/nouveau_prime.c | 10 +
8 files changed, 37 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 8f467e7..3897549 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -130,7 +130,7 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,
if (chan->ntfy) {
nouveau_bo_vma_del(chan->ntfy, &chan->ntfy_vma);
nouveau_bo_unpin(chan->ntfy);
- drm_gem_object_unreference_unlocked(chan->ntfy->gem);
+ drm_gem_object_unreference_unlocked(&chan->ntfy->gem);
}
if (chan->heap.block_size)
@@ -320,7 +320,7 @@ nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS)
goto done;
}
- ret = drm_gem_handle_create(file_priv, chan->ntfy->gem,
+ ret = drm_gem_handle_create(file_priv, &chan->ntfy->gem,
&init->notifier_handle);
if (ret)
goto done;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 4e7ee5f..7767a89 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -146,7 +146,7 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
struct drm_device *dev = drm->dev;
struct nouveau_bo *nvbo = nouveau_bo(bo);
- if (unlikely(nvbo->gem))
+ if (unlikely(nvbo->gem.filp))
DRM_ERROR("bo %p still attached to GEM object\n", bo);
WARN_ON(nvbo->pin_refcnt > 0);
nv10_bo_put_tile_region(dev, nvbo->tile, NULL);
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index 653dbbb..ff17c1f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -27,7 +27,10 @@ struct nouveau_bo {
u32 tile_flags;
struct nouveau_drm_tile *tile;
- struct drm_gem_object *gem;
+ /* Only valid if allocated via nouveau_gem_new() and iff you hold a
+* gem reference to it! For debugging, use gem.filp != NULL to test
+* whether it is valid. */
+ struct drm_gem_object gem;
/* protect by the ttm reservation lock */
int pin_refcnt;
diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 78637af..85571ed 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -50,7 +50,7 @@ nouveau_user_framebuffer_destroy(struct drm_framebuffer
*drm_fb)
struct nouveau_framebuffer *fb = nouveau_framebuffer(drm_fb);
if (fb->nvbo)
- drm_gem_object_unreference_unlocked(fb->nvbo->gem);
+ drm_gem_object_unreference_unlocked(&fb->nvbo->gem);
drm_framebuffer_cleanup(drm_fb);
kfree(fb);
@@ -63,7 +63,7 @@ nouveau_user_framebuffer_create_handle(struct drm_framebuffer
*drm_fb,
{
struct nouveau_framebuffer *fb = nouveau_framebuffer(drm_fb);
- return drm_gem_handle_create(file_priv, fb->nvbo->gem, handle);
+ return drm_gem_handle_create(file_priv, &fb->nvbo->gem, handle);
}
static const struct drm_framebuffer_funcs nouveau_framebuffer_funcs = {
@@ -668,8 +668,8 @@ nouveau_display_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
if (ret)
return ret;
-
[PATCH 7/7] drm: kill ->gem_init_object() and friends
All drivers embed gem-objects into their own buffer objects. There is no
reason to keep drm_gem_object_alloc(), gem->driver_private and
->gem_init_object() anymore.
New drivers are highly encouraged to do the same. There is no benefit in
allocating gem-objects separately.
Cc: Dave Airlie
Cc: Alex Deucher
Cc: Daniel Vetter
Cc: Jerome Glisse
Cc: Rob Clark
Cc: Inki Dae
Cc: Ben Skeggs
Cc: Patrik Jakobsson
Signed-off-by: David Herrmann
---
drivers/gpu/drm/ast/ast_drv.c | 1 -
drivers/gpu/drm/ast/ast_drv.h | 1 -
drivers/gpu/drm/ast/ast_main.c | 6 --
drivers/gpu/drm/cirrus/cirrus_drv.c | 1 -
drivers/gpu/drm/cirrus/cirrus_drv.h | 1 -
drivers/gpu/drm/cirrus/cirrus_main.c| 6 --
drivers/gpu/drm/drm_gem.c | 29 -
drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_gem.c | 5 -
drivers/gpu/drm/exynos/exynos_drm_gem.h | 3 ---
drivers/gpu/drm/gma500/gem.c| 5 -
drivers/gpu/drm/gma500/psb_drv.c| 1 -
drivers/gpu/drm/gma500/psb_drv.h| 1 -
drivers/gpu/drm/i915/i915_drv.c | 1 -
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 7 ---
drivers/gpu/drm/mgag200/mgag200_drv.c | 1 -
drivers/gpu/drm/mgag200/mgag200_drv.h | 1 -
drivers/gpu/drm/mgag200/mgag200_main.c | 6 --
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
drivers/gpu/drm/nouveau/nouveau_gem.c | 6 --
drivers/gpu/drm/nouveau/nouveau_gem.h | 1 -
drivers/gpu/drm/omapdrm/omap_drv.c | 1 -
drivers/gpu/drm/omapdrm/omap_drv.h | 1 -
drivers/gpu/drm/omapdrm/omap_gem.c | 5 -
drivers/gpu/drm/qxl/qxl_drv.c | 1 -
drivers/gpu/drm/qxl/qxl_drv.h | 1 -
drivers/gpu/drm/qxl/qxl_gem.c | 6 --
drivers/gpu/drm/radeon/radeon_drv.c | 2 --
drivers/gpu/drm/radeon/radeon_gem.c | 7 ---
drivers/gpu/drm/udl/udl_drv.c | 1 -
drivers/gpu/drm/udl/udl_drv.h | 1 -
drivers/gpu/drm/udl/udl_gem.c | 7 ---
include/drm/drmP.h | 5 -
34 files changed, 124 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index a144fb0..7b1b47a 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -212,7 +212,6 @@ static struct drm_driver driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
- .gem_init_object = ast_gem_init_object,
.gem_free_object = ast_gem_free_object,
.dumb_create = ast_dumb_create,
.dumb_map_offset = ast_dumb_mmap_offset,
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 796dbb2..a6b7b29 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -323,7 +323,6 @@ extern int ast_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-extern int ast_gem_init_object(struct drm_gem_object *obj);
extern void ast_gem_free_object(struct drm_gem_object *obj);
extern int ast_dumb_mmap_offset(struct drm_file *file,
struct drm_device *dev,
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 7f6152d..af0b868 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -449,12 +449,6 @@ int ast_dumb_create(struct drm_file *file,
return 0;
}
-int ast_gem_init_object(struct drm_gem_object *obj)
-{
- BUG();
- return 0;
-}
-
void ast_bo_unref(struct ast_bo **bo)
{
struct ttm_buffer_object *tbo;
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
b/drivers/gpu/drm/cirrus/cirrus_drv.c
index d35d99c..76fa5cd 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.c
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -98,7 +98,6 @@ static struct drm_driver driver = {
.major = DRIVER_MAJOR,
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
- .gem_init_object = cirrus_gem_init_object,
.gem_free_object = cirrus_gem_free_object,
.dumb_create = cirrus_dumb_create,
.dumb_map_offset = cirrus_dumb_mmap_offset,
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h
b/drivers/gpu/drm/cirrus/cirrus_drv.h
index 9b0bb91..b6aded7 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
@@ -191,7 +191,6 @@ int cirrus_device_init(struct cirrus_device *cdev,
struct pci_dev *pdev,
uint32_t flags);
void cirrus_device_fini(struct cirrus_device *cdev);
-int cirrus_gem_init_object(struct drm_gem_object *obj);
void cirrus_gem_free_object(struct drm_gem_object *obj);
int cirrus_dumb_mmap_offset(struct drm_file *file,
struct drm_device *dev,
diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
b/drivers/gpu/drm/cir
Re: [PATCH 5/7] drm/radeon: remove stale gem->driver_private access
On Wed, Aug 14, 2013 at 9:07 AM, David Herrmann wrote: > This field is never read. No need to set it in radeon. Besides, DRM gem > core clears it during setup, anyway. > > Cc: Dave Airlie > Cc: Alex Deucher > Signed-off-by: David Herrmann Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/radeon/radeon_object.c | 1 - > drivers/gpu/drm/radeon/radeon_prime.c | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_object.c > b/drivers/gpu/drm/radeon/radeon_object.c > index 2020bf4..c0fa4aa 100644 > --- a/drivers/gpu/drm/radeon/radeon_object.c > +++ b/drivers/gpu/drm/radeon/radeon_object.c > @@ -142,7 +142,6 @@ int radeon_bo_create(struct radeon_device *rdev, > return r; > } > bo->rdev = rdev; > - bo->gem_base.driver_private = NULL; > bo->surface_reg = -1; > INIT_LIST_HEAD(&bo->list); > INIT_LIST_HEAD(&bo->va); > diff --git a/drivers/gpu/drm/radeon/radeon_prime.c > b/drivers/gpu/drm/radeon/radeon_prime.c > index 65b9eab..2007456 100644 > --- a/drivers/gpu/drm/radeon/radeon_prime.c > +++ b/drivers/gpu/drm/radeon/radeon_prime.c > @@ -68,7 +68,6 @@ struct drm_gem_object > *radeon_gem_prime_import_sg_table(struct drm_device *dev, >RADEON_GEM_DOMAIN_GTT, sg, &bo); > if (ret) > return ERR_PTR(ret); > - bo->gem_base.driver_private = bo; > > mutex_lock(&rdev->gem.mutex); > list_add_tail(&bo->list, &rdev->gem.objects); > -- > 1.8.3.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/7] DRM: Remove gem_init_object() and friends
On Wed, Aug 14, 2013 at 03:07:13PM +0200, David Herrmann wrote: > Hi > > This series removes any access to gem_obj->driver_private from all drivers and > then drops drm_gem_object_alloc() with its ->gem_init_object() driver > callback. > > All this is only needed if a gem object is not embedded into the driver's bo. > However, all drivers (except for nouveau, see patch #6) embed the objects. No > need to allow dynamic allocations, anymore. > > Patches #1 to #5 are trivial and only remove dead code. Patch #6 converts > nouveau to embed gem objects into nouveau_bo. I tested this on my nv50 and it > runs fine. Patch #7 drops gem_init_object() from all drivers as it is unused > and > the callbacks are all empty (or BUG()). > > And the diff-stat looks pretty nice, too. > > Cheers > David > > David Herrmann (7): > drm/ast: remove unused driver_private access > drm/mgag200: remove unused driver_private access > drm/cirrus: remove unused driver_private access > drm/qxl: remove unused object_pin/unpin() helpers > drm/radeon: remove stale gem->driver_private access > drm/nouveau: embed gem object in nouveau_bo > drm: kill ->gem_init_object() and friends On the series: Reviewed-by: Daniel Vetter > > drivers/gpu/drm/ast/ast_drv.c | 1 - > drivers/gpu/drm/ast/ast_drv.h | 1 - > drivers/gpu/drm/ast/ast_main.c| 6 - > drivers/gpu/drm/ast/ast_ttm.c | 1 - > drivers/gpu/drm/cirrus/cirrus_drv.c | 1 - > drivers/gpu/drm/cirrus/cirrus_drv.h | 1 - > drivers/gpu/drm/cirrus/cirrus_main.c | 6 - > drivers/gpu/drm/cirrus/cirrus_ttm.c | 1 - > drivers/gpu/drm/drm_gem.c | 29 - > drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 - > drivers/gpu/drm/exynos/exynos_drm_gem.c | 5 > drivers/gpu/drm/exynos/exynos_drm_gem.h | 3 --- > drivers/gpu/drm/gma500/gem.c | 5 > drivers/gpu/drm/gma500/psb_drv.c | 1 - > drivers/gpu/drm/gma500/psb_drv.h | 1 - > drivers/gpu/drm/i915/i915_drv.c | 1 - > drivers/gpu/drm/i915/i915_drv.h | 1 - > drivers/gpu/drm/i915/i915_gem.c | 7 -- > drivers/gpu/drm/mgag200/mgag200_drv.c | 1 - > drivers/gpu/drm/mgag200/mgag200_drv.h | 1 - > drivers/gpu/drm/mgag200/mgag200_main.c| 6 - > drivers/gpu/drm/mgag200/mgag200_ttm.c | 1 - > drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 +-- > drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_bo.h | 5 +++- > drivers/gpu/drm/nouveau/nouveau_display.c | 10 > drivers/gpu/drm/nouveau/nouveau_drm.c | 1 - > drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_gem.c | 42 > +-- > drivers/gpu/drm/nouveau/nouveau_gem.h | 3 +-- > drivers/gpu/drm/nouveau/nouveau_prime.c | 10 +--- > drivers/gpu/drm/omapdrm/omap_drv.c| 1 - > drivers/gpu/drm/omapdrm/omap_drv.h| 1 - > drivers/gpu/drm/omapdrm/omap_gem.c| 5 > drivers/gpu/drm/qxl/qxl_drv.c | 1 - > drivers/gpu/drm/qxl/qxl_drv.h | 4 --- > drivers/gpu/drm/qxl/qxl_gem.c | 32 --- > drivers/gpu/drm/qxl/qxl_object.c | 1 - > drivers/gpu/drm/radeon/radeon_drv.c | 2 -- > drivers/gpu/drm/radeon/radeon_gem.c | 7 -- > drivers/gpu/drm/radeon/radeon_object.c| 1 - > drivers/gpu/drm/radeon/radeon_prime.c | 1 - > drivers/gpu/drm/udl/udl_drv.c | 1 - > drivers/gpu/drm/udl/udl_drv.h | 1 - > drivers/gpu/drm/udl/udl_gem.c | 7 -- > include/drm/drmP.h| 5 > 46 files changed, 37 insertions(+), 193 deletions(-) > > -- > 1.8.3.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] drm/nouveau: embed gem object in nouveau_bo
Op 14-08-13 15:07, David Herrmann schreef:
> There is no reason to keep the gem object separately allocated. nouveau is
> the last user of gem_obj->driver_private, so if we embed it, we can get
> rid of 8bytes per gem-object.
>
> The implementation follows the radeon driver. bo->gem is only valid, iff
> the bo was created via the gem helpers _and_ iff the user holds a valid
> gem reference. That is, as the gem object holds a reference to the
> nouveau_bo. If you use nouveau_ref() to gain a bo reference, you are not
> guaranteed to also hold a gem reference. The gem object might get
> destroyed after the last user drops the gem-ref via
> drm_gem_object_unreference(). Use drm_gem_object_reference() to gain a
> gem-reference.
>
> For debugging, we can use bo->gem.filp != NULL to test whether a gem-bo is
> valid. However, this shouldn't be used for real functionality to avoid
> gem-internal dependencies.
>
> Note that the implementation follows the previous style. However, we no
> longer can check for bo->gem != NULL to test for a valid gem object. This
> wasn't done before, so we should be safe now.
I'm all for getting rid of it, but I think it's not thorough enough. :P
There's still a separate refcount in ttm for the bo, and I think it doesn't
make sense to keep it like that.
Instead of having that refcount in ttm, could it be put entirely in gem?
ttm_buffer_object_transfer is the only time ttm creates a bo, and it's
immediately destroyed, so instead
of calling ttm_bo_unref it could call ttm_bo_release directly, in which case it
doesn't matter that refcount
is managed by gem.
Oh except for vmwgfx of course, I always forget that 'special' case.
Maybe something like this in memory?
struct {
struct ttm_buffer_object bo;
struct drm_gem_object gem; // Can be anything, as long as first member is a
refcount, and no hole between ttm and this..
};
This would allow ttm to do kref_put((kref_t*)(bo +1), driver->releasefn), where
driver->releasefn has to call ttm_bo_release again.
Unfortunately unless drm is fixed dma-buf is still going to be as buggy as
before, not much I can do about that. :/
But this is something for a future where dma-buf in drm doesn't suck..
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
> >> > Turning to DRM/KMS, it seems the supported formats of a plane
> >> > can be queried using drm_mode_get_plane. However, there doesn't
> >> > seem to be a way to query the supported formats of a crtc? If
> >> > display HW only supports scanning out from a single buffer
> >> > (like pl111 does), I think it won't have any planes and a fb can
> >> > only be set on the crtc. In which case, how should user-space
> > >> query which pixel formats that crtc supports?
> >>
> >> it is exposed for drm plane's. What is missing is to expose the
> >> primary-plane associated with the crtc.
> >
> > Cool - so a patch which adds a way to query the what formats a crtc
> > supports would be welcome?
>
> well, I kinda think we want something that exposes the "primary plane"
> of the crtc.. I'm thinking something roughly like:
>
> -
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 53db7ce..c7ffca8 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -157,6 +157,12 @@ struct drm_mode_get_plane {
> struct drm_mode_get_plane_res {
> __u64 plane_id_ptr;
> __u32 count_planes;
> + /* The primary planes are in matching order to crtc_id_ptr in
> + * drm_mode_card_res (and same length). For crtc_id[n], it's
> + * primary plane is given by primary_plane_id[n].
> + */
> + __u32 count_primary_planes;
> + __u64 primary_plane_id_ptr;
> };
Yup - I think that works and allows userspace to query the supported
formats of the crtc. Great!
> which is why you want to let userspace figure out the pitch and then
> tell the display driver what size it wants, rather than using dumb
> buffer ioctl ;-)
>
> Ok, you could have a generic TELL_ME_WHAT_STRIDE_TO_USE ioctl or
> property or what have you.. but I think that would be hard to get
> right for all cases, and most people don't really care about that
> because they already need a gpu/display specific xorg driver and/or
> gl/egl talking to their kernel driver. You are in a slightly special
> case, since you are providing GL driver independently of the display
> driver. But I think that is easier to handle by just telling your
> customers "here, fill out this function(s) to allocate buffer for
> scanout" (and, well, I guess you'd need one to query for
> pitch/stride), rather than trying to cram everything into the kernel.
I fear we're going round in circles here, so time to step back a sec.
My first goal is to figure out how to solve our immediate problem of
how to allocate buffers in our DDX which doesn't abuse the dumb buffer
interface. As stated at the start of this thread, we need to allocate
two types of buffers:
1) Those which will be shared between GPU & Display. These must be
allocated in such a way as to satisfy both devices' constraints.
2) Those which will only be used by the GPU (DRI2 buffers, pixmaps
which have been imported into a client's EGL, etc.)
It must be possible to obtain handles to both those types of buffers
in a single DRM/GEM name-space to allow us to implement DRI2.
I think we can satisfy the first buffer type by adjusting the display
DRM's dumb buffer alloc function to always allocate buffers which also
satisfy the GPU's constraints. In pl111_drm, that means all buffers
are allocated with a 64-byte stride alignment, even on SoCs without a
GPU. Not a big issue really and if it were we could make it a Kconfig
option or something.
>From what I have now understood, allocating GPU-only buffers should
be done with a device-specific ioctl. We then have a choice about
which DRM driver we should add that device-specific ioctl to. We could
either add it to the display controller's DRM or we could add it to
the GPU's DRM.
Adding it to the GPU's DRM requires user-space to jump through quite
a lot of hoops: In order to get both the scan-out GEM buffers and DRI2
GEM buffers in a single device's name-space, it would have to use
PRIME to export, say dumb scan-out buffers from the display's DRM as
dma_buf fds, then import those dma_buf fds into the GPU's DRM and then
use flink to give those imported scan-out buffers a name in the GPU's
DRM's namespace. Yuck.
No, I think it is easier to just add allocating GPU DRI2 buffers as
a device-specific ioctl on the display controller's DRM. Indeed, this
appears to be what OMAP and Exynos DRM drivers (and maybe others) do.
One device does all the allocations and thus all buffers are already
in the same namespace, no faffing with exporting & importing buffers
in the DDX required.
We will need to figure out a way in the xf86-video-armsoc DDX to
abstract those driver-specific allocation ioctls. Using GBM is an
interesting idea - looking at the interface it seems to be very,
_very_ similar to Android's gralloc! Though I don't see how to get
a system-wide name for a buffer I can pass back to a client via DRI2?
I assume gbm_bo_handle is process-local? In the short term, I think
we'll just use run-time detection
RE: [RFC 1/1] drm/pl111: Initial drm/kms driver for pl111
> >> > > > So in the above, after X receives the second DRI2SwapBuffers, > >> > > > it doesn't need to get scheduled again for the next frame to > >> > > > be both rendered by the GPU and issued to the display for > >> > > > scanout. > >> > > > >> > > well, this is really only an issue if you are so loaded that you > >> > > don't get a chance to schedule for ~16ms.. which is pretty long > >> > > time. > >> > >> Yes - it really is 16ms (minus interrupt/workqueue latency) isn't > >> it? Hmmm, that does sound very long. Will try out some experiments > >> and see. > > > > We're looking at moving the flip queue into the DDX driver, however > > it's not as straight-forward as I thought. With the current design, > > all rate-limiting happens on the client side. So even if you only > > > have double buffering, using KDS you can queue up as many > > asynchronous GPU-render/scan-out pairs as you want. It's up to EGL > > in the client application to figure out there's a lot of frames in- > > flight and so should probably block the application's render thread > > in eglSwapBuffers to let the GPU and/or display catch up a bit. > > > > If we only allow a single outstanding page-flip job in DRM, there'd > > > be a race if we returned a buffer to the client which had an > > outstanding page-flip queued up in the DDX: The client could issue > > > a render job to the buffer just as the DDX processed the page-flip > > from the queue, making the scan-out block until the GPU rendered > > the next frame. It would also mean the previous frame would have > > been lost as it never got scanned out before the GPU rendered the > > next-next frame to it. > > You wouldn't unconditionally send the swap-done event to the client > when the queue is "full". (Well, for omap and msm, the queue depth is > 1, for triple buffer.. I think usually you don't want to do more than > triple buffer.) The client would never get a buffer that wasn't > already done being scanned out, so there shouldn't be a race. > > Basically, in DDX, when you get a ScheduleSwap, there are two cases: > 1) you are still waiting for previous page-flip event from kernel, in > which case you queue the swap and don't immediately send the event > back to the client. When the previous page flip completes, you > schedule the new one and then send back the event to the client. > 2) you are not waiting for a previous page-flip, in which case you > schedule the new page-flip and send the event to the client. > > (I hope that is clear.. I suppose maybe a picture here would help, > but sadly I don't have anything handy) So your solution depends on the client-side EGL using page flip events to figure out when to block the application thread when CPU is running ahead of the GPU/display. We (currently) use the number of uncompleted frames sent to the GPU to block the application thread. So there is a race if we move the flip queue into the DDX and did nothing else. However, I'm not proposing we do nothing else. :-) Our proposal was to instead use waiting on the reply of the DRI2GetBuffers request to block the application thread when the client is submitting frames faster than the display can display them. I've not really looked into using the DRI2BufferSwapComplete in our EGL implementation - it always felt like we'd be at risk of the application somehow stealing the event and causing us to dead-lock. But - that may well be a completely irrational fear. :-) Anyway, I'll take a look, thanks for the pointer! Cheers, Tom ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/edid: add a helper function to extract the speaker allocation data block
On Wed, Aug 14, 2013 at 4:14 AM, Ville Syrjälä
wrote:
> On Tue, Aug 13, 2013 at 05:01:38PM -0400, Alex Deucher wrote:
>> This adds a helper function to extract the speaker allocation
>> data block from the EDID. This data block describes what speakers
>> are present on the display device.
>>
>> Signed-off-by: Alex Deucher
>> ---
>> drivers/gpu/drm/drm_edid.c | 50
>> ++
>> include/drm/drm_edid.h | 1 +
>> 2 files changed, 51 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 70fc133..bc16c80 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -2735,6 +2735,56 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
>> **sads)
>> EXPORT_SYMBOL(drm_edid_to_sad);
>>
>> /**
>> + * drm_edid_to_speaker_allocation - extracts Speaker Allocation Data Blocks
>> from EDID
>> + * @edid: EDID to parse
>> + * @sadb: pointer to the speaker block
>> + *
>> + * Looks for CEA EDID block and extracts the Speaker Allocation Data Block
>> from it.
>> + *
>> + * Return number of found Speaker Allocation Blocks or negative number on
>> error.
>> + */
>> +int drm_edid_to_speaker_allocation(struct edid *edid, u8 *sadb)
>> +{
>> + int count = 0;
>> + int i, start, end, dbl;
>> + u8 *cea;
>
> Can be const.
>
fixed.
>> +
>> + cea = drm_find_cea_extension(edid);
>> + if (!cea) {
>> + DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
>> + return -ENOENT;
>> + }
>> +
>> + if (cea_revision(cea) < 3) {
>> + DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
>> + return -ENOTSUPP;
>> + }
>> +
>> + if (cea_db_offsets(cea, &start, &end)) {
>> + DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
>> + return -EPROTO;
>> + }
>> +
>> + for_each_cea_db(cea, i, start, end) {
>> + u8 *db = &cea[i];
>
> Also const.
fixed.
>
>> +
>> + if (cea_db_tag(db) == SPEAKER_BLOCK) {
>> + dbl = cea_db_payload_len(db);
>> +
>> + /* Speaker Allocation Data Block */
>> + if (dbl >= 1) {
>
> CEA-861-E says the length must be exactly 3. Maybe we should be
> strict with this check?
>
Sure.
> Also the second payload byte also contains three valid bits. Do
> we not care about those speakers?
Updated patches on the way.
Alex
>
>> + *sadb = db[1];
>> + count = 1;
>> + break;
>> + }
>> + }
>> + }
>> +
>> + return count;
>> +}
>> +EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
>> +
>> +/**
>> * drm_av_sync_delay - HDMI/DP sink audio-video sync delay in millisecond
>> * @connector: connector associated with the HDMI/DP sink
>> * @mode: the display mode
>> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
>> index fc481fc..22d7985 100644
>> --- a/include/drm/drm_edid.h
>> +++ b/include/drm/drm_edid.h
>> @@ -259,6 +259,7 @@ struct hdmi_avi_infoframe;
>>
>> void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
>> int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
>> +int drm_edid_to_speaker_allocation(struct edid *edid, u8 *sadb);
>> int drm_av_sync_delay(struct drm_connector *connector,
>> struct drm_display_mode *mode);
>> struct drm_connector *drm_select_eld(struct drm_encoder *encoder,
>> --
>> 1.8.3.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/radeon: use loop for initializing AFMT blocks
From: Rafał Miłecki
Signed-off-by: Rafał Miłecki
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_display.c | 53 ++---
1 file changed, 23 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index c2b67b4..31d9fbe 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1257,38 +1257,31 @@ static void radeon_afmt_init(struct radeon_device *rdev)
if (ASIC_IS_DCE6(rdev)) {
/* todo */
} else if (ASIC_IS_DCE4(rdev)) {
+ static uint32_t eg_offsets[] = {
+ EVERGREEN_CRTC0_REGISTER_OFFSET,
+ EVERGREEN_CRTC1_REGISTER_OFFSET,
+ EVERGREEN_CRTC2_REGISTER_OFFSET,
+ EVERGREEN_CRTC3_REGISTER_OFFSET,
+ EVERGREEN_CRTC4_REGISTER_OFFSET,
+ EVERGREEN_CRTC5_REGISTER_OFFSET,
+ };
+ int num_afmt;
+
/* DCE4/5 has 6 audio blocks tied to DIG encoders */
/* DCE4.1 has 2 audio blocks tied to DIG encoders */
- rdev->mode_info.afmt[0] = kzalloc(sizeof(struct radeon_afmt),
GFP_KERNEL);
- if (rdev->mode_info.afmt[0]) {
- rdev->mode_info.afmt[0]->offset =
EVERGREEN_CRTC0_REGISTER_OFFSET;
- rdev->mode_info.afmt[0]->id = 0;
- }
- rdev->mode_info.afmt[1] = kzalloc(sizeof(struct radeon_afmt),
GFP_KERNEL);
- if (rdev->mode_info.afmt[1]) {
- rdev->mode_info.afmt[1]->offset =
EVERGREEN_CRTC1_REGISTER_OFFSET;
- rdev->mode_info.afmt[1]->id = 1;
- }
- if (!ASIC_IS_DCE41(rdev)) {
- rdev->mode_info.afmt[2] = kzalloc(sizeof(struct
radeon_afmt), GFP_KERNEL);
- if (rdev->mode_info.afmt[2]) {
- rdev->mode_info.afmt[2]->offset =
EVERGREEN_CRTC2_REGISTER_OFFSET;
- rdev->mode_info.afmt[2]->id = 2;
- }
- rdev->mode_info.afmt[3] = kzalloc(sizeof(struct
radeon_afmt), GFP_KERNEL);
- if (rdev->mode_info.afmt[3]) {
- rdev->mode_info.afmt[3]->offset =
EVERGREEN_CRTC3_REGISTER_OFFSET;
- rdev->mode_info.afmt[3]->id = 3;
- }
- rdev->mode_info.afmt[4] = kzalloc(sizeof(struct
radeon_afmt), GFP_KERNEL);
- if (rdev->mode_info.afmt[4]) {
- rdev->mode_info.afmt[4]->offset =
EVERGREEN_CRTC4_REGISTER_OFFSET;
- rdev->mode_info.afmt[4]->id = 4;
- }
- rdev->mode_info.afmt[5] = kzalloc(sizeof(struct
radeon_afmt), GFP_KERNEL);
- if (rdev->mode_info.afmt[5]) {
- rdev->mode_info.afmt[5]->offset =
EVERGREEN_CRTC5_REGISTER_OFFSET;
- rdev->mode_info.afmt[5]->id = 5;
+ if (ASIC_IS_DCE5(rdev))
+ num_afmt = 6;
+ else if (ASIC_IS_DCE41(rdev))
+ num_afmt = 2;
+ else /* DCE4 */
+ num_afmt = 6;
+
+ BUG_ON(num_afmt > ARRAY_SIZE(eg_offsets));
+ for (i = 0; i < num_afmt; i++) {
+ rdev->mode_info.afmt[i] = kzalloc(sizeof(struct
radeon_afmt), GFP_KERNEL);
+ if (rdev->mode_info.afmt[i]) {
+ rdev->mode_info.afmt[i]->offset = eg_offsets[i];
+ rdev->mode_info.afmt[i]->id = i;
}
}
} else if (ASIC_IS_DCE3(rdev)) {
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/radeon: add audio support for DCE6/8 GPUs (v9)
Similar to DCE4/5, but supports multiple audio pins
which can be assigned per afmt block.
v2: rework the driver to handle more than one audio
pin.
v3: try different dto reg
v4: properly program dto
v5 (ck): change dto programming order
v6: program speaker allocation block
v7: rebase
v8: rebase on Rafał's changes
v9: integrated Rafał's comments, update to latest
drm_edid_to_speaker_allocation API
Signed-off-by: Alex Deucher
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/Makefile| 2 +-
drivers/gpu/drm/radeon/atombios_encoders.c | 11 +-
drivers/gpu/drm/radeon/cik.c | 5 +
drivers/gpu/drm/radeon/dce6_afmt.c | 250 +
drivers/gpu/drm/radeon/evergreen_hdmi.c| 54 +--
drivers/gpu/drm/radeon/ni.c| 17 +-
drivers/gpu/drm/radeon/r600_audio.c| 58 ---
drivers/gpu/drm/radeon/r600_hdmi.c | 7 +-
drivers/gpu/drm/radeon/radeon.h| 18 ++-
drivers/gpu/drm/radeon/radeon_asic.c | 8 +
drivers/gpu/drm/radeon/radeon_asic.h | 4 +-
drivers/gpu/drm/radeon/radeon_display.c| 13 +-
drivers/gpu/drm/radeon/radeon_mode.h | 3 +-
drivers/gpu/drm/radeon/si.c| 5 +
drivers/gpu/drm/radeon/sid.h | 59 +++
15 files changed, 452 insertions(+), 62 deletions(-)
create mode 100644 drivers/gpu/drm/radeon/dce6_afmt.c
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index da2a8e9..306364a 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -80,7 +80,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
- ci_dpm.o
+ ci_dpm.o dce6_afmt.o
# add async DMA block
radeon-y += \
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 092275d..dfac796 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -682,8 +682,6 @@ atombios_digital_setup(struct drm_encoder *encoder, int
action)
int
atombios_get_encoder_mode(struct drm_encoder *encoder)
{
- struct drm_device *dev = encoder->dev;
- struct radeon_device *rdev = dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct drm_connector *connector;
struct radeon_connector *radeon_connector;
@@ -710,8 +708,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
case DRM_MODE_CONNECTOR_DVII:
case DRM_MODE_CONNECTOR_HDMIB: /* HDMI-B is basically DL-DVI; analog
works fine */
if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
- radeon_audio &&
- !ASIC_IS_DCE6(rdev)) /* remove once we support DCE6 */
+ radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else if (radeon_connector->use_digital)
return ATOM_ENCODER_MODE_DVI;
@@ -722,8 +719,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
case DRM_MODE_CONNECTOR_HDMIA:
default:
if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
- radeon_audio &&
- !ASIC_IS_DCE6(rdev)) /* remove once we support DCE6 */
+ radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else
return ATOM_ENCODER_MODE_DVI;
@@ -737,8 +733,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
(dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP))
return ATOM_ENCODER_MODE_DP;
else if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
-radeon_audio &&
-!ASIC_IS_DCE6(rdev)) /* remove once we support DCE6 */
+radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else
return ATOM_ENCODER_MODE_DVI;
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 01fd886..c2f78dc 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7093,6 +7093,10 @@ static int cik_startup(struct radeon_device *rdev)
return r;
}
+ r = dce6_audio_init(rdev);
+ if (r)
+ return r;
+
return 0;
}
@@ -7138,6 +7142,7 @@ int cik_resume(struct radeon_device *rdev)
*/
int cik_suspend(struct radeon_device *rdev)
{
+ dce6_audio_fini(rdev);
radeon_vm_manager_fini(rdev);
cik_cp_enable(rdev, false);
cik_sdma_enable(rdev, false);
diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c
b/drivers/gpu/dr
Re: [PATCH 1/3] drm/edid: add a helper function to extract the speaker allocation data block (v2)
On Wed, Aug 14, 2013 at 12:08:13PM -0400, Alex Deucher wrote:
> This adds a helper function to extract the speaker allocation
> data block from the EDID. This data block describes what speakers
> are present on the display device.
>
> v2: update per Ville Syrjälä's comments
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_edid.c | 52
> ++
> include/drm/drm_edid.h | 1 +
> 2 files changed, 53 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 70fc133..2e36d28 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2735,6 +2735,58 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
> **sads)
> EXPORT_SYMBOL(drm_edid_to_sad);
>
> /**
> + * drm_edid_to_speaker_allocation - extracts Speaker Allocation Data Blocks
> from EDID
> + * @edid: EDID to parse
> + * @sadb: pointer to the speaker block
> + *
> + * Looks for CEA EDID block and extracts the Speaker Allocation Data Block
> from it.
> + * Note: returned pointer needs to be kfreed
> + *
> + * Return number of found Speaker Allocation Blocks or negative number on
> error.
> + */
> +int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb)
> +{
> + int count = 0;
> + int i, start, end, dbl;
> + const u8 *cea;
> +
> + cea = drm_find_cea_extension(edid);
> + if (!cea) {
> + DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
> + return -ENOENT;
> + }
> +
> + if (cea_revision(cea) < 3) {
> + DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
> + return -ENOTSUPP;
> + }
> +
> + if (cea_db_offsets(cea, &start, &end)) {
> + DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
> + return -EPROTO;
> + }
> +
> + for_each_cea_db(cea, i, start, end) {
> + const u8 *db = &cea[i];
> +
> + if (cea_db_tag(db) == SPEAKER_BLOCK) {
> + dbl = cea_db_payload_len(db);
> +
> + /* Speaker Allocation Data Block */
> + if (dbl == 3) {
> + *sadb = kcalloc(count, dbl, GFP_KERNEL);
'count' not initialized yet. I suppose it was supposed to be just
kmalloc(dbl, GFP_KERNEL). But since it's just three bytes, making
the user just pass in a pointer to u32 would work just as well
w/o requiring the dynamic alloc/free.
> + memcpy(*sadb, &db[1], dbl);
> + count = dbl;
> + break;
> + }
> + }
> + }
> +
> + return count;
> +}
> +EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
> +
> +/**
> * drm_av_sync_delay - HDMI/DP sink audio-video sync delay in millisecond
> * @connector: connector associated with the HDMI/DP sink
> * @mode: the display mode
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index fc481fc..c76a129 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -259,6 +259,7 @@ struct hdmi_avi_infoframe;
>
> void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
> int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
> +int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
> int drm_av_sync_delay(struct drm_connector *connector,
> struct drm_display_mode *mode);
> struct drm_connector *drm_select_eld(struct drm_encoder *encoder,
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/edid: add a helper function to extract the speaker allocation data block (v2)
This adds a helper function to extract the speaker allocation
data block from the EDID. This data block describes what speakers
are present on the display device.
v2: update per Ville Syrjälä's comments
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/drm_edid.c | 52 ++
include/drm/drm_edid.h | 1 +
2 files changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 70fc133..2e36d28 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2735,6 +2735,58 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
**sads)
EXPORT_SYMBOL(drm_edid_to_sad);
/**
+ * drm_edid_to_speaker_allocation - extracts Speaker Allocation Data Blocks
from EDID
+ * @edid: EDID to parse
+ * @sadb: pointer to the speaker block
+ *
+ * Looks for CEA EDID block and extracts the Speaker Allocation Data Block
from it.
+ * Note: returned pointer needs to be kfreed
+ *
+ * Return number of found Speaker Allocation Blocks or negative number on
error.
+ */
+int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb)
+{
+ int count = 0;
+ int i, start, end, dbl;
+ const u8 *cea;
+
+ cea = drm_find_cea_extension(edid);
+ if (!cea) {
+ DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
+ return -ENOENT;
+ }
+
+ if (cea_revision(cea) < 3) {
+ DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
+ return -ENOTSUPP;
+ }
+
+ if (cea_db_offsets(cea, &start, &end)) {
+ DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
+ return -EPROTO;
+ }
+
+ for_each_cea_db(cea, i, start, end) {
+ const u8 *db = &cea[i];
+
+ if (cea_db_tag(db) == SPEAKER_BLOCK) {
+ dbl = cea_db_payload_len(db);
+
+ /* Speaker Allocation Data Block */
+ if (dbl == 3) {
+ *sadb = kcalloc(count, dbl, GFP_KERNEL);
+ memcpy(*sadb, &db[1], dbl);
+ count = dbl;
+ break;
+ }
+ }
+ }
+
+ return count;
+}
+EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
+
+/**
* drm_av_sync_delay - HDMI/DP sink audio-video sync delay in millisecond
* @connector: connector associated with the HDMI/DP sink
* @mode: the display mode
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index fc481fc..c76a129 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -259,6 +259,7 @@ struct hdmi_avi_infoframe;
void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
+int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
int drm_av_sync_delay(struct drm_connector *connector,
struct drm_display_mode *mode);
struct drm_connector *drm_select_eld(struct drm_encoder *encoder,
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/edid: add a helper function to extract the speaker allocation data block (v2)
On Wed, Aug 14, 2013 at 12:17 PM, Ville Syrjälä
wrote:
> On Wed, Aug 14, 2013 at 12:08:13PM -0400, Alex Deucher wrote:
>> This adds a helper function to extract the speaker allocation
>> data block from the EDID. This data block describes what speakers
>> are present on the display device.
>>
>> v2: update per Ville Syrjälä's comments
>>
>> Signed-off-by: Alex Deucher
>> ---
>> drivers/gpu/drm/drm_edid.c | 52
>> ++
>> include/drm/drm_edid.h | 1 +
>> 2 files changed, 53 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 70fc133..2e36d28 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -2735,6 +2735,58 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
>> **sads)
>> EXPORT_SYMBOL(drm_edid_to_sad);
>>
>> /**
>> + * drm_edid_to_speaker_allocation - extracts Speaker Allocation Data Blocks
>> from EDID
>> + * @edid: EDID to parse
>> + * @sadb: pointer to the speaker block
>> + *
>> + * Looks for CEA EDID block and extracts the Speaker Allocation Data Block
>> from it.
>> + * Note: returned pointer needs to be kfreed
>> + *
>> + * Return number of found Speaker Allocation Blocks or negative number on
>> error.
>> + */
>> +int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb)
>> +{
>> + int count = 0;
>> + int i, start, end, dbl;
>> + const u8 *cea;
>> +
>> + cea = drm_find_cea_extension(edid);
>> + if (!cea) {
>> + DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
>> + return -ENOENT;
>> + }
>> +
>> + if (cea_revision(cea) < 3) {
>> + DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
>> + return -ENOTSUPP;
>> + }
>> +
>> + if (cea_db_offsets(cea, &start, &end)) {
>> + DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
>> + return -EPROTO;
>> + }
>> +
>> + for_each_cea_db(cea, i, start, end) {
>> + const u8 *db = &cea[i];
>> +
>> + if (cea_db_tag(db) == SPEAKER_BLOCK) {
>> + dbl = cea_db_payload_len(db);
>> +
>> + /* Speaker Allocation Data Block */
>> + if (dbl == 3) {
>> + *sadb = kcalloc(count, dbl, GFP_KERNEL);
>
> 'count' not initialized yet. I suppose it was supposed to be just
> kmalloc(dbl, GFP_KERNEL). But since it's just three bytes, making
> the user just pass in a pointer to u32 would work just as well
> w/o requiring the dynamic alloc/free.
whoops, that was just a copy paste error. I'll fix that.
I suppose we could just use a u32 unless the size of the block changes
in the future.
Alex
>
>> + memcpy(*sadb, &db[1], dbl);
>> + count = dbl;
>> + break;
>> + }
>> + }
>> + }
>> +
>> + return count;
>> +}
>> +EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
>> +
>> +/**
>> * drm_av_sync_delay - HDMI/DP sink audio-video sync delay in millisecond
>> * @connector: connector associated with the HDMI/DP sink
>> * @mode: the display mode
>> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
>> index fc481fc..c76a129 100644
>> --- a/include/drm/drm_edid.h
>> +++ b/include/drm/drm_edid.h
>> @@ -259,6 +259,7 @@ struct hdmi_avi_infoframe;
>>
>> void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
>> int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
>> +int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
>> int drm_av_sync_delay(struct drm_connector *connector,
>> struct drm_display_mode *mode);
>> struct drm_connector *drm_select_eld(struct drm_encoder *encoder,
>> --
>> 1.8.3.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/radeon: add audio support for DCE6/8 GPUs (v9)
2013/8/14 Alex Deucher :
> +static u32 dce6_endpoint_rreg(struct radeon_device *rdev,
> + u32 block_offset, u32 reg)
> +{
> + u32 r;
> +
> + WREG32(AZ_F0_CODEC_ENDPOINT_INDEX + block_offset, reg);
> + r = RREG32(AZ_F0_CODEC_ENDPOINT_DATA + block_offset);
> + return r;
> +}
> +
> +static void dce6_endpoint_wreg(struct radeon_device *rdev,
> + u32 block_offset, u32 reg, u32 v)
> +{
> + if (ASIC_IS_DCE8(rdev))
> + WREG32(AZ_F0_CODEC_ENDPOINT_INDEX + block_offset, reg);
> + else
> + WREG32(AZ_F0_CODEC_ENDPOINT_INDEX + block_offset,
> + AZ_ENDPOINT_REG_WRITE_EN | AZ_ENDPOINT_REG_INDEX(reg));
> + WREG32(AZ_F0_CODEC_ENDPOINT_DATA + block_offset, v);
> +}
Thanks!
> +struct r600_audio_pin *dce6_audio_get_pin(struct radeon_device *rdev)
> +{
> + int i;
> +
> + dce6_afmt_get_connected_pins(rdev);
> +
> + for (i = 0; i < rdev->audio.num_pins; i++) {
> + if (rdev->audio.pin[i].connected)
> + return &rdev->audio.pin[i];
> + }
> + DRM_ERROR("No connected audio pins found!");
> + return NULL;
> +}
You missed the line break. Sorry I didn't spot it earlier :/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/edid: add a helper function to extract the speaker allocation data block (v3)
This adds a helper function to extract the speaker allocation
data block from the EDID. This data block describes what speakers
are present on the display device.
v2: update per Ville Syrjälä's comments
v3: fix copy/paste typo in memory allocation
Signed-off-by: Alex Deucher
---
Fixed the malloc issue. I can switch to passing a u32 if that is preferred.
drivers/gpu/drm/drm_edid.c | 52 ++
include/drm/drm_edid.h | 1 +
2 files changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 70fc133..58b4882 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2735,6 +2735,58 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
**sads)
EXPORT_SYMBOL(drm_edid_to_sad);
/**
+ * drm_edid_to_speaker_allocation - extracts Speaker Allocation Data Blocks
from EDID
+ * @edid: EDID to parse
+ * @sadb: pointer to the speaker block
+ *
+ * Looks for CEA EDID block and extracts the Speaker Allocation Data Block
from it.
+ * Note: returned pointer needs to be kfreed
+ *
+ * Return number of found Speaker Allocation Blocks or negative number on
error.
+ */
+int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb)
+{
+ int count = 0;
+ int i, start, end, dbl;
+ const u8 *cea;
+
+ cea = drm_find_cea_extension(edid);
+ if (!cea) {
+ DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
+ return -ENOENT;
+ }
+
+ if (cea_revision(cea) < 3) {
+ DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
+ return -ENOTSUPP;
+ }
+
+ if (cea_db_offsets(cea, &start, &end)) {
+ DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
+ return -EPROTO;
+ }
+
+ for_each_cea_db(cea, i, start, end) {
+ const u8 *db = &cea[i];
+
+ if (cea_db_tag(db) == SPEAKER_BLOCK) {
+ dbl = cea_db_payload_len(db);
+
+ /* Speaker Allocation Data Block */
+ if (dbl == 3) {
+ *sadb = kmalloc(dbl, GFP_KERNEL);
+ memcpy(*sadb, &db[1], dbl);
+ count = dbl;
+ break;
+ }
+ }
+ }
+
+ return count;
+}
+EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
+
+/**
* drm_av_sync_delay - HDMI/DP sink audio-video sync delay in millisecond
* @connector: connector associated with the HDMI/DP sink
* @mode: the display mode
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index fc481fc..c76a129 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -259,6 +259,7 @@ struct hdmi_avi_infoframe;
void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
+int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
int drm_av_sync_delay(struct drm_connector *connector,
struct drm_display_mode *mode);
struct drm_connector *drm_select_eld(struct drm_encoder *encoder,
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/radeon: add audio support for DCE6/8 GPUs (v10)
Similar to DCE4/5, but supports multiple audio pins
which can be assigned per afmt block.
v2: rework the driver to handle more than one audio
pin.
v3: try different dto reg
v4: properly program dto
v5 (ck): change dto programming order
v6: program speaker allocation block
v7: rebase
v8: rebase on Rafał's changes
v9: integrated Rafał's comments, update to latest
drm_edid_to_speaker_allocation API
v10: add missing line break in error message
Signed-off-by: Alex Deucher
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/Makefile| 2 +-
drivers/gpu/drm/radeon/atombios_encoders.c | 11 +-
drivers/gpu/drm/radeon/cik.c | 5 +
drivers/gpu/drm/radeon/dce6_afmt.c | 250 +
drivers/gpu/drm/radeon/evergreen_hdmi.c| 54 +--
drivers/gpu/drm/radeon/ni.c| 17 +-
drivers/gpu/drm/radeon/r600_audio.c| 58 ---
drivers/gpu/drm/radeon/r600_hdmi.c | 7 +-
drivers/gpu/drm/radeon/radeon.h| 18 ++-
drivers/gpu/drm/radeon/radeon_asic.c | 8 +
drivers/gpu/drm/radeon/radeon_asic.h | 4 +-
drivers/gpu/drm/radeon/radeon_display.c| 13 +-
drivers/gpu/drm/radeon/radeon_mode.h | 3 +-
drivers/gpu/drm/radeon/si.c| 5 +
drivers/gpu/drm/radeon/sid.h | 59 +++
15 files changed, 452 insertions(+), 62 deletions(-)
create mode 100644 drivers/gpu/drm/radeon/dce6_afmt.c
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index da2a8e9..306364a 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -80,7 +80,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
- ci_dpm.o
+ ci_dpm.o dce6_afmt.o
# add async DMA block
radeon-y += \
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 092275d..dfac796 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -682,8 +682,6 @@ atombios_digital_setup(struct drm_encoder *encoder, int
action)
int
atombios_get_encoder_mode(struct drm_encoder *encoder)
{
- struct drm_device *dev = encoder->dev;
- struct radeon_device *rdev = dev->dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct drm_connector *connector;
struct radeon_connector *radeon_connector;
@@ -710,8 +708,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
case DRM_MODE_CONNECTOR_DVII:
case DRM_MODE_CONNECTOR_HDMIB: /* HDMI-B is basically DL-DVI; analog
works fine */
if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
- radeon_audio &&
- !ASIC_IS_DCE6(rdev)) /* remove once we support DCE6 */
+ radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else if (radeon_connector->use_digital)
return ATOM_ENCODER_MODE_DVI;
@@ -722,8 +719,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
case DRM_MODE_CONNECTOR_HDMIA:
default:
if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
- radeon_audio &&
- !ASIC_IS_DCE6(rdev)) /* remove once we support DCE6 */
+ radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else
return ATOM_ENCODER_MODE_DVI;
@@ -737,8 +733,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
(dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP))
return ATOM_ENCODER_MODE_DP;
else if (drm_detect_hdmi_monitor(radeon_connector->edid) &&
-radeon_audio &&
-!ASIC_IS_DCE6(rdev)) /* remove once we support DCE6 */
+radeon_audio)
return ATOM_ENCODER_MODE_HDMI;
else
return ATOM_ENCODER_MODE_DVI;
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 01fd886..c2f78dc 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7093,6 +7093,10 @@ static int cik_startup(struct radeon_device *rdev)
return r;
}
+ r = dce6_audio_init(rdev);
+ if (r)
+ return r;
+
return 0;
}
@@ -7138,6 +7142,7 @@ int cik_resume(struct radeon_device *rdev)
*/
int cik_suspend(struct radeon_device *rdev)
{
+ dce6_audio_fini(rdev);
radeon_vm_manager_fini(rdev);
cik_cp_enable(rdev, false);
cik_sdma_enable(rdev, false);
diff --git a/drivers
Re: [PATCH 1/3] drm/edid: add a helper function to extract the speaker allocation data block (v3)
On Wed, Aug 14, 2013 at 12:30:21PM -0400, Alex Deucher wrote:
> This adds a helper function to extract the speaker allocation
> data block from the EDID. This data block describes what speakers
> are present on the display device.
>
> v2: update per Ville Syrjälä's comments
> v3: fix copy/paste typo in memory allocation
>
> Signed-off-by: Alex Deucher
> ---
>
> Fixed the malloc issue. I can switch to passing a u32 if that is preferred.
At least the kmalloc adds a bit of symmetry between this and the SAD
extractor. So I'll hand out an r-b for this one in case there's no u32
version coming. But I'd be OK w/ the u32 approach too.
Reviewed-by: Ville Syrjälä
>
> drivers/gpu/drm/drm_edid.c | 52
> ++
> include/drm/drm_edid.h | 1 +
> 2 files changed, 53 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 70fc133..58b4882 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2735,6 +2735,58 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
> **sads)
> EXPORT_SYMBOL(drm_edid_to_sad);
>
> /**
> + * drm_edid_to_speaker_allocation - extracts Speaker Allocation Data Blocks
> from EDID
> + * @edid: EDID to parse
> + * @sadb: pointer to the speaker block
> + *
> + * Looks for CEA EDID block and extracts the Speaker Allocation Data Block
> from it.
> + * Note: returned pointer needs to be kfreed
> + *
> + * Return number of found Speaker Allocation Blocks or negative number on
> error.
> + */
> +int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb)
> +{
> + int count = 0;
> + int i, start, end, dbl;
> + const u8 *cea;
> +
> + cea = drm_find_cea_extension(edid);
> + if (!cea) {
> + DRM_DEBUG_KMS("SAD: no CEA Extension found\n");
> + return -ENOENT;
> + }
> +
> + if (cea_revision(cea) < 3) {
> + DRM_DEBUG_KMS("SAD: wrong CEA revision\n");
> + return -ENOTSUPP;
> + }
> +
> + if (cea_db_offsets(cea, &start, &end)) {
> + DRM_DEBUG_KMS("SAD: invalid data block offsets\n");
> + return -EPROTO;
> + }
> +
> + for_each_cea_db(cea, i, start, end) {
> + const u8 *db = &cea[i];
> +
> + if (cea_db_tag(db) == SPEAKER_BLOCK) {
> + dbl = cea_db_payload_len(db);
> +
> + /* Speaker Allocation Data Block */
> + if (dbl == 3) {
> + *sadb = kmalloc(dbl, GFP_KERNEL);
> + memcpy(*sadb, &db[1], dbl);
> + count = dbl;
> + break;
> + }
> + }
> + }
> +
> + return count;
> +}
> +EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
> +
> +/**
> * drm_av_sync_delay - HDMI/DP sink audio-video sync delay in millisecond
> * @connector: connector associated with the HDMI/DP sink
> * @mode: the display mode
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index fc481fc..c76a129 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -259,6 +259,7 @@ struct hdmi_avi_infoframe;
>
> void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
> int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
> +int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
> int drm_av_sync_delay(struct drm_connector *connector,
> struct drm_display_mode *mode);
> struct drm_connector *drm_select_eld(struct drm_encoder *encoder,
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay
https://bugs.freedesktop.org/show_bug.cgi?id=56659 --- Comment #7 from russianneuroman...@ya.ru --- Still issue with Linux 3.11rc5, radeon driver 7.1.99+git20130730.6a278369, Mesa 9.2.0~git20130729 and KDE 4.11rc2. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60674] linux 3.10.x RV740 (Radeon HD 4770) display problem
https://bugzilla.kernel.org/show_bug.cgi?id=60674 --- Comment #9 from Yves G. (theYinYeti) --- Sorry for the long time without an answer; I was on holidays. Just to be clear: the kernel (and associated packages for my setup) is the only component that changes; here’s the exact list: linux, linux-headers, spl-utils, spl, zfs-utils, zfs, virtualbox-host-modules. I don’t know how to “bissect” and all this stuf. However, I will try the patch suggested by Alex; thanks, by the way :) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
HDMI 4k support v3
Follow up on v2: http://lists.freedesktop.org/archives/dri-devel/2013-August/043604.html With the quick and nice reviews from Ville and Simon, it's time for a v3: - Fix embarrassing hmdi typo - Fix the sending of vendor specific infoframes for side-by-side half modes - Smaller changes here and there. -- Damien ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/12] drm: Don't export drm_find_cea_extension() any more
This function is only used inside drm_edid.c.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 5 ++---
include/drm/drm_crtc.h | 1 -
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dfc7a1b..e014785 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2298,10 +2298,10 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
#define EDID_CEA_YCRCB422 (1 << 4)
#define EDID_CEA_VCDB_QS (1 << 6)
-/**
+/*
* Search EDID for CEA extension block.
*/
-u8 *drm_find_cea_extension(struct edid *edid)
+static u8 *drm_find_cea_extension(struct edid *edid)
{
u8 *edid_ext = NULL;
int i;
@@ -2322,7 +2322,6 @@ u8 *drm_find_cea_extension(struct edid *edid)
return edid_ext;
}
-EXPORT_SYMBOL(drm_find_cea_extension);
/*
* Calculate the alternate clock for the CEA mode
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index fa12a2f..f3ecc6f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1050,7 +1050,6 @@ extern int drm_mode_gamma_get_ioctl(struct drm_device
*dev,
void *data, struct drm_file *file_priv);
extern int drm_mode_gamma_set_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
-extern u8 *drm_find_cea_extension(struct edid *edid);
extern u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
extern bool drm_detect_hdmi_monitor(struct edid *edid);
extern bool drm_detect_monitor_audio(struct edid *edid);
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/12] drm/edid: Fix add_cea_modes() style issues
A few styles issues have crept in here, fix them before touching this
code again.
v2: constify arguments that can be (Ville Syrjälä)
v3: constify, but better (Ville Syrjälä)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e014785..bb25ee2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2441,10 +2441,11 @@ add_alternate_cea_modes(struct drm_connector
*connector, struct edid *edid)
}
static int
-do_cea_modes (struct drm_connector *connector, u8 *db, u8 len)
+do_cea_modes(struct drm_connector *connector, const u8 *db, u8 len)
{
struct drm_device *dev = connector->dev;
- u8 * mode, cea_mode;
+ const u8 *mode;
+ u8 cea_mode;
int modes = 0;
for (mode = db; mode < db + len; mode++) {
@@ -2501,8 +2502,9 @@ cea_db_offsets(const u8 *cea, int *start, int *end)
static int
add_cea_modes(struct drm_connector *connector, struct edid *edid)
{
- u8 * cea = drm_find_cea_extension(edid);
- u8 * db, dbl;
+ const u8 *cea = drm_find_cea_extension(edid);
+ const u8 *db;
+ u8 dbl;
int modes = 0;
if (cea && cea_revision(cea) >= 3) {
@@ -2516,7 +2518,7 @@ add_cea_modes(struct drm_connector *connector, struct
edid *edid)
dbl = cea_db_payload_len(db);
if (cea_db_tag(db) == VIDEO_BLOCK)
- modes += do_cea_modes (connector, db+1, dbl);
+ modes += do_cea_modes(connector, db + 1, dbl);
}
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/12] drm/edid: Parse the HDMI CEA block and look for 4k modes
HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.
With this commit, we now parse this block and expose the 4k modes that
we find there.
v2: Fix the "4096x2160" string (nice catch!), add comments about
do_hdmi_vsdb_modes() arguments and make it clearer that offset is
relative to the end of the required fields of the HDMI VSDB
(Ville Syrjälä)
v3: Fix 'Unknow' typo (Simon Farnsworth)
Signed-off-by: Damien Lespiau
Tested-by: Cancan Feng
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
Reviewed-by: Simon Farnsworth
---
drivers/gpu/drm/drm_edid.c | 124 +++--
1 file changed, 109 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bb25ee2..9de573c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -931,6 +931,36 @@ static const struct drm_display_mode edid_cea_modes[] = {
.vrefresh = 100, },
};
+/*
+ * HDMI 1.4 4k modes.
+ */
+static const struct drm_display_mode edid_4k_modes[] = {
+ /* 1 - 3840x2160@30Hz */
+ { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000,
+ 3840, 4016, 4104, 4400, 0,
+ 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, },
+ /* 2 - 3840x2160@25Hz */
+ { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000,
+ 3840, 4896, 4984, 5280, 0,
+ 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, },
+ /* 3 - 3840x2160@24Hz */
+ { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 297000,
+ 3840, 5116, 5204, 5500, 0,
+ 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, },
+ /* 4 - 4096x2160@24Hz (SMPTE) */
+ { DRM_MODE("4096x2160", DRM_MODE_TYPE_DRIVER, 297000,
+ 4096, 5116, 5204, 5500, 0,
+ 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, },
+};
+
/*** DDC fetch and block validation ***/
static const u8 edid_header[] = {
@@ -2465,6 +2495,68 @@ do_cea_modes(struct drm_connector *connector, const u8
*db, u8 len)
return modes;
}
+/*
+ * do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
+ * @connector: connector corresponding to the HDMI sink
+ * @db: start of the CEA vendor specific block
+ * @len: length of the CEA block payload, ie. one can access up to db[len]
+ *
+ * Parses the HDMI VSDB looking for modes to add to @connector.
+ */
+static int
+do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
+{
+ struct drm_device *dev = connector->dev;
+ int modes = 0, offset = 0, i;
+ u8 vic_len;
+
+ if (len < 8)
+ goto out;
+
+ /* no HDMI_Video_Present */
+ if (!(db[8] & (1 << 5)))
+ goto out;
+
+ /* Latency_Fields_Present */
+ if (db[8] & (1 << 7))
+ offset += 2;
+
+ /* I_Latency_Fields_Present */
+ if (db[8] & (1 << 6))
+ offset += 2;
+
+ /* the declared length is not long enough for the 2 first bytes
+* of additional video format capabilities */
+ offset += 2;
+ if (len < (8 + offset))
+ goto out;
+
+ vic_len = db[8 + offset] >> 5;
+
+ for (i = 0; i < vic_len && len >= (9 + offset + i); i++) {
+ struct drm_display_mode *newmode;
+ u8 vic;
+
+ vic = db[9 + offset + i];
+
+ vic--; /* VICs start at 1 */
+ if (vic >= ARRAY_SIZE(edid_4k_modes)) {
+ DRM_ERROR("Unknown HDMI VIC: %d\n", vic);
+ continue;
+ }
+
+ newmode = drm_mode_duplicate(dev, &edid_4k_modes[vic]);
+ if (!newmode)
+ continue;
+
+ drm_mode_probed_add(connector, newmode);
+ modes++;
+ }
+
+out:
+ return modes;
+}
+
static int
cea_db_payload_len(const u8 *db)
{
@@ -2496,6 +2588,21 @@ cea_db_offsets(const u8 *cea, int *start, int *end)
return 0;
}
+static bool cea_db_is_hdmi_vsdb(const u8 *db)
+{
+ int hdmi_id;
+
+ if (cea_db_tag(db) != VENDOR_BLOCK)
+ return false;
+
+ if (cea_db_payload_len(db) < 5)
+ return false;
+
+ hdmi_id = db[1] | (db[2] << 8) | (db[3] << 16);
+
+ return hdmi_id == HDMI_IDENTIFIER;
+}
+
#define for_each_cea_db(cea, i, start, end) \
for ((i) = (start); (i) < (end) && (i) +
cea_db_payload_len(&(cea)[(i)]) < (end); (i) += cea_db_payload_len(&(cea)[(i)])
+ 1)
@@ -2519,6 +2626,8 @@ add_cea_modes(struct drm_connector *connector, struct
edid *edid)
if (cea_db_tag(db) == VIDE
[PATCH 04/12] drm: Add support for alternate clocks of 4k modes
v2: Fix hmdi typo (Simon Farnsworth, Ville Syrjälä)
Suggested-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
Reviewed-by: Simon Farnsworth
---
drivers/gpu/drm/drm_edid.c | 68 ++
1 file changed, 62 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9de573c..2381abd 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2409,6 +2409,54 @@ u8 drm_match_cea_mode(const struct drm_display_mode
*to_match)
}
EXPORT_SYMBOL(drm_match_cea_mode);
+/*
+ * Calculate the alternate clock for HDMI modes (those from the HDMI vendor
+ * specific block).
+ *
+ * It's almost like cea_mode_alternate_clock(), we just need to add an
+ * exception for the VIC 4 mode (4096x2160@24Hz): no alternate clock for this
+ * one.
+ */
+static unsigned int
+hdmi_mode_alternate_clock(const struct drm_display_mode *hdmi_mode)
+{
+ if (hdmi_mode->vdisplay == 4096 && hdmi_mode->hdisplay == 2160)
+ return hdmi_mode->clock;
+
+ return cea_mode_alternate_clock(hdmi_mode);
+}
+
+/*
+ * drm_match_hdmi_mode - look for a HDMI mode matching given mode
+ * @to_match: display mode
+ *
+ * An HDMI mode is one defined in the HDMI vendor specific block.
+ *
+ * Returns the HDMI Video ID (VIC) of the mode or 0 if it isn't one.
+ */
+static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match)
+{
+ u8 mode;
+
+ if (!to_match->clock)
+ return 0;
+
+ for (mode = 0; mode < ARRAY_SIZE(edid_4k_modes); mode++) {
+ const struct drm_display_mode *hdmi_mode = &edid_4k_modes[mode];
+ unsigned int clock1, clock2;
+
+ /* Make sure to also match alternate clocks */
+ clock1 = hdmi_mode->clock;
+ clock2 = hdmi_mode_alternate_clock(hdmi_mode);
+
+ if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) ||
+KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) &&
+ drm_mode_equal_no_clocks(to_match, hdmi_mode))
+ return mode + 1;
+ }
+ return 0;
+}
+
static int
add_alternate_cea_modes(struct drm_connector *connector, struct edid *edid)
{
@@ -2426,18 +2474,26 @@ add_alternate_cea_modes(struct drm_connector
*connector, struct edid *edid)
* with the alternate clock for certain CEA modes.
*/
list_for_each_entry(mode, &connector->probed_modes, head) {
- const struct drm_display_mode *cea_mode;
+ const struct drm_display_mode *cea_mode = NULL;
struct drm_display_mode *newmode;
- u8 cea_mode_idx = drm_match_cea_mode(mode) - 1;
+ u8 mode_idx = drm_match_cea_mode(mode) - 1;
unsigned int clock1, clock2;
- if (cea_mode_idx >= ARRAY_SIZE(edid_cea_modes))
- continue;
+ if (mode_idx < ARRAY_SIZE(edid_cea_modes)) {
+ cea_mode = &edid_cea_modes[mode_idx];
+ clock2 = cea_mode_alternate_clock(cea_mode);
+ } else {
+ mode_idx = drm_match_hdmi_mode(mode) - 1;
+ if (mode_idx < ARRAY_SIZE(edid_4k_modes)) {
+ cea_mode = &edid_4k_modes[mode_idx];
+ clock2 = hdmi_mode_alternate_clock(cea_mode);
+ }
+ }
- cea_mode = &edid_cea_modes[cea_mode_idx];
+ if (!cea_mode)
+ continue;
clock1 = cea_mode->clock;
- clock2 = cea_mode_alternate_clock(cea_mode);
if (clock1 == clock2)
continue;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/12] video/hdmi: Don't let the user of this API create invalid infoframes
To set the active aspect ratio value in the AVI infoframe today, you not
only have to set the active_aspect field, but also the active_info_valid
bit. Out of the 1 user of this API, we had 100% misuse, forgetting the
_valid bit. This was fixed in:
Author: Damien Lespiau
Date: Tue Aug 6 20:32:17 2013 +0100
drm: Don't generate invalid AVI infoframes for CEA modes
We can do better and derive the _valid bit from the user wanting to set
the active aspect ratio.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 1 -
drivers/video/hdmi.c | 4 +++-
include/linux/hdmi.h | 1 -
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 2381abd..d76d608 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3259,7 +3259,6 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
frame->video_code = drm_match_cea_mode(mode);
frame->picture_aspect = HDMI_PICTURE_ASPECT_NONE;
- frame->active_info_valid = 1;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
return 0;
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 635d569..e36da36 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -96,7 +96,9 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe
*frame, void *buffer,
ptr[0] = ((frame->colorspace & 0x3) << 5) | (frame->scan_mode & 0x3);
- if (frame->active_info_valid)
+ /* Data byte 1, bit 4 has to be set if we provide the active format
+* aspect ratio */
+ if (frame->active_aspect & 0xf)
ptr[0] |= BIT(4);
if (frame->horizontal_bar_valid)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index bc6743e..931474c6 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -109,7 +109,6 @@ struct hdmi_avi_infoframe {
unsigned char version;
unsigned char length;
enum hdmi_colorspace colorspace;
- bool active_info_valid;
bool horizontal_bar_valid;
bool vertical_bar_valid;
enum hdmi_scan_mode scan_mode;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/12] video/hdmi: Derive the bar data valid bit from the bar data fields
Just like:
Author: Damien Lespiau
Date: Mon Aug 12 11:53:24 2013 +0100
video/hdmi: Don't let the user of this API create invalid infoframes
But this time for the horizontal/vertical bar data present bits.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/video/hdmi.c | 5 +++--
include/linux/hdmi.h | 2 --
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index e36da36..ac84215 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -101,10 +101,11 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe
*frame, void *buffer,
if (frame->active_aspect & 0xf)
ptr[0] |= BIT(4);
- if (frame->horizontal_bar_valid)
+ /* Bit 3 and 2 indicate if we transmit horizontal/vertical bar data */
+ if (frame->top_bar || frame->bottom_bar)
ptr[0] |= BIT(3);
- if (frame->vertical_bar_valid)
+ if (frame->left_bar || frame->right_bar)
ptr[0] |= BIT(2);
ptr[1] = ((frame->colorimetry & 0x3) << 6) |
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 931474c6..b98340b 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -109,8 +109,6 @@ struct hdmi_avi_infoframe {
unsigned char version;
unsigned char length;
enum hdmi_colorspace colorspace;
- bool horizontal_bar_valid;
- bool vertical_bar_valid;
enum hdmi_scan_mode scan_mode;
enum hdmi_colorimetry colorimetry;
enum hdmi_picture_aspect picture_aspect;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/12] gpu: host1x: Port the HDMI vendor infoframe code the common helpers
I just wrote the bits to define and pack HDMI vendor specific infoframe.
Port the host1x driver to use those so I can refactor the infoframe code
a bit more.
This changes the length of the infoframe payload from 6 to 5, which is
enough for the "frame packing" stereo format.
v2: Pimp up the commit message with the note about the length
(Ville Syrjälä)
Cc: Thierry Reding
Cc: Terje Bergström
Cc: linux-te...@vger.kernel.org
Signed-off-by: Damien Lespiau
---
drivers/gpu/host1x/drm/hdmi.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
index 01097da..b548918 100644
--- a/drivers/gpu/host1x/drm/hdmi.c
+++ b/drivers/gpu/host1x/drm/hdmi.c
@@ -539,7 +539,7 @@ static void tegra_hdmi_setup_audio_infoframe(struct
tegra_hdmi *hdmi)
static void tegra_hdmi_setup_stereo_infoframe(struct tegra_hdmi *hdmi)
{
- struct hdmi_vendor_infoframe frame;
+ struct hdmi_hdmi_infoframe frame;
unsigned long value;
u8 buffer[10];
ssize_t err;
@@ -551,26 +551,10 @@ static void tegra_hdmi_setup_stereo_infoframe(struct
tegra_hdmi *hdmi)
return;
}
- memset(&frame, 0, sizeof(frame));
+ hdmi_hdmi_infoframe_init(&frame);
+ frame.s3d_struct = HDMI_3D_STRUCTURE_FRAME_PACKING;
- frame.type = HDMI_INFOFRAME_TYPE_VENDOR;
- frame.version = 0x01;
- frame.length = 6;
-
- frame.data[0] = 0x03; /* regid0 */
- frame.data[1] = 0x0c; /* regid1 */
- frame.data[2] = 0x00; /* regid2 */
- frame.data[3] = 0x02 << 5; /* video format */
-
- /* TODO: 74 MHz limit? */
- if (1) {
- frame.data[4] = 0x00 << 4; /* 3D structure */
- } else {
- frame.data[4] = 0x08 << 4; /* 3D structure */
- frame.data[5] = 0x00 << 4; /* 3D ext. data */
- }
-
- err = hdmi_vendor_infoframe_pack(&frame, buffer, sizeof(buffer));
+ err = hdmi_hdmi_infoframe_pack(&frame, buffer, sizeof(buffer));
if (err < 0) {
dev_err(hdmi->dev, "failed to pack vendor infoframe: %zd\n",
err);
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/12] video/hdmi: Introduce helpers for the HDMI vendor specific infoframe
Provide the same programming model than the other infoframe types.
The generic _pack() function can't handle those yet as we need to move
the vendor OUI in the generic hdmi_vendor_infoframe structure to know
which kind of vendor infoframe we are dealing with.
v2: Fix the value of Side-by-side (half), hmdi typo, pack 3D_Ext_Data
(Ville Syrjälä)
Signed-off-by: Damien Lespiau
---
drivers/video/hdmi.c | 88
include/linux/hdmi.h | 26
2 files changed, 114 insertions(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index ac84215..59c4748 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -286,6 +286,94 @@ ssize_t hdmi_audio_infoframe_pack(struct
hdmi_audio_infoframe *frame,
EXPORT_SYMBOL(hdmi_audio_infoframe_pack);
/**
+ * hdmi_hdmi_infoframe_init() - initialize an HDMI vendor infoframe
+ * @frame: HDMI vendor infoframe
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_hdmi_infoframe_init(struct hdmi_hdmi_infoframe *frame)
+{
+ memset(frame, 0, sizeof(*frame));
+
+ frame->type = HDMI_INFOFRAME_TYPE_VENDOR;
+ frame->version = 1;
+
+ /* 0 is a valid value for s3d_struct, so we use a special "not set"
+* value */
+ frame->s3d_struct = HDMI_3D_STRUCTURE_INVALID;
+
+ return 0;
+}
+EXPORT_SYMBOL(hdmi_hdmi_infoframe_init);
+
+/**
+ * hdmi_hdmi_infoframe_pack() - write a HDMI vendor infoframe to binary buffer
+ * @frame: HDMI infoframe
+ * @buffer: destination buffer
+ * @size: size of buffer
+ *
+ * Packs the information contained in the @frame structure into a binary
+ * representation that can be written into the corresponding controller
+ * registers. Also computes the checksum as required by section 5.3.5 of
+ * the HDMI 1.4 specification.
+ *
+ * Returns the number of bytes packed into the binary buffer or a negative
+ * error code on failure.
+ */
+ssize_t hdmi_hdmi_infoframe_pack(struct hdmi_hdmi_infoframe *frame,
+void *buffer, size_t size)
+{
+ u8 *ptr = buffer;
+ size_t length;
+
+ /* empty info frame */
+ if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
+ return -EINVAL;
+
+ /* only one of those can be supplied */
+ if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
+ return -EINVAL;
+
+ /* for side by side (half) we also need to provide 3D_Ext_Data */
+ if (frame->s3d_struct == HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
+ frame->length = 6;
+ else
+ frame->length = 5;
+
+ length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
+
+ if (size < length)
+ return -ENOSPC;
+
+ memset(buffer, 0, size);
+
+ ptr[0] = frame->type;
+ ptr[1] = frame->version;
+ ptr[2] = frame->length;
+ ptr[3] = 0; /* checksum */
+
+ /* HDMI OUI */
+ ptr[4] = 0x03;
+ ptr[5] = 0x0c;
+ ptr[6] = 0x00;
+
+ if (frame->vic) {
+ ptr[7] = 0x1 << 5; /* video format */
+ ptr[8] = frame->vic;
+ } else {
+ ptr[7] = 0x2 << 5; /* video format */
+ ptr[8] = (frame->s3d_struct & 0xf) << 4;
+ if (frame->s3d_struct == HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
+ ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
+ }
+
+ hdmi_infoframe_checksum(buffer, length);
+
+ return length;
+}
+EXPORT_SYMBOL(hdmi_hdmi_infoframe_pack);
+
+/**
* hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary
*buffer
* @frame: HDMI vendor infoframe
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index b98340b..e733252 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -234,11 +234,37 @@ struct hdmi_vendor_infoframe {
ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,
void *buffer, size_t size);
+enum hdmi_3d_structure {
+ HDMI_3D_STRUCTURE_INVALID = -1,
+ HDMI_3D_STRUCTURE_FRAME_PACKING = 0,
+ HDMI_3D_STRUCTURE_FIELD_ALTERNATIVE,
+ HDMI_3D_STRUCTURE_LINE_ALTERNATIVE,
+ HDMI_3D_STRUCTURE_SIDE_BY_SIDE_FULL,
+ HDMI_3D_STRUCTURE_L_DEPTH,
+ HDMI_3D_STRUCTURE_L_DEPTH_GFX_GFX_DEPTH,
+ HDMI_3D_STRUCTURE_TOP_AND_BOTTOM,
+ HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF = 8,
+};
+
+struct hdmi_hdmi_infoframe {
+ enum hdmi_infoframe_type type;
+ unsigned char version;
+ unsigned char length;
+ u8 vic;
+ enum hdmi_3d_structure s3d_struct;
+ unsigned int s3d_ext_data;
+};
+
+int hdmi_hdmi_infoframe_init(struct hdmi_hdmi_infoframe *frame);
+ssize_t hdmi_hdmi_infoframe_pack(struct hdmi_hdmi_infoframe *frame,
+void *buffer, size_t size);
+
union hdmi_infoframe {
struct hdmi_any_infoframe any;
[PATCH 10/12] video/hdmi: Hook the HDMI vendor infoframe with the generic _pack()
With this last bit, hdmi_infoframe_pack() is now able to pack any
infoframe we support.
At the same time, because it's impractical to make two commits out of
this, we get rid of the version that encourages the open coding of the
vendor infoframe packing. We can do so because the only user of this API
has been ported in:
Author: Damien Lespiau
Date: Mon Aug 12 18:08:37 2013 +0100
gpu: host1x: Port the HDMI vendor infoframe code the common helpers
v2: Change oui to be an unsigned int (Ville Syrjälä)
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/video/hdmi.c | 45 +
include/linux/hdmi.h | 24
2 files changed, 21 insertions(+), 48 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 59c4748..7ae4f80 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -298,6 +298,7 @@ int hdmi_hdmi_infoframe_init(struct hdmi_hdmi_infoframe
*frame)
frame->type = HDMI_INFOFRAME_TYPE_VENDOR;
frame->version = 1;
+ frame->oui = HDMI_IDENTIFIER;
/* 0 is a valid value for s3d_struct, so we use a special "not set"
* value */
frame->s3d_struct = HDMI_3D_STRUCTURE_INVALID;
@@ -373,46 +374,18 @@ ssize_t hdmi_hdmi_infoframe_pack(struct
hdmi_hdmi_infoframe *frame,
}
EXPORT_SYMBOL(hdmi_hdmi_infoframe_pack);
-/**
- * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary
- *buffer
- * @frame: HDMI vendor infoframe
- * @buffer: destination buffer
- * @size: size of buffer
- *
- * Packs the information contained in the @frame structure into a binary
- * representation that can be written into the corresponding controller
- * registers. Also computes the checksum as required by section 5.3.5 of
- * the HDMI 1.4 specification.
- *
- * Returns the number of bytes packed into the binary buffer or a negative
- * error code on failure.
+/*
+ * hdmi_vendor_infoframe_pack() - write a vendor infoframe to binary buffer
*/
-ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,
- void *buffer, size_t size)
+static ssize_t hdmi_vendor_infoframe_pack(union hdmi_vendor_infoframe *frame,
+ void *buffer, size_t size)
{
- u8 *ptr = buffer;
- size_t length;
-
- length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
-
- if (size < length)
- return -ENOSPC;
-
- memset(buffer, 0, size);
-
- ptr[0] = frame->type;
- ptr[1] = frame->version;
- ptr[2] = frame->length;
- ptr[3] = 0; /* checksum */
-
- memcpy(&ptr[HDMI_INFOFRAME_HEADER_SIZE], frame->data, frame->length);
-
- hdmi_infoframe_checksum(buffer, length);
+ /* we only know about HDMI vendor infoframes */
+ if (frame->any.oui != HDMI_IDENTIFIER)
+ return -EINVAL;
- return length;
+ return hdmi_hdmi_infoframe_pack(&frame->hdmi, buffer, size);
}
-EXPORT_SYMBOL(hdmi_vendor_infoframe_pack);
/**
* hdmi_infoframe_pack() - write a HDMI infoframe to binary buffer
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 37e0cd7..e24d850 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -225,16 +225,6 @@ int hdmi_audio_infoframe_init(struct hdmi_audio_infoframe
*frame);
ssize_t hdmi_audio_infoframe_pack(struct hdmi_audio_infoframe *frame,
void *buffer, size_t size);
-struct hdmi_vendor_infoframe {
- enum hdmi_infoframe_type type;
- unsigned char version;
- unsigned char length;
- u8 data[27];
-};
-
-ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,
- void *buffer, size_t size);
-
enum hdmi_3d_structure {
HDMI_3D_STRUCTURE_INVALID = -1,
HDMI_3D_STRUCTURE_FRAME_PACKING = 0,
@@ -251,6 +241,7 @@ struct hdmi_hdmi_infoframe {
enum hdmi_infoframe_type type;
unsigned char version;
unsigned char length;
+ unsigned int oui;
u8 vic;
enum hdmi_3d_structure s3d_struct;
unsigned int s3d_ext_data;
@@ -260,12 +251,21 @@ int hdmi_hdmi_infoframe_init(struct hdmi_hdmi_infoframe
*frame);
ssize_t hdmi_hdmi_infoframe_pack(struct hdmi_hdmi_infoframe *frame,
void *buffer, size_t size);
+union hdmi_vendor_infoframe {
+ struct {
+ enum hdmi_infoframe_type type;
+ unsigned char version;
+ unsigned char length;
+ unsigned int oui;
+ } any;
+ struct hdmi_hdmi_infoframe hdmi;
+};
+
union hdmi_infoframe {
struct hdmi_any_infoframe any;
struct hdmi_avi_infoframe avi;
struct hdmi_spd_infoframe spd;
- struct hdmi_vendor_infoframe vendor;
- struct hdmi_hdmi_infoframe hdmi;
+ union hdmi_vendor_infoframe vendor;
struct hdmi_audio_infof
[PATCH 09/12] drm/edid: Move HDMI_IDENTIFIER to hdmi.h
We'll need the HDMI OUI for the HDMI vendor infoframe data, so let's
move the DRM one to hdmi.h, might as well use the hdmi header to store
some hdmi defines.
(Note that, in fact, infoframes are part of the CEA-861 standard, and
only the HDMI vendor specific infoframe is special to HDMI, but
details..)
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 1 -
include/linux/hdmi.h | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d76d608..3aa653f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2317,7 +2317,6 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
return closure.modes;
}
-#define HDMI_IDENTIFIER 0x000C03
#define AUDIO_BLOCK0x01
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e733252..37e0cd7 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -18,6 +18,7 @@ enum hdmi_infoframe_type {
HDMI_INFOFRAME_TYPE_AUDIO = 0x84,
};
+#define HDMI_IDENTIFIER 0x000c03
#define HDMI_INFOFRAME_HEADER_SIZE 4
#define HDMI_AVI_INFOFRAME_SIZE13
#define HDMI_SPD_INFOFRAME_SIZE25
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/12] drm: Add a helper to forge HDMI vendor infoframes
This can then be used by DRM drivers to setup their vendor infoframes.
v2: Fix hmdi typo (Simon Farnsworth)
Signed-off-by: Damien Lespiau
Reviewed-by: Simon Farnsworth
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 36
include/drm/drm_edid.h | 4
2 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3aa653f..42c62d1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3263,3 +3263,39 @@ drm_hdmi_avi_infoframe_from_display_mode(struct
hdmi_avi_infoframe *frame,
return 0;
}
EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
+
+/**
+ * drm_hdmi_vendor_infoframe_from_display_mode() - fill an HDMI infoframe with
+ * data from a DRM display mode
+ * @frame: HDMI vendor infoframe
+ * @mode: DRM display mode
+ *
+ * Note that there's is a need to send HDMI vendor infoframes only when using a
+ * 4k or stereoscopic 3D mode. So when giving any other mode as input this
+ * function will return -EINVAL, error that can be safely ignored.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_hdmi_infoframe *frame,
+ const struct drm_display_mode *mode)
+{
+ int err;
+ u8 vic;
+
+ if (!frame || !mode)
+ return -EINVAL;
+
+ vic = drm_match_hdmi_mode(mode);
+ if (!vic)
+ return -EINVAL;
+
+ err = hdmi_hdmi_infoframe_init(frame);
+ if (err < 0)
+ return err;
+
+ frame->vic = vic;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_vendor_infoframe_from_display_mode);
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index fc481fc..a204e31 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -256,6 +256,7 @@ struct drm_encoder;
struct drm_connector;
struct drm_display_mode;
struct hdmi_avi_infoframe;
+struct hdmi_hdmi_infoframe;
void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@ -268,5 +269,8 @@ int drm_load_edid_firmware(struct drm_connector *connector);
int
drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame,
const struct drm_display_mode *mode);
+int
+drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_hdmi_infoframe *frame,
+ const struct drm_display_mode
*mode);
#endif /* __DRM_EDID_H__ */
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/12] drm/i915/hdmi: Write HDMI vendor specific infoframes
With all the common infoframe bits now in place, we can finally write
the vendor specific infoframes in our driver.
Signed-off-by: Damien Lespiau
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 28
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 17f6252..33427fd1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4157,6 +4157,8 @@
_TRANSCODER(trans, HSW_VIDEO_DIP_CTL_A, HSW_VIDEO_DIP_CTL_B)
#define HSW_TVIDEO_DIP_AVI_DATA(trans) \
_TRANSCODER(trans, HSW_VIDEO_DIP_AVI_DATA_A, HSW_VIDEO_DIP_AVI_DATA_B)
+#define HSW_TVIDEO_DIP_VS_DATA(trans) \
+_TRANSCODER(trans, HSW_VIDEO_DIP_VS_DATA_A, HSW_VIDEO_DIP_VS_DATA_B)
#define HSW_TVIDEO_DIP_SPD_DATA(trans) \
_TRANSCODER(trans, HSW_VIDEO_DIP_SPD_DATA_A, HSW_VIDEO_DIP_SPD_DATA_B)
#define HSW_TVIDEO_DIP_GCP(trans) \
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index a619d94..4148cc8 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -74,6 +74,8 @@ static u32 g4x_infoframe_index(enum hdmi_infoframe_type type)
return VIDEO_DIP_SELECT_AVI;
case HDMI_INFOFRAME_TYPE_SPD:
return VIDEO_DIP_SELECT_SPD;
+ case HDMI_INFOFRAME_TYPE_VENDOR:
+ return VIDEO_DIP_SELECT_VENDOR;
default:
DRM_DEBUG_DRIVER("unknown info frame type %d\n", type);
return 0;
@@ -87,6 +89,8 @@ static u32 g4x_infoframe_enable(enum hdmi_infoframe_type type)
return VIDEO_DIP_ENABLE_AVI;
case HDMI_INFOFRAME_TYPE_SPD:
return VIDEO_DIP_ENABLE_SPD;
+ case HDMI_INFOFRAME_TYPE_VENDOR:
+ return VIDEO_DIP_ENABLE_VENDOR;
default:
DRM_DEBUG_DRIVER("unknown info frame type %d\n", type);
return 0;
@@ -100,6 +104,8 @@ static u32 hsw_infoframe_enable(enum hdmi_infoframe_type
type)
return VIDEO_DIP_ENABLE_AVI_HSW;
case HDMI_INFOFRAME_TYPE_SPD:
return VIDEO_DIP_ENABLE_SPD_HSW;
+ case HDMI_INFOFRAME_TYPE_VENDOR:
+ return VIDEO_DIP_ENABLE_VS_HSW;
default:
DRM_DEBUG_DRIVER("unknown info frame type %d\n", type);
return 0;
@@ -114,6 +120,8 @@ static u32 hsw_infoframe_data_reg(enum hdmi_infoframe_type
type,
return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder);
case HDMI_INFOFRAME_TYPE_SPD:
return HSW_TVIDEO_DIP_SPD_DATA(cpu_transcoder);
+ case HDMI_INFOFRAME_TYPE_VENDOR:
+ return HSW_TVIDEO_DIP_VS_DATA(cpu_transcoder);
default:
DRM_DEBUG_DRIVER("unknown info frame type %d\n", type);
return 0;
@@ -392,6 +400,21 @@ static void intel_hdmi_set_spd_infoframe(struct
drm_encoder *encoder)
intel_write_infoframe(encoder, &frame);
}
+static void
+intel_hdmi_set_hdmi_infoframe(struct drm_encoder *encoder,
+ struct drm_display_mode *adjusted_mode)
+{
+ union hdmi_infoframe frame;
+ int ret;
+
+ ret = drm_hdmi_vendor_infoframe_from_display_mode(&frame.vendor.hdmi,
+ adjusted_mode);
+ if (ret < 0)
+ return;
+
+ intel_write_infoframe(encoder, &frame);
+}
+
static void g4x_set_infoframes(struct drm_encoder *encoder,
struct drm_display_mode *adjusted_mode)
{
@@ -454,6 +477,7 @@ static void g4x_set_infoframes(struct drm_encoder *encoder,
intel_hdmi_set_avi_infoframe(encoder, adjusted_mode);
intel_hdmi_set_spd_infoframe(encoder);
+ intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
}
static void ibx_set_infoframes(struct drm_encoder *encoder,
@@ -515,6 +539,7 @@ static void ibx_set_infoframes(struct drm_encoder *encoder,
intel_hdmi_set_avi_infoframe(encoder, adjusted_mode);
intel_hdmi_set_spd_infoframe(encoder);
+ intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
}
static void cpt_set_infoframes(struct drm_encoder *encoder,
@@ -550,6 +575,7 @@ static void cpt_set_infoframes(struct drm_encoder *encoder,
intel_hdmi_set_avi_infoframe(encoder, adjusted_mode);
intel_hdmi_set_spd_infoframe(encoder);
+ intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
}
static void vlv_set_infoframes(struct drm_encoder *encoder,
@@ -584,6 +610,7 @@ static void vlv_set_infoframes(struct drm_encoder *encoder,
intel_hdmi_set_avi_infoframe(encoder, adjusted_mode);
intel_hdmi_set_spd_infoframe(encoder);
+ intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
}
static void hsw_set_infoframes(struct drm_encoder *encoder,
@@ -611,6 +638,7 @@ static void hsw_set_infoframes(struct drm_enco
Re: [PATCH 08/16] drm/vmwgfx: implement mmap access managament
(CC'ing the proper people since I'm still on parental leave).
On 08/13/2013 11:44 PM, David Herrmann wrote:
Please see inline comments.
Hi
On Tue, Aug 13, 2013 at 9:38 PM, David Herrmann wrote:
Correctly allow and revoke buffer access on each open/close via the new
VMA offset manager.
I haven't yet had time to check the access policies of the new VMA
offset manager, but anything that is identical or stricter than the
current vmwgfx verify_access() would be fine. If it's stricter however,
we need to double-check backwards user-space compatibility.
We also need to make vmw_user_dmabuf_reference()
correctly increase the vma-allow counter, but it is unused so remove it
instead.
IIRC this function or a derivative thereof is used heavily in an
upcoming version driver, so if possible, please add a corrected version
rather than remove the (currently) unused code. This will trigger a
merge error and the upcoming code can be more easily corrected.
Cc: Thomas Hellstrom
Signed-off-by: David Herrmann
Just as a hint, this patch would allow to remove the
"->access_verify()" callback in vmwgfx. No other driver uses it,
afaik. I will try to add this in v2.
Regards
David
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 0e67cf4..4d3f0ae 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -499,6 +499,12 @@ int vmw_dmabuf_alloc_ioctl(struct drm_device *dev, void
*data,
if (unlikely(ret != 0))
goto out_no_dmabuf;
+ ret = drm_vma_node_allow(&dma_buf->base.vma_node, file_priv->filp);
+ if (ret) {
+ vmw_dmabuf_unreference(&dma_buf);
+ goto out_no_dmabuf;
+ }
+
rep->handle = handle;
rep->map_handle = drm_vma_node_offset_addr(&dma_buf->base.vma_node);
rep->cur_gmr_id = handle;
@@ -517,7 +523,18 @@ int vmw_dmabuf_unref_ioctl(struct drm_device *dev, void
*data,
{
struct drm_vmw_unref_dmabuf_arg *arg =
(struct drm_vmw_unref_dmabuf_arg *)data;
+ struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
+ struct vmw_dma_buffer *dma_buf;
+ int ret;
+
+ ret = vmw_user_dmabuf_lookup(tfile, arg->handle, &dma_buf);
+ if (ret)
+ return -EINVAL;
+ drm_vma_node_revoke(&dma_buf->base.vma_node, file_priv->filp);
+ vmw_dmabuf_unreference(&dma_buf);
+
+ /* FIXME: is this equivalent to vmw_dmabuf_unreference(dma_buf)? */
No. A ttm ref object is rather similar to a generic GEM object, only
that it's generic in the sense that it is not restricted to buffers, and
can make any desired object visible to user-space. So translated the
below code removes a reference that the arg->handle holds on the "gem"
object, potentially destroying the whole object in which the "gem"
object is embedded.
return ttm_ref_object_base_unref(vmw_fpriv(file_priv)->tfile,
arg->handle,
TTM_REF_USAGE);
@@ -551,18 +568,6 @@ int vmw_user_dmabuf_lookup(struct ttm_object_file *tfile,
return 0;
}
-int vmw_user_dmabuf_reference(struct ttm_object_file *tfile,
- struct vmw_dma_buffer *dma_buf)
-{
- struct vmw_user_dma_buffer *user_bo;
-
- if (dma_buf->base.destroy != vmw_user_dmabuf_destroy)
- return -EINVAL;
-
- user_bo = container_of(dma_buf, struct vmw_user_dma_buffer, dma);
- return ttm_ref_object_add(tfile, &user_bo->base, TTM_REF_USAGE, NULL);
-}
-
/*
* Stream management
*/
--
1.8.3.4
Otherwise looks OK to me.
Thanks,
Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #40 from Aaron Watry --- Can you apply the following LLVM 2 code series, build the latest upstream libclc version, and try again? LLVM Patch series: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130812/184088.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130812/184089.html Libclc: git clone http://llvm.org/git/libclc.git With that, and the latest mesa git code, I've managed to run bfgminer for ~5 minutes on a Radeon 5400 without a single lockup. This same GPU used to lock up within 5 seconds of starting: bfgminer -v1 --benchmark -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 07/12] video/hdmi: Introduce helpers for the HDMI vendor specific infoframe
On Wed, Aug 14, 2013 at 06:19:10PM +0100, Damien Lespiau wrote:
> Provide the same programming model than the other infoframe types.
>
> The generic _pack() function can't handle those yet as we need to move
> the vendor OUI in the generic hdmi_vendor_infoframe structure to know
> which kind of vendor infoframe we are dealing with.
>
> v2: Fix the value of Side-by-side (half), hmdi typo, pack 3D_Ext_Data
> (Ville Syrjälä)
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/video/hdmi.c | 88
>
> include/linux/hdmi.h | 26
> 2 files changed, 114 insertions(+)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index ac84215..59c4748 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -286,6 +286,94 @@ ssize_t hdmi_audio_infoframe_pack(struct
> hdmi_audio_infoframe *frame,
> EXPORT_SYMBOL(hdmi_audio_infoframe_pack);
>
> /**
> + * hdmi_hdmi_infoframe_init() - initialize an HDMI vendor infoframe
> + * @frame: HDMI vendor infoframe
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_hdmi_infoframe_init(struct hdmi_hdmi_infoframe *frame)
> +{
> + memset(frame, 0, sizeof(*frame));
> +
> + frame->type = HDMI_INFOFRAME_TYPE_VENDOR;
> + frame->version = 1;
> +
> + /* 0 is a valid value for s3d_struct, so we use a special "not set"
> + * value */
> + frame->s3d_struct = HDMI_3D_STRUCTURE_INVALID;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(hdmi_hdmi_infoframe_init);
> +
> +/**
> + * hdmi_hdmi_infoframe_pack() - write a HDMI vendor infoframe to binary
> buffer
> + * @frame: HDMI infoframe
> + * @buffer: destination buffer
> + * @size: size of buffer
> + *
> + * Packs the information contained in the @frame structure into a binary
> + * representation that can be written into the corresponding controller
> + * registers. Also computes the checksum as required by section 5.3.5 of
> + * the HDMI 1.4 specification.
> + *
> + * Returns the number of bytes packed into the binary buffer or a negative
> + * error code on failure.
> + */
> +ssize_t hdmi_hdmi_infoframe_pack(struct hdmi_hdmi_infoframe *frame,
> + void *buffer, size_t size)
> +{
> + u8 *ptr = buffer;
> + size_t length;
> +
> + /* empty info frame */
> + if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID)
> + return -EINVAL;
> +
> + /* only one of those can be supplied */
> + if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID)
> + return -EINVAL;
> +
> + /* for side by side (half) we also need to provide 3D_Ext_Data */
> + if (frame->s3d_struct == HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
Could be >= for a bit of future proofing since the spec says we should
send 3d_ext_data even for the reserved > 8 values.
> + frame->length = 6;
> + else
> + frame->length = 5;
> +
> + length = HDMI_INFOFRAME_HEADER_SIZE + frame->length;
> +
> + if (size < length)
> + return -ENOSPC;
> +
> + memset(buffer, 0, size);
> +
> + ptr[0] = frame->type;
> + ptr[1] = frame->version;
> + ptr[2] = frame->length;
> + ptr[3] = 0; /* checksum */
> +
> + /* HDMI OUI */
> + ptr[4] = 0x03;
> + ptr[5] = 0x0c;
> + ptr[6] = 0x00;
> +
> + if (frame->vic) {
> + ptr[7] = 0x1 << 5; /* video format */
> + ptr[8] = frame->vic;
> + } else {
> + ptr[7] = 0x2 << 5; /* video format */
> + ptr[8] = (frame->s3d_struct & 0xf) << 4;
> + if (frame->s3d_struct == HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF)
Could be >= here too.
But whether or not you make those changes:
Reviewed-by: Ville Syrjälä
> + ptr[9] = (frame->s3d_ext_data & 0xf) << 4;
> + }
> +
> + hdmi_infoframe_checksum(buffer, length);
> +
> + return length;
> +}
> +EXPORT_SYMBOL(hdmi_hdmi_infoframe_pack);
> +
> +/**
> * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary
> *buffer
> * @frame: HDMI vendor infoframe
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index b98340b..e733252 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -234,11 +234,37 @@ struct hdmi_vendor_infoframe {
> ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame,
> void *buffer, size_t size);
>
> +enum hdmi_3d_structure {
> + HDMI_3D_STRUCTURE_INVALID = -1,
> + HDMI_3D_STRUCTURE_FRAME_PACKING = 0,
> + HDMI_3D_STRUCTURE_FIELD_ALTERNATIVE,
> + HDMI_3D_STRUCTURE_LINE_ALTERNATIVE,
> + HDMI_3D_STRUCTURE_SIDE_BY_SIDE_FULL,
> + HDMI_3D_STRUCTURE_L_DEPTH,
> + HDMI_3D_STRUCTURE_L_DEPTH_GFX_GFX_DEPTH,
> + HDMI_3D_STRUCTURE_TOP_AND_BOTTOM,
> + HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF = 8,
> +};
> +
> +struct hdmi_hdmi_infoframe {
> + enu
Re: HDMI 4k support v3
On Wed, Aug 14, 2013 at 06:19:03PM +0100, Damien Lespiau wrote: > Follow up on v2: > http://lists.freedesktop.org/archives/dri-devel/2013-August/043604.html > > With the quick and nice reviews from Ville and Simon, it's time for a v3: > - Fix embarrassing hmdi typo > - Fix the sending of vendor specific infoframes for side-by-side half modes > - Smaller changes here and there. Looking very good. Reviewed-by: Ville Syrjälä for the rest as well. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] drm: Add drm_bridge and PTN3460 bridge driver
This patchset adds the drm_bridge abstraction as well as the PTN3460 DisplayPort to LVDS bridge driver (using drm_bridge, of course). Changed in v2: - Added PTN3460 driver to show drm_bridge usage - Removed connector detect() re-route in favor of implementing the connector in the bridge driver - Removed the drm_bridge_helper_funcs and stuck everything in drm_bridge_funcs - Added driver_private to drm_bridge Sean Paul (2): drm: Add drm_bridge drm/bridge: Add PTN3460 bridge driver .../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++ drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/bridge/Kconfig | 5 + drivers/gpu/drm/bridge/Makefile| 3 + drivers/gpu/drm/bridge/ptn3460.c | 349 + drivers/gpu/drm/drm_crtc.c | 50 +++ drivers/gpu/drm/drm_crtc_helper.c | 89 -- include/drm/bridge/ptn3460.h | 36 +++ include/drm/drm_crtc.h | 55 10 files changed, 598 insertions(+), 19 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt create mode 100644 drivers/gpu/drm/bridge/Kconfig create mode 100644 drivers/gpu/drm/bridge/Makefile create mode 100644 drivers/gpu/drm/bridge/ptn3460.c create mode 100644 include/drm/bridge/ptn3460.h -- 1.8.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm: Add drm_bridge
This patch adds the notion of a drm_bridge. A bridge is a chained
device which hangs off an encoder. The drm driver using the bridge
should provide the association between encoder and bridge. Once a
bridge is associated with an encoder, it will participate in mode
set, and dpms (via the enable/disable hooks).
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_crtc.c| 50 ++
drivers/gpu/drm/drm_crtc_helper.c | 89 ++-
include/drm/drm_crtc.h| 55
3 files changed, 175 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fc83bb9..0311e2b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -781,6 +781,41 @@ void drm_connector_unplug_all(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_connector_unplug_all);
+int drm_bridge_init(struct drm_device *dev, struct drm_bridge *bridge,
+ const struct drm_bridge_funcs *funcs)
+{
+ int ret;
+
+ drm_modeset_lock_all(dev);
+
+ ret = drm_mode_object_get(dev, &bridge->base, DRM_MODE_OBJECT_BRIDGE);
+ if (ret)
+ goto out;
+
+ bridge->dev = dev;
+ bridge->funcs = funcs;
+
+ list_add_tail(&bridge->head, &dev->mode_config.bridge_list);
+ dev->mode_config.num_bridge++;
+
+ out:
+ drm_modeset_unlock_all(dev);
+ return ret;
+}
+EXPORT_SYMBOL(drm_bridge_init);
+
+void drm_bridge_cleanup(struct drm_bridge *bridge)
+{
+ struct drm_device *dev = bridge->dev;
+
+ drm_modeset_lock_all(dev);
+ drm_mode_object_put(dev, &bridge->base);
+ list_del(&bridge->head);
+ dev->mode_config.num_bridge--;
+ drm_modeset_unlock_all(dev);
+}
+EXPORT_SYMBOL(drm_bridge_cleanup);
+
int drm_encoder_init(struct drm_device *dev,
struct drm_encoder *encoder,
const struct drm_encoder_funcs *funcs,
@@ -1190,6 +1225,7 @@ static int drm_mode_group_init(struct drm_device *dev,
struct drm_mode_group *gr
total_objects += dev->mode_config.num_crtc;
total_objects += dev->mode_config.num_connector;
total_objects += dev->mode_config.num_encoder;
+ total_objects += dev->mode_config.num_bridge;
group->id_list = kzalloc(total_objects * sizeof(uint32_t), GFP_KERNEL);
if (!group->id_list)
@@ -1198,6 +1234,7 @@ static int drm_mode_group_init(struct drm_device *dev,
struct drm_mode_group *gr
group->num_crtcs = 0;
group->num_connectors = 0;
group->num_encoders = 0;
+ group->num_bridges = 0;
return 0;
}
@@ -1207,6 +1244,7 @@ int drm_mode_group_init_legacy_group(struct drm_device
*dev,
struct drm_crtc *crtc;
struct drm_encoder *encoder;
struct drm_connector *connector;
+ struct drm_bridge *bridge;
int ret;
if ((ret = drm_mode_group_init(dev, group)))
@@ -1223,6 +1261,11 @@ int drm_mode_group_init_legacy_group(struct drm_device
*dev,
group->id_list[group->num_crtcs + group->num_encoders +
group->num_connectors++] = connector->base.id;
+ list_for_each_entry(bridge, &dev->mode_config.bridge_list, head)
+ group->id_list[group->num_crtcs + group->num_encoders +
+ group->num_connectors + group->num_bridges++] =
+ bridge->base.id;
+
return 0;
}
EXPORT_SYMBOL(drm_mode_group_init_legacy_group);
@@ -3905,6 +3948,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(&dev->mode_config.fb_list);
INIT_LIST_HEAD(&dev->mode_config.crtc_list);
INIT_LIST_HEAD(&dev->mode_config.connector_list);
+ INIT_LIST_HEAD(&dev->mode_config.bridge_list);
INIT_LIST_HEAD(&dev->mode_config.encoder_list);
INIT_LIST_HEAD(&dev->mode_config.property_list);
INIT_LIST_HEAD(&dev->mode_config.property_blob_list);
@@ -3941,6 +3985,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
struct drm_connector *connector, *ot;
struct drm_crtc *crtc, *ct;
struct drm_encoder *encoder, *enct;
+ struct drm_bridge *bridge, *brt;
struct drm_framebuffer *fb, *fbt;
struct drm_property *property, *pt;
struct drm_property_blob *blob, *bt;
@@ -3951,6 +3996,11 @@ void drm_mode_config_cleanup(struct drm_device *dev)
encoder->funcs->destroy(encoder);
}
+ list_for_each_entry_safe(bridge, brt,
+&dev->mode_config.bridge_list, head) {
+ bridge->funcs->destroy(bridge);
+ }
+
list_for_each_entry_safe(connector, ot,
&dev->mode_config.connector_list, head) {
connector->funcs->destroy(connector);
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 6a64749..c722c3b 100644
--- a/d
[PATCH v2 2/2] drm/bridge: Add PTN3460 bridge driver
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul
---
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
drivers/gpu/drm/Kconfig| 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/bridge/Kconfig | 5 +
drivers/gpu/drm/bridge/Makefile| 3 +
drivers/gpu/drm/bridge/ptn3460.c | 349 +
include/drm/bridge/ptn3460.h | 36 +++
7 files changed, 423 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
create mode 100644 drivers/gpu/drm/bridge/Kconfig
create mode 100644 drivers/gpu/drm/bridge/Makefile
create mode 100644 drivers/gpu/drm/bridge/ptn3460.c
create mode 100644 include/drm/bridge/ptn3460.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
new file mode 100644
index 000..c1cd329
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
@@ -0,0 +1,27 @@
+ptn3460-bridge bindings
+
+Required properties:
+ - compatible: "nxp,ptn3460"
+ - reg: i2c address of the bridge
+ - powerdown-gpio: OF device-tree gpio specification
+ - reset-gpio: OF device-tree gpio specification
+ - edid-emulation: The EDID emulation entry to use
+ +---++--+
+ | Value | Resolution | Description |
+ | 0 | 1024x768 | NXP Generic |
+ | 1 | 1920x1080 | NXP Generic |
+ | 2 | 1920x1080 | NXP Generic |
+ | 3 | 1600x900 | Samsung LTM200KT |
+ | 4 | 1920x1080 | Samsung LTM230HT |
+ | 5 | 1366x768 | NXP Generic |
+ | 6 | 1600x900 | ChiMei M215HGE |
+ +---++--+
+
+Example:
+ ptn3460-bridge@20 {
+ compatible = "nxp,ptn3460";
+ reg = <0x20>;
+ powerdown-gpio = <&gpy2 5 1 0 0>;
+ reset-gpio = <&gpx1 5 1 0 0>;
+ edid-emulation = <5>;
+ };
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index a7c54c8..6105a34 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -223,3 +223,5 @@ source "drivers/gpu/drm/omapdrm/Kconfig"
source "drivers/gpu/drm/tilcdc/Kconfig"
source "drivers/gpu/drm/qxl/Kconfig"
+
+source "drivers/gpu/drm/bridge/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index d943b94..c2ae293 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_DRM_OMAP)+= omapdrm/
obj-$(CONFIG_DRM_TILCDC) += tilcdc/
obj-$(CONFIG_DRM_QXL) += qxl/
obj-y += i2c/
+obj-y += bridge/
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
new file mode 100644
index 000..27a83b5
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -0,0 +1,5 @@
+config DRM_PTN3460
+ tristate "PTN3460 DP/LVDS bridge"
+ depends on DRM && I2C
+ ---help---
+ Adds the driver for the NXP PTN3460 DP/LVDS bridge chip.
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
new file mode 100644
index 000..b4733e1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -0,0 +1,3 @@
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c b/drivers/gpu/drm/bridge/ptn3460.c
new file mode 100644
index 000..a9e5c1a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -0,0 +1,349 @@
+/*
+ * NXP PTN3460 DP/LVDS bridge driver
+ *
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drmP.h"
+#include "drm_edid.h"
+#include "drm_crtc.h"
+#include "drm_crtc_helper.h"
+
+#include "bridge/ptn3460.h"
+
+#define PTN3460_EDID_ADDR 0x0
+#define PTN3460_EDID_EMULATION_ADDR0x84
+#define PTN3460_EDID_ENABLE_EMULATION 0
+#define PTN3460_EDID_EMULATION_SELECTION 1
+#define PTN3460_EDID_SRAM_LOAD_ADDR0x85
+
+struct ptn3460_bridge {
+ struct drm_connector connector;
+ struct i2c_client *client;
+ struct drm_encoder *encoder;
+ struct drm_bridge *bridge;
+ str
Re: [PATCH 3/5] drm/i915: explicit store base gem object in dma_buf->priv
On Thu, Aug 08, 2013 at 09:10:38AM +0200, Daniel Vetter wrote:
> Makes it more obviously correct what tricks we play by reusing the drm
> prime release helper.
>
> Reviewed-by: Chris Wilson
> Signed-off-by: Daniel Vetter
Ok, to get things going I've merged the two i915 patches to dinq.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index f7e1682..e918b05 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -27,10 +27,15 @@
> #include "i915_drv.h"
> #include
>
> +static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
> +{
> + return to_intel_bo(buf->priv);
> +}
> +
> static struct sg_table *i915_gem_map_dma_buf(struct dma_buf_attachment
> *attachment,
>enum dma_data_direction dir)
> {
> - struct drm_i915_gem_object *obj = attachment->dmabuf->priv;
> + struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
> struct sg_table *st;
> struct scatterlist *src, *dst;
> int ret, i;
> @@ -85,7 +90,7 @@ static void i915_gem_unmap_dma_buf(struct
> dma_buf_attachment *attachment,
> struct sg_table *sg,
> enum dma_data_direction dir)
> {
> - struct drm_i915_gem_object *obj = attachment->dmabuf->priv;
> + struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
>
> mutex_lock(&obj->base.dev->struct_mutex);
>
> @@ -100,7 +105,7 @@ static void i915_gem_unmap_dma_buf(struct
> dma_buf_attachment *attachment,
>
> static void *i915_gem_dmabuf_vmap(struct dma_buf *dma_buf)
> {
> - struct drm_i915_gem_object *obj = dma_buf->priv;
> + struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> struct drm_device *dev = obj->base.dev;
> struct sg_page_iter sg_iter;
> struct page **pages;
> @@ -148,7 +153,7 @@ error:
>
> static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
> {
> - struct drm_i915_gem_object *obj = dma_buf->priv;
> + struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> struct drm_device *dev = obj->base.dev;
> int ret;
>
> @@ -191,7 +196,7 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
> struct vm_area_struct *
>
> static int i915_gem_begin_cpu_access(struct dma_buf *dma_buf, size_t start,
> size_t length, enum dma_data_direction direction)
> {
> - struct drm_i915_gem_object *obj = dma_buf->priv;
> + struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> struct drm_device *dev = obj->base.dev;
> int ret;
> bool write = (direction == DMA_BIDIRECTIONAL || direction ==
> DMA_TO_DEVICE);
> @@ -222,9 +227,7 @@ static const struct dma_buf_ops i915_dmabuf_ops = {
> struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
> struct drm_gem_object *gem_obj, int flags)
> {
> - struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
> -
> - return dma_buf_export(obj, &i915_dmabuf_ops, obj->base.size, flags);
> + return dma_buf_export(gem_obj, &i915_dmabuf_ops, gem_obj->size, flags);
> }
>
> static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
> @@ -261,7 +264,7 @@ struct drm_gem_object *i915_gem_prime_import(struct
> drm_device *dev,
>
> /* is this one of own objects? */
> if (dma_buf->ops == &i915_dmabuf_ops) {
> - obj = dma_buf->priv;
> + obj = dma_buf_to_obj(dma_buf);
> /* is it from our device? */
> if (obj->base.dev == dev) {
> /*
> --
> 1.8.3.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/20] prime patches
Hi all, So I've finally tracked down the last thing which I didn't really understand in my earlier patches and made sure it won't ever break again by writing testcases. The one thing still left to do (but I have tests for it already) is to make sure we don't duplicate buffers when importing foreign buffers on two open fds. This is the use-case for which the exynos guys recently posted a few hacky patches. I've already merged the i915 patches from this series. Since there's no real functional depency all the patches here can go through drm-next without issues. Comments&flames highly welcome. Cheers, Daniel Daniel Vetter (19): drm: use common drm_gem_dmabuf_release in i915/exynos drivers drm/prime: remove cargo-cult locking from map_sg helper drm/prime: add a bit of documentation about gem_obj->import_attach drm/gem: move drm_gem_object_handle_unreference_unlocked into drm_gem.c drm/gem: remove bogus NULL check from drm_gem_object_handle_unreference_unlocked drm/gem: WARN about unbalanced handle refcounts drm/gem: fix up flink name create race drm/prime: fix error path in drm_gem_prime_fd_to_handle drm/gem: make drm_gem_object_handle_unreference_unlocked static drm/gem: create drm_gem_dumb_destroy drm/prime: use proper pointer in drm_gem_prime_handle_to_fd drm/prime: shrink critical section protected by prime lock drm/prime: clarify logic a bit in drm_gem_prime_fd_to_handle drm/gem: switch dev->object_name_lock to a mutex drm/gem: completely close gem_open vs. gem_close races drm/prime: proper locking+refcounting for obj->dma_buf link drm/prime: Simplify drm_gem_remove_prime_handles drm/prime: make drm_prime_lookup_buf_handle static drm/prime: Always add exported buffers to the handle cache Inki Dae (1): drm/exynos: explicit store base gem object in dma_buf->priv drivers/gpu/drm/drm_fops.c | 1 + drivers/gpu/drm/drm_gem.c | 178 ++- drivers/gpu/drm/drm_info.c | 2 +- drivers/gpu/drm/drm_prime.c| 190 ++--- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 35 ++ drivers/gpu/drm/exynos/exynos_drm_gem.c| 2 +- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 13 +- include/drm/drmP.h | 79 ++-- 8 files changed, 297 insertions(+), 203 deletions(-) -- 1.8.3.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/20] drm: use common drm_gem_dmabuf_release in i915/exynos drivers
Note that this is slightly tricky since both drivers store their
native objects in dma_buf->priv. But both also embed the base
drm_gem_object at the first position, so the implicit cast is ok.
To use the release helper we need to export it, too.
Cc: Inki Dae
Cc: Intel Graphics Development
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c| 3 ++-
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 23 +--
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 13 +
include/drm/drmP.h | 1 +
4 files changed, 5 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 85e450e..a35f206 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -192,7 +192,7 @@ static void drm_gem_unmap_dma_buf(struct dma_buf_attachment
*attach,
/* nothing to be done here */
}
-static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
+void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
{
struct drm_gem_object *obj = dma_buf->priv;
@@ -202,6 +202,7 @@ static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
drm_gem_object_unreference_unlocked(obj);
}
}
+EXPORT_SYMBOL(drm_gem_dmabuf_release);
static void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
{
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index a0f997e..3cd56e1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -127,27 +127,6 @@ static void exynos_gem_unmap_dma_buf(struct
dma_buf_attachment *attach,
/* Nothing to do. */
}
-static void exynos_dmabuf_release(struct dma_buf *dmabuf)
-{
- struct exynos_drm_gem_obj *exynos_gem_obj = dmabuf->priv;
-
- /*
-* exynos_dmabuf_release() call means that file object's
-* f_count is 0 and it calls drm_gem_object_handle_unreference()
-* to drop the references that these values had been increased
-* at drm_prime_handle_to_fd()
-*/
- if (exynos_gem_obj->base.export_dma_buf == dmabuf) {
- exynos_gem_obj->base.export_dma_buf = NULL;
-
- /*
-* drop this gem object refcount to release allocated buffer
-* and resources.
-*/
- drm_gem_object_unreference_unlocked(&exynos_gem_obj->base);
- }
-}
-
static void *exynos_gem_dmabuf_kmap_atomic(struct dma_buf *dma_buf,
unsigned long page_num)
{
@@ -193,7 +172,7 @@ static struct dma_buf_ops exynos_dmabuf_ops = {
.kunmap = exynos_gem_dmabuf_kunmap,
.kunmap_atomic = exynos_gem_dmabuf_kunmap_atomic,
.mmap = exynos_gem_dmabuf_mmap,
- .release= exynos_dmabuf_release,
+ .release= drm_gem_dmabuf_release,
};
struct dma_buf *exynos_dmabuf_prime_export(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index f7af7e4..e918b05 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -103,17 +103,6 @@ static void i915_gem_unmap_dma_buf(struct
dma_buf_attachment *attachment,
mutex_unlock(&obj->base.dev->struct_mutex);
}
-static void i915_gem_dmabuf_release(struct dma_buf *dma_buf)
-{
- struct drm_i915_gem_object *obj = dma_buf->priv;
-
- if (obj->base.export_dma_buf == dma_buf) {
- /* drop the reference on the export fd holds */
- obj->base.export_dma_buf = NULL;
- drm_gem_object_unreference_unlocked(&obj->base);
- }
-}
-
static void *i915_gem_dmabuf_vmap(struct dma_buf *dma_buf)
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
@@ -224,7 +213,7 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, size_t start, size
static const struct dma_buf_ops i915_dmabuf_ops = {
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
- .release = i915_gem_dmabuf_release,
+ .release = drm_gem_dmabuf_release,
.kmap = i915_gem_dmabuf_kmap,
.kmap_atomic = i915_gem_dmabuf_kmap_atomic,
.kunmap = i915_gem_dmabuf_kunmap,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3ecdde6..016e75e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1495,6 +1495,7 @@ extern struct drm_gem_object *drm_gem_prime_import(struct
drm_device *dev,
struct dma_buf *dma_buf);
extern int drm_gem_prime_fd_to_handle(struct drm_device *dev,
struct drm_file *file_priv, int prime_fd, uint32_t *handle);
+extern void drm_gem_dmabuf_release(struct dma_buf *dma_buf);
extern int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
struct dr
[PATCH 02/20] drm/exynos: explicit store base gem object in dma_buf->priv
From: Inki Dae
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 3cd56e1..fd76449 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -22,6 +22,11 @@ struct exynos_drm_dmabuf_attachment {
bool is_mapped;
};
+static struct exynos_drm_gem_obj *dma_buf_to_obj(struct dma_buf *buf)
+{
+ return to_exynos_gem_obj(buf->priv);
+}
+
static int exynos_gem_attach_dma_buf(struct dma_buf *dmabuf,
struct device *dev,
struct dma_buf_attachment *attach)
@@ -63,7 +68,7 @@ static struct sg_table *
enum dma_data_direction dir)
{
struct exynos_drm_dmabuf_attachment *exynos_attach = attach->priv;
- struct exynos_drm_gem_obj *gem_obj = attach->dmabuf->priv;
+ struct exynos_drm_gem_obj *gem_obj = dma_buf_to_obj(attach->dmabuf);
struct drm_device *dev = gem_obj->base.dev;
struct exynos_drm_gem_buf *buf;
struct scatterlist *rd, *wr;
@@ -180,7 +185,7 @@ struct dma_buf *exynos_dmabuf_prime_export(struct
drm_device *drm_dev,
{
struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
- return dma_buf_export(exynos_gem_obj, &exynos_dmabuf_ops,
+ return dma_buf_export(obj, &exynos_dmabuf_ops,
exynos_gem_obj->base.size, flags);
}
@@ -198,8 +203,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct
drm_device *drm_dev,
if (dma_buf->ops == &exynos_dmabuf_ops) {
struct drm_gem_object *obj;
- exynos_gem_obj = dma_buf->priv;
- obj = &exynos_gem_obj->base;
+ obj = dma_buf->priv;
/* is it from our device? */
if (obj->dev == drm_dev) {
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/20] drm/prime: remove cargo-cult locking from map_sg helper
I've checked both implementations (radeon/nouveau) and they both grab
the page array from ttm simply by dereferencing it and then wrapping
it up with drm_prime_pages_to_sg in the callback and map it with
dma_map_sg (in the helper).
Only the grabbing of the underlying page array is anything we need to
be concerned about, and either those pages are pinned independently,
or we're screwed no matter what.
And indeed, nouveau/radeon pin the backing storage in their
attach/detach functions.
Since I've created this patch cma prime support for dma_buf was added.
drm_gem_cma_prime_get_sg_table only calls kzalloc and the creates&maps
the sg table with dma_get_sgtable. It doesn't touch any gem object
state otherwise. So the cma helpers also look safe.
The only thing we might claim it does is prevent concurrent mapping of
dma_buf attachments. But a) that's not allowed and b) the current code
is racy already since it checks whether the sg mapping exists _before_
grabbing the lock.
So the dev->struct_mutex locking here does absolutely nothing useful,
but only distracts. Remove it.
This should also help Maarten's work to eventually pin the backing
storage more dynamically by preventing locking inversions around
dev->struct_mutex.
v2: Add analysis for recently added cma helper prime code.
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Acked-by: Laurent Pinchart
Acked-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_prime.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index a35f206..f115962 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -167,8 +167,6 @@ static struct sg_table *drm_gem_map_dma_buf(struct
dma_buf_attachment *attach,
if (WARN_ON(prime_attach->dir != DMA_NONE))
return ERR_PTR(-EBUSY);
- mutex_lock(&obj->dev->struct_mutex);
-
sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
if (!IS_ERR(sgt)) {
@@ -182,7 +180,6 @@ static struct sg_table *drm_gem_map_dma_buf(struct
dma_buf_attachment *attach,
}
}
- mutex_unlock(&obj->dev->struct_mutex);
return sgt;
}
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/20] drm/prime: add a bit of documentation about gem_obj->import_attach
Lifetime rules seem to be solid around ->import_attach. So this patch
just properly documents them.
Note that pointing directly at the attachment might have issues for
devices that have multiple struct device *dev parts constituting the
logical gpu and so might need multiple attachment points. Similarly
for drm devices which don't need a dma attachment at all (like udl).
But fixing that up is material for different patches.
Reviewed-by: Rob Clark
Signed-off-by: Daniel Vetter
---
include/drm/drmP.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 016e75e..3711e97 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -678,7 +678,16 @@ struct drm_gem_object {
/* dma buf exported from this GEM object */
struct dma_buf *export_dma_buf;
- /* dma buf attachment backing this object */
+ /**
+* import_attach - dma buf attachment backing this object
+*
+* Any foreign dma_buf imported as a gem object has this set to the
+* attachment point for the device. This is invariant over the lifetime
+* of a gem object.
+*
+* The driver's ->gem_free_object callback is responsible for cleaning
+* up the dma_buf attachment and references acquired at import time.
+*/
struct dma_buf_attachment *import_attach;
};
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/20] drm/gem: move drm_gem_object_handle_unreference_unlocked into drm_gem.c
We have three callers of this function now and it's neither
performance critical nor really small. So an inline function feels
like overkill and unecessarily separates the different parts of the
code.
Since all callers of drm_gem_object_handle_free are now in drm_gem.c
we can make that static (and remove the unused EXPORT_SYMBOL). To
avoid a forward declaration move it (and drm_gem_object_free_bug) up a
bit.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 89 ---
include/drm/drmP.h| 21 +--
2 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 9ab038c..77c7d19 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -201,6 +201,60 @@ drm_gem_remove_prime_handles(struct drm_gem_object *obj,
struct drm_file *filp)
}
}
+static void drm_gem_object_ref_bug(struct kref *list_kref)
+{
+ BUG();
+}
+
+/**
+ * Called after the last handle to the object has been closed
+ *
+ * Removes any name for the object. Note that this must be
+ * called before drm_gem_object_free or we'll be touching
+ * freed memory
+ */
+static void drm_gem_object_handle_free(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+
+ /* Remove any name for this object */
+ spin_lock(&dev->object_name_lock);
+ if (obj->name) {
+ idr_remove(&dev->object_name_idr, obj->name);
+ obj->name = 0;
+ spin_unlock(&dev->object_name_lock);
+ /*
+* The object name held a reference to this object, drop
+* that now.
+ *
+ * This cannot be the last reference, since the handle holds one
too.
+*/
+ kref_put(&obj->refcount, drm_gem_object_ref_bug);
+ } else
+ spin_unlock(&dev->object_name_lock);
+
+}
+
+void
+drm_gem_object_handle_unreference_unlocked(struct drm_gem_object *obj)
+{
+ if (obj == NULL)
+ return;
+
+ if (atomic_read(&obj->handle_count) == 0)
+ return;
+
+ /*
+ * Must bump handle count first as this may be the last
+ * ref, in which case the object would disappear before we
+ * checked for a name
+ */
+
+ if (atomic_dec_and_test(&obj->handle_count))
+ drm_gem_object_handle_free(obj);
+ drm_gem_object_unreference_unlocked(obj);
+}
+
/**
* Removes the mapping from handle to filp for this object.
*/
@@ -533,41 +587,6 @@ drm_gem_object_free(struct kref *kref)
}
EXPORT_SYMBOL(drm_gem_object_free);
-static void drm_gem_object_ref_bug(struct kref *list_kref)
-{
- BUG();
-}
-
-/**
- * Called after the last handle to the object has been closed
- *
- * Removes any name for the object. Note that this must be
- * called before drm_gem_object_free or we'll be touching
- * freed memory
- */
-void drm_gem_object_handle_free(struct drm_gem_object *obj)
-{
- struct drm_device *dev = obj->dev;
-
- /* Remove any name for this object */
- spin_lock(&dev->object_name_lock);
- if (obj->name) {
- idr_remove(&dev->object_name_idr, obj->name);
- obj->name = 0;
- spin_unlock(&dev->object_name_lock);
- /*
-* The object name held a reference to this object, drop
-* that now.
- *
- * This cannot be the last reference, since the handle holds one
too.
-*/
- kref_put(&obj->refcount, drm_gem_object_ref_bug);
- } else
- spin_unlock(&dev->object_name_lock);
-
-}
-EXPORT_SYMBOL(drm_gem_object_handle_free);
-
void drm_gem_vm_open(struct vm_area_struct *vma)
{
struct drm_gem_object *obj = vma->vm_private_data;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3711e97..91c8d05 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1572,7 +1572,6 @@ int drm_gem_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size);
void drm_gem_private_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size);
-void drm_gem_object_handle_free(struct drm_gem_object *obj);
void drm_gem_vm_open(struct vm_area_struct *vma);
void drm_gem_vm_close(struct vm_area_struct *vma);
int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size,
@@ -1619,25 +1618,7 @@ drm_gem_object_handle_reference(struct drm_gem_object
*obj)
atomic_inc(&obj->handle_count);
}
-static inline void
-drm_gem_object_handle_unreference_unlocked(struct drm_gem_object *obj)
-{
- if (obj == NULL)
- return;
-
- if (atomic_read(&obj->handle_count) == 0)
- return;
-
- /*
- * Must bump handle count first as this may be the last
- * ref, in which case the object would
[PATCH 06/20] drm/gem: remove bogus NULL check from drm_gem_object_handle_unreference_unlocked
Calling this function with a NULL object is simply a bug, so papering
over a NULL object not a good idea.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 77c7d19..b1d9e25 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -238,9 +238,6 @@ static void drm_gem_object_handle_free(struct
drm_gem_object *obj)
void
drm_gem_object_handle_unreference_unlocked(struct drm_gem_object *obj)
{
- if (obj == NULL)
- return;
-
if (atomic_read(&obj->handle_count) == 0)
return;
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/20] drm/gem: WARN about unbalanced handle refcounts
Trying to drop a reference we don't have is a pretty serious bug.
Trying to paper over it is an even worse offense.
So scream into dmesg with a big WARN in case that ever happens.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index b1d9e25..9118f5f 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -238,7 +238,7 @@ static void drm_gem_object_handle_free(struct
drm_gem_object *obj)
void
drm_gem_object_handle_unreference_unlocked(struct drm_gem_object *obj)
{
- if (atomic_read(&obj->handle_count) == 0)
+ if (WARN_ON(atomic_read(&obj->handle_count) == 0))
return;
/*
--
1.8.3.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/20] drm/gem: fix up flink name create race
This is the 2nd attempt, I've always been a bit dissatisified with the
tricky nature of the first one:
http://lists.freedesktop.org/archives/dri-devel/2012-July/025451.html
The issue is that the flink ioctl can race with calling gem_close on
the last gem handle. In that case we'll end up with a zero handle
count, but an flink name (and it's corresponding reference). Which
results in a neat space leak.
In my first attempt I've solved this by rechecking the handle count.
But fundamentally the issue is that ->handle_count isn't your usual
refcount - it can be resurrected from 0 among other things.
For those special beasts atomic_t often suggest way more ordering that
it actually guarantees. To prevent being tricked by those hairy
semantics take the easy way out and simply protect the handle with the
existing dev->object_name_lock.
With that change implemented it's dead easy to fix the flink vs. gem
close reace: When we try to create the name we simply have to check
whether there's still officially a gem handle around and if not refuse
to create the flink name. Since the handle count decrement and flink
name destruction is now also protected by that lock the reace is gone
and we can't ever leak the flink reference again.
Outside of the drm core only the exynos driver looks at the handle
count, and tbh I have no idea why (it's just for debug dmesg output
luckily).
I've considered inlining the drm_gem_object_handle_free, but I plan to
add more name-like things (like the exported dma_buf) to this scheme,
so it's clearer to leave the handle freeing in its own function.
This is exercised by the new gem_flink_race i-g-t testcase, which on
my snb leaks gem objects at a rate of roughly 1k objects/s.
v2: Fix up the error path handling in handle_create and make it more
robust by simply calling object_handle_unreference.
v3: Fix up the handle_unreference logic bug - atomic_dec_and_test
retursn 1 for 0. Oops.
v4: Squash in inlining of drm_gem_object_handle_reference as suggested
by Dave Airlie and add a note that we now have a testcase.
Cc: Dave Airlie
Cc: Inki Dae
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 31 ---
drivers/gpu/drm/drm_info.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +-
include/drm/drmP.h | 19 ++-
4 files changed, 32 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 9118f5f..c972a8f 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -154,7 +154,7 @@ void drm_gem_private_object_init(struct drm_device *dev,
obj->filp = NULL;
kref_init(&obj->refcount);
- atomic_set(&obj->handle_count, 0);
+ obj->handle_count = 0;
obj->size = size;
}
EXPORT_SYMBOL(drm_gem_private_object_init);
@@ -218,11 +218,9 @@ static void drm_gem_object_handle_free(struct
drm_gem_object *obj)
struct drm_device *dev = obj->dev;
/* Remove any name for this object */
- spin_lock(&dev->object_name_lock);
if (obj->name) {
idr_remove(&dev->object_name_idr, obj->name);
obj->name = 0;
- spin_unlock(&dev->object_name_lock);
/*
* The object name held a reference to this object, drop
* that now.
@@ -230,15 +228,13 @@ static void drm_gem_object_handle_free(struct
drm_gem_object *obj)
* This cannot be the last reference, since the handle holds one
too.
*/
kref_put(&obj->refcount, drm_gem_object_ref_bug);
- } else
- spin_unlock(&dev->object_name_lock);
-
+ }
}
void
drm_gem_object_handle_unreference_unlocked(struct drm_gem_object *obj)
{
- if (WARN_ON(atomic_read(&obj->handle_count) == 0))
+ if (WARN_ON(obj->handle_count == 0))
return;
/*
@@ -247,8 +243,11 @@ drm_gem_object_handle_unreference_unlocked(struct
drm_gem_object *obj)
* checked for a name
*/
- if (atomic_dec_and_test(&obj->handle_count))
+ spin_lock(&obj->dev->object_name_lock);
+ if (--obj->handle_count == 0)
drm_gem_object_handle_free(obj);
+ spin_unlock(&obj->dev->object_name_lock);
+
drm_gem_object_unreference_unlocked(obj);
}
@@ -326,17 +325,21 @@ drm_gem_handle_create(struct drm_file *file_priv,
* allocation under our spinlock.
*/
idr_preload(GFP_KERNEL);
+ spin_lock(&dev->object_name_lock);
spin_lock(&file_priv->table_lock);
ret = idr_alloc(&file_priv->object_idr, obj, 1, 0, GFP_NOWAIT);
-
+ drm_gem_object_reference(obj);
+ obj->handle_count++;
spin_unlock(&file_priv->table_lock);
+ spin_unlock(&dev->object_name_lock);
idr_preload_end();
- if (ret < 0)
+ if (ret < 0) {
+ drm_gem_object_handle_unreference_unlocke
[PATCH 09/20] drm/prime: fix error path in drm_gem_prime_fd_to_handle
handle_unreference only clears up the obj->name and the reference, but would leave a dangling handle in the idr. The right thing to do is to call handle_delete. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_prime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index f115962..82cd83e 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -476,7 +476,7 @@ fail: /* hmm, if driver attached, we are relying on the free-object path * to detach.. which seems ok.. */ - drm_gem_object_handle_unreference_unlocked(obj); + drm_gem_handle_delete(file_priv, *handle); out_put: dma_buf_put(dma_buf); mutex_unlock(&file_priv->prime.lock); -- 1.8.3.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/20] drm/gem: create drm_gem_dumb_destroy
All the gem based kms drivers really want the same function to destroy a dumb framebuffer backing storage object. So give it to them and roll it out in all drivers. This still leaves the option open for kms drivers which don't use GEM for backing storage, but it does decently simplify matters for gem drivers. Cc: Inki Dae Cc: Laurent Pinchart Cc: Intel Graphics Development Cc: Ben Skeggs Cc: Rob Clark Cc: Alex Deucher Acked-by: Laurent Pinchart Reviewed-by: Rob Clark Acked-by: Inki Dae Signed-off-by: Daniel Vetter --- include/drm/drmP.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 0eb4a37..f08bbcf 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -1619,6 +1619,9 @@ int drm_gem_handle_create(struct drm_file *file_priv, u32 *handlep); int drm_gem_handle_delete(struct drm_file *filp, u32 handle); +int drm_gem_dumb_destroy(struct drm_file *file, +struct drm_device *dev, +uint32_t handle); void drm_gem_free_mmap_offset(struct drm_gem_object *obj); int drm_gem_create_mmap_offset(struct drm_gem_object *obj); -- 1.8.3.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
