Bug 96996 - [BYT][VLV] No picture on DSI display after DRM loads on Teclast X80H tablet
Summary: [BYT][VLV] No picture on DSI display after DRM loads on Teclast X80H tablet
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-19 17:14 UTC by Laszlo Fiat
Modified: 2017-03-07 13:04 UTC (History)
3 users (show)

See Also:
i915 platform: BYT
i915 features: display/DSI


Attachments
Full dmesg (119.98 KB, text/plain)
2016-07-19 17:14 UTC, Laszlo Fiat
no flags Details
Dmesg of drm-intel-nightly-2016-09-20 (157.81 KB, text/plain)
2016-09-24 12:29 UTC, Laszlo Fiat
no flags Details
dmesg of 4.6.7 with i915.fastboot=1, DSI screen works (413.59 KB, text/plain)
2016-10-10 17:11 UTC, Laszlo Fiat
no flags Details
dmesg of 4.6.7 with no fastboot parameter, DSI screen goes blank (145.16 KB, text/plain)
2016-10-10 18:00 UTC, Laszlo Fiat
no flags Details
dmesg of 4.8.9 still no picture on DSI (129.79 KB, text/plain)
2016-11-23 08:59 UTC, Laszlo Fiat
no flags Details
Dmesg of drm-tip 2016-12-22, no WARNING, but still blank screen (141.10 KB, text/plain)
2016-12-26 10:20 UTC, Laszlo Fiat
no flags Details
intel_reg dump output of kernel 4.6.7 with fastboot=1 where the dsi screen is working (51.48 KB, text/plain)
2016-12-26 12:45 UTC, Laszlo Fiat
no flags Details
intel_reg dump output of kernel 4.9.0 with fastboot=0 where dsi screen is not working (51.48 KB, text/plain)
2016-12-26 12:48 UTC, Laszlo Fiat
no flags Details
dmesg of 4.10.0-994 drm-intel-nightly (187.35 KB, text/plain)
2017-01-05 23:07 UTC, Stephan Schorn
no flags Details
dmesg of 4.10.0-rc3 drm-tip with i915.fastboot=1 (forced to work by dirty patch), DSI screen works (97.70 KB, text/plain)
2017-01-20 19:27 UTC, Stephan Schorn
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Laszlo Fiat 2016-07-19 17:14:59 UTC
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.
Comment 1 Laszlo Fiat 2016-07-19 17:46:05 UTC
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
Comment 2 Zhaofeng Li 2016-09-03 07:35:12 UTC
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.
Comment 3 Laszlo Fiat 2016-09-24 12:29:57 UTC
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?
Comment 4 Laszlo Fiat 2016-10-10 17:11:32 UTC
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.
Comment 5 Laszlo Fiat 2016-10-10 18:00:02 UTC
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)
Comment 6 Laszlo Fiat 2016-11-23 08:59:05 UTC
Created attachment 128159 [details]
dmesg of 4.8.9 still no picture on DSI
Comment 7 Ville Syrjala 2016-12-22 15:17:49 UTC
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.
Comment 8 Laszlo Fiat 2016-12-26 10:20:57 UTC
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
Comment 9 Laszlo Fiat 2016-12-26 12:45:25 UTC
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.
Comment 10 Laszlo Fiat 2016-12-26 12:48:03 UTC
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.
Comment 11 Stephan Schorn 2017-01-05 23:07:39 UTC
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
Comment 12 Stephan Schorn 2017-01-10 03:49:03 UTC
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...
Comment 13 Stephan Schorn 2017-01-10 03:52:02 UTC
Should have read your dmesgs before posting, you also have this 800x1280 resolution in your Teclast.

So what about my idea?
Comment 14 Stephan Schorn 2017-01-11 03:49:09 UTC
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
Comment 15 Stephan Schorn 2017-01-17 00:02:32 UTC
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!!!
Comment 16 Laszlo Fiat 2017-01-17 18:20:17 UTC
@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.
Comment 17 Stephan Schorn 2017-01-17 20:04:07 UTC
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?
Comment 18 Stephan Schorn 2017-01-20 19:27:24 UTC
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.
Comment 19 Laszlo Fiat 2017-03-03 17:50:31 UTC
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.
Comment 20 Jani Nikula 2017-03-07 13:04:01 UTC
(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.