Bug 109267 - [GLK DSI] Display not working with i915 driver
Summary: [GLK DSI] Display not working with i915 driver
Status: NEEDINFO
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
URL:
Whiteboard: ReadyForDev, Triaged
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-10 04:56 UTC by Danni Uptlen
Modified: 2019-07-12 08:24 UTC (History)
5 users (show)

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


Attachments
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
dmesg-drm-tip-without-x11 (187.79 KB, text/plain)
2019-04-19 06:34 UTC, Mark Wynn Garcia
no flags Details
dmesg-drm-tip-x11 (343.28 KB, text/plain)
2019-04-19 06:35 UTC, Mark Wynn Garcia
no flags Details
dmesg-drm-tip-x11-xrandr-off-dsi-1 (413.72 KB, text/plain)
2019-04-19 06:35 UTC, Mark Wynn Garcia
no flags Details
dmesg-experiment-from-sleep (1000.41 KB, text/plain)
2019-04-19 07:56 UTC, Mark Wynn Garcia
no flags Details
dmesg-drm-tip-fastboot (189.96 KB, text/plain)
2019-04-19 08:50 UTC, Mark Wynn Garcia
no flags Details
dmesg-drm-tip-with-corrupt-dsi-picture-fix (355.22 KB, text/plain)
2019-05-02 23:28 UTC, Mark Wynn Garcia
no flags Details
dmesg-max-cdclk (314.16 KB, text/plain)
2019-05-03 17:01 UTC, Mark Wynn Garcia
no flags Details
D330 display corruption (571.06 KB, image/png)
2019-05-09 15:05 UTC, Pavel Rojtberg
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]
dmesg

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")
x86_64
-- 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
Hi,

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

Thanks,
Danni
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. 

https://streamable.com/at6ik

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
CONFIG_PINCTRL_GEMINILAKE=y

Just in case this matters:

$ zgrep CONFIG_PINCTRL_ /proc/config.gz
CONFIG_PINCTRL_AS3722=m
CONFIG_PINCTRL_AXP209=m
CONFIG_PINCTRL_AMD=m
CONFIG_PINCTRL_MCP23S08=m
CONFIG_PINCTRL_SINGLE=m
CONFIG_PINCTRL_SX150X=y
CONFIG_PINCTRL_MAX77620=m
CONFIG_PINCTRL_PALMAS=m
CONFIG_PINCTRL_RK805=m
CONFIG_PINCTRL_OCELOT=y
CONFIG_PINCTRL_BAYTRAIL=y
CONFIG_PINCTRL_CHERRYVIEW=y
CONFIG_PINCTRL_INTEL=y
CONFIG_PINCTRL_BROXTON=y
CONFIG_PINCTRL_CANNONLAKE=y
CONFIG_PINCTRL_CEDARFORK=y
CONFIG_PINCTRL_DENVERTON=y
CONFIG_PINCTRL_GEMINILAKE=y
CONFIG_PINCTRL_ICELAKE=y
CONFIG_PINCTRL_LEWISBURG=y
CONFIG_PINCTRL_SUNRISEPOINT=y
CONFIG_PINCTRL_MADERA=m
CONFIG_PINCTRL_CS47L35=y
CONFIG_PINCTRL_CS47L85=y
CONFIG_PINCTRL_CS47L90=y

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.
Comment 32 Mark Wynn Garcia 2019-03-27 15:38:33 UTC
So I've done a bit of my own investigation* and found out that there is no MIPI_SEQ_ELEM_PMIC mipi element in my VBT. In the off chance that this is what's missing I'd like to be able to use/call MIPI_SEQ_ELEM_PMIC/mipi_exec_pmic, but I don't know where in the sequence to best put it. Any opinions and suggestions?

* I've modified https://github.com/freedesktop/xorg-intel-gpu-tools/blob/master/tools/intel_vbt_decode.c to include MIPI_SEQ_ELEM_SPI and MIPI_SEQ_ELEM_PMIC, with debug prints based on the corresponding function implementations in i915.
Comment 33 Mark Wynn Garcia 2019-03-27 15:44:36 UTC
Ah I didn't think much of it, but mipi_exec_pmic would need proper arguments. I'll just rummage through the kernel firmware debug files and hope for a miracle haha.
Comment 34 David Santamaría Rogado 2019-04-01 19:41:45 UTC
I have tested two D330 models, both of them with model number 81H3 and pentium silver with 1920x1200 screen, but one with the lte+gps module and the other one without it.

The d330 without the gps module can boot properly into Fedora 29 live, but the one with the gps suffer from this bugs causing it to remain black screen.

