On 05/27/2013 09:30 AM, Wang xingchao wrote:
On Thu, May 16, 2013 at 09:00:06AM +0200, David Henningsson wrote:
Hi,
I want to take this problem up again, because it's important we get
this right.
The HDA driver assumes that a codec pin widget node always refers to
the same physical output. With Haswell, it seems like this is not
guaranteed to be true. I would like to see this fixed on the
graphics side. If not, I don't know how to work around it on the
audio side.
in gfx side, eld valid bit was set according to *pipe*, not physical outputs.
For haswell, the codec pin output connected to transcoder(pipe) directly.
I cannot confirm whether the three codec Pins are fixed connected to three
transcoders(pipes) atm, i assume it is as i cannot find any programing manual
in bspec(please correct me if i'm wrong here).
And between transcoder and external DDI ports, there's cross-point mux used
for selection: pipe/transcoder can select the output DDI ports.
i.e. the physical HDMI cable is connected to DDI port B. if current using pipe
is PIPE A, the eld valid bit for PIPE A is set. But we cannot guarantee only
the first hdmi device is available for audio output. when play audio through
first codec pin, it means output audio data to Transcoder A(Pipe A), that
depends
on whether PIPE A select DDI port B. If output data to second codec PIN, it
outputs data to PIPE B, if pipe B select DDI B too, you can hear sound, even
the second pin doesnt have valid eld info.
thanks
--xingchao
The problems that occur on the audio side are:
1) Some BIOSes set default pin config. E g, if the machine has a
single HDMI out, it can set two of the codec pins to "not connected"
and let the third remain "jack". As a result, the HDA driver will
ignore the two codec pins and only enable the third. As such, HDMI
audio will not work correctly, unless it's the third codec pin that
is connected to the physical output.
2) Saving and restoring mutes, volumes etc is done on a per-pin
basis. E g, imagine that a user has a dual monitor setup and always
wants audio output from the left side monitor, and keep the right
side monitor silent. If it is not reliable which codec pin refers to
which physical output, one day suddenly the sound might come out on
the right side monitor instead.
Thanks for your answer, but it doesn't really resolve the problems as
outlined above.
If it is utterly impossible to make sure that the audio codec pin always
represent the same physical output, we might need even more
communication between the audio and video driver.
For solving problem 1), the audio driver needs to inform the video
driver what outputs are disabled by BIOS default pin config, so it can
avoid assigning those pipes to anything with audio output. (Or we can
just ignore BIOS default pin config for Haswell in the audio driver, but
I'm not sure if this leads to problems somewhere else.)
For solving problem 2), we should perhaps call into the video driver
somehow to enumerate the physical outputs and what codec pin is
currently assigned to what output.
Also, when can these PIPE -> DDI connections change? Can we get a
notification? Otherwise it would be very confusing for the user if
(s)he's currently playing an audio stream and suddenly the audio comes
out of something else than when (s)he started the stream.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
