On 3/2/2023 11:04 AM, Dmitry Baryshkov wrote:
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.
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?
