Bug 108826 - [GLK DSI] Black screen after grub - Ubuntu 18.04 - kernel latest tip 21.11.2018
Summary: [GLK DSI] Black screen after grub - Ubuntu 18.04 - kernel latest tip 21.11.2018
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-21 23:39 UTC by Miroslaw
Modified: 2019-08-06 11:30 UTC (History)
7 users (show)

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


Attachments
kernel log (285.64 KB, text/plain)
2018-11-21 23:39 UTC, Miroslaw
no flags Details
drm.debug=0x1e (335.55 KB, text/plain)
2018-11-22 23:12 UTC, Miroslaw
no flags Details
igt-gpu-tools - dump i915.modeset=0_dump.txt (17.00 KB, text/plain)
2018-11-28 00:40 UTC, Miroslaw
no flags Details
igt-gpu-tools - dump fully_working_gpu_driver_black_screen_dump.txt (17.00 KB, text/plain)
2018-11-28 00:41 UTC, Miroslaw
no flags Details
Attached pic showing logo after grub (3.62 MB, image/jpeg)
2019-01-29 10:28 UTC, Stanislav Lisovskiy
no flags Details
Kernel boots after modeset with Tux logo on E Tab (4.02 MB, image/jpeg)
2019-01-29 10:32 UTC, Stanislav Lisovskiy
no flags Details
Ubuntu desktop (4.03 MB, image/jpeg)
2019-01-31 14:26 UTC, Stanislav Lisovskiy
no flags Details
kernel config for ubuntu (46.57 KB, application/octet-stream)
2019-02-01 15:30 UTC, Miroslaw
no flags Details
xrandr output for Lenovo D330 laptop screen (1.21 KB, text/plain)
2019-02-17 05:24 UTC, Mark Wynn Garcia
no flags Details
Lenovo D330 with HD screen N5000 CPU vbt (5.62 KB, application/octet-stream)
2019-02-17 05:46 UTC, Mark Wynn Garcia
no flags Details
Lenovo D330 with HD screen N5000 CPU dmesg with drm.debug=0x1e (125.53 KB, text/plain)
2019-02-17 06:07 UTC, Mark Wynn Garcia
no flags Details
D330 dmesg unpatched 4.20.8 (245.97 KB, text/plain)
2019-02-17 07:50 UTC, Mark Wynn Garcia
no flags Details
D330 dmesg patched 4.20.8 (246.56 KB, text/plain)
2019-02-17 07:51 UTC, Mark Wynn Garcia
no flags Details
kernel_5.0-rc4-no-pathed--screen_a.txt (243.30 KB, text/plain)
2019-03-08 11:57 UTC, Jani Nikula
no flags Details
kernel_5.0-rc4-not-pathed-screen_b.txt (67.89 KB, text/plain)
2019-03-08 11:58 UTC, Jani Nikula
no flags Details
kernel_5.0-rc4-pathed--screen_a.txt (241.47 KB, text/plain)
2019-03-08 11:58 UTC, Jani Nikula
no flags Details
kernel_5.0-rc4-pathed_screen_b.txt (67.64 KB, text/plain)
2019-03-08 11:58 UTC, Jani Nikula
no flags Details
panel a i915_vbt (5.59 KB, application/octet-stream)
2019-04-05 00:10 UTC, Miroslaw
no flags Details
panel b i915_vbt (5.59 KB, application/octet-stream)
2019-04-05 00:10 UTC, Miroslaw
no flags Details
full drm/0 panel a (130.01 KB, application/x-7z-compressed)
2019-04-05 00:12 UTC, Miroslaw
no flags Details
full drm/0 panel b (115.21 KB, application/x-7z-compressed)
2019-04-05 00:13 UTC, Miroslaw
no flags Details
D330 vbt decoded (1.22 KB, text/plain)
2019-05-27 13:59 UTC, Mark Wynn Garcia
no flags Details
1200+1920IPS-WL-10102FHD-NT (2.85 MB, application/pdf)
2019-05-27 21:30 UTC, Miroslaw
no flags Details
SF101G-MT_LCD_WLY10110-BNT_V1.0-G (179.64 KB, application/octet-stream)
2019-05-29 23:26 UTC, Miroslaw
no flags Details
DSN (528.67 KB, application/pdf)
2019-05-31 07:14 UTC, Microtech
no flags Details
Allegro (111.86 KB, application/pdf)
2019-05-31 07:15 UTC, Microtech
no flags Details
Schematic TOP (72.10 KB, application/pdf)
2019-05-31 07:16 UTC, Microtech
no flags Details
Schematic BOT (14.64 KB, application/pdf)
2019-05-31 07:16 UTC, Microtech
no flags Details
d330 efifb pin dump (17.49 KB, text/plain)
2019-06-23 12:58 UTC, Mark Wynn Garcia
no flags Details
Fix escape clock pll divisor init (1.43 KB, patch)
2019-07-10 14:17 UTC, Stanislav Lisovskiy
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Miroslaw 2018-11-21 23:39:54 UTC
Created attachment 142557 [details]
kernel log

The screen after the grub is getting black ( backlight is still working ).  
System is booting normally - after that backlight screen is working .. and black all the time.
I can control brightness by shortcuts.
If connect HDMI cable then on the new via HDMI the screen works perfect but on the device screen is still black unfortunately .

I attached the kernel.



- edid from windows 10 

Monitor
  Model name............... WLY-10102FHD
  Windows description...... Generic PnP Monitor
  Manufacturer............. AUO
  Plug and Play ID......... AUO17D8
  Serial number............ n/a
  Manufacture date......... 2013, ISO week 11
  Filter driver............ None
  -------------------------
  EDID revision............ 1.4
  Input signal type........ Digital
  Color bit depth.......... 8 bits per primary color
  Color encoding formats... RGB 4:4:4, YCrCb 4:4:4
  Screen size.............. 140 x 220 mm (10,3 in)
  Power management......... Active off/sleep
  Extension blocs.......... None
  -------------------------
  DDC/CI................... n/a

Color characteristics
  Default color space...... sRGB
  Display gamma............ 3,55
  Red chromaticity......... Rx 0,625 - Ry 0,340
  Green chromaticity....... Gx 0,285 - Gy 0,605
  Blue chromaticity........ Bx 0,148 - By 0,063
  White point (default).... Wx 0,281 - Wy 0,309
  Additional descriptors... None



Thanks for any help.
Comment 1 Lakshmi 2018-11-22 07:28:54 UTC
Miroslaw, How often you see this issue? CAn you reproduce this issue?
Can you attach cat /sys/kernel/debug/dri/0/i915_edp_psr_status

Imre, any comments here?
Comment 2 Imre Deak 2018-11-22 07:43:17 UTC
Miroslaw, could you post a dmesg log booting with drm.debug=0x1e ?

I see that there's a suspend followed by a second kernel boot with the nomodeset kernel parameter. Is that some kexec thing? nomodeset will disable the i915 driver:

Nov 21 20:25:43 qq-ETP101WL64 kernel: [  117.478108] [drm:gen9_set_dc_state [i915]] Setting DC state from 01 to 00
Nov 21 20:25:43 qq-ETP101WL64 kernel: [  117.743131] PM: suspend entry (deep)
Nov 21 20:26:59 qq-ETP101WL64 kernel: [    0.000000] microcode: microcode updated early to revision 0x28, date = 2018-05-22
Nov 21 20:26:59 qq-ETP101WL64 kernel: [    0.000000] Linux version 4.20.0-994-generic (kernel@tangerine) (gcc version 8.2.0 (Ubuntu 8.2.0-9ubuntu1)) #201811202101 SMP Wed Nov 21 02:04:29 UTC 2018
Nov 21 20:26:59 qq-ETP101WL64 kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.20.0-994-generic root=UUID=c52e7968-edfb-425b-996c-93790fe96a5f ro quiet splash nomodeset vt.handoff=1
Comment 3 Miroslaw 2018-11-22 10:15:06 UTC
I think you see second boot because I had to boot device with the nomodeset parameter second time ( then screen is working but this is software mode )   to copy data log from /var/log ...because without this parameter the screen is black ( only backlight works ) .

I forgot to remove second log data from kernel.log file .
Comment 4 Jani Nikula 2018-11-22 10:53:29 UTC
(In reply to Lakshmi from comment #1)
> Can you attach cat /sys/kernel/debug/dri/0/i915_edp_psr_status

It's a MIPI DSI panel, that file is not relevant.
Comment 5 Jani Saarinen 2018-11-22 10:59:11 UTC
I see our GLK DSI on CI generally happy on BAT:
https://intel-gfx-ci.01.org/tree/drm-tip/fi-glk-dsi.html
Comment 6 Miroslaw 2018-11-22 11:31:22 UTC
This is MIPI DSI panel - yes 
Device is a tablet ..so works on battery - yes
Comment 7 Miroslaw 2018-11-22 15:52:08 UTC
Do you need more details ?
Comment 8 Imre Deak 2018-11-22 15:58:43 UTC
(In reply to Miroslaw from comment #7)
> Do you need more details ?

Could you provide the dmesg log booting with drm.debug=0x1e? Please capture the log right after booting, when the screen is blank.
Comment 9 Miroslaw 2018-11-22 23:12:36 UTC
Created attachment 142580 [details]
drm.debug=0x1e

log with param drm.debug=0x1e
Comment 10 Stanislav Lisovskiy 2018-11-23 07:15:36 UTC
Did that start to happen only with recent kernel? Can you please also attach kernel log with drm.debug with a working kernel?
Comment 11 Miroslaw 2018-11-23 09:58:42 UTC
There is no working kernel .
I tested from 4.15 up to 4.20-rc1 ... akways the same - black screen after grub ( backlight works ) .
Comment 12 Miroslaw 2018-11-23 20:23:23 UTC
Hi

Any ideas how to fix it ?
Comment 13 Jani Nikula 2018-11-26 07:21:49 UTC
One idea for debugging this:

1) boot *without* loading i915
2) get register dump using intel_reg (from the igt-gpu-tools [1])
3) modprobe i915 (presumably screen goes black at this point)
4) repeat the register dump

Alas I think intel_reg dump still falls short for MIPI DSI register dumps. Someone from our side should provide a register spec file to use with intel_reg to include all the relevant registers. (One of the reasons we're not dumping the DSI registers by default is that reading them hangs the machine if DSI isn't properly powered and clocks enabled.)

[1] https://cgit.freedesktop.org/drm/igt-gpu-tools/
Comment 14 Miroslaw 2018-11-27 01:35:52 UTC
Hi

I'm trying to compile igt-gpu-tools for debugging
but have problems with dependencies 

Dependency xmlrpc found: NO
Dependency xmlrpc_util found: NO
Dependency xmlrpc_client found: NO
Dependency xv found: NO
Program rst2man-3 found: NO

I can't find those dependencies ...
I'm trying to build it on Ubuntu 18.04 what system are you using for it ?

Thank for help
Comment 15 Jani Saarinen 2018-11-27 06:37:11 UTC
+ Petri and Arek to comment deps.
Comment 16 Jani Saarinen 2018-11-27 07:01:34 UTC
Miroslaw, have you read README.md. Does it help?
Comment 17 Miroslaw 2018-11-27 10:05:02 UTC
Reading readme was the first thing what I did .
I installed all dependencies from readme.md.

But still missing 

Dependency xmlrpc found: NO
Dependency xmlrpc_util found: NO
Dependency xmlrpc_client found: NO
Dependency xv found: NO
Program rst2man-3 found: NO

I tried installed those missing by myself but can't find it .

As I said - I'm using Ubuntu 18.04 ... maybe is not compatible. What system are you using for build this app ? .
Comment 18 Petri Latvala 2018-11-27 10:13:48 UTC
(In reply to Miroslaw from comment #14)
> Hi
> 
> I'm trying to compile igt-gpu-tools for debugging
> but have problems with dependencies 
> 
> Dependency xmlrpc found: NO
> Dependency xmlrpc_util found: NO
> Dependency xmlrpc_client found: NO
> Dependency xv found: NO
> Program rst2man-3 found: NO
> 
> I can't find those dependencies ...
> I'm trying to build it on Ubuntu 18.04 what system are you using for it ?
> 
> Thank for help


Those dependencies are for Chamelium support (xmlrpc), intel-gpu-overlay (xv) and man pages (rst2man-3).

xmlrpc in Debian and Ubuntu are old enough to not have pkg-config support. The NO you're seeing for them is not finding its pkg-config files. If those fail, the build system is using xmlrpc-config.

Overlay has two variants, with xv or with xlib.

rst2man-3 is a binary in Fedora for its python3 version. On Ubuntu, rst2man is used.

In a nutshell: All those missing dependencies are for particular variants, and even if you don't have the other variants, the disabled build artifacts are not related to the intel_reg tool.

The Debian packages that are used in gitlab CI should also work for Ubuntu, check out Dockerfile.debian.
Comment 19 Miroslaw 2018-11-28 00:40:23 UTC
Created attachment 142638 [details]
igt-gpu-tools - dump i915.modeset=0_dump.txt
Comment 20 Miroslaw 2018-11-28 00:41:06 UTC
Created attachment 142639 [details]
igt-gpu-tools - dump fully_working_gpu_driver_black_screen_dump.txt
Comment 21 Miroslaw 2018-11-28 00:48:24 UTC
I added 2 dumps from igt-gpu-tools

command : intel_reg dump 

Without loaded gpu driver and with working gpu driver.
Of course with working gpu driver I have black screen.

If you need more data please ask.
Thanks
Comment 22 Miroslaw 2018-11-29 21:15:55 UTC
So 
Any ideas ?  ;-)

