DRM/Intel Black screen after grub

[Yaron]

According to the following bug there's still no fix available for Ubuntu.

The problem is reproducible using Lenovo IdeaPad D330-10IGM, probably only the N4000 based models (I've tried with N5000 and the screen is rotated to the left and I need xradr to rotate it yet it's not blank).

https://bugs.freedesktop.org/show_bug.cgi?id=108826

I just wanted to make sure that the patch is included in Ubuntu, I can help with testing.

[mirek koc (mirek190)]

Created attachment 142557
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.

[Lakshminarayana-vudum (lakshminarayana-vudum)]

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?

[Imre-deak (imre-deak)]

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

[mirek koc (mirek190)]

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 .

[Jani-nikula (jani-nikula)]

(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.

[Jani-saarinen-g (jani-saarinen-g)]

I see our GLK DSI on CI generally happy on BAT:
https://intel-gfx-ci.01.org/tree/drm-tip/fi-glk-dsi.html

[mirek koc (mirek190)]

This is MIPI DSI panel - yes
Device is a tablet ..so works on battery - yes

[mirek koc (mirek190)]

Do you need more details ?

[Imre-deak (imre-deak)]

(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.

[mirek koc (mirek190)]

Created attachment 142580
drm.debug=0x1e

log with param drm.debug=0x1e

[Stanislav-lisovskiy (stanislav-lisovskiy)]

Did that start to happen only with recent kernel? Can you please also attach kernel log with drm.debug with a working kernel?

[mirek koc (mirek190)]

There is no working kernel .
I tested from 4.15 up to 4.20-rc1 ... akways the same - black screen after grub ( backlight works ) .

[mirek koc (mirek190)]

Hi

Any ideas how to fix it ?

[Jani-nikula (jani-nikula)]

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/

[mirek koc (mirek190)]

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

[Jani-saarinen-g (jani-saarinen-g)]

+ Petri and Arek to comment deps.

[Jani-saarinen-g (jani-saarinen-g)]

Miroslaw, have you read README.md. Does it help?

[mirek koc (mirek190)]

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 ? .

[Petri-latvala (petri-latvala)]

(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.

[mirek koc (mirek190)]

Created attachment 142638
igt-gpu-tools - dump i915.modeset=0_dump.txt

[mirek koc (mirek190)]

Created attachment 142639
igt-gpu-tools - dump fully_working_gpu_driver_black_screen_dump.txt

[mirek koc (mirek190)]

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

[mirek koc (mirek190)]

So
Any ideas ? ;-)

Thanks

[Jani-nikula (jani-nikula)]

Just to double check, are you booting in UEFI mode and not in legacy BIOS mode?

[mirek koc (mirek190)]

I'm sure on 100 % - booting from UEFI

[mirek koc (mirek190)]

And no legacy BIOS mode.

[mirek koc (mirek190)]

So do I got any support about my problem ?

[Lakshminarayana-vudum (lakshminarayana-vudum)]

Jani, attached register dumps are helpful?

[Jani-nikula (jani-nikula)]

(In reply to Lakshmi from comment #27)
> Jani, attached register dumps are helpful?

See comment #13.

[mirek koc (mirek190)]

(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 ?

[mirek koc (mirek190)]

Apart from that your team has the tablet in the hands - Etab pro .

Thanks for any solution .

[Stanislav-lisovskiy (stanislav-lisovskiy)]

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.

[Stanislav-lisovskiy (stanislav-lisovskiy)]

PS: I tried all mentioned above with E Tab pro.

[Jani-saarinen-g (jani-saarinen-g)]

HI,
So you are saying that latest RC7 worked on that tablet and no black screen?

> -----Original Message-----
> From: intel-gfx-bugs [mailto:<email address hidden>] On
> Behalf Of <email address hidden>
> Sent: torstai 27. joulukuuta 2018 11.00
> To: <email address hidden>
> 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:<email address hidden>>
> 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.

[Stanislav-lisovskiy (stanislav-lisovskiy)]

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.

[mirek koc (mirek190)]

I try the new kernel in 4th of January ...as I'm on holiday now .

[mirek koc (mirek190)]

> 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 .

[Stanislav-lisovskiy (stanislav-lisovskiy)]

(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.

[mirek koc (mirek190)]

Hi
...so did you check it again ? ... another week passed :-/

[Stanislav-lisovskiy (stanislav-lisovskiy)]

Created attachment 143247
Attached pic showing logo after grub

[Fabio-rifici (fabio-rifici)]

Created attachment 144392
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.

[Fabio-rifici (fabio-rifici)]

Created attachment 144393
Allegro

[Fabio-rifici (fabio-rifici)]

Created attachment 144394
Schematic TOP

[Fabio-rifici (fabio-rifici)]

Created attachment 144395
Schematic BOT

[Stanislav-lisovskiy (stanislav-lisovskiy)]

(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.

[Stanislav-lisovskiy (stanislav-lisovskiy)]

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.

[Fabio-rifici (fabio-rifici)]

(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?

[Stanislav-lisovskiy (stanislav-lisovskiy)]

(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.

[mirek koc (mirek190)]

Disabling suspend mode is not a solution for us at all...

[Stanislav-lisovskiy (stanislav-lisovskiy)]

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.

[Stanislav-lisovskiy (stanislav-lisovskiy)]

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.

[Markwynngarcia (markwynngarcia)]

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.

[Markwynngarcia (markwynngarcia)]

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.

[Markwynngarcia (markwynngarcia)]

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...

[Markwynngarcia (markwynngarcia)]

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...

[Stanislav-lisovskiy (stanislav-lisovskiy)]

(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.

[Fabio-rifici (fabio-rifici)]

(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!

[Stanislav-lisovskiy (stanislav-lisovskiy)]

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.

[Sinequanon (sinequanon)]

(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).

[Markwynngarcia (markwynngarcia)]

Created attachment 144615
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.

[Markwynngarcia (markwynngarcia)]

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.

[Stanislav-lisovskiy (stanislav-lisovskiy)]

(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.

[Markwynngarcia (markwynngarcia)]

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.

[Fabio-rifici (fabio-rifici)]

(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?

[Stanislav-lisovskiy (stanislav-lisovskiy)]

(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.

[Stanislav-lisovskiy (stanislav-lisovskiy)]

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.

[Markwynngarcia (markwynngarcia)]

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.

[Stanislav-lisovskiy (stanislav-lisovskiy)]

(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.

[Stanislav-lisovskiy (stanislav-lisovskiy)]

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.

[Stanislav-lisovskiy (stanislav-lisovskiy)]

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/

[Stanislav-lisovskiy (stanislav-lisovskiy)]

Created attachment 144752
Fix escape clock pll divisor init

[Markwynngarcia (markwynngarcia)]

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!

[mirek koc (mirek190)]

I have to test it as well ;-) ... later let you know ...

[Markwynngarcia (markwynngarcia)]

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.

[mirek koc (mirek190)]

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

[Stanislav-lisovskiy (stanislav-lisovskiy)]

(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.

[Markwynngarcia (markwynngarcia)]

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 .

[David Santamaría Rogado (howl)]

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.

[David Santamaría Rogado (howl)]

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

[Stanislav-lisovskiy (stanislav-lisovskiy)]

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.