* [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers @ 2016-08-03 16:09 Chris Wilson 2016-08-03 16:39 ` ✗ Ro.CI.BAT: failure for " Patchwork 2016-08-04 16:44 ` [PATCH] " Daniel Vetter 0 siblings, 2 replies; 6+ messages in thread From: Chris Wilson @ 2016-08-03 16:09 UTC (permalink / raw) To: intel-gfx; +Cc: Takashi Iwai, stable On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display power well and so the sna-hda audio codec acquires the display power well while it is operational. However, Skylake separates the powerwells again, but yet we still need the audio powerwell to setup the registers. (But then the hardware uses those registers even while powered off???) v2: Grab both rpm wakelock and audio wakelock Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96214 Fixes: 03b135cebc47 "ALSA: hda - remove dependency on i915 power well for SKL") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Libin Yang <libin.yang@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Marius Vlad <marius.c.vlad@intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org --- drivers/gpu/drm/i915/intel_audio.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 5d5f6bc10e85..948a7a52e3f8 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -600,6 +600,8 @@ static void i915_audio_component_codec_wake_override(struct device *dev, if (!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv)) return; + i915_audio_component_get_power(dev); + /* * Enable/disable generating the codec wake signal, overriding the * internal logic to generate the codec wake to controller. @@ -615,6 +617,8 @@ static void i915_audio_component_codec_wake_override(struct device *dev, I915_WRITE(HSW_AUD_CHICKENBIT, tmp); usleep_range(1000, 1500); } + + i915_audio_component_put_power(dev); } /* Get CDCLK in kHz */ @@ -648,6 +652,7 @@ static int i915_audio_component_sync_audio_rate(struct device *dev, !IS_HASWELL(dev_priv)) return 0; + i915_audio_component_get_power(dev); mutex_lock(&dev_priv->av_mutex); /* 1. get the pipe */ intel_encoder = dev_priv->dig_port_map[port]; @@ -698,6 +703,7 @@ static int i915_audio_component_sync_audio_rate(struct device *dev, unlock: mutex_unlock(&dev_priv->av_mutex); + i915_audio_component_put_power(dev); return err; } -- 2.8.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 6+ messages in thread
* ✗ Ro.CI.BAT: failure for drm/i915: Acquire audio powerwell for HD-Audio registers 2016-08-03 16:09 [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers Chris Wilson @ 2016-08-03 16:39 ` Patchwork 2016-08-04 16:44 ` [PATCH] " Daniel Vetter 1 sibling, 0 replies; 6+ messages in thread From: Patchwork @ 2016-08-03 16:39 UTC (permalink / raw) To: Chris Wilson; +Cc: intel-gfx == Series Details == Series: drm/i915: Acquire audio powerwell for HD-Audio registers URL : https://patchwork.freedesktop.org/series/10607/ State : failure == Summary == Series 10607v1 drm/i915: Acquire audio powerwell for HD-Audio registers http://patchwork.freedesktop.org/api/1.0/series/10607/revisions/1/mbox Test gem_exec_gttfill: Subgroup basic: skip -> PASS (fi-snb-i7-2600) Test kms_cursor_legacy: Subgroup basic-flip-vs-cursor-legacy: fail -> PASS (ro-hsw-i7-4770r) fail -> PASS (ro-bdw-i7-5600u) pass -> FAIL (ro-bdw-i5-5250u) fail -> PASS (ro-skl3-i5-6260u) Subgroup basic-flip-vs-cursor-varying-size: pass -> FAIL (ro-bdw-i5-5250u) pass -> FAIL (fi-skl-i7-6700k) fi-hsw-i7-4770k total:240 pass:218 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-qkkr total:240 pass:181 dwarn:29 dfail:0 fail:3 skip:27 fi-skl-i5-6260u total:240 pass:224 dwarn:0 dfail:0 fail:2 skip:14 fi-skl-i7-6700k total:240 pass:208 dwarn:0 dfail:0 fail:4 skip:28 fi-snb-i7-2600 total:240 pass:198 dwarn:0 dfail:0 fail:0 skip:42 ro-bdw-i5-5250u total:240 pass:218 dwarn:4 dfail:0 fail:2 skip:16 ro-bdw-i7-5557U total:240 pass:224 dwarn:0 dfail:0 fail:0 skip:16 ro-bdw-i7-5600u total:240 pass:207 dwarn:0 dfail:0 fail:1 skip:32 ro-bsw-n3050 total:240 pass:194 dwarn:0 dfail:0 fail:4 skip:42 ro-hsw-i3-4010u total:240 pass:214 dwarn:0 dfail:0 fail:0 skip:26 ro-hsw-i7-4770r total:240 pass:214 dwarn:0 dfail:0 fail:0 skip:26 ro-ilk-i7-620lm total:240 pass:173 dwarn:1 dfail:0 fail:1 skip:65 ro-ilk1-i5-650 total:235 pass:173 dwarn:0 dfail:0 fail:2 skip:60 ro-ivb-i7-3770 total:240 pass:205 dwarn:0 dfail:0 fail:0 skip:35 ro-ivb2-i7-3770 total:240 pass:209 dwarn:0 dfail:0 fail:0 skip:31 ro-skl3-i5-6260u total:240 pass:223 dwarn:0 dfail:0 fail:3 skip:14 ro-snb-i7-2620M total:240 pass:198 dwarn:0 dfail:0 fail:1 skip:41 ro-byt-n2820 failed to connect after reboot Results at /archive/results/CI_IGT_test/RO_Patchwork_1685/ 4d6f224 drm-intel-nightly: 2016y-08m-03d-15h-38m-31s UTC integration manifest 2115f59 drm/i915: Acquire audio powerwell for HD-Audio registers _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers 2016-08-03 16:09 [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers Chris Wilson 2016-08-03 16:39 ` ✗ Ro.CI.BAT: failure for " Patchwork @ 2016-08-04 16:44 ` Daniel Vetter 2016-08-04 18:05 ` [Intel-gfx] " Takashi Iwai 1 sibling, 1 reply; 6+ messages in thread From: Daniel Vetter @ 2016-08-04 16:44 UTC (permalink / raw) To: Chris Wilson; +Cc: Takashi Iwai, intel-gfx, stable On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote: > On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display > power well and so the sna-hda audio codec acquires the display power > well while it is operational. However, Skylake separates the powerwells > again, but yet we still need the audio powerwell to setup the registers. > (But then the hardware uses those registers even while powered off???) Yeah feels fishy, but will at least duct-tape over the breakage from the audio side. Most likely the reg writes go exactly nowhere and there's a bug on the audio side. And this patch doesn't fix that. But it does what it says on the tin, and it gets the job done. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > v2: Grab both rpm wakelock and audio wakelock > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96214 > Fixes: 03b135cebc47 "ALSA: hda - remove dependency on i915 power well for SKL") > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Libin Yang <libin.yang@intel.com> > Cc: Takashi Iwai <tiwai@suse.de> > Cc: Marius Vlad <marius.c.vlad@intel.com> > Tested-by: Hans de Goede <hdegoede@redhat.com> > Cc: stable@vger.kernel.org > --- > drivers/gpu/drm/i915/intel_audio.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c > index 5d5f6bc10e85..948a7a52e3f8 100644 > --- a/drivers/gpu/drm/i915/intel_audio.c > +++ b/drivers/gpu/drm/i915/intel_audio.c > @@ -600,6 +600,8 @@ static void i915_audio_component_codec_wake_override(struct device *dev, > if (!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv)) > return; > > + i915_audio_component_get_power(dev); > + > /* > * Enable/disable generating the codec wake signal, overriding the > * internal logic to generate the codec wake to controller. > @@ -615,6 +617,8 @@ static void i915_audio_component_codec_wake_override(struct device *dev, > I915_WRITE(HSW_AUD_CHICKENBIT, tmp); > usleep_range(1000, 1500); > } > + > + i915_audio_component_put_power(dev); > } > > /* Get CDCLK in kHz */ > @@ -648,6 +652,7 @@ static int i915_audio_component_sync_audio_rate(struct device *dev, > !IS_HASWELL(dev_priv)) > return 0; > > + i915_audio_component_get_power(dev); > mutex_lock(&dev_priv->av_mutex); > /* 1. get the pipe */ > intel_encoder = dev_priv->dig_port_map[port]; > @@ -698,6 +703,7 @@ static int i915_audio_component_sync_audio_rate(struct device *dev, > > unlock: > mutex_unlock(&dev_priv->av_mutex); > + i915_audio_component_put_power(dev); > return err; > } > > -- > 2.8.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers 2016-08-04 16:44 ` [PATCH] " Daniel Vetter @ 2016-08-04 18:05 ` Takashi Iwai 2016-08-04 21:03 ` Takashi Iwai 0 siblings, 1 reply; 6+ messages in thread From: Takashi Iwai @ 2016-08-04 18:05 UTC (permalink / raw) To: Daniel Vetter; +Cc: Chris Wilson, intel-gfx, stable On Thu, 04 Aug 2016 18:44:11 +0200, Daniel Vetter wrote: > > On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote: > > On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display > > power well and so the sna-hda audio codec acquires the display power > > well while it is operational. However, Skylake separates the powerwells > > again, but yet we still need the audio powerwell to setup the registers. > > (But then the hardware uses those registers even while powered off???) > > Yeah feels fishy, but will at least duct-tape over the breakage from the > audio side. Most likely the reg writes go exactly nowhere and there's a > bug on the audio side. And this patch doesn't fix that. Well, if the relevant code paths are only over these callbacks, I guess the following fix would work instead. Can anyone check? Takashi --- diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 89dacf9b4e6c..88ad391452ae 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1021,8 +1021,8 @@ static int azx_runtime_resume(struct device *dev) snd_hdac_i915_set_bclk(bus); } else { /* toggle codec wakeup bit for STATESTS read */ - snd_hdac_set_codec_wakeup(bus, true); - snd_hdac_set_codec_wakeup(bus, false); + snd_hdac_display_power(bus, true); + snd_hdac_display_power(bus, false); } } ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers 2016-08-04 18:05 ` [Intel-gfx] " Takashi Iwai @ 2016-08-04 21:03 ` Takashi Iwai 2016-08-10 12:13 ` Hans de Goede 0 siblings, 1 reply; 6+ messages in thread From: Takashi Iwai @ 2016-08-04 21:03 UTC (permalink / raw) To: Daniel Vetter; +Cc: Hans de Goede, intel-gfx [dropped stable ML and add a few other relevant people to Cc] On Thu, 04 Aug 2016 20:05:27 +0200, Takashi Iwai wrote: > > On Thu, 04 Aug 2016 18:44:11 +0200, > Daniel Vetter wrote: > > > > On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote: > > > On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display > > > power well and so the sna-hda audio codec acquires the display power > > > well while it is operational. However, Skylake separates the powerwells > > > again, but yet we still need the audio powerwell to setup the registers. > > > (But then the hardware uses those registers even while powered off???) > > > > Yeah feels fishy, but will at least duct-tape over the breakage from the > > audio side. Most likely the reg writes go exactly nowhere and there's a > > bug on the audio side. And this patch doesn't fix that. > > Well, if the relevant code paths are only over these callbacks, I > guess the following fix would work instead. > > Can anyone check? Scratch the previous one. There is another place calling similarly. Now looking back at the code again, I believe that the better way would be to properly do power up / down at the resume callbacks. Below is an untested patch. Let me know if this actually works. thanks, Takashi -- 8< -- From: Takashi Iwai <tiwai@suse.de> Subject: [PATCH] ALSA: hda - Manage power well properly for resume For SKL and later Intel chips, we control the power well per codec basis via link_power callback since the commit [03b135cebc47: ALSA: hda - remove dependency on i915 power well for SKL]. However, there are a few exceptional cases where the gfx registers are accessed from the audio driver: namely the wakeup override bit toggling at (both system and runtime) resume. This seems causing a kernel warning when accessed during the power well down (and likely resulting in the bogus register accesses). This patch puts the proper power up / down sequence around the resume code so that the wakeup bit is fiddled properly while the power is up. (The other callback, sync_audio_rate, is used only in the PCM callback, so it's guaranteed in the power-on.) Also, by this proper power up/down, the instantaneous flip of wakeup bit in the resume callback that was introduced by the commit [033ea349a7cd: ALSA: hda - Fix Skylake codec timeout] becomes superfluous, as snd_hdac_display_power() already does it. So we can clean it up together. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96214 Fixes: 03b135cebc47 ('ALSA: hda - remove dependency on i915 power well for SKL') Signed-off-by: Takashi Iwai <tiwai@suse.de> --- sound/pci/hda/hda_intel.c | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 89dacf9b4e6c..160c7f713722 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -906,20 +906,23 @@ static int azx_resume(struct device *dev) struct snd_card *card = dev_get_drvdata(dev); struct azx *chip; struct hda_intel *hda; + struct hdac_bus *bus; if (!card) return 0; chip = card->private_data; hda = container_of(chip, struct hda_intel, chip); + bus = azx_bus(chip); if (chip->disabled || hda->init_failed || !chip->running) return 0; - if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL - && hda->need_i915_power) { - snd_hdac_display_power(azx_bus(chip), true); - snd_hdac_i915_set_bclk(azx_bus(chip)); + if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) { + snd_hdac_display_power(bus, true); + if (hda->need_i915_power) + snd_hdac_i915_set_bclk(bus); } + if (chip->msi) if (pci_enable_msi(pci) < 0) chip->msi = 0; @@ -929,6 +932,11 @@ static int azx_resume(struct device *dev) hda_intel_init_chip(chip, true); + /* power down again for link-controlled chips */ + if ((chip->driver_caps & AZX_DCAPS_I915_POWERWELL) && + !hda->need_i915_power) + snd_hdac_display_power(bus, false); + snd_power_change_state(card, SNDRV_CTL_POWER_D0); trace_azx_resume(chip); @@ -1008,6 +1016,7 @@ static int azx_runtime_resume(struct device *dev) chip = card->private_data; hda = container_of(chip, struct hda_intel, chip); + bus = azx_bus(chip); if (chip->disabled || hda->init_failed) return 0; @@ -1015,15 +1024,9 @@ static int azx_runtime_resume(struct device *dev) return 0; if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) { - bus = azx_bus(chip); - if (hda->need_i915_power) { - snd_hdac_display_power(bus, true); + snd_hdac_display_power(bus, true); + if (hda->need_i915_power) snd_hdac_i915_set_bclk(bus); - } else { - /* toggle codec wakeup bit for STATESTS read */ - snd_hdac_set_codec_wakeup(bus, true); - snd_hdac_set_codec_wakeup(bus, false); - } } /* Read STATESTS before controller reset */ @@ -1043,6 +1046,11 @@ static int azx_runtime_resume(struct device *dev) azx_writew(chip, WAKEEN, azx_readw(chip, WAKEEN) & ~STATESTS_INT_MASK); + /* power down again for link-controlled chips */ + if ((chip->driver_caps & AZX_DCAPS_I915_POWERWELL) && + !hda->need_i915_power) + snd_hdac_display_power(bus, false); + trace_azx_runtime_resume(chip); return 0; } -- 2.9.2 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers 2016-08-04 21:03 ` Takashi Iwai @ 2016-08-10 12:13 ` Hans de Goede 0 siblings, 0 replies; 6+ messages in thread From: Hans de Goede @ 2016-08-10 12:13 UTC (permalink / raw) To: Takashi Iwai, Daniel Vetter; +Cc: intel-gfx Hi, On 04-08-16 23:03, Takashi Iwai wrote: > [dropped stable ML and add a few other relevant people to Cc] > > On Thu, 04 Aug 2016 20:05:27 +0200, > Takashi Iwai wrote: >> >> On Thu, 04 Aug 2016 18:44:11 +0200, >> Daniel Vetter wrote: >>> >>> On Wed, Aug 03, 2016 at 05:09:00PM +0100, Chris Wilson wrote: >>>> On Haswell/Broadwell, the HD-Audio block is inside the HDMI/display >>>> power well and so the sna-hda audio codec acquires the display power >>>> well while it is operational. However, Skylake separates the powerwells >>>> again, but yet we still need the audio powerwell to setup the registers. >>>> (But then the hardware uses those registers even while powered off???) >>> >>> Yeah feels fishy, but will at least duct-tape over the breakage from the >>> audio side. Most likely the reg writes go exactly nowhere and there's a >>> bug on the audio side. And this patch doesn't fix that. >> >> Well, if the relevant code paths are only over these callbacks, I >> guess the following fix would work instead. >> >> Can anyone check? > > Scratch the previous one. There is another place calling similarly. > > Now looking back at the code again, I believe that the better way > would be to properly do power up / down at the resume callbacks. > > Below is an untested patch. Let me know if this actually works. I've build a 4.7 kernel with this patch and I can confirm that it fixes the WARN_ON I was seeing in my XPS 9550 without this patch. Thanks & Regards, Hans > thanks, > > Takashi > > -- 8< -- > From: Takashi Iwai <tiwai@suse.de> > Subject: [PATCH] ALSA: hda - Manage power well properly for resume > > For SKL and later Intel chips, we control the power well per codec > basis via link_power callback since the commit [03b135cebc47: ALSA: > hda - remove dependency on i915 power well for SKL]. > However, there are a few exceptional cases where the gfx registers are > accessed from the audio driver: namely the wakeup override bit > toggling at (both system and runtime) resume. This seems causing a > kernel warning when accessed during the power well down (and likely > resulting in the bogus register accesses). > > This patch puts the proper power up / down sequence around the resume > code so that the wakeup bit is fiddled properly while the power is > up. (The other callback, sync_audio_rate, is used only in the PCM > callback, so it's guaranteed in the power-on.) > > Also, by this proper power up/down, the instantaneous flip of wakeup > bit in the resume callback that was introduced by the commit > [033ea349a7cd: ALSA: hda - Fix Skylake codec timeout] becomes > superfluous, as snd_hdac_display_power() already does it. So we can > clean it up together. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96214 > Fixes: 03b135cebc47 ('ALSA: hda - remove dependency on i915 power well for SKL') > Signed-off-by: Takashi Iwai <tiwai@suse.de> > --- > sound/pci/hda/hda_intel.c | 32 ++++++++++++++++++++------------ > 1 file changed, 20 insertions(+), 12 deletions(-) > > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c > index 89dacf9b4e6c..160c7f713722 100644 > --- a/sound/pci/hda/hda_intel.c > +++ b/sound/pci/hda/hda_intel.c > @@ -906,20 +906,23 @@ static int azx_resume(struct device *dev) > struct snd_card *card = dev_get_drvdata(dev); > struct azx *chip; > struct hda_intel *hda; > + struct hdac_bus *bus; > > if (!card) > return 0; > > chip = card->private_data; > hda = container_of(chip, struct hda_intel, chip); > + bus = azx_bus(chip); > if (chip->disabled || hda->init_failed || !chip->running) > return 0; > > - if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL > - && hda->need_i915_power) { > - snd_hdac_display_power(azx_bus(chip), true); > - snd_hdac_i915_set_bclk(azx_bus(chip)); > + if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) { > + snd_hdac_display_power(bus, true); > + if (hda->need_i915_power) > + snd_hdac_i915_set_bclk(bus); > } > + > if (chip->msi) > if (pci_enable_msi(pci) < 0) > chip->msi = 0; > @@ -929,6 +932,11 @@ static int azx_resume(struct device *dev) > > hda_intel_init_chip(chip, true); > > + /* power down again for link-controlled chips */ > + if ((chip->driver_caps & AZX_DCAPS_I915_POWERWELL) && > + !hda->need_i915_power) > + snd_hdac_display_power(bus, false); > + > snd_power_change_state(card, SNDRV_CTL_POWER_D0); > > trace_azx_resume(chip); > @@ -1008,6 +1016,7 @@ static int azx_runtime_resume(struct device *dev) > > chip = card->private_data; > hda = container_of(chip, struct hda_intel, chip); > + bus = azx_bus(chip); > if (chip->disabled || hda->init_failed) > return 0; > > @@ -1015,15 +1024,9 @@ static int azx_runtime_resume(struct device *dev) > return 0; > > if (chip->driver_caps & AZX_DCAPS_I915_POWERWELL) { > - bus = azx_bus(chip); > - if (hda->need_i915_power) { > - snd_hdac_display_power(bus, true); > + snd_hdac_display_power(bus, true); > + if (hda->need_i915_power) > snd_hdac_i915_set_bclk(bus); > - } else { > - /* toggle codec wakeup bit for STATESTS read */ > - snd_hdac_set_codec_wakeup(bus, true); > - snd_hdac_set_codec_wakeup(bus, false); > - } > } > > /* Read STATESTS before controller reset */ > @@ -1043,6 +1046,11 @@ static int azx_runtime_resume(struct device *dev) > azx_writew(chip, WAKEEN, azx_readw(chip, WAKEEN) & > ~STATESTS_INT_MASK); > > + /* power down again for link-controlled chips */ > + if ((chip->driver_caps & AZX_DCAPS_I915_POWERWELL) && > + !hda->need_i915_power) > + snd_hdac_display_power(bus, false); > + > trace_azx_runtime_resume(chip); > return 0; > } > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-08-10 12:13 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-08-03 16:09 [PATCH] drm/i915: Acquire audio powerwell for HD-Audio registers Chris Wilson 2016-08-03 16:39 ` ✗ Ro.CI.BAT: failure for " Patchwork 2016-08-04 16:44 ` [PATCH] " Daniel Vetter 2016-08-04 18:05 ` [Intel-gfx] " Takashi Iwai 2016-08-04 21:03 ` Takashi Iwai 2016-08-10 12:13 ` Hans de Goede
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox