On Thu, Jun 13, 2019 at 04:37:48PM +0800, Jian-Hong Pan wrote: > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 於 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 > > > > > > [1]: https://bugzilla.kernel.org/show_bug.cgi?id=203623#c12 > > > > > > 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/Intel 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. > > 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
