On Wed, 2012-02-15 at 20:46 -0600, Ricardo Neri wrote: > What other display types featuring audio and video should be considered > at this point? I guess they are a bit theoretical, so I wouldn't worry too much about them. But if it's easy to make the API generic, instead of HDMI specific, let's aim for generic one just to be on the safe side. > > The audio driver should iterate the dss devices to find the ones (there > > could well be multiple HDMI outputs) that support audio when the driver > > starts. > > > > Does the above make sense? > > At first glance, I think the omapd_dss_audio_* functions should cover > the following: > * CEA-861 infoframe configuration > * IEC-60958 configuration (IEC-61937 support added later) > * audio start/stop > * whether audio is supported by the current video configuration > * a notifier power and video events (e.g, DVI/HDMI mode, changes in > pixel clock and deep color configuration) to the ASoC driver. Maybe an > enum can encompass DisplayPort and HDMI events. Sounds fine to me (not that I understand anything about the audio side =). For notifications, I've long planned to implement notifications for omapdss/displays, mainly for hotplug but also other events. So I think we should try to make the notification system not audio-specific, but usable for other events also. As for the API, I don't think omap_dss_audio_* is the way to go. The audio functions should probably be function pointers in the omap_dss_driver struct. > I think that this is generic enough to cover DisplayPort and HDMI, > unless you consider that I am missing some important display type. > > I can try to make it similar to omapfb. Don't look too closely at omapfb, it's horribly ugly in many places =). Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
