Created attachment 142557 [details] kernel log The screen after the grub is getting black ( backlight is still working ). System is booting normally - after that backlight screen is working .. and black all the time. I can control brightness by shortcuts. If connect HDMI cable then on the new via HDMI the screen works perfect but on the device screen is still black unfortunately . I attached the kernel. - edid from windows 10 Monitor Model name............... WLY-10102FHD Windows description...... Generic PnP Monitor Manufacturer............. AUO Plug and Play ID......... AUO17D8 Serial number............ n/a Manufacture date......... 2013, ISO week 11 Filter driver............ None ------------------------- EDID revision............ 1.4 Input signal type........ Digital Color bit depth.......... 8 bits per primary color Color encoding formats... RGB 4:4:4, YCrCb 4:4:4 Screen size.............. 140 x 220 mm (10,3 in) Power management......... Active off/sleep Extension blocs.......... None ------------------------- DDC/CI................... n/a Color characteristics Default color space...... sRGB Display gamma............ 3,55 Red chromaticity......... Rx 0,625 - Ry 0,340 Green chromaticity....... Gx 0,285 - Gy 0,605 Blue chromaticity........ Bx 0,148 - By 0,063 White point (default).... Wx 0,281 - Wy 0,309 Additional descriptors... None Thanks for any help.
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?
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
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 .
(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.
I see our GLK DSI on CI generally happy on BAT: https://intel-gfx-ci.01.org/tree/drm-tip/fi-glk-dsi.html
This is MIPI DSI panel - yes Device is a tablet ..so works on battery - yes
Do you need more details ?
(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.
Created attachment 142580 [details] drm.debug=0x1e log with param drm.debug=0x1e
Did that start to happen only with recent kernel? Can you please also attach kernel log with drm.debug with a working kernel?
There is no working kernel . I tested from 4.15 up to 4.20-rc1 ... akways the same - black screen after grub ( backlight works ) .
Hi Any ideas how to fix it ?
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/
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
+ Petri and Arek to comment deps.
Miroslaw, have you read README.md. Does it help?
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 ? .
(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.
Created attachment 142638 [details] igt-gpu-tools - dump i915.modeset=0_dump.txt
Created attachment 142639 [details] igt-gpu-tools - dump fully_working_gpu_driver_black_screen_dump.txt
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
So Any ideas ? ;-) Thanks
Just to double check, are you booting in UEFI mode and not in legacy BIOS mode?
I'm sure on 100 % - booting from UEFI
And no legacy BIOS mode.
So do I got any support about my problem ?
Jani, attached register dumps are helpful?
(In reply to Lakshmi from comment #27) > Jani, attached register dumps are helpful? See comment #13.
(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 ?
Apart from that your team has the tablet in the hands - Etab pro . Thanks for any solution .
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.
PS: I tried all mentioned above with E Tab pro.
HI, So you are saying that latest RC7 worked on that tablet and no black screen? > -----Original Message----- > From: intel-gfx-bugs [mailto:intel-gfx-bugs-bounces@lists.freedesktop.org] On > Behalf Of bugzilla-daemon@freedesktop.org > Sent: torstai 27. joulukuuta 2018 11.00 > To: intel-gfx-bugs@lists.freedesktop.org > Subject: [Bug 108826] [GLK DSI] Black screen after grub - Ubuntu 18.04 - kernel > latest tip 21.11.2018 > > Comment # 32 <https://bugs.freedesktop.org/show_bug.cgi?id=108826#c32> > on bug 108826 <https://bugs.freedesktop.org/show_bug.cgi?id=108826> from > Stanislav Lisovskiy <mailto:stanislav.lisovskiy@intel.com> > PS: I tried all mentioned above with E Tab pro. > > ________________________________ > > You are receiving this mail because: > > * You are on the CC list for the bug. > * You are the assignee for the bug. > * You are the QA Contact for the bug.
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.
I try the new kernel in 4th of January ...as I'm on holiday now .
> 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 .
(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.
Hi ...so did you check it again ? ... another week passed :-/
Created attachment 143247 [details] Attached pic showing logo after grub
(In reply to Miroslaw from comment #38) > Hi > ...so did you check it again ? ... another week passed :-/ Sorry, we had some severe bug to address. I checked it again - and with 4.20-rc7 I can see modeset, kernel log and Xubuntu logo after booting. I had also even attached a pics with that. Probably we need to figure out what is the difference still.
Created attachment 143248 [details] Kernel boots after modeset with Tux logo on E Tab
Ok again :) Look on the video with the panel "a" where we have problem https://streamable.com/uc5ct And second vieo with panel "b" here is ok . https://streamable.com/qkwjr Only difference between them is a screen panel . Stanislav Lisovskiy - on the early stage the screen is rotated to the left ( like on your screenshot ) but later ( after kms or initiate DRM GPU driver ) screen is rotated ( must be ) to the right . So you see only a very early booting process ...and nothing more . I replaced boot kernel and in the squash.sfs to 4.20... problem is still exist . And why you're trying Kubuntu not Ubuntu ? .
Created attachment 143262 [details] Ubuntu desktop Just as I expected, I was able to boot into Ubuntu desktop with E Tab Pro. It required a few tweaks like using overlay fs instead of aufs, rebuilding live cd image to use recent drm-tip kernel(basically I guess anything which starts from 4.20-rc7 would work, checked 4.20-rc7 and 5.0.0-rc3). Please see pics in the attachment. The touchscreen and mouse pointer do not work properly though, however the system is usable.
(In reply to Miroslaw from comment #42) > Ok again :) > > Look on the video with the panel "a" where we have problem > > https://streamable.com/uc5ct > > And second vieo with panel "b" here is ok . > > https://streamable.com/qkwjr > > > Only difference between them is a screen panel . Are you saying you have two models with different panels, and one of them has the problem and the other one doesn't? And presumably we've got a working model?
As far as I know you have "a" screen panel type . This panel has a problem . I tried 4.20 ( not RC ) and the panel wasn't work . Today I try kernel 5.0 and tip so ... try to confirm it ...
(In reply to Miroslaw from comment #42) > Ok again :) > > Look on the video with the panel "a" where we have problem > > https://streamable.com/uc5ct > > And second vieo with panel "b" here is ok . > > https://streamable.com/qkwjr > > > Only difference between them is a screen panel . > > > Stanislav Lisovskiy - on the early stage the screen is rotated to the left ( > like on your screenshot ) but later ( after kms or initiate DRM GPU driver ) > screen is rotated ( must be ) to the right . > > So you see only a very early booting process ...and nothing more . > > I replaced boot kernel and in the squash.sfs to 4.20... problem is still > exist . > > And why you're trying Kubuntu not Ubuntu ? . (In reply to Miroslaw from comment #45) > As far as I know you have "a" screen panel type . > This panel has a problem . > > I tried 4.20 ( not RC ) and the panel wasn't work . > Today I try kernel 5.0 and tip so ... try to confirm it ... Well for me it works, I can use Ubuntu desktop from there. I have sent a USB stick image to Ilya. Mostly the whole thing was just LiveCD tweaking, like squashfs, adding support for FUSE, OVERLAY_FS.
Touch screen works or not ? It should be only inverted. Also rotation should works. Can you confirm it ?
Just tell me if touch screen works . If not then you have to add support for Gemini lake in the kernel config....because without it for me screen also works But without GEMINI lake support rotation and touchscreen doesn't work .
(In reply to Miroslaw from comment #48) > Just tell me if touch screen works . > If not then you have to add support for > Gemini lake in the kernel config....because without it for me screen also > works > But without GEMINI lake support rotation and touchscreen doesn't work . This is something new. I didn't check it. Touch screen doesn't work. As I understood from previous conversation for this panel you had only blank screen, also in the video.
(In reply to Miroslaw from comment #11) > There is no working kernel . > I tested from 4.15 up to 4.20-rc1 ... akways the same - black screen after > grub ( backlight works ) . I thought this was a problem. I see no mentioning about the touchscreen in the bug description.
Because touch screen is working :-) and also rotation . Your kernel config is not proper. Add pin ctrl for gemini lake ( we have such platform ) Rebuild kernel and try then . If Gemini lake config ( pin ctrl ) is "on" everything works except screen. But on device with "b" screen everything works including screen.
Please have the exact same setup on both a and b device, add drm.debug=14 module parameter, and attach dmesg all the way from boot.
> If Gemini lake config ( pin ctrl ) is "on" everything works except screen. > But on device with "b" screen everything works including screen. You should have described this in the beginning. The bug originally was: "The screen after the grub is getting black ( backlight is still working ). System is booting normally - after that backlight screen is working .. and black all the time. I can control brightness by shortcuts. If connect HDMI cable then on the new via HDMI the screen works perfect but on the device screen is still black unfortunately . I attached the kernel. - edid from windows 10 Monitor Model name............... WLY-10102FHD Windows description...... Generic PnP Monitor Manufacturer............. AUO Plug and Play ID......... AUO17D8 Serial number............ n/a Manufacture date......... 2013, ISO week 11 Filter driver............ None ------------------------- EDID revision............ 1.4 Input signal type........ Digital Color bit depth.......... 8 bits per primary color Color encoding formats... RGB 4:4:4, YCrCb 4:4:4 Screen size.............. 140 x 220 mm (10,3 in) Power management......... Active off/sleep Extension blocs.......... None ------------------------- DDC/CI................... n/a Color characteristics Default color space...... sRGB Display gamma............ 3,55 Red chromaticity......... Rx 0,625 - Ry 0,340 Green chromaticity....... Gx 0,285 - Gy 0,605 Blue chromaticity........ Bx 0,148 - By 0,063 White point (default).... Wx 0,281 - Wy 0,309 Additional descriptors... None Thanks for any help." And no mentioning about that. I'm really happy to help, however don't have telepathy skills unfortunately :)
Gemini lake config is on in standard Ubuntu config for 18.04 . I didn't know you are using different config so why I had to mention about it ? Just make a config copy from kernel boot partition of Ubuntu 18.04...
(In reply to Miroslaw from comment #54) > Gemini lake config is on in standard Ubuntu config for 18.04 . > I didn't know you are using different config so why I had to mention about > it ? > Just make a config copy from kernel boot partition of Ubuntu 18.04... I just used default kernel config. To be honest it wasn't obvious to me that I have to use that one. However at least now I know. :) I will try then enabling it, then repeat again all this sequence and tell you the results.
(In reply to Miroslaw from comment #11) > There is no working kernel . > I tested from 4.15 up to 4.20-rc1 ... akways the same - black screen after > grub ( backlight works ) . That was basically what confused me actually, I thought you had no working kernel, as of this comment.
Miroslaw, please attach /sys/kernel/debug/dri/0/i915_vbt for each device type, with display a and with display b. The VBT contains display sequences to run at specific stages of display control, including changing GPIO states. This probably conflicts with pin control.
I tested newest tip kernel and 5.0rc4 - black screen ... vbt 915 logs I will attach later today .
(In reply to Miroslaw from comment #58) > I tested newest tip kernel and 5.0rc4 - black screen ... > vbt 915 logs I will attach later today . It was with PINCTRL_GEMINILAKE=y I suppose? If so, can you try to patch intel_dsi_vbt with this patch: diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c b/drivers/gpu/drm/i915/intel_dsi_vbt.c index 06a11c35a784..9b3c68a2f75c 100644 --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c @@ -371,7 +371,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data) vlv_exec_gpio(dev_priv, gpio_source, gpio_number, value); else if (IS_CHERRYVIEW(dev_priv)) chv_exec_gpio(dev_priv, gpio_source, gpio_number, value); - else + else if (!IS_GEMINILAKE(dev_priv)) bxt_exec_gpio(dev_priv, gpio_source, gpio_index, value); return data; --- With this patch from Jani, I can boot into Ubuntu desktop and PINCTRL_GEMINILAKE is turned on. However... touchscreen still doesn't work.
Also at least now I'm able to manually rotate screen and also manipulate with mouse, even though it is inverted: https://streamable.com/at6ik
Created attachment 143270 [details] kernel config for ubuntu Strange ... touch screen and auto rotation should works at one. Here is my config for kernel ( standard config for ubuntu 18.04 )
THE PATH HELPED. The "a" screen works finally. Also tested with "b" screen also is ok . You should add the path to the main kernel branch . Thanks for help
Can I have the VBT and full dmesg with both panel types attached please? See comment #52 and comment #57.
(In reply to Jani Nikula from comment #63) > Can I have the VBT and full dmesg with both panel types attached please? See > comment #52 and comment #57. Miroslaw?
Sorry I'm very busy lately. I make it tomorrow.
(In reply to Miroslaw from comment #65) > Sorry I'm very busy lately. > I make it tomorrow. Hello Miroslaw, i'm sorry but can you please not forget to resume with the team? There is a number of users unable to get Linux on their Ideapad D330 for the same issue stated here, we are waiting for the fix patiently.
Created attachment 143387 [details] xrandr output for Lenovo D330 laptop screen
Comment on attachment 143387 [details] xrandr output for Lenovo D330 laptop screen I've been following this bug as I have the exact device, Lenovo D330 with N5000 CPU and 1280x800 screen. https://forums.lenovo.com/t5/Linux-Discussion/Linux-on-Ideapad-D330/td-p/4296738/ I'm currently able to run vanilla Arch (4.20.8) with an external monitor without modeset and setting GRUB's gfxpayload. Still having the same problem as the others, with no display on the laptop screen but with [controllable] backlight. xrandr also is able to read the modes, please see attached file. I've applied and tested the above patch. Unfortunately it doesn't fix the problem. There is one instance though that arch's login prompt showed for a brief moment before the screen blanking. This is with video=800x1280.
Created attachment 143388 [details] Lenovo D330 with HD screen N5000 CPU vbt Jani, if this could also help I've attached my device's vbt.
Created attachment 143389 [details] Lenovo D330 with HD screen N5000 CPU dmesg with drm.debug=0x1e Also dmesg with drm.debug=0x1e with no other boot parameter modifications (no nomodeset or grub gfxpayload). This is with external monitor connected, which is DP (through USB-C dongle probably converting USB-C DP alternate mode to HDMI). Laptop screen is DSI. Additional details with laptop screen, Windows 10 detects an "active signal resolution" of 800x1280 but weirdly @ ~75 hz (which isn't included in the xrandr output). Sorry I won't be able to give more Windows 10 info as I nuked everything when I installed arch.
Created attachment 143390 [details] D330 dmesg unpatched 4.20.8 Sorry for previous dmesg attachment. Here's the proper one, with unpatched kernel v 4.20.8 from arch.
Created attachment 143391 [details] D330 dmesg patched 4.20.8 And here's for the patch, on same base kernel version.
I don't know what made anyone think this bug has anything to do with Lenovo D330. AFAIK the report is *not* about Lenovo D330. If the patch that helps the original reporter does not help you, it's also a clue you have a different bug. Please file a different bug. Miroslaw, we're still waiting for the details from you.
Here you go kernel_5.0-rc4-pathed--screen_a https://pastebin.com/0qg18CMi kernel_5.0-rc4-no-pathed--screen_a https://pastebin.com/EvCUPsBa kernel_5.0-rc4-pathed_screen_b https://pastebin.com/CCzLsPX1 kernel_5.0-rc4-not-pathed-screen_b https://pastebin.com/Y2jAV6UV I remind : The same device with 2 different screens Ssreen a - had a problem after kms with a "blank screen" .. path solved it Screen b - is ok no problems at all If you need more data just ask .
Based on the Comment 66, priority of this bug is set to Highest as many users are unable to get Linux on Ideapad D330.
(In reply to Lakshmi from comment #75) > Based on the Comment 66, priority of this bug is set to Highest as many > users are unable to get Linux on Ideapad D330. Please see comment #73 and reconsider. File a new bug for D330, this is not the one.
(In reply to Mark Wynn Garcia from comment #68) > Comment on attachment 143387 [details] > xrandr output for Lenovo D330 laptop screen > > I'm currently able to run vanilla Arch (4.20.8) with an external monitor > without modeset and setting GRUB's gfxpayload. Still having the same problem > as the others, with no display on the laptop screen but with [controllable] > backlight. xrandr also is able to read the modes, please see attached file. Can you please file a new bug for this case? That will help and speed up the investigation.
To stop any further messing with the thread, D330 bug has been filed already at: https://bugs.freedesktop.org/show_bug.cgi?id=109267
Created attachment 143589 [details] kernel_5.0-rc4-no-pathed--screen_a.txt Upload from comment #74.
Created attachment 143590 [details] kernel_5.0-rc4-not-pathed-screen_b.txt
Created attachment 143591 [details] kernel_5.0-rc4-pathed--screen_a.txt
Created attachment 143592 [details] kernel_5.0-rc4-pathed_screen_b.txt
(In reply to Miroslaw from comment #74) > Here you go > > kernel_5.0-rc4-pathed--screen_a > https://pastebin.com/0qg18CMi > > kernel_5.0-rc4-no-pathed--screen_a > https://pastebin.com/EvCUPsBa > > kernel_5.0-rc4-pathed_screen_b > https://pastebin.com/CCzLsPX1 > > kernel_5.0-rc4-not-pathed-screen_b > https://pastebin.com/Y2jAV6UV > > > I remind : > The same device with 2 different screens > > Ssreen a - had a problem after kms with a "blank screen" .. path solved it > Screen b - is ok no problems at all > > If you need more data just ask . Miroslaw, please attach /sys/kernel/debug/dri/0/i915_vbt for each device type, with display a and with display b. The VBT contains display sequences to run at specific stages of display control, including changing GPIO states. This probably conflicts with pin control. For future reference, please *attach* all logs and binaries etc. instead of using pastebin. The pastebins will go away eventually.
Created attachment 143866 [details] panel a i915_vbt
Created attachment 143867 [details] panel b i915_vbt
Created attachment 143868 [details] full drm/0 panel a
Created attachment 143869 [details] full drm/0 panel b
Hi Sorry I answer so late but I was very busy lately. I attach i915_vbt ... but looks exactly identical. So I also attach whole folders dri/0 for both panels. That not working properly panel "a" works ok now with the path ... until I sleep device...when I wake up device the screen is totally black not even backlight works only restart device helps ... until I sleep device again... I have the same result on panel "b" ( with that path but panel do not need it - just for test )... waking up device from sleep - ... only black screen. Without the path: - panel "a" only works until kernel starts loading drm driver then is black but backlight works. - panel "b" - everything is ok.. no problems.
Please also notice (if using rc1) https://bugs.freedesktop.org/show_bug.cgi?id=109516 currently DSI systems in CI broken too.
So ... You even have this tablet ( device ) and still now solved it. Have any idea how to fix it permanently ? Screen works only when GEMINILAKE config is is off ... But we can't awake the screen after sleep system - s3/s4 state ( ubuntu / android ).
Looking at Miroslaw's VBT files, looks like another case of "PPS GPIO Pins: Using PMIC". Is there any way for Intel devs to know what Windows and its iGPU driver does right with these hardware?
Jani N, any further comments here?
(In reply to Jani Nikula from comment #83) > (In reply to Miroslaw from comment #74) > > Here you go > > > > kernel_5.0-rc4-pathed--screen_a > > https://pastebin.com/0qg18CMi > > > > kernel_5.0-rc4-no-pathed--screen_a > > https://pastebin.com/EvCUPsBa > > > > kernel_5.0-rc4-pathed_screen_b > > https://pastebin.com/CCzLsPX1 > > > > kernel_5.0-rc4-not-pathed-screen_b > > https://pastebin.com/Y2jAV6UV > > > > > > I remind : > > The same device with 2 different screens > > > > Ssreen a - had a problem after kms with a "blank screen" .. path solved it > > Screen b - is ok no problems at all > > > > If you need more data just ask . > > Miroslaw, please attach /sys/kernel/debug/dri/0/i915_vbt for each device > type, with display a and with display b. > > The VBT contains display sequences to run at specific stages of display > control, including changing GPIO states. This probably conflicts with pin > control. > > For future reference, please *attach* all logs and binaries etc. instead of > using pastebin. The pastebins will go away eventually. Hi Jani, I write for the first time because I would like to say thanks you to you and your colleagues for the work you did until now. I ask you a little additional effort because the tablet still don't work properly, since there is some pending issue. You have this device in your hands, I think, so you can debug it easily because you can test everything. Please help us to close this ticket. Now we really need to close it because we are stopped on this project from December and we can't go ahead.
Stanislav Lisovskiy and Jani Nikula You're Intel devs ...why you still not solved it ( who will do that if you not )? You have that tablet in you hands and have skill to fix it. Please help us with it
(In reply to Miroslaw from comment #62) > THE PATH HELPED. > The "a" screen works finally. > Also tested with "b" screen also is ok . > > You should add the path to the main kernel branch . > > Thanks for help Hi again Miroslaw. To be honest, I stopped following this bug(we have plenty of other stuff also) after this comment above you made. I thought everything was fine after this. Can you please summarize again what doesn't work for you, because I thought everything worked fine as mentioned that "patch solved it". Need now again to grab this E-Tab back to my table.. Do I understand correctly that now you have a different issue related to suspend/resume? Jani Nikula: did you find anything suspicious from i915_vbt logs that you requested?
Panel "a" works ok now with the path ... until I sleep device ( Android or Linux ) ...when I wake up device the screen is totally black even backlight no works - only restart device helps ... until I sleep device again... I have the same result on panel "b" ( with that path but panel do not need it - just for test )... waking up device from sleep - ... only black screen..( when path is applied ) Summarize: Without the path: - panel "a" only works until kernel starts loading drm driver then is black but backlight works. - panel "b" - everything is ok.. no problems. With the path - panel "a" works until you sleep device ( s3 or s4 for instance ) then you have totally black screen - even backlight not working. - panel "b" works until you sleep device ( s3 or s4 for instance ) then you have totally black screen - even backlight not working.
(In reply to Miroslaw from comment #96) > Panel "a" works ok now with the path ... until I sleep device ( Android or > Linux ) ...when I wake up device the screen is totally black even backlight > no works - only restart device helps ... until I sleep device again... > I have the same result on panel "b" ( with that path but panel do not need > it - just for test )... waking up device from sleep - ... only black > screen..( when path is applied ) > > Summarize: > > Without the path: > - panel "a" only works until kernel starts loading drm driver then is black > but backlight works. > - panel "b" - everything is ok.. no problems. > > With the path > - panel "a" works until you sleep device ( s3 or s4 for instance ) then you > have totally black screen - even backlight not working. > > > - panel "b" works until you sleep device ( s3 or s4 for instance ) then you > have totally black screen - even backlight not working. Can you please share your kernel config, that you use(which works)? Or I see there is one in attachment - can I use that one?
Yes I'm using that config from the attachment I provided. Make sure Gemini lake pin config is active . Thanks for help .
The VBT blocks for the two panels are identical. Are the specs for the two panels identical? The VBT contains lots of configuration for the panel DPHY, initialization and enable/disable sequences. Are the requirements for the two panels identical? Has the VBT DSI configuration been tailored for the platform, board and panels? The sequences contain GPIO toggles and DSI DCS commands. Any generic VBT will not work. What is the origin of the VBT configuration? Did someone provide it to you or did you use the BMP tool to adjust and generate it?
We are using standard vbt config like kernel provides nothing more. Problem exist only on panel "a" ..panel "b" is ok. On windows panel "a" works ok like panel "b". Problem exist only in Linux / Android . I remind that you have that device so you can make any tests as you needs. Cheers
I've checked it with our local device and even with Gemini lake pin config disabled I can reproduce it, so pin ctrl most likely doesn't affect this at all.
(In reply to Stanislav Lisovskiy from comment #101) > I've checked it with our local device and even with Gemini lake pin config > disabled I can reproduce it, so pin ctrl most likely doesn't affect this at > all. Not so fast. We may *need* proper pin ctrl to actually make it work.
Hi Did you get any progress? May I help somehow yet?
We also noticed some issues on our GLK DSI system and this should be fixing that: https://patchwork.freedesktop.org/series/60065/. So are you able to test with this patch to see if better after this? We did not had black screen very "cracked" screen. This is about to be merged in soon.
This now merged: drm/i915: Corrupt DSI picture fix for GeminiLake author Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> 2019-04-30 15:51:19 committer Jani Nikula <jani.nikula@intel.com> 2019-05-02 10:46:55 +0300 commit beb29980026ffb38f990fbc3be9a0b89d9a15ea4 tree 976ace1740502ac0595317f64ce2f10ba6a361f7 parent dc76e5764a46ffb2e7f502a86b3288b5edcce191 Does this help here?
I'll check that in few hours and let you know.
I tried this path on screen "a" - still not working , the path nothing changed .
(In reply to Miroslaw from comment #107) > I tried this path on screen "a" - still not working , the path nothing > changed . That would be quite strange if that would fix it - we had corrupt picture issue MIPI DSI on GLK, which was due to some side effect for low CDCLK. I will try to switch to this task again now, if nothing else more important pops up.
..So any progress ?
(In reply to Stanislav Lisovskiy from comment #108) > (In reply to Miroslaw from comment #107) > > I tried this path on screen "a" - still not working , the path nothing > > changed . > > That would be quite strange if that would fix it - we had corrupt picture > issue MIPI DSI on GLK, which was due to some side effect for low CDCLK. > > I will try to switch to this task again now, if nothing else more important > pops up. Hi Stanislav, please help us to solve this issue. You have the device, I think, you can test when you want. Let me know.
Hi ... so any changes ?
(In reply to Jani Nikula from comment #102) > (In reply to Stanislav Lisovskiy from comment #101) > > I've checked it with our local device and even with Gemini lake pin config > > disabled I can reproduce it, so pin ctrl most likely doesn't affect this at > > all. > > Not so fast. We may *need* proper pin ctrl to actually make it work. Hi Jani, please help us to solve the issue, we opened this ticket on November 2018, 6 months ago. Really we don't know how to solve it, without your cooperation.
Hi sorry for not replying here in time, unfortunately I have some other issues to solve + being sick at home. However as I understand the current problem what you have is different from which we had originally - I mean that at the beginning you had a black screen after grub and now with path display is working, but now your problem is related to suspend/resume sequences. I do understand your frustration, but seems that we have quite a lot of different issues with MIPI DSI and bugs tend to become accumulation of all possible issues, like "my DSI is not working". If you don't really have now black screen after grub, can we just close this bug and create a new one, containing more precise description for current problem, like "sleeping GLK MIPI DSI doesn't recover the device". That would really help, if not solve, but at least properly classify and analyze the data, because solving different issues one-by-one in the same bug is not the way, how this is supposed to work.
There seem to be some issue with gpio pins used in vbt sequences used for Microtech Etab. I see that backlight gpio pin index 4 works as supposed, while accessing others actually breaks the display. That explains also why initially it did work without geminilake_pinctrl - it simply couldn't access those, which was visible in the log. I confirmed this also by adding small hack to mipi_exec_gpio function so that it doesn't touch pins 3, 6 which used for power_on and reset respectively. Then my etab works with geminilake_pinctrl, also I can see the backlight switching on/off during suspend/resume. However display still stays blank. To me it looks like either there is something wrong with the vbt sequence or those pins are misconfigured somehow.
...exactly as Stanislav Lisovskiy said . I wanted to say the same thing ;-).
(In reply to Miroslaw from comment #115) > ...exactly as Stanislav Lisovskiy said . > I wanted to say the same thing ;-). Do you happen to have any schematics for this Microtech Etab? I mean, I want to see all the connections between panel, SoC and etc..
I have checked the vbt sequences, pll settings, clocks and i915 seems to follow those properly(I have added a lot of debugs to verify this). However the problem is that whenever it touches gpios related to power and reset(GPIO index 3, 6) the screen gets corrupt(there is some picture it is actually not fully black), even though we seem to do everything according to vbt, which means that now we have to compare with Windows driver(which I don't have access to right now) and also get some schematics to understand what exactly is wrong with those. If we are not touching those faulty two pins - the screen is fine(which probably means that the rest of init sequence is correct), however suspend/resume doesn't work, I guess because without those pins, we don't have a way to properly power_on/reset the panel.
Hello Stanislav. It's very good to know you're considering looking into the Windows driver sources. This will definitely speed things up. :D Could you please share with us a patch of your hack? I want to try it on my device (D330), and looking into the VBT it seems it does touch GPIO index 3 on MIPI_SEQ_POWER_ON, though there's no sequence with GPIO index 6.
(In reply to Mark Wynn Garcia from comment #118) > Hello Stanislav. It's very good to know you're considering looking into the > Windows driver sources. This will definitely speed things up. :D > > Could you please share with us a patch of your hack? I want to try it on my > device (D330), and looking into the VBT it seems it does touch GPIO index 3 > on MIPI_SEQ_POWER_ON, though there's no sequence with GPIO index 6. GPIO index 6 is the reset: BDB block 53 - MIPI sequence block: Sequence block version v3 Sequence 1 - MIPI_SEQ_ASSERT_RESET GPIO index 6, number 135, set 1 (0x01) Delay: 12000 us GPIO index 6, number 135, set 0 (0x00) Delay: 5000 us GPIO index 6, number 135, set 1 (0x01) Sequence 3 - MIPI_SEQ_DISPLAY_ON Send DCS: Port A, VC 0, LP, Type 05, Length 1, Data 11 Send DCS: Port A, VC 0, LP, Type 15, Length 2, Data b0 5a Send DCS: Port A, VC 0, LP, Type 15, Length 2, Data b1 02 Send DCS: Port A, VC 0, LP, Type 15, Length 2, Data 39 49 Send DCS: Port A, VC 0, LP, Type 05, Length 1, Data 29 Sequence 4 - MIPI_SEQ_DISPLAY_OFF Send DCS: Port A, VC 0, LP, Type 05, Length 1, Data 28 Delay: 120000 us Send DCS: Port A, VC 0, LP, Type 05, Length 1, Data 10 Delay: 34000 us Sequence 5 - MIPI_SEQ_DEASSERT_RESET Delay: 10000 us GPIO index 6, number 135, set 0 (0x00) Sequence 6 - MIPI_SEQ_BACKLIGHT_ON GPIO index 4, number 145, set 1 (0x01) Delay: 2000 us Sequence 7 - MIPI_SEQ_BACKLIGHT_OFF GPIO index 4, number 145, set 0 (0x00) Delay: 1000 us Sequence 10 - MIPI_SEQ_POWER_ON GPIO index 3, number 144, set 1 (0x01) Delay: 5000 us Sequence 11 - MIPI_SEQ_POWER_OFF GPIO index 3, number 144, set 0 (0x00) The hack is as simple as doing something like this: git diff intel_dsi_vbt.c diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c b/drivers/gpu/drm/i915/intel_dsi_vbt.c index fbed9064ac7e..f9a2e351184f 100644 --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c @@ -324,6 +324,9 @@ static void bxt_exec_gpio(struct drm_i915_private *dev_priv, struct gpio_desc *gpio_desc = bxt_gpio_table[gpio_index]; if (!gpio_desc) { + if (gpio_index == 3 || gpio_index == 6) { + return; + } gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev, NULL, gpio_index, value ? GPIOD_OUT_LOW : Which is of course quite symptomatic treatment and suspend fails to recover still..
Created attachment 144350 [details] D330 vbt decoded Looks like it's 6 is to GPIO index 0 for mine. I'm applying the patch now to drm-tip. I'll try first with just index 3 disabled.
(In reply to Mark Wynn Garcia from comment #120) > Created attachment 144350 [details] > D330 vbt decoded > > Looks like it's 6 is to GPIO index 0 for mine. > > I'm applying the patch now to drm-tip. I'll try first with just index 3 > disabled. Yes exactly I saw your vbt for you it is 0.
Created attachment 144357 [details] 1200+1920IPS-WL-10102FHD-NT Hi The manufacturer PDF manual for that LCD screen.
In the manual pin 6 has no connection ( 0 ? ).
I also checked that path .. screen works util you not sleep device ...then we have still working blacklight but black screen.
(In reply to Miroslaw from comment #123) > In the manual pin 6 has no connection ( 0 ? ). I think this numbering is related to LCD screen itself rather than cpu package gpios, we still need to know how they are connected actually.
Stani. I think I know the problem. I'm still at work so I couldn't test it. I think it's because of the call to devm_gpiod_get_index() is only done once, with the first call's value. gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev, NULL, gpio_index, value ? GPIOD_OUT_LOW : GPIOD_OUT_HIGH); The look at gpiod_set_value() -> gpiod_set_value_nocheck() (https://github.com/torvalds/linux/blob/master/drivers/gpio/gpiolib.c#L3335). It flips the value if it's flagged as low. See also gpiod_configure_flags(). So if it happens that the initial call sets the GPIOD_OUT_LOW flag, then every subsequent calls will have the value flipped. So it can never set the GPIO to 1/true!
Oops I mistook GPIO_ACTIVE_LOW to be GPIOD_OUT_LOW... but I'll check further on this because I really feel there's a high chance it's this combination of static initialization pattern and the flags that may be causing all of this.
(In reply to Mark Wynn Garcia from comment #126) > Stani. I think I know the problem. I'm still at work so I couldn't test it. > > I think it's because of the call to devm_gpiod_get_index() is only done > once, with the first call's value. > > gpio_desc = devm_gpiod_get_index(dev_priv->drm.dev, > NULL, gpio_index, > value ? GPIOD_OUT_LOW : GPIOD_OUT_HIGH); > > The look at gpiod_set_value() -> gpiod_set_value_nocheck() > (https://github.com/torvalds/linux/blob/master/drivers/gpio/gpiolib.c#L3335). > It flips the value if it's flagged as low. See also gpiod_configure_flags(). > So if it happens that the initial call sets the GPIOD_OUT_LOW flag, then > every subsequent calls will have the value flipped. So it can never set the > GPIO to 1/true! This would probably make almost all panels unusable :) Also even for this tablet backlight is working as expected..
Please sanity check this: https://github.com/torvalds/linux/blob/3601fe43e8164f67a8de3de8e988bfcb3a94af46/include/dt-bindings/gpio/gpio.h#L15 #define GPIO_ACTIVE_LOW 1 https://github.com/torvalds/linux/blob/903b77c631673eeec9e9114e9524171cdf9a2646/include/linux/gpio/consumer.h#L51 #define GPIOD_FLAGS_BIT_DIR_SET BIT(0) #define GPIOD_FLAGS_BIT_DIR_OUT BIT(1) ... GPIOD_OUT_LOW = GPIOD_FLAGS_BIT_DIR_SET | GPIOD_FLAGS_BIT_DIR_OUT, so GPIO_ACTIVE_LOW == GPIOD_OUT_LOW !!!(?)
> This would probably make almost all panels unusable :) Also even for this tablet backlight is working as expected.. Ah, my mistake. I should have just looked into GPIOD_OUT_HIGH too. I got too excited I guess. 🤦🏽♂️
(In reply to Mark Wynn Garcia from comment #129) > Please sanity check this: > > https://github.com/torvalds/linux/blob/ > 3601fe43e8164f67a8de3de8e988bfcb3a94af46/include/dt-bindings/gpio/gpio.h#L15 > > #define GPIO_ACTIVE_LOW 1 > > https://github.com/torvalds/linux/blob/ > 903b77c631673eeec9e9114e9524171cdf9a2646/include/linux/gpio/consumer.h#L51 > > #define GPIOD_FLAGS_BIT_DIR_SET BIT(0) > #define GPIOD_FLAGS_BIT_DIR_OUT BIT(1) > > ... > > GPIOD_OUT_LOW = GPIOD_FLAGS_BIT_DIR_SET | GPIOD_FLAGS_BIT_DIR_OUT, > > so GPIO_ACTIVE_LOW == GPIOD_OUT_LOW !!!(?) Yes, it is the same value. However gpiod_get_index function doesn't take it as a parameter - enum gpiod_flags does not contain GPIO_ACTIVE_LOW among possible flag values, so it doesn't really matter.
Miroslaw, do you happen to have any other documents for Microtech Etab? Would be nice to see the actual schematics..
Created attachment 144378 [details] SF101G-MT_LCD_WLY10110-BNT_V1.0-G Hi This is all what we got from the Chinese supplier about that screen ... I hope will help.
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.
Created attachment 144393 [details] Allegro
Created attachment 144394 [details] Schematic TOP
Created attachment 144395 [details] Schematic BOT
(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.
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.
(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?
(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.
Disabling suspend mode is not a solution for us at all...
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.
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.
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.
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.
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...
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...
(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.
(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!
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.
(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).
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.
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.
(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.
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.
(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?
(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.
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.
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.
(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.
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.
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/
Created attachment 144752 [details] [review] Fix escape clock pll divisor init
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!
I have to test it as well ;-) ... later let you know ...
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.
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
(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.
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 .
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.
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
Based on comment from reporter Miroslaw: > I made tests > - screen works during boot kernel and later Ubuntu ! > - Suspend/Resume .. WORKS ! finally > .. make some more tests tomorrow but seems works finally proper ! > Great job after 6 months ;-D Closing this particular bug to avoid generalizing it to some common GLK DSI issue discussion. Those who still have issues - please file another bugs - that would make analyzing them and classification easier.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.