Bug 101205 - [i915][BYT] Blank screen on DSI panel
Summary: [i915][BYT] Blank screen on DSI panel
Status: CLOSED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-26 16:58 UTC by Innocent Bystander
Modified: 2018-04-23 10:02 UTC (History)
4 users (show)

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


Attachments
Syslog for the faulty Pipo X8S (Z3735F) unit (138.08 KB, text/x-log)
2017-05-26 16:58 UTC, Innocent Bystander
no flags Details
Syslog for the good Pipo X8 (Z3736F) unit (149.42 KB, text/x-log)
2017-05-26 16:59 UTC, Innocent Bystander
no flags Details
VBT of the good Pipo X8 (7.00 KB, application/octet-stream)
2017-05-31 18:16 UTC, Innocent Bystander
no flags Details
VBT of the faulty Pipo X8S (7.00 KB, application/octet-stream)
2017-05-31 18:39 UTC, Innocent Bystander
no flags Details
Syslog for the "good" DV8P unit (109.15 KB, text/x-log)
2017-06-22 19:53 UTC, Innocent Bystander
no flags Details
VBT of the "good" DV8P unit (4.84 KB, text/plain)
2017-06-22 19:54 UTC, Innocent Bystander
no flags Details
Syslog for the "fail" DV8P unit (116.71 KB, text/x-log)
2017-06-22 19:56 UTC, Innocent Bystander
no flags Details
VBT of the "fail" DV8P unit (14.33 KB, text/plain)
2017-06-22 19:56 UTC, Innocent Bystander
no flags Details
Boot log from my DV8P (211.97 KB, text/plain)
2017-06-26 19:19 UTC, Parker Reed
no flags Details
Another failing DV8P VBT (16.30 KB, text/plain)
2017-06-26 20:55 UTC, Parker Reed
no flags Details
Screenshot on "working" DV8P (217.79 KB, image/png)
2017-06-27 03:00 UTC, Parker Reed
no flags Details
Kernel log with "hack" (492.00 KB, application/gzip)
2017-06-27 03:44 UTC, Parker Reed
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Innocent Bystander 2017-05-26 16:58:38 UTC
Created attachment 131526 [details]
Syslog for the faulty Pipo X8S (Z3735F) unit

I have two very similar Baytrail devices: Pipo X8 and Pipo X8S.

The former (X8) is based on Z3736F and runs fine. The latter (X8S) is based on Z3735F and gets a blank screen once the i915 driver is loaded.

Both units run identical set up software-wise:

distro: Gentoo
kernel: drm-tip branch (713f8e of 16 May)
xorg: 1.19.2
xf86-video-intel: 2.99.917_p20170216

Comparing the logs I can see the faulty unit seems to be missing some MIPI initialization commands. Here is the diff of the logs between the good unit (left) and the faulty one (right):

https://www.diffchecker.com/tv4c7jTl

The HDMI output on the faulty unit works fine. Attached are the logs for both the good and the faulty units with drm.debug=0x1e
Comment 1 Innocent Bystander 2017-05-26 16:59:29 UTC
Created attachment 131527 [details]
Syslog for the good Pipo X8 (Z3736F) unit
Comment 2 Innocent Bystander 2017-05-26 17:02:36 UTC
The backlight is working fine on both units with drm-tip branch.

I've tried kernel 4.11.1 with same results (except the backlight does not work on either of the units).
Comment 3 Innocent Bystander 2017-05-26 17:06:39 UTC
libdrm: 2.4.75
mesa: 13.0.5

