Re: [Intel-gfx] [PATCH 2/5] [v2] drm/i915: cleanup mapfence in bind
On Mon, Aug 12, 2013 at 05:34:17PM -0700, Ben Widawsky wrote: Cleanup the map and fenceable setting during bind to make more sense, and not check i915_is_ggtt() 2 unnecessary times v2: Move the bools into the if block (Chris) - There are ways to tidy this function (fence calculations for instance) even further, but they are quite invasive, so I am punting on those unless specifically asked. Recommended-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky b...@bwidawsk.net Missing newline between variable declaration and logic, trivial enough for Daniel to fix up inline... Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Initialize seqno for VECS too
On Mon, Aug 12, 2013 at 04:53:03PM -0700, Ben Widawsky wrote:
Cc: Mika Kuoppala mika.kuopp...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65387
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67198
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Tested-by: lu hua huax...@intel.com (both bug reports)
Please pimp the commit message as discussion on irc (reply with just the
text is ok). Strictly speaking we initialize the 3rd mbox for the 4th ring
here (which ofc is the vebox one for all rings != vebox). And also please
mention the effects of this bug, i.e. how it blows up.
Thanks, Daniel
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 10c2aaa..665602f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1592,6 +1592,8 @@ void intel_ring_init_seqno(struct intel_ring_buffer
*ring, u32 seqno)
if (INTEL_INFO(ring-dev)-gen = 6) {
I915_WRITE(RING_SYNC_0(ring-mmio_base), 0);
I915_WRITE(RING_SYNC_1(ring-mmio_base), 0);
+ if (HAS_VEBOX(ring-dev))
+ I915_WRITE(RING_SYNC_2(ring-mmio_base), 0);
}
ring-set_seqno(ring, seqno);
--
1.8.3.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop the overzealous warning from i915_gem_set_cache_level
On Mon, Aug 12, 2013 at 11:46:17AM +0100, Chris Wilson wrote: By our earlier reckoning, move from a snooped/llc setting to an uncached setting, leaves the CPU cache in a consistent state irrespective of our domain tracking - so we can forgo the warning about the lack of invalidation. Similarly for any writes posted to the snooped CPU domain, we know will be safely clflushed to the uncached PTEs after forcing the domain change. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Ville Syrjälä ville.syrj...@linux.intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68040 Tested-by: cancan,feng cancan.f...@intel.com --- drivers/gpu/drm/i915/i915_gem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 925c77d..1d3e57e 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3520,7 +3520,6 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj, * Just set it to the CPU cache for now. */ WARN_ON(obj-base.write_domain ~I915_GEM_DOMAIN_CPU); - WARN_ON(obj-base.read_domains ~I915_GEM_DOMAIN_CPU); old_read_domains = obj-base.read_domains; old_write_domain = obj-base.write_domain; -- 1.8.4.rc2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't load context at driver init time on SNB
On Mon, Aug 12, 2013 at 10:33:37AM -0700, Stéphane Marchesin wrote: On Fri, Aug 9, 2013 at 9:55 PM, Ben Widawsky b...@bwidawsk.net wrote: On Fri, Aug 09, 2013 at 08:32:54PM -0700, Stéphane Marchesin wrote: This is a partial revert of b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 (drm/i915: load boot context at driver init time) This bit breaks hardware video decode for me after resume. Signed-off-by: Stéphane Marchesin marc...@chromium.org --- drivers/gpu/drm/i915/intel_pm.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index f895d15..ffa4ab2 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4614,10 +4614,6 @@ static void gen6_init_clock_gating(struct drm_device *dev) ILK_DPARBUNIT_CLOCK_GATE_ENABLE | ILK_DPFDUNIT_CLOCK_GATE_ENABLE); - /* WaMbcDriverBootEnable:snb */ - I915_WRITE(GEN6_MBCTL, I915_READ(GEN6_MBCTL) | -GEN6_MBCTL_ENABLE_BOOT_FETCH); - g4x_disable_trickle_feed(dev); /* The default value should be 0x200 according to docs, but the two I was looking at this a bit with Stéphane. One thing we both see is that the bit isn't sticking as it should. Clearly doing the write is having an effect, but something is seriously wrong. Writing the bit manually with IGT does make the bit stick. Stéphane, could you try to write the bit with IGT before and after resume, and see if it helps? It doesn't seem to stick, and so seems to have no effect. The confusing thing is that video decode works fine before suspend, even though that reg is 0. And after resume, it is broken, and that reg is still 0. So something else is going on. Maybe this reg is write-once-ever? BSpec says This Bit is cleared by the Hardware once the Boot fetch is complete. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, Changes since 20130812: The ext4 tree gained a conflict against Linus' tree. The infiniband tree gained a build failure for which I applied a merge fix patch and another so I used the version from next-20130812. The tty tree gained conflicts against the devicetree and tile trees. The usb tree gained a conflict against the net-next tree. The usb-gadget tree gained a build failure for which I reverted a commit. The ptr-ret tree gained a conflict against the staging tree. The akpm tree gained a conflict against the staging tree. Hi, with today's next-20130813 I cannot see 1/10 of my desktop-screen's top, it's simply black. I can estimate the URL line in Firefox (or open a new tab blindly and get a known URL from my autocompleted history). My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14. next-20130808 was OK - no screen corruptions. Any idea, hint? - Sedat - ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:14 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:10 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 10:28 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, Changes since 20130812: The ext4 tree gained a conflict against Linus' tree. The infiniband tree gained a build failure for which I applied a merge fix patch and another so I used the version from next-20130812. The tty tree gained conflicts against the devicetree and tile trees. The usb tree gained a conflict against the net-next tree. The usb-gadget tree gained a build failure for which I reverted a commit. The ptr-ret tree gained a conflict against the staging tree. The akpm tree gained a conflict against the staging tree. Hi, with today's next-20130813 I cannot see 1/10 of my desktop-screen's top, it's simply black. I can estimate the URL line in Firefox (or open a new tab blindly and get a known URL from my autocompleted history). My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14. next-20130808 was OK - no screen corruptions. Any idea, hint? - Sedat - [ From my dmesg ] [ 28.026524] [ cut here ] [ 28.026557] WARNING: CPU: 3 PID: 639 at drivers/gpu/drm/i915/i915_gem.c:3435 i915_gem_object_set_cache_level+0x389/0x3a0 [i915]() [ 28.026560] Modules linked in: arc4 snd_hwdep i915(+) iwldvm snd_pcm snd_page_alloc mac80211 snd_seq_midi parport_pc snd_seq_midi_event rfcomm bnep snd_rawmidi ppdev uvcvideo snd_seq btusb videobuf2_vmalloc i2c_algo_bit psmouse iwlwifi drm_kms_helper videobuf2_memops snd_timer drm snd_seq_device videobuf2_core bluetooth videodev serio_raw snd cfg80211 samsung_laptop wmi soundcore lp mac_hid video lpc_ich parport hid_generic usbhid hid usb_storage r8169 mii [ 28.026610] CPU: 3 PID: 639 Comm: modprobe Not tainted 3.11.0-rc5-next20130813-1-iniza-small #1 [ 28.026613] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH, BIOS 13XK 03/28/2013 [ 28.026616] 0d6b 8800795535a8 816e259a 0007 [ 28.026622] 8800795535e8 810661dc 81376e70 [ 28.026627] 8800746ba200 8800746ba2b8 88007a2c7000 0041 [ 28.026632] Call Trace: [ 28.026641] [816e259a] dump_stack+0x46/0x58 [ 28.026647] [810661dc] warn_slowpath_common+0x8c/0xc0 [ 28.026653] [81376e70] ? sg_kfree+0x30/0x30 [ 28.026658] [8106622a] warn_slowpath_null+0x1a/0x20 [ 28.026680] [a03e1fe9] i915_gem_object_set_cache_level+0x389/0x3a0 [i915] [ 28.026684] [8137723f] ? sg_alloc_table+0x1f/0x50 [ 28.026703] [a03e2162] i915_gem_object_pin_to_display_plane+0x62/0x1c0 [i915] [ 28.026727] [a03f9b10] intel_pin_and_fence_fb_obj+0xc0/0x140 [i915] [ 28.026732] [816e82ee] ? mutex_lock+0x1e/0x40 [ 28.026761] [a0424277] intelfb_create+0x107/0x510 [i915] [ 28.026778] [a020f807] ? drm_mode_create+0x47/0x70 [drm] [ 28.026786] [a01a404e] drm_fb_helper_initial_config+0x2fe/0x550 [drm_kms_helper] [ 28.026813] [a0431323] ? i915_write32+0xc3/0x190 [i915] [ 28.026838] [a0424751] intel_fbdev_initial_config+0x21/0x30 [i915] [ 28.026859] [a03cb38d] i915_driver_load+0xe9d/0xed0 [i915] [ 28.026876] [a020aad1] drm_get_pci_dev+0x181/0x2a0 [drm] [ 28.026881] [8137b12d] ? do_raw_spin_unlock+0x5d/0xb0 [ 28.026900] [a03c75d6] i915_pci_probe+0x36/0x70 [i915] [ 28.026905] [81399ceb] local_pci_probe+0x4b/0x80 [ 28.026910] [8139b5c1] pci_device_probe+0x101/0x120 [ 28.026915] [81478a1b] driver_probe_device+0x7b/0x240 [ 28.026920] [81478c8b] __driver_attach+0xab/0xb0 [ 28.026924] [81478be0] ? driver_probe_device+0x240/0x240 [ 28.026928] [81476b6e] bus_for_each_dev+0x5e/0x90 [ 28.026932] [8147851e] driver_attach+0x1e/0x20 [ 28.026936] [81477fc4] bus_add_driver+0x104/0x2a0 [ 28.026941] [814793f4] driver_register+0x64/0xf0 [ 28.026946] [8139a544] __pci_register_driver+0x64/0x70 [ 28.026951] [a0475000] ? 0xa0474fff [ 28.026963] [a020ad0a] drm_pci_init+0x11a/0x130 [drm] [ 28.026968] [a0475000] ? 0xa0474fff [ 28.026987] [a0475066] i915_init+0x66/0x68 [i915] [ 28.026992] [8100207e] do_one_initcall+0x4e/0x180 [ 28.026997] [81058413] ? set_memory_nx+0x43/0x50 [ 28.027003] [810d147c] load_module+0x209c/0x25b0 [ 28.027007] [810ce0a0] ? show_initstate+0x50/0x50 [ 28.027013] [810d1a3c] SyS_init_module+0xac/0xd0 [ 28.027018] [816f41ef] tracesys+0xe1/0xe6
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote: Hi, with today's next-20130813 I cannot see 1/10 of my desktop-screen's top, it's simply black. I can estimate the URL line in Firefox (or open a new tab blindly and get a known URL from my autocompleted history). Can you attach a photograph? My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14. next-20130808 was OK - no screen corruptions. Any idea, hint? Can you please try: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index af1b2f0..b0f181d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1837,7 +1837,7 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev, break; case I915_TILING_X: /* pin() will align the object as required by fence */ - alignment = 0; + alignment = 256 * 1024; break; case I915_TILING_Y: /* Despite that we check this in framebuffer_init userspace can -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:25 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Tue, Aug 13, 2013 at 11:10:18AM +0200, Sedat Dilek wrote: Hi, with today's next-20130813 I cannot see 1/10 of my desktop-screen's top, it's simply black. I can estimate the URL line in Firefox (or open a new tab blindly and get a known URL from my autocompleted history). Can you attach a photograph? It's a black bar on the top of my desktop-screen - approx. 1/10. It looks like this is also in the VT on bootup before entering LightDM. My Xorg stack did not change: libdrm-2.4.46 | mesa-9.16 | intel-ddx-2.4.14. next-20130808 was OK - no screen corruptions. Any idea, hint? Can you please try: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index af1b2f0..b0f181d 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1837,7 +1837,7 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev, break; case I915_TILING_X: /* pin() will align the object as required by fence */ - alignment = 0; + alignment = 256 * 1024; break; case I915_TILING_Y: /* Despite that we check this in framebuffer_init userspace can -- NO, that did not help. 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. - Sedat - ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
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? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk 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 xrand output attached. - Sedat - P.S.: I switched to intel-ddx v2-21-14-35-g5840bf in the meantime. Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192 LVDS1 connected 1366x768+0+0 (0x45) normal (normal left inverted right x axis y axis) 0mm x 0mm Identifier: 0x41 Timestamp: 339571 Subpixel: horizontal rgb Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 0 CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: BACKLIGHT: 7 (0x0007) range: (0,7) Backlight: 7 (0x0007) range: (0,7) scaling mode: Full aspect supported: None Full Center Full aspect 1366x768 (0x45) 70.7MHz -HSync -VSync *current +preferred h: width 1366 start 1414 end 1446 total 1486 skew0 clock 47.6KHz v: height 768 start 770 end 775 total 792 clock 60.1Hz 1360x768 (0x46) 84.8MHz -HSync +VSync h: width 1360 start 1432 end 1568 total 1776 skew0 clock 47.7KHz v: height 768 start 771 end 781 total 798 clock 59.8Hz 1360x768 (0x47) 72.0MHz +HSync -VSync h: width 1360 start 1408 end 1440 total 1520 skew0 clock 47.4KHz v: height 768 start 771 end 781 total 790 clock 60.0Hz 1024x768 (0x48) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x49) 40.0MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 800x600 (0x4a) 36.0MHz +HSync +VSync h: width 800 start 824 end 896 total 1024 skew0 clock 35.2KHz v: height 600 start 601 end 603 total 625 clock 56.2Hz 640x480 (0x4b) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew0 clock 31.5KHz v: height 480 start 490 end 492 total 525 clock 59.9Hz VGA1 disconnected (normal left inverted right x axis y axis) Identifier: 0x42 Timestamp: 339571 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: HDMI1 disconnected (normal left inverted right x axis y axis) Identifier: 0x43 Timestamp: 339571 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: Broadcast RGB: Automatic supported: AutomaticFull Limited 16:2 audio: auto supported: force-dvioff auto on DP1 disconnected (normal left inverted right x axis y axis) Identifier: 0x44 Timestamp: 339571 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: Broadcast RGB: Automatic supported: AutomaticFull Limited 16:2 audio: auto supported: force-dvioff auto on ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:47:19AM +0200, Sedat Dilek wrote: On Tue, Aug 13, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk 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... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk 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 - ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop the overzealous warning from i915_gem_set_cache_level
Hi, feel free to add... Reported -by: Sedat Dilek sedat.di...@gmail.com (against next-20130813 see [1]) Tested-by: Sedat Dilek sedat.di...@gmail.com Thanks. Regards, - Sedat - [1] http://lists.freedesktop.org/archives/intel-gfx/2013-August/031725.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop the overzealous warning from i915_gem_set_cache_level
On Tue, Aug 13, 2013 at 09:54:48AM +0200, Daniel Vetter wrote: On Mon, Aug 12, 2013 at 11:46:17AM +0100, Chris Wilson wrote: By our earlier reckoning, move from a snooped/llc setting to an uncached setting, leaves the CPU cache in a consistent state irrespective of our domain tracking - so we can forgo the warning about the lack of invalidation. Similarly for any writes posted to the snooped CPU domain, we know will be safely clflushed to the uncached PTEs after forcing the domain change. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Ville Syrjälä ville.syrj...@linux.intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68040 Tested-by: cancan,feng cancan.f...@intel.com Oh and QA blames that this WARN newly pops up on commit d46f1c3f1372e3a72fab97c60480aa4a1084387f Author: Chris Wilson ch...@chris-wilson.co.uk AuthorDate: Thu Aug 8 14:41:06 2013 +0100 Commit: Daniel Vetter daniel.vet...@ffwll.ch CommitDate: Sat Aug 10 11:24:18 2013 +0200 drm/i915: Allow the GPU to cache stolen memory -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop the overzealous warning from i915_gem_set_cache_level
On Mon, Aug 12, 2013 at 11:46:17AM +0100, Chris Wilson wrote: By our earlier reckoning, move from a snooped/llc setting to an uncached setting, leaves the CPU cache in a consistent state irrespective of our domain tracking - so we can forgo the warning about the lack of invalidation. Similarly for any writes posted to the snooped CPU domain, we know will be safely clflushed to the uncached PTEs after forcing the domain change. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/i915_gem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 925c77d..1d3e57e 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3520,7 +3520,6 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj, * Just set it to the CPU cache for now. */ WARN_ON(obj-base.write_domain ~I915_GEM_DOMAIN_CPU); - WARN_ON(obj-base.read_domains ~I915_GEM_DOMAIN_CPU); AFAICS this can only be reached by stolen objs starting in GTT read domain. Normally set_cache_level checks if the object is bound and then calls finish_gtt, and unbind also calls finish_gtt, and GPU domain is handled in a similar way. So I don't see that we can end up here any other way. Based on that, both WARNs seem rather pointless actually. Then again I'm not really sure what we gain from setting stolen objs to GTT read domain initially. The write domain check might make a bit of sense, except for the fact that finish_gtt/gpu clears it just before. Thinking about this stuff a bit, I think I actually came up with a scenario where we would currently fail to invalidate the CPU cache between non-snooped GPU/GTT access and CPU access: 1. make bo non-snooped w/ pin_display=true (wd=0, rd|=gtt) 2. set to CPU read domain (wd=0 rd|=cpu) 3. set to GTT (or GPU) write domain (wd=gtt, rd=gtt) - CPU cache is stale after this point 4. make bo snooped - pin_display=true still so we directly set (wd=cpu, rd=cpu) 5. set to CPU domain - CPU cache is still stale old_read_domains = obj-base.read_domains; old_write_domain = obj-base.write_domain; -- 1.8.4.rc2 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop the overzealous warning from i915_gem_set_cache_level
On Tue, Aug 13, 2013 at 03:12:59PM +0300, Ville Syrjälä wrote: Thinking about this stuff a bit, I think I actually came up with a scenario where we would currently fail to invalidate the CPU cache between non-snooped GPU/GTT access and CPU access: 1. make bo non-snooped w/ pin_display=true (wd=0, rd|=gtt) 2. set to CPU read domain (wd=0 rd|=cpu) 3. set to GTT (or GPU) write domain (wd=gtt, rd=gtt) - CPU cache is stale after this point 4. make bo snooped - pin_display=true still so we directly set (wd=cpu, rd=cpu) 5. set to CPU domain - CPU cache is still stale You will also find the scanout reads stale data as well. You've managed to shoot yourself in both feet. The kernel can't fix that, so should we care about the other foot? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop the overzealous warning from i915_gem_set_cache_level
On Tue, Aug 13, 2013 at 01:20:13PM +0100, Chris Wilson wrote: On Tue, Aug 13, 2013 at 03:12:59PM +0300, Ville Syrjälä wrote: Thinking about this stuff a bit, I think I actually came up with a scenario where we would currently fail to invalidate the CPU cache between non-snooped GPU/GTT access and CPU access: 1. make bo non-snooped w/ pin_display=true (wd=0, rd|=gtt) 2. set to CPU read domain (wd=0 rd|=cpu) 3. set to GTT (or GPU) write domain (wd=gtt, rd=gtt) - CPU cache is stale after this point 4. make bo snooped - pin_display=true still so we directly set (wd=cpu, rd=cpu) 5. set to CPU domain - CPU cache is still stale You will also find the scanout reads stale data as well. Well, assuming you actually write something to the bo w/ the CPU. If not, then it keeps scanning out the correct data. You've managed to shoot yourself in both feet. The kernel can't fix that, so should we care about the other foot? Yeah, I suppose we shouldn't care too much about problems the user created for himself. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/14] drm/i915: Baytrail MIPI DSI support
Hi all - This series adds rudimentary MIPI DSI support to Baytrail. It's been built around the idea of panel specific sub-encoders, similar to the DVO support we have. This work is by no means complete; there are plenty of rough edges, but it should be a somewhat sane start to build upon. I'm aware of the Common Display Framework and drm_bridge patches. In the future, I expect our DSI support to be ported over to whatever eventually comes out of them. In the mean time, we can't wait for them to be completed, and I believe it would be helpful for that effort to have our bits and pieces upstream. The last patch is provided as an (incomplete) example of a sub-encoder, or a panel driver. It should *not* be merged. There's no proper detection or VBT handling yet, so that will cause warnings about inconsistent crtc/pll states... BR, Jani. Jani Nikula (9): drm/i915: add more VLV IOSF sideband ports accessors drm/i915: add VLV pipeconf bit definition for DSI PLL lock drm/i915: add MIPI DSI register definitions drm/i915: add MIPI DSI output type and subtypes drm/i915: add structs for MIPI DSI output drm/i915: add MIPI DSI command sending routines drm/i915: add basic MIPI DSI output support drm/i915: don't enable DPLL for DSI drm/i915: initialize DSI output on VLV Shobhit Kumar (4): drm: add MIPI DSI encoder and connector types drm/i915: Band Gap WA drm/i915: Parse the MIPI related VBT Block and store relevant info drm/i915: add AUO MIPI DSI display sub-encoder ymohanma (1): drm/i915: add VLV DSI PLL Calculations drivers/gpu/drm/drm_crtc.c |2 + drivers/gpu/drm/i915/Makefile |4 + drivers/gpu/drm/i915/auo_dsi_display.c | 182 ++ drivers/gpu/drm/i915/i915_drv.h| 13 + drivers/gpu/drm/i915/i915_reg.h| 424 ++ drivers/gpu/drm/i915/intel_bios.c | 16 + drivers/gpu/drm/i915/intel_bios.h | 41 +++ drivers/gpu/drm/i915/intel_display.c | 52 ++- drivers/gpu/drm/i915/intel_drv.h |7 +- drivers/gpu/drm/i915/intel_dsi.c | 606 drivers/gpu/drm/i915/intel_dsi.h | 104 ++ drivers/gpu/drm/i915/intel_dsi_cmd.c | 442 +++ drivers/gpu/drm/i915/intel_dsi_cmd.h | 109 ++ drivers/gpu/drm/i915/intel_dsi_pll.c | 290 +++ drivers/gpu/drm/i915/intel_sideband.c | 56 +++ include/uapi/drm/drm_mode.h|2 + 16 files changed, 2330 insertions(+), 20 deletions(-) create mode 100644 drivers/gpu/drm/i915/auo_dsi_display.c create mode 100644 drivers/gpu/drm/i915/intel_dsi.c create mode 100644 drivers/gpu/drm/i915/intel_dsi.h create mode 100644 drivers/gpu/drm/i915/intel_dsi_cmd.c create mode 100644 drivers/gpu/drm/i915/intel_dsi_cmd.h create mode 100644 drivers/gpu/drm/i915/intel_dsi_pll.c -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/14] drm: add MIPI DSI encoder and connector types
From: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/drm_crtc.c |2 ++
include/uapi/drm/drm_mode.h |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fc83bb9..8768c5f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -209,6 +209,7 @@ static struct drm_conn_prop_enum_list
drm_connector_enum_list[] =
{ DRM_MODE_CONNECTOR_TV, TV, 0 },
{ DRM_MODE_CONNECTOR_eDP, eDP, 0 },
{ DRM_MODE_CONNECTOR_VIRTUAL, Virtual, 0},
+ { DRM_MODE_CONNECTOR_DSI, DSI, 0},
};
static const struct drm_prop_enum_list drm_encoder_enum_list[] =
@@ -218,6 +219,7 @@ static const struct drm_prop_enum_list
drm_encoder_enum_list[] =
{ DRM_MODE_ENCODER_LVDS, LVDS },
{ DRM_MODE_ENCODER_TVDAC, TV },
{ DRM_MODE_ENCODER_VIRTUAL, Virtual },
+ { DRM_MODE_ENCODER_DSI, DSI },
};
const char *drm_get_encoder_name(const struct drm_encoder *encoder)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 53db7ce..589114e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -165,6 +165,7 @@ struct drm_mode_get_plane_res {
#define DRM_MODE_ENCODER_LVDS 3
#define DRM_MODE_ENCODER_TVDAC 4
#define DRM_MODE_ENCODER_VIRTUAL 5
+#define DRM_MODE_ENCODER_DSI 6
struct drm_mode_get_encoder {
__u32 encoder_id;
@@ -203,6 +204,7 @@ struct drm_mode_get_encoder {
#define DRM_MODE_CONNECTOR_TV 13
#define DRM_MODE_CONNECTOR_eDP 14
#define DRM_MODE_CONNECTOR_VIRTUAL 15
+#define DRM_MODE_CONNECTOR_DSI 16
struct drm_mode_get_connector {
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/14] drm/i915: add more VLV IOSF sideband ports accessors
For GPIO NC, CCK, CCU, and GPS CORE.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |8 +
drivers/gpu/drm/i915/i915_reg.h |4 +++
drivers/gpu/drm/i915/intel_sideband.c | 56 +
3 files changed, 68 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dcae809..6db95a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2164,6 +2164,14 @@ int sandybridge_pcode_write(struct drm_i915_private
*dev_priv, u8 mbox, u32 val)
u32 vlv_punit_read(struct drm_i915_private *dev_priv, u8 addr);
void vlv_punit_write(struct drm_i915_private *dev_priv, u8 addr, u32 val);
u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
+u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg);
+void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
+u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg);
+void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
+u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
+void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
+u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg);
+void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
u32 vlv_dpio_read(struct drm_i915_private *dev_priv, int reg);
void vlv_dpio_write(struct drm_i915_private *dev_priv, int reg, u32 val);
u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 17f6252..a30e876 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -360,6 +360,10 @@
#define IOSF_PORT_PUNIT 0x4
#define IOSF_PORT_NC 0x11
#define IOSF_PORT_DPIO 0x12
+#define IOSF_PORT_GPIO_NC0x13
+#define IOSF_PORT_CCK0x14
+#define IOSF_PORT_CCU0xA9
+#define IOSF_PORT_GPS_CORE 0x48
#define VLV_IOSF_DATA (VLV_DISPLAY_BASE + 0x2104)
#define VLV_IOSF_ADDR (VLV_DISPLAY_BASE + 0x2108)
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index 9a0e6c5..0a41670 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -101,6 +101,62 @@ u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr)
return val;
}
+u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg)
+{
+ u32 val = 0;
+ vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPIO_NC,
+ PUNIT_OPCODE_REG_READ, reg, val);
+ return val;
+}
+
+void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+{
+ vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPIO_NC,
+ PUNIT_OPCODE_REG_WRITE, reg, val);
+}
+
+u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg)
+{
+ u32 val = 0;
+ vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCK,
+ PUNIT_OPCODE_REG_READ, reg, val);
+ return val;
+}
+
+void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+{
+ vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCK,
+ PUNIT_OPCODE_REG_WRITE, reg, val);
+}
+
+u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg)
+{
+ u32 val = 0;
+ vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCU,
+ PUNIT_OPCODE_REG_READ, reg, val);
+ return val;
+}
+
+void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+{
+ vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCU,
+ PUNIT_OPCODE_REG_WRITE, reg, val);
+}
+
+u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg)
+{
+ u32 val = 0;
+ vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPS_CORE,
+ PUNIT_OPCODE_REG_READ, reg, val);
+ return val;
+}
+
+void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
+{
+ vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPS_CORE,
+ PUNIT_OPCODE_REG_WRITE, reg, val);
+}
+
u32 vlv_dpio_read(struct drm_i915_private *dev_priv, int reg)
{
u32 val = 0;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/14] drm/i915: add MIPI DSI register definitions
Add definitions for VLV MIPI DSI registers. Signed-off-by: Jani Nikula jani.nik...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 409 +++ 1 file changed, 409 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index aced53a..32e32b6 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -5104,4 +5104,413 @@ #define PIPE_CSC_POSTOFF_ME(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME) #define PIPE_CSC_POSTOFF_LO(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO) +/* VLV MIPI registers */ + +/* XXX: This register seems very messy. MIPIB has only enable and delay. */ +#define _MIPIA_PORT_CTRL (VLV_DISPLAY_BASE + 0x61190) +#define _MIPIB_PORT_CTRL (VLV_DISPLAY_BASE + 0x61700) +#define MIPI_PORT_CTRL(pipe) _PIPE(pipe, _MIPIA_PORT_CTRL, _MIPIB_PORT_CTRL) +#define DPI_ENABLE(1 31) /* A + B */ +#define MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT 27 +#define MIPIA_MIPI4DPHY_DELAY_COUNT_MASK (0xf 27) +#define DUAL_LINK_MODE_MASK (1 26) +#define DUAL_LINK_MODE_FRONT_BACK (0 26) +#define DUAL_LINK_MODE_PIXEL_ALTERNATIVE (1 26) +#define FLOPPED_HSTX (1 23) +#define DE_INVERT (1 19) /* XXX */ +#define MIPIA_FLISDSI_DELAY_COUNT_SHIFT 18 +#define MIPIA_FLISDSI_DELAY_COUNT_MASK(0xf 18) +#define AFE_LATCHOUT (1 17) +#define MIPIB_FLISDSI_DELAY_COUNT_HIGH_SHIFT 15 +#define MIPIB_FLISDSI_DELAY_COUNT_HIGH_MASK (1 15) +#define MIPIB_MIPI4DPHY_DELAY_COUNT_SHIFT 11 +#define MIPIB_MIPI4DPHY_DELAY_COUNT_MASK (0xf 11) +#define CSB_SHIFT 9 +#define CSB_MASK (3 9) +#define CSB_20MHZ (0 9) +#define CSB_10MHZ (1 9) +#define CSB_40MHZ (2 9) +#define BANDGAP_MASK (1 8) +#define BANDGAP_PNW_CIRCUIT (0 8) +#define BANDGAP_LNC_CIRCUIT (1 8) +#define MIPIB_FLISDSI_DELAY_COUNT_LOW_SHIFT 5 +#define MIPIB_FLISDSI_DELAY_COUNT_LOW_MASK(7 5) +#define TEARING_EFFECT_DELAY (1 4) /* A + B */ +#define TEARING_EFFECT_SHIFT 2 /* A + B */ +#define TEARING_EFFECT_MASK (3 2) +#define TEARING_EFFECT_OFF(0 2) +#define TEARING_EFFECT_DSI(1 2) +#define TEARING_EFFECT_GPIO (2 2) +#define LANE_CONFIGURATION_SHIFT 0 +#define LANE_CONFIGURATION_MASK (3 0) +#define LANE_CONFIGURATION_4LANE (0 0) +#define LANE_CONFIGURATION_DUAL_LINK_A(1 0) +#define LANE_CONFIGURATION_DUAL_LINK_B(2 0) + +#define _MIPIA_TEARING_CTRL(VLV_DISPLAY_BASE + 0x61194) +#define _MIPIB_TEARING_CTRL(VLV_DISPLAY_BASE + 0x61704) +#define MIPI_TEARING_CTRL(pipe)_PIPE(pipe, _MIPIA_TEARING_CTRL, _MIPIB_TEARING_CTRL) +#define TEARING_EFFECT_DELAY_SHIFT0 +#define TEARING_EFFECT_DELAY_MASK (0x 0) + +/* XXX */ +#define _MIPIA_AUTOPWG (VLV_DISPLAY_BASE + 0x611a0) + +/* MIPI DSI Controller and D-PHY registers */ + +#define _MIPIA_DEVICE_READY(VLV_DISPLAY_BASE + 0xb000) +#define _MIPIB_DEVICE_READY(VLV_DISPLAY_BASE + 0xb800) +#define MIPI_DEVICE_READY(pipe)_PIPE(pipe, _MIPIA_DEVICE_READY, _MIPIB_DEVICE_READY) +#define BUS_POSSESSION(1 3) /* set to give bus to receiver */ +#define ULPS_STATE_MASK (3 1) +#define ULPS_STATE_ENTER (2 1) /* XXX */ +#define ULPS_STATE_EXIT (1 1) /* XXX */ +#define DEVICE_READY (1 0) + +#define _MIPIA_INTR_STAT (VLV_DISPLAY_BASE + 0xb004) +#define _MIPIB_INTR_STAT (VLV_DISPLAY_BASE + 0xb804) +#define MIPI_INTR_STAT(pipe) _PIPE(pipe, _MIPIA_INTR_STAT, _MIPIB_INTR_STAT) +#define _MIPIA_INTR_EN (VLV_DISPLAY_BASE + 0xb008) +#define _MIPIB_INTR_EN (VLV_DISPLAY_BASE + 0xb808) +#define MIPI_INTR_EN(pipe) _PIPE(pipe, _MIPIA_INTR_EN, _MIPIB_INTR_EN) +#define TEARING_EFFECT(1 31)
[Intel-gfx] [PATCH 03/14] drm/i915: add VLV pipeconf bit definition for DSI PLL lock
Signed-off-by: Jani Nikula jani.nik...@intel.com --- drivers/gpu/drm/i915/i915_reg.h |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index a30e876..aced53a 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2972,6 +2972,7 @@ #define PIPECONF_DISABLE 0 #define PIPECONF_DOUBLE_WIDE (130) #define I965_PIPECONF_ACTIVE (130) +#define PIPECONF_DSI_PLL_LOCKED (129) /* vlv only */ #define PIPECONF_FRAME_START_DELAY_MASK (327) #define PIPECONF_SINGLE_WIDE 0 #define PIPECONF_PIPE_UNLOCKED 0 -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/14] drm/i915: add MIPI DSI output type and subtypes
Signed-off-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_drv.h |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 01455aa..a31abc6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -93,13 +93,17 @@
#define INTEL_OUTPUT_HDMI 6
#define INTEL_OUTPUT_DISPLAYPORT 7
#define INTEL_OUTPUT_EDP 8
-#define INTEL_OUTPUT_UNKNOWN 9
+#define INTEL_OUTPUT_DSI 9
+#define INTEL_OUTPUT_UNKNOWN 10
#define INTEL_DVO_CHIP_NONE 0
#define INTEL_DVO_CHIP_LVDS 1
#define INTEL_DVO_CHIP_TMDS 2
#define INTEL_DVO_CHIP_TVOUT 4
+#define INTEL_DSI_COMMAND_MODE 0
+#define INTEL_DSI_VIDEO_MODE 1
+
struct intel_framebuffer {
struct drm_framebuffer base;
struct drm_i915_gem_object *obj;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/14] drm/i915: add structs for MIPI DSI output
The sub-encoder model is copied from DVO.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.h | 99 ++
1 file changed, 99 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_dsi.h
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
new file mode 100644
index 000..45f649a
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -0,0 +1,99 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _INTEL_DSI_H
+#define _INTEL_DSI_H
+
+#include drm/drmP.h
+#include drm/drm_crtc.h
+#include intel_drv.h
+
+struct intel_dsi_device {
+ unsigned int panel_id;
+ const char *name;
+ int type;
+ const struct intel_dsi_dev_ops *dev_ops;
+ void *dev_priv;
+};
+
+struct intel_dsi_dev_ops {
+ bool (*init)(struct intel_dsi_device *dsi);
+
+ /* This callback must be able to assume DSI commands can be sent */
+ void (*enable)(struct intel_dsi_device *dsi);
+
+ /* This callback must be able to assume DSI commands can be sent */
+ void (*disable)(struct intel_dsi_device *dsi);
+
+ int (*mode_valid)(struct intel_dsi_device *dsi,
+ struct drm_display_mode *mode);
+
+ bool (*mode_fixup)(struct intel_dsi_device *dsi,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode);
+
+ void (*mode_set)(struct intel_dsi_device *dsi,
+struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode);
+
+ enum drm_connector_status (*detect)(struct intel_dsi_device *dsi);
+
+ bool (*get_hw_state)(struct intel_dsi_device *dev);
+
+ struct drm_display_mode *(*get_modes)(struct intel_dsi_device *dsi);
+
+ void (*destroy) (struct intel_dsi_device *dsi);
+};
+
+struct intel_dsi {
+ struct intel_encoder base;
+
+ struct intel_dsi_device dev;
+
+ struct drm_display_mode *panel_fixed_mode;
+
+ /* if true, use HS mode, otherwise LP */
+ bool hs;
+
+ /* virtual channel */
+ int channel;
+
+ /* number of DSI lanes */
+ unsigned int lane_count;
+
+ /* video mode pixel format for MIPI_DSI_FUNC_PRG register */
+ u32 pixel_format;
+
+ /* video mode format for MIPI_VIDEO_MODE_FORMAT register */
+ u32 video_mode_format;
+
+ /* eot for MIPI_EOT_DISABLE register */
+ u32 eot_disable;
+};
+
+static inline struct intel_dsi *enc_to_intel_dsi(struct drm_encoder *encoder)
+{
+ return container_of(encoder, struct intel_dsi, base.base);
+}
+
+#endif /* _INTEL_DSI_H */
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/14] drm/i915: add MIPI DSI command sending routines
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/intel_dsi_cmd.c | 442 ++
drivers/gpu/drm/i915/intel_dsi_cmd.h | 109 +
3 files changed, 552 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_dsi_cmd.c
create mode 100644 drivers/gpu/drm/i915/intel_dsi_cmd.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b8449a8..8bffd29 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -21,6 +21,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
intel_display.o \
intel_crt.o \
intel_lvds.o \
+ intel_dsi_cmd.o \
intel_bios.o \
intel_ddi.o \
intel_dp.o \
diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.c
b/drivers/gpu/drm/i915/intel_dsi_cmd.c
new file mode 100644
index 000..e78dd97
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dsi_cmd.c
@@ -0,0 +1,442 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Author: Jani Nikula jani.nik...@intel.com
+ */
+
+#include linux/export.h
+#include drm/drmP.h
+#include drm/drm_crtc.h
+#include video/mipi_display.h
+#include i915_drv.h
+#include intel_drv.h
+#include intel_dsi.h
+#include intel_dsi_cmd.h
+
+/*
+ * XXX: MIPI_DATA_ADDRESS, MIPI_DATA_LENGTH, MIPI_COMMAND_LENGTH, and
+ * MIPI_COMMAND_ADDRESS registers.
+ *
+ * Apparently these registers provide a MIPI adapter level way to send (lots
of)
+ * commands and data to the receiver, without having to write the commands and
+ * data to MIPI_{HS,LP}_GEN_{CTRL,DATA} registers word by word.
+ *
+ * Presumably for anything other than MIPI_DCS_WRITE_MEMORY_START and
+ * MIPI_DCS_WRITE_MEMORY_CONTINUE (which are used to update the external
+ * framebuffer in command mode displays) these are just an optimization that
can
+ * come later.
+ *
+ * For memory writes, these should probably be used for performance.
+ */
+
+static void print_stat(struct intel_dsi *intel_dsi)
+{
+ struct drm_encoder *encoder = intel_dsi-base.base;
+ struct drm_device *dev = encoder-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder-crtc);
+ enum pipe pipe = intel_crtc-pipe;
+ u32 val;
+
+ val = I915_READ(MIPI_INTR_STAT(pipe));
+
+#define STAT_BIT(val, bit) (val) (bit) ? #bit :
+ DRM_DEBUG_KMS(MIPI_INTR_STAT(%d) = %08x
+
%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s
+ \n, pipe, val,
+ STAT_BIT(val, TEARING_EFFECT),
+ STAT_BIT(val, SPL_PKT_SENT_INTERRUPT),
+ STAT_BIT(val, GEN_READ_DATA_AVAIL),
+ STAT_BIT(val, LP_GENERIC_WR_FIFO_FULL),
+ STAT_BIT(val, HS_GENERIC_WR_FIFO_FULL),
+ STAT_BIT(val, RX_PROT_VIOLATION),
+ STAT_BIT(val, RX_INVALID_TX_LENGTH),
+ STAT_BIT(val, ACK_WITH_NO_ERROR),
+ STAT_BIT(val, TURN_AROUND_ACK_TIMEOUT),
+ STAT_BIT(val, LP_RX_TIMEOUT),
+ STAT_BIT(val, HS_TX_TIMEOUT),
+ STAT_BIT(val, DPI_FIFO_UNDERRUN),
+ STAT_BIT(val, LOW_CONTENTION),
+ STAT_BIT(val, HIGH_CONTENTION),
+ STAT_BIT(val, TXDSI_VC_ID_INVALID),
+ STAT_BIT(val, TXDSI_DATA_TYPE_NOT_RECOGNISED),
+ STAT_BIT(val, TXCHECKSUM_ERROR),
+ STAT_BIT(val, TXECC_MULTIBIT_ERROR),
+ STAT_BIT(val, TXECC_SINGLE_BIT_ERROR),
+ STAT_BIT(val, TXFALSE_CONTROL_ERROR),
+ STAT_BIT(val, RXDSI_VC_ID_INVALID),
+ STAT_BIT(val,
[Intel-gfx] [PATCH 08/14] drm/i915: add basic MIPI DSI output support
This does not include any panel specific sub-encoders yet.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_dsi.c | 548 ++
3 files changed, 550 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_dsi.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8bffd29..5864c5b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -21,6 +21,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
intel_display.o \
intel_crt.o \
intel_lvds.o \
+ intel_dsi.o \
intel_dsi_cmd.o \
intel_bios.o \
intel_ddi.o \
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a31abc6..cbe3df1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -525,6 +525,7 @@ extern void intel_mark_fb_busy(struct drm_i915_gem_object
*obj,
struct intel_ring_buffer *ring);
extern void intel_mark_idle(struct drm_device *dev);
extern void intel_lvds_init(struct drm_device *dev);
+extern bool intel_dsi_init(struct drm_device *dev);
extern bool intel_is_dual_link_lvds(struct drm_device *dev);
extern void intel_dp_init(struct drm_device *dev, int output_reg,
enum port port);
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
new file mode 100644
index 000..aa81dd8
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -0,0 +1,548 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Author: Jani Nikula jani.nik...@intel.com
+ */
+
+#include drm/drmP.h
+#include drm/drm_crtc.h
+#include drm/drm_edid.h
+#include drm/i915_drm.h
+#include linux/slab.h
+#include i915_drv.h
+#include intel_drv.h
+#include intel_dsi.h
+#include intel_dsi_cmd.h
+
+/* the sub-encoders aka panel drivers */
+static const struct intel_dsi_device intel_dsi_devices[] = {
+};
+
+static struct intel_dsi *intel_attached_dsi(struct drm_connector *connector)
+{
+ return container_of(intel_attached_encoder(connector),
+ struct intel_dsi, base);
+}
+
+static inline bool is_vid_mode(struct intel_dsi *intel_dsi)
+{
+ return intel_dsi-dev.type == INTEL_DSI_VIDEO_MODE;
+}
+
+static inline bool is_cmd_mode(struct intel_dsi *intel_dsi)
+{
+ return intel_dsi-dev.type == INTEL_DSI_COMMAND_MODE;
+}
+
+static void intel_dsi_hot_plug(struct intel_encoder *encoder)
+{
+ DRM_DEBUG_KMS(\n);
+}
+
+static bool intel_dsi_compute_config(struct intel_encoder *encoder,
+struct intel_crtc_config *config)
+{
+ DRM_DEBUG_KMS(\n);
+ return true;
+}
+
+static void intel_dsi_pre_pll_enable(struct intel_encoder *encoder)
+{
+ DRM_DEBUG_KMS(\n);
+}
+
+static void intel_dsi_pre_enable(struct intel_encoder *encoder)
+{
+ DRM_DEBUG_KMS(\n);
+}
+
+static void intel_dsi_enable(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(encoder-base.crtc);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
+ int pipe = intel_crtc-pipe;
+ u32 temp;
+
+ DRM_DEBUG_KMS(\n);
+
+ temp = I915_READ(MIPI_DEVICE_READY(pipe));
+ temp = ~ULPS_STATE_MASK;
+ temp = ~DEVICE_READY; /* XXX: assuming it's already !ready */
+ I915_WRITE(MIPI_DEVICE_READY(pipe), temp | ULPS_STATE_EXIT);
+ msleep(20); /* XXX */
+ I915_WRITE(MIPI_DEVICE_READY(pipe), temp);
+ msleep(20); /* XXX */
+ I915_WRITE(MIPI_DEVICE_READY(pipe), temp | DEVICE_READY);
+
+ if
[Intel-gfx] [PATCH 09/14] drm/i915: add VLV DSI PLL Calculations
From: ymohanma yogesh.mohan.marimu...@intel.com
Signed-off-by: ymohanma yogesh.mohan.marimu...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_reg.h | 10 ++
drivers/gpu/drm/i915/intel_display.c |2 +
drivers/gpu/drm/i915/intel_dsi.c |5 +
drivers/gpu/drm/i915/intel_dsi.h |2 +
drivers/gpu/drm/i915/intel_dsi_pll.c | 290 ++
6 files changed, 310 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_dsi_pll.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5864c5b..65e60d2 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -23,6 +23,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
intel_lvds.o \
intel_dsi.o \
intel_dsi_cmd.o \
+ intel_dsi_pll.o \
intel_bios.o \
intel_ddi.o \
intel_dp.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 32e32b6..5713540 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -390,6 +390,16 @@
#define FB_FMAX_VMIN_FREQ_LO_SHIFT 27
#define FB_FMAX_VMIN_FREQ_LO_MASK0xf800
+/* vlv2 north clock has */
+#define CCK_REG_DSI_PLL_FUSE 0x44
+#define CCK_REG_DSI_PLL_CONTROL0x48
+#define DSI_PLL_VCO_EN(1 31)
+#define DSI_PLL_LDO_GATE (1 30)
+#define DSI_PLL_P1_POST_DIV_SHIFT 17
+#define DSI_PLL_P1_POST_DIV_MASK (0x1ff 17)
+#define DSI_PLL_LOCK (1 0)
+#define CCK_REG_DSI_PLL_DIVIDER0x4c
+
/*
* DPIO - a special bus for various display related registers to hide behind
*
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cec9189..78c42a1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1683,6 +1683,7 @@ static void intel_enable_pipe(struct drm_i915_private
*dev_priv, enum pipe pipe,
* need the check.
*/
if (!HAS_PCH_SPLIT(dev_priv-dev))
+ /* XXX: Fix for DSI PLL */
assert_pll_enabled(dev_priv, pipe);
else {
if (pch_port) {
@@ -6495,6 +6496,7 @@ void intel_crtc_load_lut(struct drm_crtc *crtc)
return;
if (!HAS_PCH_SPLIT(dev_priv-dev))
+ /* XXX: Fix for DSI PLL */
assert_pll_enabled(dev_priv, pipe);
/* use legacy palette for Ironlake */
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index aa81dd8..1dc5a77 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -68,6 +68,8 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
static void intel_dsi_pre_pll_enable(struct intel_encoder *encoder)
{
DRM_DEBUG_KMS(\n);
+
+ vlv_enable_dsi_pll(encoder);
}
static void intel_dsi_pre_enable(struct intel_encoder *encoder)
@@ -294,6 +296,9 @@ static void intel_dsi_mode_set(struct intel_encoder
*intel_encoder)
DRM_DEBUG_KMS(pipe %d\n, pipe);
+ /* Update the DSI PLL */
+ vlv_enable_dsi_pll(intel_encoder);
+
/* escape clock divider, 20MHz, shared for A and C. device ready must be
* off when doing this! txclkesc? */
tmp = I915_READ(MIPI_CTRL(0));
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 45f649a..0e0a212 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -96,4 +96,6 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
drm_encoder *encoder)
return container_of(encoder, struct intel_dsi, base.base);
}
+extern void vlv_enable_dsi_pll(struct intel_encoder *encoder);
+
#endif /* _INTEL_DSI_H */
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
new file mode 100644
index 000..12ede64
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -0,0 +1,290 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT
[Intel-gfx] [PATCH 10/14] drm/i915: don't enable DPLL for DSI
DPLL is not needed for DSI
Signed-off-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 48 --
1 file changed, 29 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 78c42a1..e3ca335 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3660,7 +3660,8 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
if (encoder-pre_pll_enable)
encoder-pre_pll_enable(encoder);
- vlv_enable_pll(intel_crtc);
+ if (!intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
+ vlv_enable_pll(intel_crtc);
for_each_encoder_on_crtc(dev, crtc, encoder)
if (encoder-pre_enable)
@@ -3775,7 +3776,8 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
if (encoder-post_disable)
encoder-post_disable(encoder);
- i9xx_disable_pll(dev_priv, pipe);
+ if (!intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
+ i9xx_disable_pll(dev_priv, pipe);
intel_crtc-active = false;
intel_update_fbc(dev);
@@ -4843,7 +4845,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
intel_clock_t clock, reduced_clock;
u32 dspcntr;
bool ok, has_reduced_clock = false;
- bool is_lvds = false;
+ bool is_lvds = false, is_dsi = false;
struct intel_encoder *encoder;
const intel_limit_t *limit;
int ret;
@@ -4853,6 +4855,9 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
case INTEL_OUTPUT_LVDS:
is_lvds = true;
break;
+ case INTEL_OUTPUT_DSI:
+ is_dsi = true;
+ break;
}
num_connectors++;
@@ -4860,18 +4865,21 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
refclk = i9xx_get_refclk(crtc, num_connectors);
- /*
-* Returns a set of divisors for the desired target clock with the given
-* refclk, or FALSE. The returned values represent the clock equation:
-* reflck * (5 * (m1 + 2) + (m2 + 2)) / (n + 2) / p1 / p2.
-*/
- limit = intel_limit(crtc, refclk);
- ok = dev_priv-display.find_dpll(limit, crtc,
-intel_crtc-config.port_clock,
-refclk, NULL, clock);
- if (!ok !intel_crtc-config.clock_set) {
- DRM_ERROR(Couldn't find PLL settings for mode!\n);
- return -EINVAL;
+ if (!is_dsi) {
+ /*
+* Returns a set of divisors for the desired target clock with
+* the given refclk, or FALSE. The returned values represent
+* the clock equation: reflck * (5 * (m1 + 2) + (m2 + 2)) / (n +
+* 2) / p1 / p2.
+*/
+ limit = intel_limit(crtc, refclk);
+ ok = dev_priv-display.find_dpll(limit, crtc,
+intel_crtc-config.port_clock,
+refclk, NULL, clock);
+ if (!ok !intel_crtc-config.clock_set) {
+ DRM_ERROR(Couldn't find PLL settings for mode!\n);
+ return -EINVAL;
+ }
}
/* Ensure that the cursor is valid for the new mode before changing...
*/
@@ -4899,16 +4907,18 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
intel_crtc-config.dpll.p2 = clock.p2;
}
- if (IS_GEN2(dev))
+ if (IS_GEN2(dev)) {
i8xx_update_pll(intel_crtc,
has_reduced_clock ? reduced_clock : NULL,
num_connectors);
- else if (IS_VALLEYVIEW(dev))
- vlv_update_pll(intel_crtc);
- else
+ } else if (IS_VALLEYVIEW(dev)) {
+ if (!is_dsi)
+ vlv_update_pll(intel_crtc);
+ } else {
i9xx_update_pll(intel_crtc,
has_reduced_clock ? reduced_clock : NULL,
num_connectors);
+ }
/* Set up the display plane register */
dspcntr = DISPPLANE_GAMMA_ENABLE;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/14] drm/i915: Band Gap WA
From: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: ymohanma yogesh.mohan.marimu...@intel.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dsi.c | 48 ++
1 file changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 1dc5a77..d28be01 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -37,6 +37,51 @@
static const struct intel_dsi_device intel_dsi_devices[] = {
};
+
+static void vlv_cck_modify(struct drm_i915_private *dev_priv, u32 reg, u32 val,
+ u32 mask)
+{
+ u32 tmp = vlv_cck_read(dev_priv, reg);
+ tmp = ~mask;
+ tmp |= val;
+ vlv_cck_write(dev_priv, reg, tmp);
+}
+
+static void band_gap_wa(struct drm_i915_private *dev_priv)
+{
+ mutex_lock(dev_priv-dpio_lock);
+
+ /* Enable bandgap fix in GOP driver */
+ vlv_cck_modify(dev_priv, 0x6D, 0x0001, 0x0003);
+ msleep(20);
+ vlv_cck_modify(dev_priv, 0x6E, 0x0001, 0x0003);
+ msleep(20);
+ vlv_cck_modify(dev_priv, 0x6F, 0x0001, 0x0003);
+ msleep(20);
+ vlv_cck_modify(dev_priv, 0x00, 0x8000, 0x8000);
+ msleep(20);
+ vlv_cck_modify(dev_priv, 0x00, 0x, 0x8000);
+ msleep(20);
+
+ /* Turn Display Trunk on */
+ vlv_cck_modify(dev_priv, 0x6B, 0x0002, 0x0003);
+ msleep(20);
+
+ vlv_cck_modify(dev_priv, 0x6C, 0x0002, 0x0003);
+ msleep(20);
+
+ vlv_cck_modify(dev_priv, 0x6D, 0x0002, 0x0003);
+ msleep(20);
+ vlv_cck_modify(dev_priv, 0x6E, 0x0002, 0x0003);
+ msleep(20);
+ vlv_cck_modify(dev_priv, 0x6F, 0x0002, 0x0003);
+
+ mutex_unlock(dev_priv-dpio_lock);
+
+ /* Need huge delay, otherwise clock is not stable */
+ msleep(100);
+}
+
static struct intel_dsi *intel_attached_dsi(struct drm_connector *connector)
{
return container_of(intel_attached_encoder(connector),
@@ -299,6 +344,9 @@ static void intel_dsi_mode_set(struct intel_encoder
*intel_encoder)
/* Update the DSI PLL */
vlv_enable_dsi_pll(intel_encoder);
+ /* XXX: Location of the call */
+ band_gap_wa(dev_priv);
+
/* escape clock divider, 20MHz, shared for A and C. device ready must be
* off when doing this! txclkesc? */
tmp = I915_READ(MIPI_CTRL(0));
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/14] drm/i915: Parse the MIPI related VBT Block and store relevant info
From: Shobhit Kumar shobhit.ku...@intel.com
Initial parsing of the VBT MIPI block. For now, just store the panel id
if found.
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |5 +
drivers/gpu/drm/i915/intel_bios.c | 16 +++
drivers/gpu/drm/i915/intel_bios.h | 41 +
3 files changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6db95a2..5be251b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1053,6 +1053,11 @@ struct intel_vbt_data {
int edp_bpp;
struct edp_power_seq edp_pps;
+ /* MIPI DSI */
+ struct {
+ u16 panel_id;
+ } dsi;
+
int crt_ddc_pin;
int child_dev_num;
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 53f2bed..6668873 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -569,6 +569,21 @@ parse_edp(struct drm_i915_private *dev_priv, struct
bdb_header *bdb)
}
static void
+parse_mipi(struct drm_i915_private *dev_priv, struct bdb_header *bdb)
+{
+ struct bdb_mipi *mipi;
+
+ mipi = find_section(bdb, BDB_MIPI);
+ if (!mipi) {
+ DRM_DEBUG_KMS(No MIPI BDB found);
+ return;
+ }
+
+ /* XXX: add more info */
+ dev_priv-vbt.dsi.panel_id = mipi-panel_id;
+}
+
+static void
parse_device_mapping(struct drm_i915_private *dev_priv,
struct bdb_header *bdb)
{
@@ -745,6 +760,7 @@ intel_parse_bios(struct drm_device *dev)
parse_device_mapping(dev_priv, bdb);
parse_driver_features(dev_priv, bdb);
parse_edp(dev_priv, bdb);
+ parse_mipi(dev_priv, bdb);
if (bios)
pci_unmap_rom(pdev, bios);
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index e088d6f..6e9250e 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -104,6 +104,7 @@ struct vbios_data {
#define BDB_LVDS_LFP_DATA 42
#define BDB_LVDS_BACKLIGHT 43
#define BDB_LVDS_POWER 44
+#define BDB_MIPI50
#define BDB_SKIP 254 /* VBIOS private block, ignore */
struct bdb_general_features {
@@ -618,4 +619,44 @@ int intel_parse_bios(struct drm_device *dev);
#definePORT_IDPC 8
#definePORT_IDPD 9
+/* MIPI DSI panel info */
+struct bdb_mipi {
+ u16 panel_id;
+ u16 bridge_revision;
+
+ /* General params */
+ u32 dithering:1;
+ u32 bpp_pixel_format:1;
+ u32 rsvd1:1;
+ u32 dphy_valid:1;
+ u32 resvd2:28;
+
+ u16 port_info;
+ u16 rsvd3:2;
+ u16 num_lanes:2;
+ u16 rsvd4:12;
+
+ /* DSI config */
+ u16 virt_ch_num:2;
+ u16 vtm:2;
+ u16 rsvd5:12;
+
+ u32 dsi_clock;
+ u32 bridge_ref_clk;
+ u16 rsvd_pwr;
+
+ /* Dphy Params */
+ u32 prepare_cnt:5;
+ u32 rsvd6:3;
+ u32 clk_zero_cnt:8;
+ u32 trail_cnt:5;
+ u32 rsvd7:3;
+ u32 exit_zero_cnt:6;
+ u32 rsvd8:2;
+
+ u32 hl_switch_cnt;
+ u32 lp_byte_clk;
+ u32 clk_lane_switch_cnt;
+} __attribute__((packed));
+
#endif /* _I830_BIOS_H_ */
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/14] drm/i915: add AUO MIPI DSI display sub-encoder
From: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/auo_dsi_display.c | 182
drivers/gpu/drm/i915/intel_dsi.c |5 +
drivers/gpu/drm/i915/intel_dsi.h |3 +
4 files changed, 191 insertions(+)
create mode 100644 drivers/gpu/drm/i915/auo_dsi_display.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 65e60d2..18bf236 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -42,6 +42,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
intel_opregion.o \
intel_sideband.o \
intel_uncore.o \
+ auo_dsi_display.o \
dvo_ch7xxx.o \
dvo_ch7017.o \
dvo_ivch.o \
diff --git a/drivers/gpu/drm/i915/auo_dsi_display.c
b/drivers/gpu/drm/i915/auo_dsi_display.c
new file mode 100644
index 000..771a725
--- /dev/null
+++ b/drivers/gpu/drm/i915/auo_dsi_display.c
@@ -0,0 +1,182 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Author: Jani Nikula jani.nik...@intel.com
+ *Shobhit Kumar shobhit.ku...@intel.com
+ */
+
+#include drm/drmP.h
+#include drm/drm_crtc.h
+#include drm/drm_edid.h
+#include drm/i915_drm.h
+#include linux/slab.h
+#include video/mipi_display.h
+#include i915_drv.h
+#include intel_drv.h
+#include intel_dsi.h
+#include intel_dsi_cmd.h
+
+#if 0 /* XXX */
+static void auo_vid_get_panel_info(int pipe, struct drm_connector *connector)
+{
+ DRM_DEBUG_KMS(\n);
+ if (!connector)
+ return;
+
+ if (pipe == 0) {
+ connector-display_info.width_mm = 216;
+ connector-display_info.height_mm = 135;
+ }
+
+ return;
+}
+#endif
+
+static bool auo_init(struct intel_dsi_device *dsi)
+{
+ struct intel_dsi *intel_dsi = container_of(dsi, struct intel_dsi, dev);
+
+ DRM_DEBUG_KMS(\n);
+
+ intel_dsi-eot_disable = 0;
+ intel_dsi-pixel_format = VID_MODE_FORMAT_RGB888;
+ intel_dsi-video_mode_format = VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE;
+ intel_dsi-lane_count = 4;
+
+ return true;
+}
+
+static void auo_enable(struct intel_dsi_device *dsi)
+{
+ struct intel_dsi *intel_dsi = container_of(dsi, struct intel_dsi, dev);
+
+ DRM_DEBUG_KMS(\n);
+
+ dsi_vc_dcs_write_0(intel_dsi, 0, MIPI_DCS_EXIT_SLEEP_MODE);
+
+ dsi_vc_dcs_write_1(intel_dsi, 0, MIPI_DCS_SET_TEAR_ON, 0x00);
+
+ dsi_vc_dcs_write_0(intel_dsi, 0, MIPI_DCS_SET_DISPLAY_ON);
+ dsi_vc_dcs_write_1(intel_dsi, 0, 0x14, 0x55);
+}
+
+static void auo_disable(struct intel_dsi_device *dsi)
+{
+ struct intel_dsi *intel_dsi = container_of(dsi, struct intel_dsi, dev);
+
+ DRM_DEBUG_KMS(\n);
+
+ dsi_vc_dcs_write_0(intel_dsi, 0, MIPI_DCS_SET_DISPLAY_OFF);
+ dsi_vc_dcs_write_0(intel_dsi, 0, MIPI_DCS_ENTER_SLEEP_MODE);
+}
+
+static int auo_mode_valid(struct intel_dsi_device *dsi,
+ struct drm_display_mode *mode)
+{
+ return MODE_OK;
+}
+
+static bool auo_mode_fixup(struct intel_dsi_device *dsi,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ return true;
+}
+
+static void auo_mode_set(struct intel_dsi_device *dsi,
+struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode)
+{
+}
+
+static enum drm_connector_status auo_detect(struct intel_dsi_device *dsi)
+{
+ return connector_status_connected;
+}
+
+static bool auo_get_hw_state(struct intel_dsi_device *dev)
+{
+ return true;
+}
+
+static struct drm_display_mode *auo_get_modes(struct intel_dsi_device *dsi)
+{
+ struct
[Intel-gfx] [PATCH 13/14] drm/i915: initialize DSI output on VLV
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e3ca335..7edb9c0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9357,6 +9357,8 @@ static void intel_setup_outputs(struct drm_device *dev)
if (I915_READ(VLV_DISPLAY_BASE + DP_B) DP_DETECTED)
intel_dp_init(dev, VLV_DISPLAY_BASE + DP_B,
PORT_B);
}
+
+ intel_dsi_init(dev);
} else if (SUPPORTS_DIGITAL_OUTPUTS(dev)) {
bool found = false;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix __wait_seqno to use true infinite timeouts
applied to experimental drm-intel-collector.
drivers/gpu/drm/i915/i915_gem.c: In function ‘__wait_seqno’:
drivers/gpu/drm/i915/i915_gem.c:1033:20: warning: ‘timeout_jiffies’ may be used
+uninitialized in this function
On Tue, Aug 6, 2013 at 10:03 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
Rather than continue to fix up the timeouts to work around the interface
impedence in wait_event_*(), open code the combination of
wait_event[_interruptible][_timeout]. And note the code size reduction,
and dare say readability?, in doing so..
Food for thought.
---
drivers/gpu/drm/i915/i915_gem.c | 82
-
1 file changed, 39 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 99ba622..8adbce9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1088,23 +1088,18 @@ static int __wait_seqno(struct intel_ring_buffer
*ring, u32 seqno,
bool interruptible, struct timespec *timeout)
{
drm_i915_private_t *dev_priv = ring-dev-dev_private;
- struct timespec before, now, wait_time={1,0};
- unsigned long timeout_jiffies;
- long end;
- bool wait_forever = true;
+ struct timespec before, now;
+ DEFINE_WAIT(__wait);
+ long timeout_jiffies;
int ret;
if (i915_seqno_passed(ring-get_seqno(ring, true), seqno))
return 0;
- trace_i915_gem_request_wait_begin(ring, seqno);
-
- if (timeout != NULL) {
- wait_time = *timeout;
- wait_forever = false;
- }
+ if (timeout)
+ timeout_jiffies = timespec_to_jiffies_timeout(timeout);
- timeout_jiffies = timespec_to_jiffies_timeout(wait_time);
+ trace_i915_gem_request_wait_begin(ring, seqno);
if (WARN_ON(!ring-irq_get(ring)))
return -ENODEV;
@@ -1112,36 +1107,47 @@ static int __wait_seqno(struct intel_ring_buffer
*ring, u32 seqno,
/* Record current time in case interrupted by signal, or wedged * */
getrawmonotonic(before);
-#define EXIT_COND \
- (i915_seqno_passed(ring-get_seqno(ring, false), seqno) || \
-i915_reset_in_progress(dev_priv-gpu_error) || \
-reset_counter != atomic_read(dev_priv-gpu_error.reset_counter))
- do {
- if (interruptible)
- end =
wait_event_interruptible_timeout(ring-irq_queue,
- EXIT_COND,
-
timeout_jiffies);
- else
- end = wait_event_timeout(ring-irq_queue, EXIT_COND,
-timeout_jiffies);
+ for (;;) {
+ prepare_to_wait(ring-irq_queue, __wait,
+ interruptible ? TASK_INTERRUPTIBLE :
TASK_UNINTERRUPTIBLE);
/* We need to check whether any gpu reset happened in between
* the caller grabbing the seqno and now ... */
- if (reset_counter !=
atomic_read(dev_priv-gpu_error.reset_counter))
- end = -EAGAIN;
+ if (reset_counter !=
atomic_read(dev_priv-gpu_error.reset_counter)) {
+ /* ... but upgrade the -EGAIN to an -EIO if the gpu
+* is truely gone. */
+ ret = i915_gem_check_wedge(dev_priv-gpu_error,
interruptible);
+ if (ret == 0)
+ ret = -EAGAIN;
+ break;
+ }
- /* ... but upgrade the -EGAIN to an -EIO if the gpu is truely
-* gone. */
- ret = i915_gem_check_wedge(dev_priv-gpu_error,
interruptible);
- if (ret)
- end = ret;
- } while (end == 0 wait_forever);
+ if (i915_seqno_passed(ring-get_seqno(ring, false), seqno)) {
+ ret = 0;
+ break;
+ }
+
+ if (interruptible signal_pending(current)) {
+ ret = -ERESTARTSYS;
+ break;
+ }
+
+ if (timeout) {
+ if (timeout_jiffies == 0) {
+ ret = -ETIME;
+ break;
+ }
+
+ timeout_jiffies = schedule_timeout(timeout_jiffies);
+ } else
+ schedule();
+ }
+ finish_wait(ring-irq_queue, __wait);
getrawmonotonic(now);
ring-irq_put(ring);
trace_i915_gem_request_wait_end(ring, seqno);
-#undef EXIT_COND
if (timeout) {
struct timespec sleep_time = timespec_sub(now, before);
Re: [Intel-gfx] [PATCH] drm/i915: Fix __wait_seqno to use true infinite timeouts
On Tue, Aug 13, 2013 at 10:36:04AM -0300, Rodrigo Vivi wrote: applied to experimental drm-intel-collector. drivers/gpu/drm/i915/i915_gem.c: In function ‘__wait_seqno’: drivers/gpu/drm/i915/i915_gem.c:1033:20: warning: ‘timeout_jiffies’ may be used +uninitialized in this function Dumb gcc. Note the lack of sign-off. Ben would hate this patch since it may unmask simulator bugs. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix __wait_seqno to use true infinite timeouts
On Tue, Aug 13, 2013 at 02:39:55PM +0100, Chris Wilson wrote: On Tue, Aug 13, 2013 at 10:36:04AM -0300, Rodrigo Vivi wrote: applied to experimental drm-intel-collector. drivers/gpu/drm/i915/i915_gem.c: In function ‘__wait_seqno’: drivers/gpu/drm/i915/i915_gem.c:1033:20: warning: ‘timeout_jiffies’ may be used +uninitialized in this function Dumb gcc. Note the lack of sign-off. Ben would hate this patch since it may unmask simulator bugs. Hm, I'd prefer it with sob line since I very much want to again have good reporting on missed interrupts (instead of silently papering over them). If the simulator is broken we need to apply special duct-tape for it (maybe in the form of a timer that regularly checks the seqno), since 1s delay is simply too slow, even for simulators. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk 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) - Sedat - Xorg.0.log Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk 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). - Sedat - - Sedat - ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch :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 ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) commit 5456fe3882812aba251886e36fe55bfefb8e8829 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Aug 8 14:41:07
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 4:45 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 4:07 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:57 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 11:52 AM, Chris Wilson ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch :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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 06:23:29PM +0200, Sedat Dilek wrote: On Tue, Aug 13, 2013 at 5:59 PM, Sedat Dilek sedat.di...@gmail.com 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 ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch :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. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson ch...@chris-wilson.co.uk 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 sedat.di...@gmail.com 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 ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch :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 - ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson ch...@chris-wilson.co.uk 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 sedat.di...@gmail.com 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 ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch :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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 07:03:44PM +0200, Sedat Dilek wrote: On Tue, Aug 13, 2013 at 6:37 PM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson ch...@chris-wilson.co.uk 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 sedat.di...@gmail.com 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 ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch :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 -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: print a message when we detect an early Haswell SDV
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Mon, Aug 12, 2013 at 2:34 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The machines that fall in this category are the SDVs that have a PCI
ID starting with 0x0C. These are very early pre-production machines
and may not fully work. Other Haswell SDVs have PCI IDs that match the
real Haswell machines and we expect them to work better.
Even though they have problems, they still mostly work so I don't see
a reason to refuse loading our driver. But I do see a reason to reject
bug reports from these machines, so the message should help the bug
triagers.
As far as I know, we don't implement some workarounds that are
specific to these machines and suspend/resume may not work on most of
them, but besides this, they may work.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61508
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 8
drivers/gpu/drm/i915/i915_drv.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 0adfe40..908442e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1485,6 +1485,14 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
i915_dump_device_info(dev_priv);
+ /* Not all pre-production machines fall into this category, only the
+* very first ones. Almost everything should work, except for maybe
+* suspend/resume. And we don't implement workarounds that affect only
+* pre-production machines. */
+ if (IS_HSW_EARLY_SDV(dev))
+ DRM_INFO(This is an early pre-production Haswell machine.
+It may not be fully functional.\n);
+
if (i915_get_bridge_dev(dev)) {
ret = -EIO;
goto free_priv;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cccd608..3f1f067 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1510,6 +1510,8 @@ struct drm_i915_file_private {
#define IS_VALLEYVIEW(dev) (INTEL_INFO(dev)-is_valleyview)
#define IS_HASWELL(dev)(INTEL_INFO(dev)-is_haswell)
#define IS_MOBILE(dev) (INTEL_INFO(dev)-is_mobile)
+#define IS_HSW_EARLY_SDV(dev) (IS_HASWELL(dev) \
+((dev)-pci_device 0xFF00) == 0x0C00)
#define IS_ULT(dev)(IS_HASWELL(dev) \
((dev)-pci_device 0xFF00) == 0x0A00)
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Print the changes required for modeset
After computing the stage changes for the set_config, record those in the debug log. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- drivers/gpu/drm/i915/intel_display.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index a21f935..4f9c3d8 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8884,6 +8884,9 @@ intel_set_config_compute_mode_changes(struct drm_mode_set *set, drm_mode_debug_printmodeline(set-mode); config-mode_changed = true; } + + DRM_DEBUG_KMS(computed changes for [CRTC:%d], mode_changed=%d, fb_changed=%d\n, + set-crtc-base.id, config-mode_changed, config-fb_changed); } static int -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Force a full modeset if the requested CRTC is disconnected
If the CRTC for this modeset is not attached to any encoder, it will be
off. In this case, we will need to turn it on as well as update its
base. This requires a full modeset sequence.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f9c3d8..30bd919 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8836,9 +8836,8 @@ is_crtc_connector_off(struct drm_mode_set *set)
for (i = 0; i set-num_connectors; i++)
if (set-connectors[i]-encoder
- set-connectors[i]-encoder-crtc == set-crtc
- set-connectors[i]-dpms != DRM_MODE_DPMS_ON)
- return true;
+ set-connectors[i]-encoder-crtc == set-crtc)
+ return set-connectors[i]-dpms != DRM_MODE_DPMS_ON;
return false;
}
@@ -8853,11 +8852,10 @@ intel_set_config_compute_mode_changes(struct
drm_mode_set *set,
if (is_crtc_connector_off(set)) {
config-mode_changed = true;
} else if (set-crtc-fb != set-fb) {
- /* If we have no fb then treat it as a full mode set */
- if (set-crtc-fb == NULL) {
- struct intel_crtc *intel_crtc =
- to_intel_crtc(set-crtc);
+ struct intel_crtc *intel_crtc = to_intel_crtc(set-crtc);
+ /* If we have no fb (or off) then treat it as a full mode set */
+ if (set-crtc-fb == NULL) {
if (intel_crtc-active i915_fastboot) {
DRM_DEBUG_KMS(crtc has no fb, will flip\n);
config-fb_changed = true;
@@ -8870,6 +8868,8 @@ intel_set_config_compute_mode_changes(struct drm_mode_set
*set,
} else if (set-fb-pixel_format !=
set-crtc-fb-pixel_format) {
config-mode_changed = true;
+ } else if (!intel_crtc-active) {
+ config-mode_changed = true;
} else {
config-fb_changed = true;
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Print the changes required for modeset
2013/8/13 Chris Wilson ch...@chris-wilson.co.uk: After computing the stage changes for the set_config, record those in the debug log. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk I've already written different versions of this patch when debugging things in the past. Definitely useful. Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/intel_display.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index a21f935..4f9c3d8 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8884,6 +8884,9 @@ intel_set_config_compute_mode_changes(struct drm_mode_set *set, drm_mode_debug_printmodeline(set-mode); config-mode_changed = true; } + + DRM_DEBUG_KMS(computed changes for [CRTC:%d], mode_changed=%d, fb_changed=%d\n, + set-crtc-base.id, config-mode_changed, config-fb_changed); } static int -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
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? Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 7:13 PM, Chris Wilson ch...@chris-wilson.co.uk 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 sedat.di...@gmail.com wrote: On Tue, Aug 13, 2013 at 6:34 PM, Chris Wilson ch...@chris-wilson.co.uk 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 sedat.di...@gmail.com 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 ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch :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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Print the changes required for modeset
On Tue, Aug 13, 2013 at 03:00:59PM -0300, Paulo Zanoni wrote: 2013/8/13 Chris Wilson ch...@chris-wilson.co.uk: After computing the stage changes for the set_config, record those in the debug log. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk I've already written different versions of this patch when debugging things in the past. Definitely useful. Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: print a message when we detect an early Haswell SDV
On Tue, Aug 13, 2013 at 02:41:15PM -0300, Rodrigo Vivi wrote: Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com On Mon, Aug 12, 2013 at 2:34 PM, Paulo Zanoni przan...@gmail.com wrote: From: Paulo Zanoni paulo.r.zan...@intel.com The machines that fall in this category are the SDVs that have a PCI ID starting with 0x0C. These are very early pre-production machines and may not fully work. Other Haswell SDVs have PCI IDs that match the real Haswell machines and we expect them to work better. Even though they have problems, they still mostly work so I don't see a reason to refuse loading our driver. But I do see a reason to reject bug reports from these machines, so the message should help the bug triagers. As far as I know, we don't implement some workarounds that are specific to these machines and suspend/resume may not work on most of them, but besides this, they may work. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61508 Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 08:40:37PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 8:01 PM, Chris Wilson ch...@chris-wilson.co.uk
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;
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: tune the RC6 threshold for stability
It's basically the same deal as the RC6+ issues on ivy bridge except this time with RC6 on sandy bridge. Like last time the core of the issue is that the timings don't work 100% with our voltage regulator. So from time to time, the kernel will print a warning message about the GPU not getting out of RC6. In particular, I found this fairly easy to reproduce during suspend/resume. Changing the threshold to 125000 instead of 5 seems to fix the issue. The previous patch used 15 but as it turns out this doesn't work everywhere. After getting such a machine, I bisected the highest value which works, which is 125000, so here it is. I also measured the idle power usage before/after this patch and didn't see a difference on a sandy bridge laptop. On haswell and up, it makes a big difference, so we want to keep it at 50k there. It also seems like haswell doesn't have the RC6 issues that sandy bridge has so the 50k value is fine. Signed-off-by: Stéphane Marchesin marc...@chromium.org --- drivers/gpu/drm/i915/intel_pm.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 51a2a60..71839f8 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3250,7 +3250,10 @@ static void gen6_enable_rps(struct drm_device *dev) I915_WRITE(GEN6_RC_SLEEP, 0); I915_WRITE(GEN6_RC1e_THRESHOLD, 1000); - I915_WRITE(GEN6_RC6_THRESHOLD, 5); + if (INTEL_INFO(dev)-gen = 6 || IS_IVYBRIDGE(dev)) + I915_WRITE(GEN6_RC6_THRESHOLD, 125000); + else + I915_WRITE(GEN6_RC6_THRESHOLD, 5); I915_WRITE(GEN6_RC6p_THRESHOLD, 15); I915_WRITE(GEN6_RC6pp_THRESHOLD, 64000); /* unused */ -- 1.8.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk
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 -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 09:05:41PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 8:53 PM, Chris Wilson ch...@chris-wilson.co.uk
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 ch...@chris-wilson.co.uk
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.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 10:16:10PM +0200, Sedat Dilek wrote:
On Tue, Aug 13, 2013 at 10:10 PM, Chris Wilson ch...@chris-wilson.co.uk
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 ch...@chris-wilson.co.uk
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
ch...@chris-wilson.co.uk 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 ;-)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Force a full modeset if the requested CRTC is disconnected
On Tue, Aug 13, 2013 at 06:59:34PM +0100, Chris Wilson wrote:
If the CRTC for this modeset is not attached to any encoder, it will be
off. In this case, we will need to turn it on as well as update its
base. This requires a full modeset sequence.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f9c3d8..30bd919 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8836,9 +8836,8 @@ is_crtc_connector_off(struct drm_mode_set *set)
for (i = 0; i set-num_connectors; i++)
if (set-connectors[i]-encoder
- set-connectors[i]-encoder-crtc == set-crtc
- set-connectors[i]-dpms != DRM_MODE_DPMS_ON)
- return true;
+ set-connectors[i]-encoder-crtc == set-crtc)
+ return set-connectors[i]-dpms != DRM_MODE_DPMS_ON;
return false;
}
@@ -8853,11 +8852,10 @@ intel_set_config_compute_mode_changes(struct
drm_mode_set *set,
if (is_crtc_connector_off(set)) {
config-mode_changed = true;
} else if (set-crtc-fb != set-fb) {
- /* If we have no fb then treat it as a full mode set */
- if (set-crtc-fb == NULL) {
- struct intel_crtc *intel_crtc =
- to_intel_crtc(set-crtc);
+ struct intel_crtc *intel_crtc = to_intel_crtc(set-crtc);
+ /* If we have no fb (or off) then treat it as a full mode set */
+ if (set-crtc-fb == NULL) {
if (intel_crtc-active i915_fastboot) {
DRM_DEBUG_KMS(crtc has no fb, will flip\n);
config-fb_changed = true;
@@ -8870,6 +8868,8 @@ intel_set_config_compute_mode_changes(struct
drm_mode_set *set,
} else if (set-fb-pixel_format !=
set-crtc-fb-pixel_format) {
config-mode_changed = true;
+ } else if (!intel_crtc-active) {
+ config-mode_changed = true;
This hunk here /should/ be redundant, at least if we don't botch up the
connector iteration above. Also can you please pimp the commit message a
bit to trace the epic multi-chapter train wreak this has become?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Force a full modeset if the requested CRTC is disconnected
On Tue, Aug 13, 2013 at 10:32:19PM +0200, Daniel Vetter wrote:
On Tue, Aug 13, 2013 at 06:59:34PM +0100, Chris Wilson wrote:
If the CRTC for this modeset is not attached to any encoder, it will be
off. In this case, we will need to turn it on as well as update its
base. This requires a full modeset sequence.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f9c3d8..30bd919 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8836,9 +8836,8 @@ is_crtc_connector_off(struct drm_mode_set *set)
for (i = 0; i set-num_connectors; i++)
if (set-connectors[i]-encoder
- set-connectors[i]-encoder-crtc == set-crtc
- set-connectors[i]-dpms != DRM_MODE_DPMS_ON)
- return true;
+ set-connectors[i]-encoder-crtc == set-crtc)
+ return set-connectors[i]-dpms != DRM_MODE_DPMS_ON;
return false;
}
@@ -8853,11 +8852,10 @@ intel_set_config_compute_mode_changes(struct
drm_mode_set *set,
if (is_crtc_connector_off(set)) {
config-mode_changed = true;
} else if (set-crtc-fb != set-fb) {
- /* If we have no fb then treat it as a full mode set */
- if (set-crtc-fb == NULL) {
- struct intel_crtc *intel_crtc =
- to_intel_crtc(set-crtc);
+ struct intel_crtc *intel_crtc = to_intel_crtc(set-crtc);
+ /* If we have no fb (or off) then treat it as a full mode set */
+ if (set-crtc-fb == NULL) {
if (intel_crtc-active i915_fastboot) {
DRM_DEBUG_KMS(crtc has no fb, will flip\n);
config-fb_changed = true;
@@ -8870,6 +8868,8 @@ intel_set_config_compute_mode_changes(struct
drm_mode_set *set,
} else if (set-fb-pixel_format !=
set-crtc-fb-pixel_format) {
config-mode_changed = true;
+ } else if (!intel_crtc-active) {
+ config-mode_changed = true;
This hunk here /should/ be redundant, at least if we don't botch up the
connector iteration above. Also can you please pimp the commit message a
bit to trace the epic multi-chapter train wreak this has become?
The connector iteration doesn't quite capture everything, the condition
it misses (the change of encoder-crtc) should be spotted by
intel_modeset_stage_output_state(). This patch shouldn't be doing anything
but terminating the iteration earlier upon finding the crtc match. The
bug is definitely that we skip a mode_changed in favour of a simple
fb_changed on a disabled output.. but where?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: Tree for Aug 13 [ screen corruption in graphical mode ]
On Tue, Aug 13, 2013 at 10:33 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Tue, Aug 13, 2013 at 10:25 PM, Sedat Dilek sedat.di...@gmail.com wrote:
On Tue, Aug 13, 2013 at 10:20 PM, Chris Wilson ch...@chris-wilson.co.uk
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 ch...@chris-wilson.co.uk
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
ch...@chris-wilson.co.uk 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
ch...@chris-wilson.co.uk 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, 8bpc)
HTOTAL_B: 0x (1 active, 1 total)
HBLANK_B: 0x (1 start, 1 end)
HSYNC_B: 0x (1 start, 1 end)
VTOTAL_B: 0x (1 active, 1 total
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Initialize seqno for VECS too
On Mon, Aug 12, 2013 at 04:53:03PM -0700, Ben Widawsky wrote:
Cc: Mika Kuoppala mika.kuopp...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65387
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67198
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 10c2aaa..665602f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1592,6 +1592,8 @@ void intel_ring_init_seqno(struct intel_ring_buffer
*ring, u32 seqno)
if (INTEL_INFO(ring-dev)-gen = 6) {
I915_WRITE(RING_SYNC_0(ring-mmio_base), 0);
I915_WRITE(RING_SYNC_1(ring-mmio_base), 0);
+ if (HAS_VEBOX(ring-dev))
+ I915_WRITE(RING_SYNC_2(ring-mmio_base), 0);
}
ring-set_seqno(ring, seqno);
We require n-1 mailboxes for proper semaphore synchronization. All
semaphore synchronization code relies on proper values in these
mailboxes. The fact that we failed to touch the vebox ring by itself was
unlikely to be an issue since the HW should be initializing the values
to 0. However the error framework for testing seqno wrap introduced by
Mika, in addition to the hangcheck via seqno, and
i915_error_first_batchbuffer() combined caused a nice explosion.
The problem is caused by seqno wrap because the wrap condition is not
properly setup. The wrap code attempts to set the sync mailboxes all to
0, and then set the current seqno to one less than 0. In all cases, the
vebox mailbox wasn't properly being initialized. This caused a wrap to
not occur. When hangcheck kicks in with the bogus seqno values, the rest
just doesn't work. It makes me wonder if we shouldn't consider a dumber
version of hangcheck...
How we messed this up:
VECS support was written before the aforementioned other features. Upon
VECS being rebased, these facts were missed.
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Force a full modeset if the requested CRTC is disconnected
On Tue, Aug 13, 2013 at 10:32:19PM +0200, Daniel Vetter wrote:
On Tue, Aug 13, 2013 at 06:59:34PM +0100, Chris Wilson wrote:
If the CRTC for this modeset is not attached to any encoder, it will be
off. In this case, we will need to turn it on as well as update its
base. This requires a full modeset sequence.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_display.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f9c3d8..30bd919 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8836,9 +8836,8 @@ is_crtc_connector_off(struct drm_mode_set *set)
for (i = 0; i set-num_connectors; i++)
if (set-connectors[i]-encoder
- set-connectors[i]-encoder-crtc == set-crtc
- set-connectors[i]-dpms != DRM_MODE_DPMS_ON)
- return true;
+ set-connectors[i]-encoder-crtc == set-crtc)
+ return set-connectors[i]-dpms != DRM_MODE_DPMS_ON;
return false;
}
@@ -8853,11 +8852,10 @@ intel_set_config_compute_mode_changes(struct
drm_mode_set *set,
if (is_crtc_connector_off(set)) {
config-mode_changed = true;
} else if (set-crtc-fb != set-fb) {
- /* If we have no fb then treat it as a full mode set */
- if (set-crtc-fb == NULL) {
- struct intel_crtc *intel_crtc =
- to_intel_crtc(set-crtc);
+ struct intel_crtc *intel_crtc = to_intel_crtc(set-crtc);
+ /* If we have no fb (or off) then treat it as a full mode set */
+ if (set-crtc-fb == NULL) {
if (intel_crtc-active i915_fastboot) {
DRM_DEBUG_KMS(crtc has no fb, will flip\n);
config-fb_changed = true;
@@ -8870,6 +8868,8 @@ intel_set_config_compute_mode_changes(struct
drm_mode_set *set,
} else if (set-fb-pixel_format !=
set-crtc-fb-pixel_format) {
config-mode_changed = true;
+ } else if (!intel_crtc-active) {
+ config-mode_changed = true;
This hunk here /should/ be redundant, at least if we don't botch up the
connector iteration above. Also can you please pimp the commit message a
bit to trace the epic multi-chapter train wreak this has become?
I'm thinking we want something closer to
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 30bd919..c12a620 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8824,7 +8824,7 @@ static void intel_set_config_restore_state(struct
drm_device *dev,
}
static bool
-is_crtc_connector_off(struct drm_mode_set *set)
+is_connector_off(struct drm_mode_set *set)
{
int i;
@@ -8835,9 +8835,8 @@ is_crtc_connector_off(struct drm_mode_set *set)
return false;
for (i = 0; i set-num_connectors; i++)
- if (set-connectors[i]-encoder
- set-connectors[i]-encoder-crtc == set-crtc)
- return set-connectors[i]-dpms != DRM_MODE_DPMS_ON;
+ if (set-connectors[i]-dpms != DRM_MODE_DPMS_ON)
+ return true;
return false;
}
@@ -8849,11 +8848,13 @@ intel_set_config_compute_mode_changes(struct
drm_mode_set *set,
/* We should be able to check here if the fb has the same properties
* and then just flip_or_move it */
- if (is_crtc_connector_off(set)) {
+ if (is_connector_off(set)) {
config-mode_changed = true;
} else if (set-crtc-fb != set-fb) {
struct intel_crtc *intel_crtc = to_intel_crtc(set-crtc);
+ config-fb_changed = true;
+
/* If we have no fb (or off) then treat it as a full mode set */
if (set-crtc-fb == NULL) {
if (intel_crtc-active i915_fastboot) {
@@ -8870,8 +8871,6 @@ intel_set_config_compute_mode_changes(struct drm_mode_set
*set,
config-mode_changed = true;
} else if (!intel_crtc-active) {
config-mode_changed = true;
- } else {
- config-fb_changed = true;
}
}
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Initialize seqno for VECS too
On Tue, Aug 13, 2013 at 01:55:36PM -0700, Ben Widawsky wrote:
On Mon, Aug 12, 2013 at 04:53:03PM -0700, Ben Widawsky wrote:
Cc: Mika Kuoppala mika.kuopp...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65387
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67198
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 10c2aaa..665602f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1592,6 +1592,8 @@ void intel_ring_init_seqno(struct intel_ring_buffer
*ring, u32 seqno)
if (INTEL_INFO(ring-dev)-gen = 6) {
I915_WRITE(RING_SYNC_0(ring-mmio_base), 0);
I915_WRITE(RING_SYNC_1(ring-mmio_base), 0);
+ if (HAS_VEBOX(ring-dev))
+ I915_WRITE(RING_SYNC_2(ring-mmio_base), 0);
}
ring-set_seqno(ring, seqno);
We require n-1 mailboxes for proper semaphore synchronization. All
semaphore synchronization code relies on proper values in these
mailboxes. The fact that we failed to touch the vebox ring by itself was
unlikely to be an issue since the HW should be initializing the values
to 0. However the error framework for testing seqno wrap introduced by
Mika, in addition to the hangcheck via seqno, and
i915_error_first_batchbuffer() combined caused a nice explosion.
The problem is caused by seqno wrap because the wrap condition is not
properly setup. The wrap code attempts to set the sync mailboxes all to
0, and then set the current seqno to one less than 0. In all cases, the
vebox mailbox wasn't properly being initialized. This caused a wrap to
not occur. When hangcheck kicks in with the bogus seqno values, the rest
just doesn't work. It makes me wonder if we shouldn't consider a dumber
version of hangcheck...
How we messed this up:
VECS support was written before the aforementioned other features. Upon
VECS being rebased, these facts were missed.
Both patches applied, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests: add pc8
On Tue, Aug 06, 2013 at 05:43:23PM -0300, Paulo Zanoni wrote: 2013/8/6 Daniel Vetter dan...@ffwll.ch: On Tue, Aug 06, 2013 at 04:33:53PM -0300, Paulo Zanoni wrote: 2013/8/5 Daniel Vetter dan...@ffwll.ch: On Mon, Aug 05, 2013 at 10:42:08AM -0300, Paulo Zanoni wrote: 2013/8/5 Daniel Vetter dan...@ffwll.ch: On Mon, Jul 29, 2013 at 05:53:27PM -0300, Paulo Zanoni wrote: The problem is: let's imagine there's some important register that we initialize when starting the driver, but then we don't touch it anymore. And this register is one of the registers that get reset when we enter PC8, but our code doesn't fix it after leaving PC8. So if you boot your machine, do something to allow PC8+ and then disallow it, the register will go back to the reset state (which isn't guaranteed to be 0x0, especially on display registers). Then you run tests/pc8: it reads the register (which contains the reset value instead of the real value set by our driver when it got loaded, because we already entered PC8+ once), enters PC8+, leaves PC8+, reads the register again, notices the value is the same and then gives us a PASS. On the other hand, if you didn't reach PC8+ before running tests/pc8, then it would have noticed the value of the register changes. In other words: if some register gets initialized by our driver to a non-default value, but this value gets lost after we enter/leave PC8+, we will *only* be able to notice the difference when comparing a state where we *never* entered PC8+ against a state where we already entered PC8+ at least once, because after the first time you enter/leave PC8+ you'll already have reset the register, so you'll be comparing bugged state against bugged state. Ok, I see your point. But imo igt testcases shouldn't (at least with the testcases run by default) have such detailed knowledge of what the kernel actually does with the registers. So a depency like this test needs to be run after a fresh boot when we've never entered pc8+ yet isn't good since it'll make the testcase fragile. Instead the test should check whether everything still works after we've been in pc8+ for a bit. One exception could be w/a bits if we have a common igt testcase to check for all of them. Then we could just rerun that testcase. But if e.g. the swizzling settings get lost over pc8+ it's better to add an explicit functional swizzle test here instead of checking registers. So instead of doing this, why not just make sure the very first i-g-t test gets us to PC8+, ant then run the full i-g-t suite after that? This should cover all the stuff that breaks due to us not restoring registers properly. Then we only have to worry about the things that run while PC8 is enabled, we can do that in another test. It would be nice if we could do this (e.g. also for re-running igt after gpu hangs or after a suspend/resume). But I think atm QA runs testcases essentially in a random order (or not in one we can control) so doing that is pretty hard. Can't we just tell them we need this one first? Not really since such testcase would be really fragile. If you really need/want a reliable starting point you could simply suspend/resume the machine. lib/drmtest.c has a little helper for that, see tests/gem_suspend.c Since the major usecase here would be to sanity-check some registers (for w/a and sane settings, e.g. the ddi transalation buffer settings) and we don't yet really have a good integration of the existing wa setting checker tool I think we can just punt here. I'll add a note to my igt wishlist about this. And of course pls keep the special test mode in your testcase so that developers could manually check that we correctly restore registers. Well, the ddi buffer translation problem leads to big screen corruption on testdisplay. There are always limits to what we can reliably test, but such issues could be caught by QA's QR code reader support in testdisplay. Unfortunately that support isn't readily available as a little drmtest.c helper function, mostly since I don't have the setup myself and so can't test it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/14] drm/i915: add basic MIPI DSI output support
On Tue, Aug 13, 2013 at 04:29:47PM +0300, Jani Nikula wrote:
This does not include any panel specific sub-encoders yet.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Quick bikesheed on how you wire up the get_modes stuff, mostly because I'm
just discussing this on irc with Rob:
- We now have intel_connector-panel.fixed_mode
- And I think it's better to route all the get_modes stuff entirely
through the connector layer, leaving the dsi encoder entirely out of the
picture. Maybe we should even go as far as registering the drm_connector
from the dsi sink device since that one really knows all the details
(like all the properties of the panel, what mode it supports or whether
maybe this DSI thingy is actually some transcoder with a totally
different output attached ...).
Cheers, Daniel
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_dsi.c | 548
++
3 files changed, 550 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_dsi.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8bffd29..5864c5b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -21,6 +21,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o \
intel_display.o \
intel_crt.o \
intel_lvds.o \
+ intel_dsi.o \
intel_dsi_cmd.o \
intel_bios.o \
intel_ddi.o \
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index a31abc6..cbe3df1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -525,6 +525,7 @@ extern void intel_mark_fb_busy(struct drm_i915_gem_object
*obj,
struct intel_ring_buffer *ring);
extern void intel_mark_idle(struct drm_device *dev);
extern void intel_lvds_init(struct drm_device *dev);
+extern bool intel_dsi_init(struct drm_device *dev);
extern bool intel_is_dual_link_lvds(struct drm_device *dev);
extern void intel_dp_init(struct drm_device *dev, int output_reg,
enum port port);
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
new file mode 100644
index 000..aa81dd8
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -0,0 +1,548 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Author: Jani Nikula jani.nik...@intel.com
+ */
+
+#include drm/drmP.h
+#include drm/drm_crtc.h
+#include drm/drm_edid.h
+#include drm/i915_drm.h
+#include linux/slab.h
+#include i915_drv.h
+#include intel_drv.h
+#include intel_dsi.h
+#include intel_dsi_cmd.h
+
+/* the sub-encoders aka panel drivers */
+static const struct intel_dsi_device intel_dsi_devices[] = {
+};
+
+static struct intel_dsi *intel_attached_dsi(struct drm_connector *connector)
+{
+ return container_of(intel_attached_encoder(connector),
+ struct intel_dsi, base);
+}
+
+static inline bool is_vid_mode(struct intel_dsi *intel_dsi)
+{
+ return intel_dsi-dev.type == INTEL_DSI_VIDEO_MODE;
+}
+
+static inline bool is_cmd_mode(struct intel_dsi *intel_dsi)
+{
+ return intel_dsi-dev.type == INTEL_DSI_COMMAND_MODE;
+}
+
+static void intel_dsi_hot_plug(struct intel_encoder *encoder)
+{
+ DRM_DEBUG_KMS(\n);
+}
+
+static bool intel_dsi_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_config *config)
+{
+ DRM_DEBUG_KMS(\n);
+ return true;
+}
+
+static void intel_dsi_pre_pll_enable(struct intel_encoder *encoder)
+{
+ DRM_DEBUG_KMS(\n);
+}
+
+static void intel_dsi_pre_enable(struct intel_encoder *encoder)
+{
+ DRM_DEBUG_KMS(\n);
[Intel-gfx] HDMI 4k support v2
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
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [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 damien.lesp...@intel.com
---
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [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ä)
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
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)
{
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;
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [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ä)
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Tested-by: Cancan Feng cancan.f...@intel.com
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
@@ -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(Unknow 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)
@@ -2518,6 +2625,8 @@ add_cea_modes(struct drm_connector *connector, const
struct edid *edid)
if (cea_db_tag(db) == VIDEO_BLOCK)
modes +=
[Intel-gfx] [PATCH 04/12] drm: Add support for alternate clocks of 4k modes
Suggested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
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
+ * @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-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [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 damien.lesp...@intel.com
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 damien.lesp...@intel.com
---
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 606335f..ec47eb8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3258,7 +3258,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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/12] video/hdmi: Derive the bar data valid bit from the bar data fields
Just like:
Author: Damien Lespiau damien.lesp...@intel.com
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 damien.lesp...@intel.com
---
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/12] video/hdmi: Introduce helpers for the HDMI vendor specific infoframe
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 damien.lesp...@intel.com
---
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,
+ 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_infoframe spd;
struct hdmi_vendor_infoframe vendor;
+ struct hdmi_hdmi_infoframe hdmi;
struct hdmi_audio_infoframe audio;
};
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [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.
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Terje Bergström tbergst...@nvidia.com
Cc: linux-te...@vger.kernel.org
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [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 damien.lesp...@intel.com
---
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 ec47eb8..9a07a33 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 f5098a8..53bbf0d 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [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 damien.lesp...@intel.com
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 damien.lesp...@intel.com
---
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;
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_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_infoframe audio;
};
--
[Intel-gfx] [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.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
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);
+ 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [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 damien.lesp...@intel.com
---
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_encoder *encoder,
[Intel-gfx] [PATCH igt] intel_infoframes: Add support for decoding HDMI VICs
The HDMI vendor infoframe can contain a HDMI VIC (as of HDMI 1.4, only
used for 4k formats).
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
tools/intel_infoframes.c | 26 ++
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/tools/intel_infoframes.c b/tools/intel_infoframes.c
index 09fdcb9..b6d289f 100644
--- a/tools/intel_infoframes.c
+++ b/tools/intel_infoframes.c
@@ -184,8 +184,13 @@ typedef union {
uint8_t Rsvd0:5;
uint8_t video_format :3;
- uint8_t Rsvd1 :4;
- uint8_t s3d_structure :4;
+ union {
+ uint8_t vic;
+ struct {
+ uint8_t Rsvd1 :4;
+ uint8_t s3d_structure :4;
+ } s3d;
+ } pb5;
uint8_t Rsvd2:4;
uint8_t s3d_ext_data :4;
@@ -467,13 +472,26 @@ static const char *s3d_structure_to_string(int format)
static void dump_vendor_hdmi(DipInfoFrame *frame)
{
+ int vic_present = frame-vendor.video_format 0x1;
int s3d_present = frame-vendor.video_format 0x2;
printf(- video format: 0x%03x %s\n, frame-vendor.video_format,
s3d_present ? (3D) : );
- if (s3d_present)
+
+ if (vic_present s3d_present) {
+ printf(Error: HDMI VIC and S3D bits set. Only one of those
+ at a time is valid\n);
+ return;
+ }
+
+ if (vic_present)
+ printf(- HDMI VIC: %d\n, frame-vendor.pb5.vic);
+ else if (s3d_present) {
+ int s3d_structure = frame-vendor.pb5.s3d.s3d_structure;
+
printf(- 3D Format: %s\n,
- s3d_structure_to_string(frame-vendor.s3d_structure));
+ s3d_structure_to_string(s3d_structure));
+ }
}
static void dump_vendor_info(Transcoder transcoder)
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [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 j...@joshtriplett.org --- 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] [v2] drm/i915: Remove node only when allocated
VMAs can be created and not bound. One may think of it as lazy cleanup, and safely gloss over the conditions which manufacture it. In either case, when the object backing the i915 vma is destroyed, we must cleanup the vma without stumbling into a bunch of pitfalls that assume the vma is bound. NOTE: I was pretty certain the above condition could only happen when we introduced the use of VMAs being looked up at execbuf, and already existing. Paulo has hit this though, so I must be missing something. As I believe the patch is correct anyway, therefore I won't scratch my head too hard. v2: use goto destroy as a compromise (Chris) Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Paulo Zanoni paulo.r.zan...@intel.com Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_gem.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 3d9e248b..4a58ead 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2606,6 +2606,9 @@ int i915_vma_unbind(struct i915_vma *vma) if (list_empty(vma-vma_link)) return 0; + if (!drm_mm_node_allocated(vma-node)) + goto destroy; + if (obj-pin_count) return -EBUSY; @@ -2643,6 +2646,8 @@ int i915_vma_unbind(struct i915_vma *vma) obj-map_and_fenceable = true; drm_mm_remove_node(vma-node); + +destroy: i915_gem_vma_destroy(vma); /* Since the unbound list is global, only move to that list if -- 1.8.3.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] [v3] drm/i915: cleanup mapfence in bind
Cleanup the map and fenceable setting during bind to make more sense,
and not check i915_is_ggtt() 2 unnecessary times
v2: Move the bools into the if block (Chris) - There are ways to tidy
this function (fence calculations for instance) even further, but they
are quite invasive, so I am punting on those unless specifically asked.
v3: Add newline between variable declaration and logic (Chris)
Recommended-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4a58ead..01cc016 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3106,7 +3106,6 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
struct drm_device *dev = obj-base.dev;
drm_i915_private_t *dev_priv = dev-dev_private;
u32 size, fence_size, fence_alignment, unfenced_alignment;
- bool mappable, fenceable;
size_t gtt_max =
map_and_fenceable ? dev_priv-gtt.mappable_end : vm-total;
struct i915_vma *vma;
@@ -3191,18 +3190,18 @@ search_free:
list_move_tail(obj-global_list, dev_priv-mm.bound_list);
list_add_tail(vma-mm_list, vm-inactive_list);
- fenceable =
- i915_is_ggtt(vm)
- i915_gem_obj_ggtt_size(obj) == fence_size
- (i915_gem_obj_ggtt_offset(obj) (fence_alignment - 1)) == 0;
+ if (i915_is_ggtt(vm)) {
+ bool mappable, fenceable;
- mappable =
- i915_is_ggtt(vm)
- vma-node.start + obj-base.size = dev_priv-gtt.mappable_end;
+ fenceable =
+ i915_gem_obj_ggtt_size(obj) == fence_size
+ (i915_gem_obj_ggtt_offset(obj) (fence_alignment - 1))
== 0;
+
+ mappable =
+ vma-node.start + obj-base.size =
dev_priv-gtt.mappable_end;
- /* Map and fenceable only changes if the VM is the global GGTT */
- if (i915_is_ggtt(vm))
obj-map_and_fenceable = mappable fenceable;
+ }
WARN_ON(map_and_fenceable !obj-map_and_fenceable);
--
1.8.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [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 b...@bwidawsk.net 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 airl...@redhat.com CC: dri-de...@lists.freedesktop.org Acked-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky b...@bwidawsk.net --- 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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] [v4] drm/i915: Convert execbuf code to use vmas
From: Ben Widawsky b...@bwidawsk.net
In order to transition more of our code over to using a VMA instead of
an OBJ, VM pair - we must have the vma accessible at execbuf time. Up
until now, we've only had a VMA when actually binding an object.
The previous patch helped handle the distinction on bound vs. unbound.
This patch will help us catch leaks, and other issues before we actually
shuffle a bunch of stuff around.
This attempts to convert all the execbuf code to speak in vmas. Since
the execbuf code is very self contained it was a nice isolated
conversion.
The meat of the code is about turning eb_objects into eb_vma, and then
wiring up the rest of the code to use vmas instead of obj, vm pairs.
Unfortunately, to do this, we must move the exec_list link from the obj
structure. This list is reused in the eviction code, so we must also
modify the eviction code to make this work.
WARNING: This patch makes an already hotly profiled path slower. The cost is
unavoidable. In reply to this mail, I will attach the extra data.
v2: Release table lock early, and two a 2 phase vma lookup to avoid
having to use a GFP_ATOMIC. (Chris)
v3: s/obj_exec_list/obj_exec_link/
Updates to address
commit 6d2b888569d366beb4be72cacfde41adee2c25e1
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Wed Aug 7 18:30:54 2013 +0100
drm/i915: List objects allocated from stolen memory in debugfs
v4: Use obj = vma-obj for neatness in some places (Chris)
need_reloc_mappable() should return false if ppgtt (Chris)
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c| 12 +-
drivers/gpu/drm/i915/i915_drv.h| 25 ++-
drivers/gpu/drm/i915/i915_gem.c| 28 ++-
drivers/gpu/drm/i915/i915_gem_evict.c | 31 ++-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 319 -
5 files changed, 232 insertions(+), 183 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index eb87865..4785d8c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -195,9 +195,9 @@ static int obj_rank_by_stolen(void *priv,
struct list_head *A, struct list_head *B)
{
struct drm_i915_gem_object *a =
- container_of(A, struct drm_i915_gem_object, exec_list);
+ container_of(A, struct drm_i915_gem_object, obj_exec_link);
struct drm_i915_gem_object *b =
- container_of(B, struct drm_i915_gem_object, exec_list);
+ container_of(B, struct drm_i915_gem_object, obj_exec_link);
return a-stolen-start - b-stolen-start;
}
@@ -221,7 +221,7 @@ static int i915_gem_stolen_list_info(struct seq_file *m,
void *data)
if (obj-stolen == NULL)
continue;
- list_add(obj-exec_list, stolen);
+ list_add(obj-obj_exec_link, stolen);
total_obj_size += obj-base.size;
total_gtt_size += i915_gem_obj_ggtt_size(obj);
@@ -231,7 +231,7 @@ static int i915_gem_stolen_list_info(struct seq_file *m,
void *data)
if (obj-stolen == NULL)
continue;
- list_add(obj-exec_list, stolen);
+ list_add(obj-obj_exec_link, stolen);
total_obj_size += obj-base.size;
count++;
@@ -239,11 +239,11 @@ static int i915_gem_stolen_list_info(struct seq_file *m,
void *data)
list_sort(NULL, stolen, obj_rank_by_stolen);
seq_puts(m, Stolen:\n);
while (!list_empty(stolen)) {
- obj = list_first_entry(stolen, typeof(*obj), exec_list);
+ obj = list_first_entry(stolen, typeof(*obj), obj_exec_link);
seq_puts(m,);
describe_obj(m, obj);
seq_putc(m, '\n');
- list_del_init(obj-exec_list);
+ list_del_init(obj-obj_exec_link);
}
mutex_unlock(dev-struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3fc4324..2147e4d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -563,6 +563,17 @@ struct i915_vma {
struct list_head mm_list;
struct list_head vma_link; /* Link in the object's VMA list */
+
+ /** This vma's place in the batchbuffer or on the eviction list */
+ struct list_head exec_list;
+
+ /**
+* Used for performing relocations during execbuffer insertion.
+*/
+ struct hlist_node exec_node;
+ unsigned long exec_handle;
+ struct drm_i915_gem_exec_object2 *exec_entry;
+
};
struct i915_ctx_hang_stats {
@@ -1312,8 +1323,8 @@ struct drm_i915_gem_object {
struct list_head global_list;
struct list_head ring_list;
- /** This object's place in the batchbuffer or on the eviction list */
- struct list_head exec_list;
+ /** Used in
Re: [Intel-gfx] [PATCH 4/4] [v4] drm/i915: Convert execbuf code to use vmas
On Tue, Aug 13, 2013 at 06:09:09PM -0700, Ben Widawsky wrote: From: Ben Widawsky b...@bwidawsk.net In order to transition more of our code over to using a VMA instead of an OBJ, VM pair - we must have the vma accessible at execbuf time. Up until now, we've only had a VMA when actually binding an object. The previous patch helped handle the distinction on bound vs. unbound. This patch will help us catch leaks, and other issues before we actually shuffle a bunch of stuff around. This attempts to convert all the execbuf code to speak in vmas. Since the execbuf code is very self contained it was a nice isolated conversion. The meat of the code is about turning eb_objects into eb_vma, and then wiring up the rest of the code to use vmas instead of obj, vm pairs. Unfortunately, to do this, we must move the exec_list link from the obj structure. This list is reused in the eviction code, so we must also modify the eviction code to make this work. WARNING: This patch makes an already hotly profiled path slower. The cost is unavoidable. In reply to this mail, I will attach the extra data. [snip] Here is the output from gem_exec_lut_handle both before and after this patch. The results honestly don't make sense to me, but I'll set Chris parse it before scratching my head harder. Before patch relocation: buffers= 1: old= 8060 + 165.3*reloc, lut= 7816 + 164.8*reloc (ns) relocation: buffers= 2: old= 6748 + 166.6*reloc, lut= 6952 + 165.4*reloc (ns) relocation: buffers= 4: old= 8140 + 165.9*reloc, lut= 8216 + 165.4*reloc (ns) relocation: buffers= 8: old= 10732 + 166.0*reloc, lut= 10615 + 165.2*reloc (ns) relocation: buffers= 16: old= 15099 + 167.8*reloc, lut= 15337 + 165.3*reloc (ns) relocation: buffers= 32: old= 26140 + 166.0*reloc, lut= 25488 + 165.5*reloc (ns) relocation: buffers= 64: old= 46300 + 170.5*reloc, lut= 44279 + 166.7*reloc (ns) relocation: buffers= 128: old= 84056 + 176.9*reloc, lut= 85379 + 166.3*reloc (ns) relocation: buffers= 256: old= 174398 + 167.9*reloc, lut= 167744 + 167.0*reloc (ns) relocation: buffers= 512: old= 349688 + 175.7*reloc, lut= 348590 + 170.8*reloc (ns) relocation: buffers=1024: old= 726265 + 191.2*reloc, lut= 719774 + 180.2*reloc (ns) relocation: buffers=2048: old=1456866 + 224.3*reloc, lut=1442087 + 173.0*reloc (ns) skip-relocs: buffers= 1: old= 4445 + 16.0*reloc, lut= 4433 + 15.6*reloc (ns) skip-relocs: buffers= 2: old= 4585 + 16.0*reloc, lut= 4571 + 15.6*reloc (ns) skip-relocs: buffers= 4: old= 5667 + 16.0*reloc, lut= 5340 + 15.6*reloc (ns) skip-relocs: buffers= 8: old= 6051 + 16.1*reloc, lut= 6026 + 15.6*reloc (ns) skip-relocs: buffers= 16: old= 7953 + 16.1*reloc, lut= 7914 + 15.6*reloc (ns) skip-relocs: buffers= 32: old= 11972 + 16.2*reloc, lut= 11875 + 15.7*reloc (ns) skip-relocs: buffers= 64: old= 1 + 16.5*reloc, lut= 19832 + 15.7*reloc (ns) skip-relocs: buffers= 128: old= 37796 + 16.9*reloc, lut= 36539 + 15.9*reloc (ns) skip-relocs: buffers= 256: old= 71604 + 18.1*reloc, lut= 71313 + 16.5*reloc (ns) skip-relocs: buffers= 512: old= 152682 + 24.3*reloc, lut= 141379 + 27.9*reloc (ns) skip-relocs: buffers=1024: old= 314116 + 41.7*reloc, lut= 303019 + 20.1*reloc (ns) skip-relocs: buffers=2048: old= 619784 + 54.1*reloc, lut= 603931 + 20.0*reloc (ns) no-relocs: buffers= 1: old= 4194 + 5.1*reloc, lut= 4206 + 4.8*reloc (ns) no-relocs: buffers= 2: old= 4404 + 5.1*reloc, lut= 4381 + 4.8*reloc (ns) no-relocs: buffers= 4: old= 4926 + 5.1*reloc, lut= 4921 + 4.8*reloc (ns) no-relocs: buffers= 8: old= 5901 + 5.1*reloc, lut= 5822 + 4.9*reloc (ns) no-relocs: buffers= 16: old= 7840 + 5.1*reloc, lut= 7737 + 4.9*reloc (ns) no-relocs: buffers= 32: old= 11842 + 5.1*reloc, lut= 11681 + 4.9*reloc (ns) no-relocs: buffers= 64: old= 19741 + 5.1*reloc, lut= 19542 + 4.8*reloc (ns) no-relocs: buffers= 128: old= 36479 + 5.2*reloc, lut= 35958 + 4.9*reloc (ns) no-relocs: buffers= 256: old= 70171 + 5.4*reloc, lut= 69390 + 5.2*reloc (ns) no-relocs: buffers= 512: old= 147213 + 3.5*reloc, lut= 137953 + 13.0*reloc (ns) no-relocs: buffers=1024: old= 300165 + 4.8*reloc, lut= 293852 + 4.9*reloc (ns) no-relocs: buffers=2048: old= 597992 + 8.3*reloc, lut= 590185 + 2.1*reloc (ns) After patch === relocation: buffers= 1: old= 8075 + 81.4*reloc, lut= 7592 + 80.6*reloc (ns) relocation: buffers= 2: old= 5744 + 82.3*reloc, lut= 5837 + 81.1*reloc (ns) relocation: buffers= 4: old= 4875 + 82.7*reloc, lut= 4871 + 81.6*reloc (ns) relocation: buffers= 8: old= 5729 + 82.7*reloc, lut= 5698 + 81.5*reloc (ns) relocation: buffers= 16: old= 7952 + 83.0*reloc, lut= 7809 + 81.9*reloc (ns) relocation: buffers= 32: old= 11884 + 82.9*reloc, lut= 11702 + 81.6*reloc (ns) relocation: buffers= 64: old= 20388 + 83.4*reloc, lut= 19995 + 82.2*reloc (ns) relocation: buffers= 128: old= 38057 + 85.0*reloc, lut= 37675 +
