Bug 109267 - [GLK DSI] Display not working with i915 driver
Summary: [GLK DSI] Display not working with i915 driver
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
Whiteboard: ReadyForDev, Triaged
Depends on:
Reported: 2019-01-10 04:56 UTC by Danni Uptlen
Modified: 2019-03-14 22:44 UTC (History)
4 users (show)

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

dmesg (58.87 KB, text/plain)
2019-01-10 04:56 UTC, Danni Uptlen
no flags Details
dmesg drm-tip (582.94 KB, text/plain)
2019-01-15 02:58 UTC, Danni Uptlen
no flags Details
vbt for Lenovo D330 (5.62 KB, application/octet-stream)
2019-03-08 13:06 UTC, Mark Wynn Garcia
no flags Details
D330 acpidump (495.16 KB, text/plain)
2019-03-11 20:24 UTC, Mark Wynn Garcia
no flags Details
pinctrl dump - i915 disabled (58.24 KB, text/plain)
2019-03-13 14:57 UTC, Mark Wynn Garcia
no flags Details
pinctrl dump - normal boot, no/before X11 (58.23 KB, text/plain)
2019-03-13 14:57 UTC, Mark Wynn Garcia
no flags Details
pinctrl dump - normal boot, within X11 (58.25 KB, text/plain)
2019-03-13 14:58 UTC, Mark Wynn Garcia
no flags Details
pinctrl dump - normal boot, within X11, xrandr DSI-1 off (58.23 KB, text/plain)
2019-03-13 14:59 UTC, Mark Wynn Garcia
no flags Details
pinctrl dump - ddc patch, within X11 (57.75 KB, text/plain)
2019-03-14 22:44 UTC, Mark Wynn Garcia
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Danni Uptlen 2019-01-10 04:56:51 UTC
Created attachment 143051 [details]

On boot, laptop display goes black, however desktop etc loads (confirmed by swapping to tty and outputting data to file whilst still being unable to see anything).

If I boot with nomodeset and manually setting resolution to 800x1280, I can get to desktop but cannot rotate screen etc.

