Created attachment 130813 [details] dmesg ==Bug detailed description== -------------------------------------------------- Mipi screen gets blank screen after resuming from S3 state ==Steps to reproduce== -------------------------------------------------- # echo mem > /sys/power/state Resume system ==Actual results== -------------------------------------------------- Mipi screen gets blank screen after resuming from S3 state ==Expected results== -------------------------------------------------- displays should resume with no corruption nor any kind of failures ==Hardware configuration== -------------------------------------------------- CPU Name : Genuine Intel(R) CPU @ 1.10GHz (family: 6, model: 122) 4 cores Graphic: Intel Corporation Device 3184 (rev 01) prog-if 00 VGA controller RVP SKU : GLK RVP1 SOC : GML A1 Soc QDF : Ql9R Reworks : F23 Display: MIPI AUO 10.1" 1920x1200 Non-Touch MIPI Kit - B101UAN01.7 ==Software configuration== -------------------------------------------------- kernel version : 4.11.0-rc6-drm-tip-madhav-config-ok-g1a8653e-dirty architecture : x86_64 os version : Ubuntu 16.10 kernel driver : i915 bios revision : 32.30 ksc : 1.19 mesa : 17.1.0-devel (git-957ccbe xf86-video-intel (tag) : 2.99.917 xorg-xserver : 1.18.4 libdrm : 2.4.79 cairo : 1.15.5 xserver : X.Org X Server 1.19.99.1 ==kernel configuration== -------------------------------------------------- commit 1a8653e657e1154a337956033af17740ef5f9dda Author: Jani Nikula <jani.nikula@intel.com> Date: Tue Apr 11 17:18:53 2017 +0300 drm-tip: 2017y-04m-11d-14h-18m-13s UTC integration manifest ==Attachments== -------------------------------------------------- dmesg
[ 59.716402] [drm:intel_dsi_prepare] pipe A [ 59.716416] [drm:intel_dsi_vbt_exec_sequence] Starting MIPI sequence 10 - MIPI_SEQ_POWER_ON [ 59.716419] [drm:mipi_exec_gpio] [ 59.716786] [drm:mipi_exec_gpio] *ERROR* GPIO index 3 request failed (-517) 517 is EPROBE_DEFER.
Luis, can you attach your kernel config to the bug? Also, please recompile the kernel with the option CONFIG_DEBUG_GPIO set, run the test again and attach a new dmesg.
Created attachment 131032 [details] config
(In reply to Ander Conselvan de Oliveira from comment #2) > Luis, can you attach your kernel config to the bug? > > Also, please recompile the kernel with the option CONFIG_DEBUG_GPIO set, run > the test again and attach a new dmesg. Issue is also seen for Suspend to disk. Adding dmesgGpioDebug
Created attachment 131033 [details] dmesgGpioDebug
Created attachment 131120 [details] [review] Hackish fix This is not a finished solution for the problem, but with the attached patch I do get image on the DSI screen after suspend/resume. The bulk of the problem is that certain registers can only be written from the middle of device ready sequence.
Btw, Luis, you need to set CONFIG_PINCTRL_GEMINILAKE=y in your kernel config.
Created attachment 131214 [details] [review] Temp Patch 1
Created attachment 131215 [details] [review] Temp Patch 2
Luis: Can you verify S3/S4/HDMI Connected Boot. Tested S3, works fine. Couldnt test S4/connected HDMI boot some board issue.
Created attachment 131217 [details] dmesgS3HDMIandMIPI
Hi Madhav I tried both S3/S4 with HDMI and MIPI panel, here are my findings: Mipi Boot up - OK S3 - MIPI Screen is slightly shifted to right / Flickering S4 - MIPI Screen is slightly shifted to right / Flickering Mipi plus HDMI Boot up - MIPI Screen is slightly shifted to right/No Flickering S3 - MIPI Screen is slightly shifted to right/No Flickering S4 - MIPI Screen is slightly shifted to right/No Flickering
Created attachment 131218 [details] dmesgS3Mipi
Created attachment 131219 [details] dmesgS4HMDIandMIPI
Created attachment 131220 [details] dmesgS4MIPI
Created attachment 131227 [details] [review] Tmp Patch fixing S3 and Flicker/Screenhift issue Luis: Please verify S3/S4/HDMI(MIPI) with this patch. Tested with standalone DSI panel S3 works without any flickering/screen shift.
(In reply to Madhav Chauhan from comment #16) > Created attachment 131227 [details] [review] [review] > Tmp Patch fixing S3 and Flicker/Screenhift issue > > Luis: Please verify S3/S4/HDMI(MIPI) with this patch. Tested with standalone > DSI panel S3 works without any flickering/screen shift. Hi Madhav: It is working now with this patch. Waiting for patch to be upstream in order to close this bug.
Let keep this open until the patch is merged.
Created attachment 131638 [details] Patch after review comments. Luis: Please test this patch for all the scenarios i.e S3/S4, Connected HDMI on the drm-tip. This patch includes review comments.
Issue is not seen anymore with that the latest patch provided by Madhav "Patch after review comments." HDMI and MIPI works fine after s3 and s4. Waiting for patch to be upstream in order to close this bug
(In reply to Luis Botello from comment #20) > Issue is not seen anymore with that the latest patch provided by Madhav > "Patch after review comments." > HDMI and MIPI works fine after s3 and s4. > Waiting for patch to be upstream in order to close this bug We do not resolve bugs before the patches have actually landed. Reopen.
Created attachment 131827 [details] Patch1 after splitting glk device ready functionality
Created attachment 131828 [details] Patch2 after splitting glk device ready functionality
As per discussion over mailing list, we need to divide glk_dsi_device_ready() functionality in 2 parts and then enable the cold boot sequence. Luis: Attached 2 patches, please test them on drm-tip.
System works fine if only MIPI panel is connected to platform. However, if MIPI and HDMI panels are connected to platform at the same time, system hangs as soon as it loads UI (tty7). For tty1 to tty6 if startx is initialized, mouse pointer is not seen and some glitches are observed if mouse is moved around the screen. I am adding dmesg_startx and Xorg.o.log_startx
Created attachment 131909 [details] dmesg_startx
Created attachment 131910 [details] Xorg.o.log_startx
Thanks for sharing the result Luis. I wonder why results are different with these patches comparing to older one. Technically old and new patches are doing same thing. New patch divide the overall changes in 2 parts thats all. Just to make sure that issue is due to these 2 patches or something broken on drm-tip, Can you please verify old patch on the latest drm-tip??
I tested DSI + HDMI with the latest drm-tip code, commit: 66555696fc0f33fc19eca5068783b95ecc8a91d5. And connected boot and S3 works fine without any issue.. Luis: looks like you observed hang due to some Xserver issue.
(In reply to Luis Botello from comment #25) > For tty1 to tty6 if startx is initialized, mouse pointer is not seen and > some glitches are observed if mouse is moved around the screen. I've seen a similar issue that is independent of DSI but related to dual screen usage in general. I bisected it to the new ddb allocation algorithm. Rodrigo sent a patch to revert the bad commit since he also has issues with it: https://patchwork.freedesktop.org/patch/161456/ It probably makes sense to test again including the patch from the link above.
Mahesh also sent proposal to test: "Can you please try with following patch to see if it's solving the problem. https://patchwork.freedesktop.org/patch/161571/"
(In reply to Jani Saarinen from comment #31) > Mahesh also sent proposal to test: > "Can you please try with following patch to see if it's solving the problem. > https://patchwork.freedesktop.org/patch/161571/" That's a proposed fix for the unrelated bug, but asking Luis to test this here only makes this bug more complicated than it should be. Let's focus on testing the DSI issue here. The fix proposed by Mahesh should be tracked elsewhere. And for the record, at least in my own testing, that doesn't fix the issue.
Agree, ignore my comment.
But how come i didnt see the issue observed by Luis. I tested yesterday latest drm-tip. Is it having some dependency on Xerver versions??
(In reply to Madhav Chauhan from comment #34) > But how come i didnt see the issue observed by Luis. I tested yesterday > latest drm-tip. Is it having some dependency on Xerver versions?? I don't think we know the exact cause of the problem yet, so it is hard to tell. I suppose differences in watermarks, which do depend on how the planes are being used. So there could be a dependency to userspace. I opened bug 101441. Let's keep the discussion about the dual screen artifacts there and focus on the DSI blank screen here.
Agree with you Ander.
commit 8a1deb329ffbdb049f6a475cf535644a81e80b55 Author: Madhav Chauhan <madhav.chauhan@intel.com> Date: Tue Jun 13 13:18:15 2017 +0530 drm/i915/glk: Add cold boot sequence for GLK DSI commit 74e4ce6a78751f0a602dcbd00b53f710e312fcc5 Author: Madhav Chauhan <madhav.chauhan@intel.com> Date: Tue Jun 13 13:18:14 2017 +0530 drm/i915/glk: Split GLK DSI device ready functionality in drm-intel-next-queued.
(In reply to Jani Nikula from comment #37) > commit 8a1deb329ffbdb049f6a475cf535644a81e80b55 > Author: Madhav Chauhan <madhav.chauhan@intel.com> > Date: Tue Jun 13 13:18:15 2017 +0530 > > drm/i915/glk: Add cold boot sequence for GLK DSI > > commit 74e4ce6a78751f0a602dcbd00b53f710e312fcc5 > Author: Madhav Chauhan <madhav.chauhan@intel.com> > Date: Tue Jun 13 13:18:14 2017 +0530 > > drm/i915/glk: Split GLK DSI device ready functionality > > in drm-intel-next-queued. Resolving as FIXED. Luis, can you please verify?
Luis verified these patches and he was observing cusrsor/UI hang. Do we need another round of testing??
Cursor/UI hang due to WM issue as you described earlier :)
Issue is not seen anymore with the latest drm-tip kernel
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.