[Applied][Raring PATCH] Ubuntu (no-up): ALSA: hda - fixup D3 pin and right channel mute on Haswell HDMI audio

[David Henningsson]

On 04/11/2013 09:25 PM, David Henningsson wrote:
> On 04/11/2013 04:31 PM, Tim Gardner wrote:
>> On 04/11/2013 07:28 AM, Leann Ogasawara wrote:
>>> On 04/11/2013 06:09 AM, Leann Ogasawara wrote:
>>>> Applied to Raring master-next.
>>>
>>> Hi David,
>>>
>>> After I'd applied this to Raring master-next, there was some concern
>>> raised about the patch via the #ubuntu-kernel IRC channel.  We are
>>> hoping to get some clarification and feedback from you.
>>>
>>> [06:12:36] <rtg_> ogasawara, actually, I was gonna question David on
>>> that patch. it seems over engineered to me.
>>> [06:14:13] <ogasawara> rtg_: I thought it seemed fairly well contained
>>> and tested
>>> [06:14:40] <ogasawara> rtg_: it's not too late to yank it if you have
>>> reservations
>>> [06:15:12] <rtg_> ogasawara, in that it only affects haswell. however,
>>> why not just force the D0 and mute settings rather then interrogate the
>>> HW ? less code I think.
>>> [06:17:24] <ogasawara> rtg_: it's a valid question, want me to punt it
>>> till we get clarification?
>>> [06:18:54] <rtg_> ogasawara, if we can get ahold of him today.
>>> [06:20:23] <rtg_> ogasawara, by collapsing the code into a more
>>> definitive form I might worry about audio artifacts such as pops and
>>> clicks whilst programming those registers. thats really what I'd like to
>>> confirm from him.
>>>
>>>>
>>>> On 04/11/2013 12:38 AM, David Henningsson wrote:
>>>>> BugLink: https://bugs.launchpad.net/bugs/1167270
>>>>>
>>>>> This patch has been tested on two machines, and found to resolve one
>>>>> of the HDMI audio issues on Haswell.
>>>>>
>>>>> The root cause is lack of synchronisation between the video driver and
>>>>> the audio driver. Upstream wants to resolve this by adding
>>>>> synchronisation mechanisms, so they won't take this patch. But since
>>>>> kernel freeze is today, I wanted to ask you to accept this
>>>>> intermediate workaround, which at every playback start checks for the
>>>>> error and corrects it if found.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>> Perhaps something like the attached.
>>
>
> Thanks for the review.
>
> There are two things here: The D0 and the mute.
>
> For the D0 part, I *think* setting it always is harmless and shouldn't
> cause any clicks or similar. After all, this is a digital connection so
> artifacts should be avoided by the recipient (HDMI monitor/receiver)
> anyway.
> The gain to keep it as it is would be to avoid the 40 ms delay in case
> this does not happen (which is does not in the majority of cases). But
> probably just enabling it, skipping the delay, and not read it back for
> debugging would work too, I just haven't tested it (and can't do so
> since the hw is in Asia), and I know you like patches to be tested
> before you apply them :-)
>
> For the mute part; I think the patch suggested by rtg is buggy since it
> always enables audio, without taking the mute kcontrol into affect:
> there is a "IEC958 Playback Switch" control that user could set to turn
> both channels off legitimately. So the mute part needs to stay the way
> it was in my version of the patch.

It looks like this patch did not make it into Raring before the kernel 
freeze?


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