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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
