[PATCH v3] drm/msm/dp: check core_initialized flag at both host_init() and host_deinit()

[Dmitry Baryshkov]

On 04/03/2023 00:45, Kuogee Hsieh wrote:
> 
> On 3/2/2023 11:04 AM, Dmitry Baryshkov wrote:
>> On Thu, 2 Mar 2023 at 20:41, Kuogee Hsieh <quic_khsieh at quicinc.com> 
>> wrote:
>>>
>>> On 3/1/2023 1:15 PM, Dmitry Baryshkov wrote:
>>>> On 01/03/2023 18:57, Kuogee Hsieh wrote:
>>>>> On 2/28/2023 6:16 PM, Dmitry Baryshkov wrote:
>>>>>> On Wed, 1 Mar 2023 at 02:17, Kuogee Hsieh <quic_khsieh at quicinc.com>
>>>>>> wrote:
>>>>>>> There is a reboot/suspend test case where system suspend is forced
>>>>>>> during system booting up. Since dp_display_host_init() of external
>>>>>>> DP is executed at hpd thread context, this test case may created a
>>>>>>> scenario that dp_display_host_deinit() from pm_suspend() run before
>>>>>>> dp_display_host_init() if hpd thread has no chance to run during
>>>>>>> booting up while suspend request command was issued. At this 
>>>>>>> scenario
>>>>>>> system will crash at aux register access at dp_display_host_deinit()
>>>>>>> since aux clock had not yet been enabled by dp_display_host_init().
>>>>>>> Therefore we have to ensure aux clock enabled by checking
>>>>>>> core_initialized flag before access aux registers at pm_suspend.
>>>>>> Can a call to dp_display_host_init() be moved from
>>>>>> dp_display_config_hpd() to dp_display_bind()?
>>>>> yes,  Sankeerth's  "drm/msm/dp: enable pm_runtime support for dp
>>>>> driver" patch is doing that which is under review.
>>>>>
>>>>> https://patchwork.freedesktop.org/patch/523879/?series=114297&rev=1
>>>> No, he is doing another thing. He is moving these calls to pm_runtime
>>>> callbacks, not to the dp_display_bind().
>>>>
>>>>>> Related question: what is the primary reason for having
>>>>>> EV_HPD_INIT_SETUP and calling dp_display_config_hpd() via the event
>>>>>> thread? Does DP driver really depend on DPU irqs being installed? As
>>>>>> far as I understand, DP device uses MDSS interrupts and those IRQs 
>>>>>> are
>>>>>> available and working at the time of dp_display_probe() /
>>>>>> dp_display_bind().
>>>>> HDP gpio pin has to run through DP aux module 100ms denouncing logic
>>>>> and have its mask bits.
>>>>>
>>>>> Therefore DP irq has to be enabled to receive DP isr with mask bits 
>>>>> set.
>>>> So... DP irq is enabled by the MDSS, not by the DPU. Again, why does
>>>> DP driver depend on DPU irqs being installed?
>>> sorry, previously i mis understand your question -- why does DP driver
>>> depend on DPU irqs being installed?
>>>
>>> now, I think you are asking why  dpu_irq_postinstall() ==>
>>> msm_dp_irq_postinstall() ==> event_thread ==> dp_display_config_hdp()
>>> ==> enable_irq(dp->irq)
>>>
>>> With the below test i had run, i think the reason is to make sure
>>> dp->irq be requested before enable it.
>>>
>>> I just run the execution timing order test and collect execution order
>>> as descending order at below,
>>>
>>> 1) dp_display_probe() -- start
>>>
>>> 2) dp_display_bind()
>>>
>>> 3) msm_dp_modeset_init()  ==> dp_display_request_irq() ==>
>>> dp_display_get_next_bridge()
>>>
>>> 4) dpu_irq_postinstall() ==> msm_dp_irq_postinstall() ==>
>>> enable_irq(dp->irq)
>>>
>>> 5) dp_display_probe() -- end
>>>
>>> dp->irq is request at msm_dp_modeset_init() and enabled after.
>> Should be moved to probe.
>>
>>> That bring up the issue to move DP's dp_display_host_init() executed at
>>> dp_display_bind().
>>>
>>> Since eDP have dp_dispaly_host_init() executed at
>>> dp_display_get_next_bridge() which executed after dp_display_bind().
>>>
>>> If moved DP's dp_display_host_init() to dp_dispaly_bind() which means DP
>>> will be ready to receive HPD irq before eDP ready.
>> And the AUX bus population should also be moved to probe(), which
>> means we should call dp_display_host_init() from probe() too.
>> Having aux_bus_populate in probe would allow moving component_add() to
>> the done_probing() callback, making probe/defer case more robust
>>
>>> This may create some uncertainties at execution flow and complicate
>>> things up.
>> Hopefully the changes suggested above will make it simpler.
> 
> ok, I will create another patch to

patchset

> 
> 1) move dp_display_host_init() to probe()
> 
> 2) move component_add() to done_probing() for eDP
> 
> 3) keep DP as simple platform device (component_add() still executed in 
> probe())

4) move devm_request_irq() to probe, add IRQF_NO_AUTOEN instead of 
calling disable_irq() right after request_irq()

5) drop DP_HPD_INIT_SETUP and related code

> 
> Meanwhile, can you approve this patch so that it will not block our 
> internal daily testing?

Quoting your commit message: "Since dp_display_host_init() of external
DP is executed at hpd thread context...". After these changes the 
mentioned function will no longer be executed from the hpd thread. So, 
let's rework the probe/init sequence first, then we can see if this 
patch is still necessary and how should it look.

-- 
With best wishes
Dmitry