[alsa-devel] [PATCH] ASoC: Intel: Power down links before turning off display audio power

[Takashi Iwai]

On Tue, 26 Jun 2018 13:24:01 +0200,
Sriram Periyasamy wrote:
> 
> On Mon, Jun 25, 2018 at 05:18:27PM +0200, Takashi Iwai wrote:
> > On Mon, 25 Jun 2018 16:51:12 +0200,
> > Sriram Periyasamy wrote:
> > > 
> > > On Mon, Jun 25, 2018 at 11:53:59AM +0200, Takashi Iwai wrote:
> > > > On Mon, 25 Jun 2018 11:23:17 +0200,
> > > > Sriram Periyasamy wrote:
> > > > > 
> > > > > On Mon, Jun 25, 2018 at 11:08:13AM +0200, Takashi Iwai wrote:
> > > > > > On Mon, 25 Jun 2018 10:53:49 +0200,
> > > > > > Sriram Periyasamy wrote:
> > > > > > > 
> > > > > > > On Fri, Jun 22, 2018 at 07:14:50PM +0200, Takashi Iwai wrote:
> > > > > > > > On Fri, 22 Jun 2018 18:42:24 +0200,
> > > > > > > > Pierre-Louis Bossart wrote:
> > > > > > > > > 
> > > > > > > > > On 6/22/18 4:25 AM, Sriram Periyasamy wrote:
> > > > > > > > > > On certain platforms, Display HDMI HDA codec was not going to sleep state
> > > > > > > > > > after the use when links are powered down after turning off the display
> > > > > > > > > > power. As per the HW recommendation, links are powered down before turning
> > > > > > > > > > off the display power to ensure that the codec goes to sleep state.
> > > > > > > > > 
> > > > > > > > > The change looks ok, I am still not clear on display power
> > > > > > > > > management. snd_hdac_display_power is called both from hdac_hdmi.c and
> > > > > > > > > skl.c in the respective probe/suspend/resume routines, wondering if
> > > > > > > > > this is redundant or intentional.
> > > > > > > > 
> > > > > > > > Yeah, it looks like that skl.c keeps the display power on by assuming
> > > > > > > > that it's turned off by the codec driver, but it doesn't happen
> > > > > > > > actually.  I also find it fishy there...
> > > > > > > > 
> > > > > > > 
> > > > > > > snd_hdac_display_power is called intentionally to ensure that the codec is
> > > > > > > powered up before any communication is initiated from either skl.c or
> > > > > > > hdac_hdmi.c.
> > > > > > 
> > > > > > But who turns it down if the device is not used?
> > > > > 
> > > > > Powering down of codec is taken care in codec's suspend routine.
> > > > 
> > > > But you'll power up twice, no?  Once in skl_resume() (which is no
> > > > runtime resume but only for S3/S4) and once in codec resume.
> > > > I wonder who will turn down when you wake up from S3.
> > > 
> > > No. When entering to S3, hdmi_codec_prepare() will invoke the runtime
> > > resume of codec hdac_hdmi_runtime_resume() which power up the codec and
> > > skl_suspend power down the codec. When it wakes up from S3, skl_resume()
> > > powers up the codec and hdmi_codec_complete invokes the runtime suspend of
> > > codec hdac_hdmi_runtime_suspend() which powers down the codec.
> > 
> > Hm, but what about the i915 power well refcount, not the codec runtime
> > PM refcount?  Does the refcount reach to zero when the system goes to
> > runtime suspend?  That puzzles me.
> > 
> 
> Yes, i915 power well refcount goes to zero when system goes to runtime
> suspend. The value of bus->i915_power_refcount in snd_hdac_display_power
> is zero.
> 
> > > This design is required to achieve the runtime power reference count for
> > > codec device when it is put to S3/S4 while playback was going on.
> > 
> > ... and this "design" picture is completely missing.
> > That's why illustrating it was requested instead of a patch :)
> > 
> > > >  The runtime
> > > > suspend doesn't call snd_hdac_display_power() in skl.c.
> > > > 
> > > 
> > > Display power management for all runtime uses cases are handled in the
> > > codec driver hdac_hdmi.c.
> > 
> > But it means that hdac_hdmi.c does manage the extra decrement the
> > refcount that was taken in skl.c?
> >
> 
> No, snd_hdac_display_power is invoked in skl.c for the following cases,
> 
> skl_probe_work - display power on, enumurate the codec and display power
>                  off
> skl_suspend & skl_resume - display power off/on for S3/S0 cycle 
> 	                   respectively
> 
> snd_hdac_display_power is invoked in hdac_hdmi.c for the following cases,
> 
> hdac_hdmi_dev_probe - display power on, probe the device and put the
> 		      device to runtime suspend explicitly
> 
> runtime suspend & resume - display power off and on respectively

That puzzled me.  How does display refcount goes to zero at runtime
suspend of skl?  skl_suspend() is only for S3, not for runtime PM.

Suppose you probe skl, hdac_hdmi, then do runtime suspend hdac_hdmi
and skl respectively.  How does the display pm refcount go to zero?


Takashi