The only problem with the d330 that boots ok is the screen rotation, but patches has been sent to systemd and linux kernel.

Apparently the only difference between them is the lack of the lte/gps module.

Also I have to mention that both models can boot with Elementary 5.0 and other Ubuntu 18.04 based distros, so there should from the kernel version used there with the more recent ones.

Actually I don't have the non gps d330 as the lcd had a fabrication defect.

To be more precise the working model is 81H3001PSP, and the non working with recent kernels is 81H3001TSP that have lte+gps.

I have also tested 81H3001TSP over fedora 30 beta 1.8 and still black screen, also enabling alpha support in i915.
Comment 35 David Santamaría Rogado 2019-04-03 13:45:26 UTC
Ubuntu 18.04 has 4.15 kernel and Fedora 29 has 4.18 without updates, so some change between breaks d330 display.

Also in 4.15 touchpanel works at first, but with little use It stop working till reboot, but this is another issue.
Comment 36 David Santamaría Rogado 2019-04-05 16:23:02 UTC
I have tested Fedora 18 that includes 4.16 in Live and also black screen.

This manjaro user https://forum.manjaro.org/t/4-16-kernel-booting-to-black-screen/48674 reports that the black screen issue started with 4.16.2 and update it regularly, so it's very probably that some change between 4.16.1 - 4.16.2 bring up this bug.
Comment 37 David Santamaría Rogado 2019-04-05 20:11:38 UTC
Sorry meant Fedora 28 not 18.
Comment 38 Mark Wynn Garcia 2019-04-07 02:38:55 UTC
David, I think the devs here prefer that you make a separate bug report specific to your SKU. Please also attach in the new bug report i915_vbt files and if possible also dmesg with  drm.debug=0x1e as detailed here: https://bugs.freedesktop.org/show_bug.cgi?id=108826 . Then maybe you can link the new bug report here so those visiting this one can at least get visibility on your possibly related issue.

Jani, Ville, is there any way you can know what Windows and its iGPU driver does right in these hardware? Is there any other way to somehow control the suspect PMIC, perhaps with ACPI?

More importantly, can we be promised a fix for our related of set display issues? From us users' perspective, it's looking more like Intel hasn't really been keen on supporting Gemini Lake the same way as the more marketed parts. The ecosystem seem to lack a standardized way of doing things, and there's little to no documentation around to see. That's really frustrating, as we're now at a time where people are made to expect good Linux support for any of their Intel-powered devices. And the people who buy these lower-end devices aren't exactly those who can afford to buy a new one with better support. We want Linux on these devices because we want more longevity for our devices. It's just plain disappointing.

Sorry for the rant. I just want to have closure on this issue.
Comment 39 David Santamaría Rogado 2019-04-07 13:13:45 UTC
I'm pretty sure is exactly the same bug. Just to be sure, if someone experiencing this bug can try to boot Ubuntu 18.04 live, elementary 5.0, Mint 19 or any other based in the first one and can get display rotated -90 degrees will confirm it.
Comment 40 Danni Uptlen 2019-04-08 00:08:22 UTC
It is a different bug with different behaviour.  This bug and earlier test results are for the "base" model that has a resolution of 800 x 1280.

