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
Attachment:
signature.asc
Description: This is a digitally signed message part