-- system architecture: ("uname -m")
-- kernel version: ("uname -r"). 
4.18.0-10-generic (i have attempted to use drm-tip but cannot boot, i think emmc support needs to be enabled?  I don't know how to do this)
-- Linux distribution:
xubuntu 18.10
-- Machine or mother board model:
Lenovo D330-10IGM

Happy to try drm-tip if anyone can tell me how to get it booting.

dmesg is attached
Comment 1 Denis 2019-01-10 09:28:11 UTC
>Happy to try drm-tip if anyone can tell me how to get it booting

https://01.org/linuxgraphics/documentation/build-guide-0 here you can find manual.
(could be that with defconfig you'll fail, so worse to try use simply "config" command, and use your current system config (from /boot folder, but copy it before) with a name .config (in GUI you will find this option, something like "use my own config")

As I saw, intel guys also asking for this part, when you are booted with latest drm-tip:

full dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.
Comment 2 Radosław Szwichtenberg 2019-01-10 13:10:45 UTC
Thanks a lot for submitting a bug!
As Denis mentioned - Please try to reproduce the error using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.
Comment 3 Danni Uptlen 2019-01-15 01:38:54 UTC
I have followed the build guide and installed, however I cannot boot the new kernel.  I have been searching for some way to fix this and have asked for help in a few forums now.

I understand that this is not a help forum, but if anyone understands why this might occur after following the build guide, that would be a great help.

Gave up waiting for root device. common problems:

Boot args (cat /proc/cmdline)
Check rootdelay= (did the system wait long enough?)
Check root= (did the system wait for the right device?)
Missing modules (cat /proc/modules; ls /dev) ALERT! /dev/disk/by-uuid/blahblahblah does not exist.
Dropping to shell!
Comment 4 Danni Uptlen 2019-01-15 02:58:05 UTC
Created attachment 143114 [details]
dmesg drm-tip

please find drm-tip log file attached
Comment 5 Jani Saarinen 2019-01-15 07:12:03 UTC
CPU looks to be GLK N4000, document that.
Comment 6 Jani Saarinen 2019-01-15 07:15:28 UTC
Jani, looks like mipi/dsi issue?
Comment 7 Jani Nikula 2019-01-15 07:53:25 UTC
It's DSI all right. Might be a dupe of bug #108826. Nothing suspicious AFAICS in dmesg.
Comment 8 Jani Saarinen 2019-01-15 07:57:39 UTC
On Ci https://intel-gfx-ci.01.org/tree/drm-tip/fi-glk-dsi.html system shows nicely desktop too.
Comment 9 Jani Saarinen 2019-01-15 08:39:22 UTC
Stan, do you see pattern here?
Comment 10 Danni Uptlen 2019-01-23 00:43:04 UTC

I'm assuming nothing else is needed from me and this is just somewhere down the list, is that correct?

Comment 11 Jani Saarinen 2019-01-23 07:21:59 UTC
Yes, we have some issues seen on similar issues on GLK but as you mention down on the list. But as this also GLK do you see this as dup of https://bugs.freedesktop.org/show_bug.cgi?id=108826 ?
Comment 12 Danni Uptlen 2019-01-31 03:05:32 UTC
This sounds like the same/similar issue - however I have not tested external monitors.
Comment 13 Mark Wynn Garcia 2019-03-07 14:16:20 UTC
So I posted a fair amount of details on https://bugs.freedesktop.org/show_bug.cgi?id=108826 but were directed back on this bug thread. Is there any more that I can provide to help the investigation? I've not seen any activity on the linked thread which is quite disheartening considering that many D330 and potentially Apollo Lake users won't really be able to use their mobile devices on Linux without an external screen.
Comment 14 Mark Wynn Garcia 2019-03-07 14:40:35 UTC
Sorry, I meant Gemini Lake. By the way, I see a lot of functions specific to Gemini Lake and MIPI/DSI. The patch in the linked thread doesn't fix the D330 issue, and I expect there will be many other places in those functions that you may want to test. I'll do my best to be quick in testing any patches, and you can expect a reply within a day or two.
Comment 15 Stanislav Lisovskiy 2019-03-08 08:50:55 UTC
Hi, could you please try latest drm-tip kernel with default(no Ubuntu) config. 
At some point I was checking this bug  https://bugs.freedesktop.org/show_bug.cgi?id=108826 and I have that device here at office. I could boot it and see the Ubuntu desktop with it. 


So there is a hope! :)

If you need help on installing it, I can assist.
Comment 16 Jani Nikula 2019-03-08 12:03:48 UTC
Please also attach /sys/kernel/debug/dri/0/i915_vbt on Lenove D330.
Comment 17 Jani Nikula 2019-03-08 12:06:33 UTC
(In reply to Stanislav Lisovskiy from comment #15)
> https://bugs.freedesktop.org/show_bug.cgi?id=108826 and I have that device
> here at office.

With DSI the trouble is often with the differences in the panels, the panel and board specific sequences that need to be followed. The VBT should capture most of that, but we also haven't implemented everything in the VBT sequences.
Comment 18 Mark Wynn Garcia 2019-03-08 13:06:46 UTC
Created attachment 143593 [details]
vbt for Lenovo D330

Jani, first of all thank you for working on this.

I've also attached several dmesg outputs on https://bugs.freedesktop.org/show_bug.cgi?id=108826 for the D330. Please do tell me if you need one from a newer kernel (I'm using Arch and with the current 5.0 kernel).
Comment 19 Jani Nikula 2019-03-08 19:16:43 UTC
Do you have CONFIG_PINCTRL_GEMINILAKE kernel config option enabled?

I do suspect there's something wrong with the GPIO code (either in the pincntrl part or i915). Disabling the GPIO setting worked in bug 108826 but I believe that then works by accident; apparently the panels in question don't absolutely require the GPIOs to be changed from whatever the GOP did. And apparently setting the GPIOs properly is required for D330. Again, just my educated guesses.
Comment 20 Mark Wynn Garcia 2019-03-09 03:05:17 UTC
So this is with Arch's vanilla 5.0 kernel:

$ zgrep CONFIG_PINCTRL_GEMINILAKE= /proc/config.gz

Just in case this matters:

$ zgrep CONFIG_PINCTRL_ /proc/config.gz

As an aside, I'm also asking other users in the Lenovo forum thread (https://forums.lenovo.com/t5/Linux-Discussion/Linux-on-Ideapad-D330/m-p/4378118#M12729) to compare their VBT data to what I've attached here to see if there are differences among the 1280x800 SKUs.
Comment 21 Ville Syrjala 2019-03-11 16:58:02 UTC
I suspect "PPS GPIO Pins: Using PMIC" might be the problem here. It may mean that the pmic driver may have be involved here somehow. Sadly the VBT spec is as useless as ever explaining any of this. Also I'm not sure which pmic glk would even have.

Please attach the output of acpidump here.
Comment 22 Mark Wynn Garcia 2019-03-11 20:24:28 UTC
Created attachment 143628 [details]
D330 acpidump

Hello Ville.

Attached is the acpidump output. Thanks for working on this!
Comment 23 Ville Syrjala 2019-03-12 15:11:09 UTC
So based on that it looks like this is the pin mapping:
reset pin (index 0) = audio 4 aka. AVS_I2S0_SDO
power pin (index 4) = north 69 aka, GPIO_145
backlight pin (index 3) = north 68 aka. GPIO_144

Can you do something like this and attach the results here:
1. boot without loading i915
2. /sys/kernel/debug/pinctrl
3. grep . * */* > ~/pin.dump.noi915
4. modprobe i915
5. grep . * */* > ~/pin.dump.i915
Comment 24 Mark Wynn Garcia 2019-03-13 14:56:18 UTC
I'll be posting the pinctrl outputs as follow up attachments. I am not able to use `modprobe i915` after disabling i915 using module_blacklist=i915 (https://wiki.archlinux.org/index.php/Kernel_module#Using_kernel_command_line) as it seems that there is a path in the kernel module loading function itself that blocks anything in the module_blacklist even after the boot process, so modprobe returns an error. Using modprobe blacklist + initramfs/mkinitcpio even including i915's dependencies doesn't work at all.

Anyway I did still manage to get pinctrl output for the following:
* i915 disabled, with grub GFX_PAYLOAD=800x1280
* normal boot (unmodified kernel and boot params) without X11
* normal boot within X11
* normal boot within X11 after `xrandr --output DSI-1 --off`, which turns off the backlight of the screen perhaps among other things

All are done with an external monitor connected through USB-C (DP alternate mode I think) -> hub -> HDMI. I have to note that when i915 is disabled only the laptop's screen has output (that's why I have to use GFX_PAYLOAD because otherwise the output is garbage). Also, for normal boot the console is shown on the external monitor by default (thankfully).
Comment 25 Mark Wynn Garcia 2019-03-13 14:57:08 UTC
Created attachment 143646 [details]
pinctrl dump - i915 disabled
Comment 26 Mark Wynn Garcia 2019-03-13 14:57:58 UTC
Created attachment 143647 [details]
pinctrl dump - normal boot, no/before X11
Comment 27 Mark Wynn Garcia 2019-03-13 14:58:33 UTC
Created attachment 143648 [details]
pinctrl dump - normal boot, within X11
Comment 28 Mark Wynn Garcia 2019-03-13 14:59:29 UTC
Created attachment 143649 [details]
pinctrl dump - normal boot, within X11, xrandr DSI-1 off
Comment 29 Mark Wynn Garcia 2019-03-13 15:09:18 UTC
Ah, I have to clarify: the only way I am able to blacklist i915 is through module_blacklist=i915. Using any other way like modprobe config `blacklist i915` or `install i915 /bin/false` and even blacklisting its dependencies doesn't work at all. `modprobe i915` after boot with module_blacklist=i915 errors out which is likely caused by this: https://github.com/torvalds/linux/blob/ebc551f2b8f905eca0e25c476c1e5c098cd92103/kernel/module.c#L3671 .

