| Message ID | 1677629817-18891-1-git-send-email-quic_khsieh@quicinc.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | [v3] drm/msm/dp: check core_initialized flag at both host_init() and host_deinit() | expand |
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()? 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(). > > Changes in v2: > -- at commit text, dp_display_host_init() instead of host_init() > -- at commit text, dp_display_host_deinit() instead of host_deinit() > > Changes in v3: > -- re arrange to avoid commit text line over 75 chars > > Fixes: 989ebe7bc446 ("drm/msm/dp: do not initialize phy until plugin interrupt received") > Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> > Reviewed-by: Stephen Boyd <swboyd@chromium.org> > --- > drivers/gpu/drm/msm/dp/dp_display.c | 20 ++++++++++++-------- > 1 file changed, 12 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c > index bde1a7c..1850738 100644 > --- a/drivers/gpu/drm/msm/dp/dp_display.c > +++ b/drivers/gpu/drm/msm/dp/dp_display.c > @@ -460,10 +460,12 @@ static void dp_display_host_init(struct dp_display_private *dp) > dp->dp_display.connector_type, dp->core_initialized, > dp->phy_initialized); > > - dp_power_init(dp->power, false); > - dp_ctrl_reset_irq_ctrl(dp->ctrl, true); > - dp_aux_init(dp->aux); > - dp->core_initialized = true; > + if (!dp->core_initialized) { > + dp_power_init(dp->power, false); > + dp_ctrl_reset_irq_ctrl(dp->ctrl, true); > + dp_aux_init(dp->aux); > + dp->core_initialized = true; > + } > } > > static void dp_display_host_deinit(struct dp_display_private *dp) > @@ -472,10 +474,12 @@ static void dp_display_host_deinit(struct dp_display_private *dp) > dp->dp_display.connector_type, dp->core_initialized, > dp->phy_initialized); > > - dp_ctrl_reset_irq_ctrl(dp->ctrl, false); > - dp_aux_deinit(dp->aux); > - dp_power_deinit(dp->power); > - dp->core_initialized = false; > + if (dp->core_initialized) { > + dp_ctrl_reset_irq_ctrl(dp->ctrl, false); > + dp_aux_deinit(dp->aux); > + dp_power_deinit(dp->power); > + dp->core_initialized = false; > + } > } > > static int dp_display_usbpd_configure_cb(struct device *dev) > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > a Linux Foundation Collaborative Project >
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 > > 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. Similar mechanism is used for mdp, dsi, etc. >> Changes in v2: >> -- at commit text, dp_display_host_init() instead of host_init() >> -- at commit text, dp_display_host_deinit() instead of host_deinit() >> >> Changes in v3: >> -- re arrange to avoid commit text line over 75 chars >> >> Fixes: 989ebe7bc446 ("drm/msm/dp: do not initialize phy until plugin interrupt received") >> Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> >> Reviewed-by: Stephen Boyd <swboyd@chromium.org> >> --- >> drivers/gpu/drm/msm/dp/dp_display.c | 20 ++++++++++++-------- >> 1 file changed, 12 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c >> index bde1a7c..1850738 100644 >> --- a/drivers/gpu/drm/msm/dp/dp_display.c >> +++ b/drivers/gpu/drm/msm/dp/dp_display.c >> @@ -460,10 +460,12 @@ static void dp_display_host_init(struct dp_display_private *dp) >> dp->dp_display.connector_type, dp->core_initialized, >> dp->phy_initialized); >> >> - dp_power_init(dp->power, false); >> - dp_ctrl_reset_irq_ctrl(dp->ctrl, true); >> - dp_aux_init(dp->aux); >> - dp->core_initialized = true; >> + if (!dp->core_initialized) { >> + dp_power_init(dp->power, false); >> + dp_ctrl_reset_irq_ctrl(dp->ctrl, true); >> + dp_aux_init(dp->aux); >> + dp->core_initialized = true; >> + } >> } >> >> static void dp_display_host_deinit(struct dp_display_private *dp) >> @@ -472,10 +474,12 @@ static void dp_display_host_deinit(struct dp_display_private *dp) >> dp->dp_display.connector_type, dp->core_initialized, >> dp->phy_initialized); >> >> - dp_ctrl_reset_irq_ctrl(dp->ctrl, false); >> - dp_aux_deinit(dp->aux); >> - dp_power_deinit(dp->power); >> - dp->core_initialized = false; >> + if (dp->core_initialized) { >> + dp_ctrl_reset_irq_ctrl(dp->ctrl, false); >> + dp_aux_deinit(dp->aux); >> + dp_power_deinit(dp->power); >> + dp->core_initialized = false; >> + } >> } >> >> static int dp_display_usbpd_configure_cb(struct device *dev) >> -- >> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, >> a Linux Foundation Collaborative Project >> >
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? > Similar mechanism is used for mdp, dsi, etc. And none of them uses irq_postinstall callback. > > >>> Changes in v2: >>> -- at commit text, dp_display_host_init() instead of host_init() >>> -- at commit text, dp_display_host_deinit() instead of host_deinit() >>> >>> Changes in v3: >>> -- re arrange to avoid commit text line over 75 chars >>> >>> Fixes: 989ebe7bc446 ("drm/msm/dp: do not initialize phy until plugin >>> interrupt received") >>> Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> >>> Reviewed-by: Stephen Boyd <swboyd@chromium.org> >>> --- >>> drivers/gpu/drm/msm/dp/dp_display.c | 20 ++++++++++++-------- >>> 1 file changed, 12 insertions(+), 8 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c >>> b/drivers/gpu/drm/msm/dp/dp_display.c >>> index bde1a7c..1850738 100644 >>> --- a/drivers/gpu/drm/msm/dp/dp_display.c >>> +++ b/drivers/gpu/drm/msm/dp/dp_display.c >>> @@ -460,10 +460,12 @@ static void dp_display_host_init(struct >>> dp_display_private *dp) >>> dp->dp_display.connector_type, dp->core_initialized, >>> dp->phy_initialized); >>> >>> - dp_power_init(dp->power, false); >>> - dp_ctrl_reset_irq_ctrl(dp->ctrl, true); >>> - dp_aux_init(dp->aux); >>> - dp->core_initialized = true; >>> + if (!dp->core_initialized) { >>> + dp_power_init(dp->power, false); >>> + dp_ctrl_reset_irq_ctrl(dp->ctrl, true); >>> + dp_aux_init(dp->aux); >>> + dp->core_initialized = true; >>> + } >>> } >>> >>> static void dp_display_host_deinit(struct dp_display_private *dp) >>> @@ -472,10 +474,12 @@ static void dp_display_host_deinit(struct >>> dp_display_private *dp) >>> dp->dp_display.connector_type, dp->core_initialized, >>> dp->phy_initialized); >>> >>> - dp_ctrl_reset_irq_ctrl(dp->ctrl, false); >>> - dp_aux_deinit(dp->aux); >>> - dp_power_deinit(dp->power); >>> - dp->core_initialized = false; >>> + if (dp->core_initialized) { >>> + dp_ctrl_reset_irq_ctrl(dp->ctrl, false); >>> + dp_aux_deinit(dp->aux); >>> + dp_power_deinit(dp->power); >>> + dp->core_initialized = false; >>> + } >>> } >>> >>> static int dp_display_usbpd_configure_cb(struct device *dev) >>> -- >>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora >>> Forum, >>> a Linux Foundation Collaborative Project >>> >>
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. 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. This may create some uncertainties at execution flow and complicate things up. > >> Similar mechanism is used for mdp, dsi, etc. > > And none of them uses irq_postinstall callback. > >> >> >>>> Changes in v2: >>>> -- at commit text, dp_display_host_init() instead of host_init() >>>> -- at commit text, dp_display_host_deinit() instead of host_deinit() >>>> >>>> Changes in v3: >>>> -- re arrange to avoid commit text line over 75 chars >>>> >>>> Fixes: 989ebe7bc446 ("drm/msm/dp: do not initialize phy until >>>> plugin interrupt received") >>>> Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> >>>> Reviewed-by: Stephen Boyd <swboyd@chromium.org> >>>> --- >>>> drivers/gpu/drm/msm/dp/dp_display.c | 20 ++++++++++++-------- >>>> 1 file changed, 12 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c >>>> b/drivers/gpu/drm/msm/dp/dp_display.c >>>> index bde1a7c..1850738 100644 >>>> --- a/drivers/gpu/drm/msm/dp/dp_display.c >>>> +++ b/drivers/gpu/drm/msm/dp/dp_display.c >>>> @@ -460,10 +460,12 @@ static void dp_display_host_init(struct >>>> dp_display_private *dp) >>>> dp->dp_display.connector_type, dp->core_initialized, >>>> dp->phy_initialized); >>>> >>>> - dp_power_init(dp->power, false); >>>> - dp_ctrl_reset_irq_ctrl(dp->ctrl, true); >>>> - dp_aux_init(dp->aux); >>>> - dp->core_initialized = true; >>>> + if (!dp->core_initialized) { >>>> + dp_power_init(dp->power, false); >>>> + dp_ctrl_reset_irq_ctrl(dp->ctrl, true); >>>> + dp_aux_init(dp->aux); >>>> + dp->core_initialized = true; >>>> + } >>>> } >>>> >>>> static void dp_display_host_deinit(struct dp_display_private *dp) >>>> @@ -472,10 +474,12 @@ static void dp_display_host_deinit(struct >>>> dp_display_private *dp) >>>> dp->dp_display.connector_type, dp->core_initialized, >>>> dp->phy_initialized); >>>> >>>> - dp_ctrl_reset_irq_ctrl(dp->ctrl, false); >>>> - dp_aux_deinit(dp->aux); >>>> - dp_power_deinit(dp->power); >>>> - dp->core_initialized = false; >>>> + if (dp->core_initialized) { >>>> + dp_ctrl_reset_irq_ctrl(dp->ctrl, false); >>>> + dp_aux_deinit(dp->aux); >>>> + dp_power_deinit(dp->power); >>>> + dp->core_initialized = false; >>>> + } >>>> } >>>> >>>> static int dp_display_usbpd_configure_cb(struct device *dev) >>>> -- >>>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora >>>> Forum, >>>> a Linux Foundation Collaborative Project >>>> >>> >
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.
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? >
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@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 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.
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index bde1a7c..1850738 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -460,10 +460,12 @@ static void dp_display_host_init(struct dp_display_private *dp) dp->dp_display.connector_type, dp->core_initialized, dp->phy_initialized); - dp_power_init(dp->power, false); - dp_ctrl_reset_irq_ctrl(dp->ctrl, true); - dp_aux_init(dp->aux); - dp->core_initialized = true; + if (!dp->core_initialized) { + dp_power_init(dp->power, false); + dp_ctrl_reset_irq_ctrl(dp->ctrl, true); + dp_aux_init(dp->aux); + dp->core_initialized = true; + } } static void dp_display_host_deinit(struct dp_display_private *dp) @@ -472,10 +474,12 @@ static void dp_display_host_deinit(struct dp_display_private *dp) dp->dp_display.connector_type, dp->core_initialized, dp->phy_initialized); - dp_ctrl_reset_irq_ctrl(dp->ctrl, false); - dp_aux_deinit(dp->aux); - dp_power_deinit(dp->power); - dp->core_initialized = false; + if (dp->core_initialized) { + dp_ctrl_reset_irq_ctrl(dp->ctrl, false); + dp_aux_deinit(dp->aux); + dp_power_deinit(dp->power); + dp->core_initialized = false; + } } static int dp_display_usbpd_configure_cb(struct device *dev)
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. Changes in v2: -- at commit text, dp_display_host_init() instead of host_init() -- at commit text, dp_display_host_deinit() instead of host_deinit() Changes in v3: -- re arrange to avoid commit text line over 75 chars Fixes: 989ebe7bc446 ("drm/msm/dp: do not initialize phy until plugin interrupt received") Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> --- drivers/gpu/drm/msm/dp/dp_display.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-)