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

[Tomi Valkeinen]

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