On 19/12/2019 12:03, Laurent Pinchart wrote:
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
I agree, but I wonder if that's just a lot of work and possibilities for complex to find bugs, for
little benefit.
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.
I agree here too, without any buts.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
