Ville Syrjälä ville.syrjala@linux.intel.com 於 2019年6月13日 週四 下午6:05寫道：
On Thu, Jun 13, 2019 at 04:37:48PM +0800, Jian-Hong Pan wrote:
Greg KH gregkh@linuxfoundation.org 於 2019年6月13日 週四 下午3:52寫道：
On Mon, Jun 10, 2019 at 02:01:39PM +0800, Jian-Hong Pan wrote:
Hi,
After apply the commit "drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled", it induces the screen to flicker when the CDCLK changes on the laptop like ASUS E406MA. [1]
So, we need these commits to prevent that: commit 48d9f87ddd21 drm/i915: Save the old CDCLK atomic state commit 2b21dfbeee72 drm/i915: Remove redundant store of logical CDCLK state commit 59f9e9cab3a1 drm/i915: Skip modeset for cdclk changes if possible
Jian-Hong Pan
Imre Deak (2): drm/i915: Save the old CDCLK atomic state drm/i915: Remove redundant store of logical CDCLK state
Ville Syrjälä (1): drm/i915: Skip modeset for cdclk changes if possible
drivers/gpu/drm/i915/i915_drv.h | 3 +- drivers/gpu/drm/i915/intel_cdclk.c | 155 ++++++++++++++++++++++----- drivers/gpu/drm/i915/intel_display.c | 48 +++++++-- drivers/gpu/drm/i915/intel_drv.h | 18 +++- 4 files changed, 186 insertions(+), 38 deletions(-)
These are all big patches, I would like to get an ack from the i915 developer(s) that these are acceptable for the stable tree before applying them...
thanks,
greg k-h
Hi Intel friends,
We have laptops like ASUS E406MA, which hits the issue: The audio playback does not work anymore after suspend & resume [1] Thanks for your contribution. We found the commit "drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled" can fix it. But, it induces the screen to flicker when the CDCLK changes on. So, we need these commits to be back ported to Linux stable 5.1.x tree to prevent flickering:
Pardon the delay.
Now that I refreshed my memory a bit I can't really see how this could fix anything, except by luck. Before these patches we always forced cdclk to be >=2*96 MHz so audio should never have hit this particular problem.
The reason for adding this extra complexity was to claw back a few milliwatts of power by allowing cdclk to drop below that magic limit when audio isn't needed.
I *think* these patches should probably work in 5.1, but for now I don't see this as anything more than bandaid for an unknown issue somewhere else. So I'd rather like a new bug filed at https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Int... with a full dmesg with drm.debug=0xe (+ some audio debug knob(s) which show when it's trying to poke the hw during suspend/resume) attached.
Thanks for your attention! I have filed the bug on freedesktop's bugzilla. https://bugs.freedesktop.org/show_bug.cgi?id=110916
I can upload more log information with guidance.
Jian-Hong Pan
59f9e9cab3a1 drm/i915: Skip modeset for cdclk changes if possible 2b21dfbeee72 drm/i915: Remove redundant store of logical CDCLK state 48d9f87ddd21 drm/i915: Save the old CDCLK atomic state 905801fe7237 drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
[1] https://bugzilla.kernel.org/show_bug.cgi?id=203623
May we have your comment or ack for the back port patches? https://www.spinics.net/lists/stable/msg308491.html https://www.spinics.net/lists/stable/msg310121.html https://www.spinics.net/lists/stable/msg310122.html https://www.spinics.net/lists/stable/msg310124.html https://www.spinics.net/lists/stable/msg310125.html
Thank you, Jian-Hong Pan
-- Ville Syrjälä Intel