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

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.

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!

Created attachment 143114 [details]
dmesg drm-tip

please find drm-tip log file attached

CPU looks to be GLK N4000, document that.

Jani, looks like mipi/dsi issue?

It's DSI all right. Might be a dupe of bug #108826. Nothing suspicious AFAICS in dmesg.

On Ci https://intel-gfx-ci.01.org/tree/drm-tip/fi-glk-dsi.html system shows nicely desktop too.

Stan, do you see pattern here?

Hi,

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

Thanks,
Danni

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 ?

This sounds like the same/similar issue - however I have not tested external monitors.

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.

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.

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.

Please also attach /sys/kernel/debug/dri/0/i915_vbt on Lenove D330.

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

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

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.

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.

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.

Created attachment 143628 [details]
D330 acpidump

Hello Ville.

Attached is the acpidump output. Thanks for working on this!

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

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

Created attachment 143646 [details]
pinctrl dump - i915 disabled

Created attachment 143647 [details]
pinctrl dump - normal boot, no/before X11

Created attachment 143648 [details]
pinctrl dump - normal boot, within X11

Created attachment 143649 [details]
pinctrl dump - normal boot, within X11, xrandr DSI-1 off

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.

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

Created attachment 143670 [details]
pinctrl dump - ddc patch, within X11

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

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.

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.

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.

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.

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.

Sorry meant Fedora 28 not 18.

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.

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.

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

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.

Any updates here?

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

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?

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

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

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.

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?

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

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.

Created attachment 144039 [details]
dmesg-drm-tip-without-x11

Created attachment 144040 [details]
dmesg-drm-tip-x11

Created attachment 144041 [details]
dmesg-drm-tip-x11-xrandr-off-dsi-1

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.

I meant "DSI disable", i.e. calling intel_dsi_disable.

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.

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?

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?

Awesome! Let me try this at once!

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.

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.

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.

(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

Created attachment 144208 [details]
D330 display corruption

screen when booting with "nomodeset"

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.

just noticed that gyro works on Ubuntu 19.04; rotating the Device is sufficient to make output work.

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.

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.

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/

Is not for this bug exactly but to apply some patches to correct the display for the 1280x800 version.

¿Could someone with a 1280x800 panel version paste the output of the following command run as a normal user?
grep . /sys/class/dmi/id/* 2> /dev/null

Don't run as root to avoid displaying things like your own computer serial number.

The idea is to apply panel orientation correction to the HD version as is now for the FHD version.

Sure!

/sys/class/dmi/id/bios_date:01/16/2019
/sys/class/dmi/id/bios_vendor:LENOVO
/sys/class/dmi/id/bios_version:8NCN32WW
/sys/class/dmi/id/board_asset_tag:NO Asset Tag
/sys/class/dmi/id/board_name:LNVNB161216
/sys/class/dmi/id/board_vendor:LENOVO
/sys/class/dmi/id/board_version:SDK0K13475 WIN
/sys/class/dmi/id/chassis_asset_tag:NO Asset Tag
/sys/class/dmi/id/chassis_type:32
/sys/class/dmi/id/chassis_vendor:LENOVO
/sys/class/dmi/id/chassis_version:Lenovo ideapad D330-10IGM
/sys/class/dmi/id/modalias:dmi:bvnLENOVO:bvr8NCN32WW:bd01/16/2019:svnLENOVO:pn81H3:pvrLenovoideapadD330-10IGM:rvnLENOVO:rnLNVNB161216:rvrSDK0K13475WIN:cvnLENOVO:ct32:cvrLenovoideapadD330-10IGM:
/sys/class/dmi/id/product_family:ideapad D330-10IGM
/sys/class/dmi/id/product_name:81H3
/sys/class/dmi/id/product_sku:LENOVO_MT_81H3_BU_idea_FM_ideapad D330-10IGM
/sys/class/dmi/id/product_version:Lenovo ideapad D330-10IGM
/sys/class/dmi/id/sys_vendor:LENOVO
/sys/class/dmi/id/uevent:MODALIAS=dmi:bvnLENOVO:bvr8NCN32WW:bd01/16/2019:svnLENOVO:pn81H3:pvrLenovoideapadD330-10IGM:rvnLENOVO:rnLNVNB161216:rvrSDK0K13475WIN:cvnLENOVO:ct32:cvrLenovoideapadD330-10IGM:

Most of it seems the same with what's in drm_panel_orientation_quirks.c for the 1920x1200 version, though I believe the implementation does check for the resolution right?

Yes, that's why with 5.2 hd panel gets no corrected. I'm going to send a patch applying to both resolutions I think it should accept two entries with identical dmi data.

Most problematic is going to be the efifb pitch correction as stated by Hans de Goede.

Sended a patch to have panel orientation quirk in hd version to dri-devel.

I'm going to give here the same advise that in the other bug report, try Stanislav's patch removing all the kernel parameter you could have set, nomodeset gfxpayload and similars.

Created attachment 144834 [details] [review]
[PATCH] x86/sysfb_efi: Add quirks for some devices with swapped width and height

(In reply to David Santamaría Rogado from comment #72)
> Most problematic is going to be the efifb pitch correction as stated by Hans
> de Goede.

Here is a patch which I've just submitted upstream which fixes the efifb resolution and pitch issues. This has already been tested successfully on the Lenovo Miix 310, Mixx 320 and D330 1200x1920 version.

It should work without modification on the D330 800x1280 version.

Here is the patch for the panel orientation https://lists.freedesktop.org/archives/dri-devel/2019-July/227383.html.

Mark, if you use the Hans patch you should be able to use the laptop but as a tablet because using nomodeset will now show you good output but there is no screen rotation, so even with panel orientation quirk you will have vconsoles in the right orientation but wayland/x will only be in the wrong one.

Have you done more tests with Stanislav's patch? I have some issues with the keyboard while doing suspend resume, check it without the keyboard attached to see if something else is messing. I think intel uhd 600 and 650 should differ too much in their initialization.

Still have to apply Han's patch. However right now if I wanted to have proper console screen rotation I use gfxpayload=800x1280x32 along with fbcon=rotate:1.

I do have a consistent issue with my keyboard and touchpad stopping to work around 5 seconds after boot, before which I can login and start X. I then detach and reattach the keyboard base and it will resume working. I did notice the new keyboard firmware update they posted https://pcsupport.lenovo.com/ph/en/products/LAPTOPS-AND-NETBOOKS/IDEAPAD-D-SERIES-LAPTOPS/D330-10IGM/81H3/81H3005HPH/YN000DJ6/downloads/DS539081 and I'll try to boot Windows just to install it. Unfortunately Lenovo doesn't care about registering these devices to LVFS :(

Suspend/resume also still don't work for me, with blank screen on resume.

I meant shouldn't differ too much.

The issues I have with the keyboard are different, perhaps is something to do with the firmware you linked.

Mark, at least for me the keyboard firmware setup says that is not for my device or similar message, can't remember textually.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/210.