Re: [PATCH v6 07/14] drm/bridge: analogix_dp: Add support to get panel from the DP AUX bus

Hi Doug,

On 2025/1/24 11:13, Doug Anderson wrote:

Hi,

On Thu, Jan 23, 2025 at 3:25 AM Dmitry Baryshkov
[off-list ref] wrote:

quoted

On Thu, Jan 23, 2025 at 06:07:40PM +0800, Damon Ding wrote:

quoted

The main modification is moving the DP AUX initialization from function
analogix_dp_bind() to analogix_dp_probe(). In order to get the EDID of
eDP panel during probing, it is also needed to advance PM operaions to

nit: s/operaions/operations

I will fix it in the next version.

quoted

quoted

ensure that eDP controller and phy are prepared for AUX transmission.

This doesn't sound right. Per the documentation of
drm_dp_aux::transfer(), the device should power itself up if transfer()
is called when it is powered off. The caller must only ensure that the
panel is on.

Doug, what's your opinion?

I think maybe the CL description is a bit confusing, but looking at
the patch I think that the general idea is correct. drm_dp_aux_init()
is expected to be called in probe() and not in bind(). ...and in order
for it to work then pm_runtime needs to be enabled at probe and not at
bind. So both of those two things that this patch does are (in my
opinion) correct.

quoted

quoted

In addtion, add a new function analogix_dp_remove() to ensure symmetry
for PM operations.

Signed-off-by: Damon Ding <redacted>

---

Changes in v4:
- Use done_probing() to call drm_of_find_panel_or_bridge() and
   component_add() when getting panel from the DP AUX bus

Changes in v5:
- Advance PM operations to make eDP AUX work well

Changes in v6:
- Use devm_pm_runtime_enable() instead of devm_add_action_or_reset()
- Add a new function analogix_dp_remove() to ensure symmetry for PM
   operations
---
  .../drm/bridge/analogix/analogix_dp_core.c    | 57 ++++++++++---------
  .../gpu/drm/rockchip/analogix_dp-rockchip.c   |  4 ++
  include/drm/bridge/analogix_dp.h              |  1 +
  3 files changed, 34 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 8251adfce2f9..30da8a14361e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c

@@ -1658,14 +1658,42 @@ analogix_dp_probe(struct device *dev, struct analogix_dp_plat_data *plat_data)
       }
       disable_irq(dp->irq);

not related to your patch, but probably needs to be a prerequisite of
your patch: instead of calling disable_irq() here, you should OR in
"IRQF_NO_AUTOEN" to the "irq_flags" of devm_request_threaded_irq().
That not only closes a potential race condition but also makes all the
error handling much more robust.

Yes, it is nice to set the IRQF_NO_AUTOEN flag rather than calling the 
disable_irq().

quoted

quoted

+     dp->aux.name = "DP-AUX";
+     dp->aux.transfer = analogix_dpaux_transfer;
+     dp->aux.dev = dp->dev;
+     drm_dp_aux_init(&dp->aux);

FWIW: I would highly encourage you to (in a separate patch) add
wait_hpd_asserted() support here. It is deprecated to not implement
wait_hpd_asserted(). See the definition of "wait_hpd_asserted" in
"struct drm_dp_aux" if you're going to support eDP panels.

Indeed, the &drm_dp_aux.wait_hpd_asserted() help confirm the HPD state 
before doing AUX transfers. I will add it in the next version.

quoted

quoted

+     if (IS_ENABLED(CONFIG_PM)) {

Do we really truly need this? Is there anyone actually using this
driver without "CONFIG_PM", or can we just assume CONFIG_PM. For the
most part drivers I've interacted with just assume CONFIG_PM and
they're a lot simpler because of it. If there's truly a need then we
can keep this complexity, but I'd rather wait until there is a user.
Maybe you could add this as a dependency in the Kconfig if needed.

I would also like to remove the CONFIG_PM related check, which would 
make the code more concise. And I believe that it would be a good idea 
to remove it and wait until there is a user who actually needs it.

quoted

quoted

+             pm_runtime_use_autosuspend(dp->dev);
+             pm_runtime_set_autosuspend_delay(dp->dev, 100);
+             ret = devm_pm_runtime_enable(dp->dev);
+             if (ret)
+                     goto err_disable_pm_runtime;
+     } else {
+             ret = analogix_dp_resume(dp);
+             if (ret)
+                     goto err_disable_clk;

IMO: if analogix_dp_resume() succeeds, use devm_add_action_or_reset()
to have a function call analogix_dp_suspend(). Then you can keep using
"devm" for everything and totally get rid of the need for the
analogix_dp_remove() function.

It may be better to drop the 'complex' check about CONFIG_PM and just 
keep using 'devm' as mentioned above.

quoted

quoted

+     }
+
       return dp;

+err_disable_pm_runtime:
+     pm_runtime_dont_use_autosuspend(dp->dev);

You don't need to call pm_runtime_dont_use_autosuspend(). If you
enabled pm_runtime with devm_pm_runtime_enable() then it's documented
to handle calling pm_runtime_dont_use_autosuspend() for you. See the
kernel doc comment for devm_pm_runtime_enable(). So you can get rid of
this.

Yeah, I find the comment in the definition of 
pm_runtime_use_autosuspend() and I will remove it in the next version.

quoted

quoted

  err_disable_clk:
       clk_disable_unprepare(dp->clock);
       return ERR_PTR(ret);

Huh? Why would you call "err_disable_clk" here? The only thing that
enables the clock is analogix_dp_resume(), right? There's something
fishy here and it predates your patch. I suspect there were problems
in commit f37952339cc2 ("drm/bridge: analogix_dp: handle clock via
runtime PM"). You should fix that in a separate patch before yours.

Yes, I believe there is a small bug in the commit mentioned above and I 
will add a separate patch to fix it.

quoted

quoted

+void analogix_dp_remove(struct analogix_dp_device *dp)
+{
+     if (IS_ENABLED(CONFIG_PM))
+             pm_runtime_dont_use_autosuspend(dp->dev);
+     else
+             analogix_dp_suspend(dp);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_remove);

See above. Proper use of "devm" should mean you don't need a remove() function.

Yeah, the analogix_dp_remove() is not needed based on the above discussion.

Best regards
Damon