[alsa-devel] [PATCH] ALSA: hda_intel: add AZX_DCAPS_I915_POWERWELL for skl

[David Henningsson]

On 2015-04-01 23:55, Yang, Libin wrote:
> Hi David,
>
>
>
>> -----Original Message-----
>> From: David Henningsson [mailto:david.henningsson at canonical.com]
>> Sent: Wednesday, April 01, 2015 4:12 PM
>> To: Yang, Libin; 'Takashi Iwai'
>> Cc: 'alsa-devel at 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 at alsa-project.org [mailto:alsa-devel-
>>>> bounces at alsa-project.org] On Behalf Of David Henningsson
>>>> Sent: Wednesday, April 01, 2015 3:31 PM
>>>> To: Yang, Libin; 'Takashi Iwai'
>>>> Cc: 'alsa-devel at 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:
>>>>>
>>>>> 1. power on the power well
>>>>> 2. read STATESTS to determine the codec_mask
>>>>> 3. if codec is not present, power off the power well
>>>>>        and remove the flag. (seems we need a new flag)
>>>>> 4. 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
>>
>> ...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)

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic