Created attachment 125149 [details] Full dmesg - Steps to reproduce the issue: I turn on the tablet, grub menu appears, then a few lines of log displayed as linux boots, then the DSI display goes blank. Backlight is visibly on all the time. - How often does the steps listed above trigger the issue? Always - system architecture: ("uname -m"): x86_64 - kernel version: ("uname -r"): 4.7.0-rc7+ (compiled from drm-intel-nightly on 2016-07-18) - Linux distribution: Debian testing - Machine or mother board model: Teclast X80H baytrail-t tablet (z3735f CPU) - Display connector: DSI full dmesg is attached.
I've had this bug open as BUG 93799, then I added it as a duplicate of BUG 90469, which is the same issue on a different hardware, but that bug was tested on its original hardware, and got closed. As I wrote in BUG 90469 Comment 51, the kernels between linux-next-20151012 to linux-next-20151119 actually worked, there were some red or purple screen for a second, but then the DSI display worked properly. I found out that for later kernels I needed to add i915.fastboot=1 to have the display working, like 4.6.0-rc4. But something went wrong again, because it doesn't work even with i915.fastboot=1 with newer kernels (I first detected this on 20160517 with intel-drm-nightly) With kernels, where the DSI display doesn't work, there are warnings in the dmesg. In the latest dmesg I get: [ 8.592431] WARNING: CPU: 3 PID: 59 at drivers/gpu/drm/i915/intel_display.c:13590 intel_atomic_commit_tail+0x104b/0x1050 [i915] [ 8.592435] pipe A vblank wait timed out
Wow, thanks for the hint! Although booting with i915.fastboot=1 or video=1280x800@60 alone doesn't fix the problem for me with vanilla 4.7.2, using both options together gets the display working! I'll do more testing with it. My device is iWork 8, with the exact same CPU and display, like many other budget Baytrail-based tablets.
Created attachment 126760 [details] Dmesg of drm-intel-nightly-2016-09-20 This is a new dmesg of drm-intel-nightly fetched on 2016-09-20. This time it is without the i915.fastboot=1 parameter. The screen worked with i915.fastboot=1 from Nov 2015 to kernel 4.6.7, but not with newer ones. I made a video of the boot process, but it is really not interesting, the screen goes blank after line "[7.648499] fb: switching to inteldrmfb from simple" There is an WARNING later in the boot log: [ 9.197313] [drm:intel_dsi_enable] [ 9.333433] [drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511 [ 9.333451] [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=461, cursor=63, sprite0=0, sprite1=0, SR: plane=0, cursor=0 level=0 cxsr=0 [ 9.333457] [drm:intel_enable_pipe] enabling pipe A [ 9.333485] [drm:intel_dsi_enable_nop] [ 9.389302] ------------[ cut here ]------------ [ 9.389560] WARNING: CPU: 2 PID: 61 at drivers/gpu/drm/i915/intel_display.c:14144 intel_atomic_commit_tail+0x1075/0x10a0 [i915] [ 9.389564] pipe A vblank wait timed out Could someone please take a look at the log, and tell me what goes wrong?
Created attachment 127198 [details] dmesg of 4.6.7 with i915.fastboot=1, DSI screen works I've compared this to the other dmesgs, and the first difference I can see that this has: [ 8.109949] [drm:intel_dump_pipe_config] [CRTC:26][fastset] config ffff88007ac95800 for pipe A Notice it has fastset in it. All other (non-working) dmesgs has modeset instead of fastset.
Created attachment 127200 [details] dmesg of 4.6.7 with no fastboot parameter, DSI screen goes blank If I understand correctly, with fastboot=1 (fastset) the driver doesn't try to initialize the dsi display, it just takes it over, and it works. Without the fastboot, it disables the dsi screen, tries to initialize it again, and this is where something goes wrong: [ 9.060698] [drm:vlv_dsi_device_ready] [ 9.097539] [drm:generic_exec_sequence] Starting MIPI sequence 1 - MIPI_SEQ_ASSERT_RESET [ 9.129546] [drm:generic_exec_sequence] Starting MIPI sequence 2 - MIPI_SEQ_INIT_OTP [ 9.237341] [drm:intel_dsi_enable] [ 9.369496] [drm:generic_exec_sequence] MIPI sequence 3 - MIPI_SEQ_DISPLAY_ON not available [ 9.373597] [drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511 [ 9.373616] [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=461, cursor=63, sprite0=0, sprite1=0, SR: plane=0, cursor=0 level=0 cxsr=0 [ 9.373621] [drm:intel_enable_pipe] enabling pipe A [ 9.377542] [drm:intel_dsi_enable_nop] [ 9.429535] ------------[ cut here ]------------ [ 9.429763] WARNING: CPU: 3 PID: 59 at drivers/gpu/drm/i915/intel_display.c:13472 intel_atomic_commit+0x13bb/0x1450 [i915] [ 9.429770] WARN_ON(!lret)
Created attachment 128159 [details] dmesg of 4.8.9 still no picture on DSI
Hans probably fixed something related to this bug with these: commit 2b8208ac93be2783edc627fc02d9ca50cc479923 Author: Hans de Goede <hdegoede@redhat.com> Date: Fri Dec 2 16:01:28 2016 +0100 drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET commit 721d484563e1a51ada760089c490cbc47e909756 Author: Hans de Goede <hdegoede@redhat.com> Date: Fri Dec 2 15:29:04 2016 +0100 drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating So please re-test with the latest drm-tip.
Created attachment 128654 [details] Dmesg of drm-tip 2016-12-22, no WARNING, but still blank screen The patches make the WARNING go away, but the screen still stays blank after modeset. Just a wild guess: this may be a gpio issue like what Hans fixed with his patch [1] for CHT, but this is VLV. This tablet has a DollarCove pmic (AXP288), so this is not CrystalCove. The Android kernel code handled this pmic in intel_soc_pmic, while mainline has is in axp20x (in a really bad shape). Hans created some patches for it, but they are not in linux-next yet. This may, or may not be relevant for panel handling. [1]: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/i915?id=22ca0d4991169b76e753d767a45f1105c356bbb8
Created attachment 128660 [details] intel_reg dump output of kernel 4.6.7 with fastboot=1 where the dsi screen is working This is for reference.
Created attachment 128661 [details] intel_reg dump output of kernel 4.9.0 with fastboot=0 where dsi screen is not working Comparing (diff) this to the previous attachment reveals some differences.
Created attachment 128788 [details] dmesg of 4.10.0-994 drm-intel-nightly No changes in the new year, still blank screen on the almost identical "Trekstor SurfTab twin 10.1" Kernel: 4.10.0-994-generic drm-intel-nightly 2017-01-04 http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2017-01-04/ latest microcode, latest driver
I further investigated the problem and found out that my tablet has no usable framebuffer configuration when booted. But X is running. The timings are, according to fbset, all 0, the values xrandr shows are also just some standard values while the resolution is the only thing they get right. If i boot with nomodeset, I get a working screen and fbset and xrandr show completely different values. Obviously correct values. cvt shows always the same correct results. So I think, for some reason, this KMS stuff doesn't read the display values correctly. It's an Innolux 10x12 Witz 800x1280px. Yeah, 800x1280, not 1280x800! Has the Teclast tablet this 800x1280 resolution too? Maybe that is the difference to all the other z3735 tablets that are working while ours don't. The unusual higher than wide native resolution. Could that confuse this KMS stuff? If yes, how could we find that out? I couldn't find a way to see what KMS reads and how it reads and what it passes to whom...
Should have read your dmesgs before posting, you also have this 800x1280 resolution in your Teclast. So what about my idea?
I compared the working dmesgs with the non-working dmesgs. 4.6.7 Kernel with fastboot=1 from Laszlo Fiat [drm:intel_plane_atomic_calc_changes] [CRTC:26] has [PLANE:23] with fb 50 [drm:intel_plane_atomic_calc_changes] [PLANE:23] visible 1 -> 1, off 0, on 0, ms 0 [drm:drm_atomic_commit] commiting ffff88007529e400 [drm:intel_update_pipe_config] Updating pipe size 800x1280 -> 800x1280 [drm:intel_connector_check_state] [CONNECTOR:46:DSI-1] [drm:intel_dsi_get_hw_state] 4.6.7 Kernel with fastboot=0 from Laszlo Fiat [drm:intel_modeset_checks] New cdclk calculated to be atomic 266667, actual 266667 [drm:intel_plane_atomic_calc_changes] [CRTC:26] has [PLANE:23] with fb 50 [drm:intel_plane_atomic_calc_changes] [PLANE:23] visible 1 -> 1, off 1, on 1, ms 1 [drm:drm_atomic_commit] commiting ffff880036c03a00 [drm:intel_set_memory_cxsr] memory self-refresh is disabled [drm:intel_set_memory_cxsr] memory self-refresh is disabled [drm:intel_dsi_pre_disable] [drm:intel_disable_pipe] disabling pipe A 4.9.0 Kernel with fastboot=0 from Laszlo Fiat [drm:intel_atomic_check [i915]] New cdclk calculated to be atomic 266667, actual 266667 [drm:intel_plane_atomic_calc_changes [i915]] [CRTC:33:pipe A] has [PLANE:25:primary A] with fb 60 [drm:intel_plane_atomic_calc_changes [i915]] [PLANE:25:primary A] visible 1 -> 1, off 1, on 1, ms 1 [drm:drm_atomic_commit [drm]] commiting ffff963535f88800 [drm:_intel_set_memory_cxsr [i915]] memory self-refresh is disabled (was disabled) [drm:intel_dsi_pre_disable [i915]] [drm:intel_disable_pipe [i915]] disabling pipe A 4.10.0 Kernel with fastboot=0 from me [drm:intel_atomic_check [i915]] New cdclk calculated to be atomic 266667, actual 266667 [drm:intel_plane_atomic_calc_changes [i915]] [CRTC:33:pipe A] has [PLANE:25:primary A] with fb 60 [drm:intel_plane_atomic_calc_changes [i915]] [PLANE:25:primary A] visible 1 -> 1, off 1, on 1, ms 1 [drm:drm_atomic_commit [drm]] commiting ffff97c4b5124c00 [drm:_intel_set_memory_cxsr [i915]] memory self-refresh is disabled (was disabled) [drm:intel_dsi_pre_disable [i915]] [drm:intel_disable_pipe [i915]] disabling pipe A 4.10.0 Kernel with fastboot=1 from me [drm:intel_atomic_check [i915]] New cdclk calculated to be atomic 266667, actual 266667 [drm:intel_plane_atomic_calc_changes [i915]] [CRTC:33:pipe A] has [PLANE:25:primary A] with fb 60 [drm:intel_plane_atomic_calc_changes [i915]] [PLANE:25:primary A] visible 1 -> 1, off 1, on 1, ms 1 [drm:drm_atomic_commit [drm]] commiting ffff8907f567f400 [drm:_intel_set_memory_cxsr [i915]] memory self-refresh is disabled (was disabled) [drm:intel_dsi_pre_disable [i915]] [drm:intel_disable_pipe [i915]] disabling pipe A If you boot with fastboot, the modeset_checks a.k.a atomic_checks didn't happen, but they do now. They cause off, on and ms to change from 0 to 1. And they cause this strange "corretion" of the value 266667 to 266667. So, I think the error is in this check routine. Although, it doesnt't seem to be related with my resolution idea. http://lxr.free-electrons.com/source/drivers/gpu/drm/i915/intel_display.c#L14006 http://lxr.free-electrons.com/source/drivers/gpu/drm/i915/intel_display.c#L13921
I had a look into the regdumps and compared the dmesgs again. The GMBus frequencies are wrongly calculated on our devices. There had already been problems with the GMBus on VLV which have been fixed with this commit: http://o.cs.uvic.ca:20810/perl/cid.pl?cid=24eb2d599b6a2bf7761c00e1959898d1d9240cb5 The regdump of the working 2.6.7 fastboot=1 regdump shows GMBUS frequency binary encoding GMBUSFREQ (0x00180000:0x00006510): 0x0000014e This is 334 in decimal The regdump of the not working 4.9.0 shows GMBUSFREQ (0x00180000:0x00006510): 0x0000010b which is 267 in decimal. The dmesgs show time out events of the GMBus. The wrong frequency could cause them. If you have a look into the commit or the regarding code, you'll see GMBus frequency is calculated with the CDCLK which also showed strange values in the dmesgs as I've already mentioned. By the way, I found this very helpful: https://01.org/sites/default/files/documentation/intel_os_gfx_prm_vol10_-_display_0.pdf working: CZCLK_CDCLK_FREQ_RATIO (0x00180000:0x00006508): 0x000000bb CDCLK Frequency encoding: 1011 CDCLK Divide Ratio: 6 CD Register Encoding (Decimal): 11 SKU200 VCO 800 (MHz): 133 SKU266 VCO 1600 (MHz): 267 SKU333 VCO 2000 (MHz): 333 CD Qual Gen Ratio: 11 not working CZCLK_CDCLK_FREQ_RATIO (0x00180000:0x00006508): 0x000000eb CDCLK Frequency encoding: 1110 CDCLK Divide Ratio: 7.5 CD Register Encoding (Decimal): 14 SKU200 VCO 800 (MHz): 107 SKU266 VCO 1600 (MHz): 213 SKU333 VCO 2000 (MHz): 367 CD Qual Gen Ratio: 14 In both cases, the CZCLK Frequency encoding looks like this: CZCLK Frequency encoding: 1011 CZCLK Divide Ratio: 6 CZ Register Encoding (Decimal): 11 SKU200 VCO 800 (MHt): 133 SKU266 VCO 1600 (MHz): 267 SKU333 VCO 2000 (MHz): 333 CZ Qual Gen Ratio: 11 So, in the working configuration, CZCLK and CDCLK are identical. In the not working configuration, they aren't. GMBus frequency is calculated usind CDCLK. Wrong GMBus frequency means time out means no screen control means no picture. Still, I have no idea, WHY these values are wrong. The next step in the investigation would be to find out why the CDCLK is set to a new value although it shouldn't. At least I think it shouldn't... If someone has an idea that would help or someone finds an error in my conclusions, it would REALLY be appreciated if this someone told me!!!
@Stephan Schorn Thank you for looking into this. CDCLK can be easily set in intel_display.c, in valleyview_calc_cdclk routine. I have tried to fix it to 333333 KHz, but it wasn't enough to get the DSI screen working. I think GMBUS is only related to HDMI/DP, and those are not connected, that is why the error in the dmesgs. I also tried to fix the dsi pll div to the correct value (18d) shown by the intel_reg with fastboot=1, but still no picture. What I try to do is to compile the "ancient" android-ia kernel for Baytrail/Cherryview, it is based on vanilla 3.14.64, plus a quilt (bunch of patches) from https://github.com/01org/ProductionKernelQuilts/blob/master/README.md . This patchset contains everything that is needed to run android on Baytrail/Cherryview. It contains lots of code that never got mainlined (e.g. proper power management ic support). We also need the EFI_MIXED patchset that went into 3.15, because we want a 64 bit kernel that boots on our 32 bit EFI (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7cc3afdf43ffb703db831292f3816d909fd44767 ). And also a nice .config file (enabling lots of options that the patches bring in). I want to try this kernel to see if it can initialize our display.
I am going to do a regdump of a working Windows 10 kernel and compare it to a regdump of a current, not-working intel kernel. That way, I can be sure which register values are the correct-ones. I still think hardsetting a working set of values would lead to a working screen. CDCLK maybe just wasn't enough. Although, I doubt the Windows values will differ from the nomodeset values. Then I could, by debugging the kernel, try to find out when the first of these values gets changed... There should be the problem. Another approach I'm gonna try is to enable fastboot again. I've seen in the code that an "if" that enables fastboot when the kernel parameter is set, got a new condition around 2.7.0. In my opinion, enabling fastboot again should also lead to a working screen. Do you know whether the Android-IA kernel uses fastboot or not?
Created attachment 129075 [details] dmesg of 4.10.0-rc3 drm-tip with i915.fastboot=1 (forced to work by dirty patch), DSI screen works I got it working! At least with a very dirty patch: In intel_display.c, I changed the line FROM if (i915.fastboot && intel_pipe_config_compare(dev, to_intel_crtc_state(crtc->state), pipe_config, true)) { TO if (i915.fastboot) { That way, fastboot can be enabled by kernel parameter i915.fastboot=1 again. Although, if you only add this kernel parameter, the system won't boot, it will hang. I don't know why. You have to remove quiet and splash (or only one of them, I don't know). Then, the system will boot absolutely normal. Acceleration works, rotating the screen works etc. The other problems like the real time clock bug and system freezes persist, but you'll get a working system - for a few minutes. I don't have time to further investigate this stuff this evening, but I hope you'll be happy to know that the screen can be made working! You'll find the dmesg of my successful boot as attachment.
Hans De Goede commited some patches to DRM-TIP regarding MIPI-DSI recently. I've built a DRM-TIP kernel as of 2017-03-02, and with that version the DSI screen initializes properly!!!! No fastboot parameter is needed, and rotation with xrandr works properly for the first time ever. A huge thanks to Hans for making our Baytrail tablets usable as an actual tablet with linux. I'd like to keep this bug open until these patches reach mainline.
(In reply to Laszlo Fiat from comment #19) > Hans De Goede commited some patches to DRM-TIP regarding MIPI-DSI recently. > I've built a DRM-TIP kernel as of 2017-03-02, and with that version the DSI > screen initializes properly!!!! No fastboot parameter is needed, and > rotation with xrandr works properly for the first time ever. Awesome. Thanks for the update. > A huge thanks to Hans for making our Baytrail tablets usable as an actual > tablet with linux. Indeed! > I'd like to keep this bug open until these patches reach mainline. Our policy is to keep bugs open until the fixes have landed in our branches, and they now have. It's not likely they would not hit mainline in the next merge window. Thanks, closing.
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.