Bug 96923

Summary: Black display once loading the module i915 on Bay trail (DSI/MIPI) - Zen10 tablet
Product: DRI Reporter: viric
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: intel-gfx-bugs, jan.brummer, laszlo.fiat, shobhit.kumar
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: BYT i915 features: display/DSI
Bug Depends on: 96571    
Bug Blocks:    
Attachments:
Description Flags
The i915_vbt debugfs dump
none
blackscreen dmesg+intel_reg_dump+framecounter none

Description viric 2016-07-13 21:44:18 UTC 
Created attachment 125061 [details]
The i915_vbt debugfs dump

After fixing the PWM backlight of this LPSS system (bug 96571), I get a black screen once I load the i915 module. Before it, (efi fb), it displays fine.

I'm using Shobhit patches for enabling the PWM plus another one in the referred bug, over 4.5 and 4.6.3, with the same outcome: backlight works great, the pixels get all black after a quick flicker at module loading.

I notice from the drm debugfs that the lcd panel is connected with DSI. The LCD panel, acording to the BIOS setting for "MIPI panel", is an "Innolux 8x12" (10.1", 800x1280) like this:

http://www.innolux.com/Pages/Dyn/Product3_EN.aspx?cateN=Tablet%20Hybrid%20Solution&catedes=Tablet/Hybrid%20Solution&catel1=Tablet&catel2=WXGA&size=10.1"&Language=EN

The i915 module does not seem to know an EDID for the panel, but has a VBT that I will attach.

The dmesg content at the time of i915 loading is this:

[   72.226417] Linux agpgart interface v0.103
[   72.265453] [drm] Initialized drm 1.1.0 20060810
[   72.384656] [drm] Memory usable by graphics device = 2048M
[   72.384666] checking generic (80000000 1d5000) vs hw (80000000 10000000)
[   72.384669] fb: switching to inteldrmfb from EFI VGA
[   72.384773] Console: switching to colour dummy device 80x25
[   72.384904] [drm] Replacing VGA console driver
[   72.385680] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   72.385686] [drm] Driver supports precise vblank timestamp query.
[   72.407090] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   72.465860] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   72.466436] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input6
[   72.466663] [drm] Initialized i915 1.6.0 20160229 for 0000:00:02.0 on minor 0
[   72.508911] audit: type=1130 audit(1468319461.361:75): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-backlight@backlight:intel_backlight comm="systemd" exe="/nix/store/24qss832pv2xwpjbzk354kimypf4f1jc-systemd-230/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   72.695713] fbcon: inteldrmfb (fb0) is primary device
[   74.649688] Console: switching to colour frame buffer device 100x80
[   74.660835] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

The "Memory usable by graphics device" seems to be all RAM available in the system, 2GiB.
Comment 1 viric 2016-07-20 13:24:51 UTC 
Is there anything I can do to help this go forward? Some special dump to do with intel-gpu-tools?
Comment 2 Shobhit 2016-07-21 11:01:57 UTC 
Can you upload recent logs with drm.debug=0xe here. Also do you have access to ssh after i915 load even when screen is blank ? Maybe you can dump all registers using  intel_reg_dumper.

Also is the frame counter running - intel_reg_read 0x1F0040
Comment 3 viric 2016-07-21 13:01:46 UTC 
I have ssh access. I will gather all that.
Comment 4 viric 2016-07-21 17:37:44 UTC 
Created attachment 125237 [details]
blackscreen dmesg+intel_reg_dump+framecounter

Here I provide the data requested.
Comment 5 viric 2016-07-21 18:00:33 UTC 
I wonder if this is related:

https://bbs.archlinux.org/viewtopic.php?id=202122
Comment 6 viric 2016-07-21 18:42:10 UTC 
I tried the xrandr off and auto, and also the gamma, and nothing changed.

------------------------
[root@teula:/proc/1301]# export XAUTHORITY=/home/viric/.Xauthority

[root@teula:/proc/1301]# DISPLAY=:0.0 xrandr
Screen 0: minimum 8 x 8, current 800 x 1280, maximum 32767 x 32767
DSI1 connected 800x1280+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   800x1280      61.79*+
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

[root@teula:/proc/1301]# DISPLAY=:0.0 xrandr --output DSI1 --off

[root@teula:/proc/1301]# DISPLAY=:0.0 xrandr --output DSI1 --auto

[root@teula:/proc/1301]# DISPLAY=:0.0 xrandr --output DSI1 --gamma 2.20:2.20:2.20

[root@teula:/proc/1301]# DISPLAY=:0.0 xrandr --output DSI1 --gamma 1:1:1
----------------------
Comment 7 Shobhit 2016-07-21 18:45:34 UTC 
From your uploads, it is clear that pipe framecounter is running so the display pipe is not stuck and actually enabled. With backlight also enabled, don't see why display should not work.

