On Thu, Dec 19, 2019 at 12:01:34PM +0200, Tomi Valkeinen wrote: > On 19/12/2019 11:40, Laurent Pinchart wrote: > >> Do we ever get drm_bridge_funcs calls from multiple threads at the > >> same time? Is there a difference between having a single DPI output, > >> or multiple DPI outputs (i.e. can two different DPI outputs get calls > >> simultaneously?). > > > > I'll drop the lock, it's not needed. The core should serialize calls to > > the bridge, at least per output. For different outputs, there's a > > possibility I believe of atomic commits being handled concurrently if > > they don't share any resource. > > I don't think we do much locking with resource handling. E.g. we have single registers with mux > settings for multiple outputs. If DPI (or any other dss output) gets called concurrently for > different outputs, we might get a race. > > I wonder if that concurrency is opt-in... It's at least opt-out in the sense that we can acquire all resources in our top-level .atomic_check() implementation if we want to. Of course the best option would be to handle locking correcly in the core :-) With this rework done, I want to focus on Sebastian's DSI move to drm_bridge, and then remove lots of dead code. I think a cleanup pass in the DISPC would be useful after that. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
