Hi, On Thu, 2012-05-03 at 20:44 -0500, Ricardo Neri wrote: > Implement the DSS device driver audio support interface in the HDMI > panel driver and generic driver. The implementation relies on the > IP-specific functions that are defined at DSS probe time. > > At the moment, a hardirq-safe spinlock is used to protect the audio > functions. This is because such functions might be called while > holding a lock (this especially true for audio_start/stop). For the > rest of the audio functions, a mutex could be used in the future as > the enablement of resources might take too much time.
The series looks good, except locking. Granted, the locking in omapdss is a bit bad generally also, but here I think it's a bit more broken. For example, hdmi_panel.c:hdmi_panel_audio_supported() takes the audio lock, and then uses variables like dssdev->state, and the hdmi video mode. However, the video functions do not use audio lock, so effectively the lock doesn't protect at all. I'm not sure how to fix it, though. I think this shows the shortcomings of the current locking strategy (or lack of =). What if the audio functions that can sleep would take the hdmi panel's mutex, and also the audio spinlock? That would at least fix some of the cases. Tomi
signature.asc
Description: This is a digitally signed message part