Anyway, I hope you still find something useful with what I've currently gathered.
Comment 30 Ville Syrjala 2019-03-13 17:02:53 UTC
-INT3453:01/pinmux-pins:pin 68 (GPIO_144): (MUX UNCLAIMED) (GPIO UNCLAIMED)
-INT3453:01/pinmux-pins:pin 69 (GPIO_145): (MUX UNCLAIMED) (GPIO UNCLAIMED)
+INT3453:01/pinmux-pins:pin 68 (GPIO_144): (MUX UNCLAIMED) INT3453:01:420
+INT3453:01/pinmux-pins:pin 69 (GPIO_145): (MUX UNCLAIMED) INT3453:01:421
-INT3453:02/pinmux-pins:pin 4 (AVS_I2S0_SDO): (MUX UNCLAIMED) (GPIO UNCLAIMED)
+INT3453:02/pinmux-pins:pin 4 (AVS_I2S0_SDO): (MUX UNCLAIMED) INT3453:02:336

When loading the driver the expected gpio pins seem to have been claimed correctly. And the state of those is unchanged, until the xrandr off when they do change state in the expected manner.

-INT3453:01/pins:pin 68 (GPIO_144) GPIO 0x44000201 0x00021267 0x00000100
-INT3453:01/pins:pin 69 (GPIO_145) GPIO 0x44000201 0x00021268 0x00000100
+INT3453:01/pins:pin 68 (GPIO_144) GPIO 0x44000200 0x00021267 0x00000100
+INT3453:01/pins:pin 69 (GPIO_145) GPIO 0x44000200 0x00021268 0x00000100
-INT3453:02/pins:pin 4 (AVS_I2S0_SDO) GPIO 0x44000201 0x0003d200 0x00000000
+INT3453:02/pins:pin 4 (AVS_I2S0_SDO) GPIO 0x44000200 0x0003d200 0x00000000

