On Thu, 2 Mar 2023 at 20:41, Kuogee Hsieh <quic_khsieh@xxxxxxxxxxx> wrote:
Should be moved to probe.
On 3/1/2023 1:15 PM, Dmitry Baryshkov wrote:
On 01/03/2023 18:57, Kuogee Hsieh wrote:sorry, previously i mis understand your question -- why does DP driver
On 2/28/2023 6:16 PM, Dmitry Baryshkov wrote:No, he is doing another thing. He is moving these calls to pm_runtime
On Wed, 1 Mar 2023 at 02:17, Kuogee Hsieh <quic_khsieh@xxxxxxxxxxx>yes, Sankeerth's "drm/msm/dp: enable pm_runtime support for dp
wrote:
There is a reboot/suspend test case where system suspend is forcedCan a call to dp_display_host_init() be moved from
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.
dp_display_config_hpd() to dp_display_bind()?
driver" patch is doing that which is under review.
https://patchwork.freedesktop.org/patch/523879/?series=114297&rev=1
callbacks, not to the dp_display_bind().
So... DP irq is enabled by the MDSS, not by the DPU. Again, why doesRelated question: what is the primary reason for havingHDP gpio pin has to run through DP aux module 100ms denouncing logic
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().
and have its mask bits.
Therefore DP irq has to be enabled to receive DP isr with mask bits set.
DP driver depend on DPU irqs being installed?
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 atAnd the AUX bus population should also be moved to probe(), which
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.
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 complicateHopefully the changes suggested above will make it simpler.
things up.