On 08/23/2012 07:44 PM, Ricardo Neri wrote:
On 08/22/2012 02:55 AM, Takashi Iwai wrote:
At Tue, 21 Aug 2012 19:58:02 -0500, Ricardo Neri wrote:
...
Maybe the lack of audio support in drm is because the audio users should not talk to drm directly but to a lower level component (omapdrm, omapdss?). However, today there exists video technology supports audio as well, such as DisplayPort or HDMI. Could it make more sense now to provide audio support?
The reason is that the audio and video handling are already separated in the hardware level, at least, for desktop graphics.
Separated in what sense? Do they have separate register banks in
For NVIDIA desktop GPUs, this is certainly true, and I think so for any Intel Azalia/HDA controller. The separate register banks are in different PCI functions on the chip. The Intel Azalia/HDA spec also architects specific ways that the audio and video parts interact (i.e. ELD representation of EDID data, unsolicited response messages when the video state changes, etc.) Oh, I see Takashi mentioned this below.
independent power domains?
Most likely yes.
Can audio an video work with complete independence. What happens if someone decides to power off video. Is the audio able to continue if required?
I believe audio DMA isn't affect by the video state, but I'm not 100% sure of that.
The audio infoframe is passed via ELD to the audio controller part upon plug/unplugging via HD-audio unsolicited event, and the audio driver sets up the stuff according to the given ELD. Thus no extra interface between drm and ALSA was required in the kernel API level, so far.
I see that the unsolicited event is used only to parse the EDID, correct? It also notifies about the jack status. Hence, if there the cable is disconnected the application will know and act accordingly. Is this understanding correct?
The kernel will know, and then passes the information on to user-space.