Bug 82880

Summary: [BYT dsi] Black screen on modesetting with Dell Venue 8 Pro (version with screen with MIPI panel index = 3)
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: major    
Priority: medium CC: bugzilla, intel-gfx-bugs, jwrdegoede, pbrobinson, rw, zeng.shixin
Version: unspecified   
Hardware: x86 (IA32)   
OS: All   
Whiteboard:
i915 platform: BYT i915 features: display/DSI
Attachments:
Description Flags
boot log with drm.debug=15
none
log of a failed boot with 3.17rc6
none
log of a 'successful' (though very very slow performance) boot with 3.17rc6
none
vblank timed out on i915
none
vblank wait timed out
none
dmesg 4.6.0-rc7 drm-intel-nightly
none
[PATCH] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence
none
[PATCH] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence
none
[PATCH] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence v2 none

Description Adam Williamson 2014-08-20 23:06:00 UTC
Created attachment 104995 [details]
boot log with drm.debug=15

This is kind of a follow-up to https://bugzilla.kernel.org/show_bug.cgi?id=68451 . As of kernel 3.16 support for the problematic Baytrail tablets with DSI displays is supposed to be present in the kernel, and some people have reported success. However, I don't get a working display on my test system, a Dell Venue 8 Pro. The behaviour is clearly different to how it was, but I get a black screen when modesetting kicks in.

