On Fri, Jun 14, 2019 at 01:59:51PM +0800, Jian-Hong Pan wrote:
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.
OK, I think I see what's going on. We would just need to change a few lines of code to fix that (basically just s/0/2*96000/ in two places) but we don't want that upstream anymore due to these patches.
So I guess we need to go ahead with the backport. I read through them and checked the 5.1 baseline and couldn't spot any problems. So for the backport to 5.1: Acked-by: Ville Syrjälä ville.syrjala@linux.intel.com