[PATCH v1 2/2] drm/msm/dp: add mutex to protect internal_hpd against race condition between different threads

Abhinav Kumar quic_abhinavk at quicinc.com
Wed May 10 23:30:38 UTC 2023


Hi Stephen

On 5/10/2023 4:19 PM, Kuogee Hsieh wrote:
> internal_hpd is referenced at both plug and unplug handle.
> 
> The majority purpose of  mutext is try to serialize internal_hpd between 
> dp_bridge_hpd_disable() and either plug or unplug handle.
> 
> 
> On 5/10/2023 4:11 PM, Abhinav Kumar wrote:
>>
>>
>> On 5/10/2023 3:46 PM, Stephen Boyd wrote:
>>> Quoting Kuogee Hsieh (2023-05-10 13:31:05)
>>>> Intrenal_hpd is referenced by event thread but set by drm bridge 
>>>> callback
>>>> context. Add mutex to protect internal_hpd to avoid conflicts between
>>>> threads.
>>>>
>>>> Signed-off-by: Kuogee Hsieh <quic_khsieh at quicinc.com>
>>>> ---
>>>
>>> This patch looks completely unnecessary. How can dp_bridge_hpd_enable()
>>> be called at the same time that dp_bridge_hpd_disable() is called or
>>> dp_bridge_hpd_notify() is called? Isn't there locking or ordering at a
>>> higher layer?
>>
>> Ack. We can drop this patch because we are protected by 
>> bridge->hpd_mutex in drm_bridge_hpd_enable() / drm_bridge_hpd_disable 
>> () and drm_bridge_hpd_notify().

I understood now, so what kuogee is referring to is that this 
event_mutex protection is to not protect those 3 calls from each other 
(since they are already protected as we saw above) but because 
dp_hpd_plug_handle/dp_hpd_unplug_handle still uses 
dp_display.internal_hpd to re-enable the hot-plug interrupt, this is 
making sure that flow is protected as well.


More information about the dri-devel mailing list