Created attachment 144739 [details] drm-tip dmesg with drm.debug=0x1e from Irbis TW90 Hello! I find that backlight is flicker after suspend on certain Intel CherryTrail tablets. In particular, I reproduced this issue on Irbis TW90 and Lenovo Miix 320-10ICR. There is few ways of reproducing this issue, none is 100% reliable, but in general it boiling down to several suspend/wakeup cycles for a period of few hours. In attached Irbis TW90 log issue happened after two suspend/wakeup cycles, every suspend lasted for a ~3 hours. Other symptoms: 1. When backlight flicker occur brightness adjustment to 10-20% level makes screen completely black (backlight is disabled). This doesn't happen before suspend. 2. When backlight flicker occur brightness adjustment to 100% allow to temporary workaround issue at cost of battery time. 3. Reboot or power cycle usually doesn't help. When backlight flicker started it continue to happen everywhere, even in BIOS. Logs from drm-tip/2019-07-05 (ad5a0afdd20635e644d13406e1d1a7ec44398e0e) with drm.debug=0x1e from both devices is attached.
Created attachment 144740 [details] drm-tip dmesg with drm.debug=0x1e from Lenovo Miix 320-10ICR Additional information about hardware and software: Both devices have Intel Atom x5-Z8350 CPU and 2GB RAM. Both devices run Ubuntu 19.04 with Gnome Shell 3.32.2 session in Wayland mode and 200% scaling. libdrm version is 2.4.97
Other user found that issue is also reproducible on Irbis TW52 tablet: http://4pda.ru/forum/index.php?showtopic=942823&view=findpost&p=86750476
@Jani/Imre, any suggestions here?
(In reply to russianneuromancer from comment #0) > 3. Reboot or power cycle usually doesn't help. When backlight flicker > started it continue to happen everywhere, even in BIOS. How do you recover from this?
> How do you recover from this? Poweroff tablet for a ten minutes or so. User mentioned in Comment 2 said that eventually flicker go away if tablet is powered on too, but I didn't tried that.
Issue it reproducible with Linux 5.3rc3.
(In reply to russianneuromancer from comment #5) > > How do you recover from this? > > Poweroff tablet for a ten minutes or so. User mentioned in Comment 2 said > that eventually flicker go away if tablet is powered on too, but I didn't > tried that. @Jani any further comments here?
> User mentioned in Comment 2 said that eventually flicker go away if tablet is powered on too, but I didn't tried that. Tested this couple of days ago with rc3, I tried to left Lenovo Miix320-10ICR powered on with flicker screen for two hours, and flicker doesn't go away. So this does not help in my case. > Poweroff tablet for a ten minutes or so. It seems like this was necessary with Linux 5.0/5.1, but with more recent kernels (Linux 5.3 and drm-tip) simple reboot was sufficient, at least latest two times I tried to do this. Please let me know if I should test few latest Linux releases to find out since when reboot starting to be sufficient to workaround this issue.
I'm not sure what to look for, but let's check some basics first. Please provide the output of # intel_reg read 0x180000:0x61250 0x180000:0x61254 0x180000:0x61350 0x180000:0x61354 before and after it starts flickering. intel_reg is part of igt-gpu-tools.
Jani, note that the affected devices are using the LPSS PWM controller for backlight control (AFAICT).
Hum, is that right? Please attach /sys/kernel/debug/dri/0/i915_vbt
Created attachment 145114 [details] i915_vbt from Lenovo Miix320-10ICR > Please attach /sys/kernel/debug/dri/0/i915_vbt Attached.
Hmm, I think the VBT says it uses the CPU PWM.
I tried to use intel_rug but it doesn't read registers for some reason. intel-gpu-tools package from Ubuntu repository, version 1.2.2: ~$ sudo intel_reg read 0x180000:0x61250 0x180000:0x61254 0x180000:0x61350 0x180000:0x61354 Error: /usr/share/intel-gpu-tools/registers/gen7_other.txt:1: ('RCS_MODE_GEN7', '0x0000229c', '') Error: /usr/share/intel-gpu-tools/registers/cherryview:10: gen7_other.txt Warning: reading '/usr/share/intel-gpu-tools/registers/cherryview' failed. Using builtin register spec. (0x00180000:0x00061250): 0x00000000 (0x00180000:0x00061254): 0x00000000 (0x00180000:0x00061350): 0x00000000 (0x00180000:0x00061354): 0x00000000 Build from 1.2.4 tag of igt-gpu-tools git repository on freedesktop gitlab: ~/tools$ sudo ./intel_reg read 0x180000:0x61250 0x180000:0x61254 0x180000:0x61350 0x180000:0x61354 Error: /usr/local/share/igt-gpu-tools/registers/gen7_other.txt:1: ('RCS_MODE_GEN7', '0x0000229c', '') Error: /usr/local/share/igt-gpu-tools/registers/cherryview:10: gen7_other.txt Warning: reading '/usr/local/share/igt-gpu-tools/registers/cherryview' failed. Using builtin register spec. (0x00180000:0x00061250): 0x00000000 (0x00180000:0x00061254): 0x00000000 (0x00180000:0x00061350): 0x00000000 (0x00180000:0x00061354): 0x00000000 Not sure what I do wrong here.
I just recently found a bug in intel_reg that would explain this. It's fixed in igt master.
Output before and after suspend is with intel_reg build from today master: ~$ ./intel_reg read 0x180000:0x61250 0x180000:0x61254 0x180000:0x61350 0x180000:0x61354 PIPEA_BLC_PWM_CLT2 (0x00180000:0x00061250): 0x00000000 PIPEA_BLC_PWM_CTL (0x00180000:0x00061254): 0x00000000 PIPEB_BLC_PWM_CLT2 (0x00180000:0x00061350): 0x00000000 PIPEB_BLC_PWM_CTL (0x00180000:0x00061354): 0x00000000 ~$ ./intel_reg read 0x180000:0x61250 0x180000:0x61254 0x180000:0x61350 0x180000:0x61354 PIPEA_BLC_PWM_CLT2 (0x00180000:0x00061250): 0x00000000 PIPEA_BLC_PWM_CTL (0x00180000:0x00061254): 0x00000000 PIPEB_BLC_PWM_CLT2 (0x00180000:0x00061350): 0x00000000 PIPEB_BLC_PWM_CTL (0x00180000:0x00061354): 0x00000000
Is there anything else I can provide to help resolve this?
Created attachment 145791 [details] drm-tip dmesg with drm.debug=0x1e from Lenovo Miix 320-10ICR Issue is still reproducible with drm-tip 2019-10-21 54d0d8863278fb7c4f7496e57e59488ee75f15be After second wakeup screen is flicker.
Jani, any further help on this?
I have an Terra Pad 1061 which has this too, it also has another problem only 90-100% of the brightness range of the backlight sysfs interface is usable. I can fix the brightness range problem by disabling the pwm backlight support in the i915 driver with a quick hack. Then I can control the backlight smoothly using the entire duty-cycle range using /sys/class/pwm. I believe that the problem is that the i915 driver overrides the pwm frequency. At least the LPSS pwm driver supports the pwm atomic APIs now, which means the frequency set by the GOP gets read back from the PWM controller. I plan to add support for the PWM atomic API to drivers/pwm/pwm-crc.c and then convert the i915 pwm backlight code to use the atomic API and preserve the frequency. This does raise the question of what to do if the GOP has not initialized the PWM. I can test this on BYT / CHT hardware and see what happens when the GOP has not initialized the panel. I think that the flickering russianneuromancer is seeing might be related. ### Mostly unrelated: I found out this week that on BYT with a DSI panel when using the SoC/LPSS for PWM, and booting with a HDMI cable inserted so that the GOP will not initialize the panel, the panel will not light up. The problems is that when using the Crystal Cove PMIC for PWM we manually set the panel enable GPIO, we need similar code for the SoC/LPSS case. So far I have tested 3 BYT + DSI + LPSS devices and all 3 need this. I have writing a patch-set for this on my to do list.
(In reply to Jani Nikula from comment #13) > Hmm, I think the VBT says it uses the CPU PWM. I have access to both a Miix320 and an Irbis TW90 for testing, both my models use a DSI panel. AFAIK DSI panels always either the Crystal Cove PMIC PWM, or the LPSS PWM (which is part of the SoC). I guess you are basing this "I think the VBT says it uses the CPU PWM" on the dev_priv->vbt.dsi.config->pwm_blc bit ? When that is PPS_BLC_SOC then the LPSS PWM is used, not the PWM which is part of the display controller. Also see: drivers/gpu/drm/i915/display/intel_panel.c which has: } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) { if (connector->base.connector_type == DRM_MODE_CONNECTOR_DSI) { panel->backlight.setup = pwm_setup_backlight; panel->backlight.enable = pwm_enable_backlight; panel->backlight.disable = pwm_disable_backlight; panel->backlight.set = pwm_set_backlight; panel->backlight.get = pwm_get_backlight; } else { ... And pwm_setup_backlight() does: /* Get the PWM chip for backlight control */ panel->backlight.pwm = pwm_get(dev->dev, "pwm_backlight"); Which means it uses the pwm subsystem to talk to either the CRC or LPSS pwm controller. So AFAICT dumping the registers of the display-block PWM controller does not provide any useful info here. I actually wonder if the displayblock on CHT devices has the PWM controller at all.
-- 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/328.
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.