On 2015-04-01 23:55, Yang, Libin wrote:
Hi David,
-----Original Message----- From: David Henningsson [mailto:david.henningsson@canonical.com] Sent: Wednesday, April 01, 2015 4:12 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-04-01 10:00, Yang, Libin wrote:
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:
- define a new flag, power on the power well if flag is set
- read STATESTS to determine the codec_mask
- if codec is not present, power off the power well and remove the flag.
- after initialization, power off the power well if new flag is set and AZX_DCAPS_I915_POWERWELL is not set
- power on power well when pcm open
- power off the power well when pcm close
...and we're opening the right codec - in case of analog playback, the powerwell can still be off, right?
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.
Ok, thanks for the clarification. I was wondering - the reason the codec might send unsol events is just due to hotplug events, right?
And these unsol events are triggered by the i915 side by setting some registers, right?
Is it then possible that i915, when it detects a video hotplug event, can increment the powerwell counter (so that the powerwell is turned on), trigger the hotplug event to the audio side, and then decrement the powerwell again (possibly with a few seconds delay if needed)?
The idea is that once the audio side has got the hotplug event, it can turn on and off the powerwell itself. We just need the i915 driver to turn it on for us to get the hotplug event through.
Normally, it's the hotplug unsol event. But sometimes, I found on SKL, when suspending, there is some strange event sending from hdmi codec. And the controller will fallback to single cmd mode. Then the analog audio will be impacted after resume.
BSW may also have this issue. But I didn't find it on our RVP board.
I will test power on power well during unsol events.
Ok. I wonder if it is possible to stop this "strange event", either because it's a hardware/firmware bug that could be fixed in later revisions of the hardware/firmware, or if there is some register we could write to (or even stop writing to!) on the i915 side that stops the unsol events.
Or as a last resort, if we can't stop the "strange event", maybe there's some way the audio side could handle the "strange event" more gracefully so we don't fall back to single cmd mode when this happens.
(I don't know much about this "strange event" so I'm just guessing here)