[PATCH 2/3] drm/msm/dsi: move next bridge acquisition to dsi_bind

[Abhinav Kumar]

On 4/5/2024 11:15 AM, Dmitry Baryshkov wrote:
> On Fri, 5 Apr 2024 at 20:35, Abhinav Kumar <quic_abhinavk at quicinc.com> wrote:
>>
>>
>>
>> On 3/9/2024 7:09 AM, Dmitry Baryshkov wrote:
>>> Currently the MSM DSI driver looks for the next bridge during
>>> msm_dsi_modeset_init(). If the bridge is not registered at that point,
>>> this might result in -EPROBE_DEFER, which can be problematic that late
>>> during the device probe process. Move next bridge acquisition to the
>>> dsi_bind state so that probe deferral is returned as early as possible.
>>>
>>
>> But msm_dsi_modeset)init() is also called during msm_drm_bind() only.
>>
>> What issue are you suggesting will be fixed by moving this from
>> msm_drm_bind() to dsi_bind()?
> 
> The goal is to return as early as possible as not not cause
> probe-deferral loops. See commit fbc35b45f9f6 ("Add documentation on
> meaning of -EPROBE_DEFER"). It discusses returning from probe() but
> the same logic applies to bind().
> 

Understood. I was trying to make sure the purpose of the patch is that 
"deferral in component_bind() is better than component_master_bind()"

But yes, overall that is better since the unbounding path will be more 
in the master case.

>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
>>> ---
>>>    drivers/gpu/drm/msm/dsi/dsi.c         | 16 ++++++++++++++++
>>>    drivers/gpu/drm/msm/dsi/dsi.h         |  2 ++
>>>    drivers/gpu/drm/msm/dsi/dsi_manager.c |  8 +-------
>>>    3 files changed, 19 insertions(+), 7 deletions(-)
>>>

Reviewed-by: Abhinav Kumar <quic_abhinavk at quicinc.com>