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

[Dmitry Baryshkov]

On Thu, 2 Mar 2023 at 20:41, Kuogee Hsieh <quic_khsieh@xxxxxxxxxxx> 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@xxxxxxxxxxx>
> >>> 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.

-- 
With best wishes
Dmitry