Hi Shuah, Thanks for the review! On Wed, May 04, 2016 at 08:50:56AM -0600, Shuah Khan wrote: > On 05/04/2016 05:20 AM, Sakari Ailus wrote: > > New IOCTLs (especially for the request API) do not necessarily need the > > graph mutex acquired. Leave this up to the drivers. > > Sakari, > > Does this mean drivers have to hold the graph mutex as needed? > My concern with this is that we will have graph_mutex holds in > driver code in addition to the ones we have now. My concern with > referencing graph_mutex from driver code is lack of abstraction. > If we ever need to change grahp-mutex in the media-core, if it > is exposed to drivers, then there will be lot of changes. > > Could we look into avoiding drivers referencing graph_mutex > directly? I think we rather need to get rid of the graph mutex in the end; it's a bit like the big kernel lock right now: most operations on the graph, whatever they are, need it. The case for not acquiring it (I have request API and events in mind, in particular) for some IOCTLs is there. Drivers may need to acquire other mutexes while holding the graph mutex, and the locking order has to be maintained in order to avoid deadlocks. Dequeueing events does not need the graph mutex, whereas requests changing the graph state would need it for the time being. The reason there's a flag to acquire the graph mutex (rather than not acquiring it) is that it'd be easier to spot where it's needed. -- Kind regards, Sakari Ailus e-mail: sakari.ailus@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