I will try later versions to see if it makes a difference.
Comment 4 Innocent Bystander 2017-05-26 18:13:36 UTC
(In reply to Innocent Bystander from comment #3)
> libdrm: 2.4.75
> mesa: 13.0.5
> 
> I will try later versions to see if it makes a difference.

Never mind, I realized this has nothing to do with the issue. The screen goes blank as soon as the i915 driver is loaded, even without the X server.
Comment 5 Innocent Bystander 2017-05-27 02:11:41 UTC
Sprinkling a few printks in the kernel I've discovered that in the file `intel_bios.c` inside the function `parse_mipi_sequence()` a call to `find_panel_sequence_block()` here:

https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/i915/intel_bios.c#n984

returns 2-byte long sequence block with the the first seq_id set to 0 (MIPI_SEQ_END).

This causes `intel_dsi_vbt_exec_sequence()` in `intel_dsi_vbt.c` to simply return here:

https://cgit.freedesktop.org/drm/drm-tip/tree/drivers/gpu/drm/i915/intel_dsi_vbt.c#n429

I am really just shooting in the dark here, as I've no clue what all of this means. My guess is these are some sort of initialization sequences for the MIPI panel.

On the other hand, on the working unit the size of the sequence block is 1350 and it contains seq_ids: 1, 5, 2, 3 and 4, which would be MIPI_SEQ_{DEASSERT_RESET,ASSERT_RESET,INIT_OTP,DISPLAY_ON,DISPLAY_OFF}.

If somebody could point me in the right direction, I would very much appreciate that.
Comment 6 Innocent Bystander 2017-05-27 02:18:22 UTC
Tried dumping the bios with:

echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom
cat /sys/devices/pci0000:00/0000:00:02.0/rom

and with:

intel_bios_dumper

but all's I get is "Input/output error" and the following in the syslog:

... i915 0000:00:02.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xf581
Comment 7 Innocent Bystander 2017-05-27 03:05:23 UTC
Sprinkled a few more printks here and there. Discovered an interesting thing in the function `find_section()` here:

http://elixir.free-electrons.com/linux/v4.6/source/drivers/gpu/drm/i915/intel_bios.c#L78

The faulty unit (X8S) reports section 53 (BDB_MIPI_SEQUENCE) at offset 4650 with length of 7! Whereas the good unit (X8) reports the same offset, but the length of 1355. All other sections are identical.

Sounds like a firmware bug?...
Comment 8 Innocent Bystander 2017-05-27 17:04:34 UTC
(In reply to Innocent Bystander from comment #7)
> Sprinkled a few more printks here and there. Discovered an interesting thing
> in the function `find_section()` here:
> 
> http://elixir.free-electrons.com/linux/v4.6/source/drivers/gpu/drm/i915/
> intel_bios.c#L78
> 
> The faulty unit (X8S) reports section 53 (BDB_MIPI_SEQUENCE) at offset 4650
> with length of 7! Whereas the good unit (X8) reports the same offset, but
> the length of 1355. All other sections are identical.
> 
> Sounds like a firmware bug?...

Actually not necessarily. It seems it's simply missing from the VBT.

How does Windows figure out how to deal with the panel then? Is there a fallback sequences that can be used?
Comment 9 Innocent Bystander 2017-05-27 20:02:39 UTC
So, I've extracted contents of the sequence block returned by `find_panel_sequence_block()` which contains all MIPI sequences on the good unit.

Added it to the kernel as a static u8[] and made the various `dev_priv->vbt.dsi.sequence[...]` point to it.

I was now able to see the missing mipi_exec_... commands in the log. Sadly, this did not make any difference.

It looks like I am on a completely wrong path.

Can't really think of what to do next... If anybody is reading this, please chime in. I could really use some pointers here
Comment 10 Jani Nikula 2017-05-31 09:24:59 UTC
The VBT with the sequences is available at /sys/kernel/debug/dri/0/i915_vbt. Please attach it for both working and non-working machines. You can use intel_vbt_decode tool from IGT to decode them. Not sure if the decoder supports all the little details of the DSI sequences though.
Comment 11 Jani Nikula 2017-05-31 09:26:12 UTC
Btw there are no guarantees the displays are the same.
Comment 12 Jani Nikula 2017-05-31 09:31:10 UTC
(In reply to Jani Nikula from comment #11)
> Btw there are no guarantees the displays are the same.

Based on the logs looks like they have way different timings.
Comment 13 Innocent Bystander 2017-05-31 18:16:01 UTC
Created attachment 131614 [details]
VBT of the good Pipo X8
Comment 14 Innocent Bystander 2017-05-31 18:39:55 UTC
Created attachment 131615 [details]
VBT of the faulty Pipo X8S
Comment 15 Innocent Bystander 2017-05-31 18:44:54 UTC
Jani, I've attached VBTs for both devices. Here is also diff of outputs for the intel_bios_reader:

https://www.diffchecker.com/VBiyL6tM

The panels do seem to have different timings... But where does it take us?
Comment 16 Innocent Bystander 2017-05-31 19:33:51 UTC
Perhaps an irrelevant comment, by these boxen came with Android 4.4, which (obviously) works
Comment 17 Innocent Bystander 2017-06-01 00:38:35 UTC
(In reply to Jani Nikula from comment #11)
> Btw there are no guarantees the displays are the same.

I took both units apart and they do indeed have completely different panels.

The working unit has Innolux N070ICN-GB1 panel:

http://www.panelook.com/N070ICN-GB1_Innolux_7.0_LCM_overview_20644.html

The faulty unit has Chunghwa CLAA070WP0B panel:

http://www.cptt.com.tw/index.php?option=com_wrapper&Itemid=201
http://bit.ly/2rcY247
Comment 18 Jani Nikula 2017-06-01 08:06:21 UTC
The VBT for the non-working Pipo X8S does not seem to have any real contents in the MIPI DSI sequence block, which is surprising. I can think of two scenarios here:

1) You've changed the boot mode when installing. It's surprisingly common that the VBT is different for UEFI vs. legacy boot. Though this is usually more of an issue on Windows based machines, not sure about Android. (But I guess this is originally dual boot?)

2) The vendor failed to make the panel work using the VBT sequences, and opted to hack it all in the driver. It's usual that the vendor kernels have quite a bit of delta from upstream. You could try to find the sources for the kernels used in both devices, and compare.

In any case effectively reverse engineering this kind of non-standard, typically one-off products is not a priority in the upstream driver. If it works, great. If you figure out how to make it work, and contribute upstream, great. But we won't go out of our way to fix this.
Comment 19 Innocent Bystander 2017-06-01 15:02:52 UTC
(In reply to Jani Nikula from comment #18)
> The VBT for the non-working Pipo X8S does not seem to have any real contents
> in the MIPI DSI sequence block, which is surprising. I can think of two
> scenarios here:
> 
> 1) You've changed the boot mode when installing. It's surprisingly common
> that the VBT is different for UEFI vs. legacy boot. Though this is usually
> more of an issue on Windows based machines, not sure about Android. (But I
> guess this is originally dual boot?)

The unit only has UEFI mode -- no legacy boot. I kept it as-is and I am booting in UEFI using GRUB. 

It originally came with Windows and Android dual boot option.

> 2) The vendor failed to make the panel work using the VBT sequences, and
> opted to hack it all in the driver. It's usual that the vendor kernels have
> quite a bit of delta from upstream. You could try to find the sources for
> the kernels used in both devices, and compare.

I don't think that's the case. On Windows they are running Intel HD Graphics driver.

On Android side itsa anzhen4_mrd8_w base, which I believe is a base for Intel BayTrail-T devices. I installed a terminal app and discovered that they are running kernel 3.10.20 and using i915 driver.

Sadly I have failed horribly trying to compile an Android kernel.

> In any case effectively reverse engineering this kind of non-standard,
> typically one-off products is not a priority in the upstream driver. If it
> works, great. If you figure out how to make it work, and contribute
> upstream, great. But we won't go out of our way to fix this.

BTW, I've had exact same phenomena with some of the Dell Venue 8 Pro tablets. They would just go blank as soon as the i915 driver loaded. Similarly, they've worked totally fine in Windows with Intel HD Graphics driver.

I've abandoned them in favor of these units... And now I am back to square zero.
Comment 20 Jani Nikula 2017-06-02 09:13:57 UTC
Whatever the Windows driver does is not applicable to the Linux driver. Among other things, IIUC they can provide the VBT in .INF files or something like that too.

Seeing an "i915" driver does not mean that it's the upstream i915 driver. It may have been backported, forward ported, and in general modified in various ways.
Comment 21 Innocent Bystander 2017-06-08 14:15:14 UTC
One thing I noticed is that Windows does not seem to reset the screen. It simply takes over the screen from EFI and starts drawing on top of it.

On the other hand, the Linux driver seems to reset the panel, after which point the screen remains blank.

Is it possible to tell the driver not to reset the panel?
Comment 22 russianneuromancer 2017-06-16 05:52:22 UTC
If you still have access to yours Dell Venue 8 Pro I advice you try Linux 4.12 on it: https://bugs.freedesktop.org/show_bug.cgi?id=82880#c38
Comment 23 Innocent Bystander 2017-06-22 19:43:35 UTC
(In reply to russianneuromancer from comment #22)
> If you still have access to yours Dell Venue 8 Pro I advice you try Linux
> 4.12 on it: https://bugs.freedesktop.org/show_bug.cgi?id=82880#c38

Doesn't work for me.

At the time when I was planning to use DV8P I was able to get around 20 units working and had 4 duds (screen turned blank as soon as i915 loaded). This was with kernel 4.2.8.

By "working" I mean I had a picture, but no backlight control with the backlight being stuck at 100% (which suited me).

When I switched to the Pipo units, I started using drm-tip at commit 62b63dcce03c09d31c1f297af4b6245a5159d923 of 2017-05-16, which also includes the patch you've mentioned.

So, I just grabbed a working (good) and non-working (fail) DV8P units and loaded the above kernel onto them and both units go blank as soon as i915 loads. I do have control of the backlight now. But no picture.

I will upload logs and VBTs for both. The funny thing is that the unit that used work with 4.2.8 is also missing MIPI sequences in VBT.
Comment 24 Innocent Bystander 2017-06-22 19:53:36 UTC
Created attachment 132145 [details]
Syslog for the "good" DV8P unit

By "good" I mean it used to work with 4.2.8 but still goes blank with 4.12 (drm-tip)
Comment 25 Innocent Bystander 2017-06-22 19:54:33 UTC
Created attachment 132146 [details]
VBT of the "good" DV8P unit
Comment 26 Innocent Bystander 2017-06-22 19:56:17 UTC
Created attachment 132147 [details]
Syslog for the "fail" DV8P unit

By "fail" I mean it used to go blank with 4.2.8 and still goes blank with 4.12 (drm-tip)
Comment 27 Innocent Bystander 2017-06-22 19:56:44 UTC
Created attachment 132148 [details]
VBT of the "fail" DV8P unit
Comment 28 Innocent Bystander 2017-06-22 20:03:23 UTC
I also found this interesting bit: https://lists.freedesktop.org/archives/intel-gfx/2011-October/012811.html. An effort by Keith Packard to create flicker-free boot. But it doesn't look like anything materialized from that.
Comment 29 Parker Reed 2017-06-26 19:18:06 UTC
Adding another failed DV8P unit. Used Hans de Goede's config along with Linux GIT.

Where do I pull the VBT info from?
Comment 30 Parker Reed 2017-06-26 19:19:11 UTC
Created attachment 132264 [details]
Boot log from my DV8P

With debug and drm.debug enabled
Comment 31 Innocent Bystander 2017-06-26 20:42:40 UTC
(In reply to Parker Reed from comment #29)
> Adding another failed DV8P unit. Used Hans de Goede's config along with
> Linux GIT.
> 
> Where do I pull the VBT info from?

You can access VBT through: /sys/kernel/debug/dri/0/i915_vbt

Use intel_read_bios from intel-gpu-tools to decode it.
Comment 32 Parker Reed 2017-06-26 20:55:44 UTC
Created attachment 132267 [details]
Another failing DV8P VBT

Here's mine. Did a diff with the previously posted VBT and there are quite a few differences. Pulled this while booted into the "failed" state (SSH)
Comment 33 Innocent Bystander 2017-06-26 21:15:05 UTC
Parker, the differences could be because I am using an older version of intel-gpu-tools.

The MIPI sequences (block 53) seems to be identical on both units: https://www.diffchecker.com/98E7NTrG
Comment 34 Parker Reed 2017-06-27 03:00:40 UTC
Created attachment 132269 [details]
Screenshot on "working" DV8P

So after doing some digging I ran across this issue https://bugs.freedesktop.org/show_bug.cgi?id=100356

Having all else fail, I figured I'd try the "hacky" method. Already had drm-tip cloned and compiled, so I just made that one change and recompiled. Installed and added the fastboot to my kernel args. It actually comes up and KMS works. As noted in the issue, an xrandr rotate does kill the output, but mine does show DSI info instead of "UNKNOWN"
Comment 35 Parker Reed 2017-06-27 03:44:09 UTC
Created attachment 132271 [details]
Kernel log with "hack"

So I decided to try my normal workflow of GDM plus Gnome. The kernel starts to complain a lot... (40MB log) Bunch of drm.debug output/ACPI errors. Figured I'd post this in case it helps lead to something.
Comment 36 Ville Syrjala 2017-06-27 08:40:20 UTC
(In reply to Parker Reed from comment #32)
> Created attachment 132267 [details]
> Another failing DV8P VBT
> 
> Here's mine. Did a diff with the previously posted VBT and there are quite a
> few differences. Pulled this while booted into the "failed" state (SSH)

Please always attach these kinds of dumps as raw binary. That way we won't have any risk of having invalid data due to potential bugs in the decoder.
Comment 37 Jani Nikula 2017-07-05 10:08:58 UTC
(In reply to Innocent Bystander from comment #21)
> One thing I noticed is that Windows does not seem to reset the screen. It
> simply takes over the screen from EFI and starts drawing on top of it.
> 
> On the other hand, the Linux driver seems to reset the panel, after which
> point the screen remains blank.
> 
> Is it possible to tell the driver not to reset the panel?

In the long run, that's the plan across all panels. I think you can currently try it with i915.fastboot. Might work, might not.

However, that will only help the takeover at boot. If the driver does not know how to properly enable the display, it'll fail the next time you do a modeset anyway.
Comment 38 Innocent Bystander 2017-08-24 20:11:42 UTC
FWIW, tried 4.12.8 and the "failed" units still don't work (blank)

Jani, I've tried i915.fastboot but it didn't seem to make any difference. Do I need to apply the "dirty" hack mentioned above?
Comment 39 Elizabeth 2017-09-28 14:45:43 UTC
(In reply to Jani Nikula from comment #37)
> ... In the long run, that's the plan across all panels. I think you can
> currently try it with i915.fastboot. Might work, might not...
(In reply to Innocent Bystander from comment #38)
> Do
> I need to apply the "dirty" hack mentioned above?
As Jani mentioned before that could or couldn't work. No new advances have been reported in this case. Still a valid bug, please keep open. Thank you.
Comment 40 Hans de Goede 2018-01-25 13:30:58 UTC
Hi,

So there seem to be 2 issues here really:

1) The original issue of the LCD not working on the Pipo with no MIPI sequences defined in its VBT

2) Later on some comments got added about a different problem:  Black screen on modesetting with Dell Venue 8 Pro (version with screen with MIPI panel index = 3)

For 2. we already have bug 82880 open so lets use that bug for further discussion of the Dell issue. Note 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 and I've managed to come up with a patch, for details on this see bug 82880.

Regards,

Hans
Comment 41 Jani Saarinen 2018-03-29 07:10:00 UTC
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 42 Jani Saarinen 2018-04-23 10:02:44 UTC
Closing, please re-open if still occurs.


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.