Messages in this thread | | | Date | Fri, 3 Mar 2023 14:45:48 -0800 | Subject | Re: [PATCH v3] drm/msm/dp: check core_initialized flag at both host_init() and host_deinit() | From | Kuogee Hsieh <> |
| |
On 3/2/2023 11:04 AM, Dmitry Baryshkov wrote: > On Thu, 2 Mar 2023 at 20:41, Kuogee Hsieh <quic_khsieh@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@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
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())
Meanwhile, can you approve this patch so that it will not block our internal daily testing?
>
| |