There is further information around different results between the different models here:
https://forums.lenovo.com/t5/Other-Linux-Discussions/Linux-on-Ideapad-D330/m-p/4307106
Comment 41 David Santamaría Rogado 2019-04-10 11:49:03 UTC
Got it, just to mention, the model miix 310 had exactly the same behaviour described for d330 1024x768 models but was resolved in recent kernel versions.
Comment 42 Mark Wynn Garcia 2019-04-18 10:49:08 UTC
Any updates here?
Comment 43 Jani Nikula 2019-04-18 11:06:20 UTC
(In reply to Mark Wynn Garcia from comment #38)
> David, I think the devs here prefer that you make a separate bug report
> specific to your SKU. Please also attach in the new bug report i915_vbt
> files and if possible also dmesg with  drm.debug=0x1e as detailed here:
> https://bugs.freedesktop.org/show_bug.cgi?id=108826 . Then maybe you can
> link the new bug report here so those visiting this one can at least get
> visibility on your possibly related issue.

Yeah, it's often pretty easy to confirm whether it's the same bug or not based on the dmesg. I suspect there are D330's with both DSI and eDP displays.
Comment 44 Mark Wynn Garcia 2019-04-18 11:22:31 UTC
Jani, do you think there may be some other reason other than the seemingly missing PMIC-specific data in the VBT? I would also like to understand how fbdev* or the bios could possibly properly power up the panel. Is there a generic power up sequence for DSI panels?
Comment 45 Jani Nikula 2019-04-18 11:41:05 UTC
(In reply to Mark Wynn Garcia from comment #38)
> Jani, Ville, is there any way you can know what Windows and its iGPU driver
> does right in these hardware? Is there any other way to somehow control the
> suspect PMIC, perhaps with ACPI?
> 
> More importantly, can we be promised a fix for our related of set display
> issues? From us users' perspective, it's looking more like Intel hasn't
> really been keen on supporting Gemini Lake the same way as the more marketed
> parts. The ecosystem seem to lack a standardized way of doing things, and
> there's little to no documentation around to see. That's really frustrating,
> as we're now at a time where people are made to expect good Linux support
> for any of their Intel-powered devices. And the people who buy these
> lower-end devices aren't exactly those who can afford to buy a new one with
> better support. We want Linux on these devices because we want more
> longevity for our devices. It's just plain disappointing.
> 
> Sorry for the rant. I just want to have closure on this issue.

I understand the frustration.

However I think early adopters of any new hardware on Linux should be aware that the support might not be there from day one. Sure, most of it works just fine, even most Geminilake based devices, but there's almost always a long tail of devices that might have issues.

You have to understand that the devices shipped running Windows. Usually the OEMs have done *zero* validation on Linux. Absolutely none. They may be Intel-powered devices, but, for example, Intel did not choose or integrate the display. You don't see the OEMs participating upstream or even on their own forums regarding Linux.

It's an impossible proposition to expect full Linux support and validation from Intel on all Intel CPU based devices running Windows the plethora of OEMs have conceived to produce.

Even so they mostly work remarkably well, and has lead to the high expectations.
Comment 46 Mark Wynn Garcia 2019-04-18 12:06:40 UTC
(In reply to Jani Nikula from comment #45)

I understand the situation. I just wish for better standardization so OEMs won't resort anymore to tricks outside of specification which could be a cause for this problem we have here.

Now I'll ask something that may come off as insinuating, but I promise this comes from genuine curiosity: Does Intel have a unified graphics driver team for both Windows and Linux? I'm asking this because I'd again like to know if there is some way to know what the Intel graphics driver for Windows could be doing right. I once installed a clean Windows installation on this same D330 device and I think I remember Windows before installing the iGPU driver behaving similar to Linux with i915 disabled, so there's a chance that it's not Windows per se that's doing something right, but the Windows iGPU driver.
Comment 47 Jani Nikula 2019-04-18 12:13:13 UTC
Suffice it to say *I* am not familiar with the Windows driver source. ;)

It's entirely possible we're missing something or doing something wrong in the i915 driver. It's also entirely possible something else related to e.g. GPIOs is wrong in the kernel outside of i915 driver.

The point remains, if it's not tested, it doesn't exist.
Comment 48 Jani Saarinen 2019-04-18 14:00:43 UTC
Hi, also we had some issues on our CI machine GLK-DSI that got fixed so that was rc1-breakage but system we have in CI seems to work now: https://intel-gfx-ci.01.org/tree/drm-tip/bat-all.html. See breakege and fix points: https://intel-gfx-ci.01.org/tree/drm-tip/fi-glk-dsi.html. But as said now that is working fine. Have you tried latest drm-tip and it still broken?
Comment 49 Mark Wynn Garcia 2019-04-18 14:07:06 UTC
(In reply to Jani Saarinen from comment #48)
> Hi, also we had some issues on our CI machine GLK-DSI that got fixed so that
> was rc1-breakage but system we have in CI seems to work now:
> https://intel-gfx-ci.01.org/tree/drm-tip/bat-all.html. See breakege and fix
> points: https://intel-gfx-ci.01.org/tree/drm-tip/fi-glk-dsi.html. But as
> said now that is working fine. Have you tried latest drm-tip and it still
> broken?

Ooh let me try it! I still have to figure out how to compile drm-tip with arch's kernel build system, but I have time tomorrow and this weekend.
Comment 50 Mark Wynn Garcia 2019-04-19 06:33:42 UTC
So I managed to build drm-tip and boot. Unfortunately the issue is still there. There seem to be more flickers though between grub and the login screen and while starting X11. I'll be following up with the dmesg logs.
Comment 51 Mark Wynn Garcia 2019-04-19 06:34:44 UTC
Created attachment 144039 [details]
dmesg-drm-tip-without-x11
Comment 52 Mark Wynn Garcia 2019-04-19 06:35:11 UTC
Created attachment 144040 [details]
dmesg-drm-tip-x11
Comment 53 Mark Wynn Garcia 2019-04-19 06:35:49 UTC
Created attachment 144041 [details]
dmesg-drm-tip-x11-xrandr-off-dsi-1
Comment 54 Mark Wynn Garcia 2019-04-19 07:56:35 UTC
Created attachment 144043 [details]
dmesg-experiment-from-sleep

Hmmm, so I did an experiment, with the external monitor removed and device screen active (backlight is on), I closed the lid and it supposedly goes into sleep mode (it seem to indicate with a sine wave brightness thing on the power button LED). When I opened it again the screen flashed a couple of times. You can see it in the attached dmesg logs following the MIPI_SEQ_* executions. This is still on the drm-tip kernel. I think this is interesting because somehow something is triggering DSI enable and it keeps retrying something.
Comment 55 Mark Wynn Garcia 2019-04-19 07:57:10 UTC
I meant "DSI disable", i.e. calling intel_dsi_disable.
Comment 56 Mark Wynn Garcia 2019-04-19 08:50:02 UTC
Created attachment 144045 [details]
dmesg-drm-tip-fastboot

No improvements with fastboot enabled (i915.fastboot=1), but coincidentally (this also sometimes happen without fastboot parameter) this shows off-on-off-on panel behavior, as indicated by the mipi sequences.

I'm starting to think there may be something problematic with the modesetting logic.
Comment 57 Mark Wynn Garcia 2019-04-19 09:00:19 UTC
Ugh, I failed to send my previous message which was quite long with details...

But I observed that the power offs are triggered by drm_atomic_commit -> intel_atomic_commit_tail -> *crtc_disable, which seems to be the modesetting process.

This also happens in the unpatched kernel, but seems to be normal modesetting process. So I decided to check if enabling fastboot would help by potentially eliminating that modeset.

So is there a way to verify what mode it is modesetting to?
Comment 58 Jani Saarinen 2019-05-02 09:35:53 UTC
There is now patch merged to drm-tip
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 59 Mark Wynn Garcia 2019-05-02 14:52:40 UTC
Awesome! Let me try this at once!
Comment 60 Jani Saarinen 2019-05-02 15:08:25 UTC
Just want to comment that on our GLK DSI system display was "broken" so not fully black but unusable and with this fix system boots now nice to console or desktop.
Comment 61 Mark Wynn Garcia 2019-05-02 23:28:13 UTC
Created attachment 144131 [details]
dmesg-drm-tip-with-corrupt-dsi-picture-fix

Unfortunately it still doesn't seem to fix the issue. Note that I'm also experiencing more flashes (likely modesets) than in vanilla kernel in between booting and login screen and in between login screen and starting X11.

I'm attaching dmesg here. It does look like it's now using 158400 as cdclk value.
Comment 62 Mark Wynn Garcia 2019-05-03 17:01:34 UTC
Created attachment 144151 [details]
dmesg-max-cdclk

So I tried something, which is to modify the patch and max the cdclk to 316800. It actually completely removed all flicker/modesetting that happens when starting X11. It also reduced flickering to just once instance in between grub and boot.

Right now I really want to know what will happen if we can remove that modeset on boot, that maybe at least we will preserve working states even if there is still a bug in i915's initialization routines for GLK. In the attached dmesg, I think these are what's triggering the modeset:

[    4.941737] [drm:pipe_config_err [i915]] mismatch in base.adjusted_mode.crtc_vtotal (expected 1334, found 1335)
[    4.941786] [drm:pipe_config_err [i915]] mismatch in base.adjusted_mode.crtc_vblank_end (expected 1334, found 1335)
[    4.941834] [drm:pipe_config_err [i915]] mismatch in dsi_pll.ctrl (expected 0x00000132, found 0x00000532)

I'll try hacking around this one, and if you any ideas, if you think this is a good direction to pursue, please let me know.
Comment 63 Stanislav Lisovskiy 2019-05-06 08:09:11 UTC
(In reply to Mark Wynn Garcia from comment #62)
> Created attachment 144151 [details]
> dmesg-max-cdclk
> 
> So I tried something, which is to modify the patch and max the cdclk to
> 316800. It actually completely removed all flicker/modesetting that happens
> when starting X11. It also reduced flickering to just once instance in
> between grub and boot.
> 
> Right now I really want to know what will happen if we can remove that
> modeset on boot, that maybe at least we will preserve working states even if
> there is still a bug in i915's initialization routines for GLK. In the
> attached dmesg, I think these are what's triggering the modeset:
> 
> [    4.941737] [drm:pipe_config_err [i915]] mismatch in
> base.adjusted_mode.crtc_vtotal (expected 1334, found 1335)
> [    4.941786] [drm:pipe_config_err [i915]] mismatch in
> base.adjusted_mode.crtc_vblank_end (expected 1334, found 1335)
> [    4.941834] [drm:pipe_config_err [i915]] mismatch in dsi_pll.ctrl
> (expected 0x00000132, found 0x00000532)
> 
> I'll try hacking around this one, and if you any ideas, if you think this is
> a good direction to pursue, please let me know.

I don't think those pipe config mismatches are triggering a modeset: those are just warnings when sw calculated and hw configs do not match(which happens quite often to be honest and often doesn't affect anything). Those checks are happening before modeset, which is triggered by userspace and just give warnings. 

You said you see some flickering, but do you see actual picture?

In your last log I also saw couple of weird modesets, when userspace tries to set 1366x768 resulution, while using fb of size 800x1200, which makes atomic_check and thus modesetting fail:

[    4.923785] [drm:drm_atomic_check_only [drm]] checking 000000008bb8c67f
[    4.923802] [drm:drm_atomic_check_only [drm]] [PLANE:62:plane 1B] invalid source coordinates 1366.000000x768.000000+0.000000+0.000000 (fb 800x1280)
[    4.923816] [drm:drm_atomic_check_only [drm]] [PLANE:62:plane 1B] atomic core check failed
Comment 64 Pavel Rojtberg 2019-05-09 15:05:06 UTC
Created attachment 144208 [details]
D330 display corruption

screen when booting with "nomodeset"
Comment 65 Pavel Rojtberg 2019-05-09 15:15:36 UTC
I have the D330 1200x1920 device, non LTE. With nomodeset I get a garbled picture (see attachment).
The pattern in the corruption suggests the display is reading with a wrong stride like if width/ height are swapped.

I get this behavior with Ubuntu 18.04.2 (Linux 4.18) and Ubuntu 19.04 (Linux 5.0).

An interesting finding however is that the experiment by "Mark Wynn Garcia" does work for me.
After exiting GRUB with default options (notably _without_ nomodest), I close the lid and wait for ~5min until the device went to sleep.
Opening the lid now results in the correct picture (at portrait 1200x1920 resolution) and things (xrandr --rotate) work as expected.

So it seems some panel data is read prematurely at boot that is re-read correctly on resume.

Again this works reproducible with both Ubuntu 18.04.2 and Ubuntu 19.04.
Comment 66 Pavel Rojtberg 2019-05-10 17:52:33 UTC
just noticed that gyro works on Ubuntu 19.04; rotating the Device is sufficient to make output work.
Comment 67 Stanislav Lisovskiy 2019-05-15 07:15:56 UTC
I think this bug is becoming now too general. It is like aggregation of all possible "my GLK DSI doesn't work" issues. I guess we will need to split those more properly or classify somehow as it is becoming really hard to track. 
I see there are people who can't get picture at all after grub, also there were who had picture, but issues with suspend/resume and corrupted picture. Those all most likely are different cases. 
People who have similar issues - please always create a separate bug, don't just write here, so that we can determine if it's a dup or not. Otherwise this is becoming too chaotic.
Comment 68 Stas KG 2019-06-19 10:25:07 UTC
I think some of your problems stem from the fact that there are *at least* three versions of D330-10IGM around:
- Celeron N4000 (UHD 600), 800 x 1280 screen, 
- Pentium N5000 (UHD 605), 1200 x 1920 screen
- Pentium N5000 (UHD 605), 1200 x 1920 screen, LTE and GPS modems

(not sure if the LTE modem makes a difference but comment #34 suggests it does)

Then there are 2 filed bugs:
- This one, 109267, seems to be for the Celeron version
- 108826 is for the Pentium version(s)

Which you probably know by now of course. But some people don't check and Pavel Rojtberg for example posted his observations about the Pentium version booting with nomodeset in the wrong bug. Maybe that's what got you confused.

Otherwise, I think it's fairly "simple", two relatively different devices with  different sets of problems but the same Lenovo name:
- The Celeron version (bug 109267) doesn't get any picture at all after booting no matter what you do
- The Pentium version (bug 108826) that boots to a black screen as well, but rotating the screen or waiting for the screen to go to sleep and waking it up again then reinitializes it properly (my observations on Ubuntu 19.04 w/ kernel 5.0).

Is there an option to clearly label these two bugs so crossposts don't happen as often?

Also, another problem seems to be that a lot of plain silly fixes are floating around the web, namely booting both of these devices with nomodeset and GRUB gfxpayload, which is not a real solution at all ... so you get a lot of garbled output.
Comment 69 Stanislav Lisovskiy 2019-07-12 08:24:49 UTC
There was a fix in a bug 108826, which could affect this one also. I would suggest everyone interested to test this:

https://patchwork.freedesktop.org/patch/317041/


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.