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. The runtime suspend doesn't call snd_hdac_display_power() in skl.c.
It'd be helpful if you can illustrate the PM scheme in a big picture.
We will add separate patch for providing PM sequence.
Well, no patch is needed but rather an explanation is...
thanks,
Takashi