Thanks
Comment 23 Jani Nikula 2018-11-30 11:54:15 UTC
Just to double check, are you booting in UEFI mode and not in legacy BIOS mode?
Comment 24 Miroslaw 2018-11-30 13:39:19 UTC
I'm sure on 100 % - booting from  UEFI
Comment 25 Miroslaw 2018-11-30 13:40:38 UTC
And no legacy BIOS mode.
Comment 26 Miroslaw 2018-12-12 14:53:03 UTC
So do I got any support about my problem ?
Comment 27 Lakshmi 2018-12-17 05:08:16 UTC
Jani, attached register dumps are helpful?
Comment 28 Jani Nikula 2018-12-19 07:42:39 UTC
(In reply to Lakshmi from comment #27)
> Jani, attached register dumps are helpful?

See comment #13.
Comment 29 Miroslaw 2018-12-21 00:08:10 UTC
(In reply to Jani Nikula from comment #28)
> (In reply to Lakshmi from comment #27)
> > Jani, attached register dumps are helpful?
> 
> See comment #13.

I did dumps and attached here ...
What's you want now  ?
Comment 30 Miroslaw 2018-12-21 00:11:53 UTC
Apart from that your team has the tablet in the hands - Etab pro .

Thanks for any solution .
Comment 31 Stanislav Lisovskiy 2018-12-27 08:58:45 UTC
Can you try the most recent drm-tip kernel? Yesterday I tried to boot from Ubuntu Live CD, the 4.15 kernel which is included obviously didn't work(blank screen as mentioned), however once I've substituted that kernel to 4.20.0-rc7, I could see the kernel boot messages and modesetting worked.
Comment 32 Stanislav Lisovskiy 2018-12-27 08:59:56 UTC
PS: I tried all mentioned above with E Tab pro.
Comment 33 Jani Saarinen 2018-12-27 10:24:42 UTC
HI,
So you are saying that latest RC7 worked on that tablet and no black screen? 

> -----Original Message-----
> From: intel-gfx-bugs [mailto:intel-gfx-bugs-bounces@lists.freedesktop.org] On
> Behalf Of bugzilla-daemon@freedesktop.org
> Sent: torstai 27. joulukuuta 2018 11.00
> To: intel-gfx-bugs@lists.freedesktop.org
> Subject: [Bug 108826] [GLK DSI] Black screen after grub - Ubuntu 18.04 - kernel
> latest tip 21.11.2018
> 
> Comment # 32 <https://bugs.freedesktop.org/show_bug.cgi?id=108826#c32>
> on bug 108826 <https://bugs.freedesktop.org/show_bug.cgi?id=108826>  from
> Stanislav Lisovskiy <mailto:stanislav.lisovskiy@intel.com>
> PS: I tried all mentioned above with E Tab pro.
> 
> ________________________________
> 
> You are receiving this mail because:
> 
> *	You are on the CC list for the bug.
> *	You are the assignee for the bug.
> *	You are the QA Contact for the bug.
Comment 34 Stanislav Lisovskiy 2018-12-27 10:52:19 UTC
I could see a modeset during boot and kernel messages as well as Ubuntu logo. It didn't boot further(couldn't find init) as I didn't update LiveCD filesystem which is squashfs, however I'm pretty sure it will boot, if I will do that. I will try to install Ubuntu to flash drive completely and then try with the recent kernel to confirm this.
Comment 35 Miroslaw 2018-12-27 19:08:41 UTC
I try the new kernel in 4th of January ...as I'm on holiday now .
Comment 36 Miroslaw 2019-01-08 00:19:11 UTC
> Stanislav Lisovskiy 2018-12-27 10:52:19 UTC
>  I could see a modeset during boot and kernel  
> messages as well as Ubuntu logo. It didn't boot 
> further (couldn't find init) as I didn't update  
> LiveCD filesystem which is squashfs, however I'm 
> pretty sure it will boot, if I will do that. I 
> will try to install Ubuntu to flash drive 
> completely and then try with the recent kernel to 
> confirm this.

Hi 

I tested full 4.20 kernel ( not rc ) 

Still black screen is like it was ... 
Nothing changed ...
Tomorrow I will test newst tlp kernel kernel .
Comment 37 Stanislav Lisovskiy 2019-01-13 20:25:53 UTC
(In reply to Miroslaw from comment #36)
> > Stanislav Lisovskiy 2018-12-27 10:52:19 UTC
> >  I could see a modeset during boot and kernel  
> > messages as well as Ubuntu logo. It didn't boot 
> > further (couldn't find init) as I didn't update  
> > LiveCD filesystem which is squashfs, however I'm 
> > pretty sure it will boot, if I will do that. I 
> > will try to install Ubuntu to flash drive 
> > completely and then try with the recent kernel to 
> > confirm this.
> 
> Hi 
> 
> I tested full 4.20 kernel ( not rc ) 
> 
> Still black screen is like it was ... 
> Nothing changed ...
> Tomorrow I will test newst tlp kernel kernel .

Ok, I will check it again then.
Comment 38 Miroslaw 2019-01-24 02:31:02 UTC
Hi 
...so did you check it again ? ... another week passed :-/
Comment 39 Stanislav Lisovskiy 2019-01-29 10:28:10 UTC
Created attachment 143247 [details]
Attached pic showing logo after grub
Comment 40 Stanislav Lisovskiy 2019-01-29 10:30:59 UTC
(In reply to Miroslaw from comment #38)
> Hi 
> ...so did you check it again ? ... another week passed :-/

Sorry, we had some severe bug to address. I checked it again - and with 4.20-rc7 I can see modeset, kernel log and Xubuntu logo after booting. I had also even attached a pics with that. Probably we need to figure out what is the difference still.
Comment 41 Stanislav Lisovskiy 2019-01-29 10:32:39 UTC
Created attachment 143248 [details]
Kernel boots after  modeset with Tux logo on E Tab
Comment 42 Miroslaw 2019-01-31 10:45:39 UTC
Ok again :) 

Look on the video with the panel "a" where we have problem 

https://streamable.com/uc5ct

And second vieo with panel "b" here is ok .

https://streamable.com/qkwjr


Only difference between them is a screen panel .


Stanislav Lisovskiy - on the early stage the screen is rotated to the left ( like on your screenshot ) but later ( after kms or initiate DRM GPU driver ) screen is rotated ( must be ) to the right .

So you see only a very early booting process ...and nothing more .

I replaced boot kernel and in the squash.sfs to 4.20... problem is still exist .

And why you're trying Kubuntu not Ubuntu ? .
Comment 43 Stanislav Lisovskiy 2019-01-31 14:26:27 UTC
Created attachment 143262 [details]
Ubuntu desktop

Just as I expected, I was able to boot into Ubuntu desktop with E Tab Pro. It required a few
tweaks like using overlay fs instead of aufs, rebuilding live cd image to use recent drm-tip kernel(basically I guess anything which starts from 4.20-rc7 would work, checked 4.20-rc7 and 5.0.0-rc3). Please see pics in the attachment. The touchscreen and mouse pointer do not work properly though, however the system is usable.
Comment 44 Jani Nikula 2019-01-31 14:45:24 UTC
(In reply to Miroslaw from comment #42)
> Ok again :) 
> 
> Look on the video with the panel "a" where we have problem 
> 
> https://streamable.com/uc5ct
> 
> And second vieo with panel "b" here is ok .
> 
> https://streamable.com/qkwjr
> 
> 
> Only difference between them is a screen panel .

Are you saying you have two models with different panels, and one of them has the problem and the other one doesn't? And presumably we've got a working model?
Comment 45 Miroslaw 2019-01-31 14:54:00 UTC
As far as I know you have "a" screen panel type .
This panel has a problem .

I tried 4.20 ( not RC ) and the panel wasn't work .
Today I try kernel 5.0 and tip so ... try to confirm it ...
Comment 46 Stanislav Lisovskiy 2019-01-31 14:57:33 UTC
(In reply to Miroslaw from comment #42)
> Ok again :) 
> 
> Look on the video with the panel "a" where we have problem 
> 
> https://streamable.com/uc5ct
> 
> And second vieo with panel "b" here is ok .
> 
> https://streamable.com/qkwjr
> 
> 
> Only difference between them is a screen panel .
> 
> 
> Stanislav Lisovskiy - on the early stage the screen is rotated to the left (
> like on your screenshot ) but later ( after kms or initiate DRM GPU driver )
> screen is rotated ( must be ) to the right .
> 
> So you see only a very early booting process ...and nothing more .
> 
> I replaced boot kernel and in the squash.sfs to 4.20... problem is still
> exist .
> 
> And why you're trying Kubuntu not Ubuntu ? .

(In reply to Miroslaw from comment #45)
> As far as I know you have "a" screen panel type .
> This panel has a problem .
> 
> I tried 4.20 ( not RC ) and the panel wasn't work .
> Today I try kernel 5.0 and tip so ... try to confirm it ...


Well for me it works, I can use Ubuntu desktop from there. I have sent a USB stick image to Ilya. Mostly the whole thing was just LiveCD tweaking, like squashfs, adding support for FUSE, OVERLAY_FS.
Comment 47 Miroslaw 2019-01-31 15:01:03 UTC
Touch screen works or not ? 
It should be only inverted.
Also rotation should works.
Can you confirm it ?
Comment 48 Miroslaw 2019-01-31 15:10:11 UTC
Just tell me if touch screen works .
If not then you have to add support for
 Gemini lake in the kernel config....because without it for me screen also works
But without GEMINI lake support rotation and touchscreen doesn't work .
Comment 49 Stanislav Lisovskiy 2019-01-31 15:30:06 UTC
(In reply to Miroslaw from comment #48)
> Just tell me if touch screen works .
> If not then you have to add support for
>  Gemini lake in the kernel config....because without it for me screen also
> works
> But without GEMINI lake support rotation and touchscreen doesn't work .

This is something new. I didn't check it. Touch screen doesn't work. As I understood from previous conversation for this panel you had only blank screen, also in the video.
Comment 50 Stanislav Lisovskiy 2019-01-31 15:32:24 UTC
(In reply to Miroslaw from comment #11)
> There is no working kernel .
> I tested from 4.15 up to 4.20-rc1 ... akways the same - black screen after
> grub ( backlight works ) .

I thought this was a problem. I see no mentioning about the touchscreen in the bug description.
Comment 51 Miroslaw 2019-01-31 15:39:37 UTC
Because touch screen is working :-) and also rotation .

Your kernel config is not proper.
Add pin ctrl for gemini lake ( we have such platform ) 
Rebuild kernel and try then .

If Gemini lake config ( pin ctrl )  is "on" everything works except screen.
But on device with "b" screen everything works including screen.
Comment 52 Jani Nikula 2019-01-31 15:41:54 UTC
Please have the exact same setup on both a and b device, add drm.debug=14 module parameter, and attach dmesg all the way from boot.
Comment 53 Stanislav Lisovskiy 2019-01-31 15:48:27 UTC
> If Gemini lake config ( pin ctrl )  is "on" everything works except screen.
> But on device with "b" screen everything works including screen.

You should have described this in the beginning.
The bug originally was:


"The screen after the grub is getting black ( backlight is still working ).  
System is booting normally - after that backlight screen is working .. and black all the time.
I can control brightness by shortcuts.
If connect HDMI cable then on the new via HDMI the screen works perfect but on the device screen is still black unfortunately .

I attached the kernel.



- edid from windows 10 

Monitor
  Model name............... WLY-10102FHD
  Windows description...... Generic PnP Monitor
  Manufacturer............. AUO
  Plug and Play ID......... AUO17D8
  Serial number............ n/a
  Manufacture date......... 2013, ISO week 11
  Filter driver............ None
  -------------------------
  EDID revision............ 1.4
  Input signal type........ Digital
  Color bit depth.......... 8 bits per primary color
  Color encoding formats... RGB 4:4:4, YCrCb 4:4:4
  Screen size.............. 140 x 220 mm (10,3 in)
  Power management......... Active off/sleep
  Extension blocs.......... None
  -------------------------
  DDC/CI................... n/a

Color characteristics
  Default color space...... sRGB
  Display gamma............ 3,55
  Red chromaticity......... Rx 0,625 - Ry 0,340
  Green chromaticity....... Gx 0,285 - Gy 0,605
  Blue chromaticity........ Bx 0,148 - By 0,063
  White point (default).... Wx 0,281 - Wy 0,309
  Additional descriptors... None



Thanks for any help."

And no mentioning about that. I'm really happy to help, however don't have telepathy skills unfortunately :)
Comment 54 Miroslaw 2019-01-31 16:17:54 UTC
Gemini lake config is on in standard Ubuntu config for 18.04 .
I didn't know you are using different config so why I had to mention about it ? 
Just make a config copy from kernel boot partition of Ubuntu 18.04...
Comment 55 Stanislav Lisovskiy 2019-01-31 16:42:03 UTC
(In reply to Miroslaw from comment #54)
> Gemini lake config is on in standard Ubuntu config for 18.04 .
> I didn't know you are using different config so why I had to mention about
> it ? 
> Just make a config copy from kernel boot partition of Ubuntu 18.04...

I just used default kernel config. To be honest it wasn't obvious to me that I have to use that one. However at least now I know. :)

I will try then enabling it, then repeat again all this sequence and tell you the results.
Comment 56 Stanislav Lisovskiy 2019-01-31 16:52:02 UTC
(In reply to Miroslaw from comment #11)
> There is no working kernel .
> I tested from 4.15 up to 4.20-rc1 ... akways the same - black screen after
> grub ( backlight works ) .

That was basically what confused me actually, I thought you had no working kernel, as of this comment.
Comment 57 Jani Nikula 2019-02-01 08:27:56 UTC
Miroslaw, please attach /sys/kernel/debug/dri/0/i915_vbt for each device type, with display a and with display b.

The VBT contains display sequences to run at specific stages of display control, including changing GPIO states. This probably conflicts with pin control.
Comment 58 Miroslaw 2019-02-01 11:39:08 UTC
I tested newest tip kernel and 5.0rc4 - black screen ...
vbt 915 logs I will attach later today .
Comment 59 Stanislav Lisovskiy 2019-02-01 11:54:46 UTC
(In reply to Miroslaw from comment #58)
> I tested newest tip kernel and 5.0rc4 - black screen ...
> vbt 915 logs I will attach later today .

It was with PINCTRL_GEMINILAKE=y I suppose? 

If so, can you try to patch intel_dsi_vbt with this patch:

diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 06a11c35a784..9b3c68a2f75c 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -371,7 +371,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
                 vlv_exec_gpio(dev_priv, gpio_source, gpio_number, value);
         else if (IS_CHERRYVIEW(dev_priv))
                 chv_exec_gpio(dev_priv, gpio_source, gpio_number, value);
-       else
+       else if (!IS_GEMINILAKE(dev_priv))
                 bxt_exec_gpio(dev_priv, gpio_source, gpio_index, value);
 
         return data;

---

With this patch from Jani, I can boot into Ubuntu desktop and PINCTRL_GEMINILAKE is turned on. However... touchscreen still doesn't work.
Comment 60 Stanislav Lisovskiy 2019-02-01 12:15:50 UTC
Also at least now I'm able to manually rotate screen and also manipulate with mouse, even though it is inverted:

https://streamable.com/at6ik
Comment 61 Miroslaw 2019-02-01 15:30:50 UTC
Created attachment 143270 [details]
kernel config for ubuntu

Strange ... touch screen and auto rotation should works at one.
Here is my config for kernel ( standard config for ubuntu 18.04 )
Comment 62 Miroslaw 2019-02-02 01:32:31 UTC
THE PATH HELPED.
The "a" screen works finally.
Also tested with "b" screen also is ok .

You should add the path to the main kernel branch .

Thanks for help
Comment 63 Jani Nikula 2019-02-05 08:09:23 UTC
Can I have the VBT and full dmesg with both panel types attached please? See comment #52 and comment #57.
Comment 64 Jani Nikula 2019-02-08 08:52:23 UTC
(In reply to Jani Nikula from comment #63)
> Can I have the VBT and full dmesg with both panel types attached please? See
> comment #52 and comment #57.

Miroslaw?
Comment 65 Miroslaw 2019-02-12 01:54:22 UTC
Sorry I'm very busy lately.
I make it tomorrow.
Comment 66 Michael Matta 2019-02-15 09:34:31 UTC
(In reply to Miroslaw from comment #65)
> Sorry I'm very busy lately.
> I make it tomorrow.

Hello Miroslaw, i'm sorry but can you please not forget to resume with the team? There is a number of users unable to get Linux on their Ideapad D330 for the same issue stated here, we are waiting for the fix patiently.
Comment 67 Mark Wynn Garcia 2019-02-17 05:24:55 UTC
Created attachment 143387 [details]
xrandr output for Lenovo D330 laptop screen
Comment 68 Mark Wynn Garcia 2019-02-17 05:29:22 UTC
Comment on attachment 143387 [details]
xrandr output for Lenovo D330 laptop screen

I've been following this bug as I have the exact device, Lenovo D330 with N5000 CPU and 1280x800 screen. https://forums.lenovo.com/t5/Linux-Discussion/Linux-on-Ideapad-D330/td-p/4296738/

I'm currently able to run vanilla Arch (4.20.8) with an external monitor without modeset and setting GRUB's gfxpayload. Still having the same problem as the others, with no display on the laptop screen but with [controllable] backlight. xrandr also is able to read the modes, please see attached file.

I've applied and tested the above patch. Unfortunately it doesn't fix the problem. There is one instance though that arch's login prompt showed for a brief moment before the screen blanking. This is with video=800x1280.
Comment 69 Mark Wynn Garcia 2019-02-17 05:46:39 UTC
Created attachment 143388 [details]
Lenovo D330 with HD screen N5000 CPU vbt

Jani, if this could also help I've attached my device's vbt.
Comment 70 Mark Wynn Garcia 2019-02-17 06:07:09 UTC
Created attachment 143389 [details]
Lenovo D330 with HD screen N5000 CPU dmesg with drm.debug=0x1e

Also dmesg with drm.debug=0x1e with no other boot parameter modifications (no nomodeset or grub gfxpayload). This is with external monitor connected, which is DP (through USB-C dongle probably converting USB-C DP alternate mode to HDMI). Laptop screen is DSI.

Additional details with laptop screen, Windows 10 detects an "active signal resolution" of 800x1280 but weirdly @ ~75 hz (which isn't included in the xrandr output). Sorry I won't be able to give more Windows 10 info as I nuked everything when I installed arch.
Comment 71 Mark Wynn Garcia 2019-02-17 07:50:15 UTC
Created attachment 143390 [details]
D330 dmesg unpatched 4.20.8

Sorry for previous dmesg attachment. Here's the proper one, with unpatched kernel v 4.20.8 from arch.
Comment 72 Mark Wynn Garcia 2019-02-17 07:51:18 UTC
Created attachment 143391 [details]
D330 dmesg patched 4.20.8

And here's for the patch, on same base kernel version.
Comment 73 Jani Nikula 2019-02-20 10:21:51 UTC
I don't know what made anyone think this bug has anything to do with Lenovo D330. AFAIK the report is *not* about Lenovo D330.

If the patch that helps the original reporter does not help you, it's also a clue you have a different bug. Please file a different bug.

Miroslaw, we're still waiting for the details from you.
Comment 74 Miroslaw 2019-02-21 01:54:43 UTC
Here you go 

kernel_5.0-rc4-pathed--screen_a
https://pastebin.com/0qg18CMi

kernel_5.0-rc4-no-pathed--screen_a
https://pastebin.com/EvCUPsBa

kernel_5.0-rc4-pathed_screen_b
https://pastebin.com/CCzLsPX1

kernel_5.0-rc4-not-pathed-screen_b
https://pastebin.com/Y2jAV6UV


I remind :
The same device with 2 different screens

Ssreen a - had a problem  after kms with a "blank screen" .. path solved it
Screen b - is ok no problems at all

If you need more data just ask .
Comment 75 Lakshmi 2019-02-22 11:43:53 UTC
Based on the Comment 66, priority of this bug is set to Highest as many users are unable to get Linux on  Ideapad D330.
Comment 76 Jani Nikula 2019-02-25 11:02:19 UTC
(In reply to Lakshmi from comment #75)
> Based on the Comment 66, priority of this bug is set to Highest as many
> users are unable to get Linux on  Ideapad D330.

Please see comment #73 and reconsider. File a new bug for D330, this is not the one.
Comment 77 Lakshmi 2019-02-25 11:18:24 UTC
(In reply to Mark Wynn Garcia from comment #68)
> Comment on attachment 143387 [details]
> xrandr output for Lenovo D330 laptop screen
> 
> I'm currently able to run vanilla Arch (4.20.8) with an external monitor
> without modeset and setting GRUB's gfxpayload. Still having the same problem
> as the others, with no display on the laptop screen but with [controllable]
> backlight. xrandr also is able to read the modes, please see attached file.

Can you please file a new bug for this case? That will help and speed up the investigation.
Comment 78 Danni Uptlen 2019-02-26 23:35:32 UTC
To stop any further messing with the thread, D330 bug has been filed already at:
https://bugs.freedesktop.org/show_bug.cgi?id=109267
Comment 79 Jani Nikula 2019-03-08 11:57:46 UTC
Created attachment 143589 [details]
kernel_5.0-rc4-no-pathed--screen_a.txt

Upload from comment #74.
Comment 80 Jani Nikula 2019-03-08 11:58:08 UTC
Created attachment 143590 [details]
kernel_5.0-rc4-not-pathed-screen_b.txt
Comment 81 Jani Nikula 2019-03-08 11:58:32 UTC
Created attachment 143591 [details]
kernel_5.0-rc4-pathed--screen_a.txt
Comment 82 Jani Nikula 2019-03-08 11:58:52 UTC
Created attachment 143592 [details]
kernel_5.0-rc4-pathed_screen_b.txt
Comment 83 Jani Nikula 2019-03-08 12:01:25 UTC
(In reply to Miroslaw from comment #74)
> Here you go 
> 
> kernel_5.0-rc4-pathed--screen_a
> https://pastebin.com/0qg18CMi
> 
> kernel_5.0-rc4-no-pathed--screen_a
> https://pastebin.com/EvCUPsBa
> 
> kernel_5.0-rc4-pathed_screen_b
> https://pastebin.com/CCzLsPX1
> 
> kernel_5.0-rc4-not-pathed-screen_b
> https://pastebin.com/Y2jAV6UV
> 
> 
> I remind :
> The same device with 2 different screens
> 
> Ssreen a - had a problem  after kms with a "blank screen" .. path solved it
> Screen b - is ok no problems at all
> 
> If you need more data just ask .

Miroslaw, please attach /sys/kernel/debug/dri/0/i915_vbt for each device type, with display a and with display b.

The VBT contains display sequences to run at specific stages of display control, including changing GPIO states. This probably conflicts with pin control.

For future reference, please *attach* all logs and binaries etc. instead of using pastebin. The pastebins will go away eventually.
Comment 84 Miroslaw 2019-04-05 00:10:01 UTC
Created attachment 143866 [details]
panel a i915_vbt
Comment 85 Miroslaw 2019-04-05 00:10:46 UTC
Created attachment 143867 [details]
panel b i915_vbt
Comment 86 Miroslaw 2019-04-05 00:12:32 UTC
Created attachment 143868 [details]
full drm/0 panel a
Comment 87 Miroslaw 2019-04-05 00:13:12 UTC
Created attachment 143869 [details]
full drm/0 panel b
Comment 88 Miroslaw 2019-04-05 00:24:14 UTC
Hi

Sorry I answer so late but I was very busy lately.
I attach i915_vbt  ... but looks exactly identical.
So I also attach whole folders dri/0 for both panels.

That not working properly panel "a" works ok now with the path ... until I sleep device...when I wake up device the screen is totally black not even backlight works only restart device helps ... until I sleep device again...
I have the same result on panel "b" ( with that path but panel do not need it - just for test )...  waking up device from sleep  - ... only black screen.


Without the path:
- panel "a" only works until kernel starts loading drm driver then is black but backlight works.
- panel "b" - everything is ok.. no problems.
Comment 89 Jani Saarinen 2019-04-05 06:52:05 UTC
Please also notice (if using rc1) https://bugs.freedesktop.org/show_bug.cgi?id=109516 currently DSI systems in CI broken too.
Comment 90 Miroslaw 2019-04-05 22:45:44 UTC
So ...
You even have this tablet ( device ) and still now solved it.

Have any idea how to fix it permanently ? 
Screen works only when GEMINILAKE config is is off ... 
But we can't awake the screen after sleep system - s3/s4 state ( ubuntu / android ).
Comment 91 Mark Wynn Garcia 2019-04-07 02:06:38 UTC
Looking at Miroslaw's VBT files, looks like another case of "PPS GPIO Pins: Using PMIC". Is there any way for Intel devs to know what Windows and its iGPU driver does right with these hardware?
Comment 92 Lakshmi 2019-04-10 07:24:55 UTC
Jani N, any further comments here?
Comment 93 Microtech 2019-04-15 19:17:35 UTC
(In reply to Jani Nikula from comment #83)
> (In reply to Miroslaw from comment #74)
> > Here you go 
> > 
> > kernel_5.0-rc4-pathed--screen_a
> > https://pastebin.com/0qg18CMi
> > 
> > kernel_5.0-rc4-no-pathed--screen_a
> > https://pastebin.com/EvCUPsBa
> > 
> > kernel_5.0-rc4-pathed_screen_b
> > https://pastebin.com/CCzLsPX1
> > 
> > kernel_5.0-rc4-not-pathed-screen_b
> > https://pastebin.com/Y2jAV6UV
> > 
> > 
> > I remind :
> > The same device with 2 different screens
> > 
> > Ssreen a - had a problem  after kms with a "blank screen" .. path solved it
> > Screen b - is ok no problems at all
> > 
> > If you need more data just ask .
> 
> Miroslaw, please attach /sys/kernel/debug/dri/0/i915_vbt for each device
> type, with display a and with display b.
> 
> The VBT contains display sequences to run at specific stages of display
> control, including changing GPIO states. This probably conflicts with pin
> control.
> 
> For future reference, please *attach* all logs and binaries etc. instead of
> using pastebin. The pastebins will go away eventually.

Hi Jani, I write for the first time because I would like to say thanks you to you and your colleagues for the work you did until now. 
I ask you a little additional effort because the tablet still don't work properly, since there is some pending issue. You have this device in your hands, I think, so you can debug it easily because you can test everything. 
Please help us to close this ticket. Now we really need to close it because we are stopped on this project from December and we can't go ahead.
Comment 94 Miroslaw 2019-04-15 23:53:52 UTC
Stanislav Lisovskiy and Jani Nikula

You're Intel devs ...why you still not solved it ( who will do that if you not )? 

You have that tablet in you hands and have skill to fix it.
Please help us with it
Comment 95 Stanislav Lisovskiy 2019-04-16 11:36:49 UTC
(In reply to Miroslaw from comment #62)
> THE PATH HELPED.
> The "a" screen works finally.
> Also tested with "b" screen also is ok .
> 
> You should add the path to the main kernel branch .
> 
> Thanks for help

Hi again Miroslaw. To be honest, I stopped following this bug(we have plenty of other stuff also) after this comment above you made. I thought everything was fine after this. 

Can you please summarize again what doesn't work for you, because I thought everything worked fine as mentioned that "patch solved it". 

Need now again to grab this E-Tab back to my table..

Do I understand correctly that now you have a different issue related to suspend/resume?

Jani Nikula: did you find anything suspicious from i915_vbt logs that you requested?
Comment 96 Miroslaw 2019-04-16 19:36:29 UTC
Panel "a" works ok now with the path ... until I sleep device ( Android or Linux ) ...when I wake up device the screen is totally black even backlight no works - only restart device helps ... until I sleep device again...
I have the same result on panel "b" ( with that path but panel do not need it - just for test )...  waking up device from sleep  - ... only black screen..( when path is applied ) 

Summarize: 

Without the path:
- panel "a" only works until kernel starts loading drm driver then is black but backlight works.
- panel "b" - everything is ok.. no problems.

With the path
- panel "a" works until you sleep device ( s3 or s4 for instance  ) then you have totally black screen - even backlight not working.


- panel "b" works until you sleep device ( s3 or s4 for instance  ) then you have totally black screen - even backlight not working.
Comment 97 Stanislav Lisovskiy 2019-04-17 08:27:58 UTC
(In reply to Miroslaw from comment #96)
> Panel "a" works ok now with the path ... until I sleep device ( Android or
> Linux ) ...when I wake up device the screen is totally black even backlight
> no works - only restart device helps ... until I sleep device again...
> I have the same result on panel "b" ( with that path but panel do not need
> it - just for test )...  waking up device from sleep  - ... only black
> screen..( when path is applied ) 
> 
> Summarize: 
> 
> Without the path:
> - panel "a" only works until kernel starts loading drm driver then is black
> but backlight works.
> - panel "b" - everything is ok.. no problems.
> 
> With the path
> - panel "a" works until you sleep device ( s3 or s4 for instance  ) then you
> have totally black screen - even backlight not working.
> 
> 
> - panel "b" works until you sleep device ( s3 or s4 for instance  ) then you
> have totally black screen - even backlight not working.

Can you please share your kernel config, that you use(which works)? Or I see there is one in attachment - can I use that one?
Comment 98 Miroslaw 2019-04-17 08:41:12 UTC
Yes I'm using that config from the attachment I provided.
Make sure Gemini lake pin config is active .
Thanks for help .
Comment 99 Jani Nikula 2019-04-18 09:13:02 UTC
The VBT blocks for the two panels are identical. Are the specs for the two panels identical?

The VBT contains lots of configuration for the panel DPHY, initialization and enable/disable sequences. Are the requirements for the two panels identical?

Has the VBT DSI configuration been tailored for the platform, board and panels? The sequences contain GPIO toggles and DSI DCS commands. Any generic VBT will not work.

What is the origin of the VBT configuration? Did someone provide it to you or did you use the BMP tool to adjust and generate it?
Comment 100 Miroslaw 2019-04-20 06:37:45 UTC
We are using standard vbt config like kernel provides nothing more.
Problem exist only on panel "a" ..panel "b" is ok.

On windows panel "a" works ok like panel "b".
Problem exist only in Linux / Android .
I remind that you have that device so you can make any tests as you needs.

Cheers
Comment 101 Stanislav Lisovskiy 2019-04-23 07:41:39 UTC
I've checked it with our local device and even with Gemini lake pin config disabled I can reproduce it, so pin ctrl most likely doesn't affect this at all.
Comment 102 Jani Nikula 2019-04-23 08:06:46 UTC
(In reply to Stanislav Lisovskiy from comment #101)
> I've checked it with our local device and even with Gemini lake pin config
> disabled I can reproduce it, so pin ctrl most likely doesn't affect this at
> all.

Not so fast. We may *need* proper pin ctrl to actually make it work.
Comment 103 Miroslaw 2019-05-01 10:07:17 UTC
Hi
Did you get any progress?
May I help somehow yet?
Comment 104 Jani Saarinen 2019-05-02 04:19:20 UTC
We also noticed some issues on our GLK DSI system and this should be fixing that: https://patchwork.freedesktop.org/series/60065/. So are you able to test with this patch to see if better after this? We did not had black screen very "cracked" screen. This is about to be merged in soon.
Comment 105 Jani Saarinen 2019-05-02 09:37:13 UTC
This now merged:

drm/i915: Corrupt DSI picture fix for GeminiLake

author	Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>	2019-04-30 15:51:19 
committer	Jani Nikula <jani.nikula@intel.com>	2019-05-02 10:46:55 +0300
commit	beb29980026ffb38f990fbc3be9a0b89d9a15ea4
tree	976ace1740502ac0595317f64ce2f10ba6a361f7
parent	dc76e5764a46ffb2e7f502a86b3288b5edcce191

Does this help here?
Comment 106 Miroslaw 2019-05-02 11:54:52 UTC
I'll check that in few hours and let you know.
Comment 107 Miroslaw 2019-05-02 21:36:17 UTC
I tried this path on screen "a" - still not working , the path nothing changed .
Comment 108 Stanislav Lisovskiy 2019-05-03 11:26:08 UTC
(In reply to Miroslaw from comment #107)
> I tried this path on screen "a" - still not working , the path nothing
> changed .

That would be quite strange if that would fix it - we had corrupt picture issue MIPI DSI on GLK, which was due to some side effect for low CDCLK.

I will try to switch to this task again now, if nothing else more important pops up.
Comment 109 Miroslaw 2019-05-06 21:50:35 UTC
..So any progress ?
Comment 110 Microtech 2019-05-09 09:52:43 UTC
(In reply to Stanislav Lisovskiy from comment #108)
> (In reply to Miroslaw from comment #107)
> > I tried this path on screen "a" - still not working , the path nothing
> > changed .
> 
> That would be quite strange if that would fix it - we had corrupt picture
> issue MIPI DSI on GLK, which was due to some side effect for low CDCLK.
> 
> I will try to switch to this task again now, if nothing else more important
> pops up.

Hi Stanislav, please help us to solve this issue. You have the device, I think, you can test when you want. Let me know.
Comment 111 Miroslaw 2019-05-13 23:15:00 UTC
Hi ... so any changes ?
Comment 112 Microtech 2019-05-16 12:20:59 UTC
(In reply to Jani Nikula from comment #102)
> (In reply to Stanislav Lisovskiy from comment #101)
> > I've checked it with our local device and even with Gemini lake pin config
> > disabled I can reproduce it, so pin ctrl most likely doesn't affect this at
> > all.
> 
> Not so fast. We may *need* proper pin ctrl to actually make it work.

Hi Jani, please help us to solve the issue, we opened this ticket on November 2018, 6 months ago. 
Really we don't know how to solve it, without your cooperation.
Comment 113 Stanislav Lisovskiy 2019-05-20 12:25:59 UTC
Hi sorry for not replying here in time, unfortunately I have some other issues to solve + being sick at home. 

However as I understand the current problem what you have is different from which we had originally - I mean that at the beginning you had a black screen after grub and now with path display is working, but now your problem is related to suspend/resume sequences.

I do understand your frustration, but seems that we have quite a lot of different issues with MIPI DSI and bugs tend to become accumulation of all possible issues, like "my DSI is not working". 

If you don't really have now black screen after grub, can we just close this bug and create a new one, containing more precise description for current problem, like "sleeping GLK MIPI DSI doesn't recover the device". 

That would really help, if not solve, but at least properly classify and analyze the data, because solving different issues one-by-one in the same bug is not the way, how this is supposed to work.
Comment 114 Stanislav Lisovskiy 2019-05-21 12:54:41 UTC
There seem to be some issue with gpio pins used in vbt sequences used for Microtech Etab. 
I see that backlight gpio pin index 4 works as supposed, while accessing others actually breaks the display. That explains also why initially it did work without
geminilake_pinctrl - it simply couldn't access those, which was visible in the log.

I confirmed this also by adding small hack to mipi_exec_gpio function so that it doesn't touch pins 3, 6 which used for power_on and reset respectively. 
Then my etab works with geminilake_pinctrl, also I can see the backlight switching on/off during suspend/resume. However display still stays blank. To me it looks like either there is something wrong with the vbt sequence or those pins are misconfigured somehow.
Comment 115 Miroslaw 2019-05-21 20:47:08 UTC
...exactly as Stanislav Lisovskiy  said .
I wanted to say the same thing ;-).
Comment 116 Stanislav Lisovskiy 2019-05-22 12:00:53 UTC
(In reply to Miroslaw from comment #115)
> ...exactly as Stanislav Lisovskiy  said .
> I wanted to say the same thing ;-).

Do you happen to have any schematics for this Microtech Etab? I mean, I want to see all the connections between panel, SoC and etc..
Comment 117 Stanislav Lisovskiy 2019-05-27 10:00:42 UTC
I have checked the vbt sequences, pll settings, clocks and i915 seems to follow those properly(I have added a lot of debugs to verify this). 
However the problem is that whenever it touches gpios related to power and reset(GPIO index 3, 6) the screen gets corrupt(there is some picture it is actually not fully black), even though we seem to do everything according to vbt, which means that now we have to compare with Windows driver(which I don't have access to right now) and also get some schematics to understand what exactly is wrong with those.
If we are not touching those faulty two pins - the screen is fine(which probably means that the rest of init sequence is correct), however suspend/resume doesn't work, I guess because without those pins, we don't have a way to properly power_on/reset the panel.
Comment 118 Mark Wynn Garcia 2019-05-27 13:02:16 UTC
Hello Stanislav. It's very good to know you're considering looking into the Windows driver sources. This will definitely speed things up. :D

Could you please share with us a patch of your hack? I want to try it on my device (D330), and looking into the VBT it seems it does touch GPIO index 3 on MIPI_SEQ_POWER_ON, though there's no sequence with GPIO index 6.
Comment 119 Stanislav Lisovskiy 2019-05-27 13:39:17 UTC
(In reply to Mark Wynn Garcia from comment #118)
> Hello Stanislav. It's very good to know you're considering looking into the
> Windows driver sources. This will definitely speed things up. :D
> 
> Could you please share with us a patch of your hack? I want to try it on my
> device (D330), and looking into the VBT it seems it does touch GPIO index 3
> on MIPI_SEQ_POWER_ON, though there's no sequence with GPIO index 6.

GPIO index 6 is the reset:

BDB block 53 - MIPI sequence block:
	Sequence block version v3
	Sequence 1 - MIPI_SEQ_ASSERT_RESET
		GPIO index 6, number 135, set 1 (0x01)
		Delay: 12000 us
		GPIO index 6, number 135, set 0 (0x00)
		Delay: 5000 us
		GPIO index 6, number 135, set 1 (0x01)
	Sequence 3 - MIPI_SEQ_DISPLAY_ON
		Send DCS: Port A, VC 0, LP, Type 05, Length 1, Data 11
		Send DCS: Port A, VC 0, LP, Type 15, Length 2, Data b0 5a
		Send DCS: Port A, VC 0, LP, Type 15, Length 2, Data b1 02
		Send DCS: Port A, VC 0, LP, Type 15, Length 2, Data 39 49
		Send DCS: Port A, VC 0, LP, Type 05, Length 1, Data 29
	Sequence 4 - MIPI_SEQ_DISPLAY_OFF
		Send DCS: Port A, VC 0, LP, Type 05, Length 1, Data 28
		Delay: 120000 us
		Send DCS: Port A, VC 0, LP, Type 05, Length 1, Data 10
		Delay: 34000 us
	Sequence 5 - MIPI_SEQ_DEASSERT_RESET
		Delay: 10000 us
		GPIO index 6, number 135, set 0 (0x00)
	Sequence 6 - MIPI_SEQ_BACKLIGHT_ON
		GPIO index 4, number 145, set 1 (0x01)
		Delay: 2000 us
	Sequence 7 - MIPI_SEQ_BACKLIGHT_OFF
		GPIO index 4, number 145, set 0 (0x00)
		Delay: 1000 us
	Sequence 10 - MIPI_SEQ_POWER_ON
		GPIO index 3, number 144, set 1 (0x01)
		Delay: 5000 us
	Sequence 11 - MIPI_SEQ_POWER_OFF
		GPIO index 3, number 144, set 0 (0x00)

The hack is as simple as doing something like this:

git diff intel_dsi_vbt.c 
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index fbed9064ac7e..f9a2e351184f 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -324,6 +324,9 @@ static void bxt_exec_gpio(struct drm_i915_private *dev_priv,
        struct gpio_desc *gpio_desc = bxt_gpio_table[gpio_index];
 
        if (!gpio_desc) {
+               if (gpio_index == 3 || gpio_index == 6) {
+                       return;
+               }
                gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
                                                 NULL, gpio_index,
                                                 value ? GPIOD_OUT_LOW :

Which is of course quite symptomatic treatment and suspend fails to recover still..
Comment 120 Mark Wynn Garcia 2019-05-27 13:59:33 UTC
Created attachment 144350 [details]
D330 vbt decoded

Looks like it's 6 is to GPIO index 0 for mine.

I'm applying the patch now to drm-tip. I'll try first with just index 3 disabled.
Comment 121 Stanislav Lisovskiy 2019-05-27 15:15:46 UTC
(In reply to Mark Wynn Garcia from comment #120)
> Created attachment 144350 [details]
> D330 vbt decoded
> 
> Looks like it's 6 is to GPIO index 0 for mine.
> 
> I'm applying the patch now to drm-tip. I'll try first with just index 3
> disabled.

Yes exactly I saw your vbt for you it is 0.
Comment 122 Miroslaw 2019-05-27 21:30:30 UTC
Created attachment 144357 [details]
1200+1920IPS-WL-10102FHD-NT

Hi
The manufacturer PDF manual for that LCD screen.
Comment 123 Miroslaw 2019-05-27 21:32:36 UTC
In the manual pin 6 has no connection ( 0 ? ).
Comment 124 Miroslaw 2019-05-28 00:22:38 UTC
I also checked that path .. screen works util you not sleep device ...then we have still working blacklight but black screen.
Comment 125 Stanislav Lisovskiy 2019-05-28 07:20:04 UTC
(In reply to Miroslaw from comment #123)
> In the manual pin 6 has no connection ( 0 ? ).

I think this numbering is related to LCD screen itself rather than cpu package gpios, we still need to know how they are connected actually.
Comment 126 Mark Wynn Garcia 2019-05-28 08:17:43 UTC
Stani. I think I know the problem. I'm still at work so I couldn't test it. 

I think it's because of the call to devm_gpiod_get_index() is only done once, with the first call's value.

		gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
						 NULL, gpio_index,
						 value ? GPIOD_OUT_LOW : GPIOD_OUT_HIGH);

The look at gpiod_set_value() -> gpiod_set_value_nocheck() (https://github.com/torvalds/linux/blob/master/drivers/gpio/gpiolib.c#L3335). It flips the value if it's flagged as low. See also gpiod_configure_flags(). So if it happens that the initial call sets the GPIOD_OUT_LOW flag, then every subsequent calls will have the value flipped. So it can never set the GPIO to 1/true!
Comment 127 Mark Wynn Garcia 2019-05-28 08:26:10 UTC
Oops I mistook GPIO_ACTIVE_LOW to be GPIOD_OUT_LOW... but I'll check further on this because I really feel there's a high chance it's this combination of static initialization pattern and the flags that may be causing all of this.
Comment 128 Stanislav Lisovskiy 2019-05-28 08:30:35 UTC
(In reply to Mark Wynn Garcia from comment #126)
> Stani. I think I know the problem. I'm still at work so I couldn't test it. 
> 
> I think it's because of the call to devm_gpiod_get_index() is only done
> once, with the first call's value.
> 
> 		gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev,
> 						 NULL, gpio_index,
> 						 value ? GPIOD_OUT_LOW : GPIOD_OUT_HIGH);
> 
> The look at gpiod_set_value() -> gpiod_set_value_nocheck()
> (https://github.com/torvalds/linux/blob/master/drivers/gpio/gpiolib.c#L3335).
> It flips the value if it's flagged as low. See also gpiod_configure_flags().
> So if it happens that the initial call sets the GPIOD_OUT_LOW flag, then
> every subsequent calls will have the value flipped. So it can never set the
> GPIO to 1/true!

This would probably make almost all panels unusable :) Also even for this tablet backlight is working as expected..
Comment 129 Mark Wynn Garcia 2019-05-28 08:32:13 UTC
Please sanity check this:

https://github.com/torvalds/linux/blob/3601fe43e8164f67a8de3de8e988bfcb3a94af46/include/dt-bindings/gpio/gpio.h#L15

#define GPIO_ACTIVE_LOW 1

https://github.com/torvalds/linux/blob/903b77c631673eeec9e9114e9524171cdf9a2646/include/linux/gpio/consumer.h#L51

#define GPIOD_FLAGS_BIT_DIR_SET		BIT(0)
#define GPIOD_FLAGS_BIT_DIR_OUT	BIT(1)

...

	GPIOD_OUT_LOW = GPIOD_FLAGS_BIT_DIR_SET | GPIOD_FLAGS_BIT_DIR_OUT,

so GPIO_ACTIVE_LOW == GPIOD_OUT_LOW !!!(?)
Comment 130 Mark Wynn Garcia 2019-05-28 08:47:58 UTC
> This would probably make almost all panels unusable :) Also even for this tablet backlight is working as expected..

Ah, my mistake. I should have just looked into GPIOD_OUT_HIGH too. I got too excited I guess. 🤦🏽‍♂️
Comment 131 Stanislav Lisovskiy 2019-05-28 08:56:38 UTC
(In reply to Mark Wynn Garcia from comment #129)
> Please sanity check this:
> 
> https://github.com/torvalds/linux/blob/
> 3601fe43e8164f67a8de3de8e988bfcb3a94af46/include/dt-bindings/gpio/gpio.h#L15
> 
> #define GPIO_ACTIVE_LOW 1
> 
> https://github.com/torvalds/linux/blob/
> 903b77c631673eeec9e9114e9524171cdf9a2646/include/linux/gpio/consumer.h#L51
> 
> #define GPIOD_FLAGS_BIT_DIR_SET		BIT(0)
> #define GPIOD_FLAGS_BIT_DIR_OUT	BIT(1)
> 
> ...
> 
> 	GPIOD_OUT_LOW = GPIOD_FLAGS_BIT_DIR_SET | GPIOD_FLAGS_BIT_DIR_OUT,
> 
> so GPIO_ACTIVE_LOW == GPIOD_OUT_LOW !!!(?)

Yes, it is the same value. 
However gpiod_get_index function doesn't take it as a parameter - 
enum gpiod_flags does not contain GPIO_ACTIVE_LOW among possible flag values, so it doesn't really matter.
Comment 132 Stanislav Lisovskiy 2019-05-28 09:01:28 UTC
Miroslaw, do you happen to have any other documents for Microtech Etab? Would be nice to see the actual schematics..
Comment 133 Miroslaw 2019-05-29 23:26:34 UTC
Created attachment 144378 [details]
SF101G-MT_LCD_WLY10110-BNT_V1.0-G

Hi
This is all what we got from the Chinese supplier about that screen ...
I hope will help.
Comment 134 Microtech 2019-05-31 07:14:39 UTC
Created attachment 144392 [details]
DSN

(In reply to Stanislav Lisovskiy from comment #132)
> Miroslaw, do you happen to have any other documents for Microtech Etab?
> Would be nice to see the actual schematics..

Hi Stanislav, in attached you can find all the docs showing connections between PCBA and all the rest. I hope you can find a solution quickly, because this is the last issue we have to solve before to make available the Linux systems on the e-tab Pro.
Please let us know.
Comment 135 Microtech 2019-05-31 07:15:30 UTC
Created attachment 144393 [details]
Allegro
Comment 136 Microtech 2019-05-31 07:16:07 UTC
Created attachment 144394 [details]
Schematic TOP
Comment 137 Microtech 2019-05-31 07:16:30 UTC
Created attachment 144395 [details]
Schematic BOT
Comment 138 Stanislav Lisovskiy 2019-05-31 10:45:48 UTC
(In reply to Microtech from comment #134)
> Created attachment 144392 [details]
> DSN
> 
> (In reply to Stanislav Lisovskiy from comment #132)
> > Miroslaw, do you happen to have any other documents for Microtech Etab?
> > Would be nice to see the actual schematics..
> 
> Hi Stanislav, in attached you can find all the docs showing connections
> between PCBA and all the rest. I hope you can find a solution quickly,
> because this is the last issue we have to solve before to make available the
> Linux systems on the e-tab Pro.
> Please let us know.

I checked the schematics -  pins look correct(i.e GPIO 135 is reset, GPIO 144 power and GPIO 145 is backlight). I guess we might be missing something in vbt and/or during port initilization stage. Do you have any documents containing more precise panel initialization sequence? I mean exact sequence of command which is expected by this panel, for example exact DCS commands need to be sent for example. 
The pdf attached by Miroslaw has power-on, power-off sequence which matches what we doing already, however there is no dcs command description.
I also checked Windows driver - MIPI DSI initilization looks roughly the same, however as I'm not familiar with that codebase which is quite big, it might take a lot of time to figure out some minor differences. I would say the best way to go would be to get exact example initilization sequence from panel vendor and then compare everything what we send to that.
Comment 139 Stanislav Lisovskiy 2019-05-31 13:38:23 UTC
Also I found that restarting the device without i915 driver and then loading it manually still works, even without those pins.
However if I do suspend even without i915, can't get anything except backlight afterwards. Also if I disable suspend in BIOS it works fine then.

To me it looks like there is something either related to acpi management or panel initialization sequence not mentioned in vbt is missing here.
Comment 140 Microtech 2019-05-31 16:56:59 UTC
(In reply to Stanislav Lisovskiy from comment #139)
> Also I found that restarting the device without i915 driver and then loading
> it manually still works, even without those pins.
> However if I do suspend even without i915, can't get anything except
> backlight afterwards. Also if I disable suspend in BIOS it works fine then.
> 
> To me it looks like there is something either related to acpi management or
> panel initialization sequence not mentioned in vbt is missing here.

We asked to the panel supplier the exact description of DCS Command. I hope to reply you soon. However, in your opinion which is the solution?
Comment 141 Stanislav Lisovskiy 2019-06-03 10:31:04 UTC
(In reply to Microtech from comment #140)
> (In reply to Stanislav Lisovskiy from comment #139)
> > Also I found that restarting the device without i915 driver and then loading
> > it manually still works, even without those pins.
> > However if I do suspend even without i915, can't get anything except
> > backlight afterwards. Also if I disable suspend in BIOS it works fine then.
> > 
> > To me it looks like there is something either related to acpi management or
> > panel initialization sequence not mentioned in vbt is missing here.
> 
> We asked to the panel supplier the exact description of DCS Command. I hope
> to reply you soon. However, in your opinion which is the solution?

Well currently one solution is to disable suspend in BIOS and disable access to the gpio pins 3 and 6. Then at least device is fully usable.. However I guess we still need to figure out the reason why this is happening.
If everything is correct in panel initialization then most likely this is related to acpi.
Also it is pretty weird that suspending device even without i915 makes it unusable for i915 driver afterwards. I would say that there is some issue related to acpi management or bios.
Comment 142 Miroslaw 2019-06-03 10:56:12 UTC
Disabling suspend mode is not a solution for us at all...
Comment 143 Stanislav Lisovskiy 2019-06-03 14:27:03 UTC
Also when I look at the schematics file("DSN") in the attachment at page 34, where it describes LCD panel pins connections - those don't match with the pin numbers in panel doc pdf itself "1200+1920IPS-WL-10102FHD-NT". There are also around 40 pins and similar naming but those are different. So there is either some mapping missing or some of those documents is wrong.
Comment 144 Stanislav Lisovskiy 2019-06-04 12:30:49 UTC
One more interesting finding is that gpio index 5 seems to control display just a same way as backlight pin 4, moreover they both need to be set as 1 in order for display to work. However that doesn't seem to help with suspend issue anyway.
Comment 145 Mark Wynn Garcia 2019-06-04 16:52:06 UTC
Hello Stanislav. I have some questions and observations with regards to pinctrl/gpio.

Based on https://github.com/torvalds/linux/blob/28e8c4bc8eb483c22d977e147a0b98fc63efadf7/drivers/pinctrl/intel/pinctrl-geminilake.c , is it correct for me to say PANEL0_VDDEN corresponds to GPIO index 3 in the VBT, and PANEL0_BKLTEN would be GPIO index 4? There's some evidence in https://www.intel.ca/content/dam/www/public/us/en/documents/datasheets/pentium-celeron-n-series-j-series-datasheet-vol-1.pdf which is for Apollo Lake, but it describes VDDEN and BKLTEN as for panel and backlight enable, respectively.

So I checked further and found in /sys/kernel/debug/pinctrl/INT3453:01/pinmux-pins the following:

...
pin 46 (PCIE_CLKREQ2_B): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 47 (PCIE_CLKREQ3_B): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 48 (HV_DDI0_DDC_SDA): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 49 (HV_DDI0_DDC_SCL): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 50 (HV_DDI1_DDC_SDA): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 51 (HV_DDI1_DDC_SCL): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 52 (PANEL0_VDDEN): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 53 (PANEL0_BKLTEN): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 54 (PANEL0_BKLTCTL): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 55 (HV_DDI0_HPD): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 56 (HV_DDI1_HPD): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 57 (HV_EDP_HPD): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 58 (GPIO_134): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 59 (GPIO_135): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 60 (GPIO_136): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 61 (GPIO_137): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 62 (GPIO_138): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 63 (GPIO_139): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 64 (GPIO_140): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 65 (GPIO_141): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 66 (GPIO_142): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 67 (GPIO_143): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 68 (GPIO_144): (MUX UNCLAIMED) INT3453:01:420
pin 69 (GPIO_145): (MUX UNCLAIMED) INT3453:01:421
pin 70 (GPIO_146): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 71 (LPC_ILB_SERIRQ): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 72 (LPC_CLKOUT0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 73 (LPC_CLKOUT1): (MUX UNCLAIMED) (GPIO UNCLAIMED)
...

Take a look at pins 52 and 53, then at 68 and 69. I also did the following:

# cat /sys/kernel/debug/gpio
gpiochip3: GPIOs 297-331, parent: platform/INT3453:03, INT3453:03:

gpiochip2: GPIOs 332-351, parent: platform/INT3453:02, INT3453:02:
 gpio-336 (                    |0000:00:02.0        ) out hi 

gpiochip1: GPIOs 352-431, parent: platform/INT3453:01, INT3453:01:
 gpio-420 (                    |0000:00:02.0        ) out hi 
 gpio-421 (                    |0000:00:02.0        ) out hi 

gpiochip0: GPIOs 432-511, parent: platform/INT3453:00, INT3453:00:

(420-352 == 68)

I think that somehow the device we use devm_gpiod_get_index() on probably has a wrong "base GPIO index" (just a hunch, if that exists at all).

I also tried manually writing to pins 52 and 53 using sysfs, which unfortunately does nothing. I think, at least for my device, it's important to do this in conjunction with MIPI_SEQ_DISPLAY_ON/MIPI_SEQ_DISPLAY_OFF.
Comment 146 Mark Wynn Garcia 2019-06-04 17:13:11 UTC
Ah nevermind again. I looked at https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/silver-celeron-datasheet-vol-1.pdf and it seems to use multiplexing.
Comment 147 Mark Wynn Garcia 2019-06-04 17:19:58 UTC
Hmmm, so GPIOs 144-145 is for panel 1 (i.e. PNL1_VDDEN,PNL1_BKLTEN) while 128-129 is for panel 0 (i.e. PNL0_VDDEN,PNL0_BKLTEN). Don't know why we're using panel 1...
Comment 148 Mark Wynn Garcia 2019-06-04 18:02:46 UTC
Multiplexing/Muxing (or lack of) could be the culprit. However the topic is way above my head, and the mux tables in https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/silver-celeron-datasheet-vol-1.pdf are quite confusing...
Comment 149 Stanislav Lisovskiy 2019-06-06 17:00:31 UTC
(In reply to Mark Wynn Garcia from comment #147)
> Hmmm, so GPIOs 144-145 is for panel 1 (i.e. PNL1_VDDEN,PNL1_BKLTEN) while
> 128-129 is for panel 0 (i.e. PNL0_VDDEN,PNL0_BKLTEN). Don't know why we're
> using panel 1...

As I understand Panel 0 is reserved for eDP just as correspondent GPIOs and panel 1 is for DSI. This is visible from DSN schematics file. Some of the signal lines are shared though, there could be an issue with that however I don't see anything suspicious so far.
Comment 150 Microtech 2019-06-11 22:15:53 UTC
(In reply to Stanislav Lisovskiy from comment #141)
> (In reply to Microtech from comment #140)
> > (In reply to Stanislav Lisovskiy from comment #139)
> > > Also I found that restarting the device without i915 driver and then loading
> > > it manually still works, even without those pins.
> > > However if I do suspend even without i915, can't get anything except
> > > backlight afterwards. Also if I disable suspend in BIOS it works fine then.
> > > 
> > > To me it looks like there is something either related to acpi management or
> > > panel initialization sequence not mentioned in vbt is missing here.
> > 
> > We asked to the panel supplier the exact description of DCS Command. I hope
> > to reply you soon. However, in your opinion which is the solution?
> 
> Well currently one solution is to disable suspend in BIOS and disable access
> to the gpio pins 3 and 6. Then at least device is fully usable.. However I
> guess we still need to figure out the reason why this is happening.
> If everything is correct in panel initialization then most likely this is
> related to acpi.
> Also it is pretty weird that suspending device even without i915 makes it
> unusable for i915 driver afterwards. I would say that there is some issue
> related to acpi management or bios.

Hi Stanislav, thanks for your efforts. 
I remember you that under Windows everything works perfectly. If the problem is BIOS or Acpi management inside the BIOS, then Windows 10 shouldn't work.
Maybe you have some other solution?
At the end you have the best document ever in your hands : the tablet!
Comment 151 Stanislav Lisovskiy 2019-06-14 08:52:31 UTC
Hi,

Sorry for a long reply. I'm currently on vacation. Yes it works on Windows, I checked with codebase to which I have access and DSI/VBT code looks pretty much same. However I'm still not able to compare with their GPIO and ACPI code. It looks like we are lacking initialization of something or may be GPIO mapping is not completely correct. However I checked with our pinctrl developer person and from his point of view everything looks correct.
I have found that there are other controlable pins which affect DSI display, not mentioned in VBT or manual, which makes me believe there is something else we need to make it work. Unfortunately without exact pin description and initialization sequences any hardware is a "blackbox". That is why I asked for more detailed init description from panel vendor. I guess they should have it anyway for panel testing purposes. I will be back on 17th and start working on it immediately.
Comment 152 Stas KG 2019-06-19 10:35:05 UTC
(In reply to Stanislav Lisovskiy from comment #151)
> Hi,
> 
> Sorry for a long reply. I'm currently on vacation. Yes it works on Windows,
> I checked with codebase to which I have access and DSI/VBT code looks pretty
> much same. However I'm still not able to compare with their GPIO and ACPI
> code. It looks like we are lacking initialization of something or may be
> GPIO mapping is not completely correct. However I checked with our pinctrl
> developer person and from his point of view everything looks correct.
> I have found that there are other controlable pins which affect DSI display,
> not mentioned in VBT or manual, which makes me believe there is something
> else we need to make it work. Unfortunately without exact pin description
> and initialization sequences any hardware is a "blackbox". That is why I
> asked for more detailed init description from panel vendor. I guess they
> should have it anyway for panel testing purposes. I will be back on 17th and
> start working on it immediately.

Hi, just so you know, I also have a D330-10IGM (N5000 1200x1920 version), so if you need any testing, I will follow this bug thread.

Just to confirm that the latest Windows driver (26.20.100.6890) works "out of the box" (previous versions complained that they are not certified for this device). For proper screen rotation and touchscreen operation you still need separate drivers (Bosch rotation sensor and Goodix touchpanel).
Comment 153 Mark Wynn Garcia 2019-06-23 12:58:36 UTC
Created attachment 144615 [details]
d330 efifb pin dump

Hello Stanislav. So I found out about efifb and tried it with nomodeset and the screen works nicely, albeit with i915 essentially disabled and no backlight control. I thought the unadulterated GPIO states set by the EFI could be useful so I attached the pinctrl dumps.
Comment 154 Mark Wynn Garcia 2019-06-23 13:24:33 UTC
I looked further into the docs regarding multiplexing, specifically...

Table 3-52.Northwest Community Mapping (TXE and Direct IRQ), important to see the note below the table:
https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/silver-celeron-datasheet-vol-1.pdf

9.365 Event Trigger Output Enable (EVOUTEN_0)—Offset 210h
29.367 Event Trigger Mapping (EVMAP_0)—Offset 220h
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/silver-celeron-datasheet-vol-2.pdf

And found a similar-sounding EFI implementation for broxton in

https://github.com/tianocore-training/PlatformBuildLab_UP2_FW/blob/7600efc681e74d08682ef32ce8c3f0230721233b/FW/PlatformBuildLab/MV3/edk2-platforms/Silicon/BroxtonSoC/BroxtonSiPkg/Library/GpioLib/GpioLib.c#L308

It could be that i915 is wreaking havoc on the registers involved which are already properly set by EFI.
Comment 155 Stanislav Lisovskiy 2019-06-24 09:49:06 UTC
(In reply to Mark Wynn Garcia from comment #153)
> Created attachment 144615 [details]
> d330 efifb pin dump
> 
> Hello Stanislav. So I found out about efifb and tried it with nomodeset and
> the screen works nicely, albeit with i915 essentially disabled and no
> backlight control. I thought the unadulterated GPIO states set by the EFI
> could be useful so I attached the pinctrl dumps.

Does suspend/resume work then? Currently, unfortunately I have another stuff which has more priority, so I had to stop investigating for some while, however it is very nice that you continue your research.
Comment 156 Mark Wynn Garcia 2019-06-24 10:35:53 UTC
It's unclear if suspend/resume through lid closing/opening is working on this mode. Once I open back from closing the backlight doesn't turn on. I also tried playing music while closing (which causes the music to cease) and once I open the lid it resumes playing for a very brief moment. Suspend/resume wasn't actually a problem when i915 was normally loaded.
Comment 157 Microtech 2019-06-28 21:07:56 UTC
(In reply to Stanislav Lisovskiy from comment #151)
> Hi,
> 
> Sorry for a long reply. I'm currently on vacation. Yes it works on Windows,
> I checked with codebase to which I have access and DSI/VBT code looks pretty
> much same. However I'm still not able to compare with their GPIO and ACPI
> code. It looks like we are lacking initialization of something or may be
> GPIO mapping is not completely correct. However I checked with our pinctrl
> developer person and from his point of view everything looks correct.
> I have found that there are other controlable pins which affect DSI display,
> not mentioned in VBT or manual, which makes me believe there is something
> else we need to make it work. Unfortunately without exact pin description
> and initialization sequences any hardware is a "blackbox". That is why I
> asked for more detailed init description from panel vendor. I guess they
> should have it anyway for panel testing purposes. I will be back on 17th and
> start working on it immediately.

Hi Stanislav, any news for us?
Comment 158 Stanislav Lisovskiy 2019-07-02 06:33:41 UTC
(In reply to Microtech from comment #157)
> (In reply to Stanislav Lisovskiy from comment #151)
> > Hi,
> > 
> > Sorry for a long reply. I'm currently on vacation. Yes it works on Windows,
> > I checked with codebase to which I have access and DSI/VBT code looks pretty
> > much same. However I'm still not able to compare with their GPIO and ACPI
> > code. It looks like we are lacking initialization of something or may be
> > GPIO mapping is not completely correct. However I checked with our pinctrl
> > developer person and from his point of view everything looks correct.
> > I have found that there are other controlable pins which affect DSI display,
> > not mentioned in VBT or manual, which makes me believe there is something
> > else we need to make it work. Unfortunately without exact pin description
> > and initialization sequences any hardware is a "blackbox". That is why I
> > asked for more detailed init description from panel vendor. I guess they
> > should have it anyway for panel testing purposes. I will be back on 17th and
> > start working on it immediately.
> 
> Hi Stanislav, any news for us?

Hi, unfortunately I had to do other things for last 2 weeks, however I will get back to this asap.
Comment 159 Stanislav Lisovskiy 2019-07-02 13:38:09 UTC
Looks like I got some additional clue of what can be the reason. I have discovered that if I disable part of DSI initilizations in i915 driver(mainly pll divisor init), touching those GPIO pins doesn't harm anymore.
Which might mean that it is simply some configuring issue and once we do reset/power on, those wrong values are taken into use. If we don't modify those then they stay the way as set by BIOS.

Just figured this out, have to leave now. Will continue tommorrow.
Comment 160 Mark Wynn Garcia 2019-07-04 14:41:04 UTC
This is really encouraging to hear. Please do send us the patches as soon as they're ready so we can test them.

So I guess this class of problems can be more or less fixed by tracing state changes that essentially causes a modeset from the BIOS-set states.
Comment 161 Stanislav Lisovskiy 2019-07-05 07:15:21 UTC
(In reply to Mark Wynn Garcia from comment #160)
> This is really encouraging to hear. Please do send us the patches as soon as
> they're ready so we can test them.
> 
> So I guess this class of problems can be more or less fixed by tracing state
> changes that essentially causes a modeset from the BIOS-set states.

Currently I still try to figure what exactly breakes it - there is plenty of things being configured.
Comment 162 Stanislav Lisovskiy 2019-07-09 13:04:38 UTC
So update regarding recent findings(see comment above):

Pll escape clock divisers seem to get initialized incorrectly for GeminiLake platform - problem is that in spec those need to be written as 1 shifted(<<) by amount of the divisor itself. While in a driver we write those just as is. 

However that seems not all, because there are other places where escape clocks are used and probably need to be fixed.

Once I will finally identify all the issues - I will send a patch to mailing list and also attach it here.
Comment 163 Stanislav Lisovskiy 2019-07-10 14:16:15 UTC
I have a good news. So after fixing escape clock div init it now works. I can also suspend/resume Etab without any issues. I have sent a patch to mailing list and also attached it here.

https://patchwork.freedesktop.org/patch/317041/
Comment 164 Stanislav Lisovskiy 2019-07-10 14:17:41 UTC
Created attachment 144752 [details] [review]
Fix escape clock pll divisor init
Comment 165 Mark Wynn Garcia 2019-07-10 14:39:15 UTC
This is amazing! I'm now building drm-tip with the patch and will send results as soon as I finish testing. Thank you very much!
Comment 166 Miroslaw 2019-07-10 15:06:01 UTC
I have to test it as well ;-) ... later let you know ...
Comment 167 Mark Wynn Garcia 2019-07-10 23:42:15 UTC
So I tested it and the screen and backlight now works! However I still encounter some issues:
- Suspend/Resume still doesn't seem to power up the screen properly. Only the backlight turns on.
- When soft rebooting (e.g. systemctl reboot), grub and splash screen properly shows, but will always fail on initial modeset.
- There are rare cases when the screen on initial modeset fails even on normal power on (i.e. not from reboot).
- I can sometimes force screen power on to fail by repeatedly turning it off and on through xrandr.

But overall the fix makes everything so much better. I guess there's still a couple of cases we haven't checked, but I'm happy to start with this fix.
Comment 168 Miroslaw 2019-07-11 00:48:45 UTC
I made tests

- screen works during boot kernel and later Ubuntu !
- Suspend/Resume .. WORKS ! finally

.. make some more tests tomorrow but seems works finally proper !
Great job after 6 months ;-D
Comment 169 Stanislav Lisovskiy 2019-07-11 10:14:31 UTC
(In reply to Mark Wynn Garcia from comment #167)
> So I tested it and the screen and backlight now works! However I still
> encounter some issues:
> - Suspend/Resume still doesn't seem to power up the screen properly. Only
> the backlight turns on.

That might mean you either have somewhat different hardware or kernel source tree... Or we might need to search for some other typo ;)

> 
> But overall the fix makes everything so much better. I guess there's still a
> couple of cases we haven't checked, but I'm happy to start with this fix.

(In reply to Miroslaw from comment #168)
> I made tests
> 
> - screen works during boot kernel and later Ubuntu !
> - Suspend/Resume .. WORKS ! finally
> 
> .. make some more tests tomorrow but seems works finally proper !
> Great job after 6 months ;-D

Great to hear that :) I have ended up comparing each and every register write with default values set by BIOS.
Comment 170 Mark Wynn Garcia 2019-07-16 09:35:52 UTC
Is it possible to also publish the PRM for Gemini Lake, like in https://01.org/linuxgraphics/documentation/hardware-specification-prms ?

I'd like to investigate the remaining issues in my device. I suspect it has something to do with https://github.com/freedesktop/drm-tip/blob/f870335815abecda28467d0dcc88732624bb8799/drivers/gpu/drm/i915/display/vlv_dsi.c#L836 .
Comment 171 David Santamaría Rogado 2019-07-20 14:06:14 UTC
I have tested this patch in a Hans de Goede test kernel to solve other bugs at the same time and makes dsi output work as expected. So I think this bug could be marked as solved and report other bugs separately as there are more issues with this convertible, like keyboard not working after suspend resume...

People using Fedora 30 could give a try https://bugzilla.redhat.com/show_bug.cgi?id=1730783 the patched plymouth is on updates-testing and a new testing kernel is being compiled at this moment with orientation correction and Stanislav's fix for dsi output.
Comment 172 David Santamaría Rogado 2019-07-20 21:56:00 UTC
One advice for those with still problems, check you don't have set kernel parameters like nomodeset o gfxpayload or similar.

At booting, there is a warning just after loading the firmware i915/glk_dmc_ver1_04.bin (v1.4) seems to be triggered by (!crtc_clock || max_dotclk < crtc_clock) drivers/gpu/drm/i915/intel_display.c:14090
Comment 173 Stanislav Lisovskiy 2019-08-06 11:30:04 UTC
Based on comment from reporter Miroslaw: 

> I made tests

> - screen works during boot kernel and later Ubuntu !
> - Suspend/Resume .. WORKS ! finally

> .. make some more tests tomorrow but seems works finally proper !
> Great job after 6 months ;-D

Closing this particular bug to avoid generalizing it to some common GLK DSI issue discussion. Those who still have issues - please file another bugs - that would make analyzing them and classification easier.


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.