Bug 74657

Summary: [byt dsi] Mode detection fails on Dell Venue 8 Pro
Product: DRI Reporter: Adam Williamson <adamw>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: bugzilla, intel-gfx-bugs, jacek.m.danecki, samuel, thomas.wood, tobiasu
Version: unspecified   
Hardware: Other   
OS: All   
See Also: https://bugzilla.kernel.org/show_bug.cgi?id=68451
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
the V8P's EDID
none
journalctl from a KMS boot *without* forcing the mode (you can see 1024x768 is picked)
none
VBT from the Venue 8 Pro (/sys/kernel/debug/dri/0/i915_opregion )
none
quick_dump.py -a output on v8p none

Description Adam Williamson 2014-02-07 09:14:32 UTC
Following on from https://bugs.freedesktop.org/show_bug.cgi?id=71977 . With kernel 3.14-rc1 plus patches to fix various boot failures plus the reversion of "drm/i915/vlv: re-enable hotplug detect based probing on VLV/BYT" (that's 71977), multiple testers have confirmed you can get KMS to work on Bay Trail tablets.

On the Venue 8 Pro, the modesetting does not correctly discover the device's preferred mode, though, which is 800x1280 (the screen's 'native' orientation is portrait). It decides on 1024x768.

I've captured the EDID of the screen - I'll attach it. The thing that leaps out to me as being incorrect is that the minimum hsync and vsync are both set to 0, which is I believe outside the spec (Wikipedia sez it should be in the range of 1–255 kHz).

If I run monitor-parse-edid on the unmodified EDID, it barfs:

[adamw@adam data]$ monitor-parse-edid AUO00C4.bin 
bad HorizSync

with a version hex edited to bump the min hsync and vsync to 10 (hex, so 16kHz), it works:

[adamw@adam data]$ monitor-parse-edid AUO00C4_mod.bin 
EISA ID: AUO00c4
EDID version: 1.3
EDID extension blocks: 0
Screen size: 10.8 cm x 17.2 cm (8.00 inches, aspect ratio 0.63)
Gamma: 3.55
Digital signal
Max video bandwidth: 80 MHz

	HorizSync 16-173
	VertRefresh 16-60

	# Monitor preferred modeline (60.0 Hz vsync, 78.0 kHz hsync, ratio 0.62, 188 dpi)
	ModeLine "800x1280" 76.75 800 824 828 984 1280 1288 1292 1300 -hsync -vsync

I know the kernel code isn't the same as monitor-parse-edid, but it still seems indicative.
Comment 1 Adam Williamson 2014-02-07 09:15:17 UTC
Created attachment 93593 [details]
the V8P's EDID
Comment 2 Adam Williamson 2014-02-07 09:16:26 UTC
Created attachment 93594 [details]
journalctl from a KMS boot *without* forcing the mode (you can see 1024x768 is picked)
Comment 3 Adam Williamson 2014-02-07 09:40:02 UTC
The other thing to note is that if I run 'monitor-edid' directly on the tablet, I get "ERROR: timeout during EDID probe" three times (slowly, not instantly), and nothing else. I captured the EDID with a Windows tool.
Comment 4 Adam Williamson 2014-02-07 18:40:17 UTC
From ajax today:

---

If I'm reading the dmesg there correctly, it looks like that EDID shows up on the VGA port?  Which could cause problems, since the EDID claims to be for a digital output, so we might refuse to believe it's attached to an analog port.  But also:

eb 06 20:04:30 localhost kernel: [drm:valleyview_crt_detect_hotplug], valleyview hotplug adpa=0xf40000, result 0
Feb 06 20:04:30 localhost kernel: [drm:intel_crt_detect], CRT detected via hotplug
Feb 06 20:04:30 localhost kernel: [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2
Feb 06 20:04:30 localhost kernel: [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus vga
Feb 06 20:04:30 localhost kernel: [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:VGA-1] probed modes :
Feb 06 20:04:30 localhost kernel: [drm:drm_mode_debug_printmodeline], Modeline 21:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
Feb 06 20:04:30 localhost kernel: [drm:drm_mode_debug_printmodeline], Modeline 19:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
Feb 06 20:04:30 localhost kernel: [drm:drm_mode_debug_printmodeline], Modeline 18:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5
Feb 06 20:04:30 localhost kernel: [drm:drm_mode_debug_printmodeline], Modeline 20:"848x480" 60 33750 848 864 976 1088 480 486 494 517 0x40 0x5
Feb 06 20:04:30 localhost kernel: [drm:drm_mode_debug_printmodeline], Modeline 17:"640x480" 60 25175 640 656 752 800 480 489 492 525 0x40 0xa

It looks like Linux is failing to read DDC off the VGA port (possibly not surprising, the EDID might be in the VBT instead of on the other end of I2C).  But we're only going to look in the VBT for EDID for LVDS or eDP, and since this appears to be VGA not LVDS...

Anyway that could be the bug, it could also not.  If it's not that then I'd want to manually step through i915 init to figure it out.

---
Comment 5 Adam Williamson 2014-02-07 19:29:23 UTC
Created attachment 93629 [details]
VBT from the Venue 8 Pro (/sys/kernel/debug/dri/0/i915_opregion )

Attaching the VBT from my v8p, as requested by ajax. full vbios doesn't appear to be available to userspace.

<ajax> i think the trick here really is figure out how to tell that VGA is actually LVDS
Comment 6 Ville Syrjala 2014-02-07 19:48:01 UTC
If this thing is like the Asus T100TA, then it's a DSI display (or at least DSI is how it's hooked up to the soc, might be a DSI->LVDS bridge or something actually).

See here for the Asus case:
https://bugzilla.kernel.org/show_bug.cgi?id=68451

Would be great if you can repeat the quick_dump check to make sure if it's really DSI.
Comment 7 Adam Williamson 2014-02-07 20:05:25 UTC
Ah, neat. I strongly suspect they'll be the same, but I'll check. Just need to bump Fedora's intel-gpu-tools first :/
Comment 8 Adam Williamson 2014-02-07 20:58:34 UTC
Having all kinds of trouble getting quick_dump built, I'm afraid - my latest attempt at building our xorg-x11-drv-intel package (where we also build intel-gpu-tools) with the latest i-g-t git snapshot failed like this:

http://kojipkgs.fedoraproject.org//work/tasks/5651/6505651/build.log

make[3]: Entering directory `/builddir/build/BUILD/intel-gpu-tools-20140207/debugger/system_routine'
  CC       eviction_macro.o
  CCLD     eviction_macro
./pre_cpp.py ./sr.g4a > sr.cpp.tmp && mv sr.cpp.tmp sr.cpp
Traceback (most recent call last):
  File "./pre_cpp.py", line 38, in <module>
    lines = file.readlines()
  File "/usr/lib/python3.3/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 16: ordinal not in range(128)
make[3]: *** [sr.cpp] Error 1

It builds fine with Python 2, but I have to pull in Python 3 to build quick_dump , and when I do that, it builds everything else with Python 3 too.
Comment 9 Ville Syrjala 2014-02-07 21:16:42 UTC
(In reply to comment #8)
> Having all kinds of trouble getting quick_dump built, I'm afraid - my latest
> attempt at building our xorg-x11-drv-intel package (where we also build
> intel-gpu-tools) with the latest i-g-t git snapshot failed like this:
> 
> http://kojipkgs.fedoraproject.org//work/tasks/5651/6505651/build.log
> 
> make[3]: Entering directory
> `/builddir/build/BUILD/intel-gpu-tools-20140207/debugger/system_routine'
>   CC       eviction_macro.o
>   CCLD     eviction_macro
> ./pre_cpp.py ./sr.g4a > sr.cpp.tmp && mv sr.cpp.tmp sr.cpp
> Traceback (most recent call last):
>   File "./pre_cpp.py", line 38, in <module>
>     lines = file.readlines()
>   File "/usr/lib/python3.3/encodings/ascii.py", line 26, in decode
>     return codecs.ascii_decode(input, self.errors)[0]
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 16:
> ordinal not in range(128)
> make[3]: *** [sr.cpp] Error 1
> 
> It builds fine with Python 2, but I have to pull in Python 3 to build
> quick_dump , and when I do that, it builds everything else with Python 3 too.

Some kind of locale problem. Looks like it fails the same way for me if I set LC_ALL=C. With LC_ALL=en_US.UTF-8 it builds fine.
Comment 10 Adam Williamson 2014-02-08 02:23:22 UTC
OK, building with LC_ALL=en_US.UTF-8 does the trick, but then running the installed binary on the tablet can't import the _chipset module. I've no idea where it's supposed to be finding that, but it isn't.
Comment 11 Adam Williamson 2014-02-08 02:29:29 UTC
oh, looks like it's built into /usr/lib/I915ChipsetPython.so , but it's not finding that...
Comment 12 Adam Williamson 2014-02-11 17:35:17 UTC
Created attachment 93876 [details]
quick_dump.py -a output on v8p

OK, here's the 'quick_dump.py -a' output from a Venue 8 Pro.
Comment 13 Ville Syrjala 2014-02-11 17:55:45 UTC
(In reply to comment #12)
> Created attachment 93876 [details]
> quick_dump.py -a output on v8p
> 
> OK, here's the 'quick_dump.py -a' output from a Venue 8 Pro.

0x001f0008 | PIPEACONF                    | 0xe0000000
0x001e1190 | MIPIA_PORT_CTRL              | 0x80010000
0x0018b020 | MIPIA_DPI_RESOLUTION         | 0x05000320

Yeah, looks like DSI @ 1280x800 resolution.
Comment 14 Adam Williamson 2014-02-12 06:58:10 UTC
So, I guess this doesn't need to be NEEDINFO any more - let me know if you needed something else. Would it be safe to mark this as a dupe of Alan's?
Comment 15 Adam Williamson 2014-02-12 06:58:33 UTC
btw, it's 800x1280 resolution - the screen is native portrait.
Comment 16 Daniel Vetter 2014-03-27 09:21:30 UTC
Jani admitted to now possessing a dsi byt platform.
Comment 17 Jani Nikula 2014-06-13 08:55:18 UTC
Please try Linus' master; this should be fixed with

commit 682b7c1c8ea8885aa681ddf530d6cf2ad4f2dc15
Merge: 16b9057804c0 bc1dfff04a5d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jun 12 11:32:30 2014 -0700

    Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux
Comment 18 Adam Williamson 2014-08-20 23:08:15 UTC
My V8P still has trouble with 3.16, but I filed a new bug for it - https://bugs.freedesktop.org/show_bug.cgi?id=82880 - so we could possibly close this one. The DSI support was definitely added in 3.16 and seems to be working for some folks, but not for me yet :/
Comment 19 Jani Nikula 2014-09-05 12:18:01 UTC
(In reply to comment #18)
> My V8P still has trouble with 3.16, but I filed a new bug for it -
> https://bugs.freedesktop.org/show_bug.cgi?id=82880 - so we could possibly
> close this one. The DSI support was definitely added in 3.16 and seems to be
> working for some folks, but not for me yet :/

Closing this one as the feature has been merged; let's track remaining issues with your model at bug 82880. Thanks for the report.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.