Created attachment 121876 [details] dmesg_S3.log & xrandr_S3.log How often does the steps listed above trigger the issue? always The following information about system: -- system architecture: i686 -- kernel version: 3.19 -- Linux distribution: Lubuntu -- Machine or mother board model:Bay trail-M N2920 -- Display connector: HDMI, DP, VGA -- Kernel Parameter: drm.debug=0x1e, log_buf_len=1M The DDI1_BKLTCTL has output at S3 resume on WIN7 /8, but Lubuntu 1404 Kernel 3.19 the DDI1_BKLTCTL is no signal at S3 resume. The xrand and dmesg file please reference the attachment. "dmesg.log" / "xrand.log" before enter S3. "dmesg_S3.log" / "xrand_S3.log" resume from S3. We are using Legacy VBIOS. To update the Fedora23's LiveCD,the DDI1_BKLTCTL still no output PWM.
Created attachment 121877 [details] dmesg.log
Created attachment 121878 [details] dmesg_S3.log
Created attachment 121879 [details] xrandr.log
Created attachment 121880 [details] xrandr_S3.log Please add plain text attachments individually instead of archives. Done now.
(In reply to shadow from comment #0) > -- Display connector: HDMI, DP, VGA > > The DDI1_BKLTCTL has output at S3 resume on WIN7 /8, but Lubuntu 1404 Kernel > 3.19 the DDI1_BKLTCTL is no signal at S3 resume. What is DDI1_BKLTCTL exactly? Is that some PWM output pin on your board, or in some display connector? In any case, per the dmesg and xrandr, your displays are not identified as an eDP (embedded display port) output. We don't have SoC PWM support for external displays or other PWM pins. What is your use case? Is this a somehow misconfigured eDP port, or do you need the PWM signal for something else?
Created attachment 121902 [details] DDI BKLT.png
Created attachment 121903 [details] CH7511 PWM.png
Created attachment 121904 [details] LVDS panel.png
(In reply to Jani Nikula from comment #5) > (In reply to shadow from comment #0) > > -- Display connector: HDMI, DP, VGA > > > > The DDI1_BKLTCTL has output at S3 resume on WIN7 /8, but Lubuntu 1404 Kernel > > 3.19 the DDI1_BKLTCTL is no signal at S3 resume. > > What is DDI1_BKLTCTL exactly? Is that some PWM output pin on your board, or > in some display connector? > > In any case, per the dmesg and xrandr, your displays are not identified as > an eDP (embedded display port) output. We don't have SoC PWM support for > external displays or other PWM pins. > > What is your use case? Is this a somehow misconfigured eDP port, or do you > need the PWM signal for something else? The DDI1_BKLTCTL is same as CRB, it is DDI backlight PWM signal. Please reference the "DDI BKLT.png". In our circuit, it is connected to CH7511B PWM input. And the CH7511B just only bypass the signal to LVDS panel. Please reference the "CH7511 PWM.png" and "LVDS panel.png". The Chrontel CH7511B is eDP to LVDS bridge. The DDI1_BKLTCTL is PWM signal. It can be used at Windows OS. Does it not use at the Linux OS?
(In reply to shadow from comment #9) > > The DDI1_BKLTCTL is PWM signal. It can be used at Windows OS. Does it not > use at the Linux OS? As Jani stated, the problem is that the port is identified as DP rather than DP. Please attach a copy of /sys/kernel/debug/dri/0/i915_opregion so we can check the VBT.
Created attachment 121930 [details] i915_opregion.log cat /sys/kernel/debug/dri/0/i915_opregion > i915_opregion.log
We seem to have neglected the bug a bit, apologies. Have you tried more recent kernels? 3.19 is quite old.
Based on the VBT, I *think* this should have been fixed by commit 972e7d71c82ea70100b808695d5cf735c1df5ef8 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Sep 11 21:04:39 2015 +0300 drm/i915: Ignore "digital output" and "not HDMI output" bits for eDP detection
Okay, I'm feeling optimistic, closing. Please reopen if the problem persists with that commit.
Thanks for update, we solve the issue by setting CSM to UEFI of the BIOS. It shows eDP and could resume S3 correctly. For new kernel, we get eDP and do not have to change to UEFI setting.
Thanks for the update. Indeed there can be and often are different VBT etc. for legacy vs. UEFI boots. The latter is recommended for newer hardware.
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.