Re: [PATCH 4/5] OMAPDSS: Export functions to enable dynamic linking

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]