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