I am running an older firmware on my V8P - A04 - as updating requires Windows, and I wiped the Windows install. This may be related to the bug, or not (it's not entirely clear).

I'm attaching a boot log from kernel 3.16.1 with drm.debug=15 set in the kernel parameters. The tablet was booting with no external display attached, only the internal DSI-connected 800x1280 8" panel. The correct resolution seems to be detected, but the screen blanks as soon as KMS kicks in (very early boot messages are visible).
Comment 1 Adam Williamson 2014-08-20 23:06:53 UTC
I'll test with 3.17 when I can, but the current Fedora 3.17 build appears to be completely DOA on the system (fails long before KMS), so I can't test currently.
Comment 2 Jani Nikula 2014-09-11 14:32:39 UTC
(In reply to comment #1)
> I'll test with 3.17 when I can, but the current Fedora 3.17 build appears to
> be completely DOA on the system (fails long before KMS), so I can't test
> currently.

Adam, any luck with 3.17-rc now?

Vijay, here's a candidate display bug for your team to look at. If you want to decline or don't have the bandwidth, please just re-assign using "Reset Assignee to default". Thanks.
Comment 3 Adam Williamson 2014-09-11 17:23:25 UTC
Jani: no, 3.17 is still busted (Jan-Michael Brummer and Bastien Nocera confirm the bug, too): https://bugzilla.kernel.org/show_bug.cgi?id=84241
Comment 4 Adam Williamson 2014-09-27 21:28:41 UTC
So just took another look at this to see if I can figure out what the hell's going on, and I can't, but something odd happened.

I booted (with 3.17rc6) and got a successful accelerated boot - the first time that's ever happened. Performance was *very* slow, though - way slower than with nomodeset.

Then I booted again, and it black screened again.

I grabbed logs from both boots, I'll attach them. I did some dumb grep and cut on the logs so they were vaguely comparable and ran a diff, and the diff is weirdly small, and mostly just things happening in a different order - I just can't see a lot of difference between the 'failure' and 'success' cases. Very strange.
Comment 5 Adam Williamson 2014-09-27 21:29:02 UTC
Created attachment 106968 [details]
log of a failed boot with 3.17rc6
Comment 6 Adam Williamson 2014-09-27 21:30:23 UTC
Created attachment 106969 [details]
log of a 'successful' (though very very slow performance) boot with 3.17rc6

To describe the 'success' case in more detail, every animation that occurred in GDM and GNOME was very slow, but smooth (not jerky). it'd take like 10 seconds for a menu to slowly slide into place. After a bit, it seemed to stop responding entirely, so I had to force power off.
Comment 7 Adam Williamson 2014-11-10 08:22:44 UTC
So I just made a bit of a discovery in testing 3.18 on my V8P.

If I boot normally, or go through the firmware UI (hold down volume *up* key when booting):

* Early boot, all the way from Dell logo to the point where KMS tries to kick in, looks to be in native resolution (800x1280)
* KMS fails as described in this bug, screen blanks when it kicks in

But! If I boot through the boot device menu (hold down volume *down* key when booting):

* Early boot is in some other resolution - lower, and not the right ratio, text is squashed
* KMS works! When it kicks in, the display switches to native resolution (800x1280) and I get a successful boot, all the way into a fully accelerated GNOME session

So not sure if that helps anyone figure out what the bug is, but hey, at least it's a workaround for me for now. I'll attach updated drm.debug logs from 3.18 soon.
Comment 8 Kyvaith 2014-11-12 14:12:24 UTC
This means that now we can change gfxpayload=keep to gfxpayload=text in grub cfg and it should work every time. I'll check in 5 minutes.
Comment 9 Kyvaith 2014-11-12 14:52:17 UTC
I'm sorry, but your solution does not work for me. I mean, there is a difference - now, I do not have a black screen, I see loads plymouth and Gnome, but the screen is like a broken TV - flying lines.
Comment 10 Adam Williamson 2014-11-12 15:41:29 UTC
Are you using a Venue 8 Pro? If not, what device? Also, make sure you drop any 'video=' parameter from the command line (that you might have had for the old hacky video support from 3.14 and earlier).
Comment 11 Kyvaith 2014-11-12 16:51:19 UTC
Yes, it's Dell Venue 8 PRO. I've tried with 08 Bios and now I'm on 09 Bios with the same issue. And I've tried with grub.cfg you provided in ISO.
Comment 12 Kyvaith 2014-11-12 17:39:08 UTC
Have you compiled kernel with this? https://bugzilla.kernel.org/show_bug.cgi?id=68291#c46
Comment 13 Evgheni Dereveanchin 2014-12-21 22:15:05 UTC
I am also experiencing this behavior on a 3.18 kernel built by Adam. Will attach the trace to this bz.

Adam, the "slow boot" in your case may be caused by this:

Sep 27 07:05:54 fedlet.happyassassin.net kernel: Clocksource tsc unstable (delta = 64072097 ns)
Sep 27 07:05:54 fedlet.happyassassin.net kernel: Switched to clocksource refined-jiffies

In my case the clocksource was also switching to refined-jiffies which made huge timing issues, i worked around it by sticking with tsc (added clocksource=tsc cmdline) because in my case hpet is not available, probably due to buggy BIOS.
Comment 14 Evgheni Dereveanchin 2014-12-21 22:16:27 UTC
Created attachment 111132 [details]
vblank timed out on i915
Comment 15 zeng.shixin 2015-02-15 15:00:03 UTC
Created attachment 113510 [details]
vblank wait timed out
Comment 16 zeng.shixin 2015-02-15 15:01:04 UTC
Comment on attachment 113510 [details]
vblank wait timed out

My WinBook TW802/TW802 probably hit the same bug.
Comment 17 Jesse Barnes 2015-04-02 18:11:13 UTC
*** Bug 89573 has been marked as a duplicate of this bug. ***
Comment 18 Jani Nikula 2015-10-23 10:00:20 UTC
I'm being optimistic and presume we've fixed this upstream. Please reopen if the problem persists with latest kernels.
Comment 19 Vijay Purushothaman 2015-10-23 10:00:56 UTC
On Vacation during WW42 (no email access) and on business trip during WW43 (limited mail access). Please contact:

Ganesh S T for Display GEN TR (GEN11, 11.5, 12) queries
Megha Aggarwal & Arun Murthy for CHT power optimization TF queries
Ganesh S T for VBT spec review approvals & queries

I will be back in office during WW44.1.

Thanks,
Vijay
Comment 20 Adam Williamson 2015-10-23 16:20:56 UTC
It still behaves exactly as per #c8 at least in kernel 4.1, which is the last I checked. I'll get around to building a 4.2 Fedlet image some time...
Comment 21 Bastien Nocera 2015-10-23 17:26:39 UTC
(In reply to Adam Williamson from comment #20)
> It still behaves exactly as per #c8 at least in kernel 4.1, which is the
> last I checked. I'll get around to building a 4.2 Fedlet image some time...

I have regular rc kernels here:
http://copr.fedoraproject.org/coprs/hadess/32bit-boot/builds/
with BayTrail and CherryTrail patches

And you can update existing images, if you've added the persistent overlay like so:
https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB
(look for Kernel Updates at the bottom)
Comment 22 Rene Wagner 2015-10-23 21:12:10 UTC
Is an updated user space also required? If so, which Xorg server/driver versions specifically? How about mesa? I haven't used my tablet in a while so it's still on Debian Jessie with the exception of xserver-xorg-video-intel-2.99.917 from experimental as of March this year.

Cheers,
Rene
Comment 23 Jani Nikula 2015-10-26 14:02:23 UTC
I don't imagine new userspace being required; however please go for latest upstream kernel, preferably v4.3-rc7.
Comment 24 bs666_1 2015-11-06 02:43:47 UTC
On my tablet, a Winbook with a Atom Z3735G cpu, the screen goes blank when the Intel DRM driver is loaded but no issues with modesetting disabled with kernel 4.3-rc7.  So it seems this problem still exists.
Comment 25 Rene Wagner 2015-12-20 20:43:43 UTC
I'm sorry it took me so long to test this. With my Venue 8 Pro 3845, I'm afraid the problem persists with 4.4.0-rc5-amd64 version 4.4~rc5-1~exp1 from Debian experimental. Unless I pass 'nomodeset' on the kernel command line I still get a black screen when X starts. Reopening as requested in Comment 19.
Comment 26 Jani Nikula 2016-05-11 13:19:33 UTC
So there's tons of DSI related fixes in drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel. Please try that and report back.
Comment 27 bs666_1 2016-05-14 02:07:27 UTC
Still broken with same symptom in 4.6.0-rc7 drm-intel-nightly as of 2016-05-12.
Comment 28 Jani Nikula 2016-05-16 08:07:36 UTC
(In reply to bs666_1 from comment #27)
> Still broken with same symptom in 4.6.0-rc7 drm-intel-nightly as of
> 2016-05-12.

Care to attach dmesg with drm.debug=14 module parameter set as well please?
Comment 29 bs666_1 2016-05-17 00:36:40 UTC
Created attachment 123802 [details]
dmesg 4.6.0-rc7 drm-intel-nightly

Added dmesg
Comment 30 Ville Syrjala 2016-05-17 07:43:42 UTC
(In reply to bs666_1 from comment #29)
> Created attachment 123802 [details]
> dmesg 4.6.0-rc7 drm-intel-nightly
> 
> Added dmesg

Unrelated to this bug, but I noticed in your dmesg that your BYT is running with a 333 MHz CZ clock. I've been looking for one of those to confirm how the minimum GPU frequency behaves.

[    5.328217] [drm:intel_update_czclk] CZ clock rate: 333333 kHz
[    5.462363] [drm:vlv_init_gpll_ref_freq] GPLL reference freq: 20833 kHz
[    5.466068] [drm:valleyview_init_gt_powersave] DDR speed: 1333 MHz
[    5.470064] [drm:valleyview_init_gt_powersave] max GPU freq: 646 MHz (214)
[    5.478082] [drm:valleyview_init_gt_powersave] RPe GPU freq: 646 MHz (214)
[    5.478104] [drm:valleyview_init_gt_powersave] RP1(Guar Freq) GPU freq: 312 MHz (198)
[    5.478121] [drm:valleyview_init_gt_powersave] min GPU freq: 187 MHz (192)

Can you do a 'grep . /sys/class/drm/card0/gt_*' and
'intel_reg read punit:0xd3 punit:0xd4 punit:0xd8 nc:0x1c nc:0x30 nc:0x34'
when the GPU is idle?
Comment 31 bs666_1 2016-05-18 00:28:32 UTC
I can't really be certain the GPU was idle as the screen was blank but the values were stable and I'm fairly sure it was at a fbcon vt.

$ sudo ./intel_reg read punit:0xd3 punit:0xd4 punit:0xd8 nc:0x1c nc:0x30 nc:0x34 --spec=registers
        punit:0x000000d3 (0x04:0x000000d3): 0x000000bf
        punit:0x000000d4 (0x04:0x000000d4): 0x000000bf
        punit:0x000000d8 (0x04:0x000000d8): 0x0000c0d0
           nc:0x0000001c (0x11:0x0000001c): 0xbbfe36b4
           nc:0x00000030 (0x11:0x00000030): 0xb378ad39
           nc:0x00000034 (0x11:0x00000034): 0xfc0eb636
$ sudo grep . /sys/class/drm/card0/gt_*
/sys/class/drm/card0/gt_act_freq_mhz:187
/sys/class/drm/card0/gt_cur_freq_mhz:167
/sys/class/drm/card0/gt_max_freq_mhz:645
/sys/class/drm/card0/gt_min_freq_mhz:167
/sys/class/drm/card0/gt_RP0_freq_mhz:645
/sys/class/drm/card0/gt_RP1_freq_mhz:312
/sys/class/drm/card0/gt_RPn_freq_mhz:167
Comment 32 Ville Syrjala 2016-05-18 07:31:58 UTC
(In reply to bs666_1 from comment #31)
> I can't really be certain the GPU was idle as the screen was blank but the
> values were stable and I'm fairly sure it was at a fbcon vt.
> 
> $ sudo ./intel_reg read punit:0xd3 punit:0xd4 punit:0xd8 nc:0x1c nc:0x30
> nc:0x34 --spec=registers
>         punit:0x000000d3 (0x04:0x000000d3): 0x000000bf
>         punit:0x000000d4 (0x04:0x000000d4): 0x000000bf
>         punit:0x000000d8 (0x04:0x000000d8): 0x0000c0d0
>            nc:0x0000001c (0x11:0x0000001c): 0xbbfe36b4
>            nc:0x00000030 (0x11:0x00000030): 0xb378ad39
>            nc:0x00000034 (0x11:0x00000034): 0xfc0eb636
> $ sudo grep . /sys/class/drm/card0/gt_*
> /sys/class/drm/card0/gt_act_freq_mhz:187
> /sys/class/drm/card0/gt_cur_freq_mhz:167
> /sys/class/drm/card0/gt_max_freq_mhz:645
> /sys/class/drm/card0/gt_min_freq_mhz:167
> /sys/class/drm/card0/gt_RP0_freq_mhz:645
> /sys/class/drm/card0/gt_RP1_freq_mhz:312
> /sys/class/drm/card0/gt_RPn_freq_mhz:167

I take it that was with 4.4 or earlier kernel? Anyway, based on those the register values it does look like our current code is in fact correct also for the cz=333 case.
Comment 33 Jan Brøndum Johansson 2016-10-22 12:40:19 UTC
Hi, did you ever get this problem solved?

I have the same on ODYS WinTab 8 with Intel Atom Baytrail-T Z3735E CPU.

Any(tried many different distro including all ubuntu, slacko(and other puppy), android, phoenix, remix, x86) linux boots, then end up in black screen - If I add nomodeset to grub.cfg on the LiveUSB(made with Unetbootin) then it boots into desktop - but then I can't change resolution or rotation. If I remove nomodeset and add i915.modeset=0 then its the same - still can't rotate or change resolution.

This is on 16.04 Linuxium 64bit, Unity, gnome, xubuntu.

On Kubuntu 16.10 linuxium 64bit resolution are available but not working - rotation is there but not working either. This doesn't work on Unity, gnome, xubuntu - I have not tried Lubuntu or MATE.

My thoughts is that the screen/display/monitor/panel or what you will call it, is not getting discovered correctly by the kernel. It is only found as default.

It is not possible to get 

I worked on this problem and some other ones with this tablet(sound, wi-fi bluetooth), for over 2½ month. Bluetooth and wi-fi works in linuxium - sound do not.

My effort on getting slacko to work on this can be followed below, that page also have hardware list:

http://www.murga-linux.com/puppy/viewtopic.php?t=108295&sid=6a8c4349d9a2e5799295a020318d3185

My effort on getting linuxium to work:
https://linuxiumcomau.blogspot.com/2016/10/running-ubuntu-on-intel-bay-trail-and.html?showComment=1477057433854#c5416952429820429838
Comment 34 Jari Tahvanainen 2017-03-29 13:05:02 UTC
Jan - I would propose that you file new bug for your problem if it still persist.
bs666_1@hotmail.com - please check if the problem still persist with the latest kernel (preferable from drm-tip).
Comment 35 Jani Nikula 2017-03-29 13:38:42 UTC
Plenty of DSI fixes have landed in drm-tip branch of https://cgit.freedesktop.org/drm/drm-tip lately. Please use that.

There's the remaining bug 96571 that requires specific kernel config options, be sure to use them.
Comment 36 bs666_1 2017-04-07 02:10:18 UTC
I don't have time to do any real testing but the screen doesn't go black and I can interact with the console with modesetting enabled so it looks very promising.  My current linux install on the machine is very old and X doesn't even start so I'd have to upgrade it to be sure.
Comment 37 bs666_1 2017-05-05 19:32:35 UTC
Everything seems to work properly now KMS, DRM, X and Wayland with the drm-tip tree.  Think bug can be closed.
Comment 38 russianneuromancer 2017-06-16 05:49:18 UTC
Adam, Dell's exe files with BIOS update can be run from Windows and FreeDOS. You also can find "BIOS Updater" item in boot menu, run it, select this exe, and BIOS will get updated.

As for DV8P, display of DV8P5830 works since https://patchwork.kernel.org/patch/9458597/ got merged, and display of DV8P58305855 works since Linux 4.12rc1. This bug can be closed.
Comment 39 Hans de Goede 2018-01-25 11:09:13 UTC
I don't think this has anything to do with the firmware version on the Dell Venue 8 5130. Mine is working fine, but as reported e.g. also in bug 101205 (which is really about Pipo devices) their are 2 different versions of the Dell Venue 8 5130. With different panels, the working one has:

Jan 01 01:42:14 phone kernel: [drm:intel_bios_init [i915]] Found MIPI Config block, panel index = 5
Jan 01 01:42:14 phone kernel: [drm:intel_bios_init [i915]] No MIPI Sequence found, parsing complete

Where as the broken one has:

Mar 10 10:10:24 phone kernel: [drm:intel_bios_init [i915]] Found MIPI Config block, panel index = 3
Mar 10 10:10:24 phone kernel: [drm:intel_bios_init [i915]] Found MIPI sequence block v1

Note different panel indexes and if you look at the logs in bug 101205, which contains logs for both a good and a bad unit then you will also see different timings.

Jan Brummer has send me a Dell Venue 8 5130 with the trouble-some screen so that I could take a shot at fixing this.

I've actually managed to find the problem and I've a patch ready, but it is not pretty...

In the mean time lets open this bug for proper tracking of this until the problem is fixed on units with a panel index of 3.
Comment 40 Hans de Goede 2018-01-25 11:24:01 UTC
Created attachment 136952 [details] [review]
[PATCH] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence

Here is the patch for this which I intend to submit upstream soon.
Comment 41 Hans de Goede 2018-01-25 13:33:50 UTC
Created attachment 136958 [details] [review]
[PATCH] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence
Comment 42 Hans de Goede 2018-01-26 08:40:46 UTC
Created attachment 136969 [details] [review]
[PATCH] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence v2

Here is a new version of the patch, with some changes because of upstream review, functionally it should be unchanged.
Comment 43 hexdump 2018-01-27 11:25:31 UTC
i can confirm, that it fixes the problem on my 5830 dell venue 8 pro, which had the blank screen syndrome before - thaks a lot! i was hoping, that maybe it helps too with my trekstor twin 10.1 from https://bugs.freedesktop.org/show_bug.cgi?id=104807 which has very similar symptoms, but sadly it does not fix the problem there ... most probably the reason for the blank screen there is a different one.
Comment 44 Hans de Goede 2018-01-28 16:28:40 UTC
(In reply to hexdump from comment #43)
> i can confirm, that it fixes the problem on my 5830 dell venue 8 pro, which
> had the blank screen syndrome before - thaks a lot!

Thank you for testing.

> i was hoping, that maybe
> it helps too with my trekstor twin 10.1 from
> https://bugs.freedesktop.org/show_bug.cgi?id=104807 which has very similar
> symptoms, but sadly it does not fix the problem there ... most probably the
> reason for the blank screen there is a different one.

Looking at the drm.debug log you've attached there that indeed is a different problem, the MIPI sequences there do have a de-assert sequence.
Comment 45 Jani Nikula 2018-02-16 08:50:45 UTC
Presumed fixed by

commit ee622fe757f6de612dad0f01805eea815a5b3025
Author: Hans de Goede <j.w.r.degoede@gmail.com>
Date:   Wed Feb 14 09:21:51 2018 +0100

    drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence v3

in drm-fixes, headed to v4.16-rc2.

Thanks for the report, closing, please reopen if the problem persists with that.

Thanks for fixing this, Hans!

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.