So unfortunately I'm not seeing anything obvious that would explain the failure.

The only other change I see is that we manage to change the state of the DDC pins. The BIOS/GOP has left them low for some reason, and we just pull them high when the DDC bus is idle (which is the correct thing to do).
-INT3453:01/pins:pin 48 (HV_DDI0_DDC_SDA) mode 1 0x44000400 0x0001c353 0x00000000 [ACPI]
-INT3453:01/pins:pin 49 (HV_DDI0_DDC_SCL) mode 1 0x44000400 0x0001c354 0x00000000 [ACPI]
+INT3453:01/pins:pin 48 (HV_DDI0_DDC_SDA) mode 1 0x44000402 0x0001c353 0x00000000 [ACPI]
+INT3453:01/pins:pin 49 (HV_DDI0_DDC_SCL) mode 1 0x44000402 0x0001c354 0x00000000 [ACPI]

Just to be super sure the DDC pins aren't somehow involved we could test something like:
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 5a733e711355..1423aa5d2ff7 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -703,6 +703,8 @@ gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
        intel_wakeref_t wakeref;
        int ret;
+       return -ENXIO;
        wakeref = intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
        if (bus->force_bit) {

Though I don't expect that to help.
Comment 31 Mark Wynn Garcia 2019-03-14 22:44:22 UTC
Created attachment 143670 [details]
pinctrl dump - ddc patch, within X11

Yes, it doesn't seem to help. Virtually the same behavior with normal boot.

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.