Messages in this thread | | | Date | Wed, 10 May 2023 16:30:38 -0700 | Subject | Re: [PATCH v1 2/2] drm/msm/dp: add mutex to protect internal_hpd against race condition between different threads | From | Abhinav Kumar <> |
| |
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@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.
| |