Can you stop the GDM/LightDM from ssh and use either test_display from i-g-t or modetest and see if you get some test pattern on the screen.
Comment 8 viric 2016-07-21 19:18:18 UTC 
I don't see anything on screen with testdisplay. Black screen.

# ./libexec/intel-gpu-tools/testdisplay
CRTC(26):[0]  800x1280 62 800 832 840 848 1280 1281 1285 1312 0xa 0x8 68750
SUCCESS (-1.000s)

I don't know what 'modetest' is.
Comment 9 viric 2016-07-21 19:20:27 UTC 
I also saw kms_setmode in i-g-t. The screen is all black; I can only notice that the backlight switches off and on.

# ./kms_setmode 
IGT-Version: 1.15-NOT-GIT (x86_64) (Linux: 4.6.3 x86_64)
Testing: basic-clone-single-crtc 2 connector combinations
Subtest basic-clone-single-crtc: SUCCESS (0.270s)
Testing: invalid-clone-single-crtc 2 connector combinations
  Test id#1 CRTC count 1
    CRTC[26] [Pipe A] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC), HDMI-A-2[42] (NC)
  Test id#2 CRTC count 1
    CRTC[31] [Pipe B] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC), HDMI-A-2[42] (NC)
  Test id#3 CRTC count 1
    CRTC[26] [Pipe A] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC), DSI-1[46]
  Test id#4 CRTC count 1
    CRTC[31] [Pipe B] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC), DSI-1[46]
  Test id#5 CRTC count 1
    CRTC[26] [Pipe A] Mode: 640x480@60Hz Connectors: HDMI-A-2[42] (NC), DSI-1[46]
  Test id#6 CRTC count 1
    CRTC[31] [Pipe B] Mode: 640x480@60Hz Connectors: HDMI-A-2[42] (NC), DSI-1[46]
Subtest invalid-clone-single-crtc: SUCCESS (0.961s)
Testing: invalid-clone-exclusive-crtc 2 connector combinations
  Test id#7 CRTC count 2
    CRTC[26] [Pipe A] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC)
    CRTC[31] [Pipe B] Mode: 800x1280@62Hz Connectors: DSI-1[46]
  Test id#8 CRTC count 2
    CRTC[26] [Pipe A] Mode: 640x480@60Hz Connectors: HDMI-A-2[42] (NC)
    CRTC[31] [Pipe B] Mode: 800x1280@62Hz Connectors: DSI-1[46]
Subtest invalid-clone-exclusive-crtc: SUCCESS (0.740s)
Testing: clone-exclusive-crtc 2 connector combinations
  Test id#9 CRTC count 2
    CRTC[26] [Pipe A] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC)
    CRTC[31] [Pipe B] Mode: 640x480@60Hz Connectors: HDMI-A-2[42] (NC)
  Test id#10 CRTC count 2
    CRTC[31] [Pipe B] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC)
    CRTC[26] [Pipe A] Mode: 640x480@60Hz Connectors: HDMI-A-2[42] (NC)
  Test id#11 CRTC count 2
    CRTC[31] [Pipe B] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC)
    CRTC[26] [Pipe A] Mode: 800x1280@62Hz Connectors: DSI-1[46]
  Test id#12 CRTC count 2
    CRTC[31] [Pipe B] Mode: 640x480@60Hz Connectors: HDMI-A-2[42] (NC)
    CRTC[26] [Pipe A] Mode: 800x1280@62Hz Connectors: DSI-1[46]
Subtest clone-exclusive-crtc: SUCCESS (15.159s)
Testing: invalid-clone-single-crtc-stealing 2 connector combinations
  Test id#13 CRTC count 1
    CRTC[26] [Pipe A] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC), HDMI-A-2[42] (NC)
  Test id#14 CRTC count 1
    CRTC[31] [Pipe B] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC), HDMI-A-2[42] (NC)
  Test id#15 CRTC count 1
    CRTC[26] [Pipe A] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC), DSI-1[46]
  Test id#16 CRTC count 1
    CRTC[31] [Pipe B] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC), DSI-1[46]
(kms_setmode:1061) CRITICAL: Test assertion failure function test_stealing, file kms_setmode.c:398:
(kms_setmode:1061) CRITICAL: Failed assertion: ret == 0
(kms_setmode:1061) CRITICAL: Last errno: 22, Invalid argument
(kms_setmode:1061) CRITICAL: error: -22 != 0
Stack trace:
  #0 [__igt_fail_assert+0xf1]
  #1 [test_combinations+0xd52]
  #2 [main+0x1af]
  #3 [__libc_start_main+0xf0]
  #4 [_start+0x29]
  #5 [<unknown>+0x29]
Subtest invalid-clone-single-crtc-stealing failed.
**** DEBUG ****
(kms_setmode:1061) INFO: Testing: invalid-clone-single-crtc-stealing 2 connector combinations
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=640, height=480, format=0x34325258, tiling=0x0, size=0)
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=55, pitch=2560)
(kms_setmode:1061) INFO:   Test id#13 CRTC count 1
(kms_setmode:1061) INFO:     CRTC[26] [Pipe A] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC), HDMI-A-2[42] (NC)
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=640, height=480, format=0x34325258, tiling=0x0, size=0)
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=56, pitch=2560)
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=640, height=480, format=0x34325258, tiling=0x0, size=0)
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=57, pitch=2560)
(kms_setmode:1061) INFO:   Test id#14 CRTC count 1
(kms_setmode:1061) INFO:     CRTC[31] [Pipe B] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC), HDMI-A-2[42] (NC)
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=640, height=480, format=0x34325258, tiling=0x0, size=0)
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=58, pitch=2560)
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=640, height=480, format=0x34325258, tiling=0x0, size=0)
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=59, pitch=2560)
(kms_setmode:1061) INFO:   Test id#15 CRTC count 1
(kms_setmode:1061) INFO:     CRTC[26] [Pipe A] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC), DSI-1[46]
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=640, height=480, format=0x34325258, tiling=0x0, size=0)
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=60, pitch=2560)
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=640, height=480, format=0x34325258, tiling=0x0, size=0)
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=61, pitch=2560)
(kms_setmode:1061) INFO:   Test id#16 CRTC count 1
(kms_setmode:1061) INFO:     CRTC[31] [Pipe B] Mode: 640x480@60Hz Connectors: HDMI-A-1[35] (NC), DSI-1[46]
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=640, height=480, format=0x34325258, tiling=0x0, size=0)
(kms_setmode:1061) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=62, pitch=2560)
(kms_setmode:1061) CRITICAL: Test assertion failure function test_stealing, file kms_setmode.c:398:
(kms_setmode:1061) CRITICAL: Failed assertion: ret == 0
(kms_setmode:1061) CRITICAL: Last errno: 22, Invalid argument
(kms_setmode:1061) CRITICAL: error: -22 != 0
****  END  ****
Subtest invalid-clone-single-crtc-stealing: FAIL (2.966s)
Comment 10 viric 2016-07-23 10:07:02 UTC 
Can it be that some of the pinctrl problems in kernel log breaks something? Or gpio?

Can there be a bug in the vbt, or in vbt interpretation?

What can I do next?
Comment 11 Shobhit 2016-07-27 08:36:21 UTC 
I doubt VBT being wrong as your BIOS Display comes up and it uses same VBT in exactly same way as kernel would use. There can be some issue in our driver parsing but no indication in logs or yes there might be some external pin for panel control which we are not aware about or not n VBT but controlled by pre-os

@jani, any ideas ?
Comment 12 Laszlo Fiat 2016-08-13 17:43:47 UTC 
viric:

Please try with kernel parameter i915.fastboot=1 with kernel 4.6.x. 
On my Teclast X80H I have a working DSI display with kernel 4.6.4 with that kernel parameter, but only if there is no external (HDMI) display connected. 
And this doesn't work with 4.7, only 4.6 and earlier (down to 4.1-ish). 
Of course your problem can be different than mine, so it may not help on your tablet.
Comment 13 viric 2016-08-15 14:47:15 UTC 
I tried the fastboot, and it does not seem to help.

Today it often fails to provide image even on the first efifb too (before loading i915); screen in black.

Maybe there is a picky initialisation sequence timing in this hardware. The Android and Win10 I run in it seem to get it right all the time, though.
Comment 14 Farooq Hussain 2016-10-21 20:00:56 UTC 
@Viric, what you share which android you are using.

I have the same exact issue as you do. DSI is connected, but black screen, with backlight working fine.
Comment 15 Farooq Hussain 2016-10-21 20:20:45 UTC 
(In reply to Laszlo Fiat from comment #12)
> viric:
> 
> Please try with kernel parameter i915.fastboot=1 with kernel 4.6.x. 
> On my Teclast X80H I have a working DSI display with kernel 4.6.4 with that
> kernel parameter, but only if there is no external (HDMI) display connected. 
> And this doesn't work with 4.7, only 4.6 and earlier (down to 4.1-ish). 
> Of course your problem can be different than mine, so it may not help on
> your tablet.

This seems to take me little further into boot, with modeset taking place and display not going black, but boot stop after sometime, when it hits "Starting Suspend"
Comment 16 Jani Nikula 2017-03-23 13:07:28 UTC 
I think this is probably fixed in either v4.11-rc3 or drm-tip branch of https://cgit.freedesktop.org/drm/drm-tip. Please retest.

(Bug 96571 still remains, though, so the kernel config must be correct.)
Comment 17 Ricardo 2017-06-22 16:23:53 UTC 
closing as fix, submitted did not answer with verification

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.