Hi David,
-----Original Message----- From: alsa-devel-bounces@alsa-project.org [mailto:alsa-devel- bounces@alsa-project.org] On Behalf Of David Henningsson Sent: Wednesday, April 01, 2015 3:31 PM To: Yang, Libin; 'Takashi Iwai' Cc: 'alsa-devel@alsa-project.org' Subject: Re: [alsa-devel] [PATCH] ALSA: hda_intel: add AZX_DCAPS_I915_POWERWELL for skl
On 2015-03-30 04:47, Yang, Libin wrote:
From our silicon team's comment, it seems we need power on the powerwell when detecting and probing the HDMI codec.
For the skl case (HDMI codec is in powerwell, while controller not), my thinking is:
- power on the power well
- read STATESTS to determine the codec_mask
- if codec is not present, power off the power well and remove the flag. (seems we need a new flag)
- if codec is present, we will power on the power well when dealing with HDMI codec.
What do you think?
Side question - do you know if it's the same for braswell? I e, the HDMI codec is in the powerwell but the controller is not?
Yes, BSW has the same issue.
At first, my thinking is: 1. define a new flag, power on the power well if flag is set 2. read STATESTS to determine the codec_mask 3. if codec is not present, power off the power well and remove the flag. 4. after initialization, power off the power well if new flag is set and AZX_DCAPS_I915_POWERWELL is not set 5. power on power well when pcm open 6. power off the power well when pcm close
After a second thought, the method may have limitation: the codec may send the unsolicited responses.
So my currently thinking is: If the codec is in powerwell, the behavior is like the flag AZX_DCAPS_I915_POWERWELL: always power on unless suspend. This method may cause power consumption. But consider normally audio will be in suspend state in most case.
-- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel