[PATCH v3 45/50] drm/omap: dpi: Register a drm_bridge

[Laurent Pinchart]

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