On Thu, Feb 06, 2025 at 07:14:23PM +0100, Luca Ceresoli wrote:
> Adding a panel does currently not add a panel_bridge wrapping it. Usually
> the panel_bridge creation happens when some other driver (e.g. the previous
> bridge or the encoder) calls *_of_get_bridge() and the following element in
> the pipeline is a panel.
>
> This has some drawbacks:
>
> * the panel_bridge is not created in the context of the driver of the
> underlying physical device (the panel driver), but of some other driver
> * that "other driver" is not aware of whether the returned drm_bridge
> pointer is a panel_bridge created on the fly, a pre-existing
> panel_bridge or a non-panel bridge
> * removal of a panel_bridge requires calling drm_panel_bridge_remove(),
> but the "other driver" doesn't know whether this is needed because it
> doesn't know whether it has created a panel_bridge or not
>
> So far this approach has been working because devm and drmm ensure the
> panel bridge would be dealloacted at some later point. However with the
> upcoming implementation of dynamic bridge lifetime this will get more
> complicated.
>
> Correct removal of a panel_bridge might possibly be obtained by adding more
> devm/drmm technology to have it freed correctly at all times. However this
> would add more complexity and not help making lifetime more understandable.
>
> Use a different approach instead: always create a panel_bridge with a
> drm_panel, thus matching the lifetime of the drm_panel and the panel_bridge
> wrapping it. This makes lifetime much more straightforward to understand
> and to further develop on.
>
> With the panel_bridge always created, the functions to get a bridge
> [devm_drm_of_get_bridge() and drmm_of_get_bridge()] become simpler because
> the bridge they are looking for exists already (if it can exist at all). In
> turn, this is implemented based on a variant of
> drm_of_find_panel_or_bridge() that only looks for panels:
> of_drm_find_bridge_by_endpoint(). In the future
> drm_of_find_panel_or_bridge() can be progressively removed because there
> will never be a panel not exposing a bridge.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@xxxxxxxxxxx>
>
> ---
>
> This patch was added in v6.
> ---
> drivers/gpu/drm/bridge/panel.c | 74 +++++++++++++++++++++++++++++++++---------
> include/drm/drm_panel.h | 8 +++++
> 2 files changed, 66 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
> index 58570ff6952ca313b3def084262c9bb3772272ef..6995de605e7317dd1eb153afd475746ced764712 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -69,6 +69,9 @@ EXPORT_SYMBOL(drm_panel_init);
> */
> void drm_panel_add(struct drm_panel *panel)
> {
> + panel->bridge = drm_panel_bridge_add(panel);
> + WARN_ON(!panel->bridge);
> +
> mutex_lock(&panel_lock);
> list_add_tail(&panel->list, &panel_list);
> mutex_unlock(&panel_lock);
> @@ -86,6 +89,9 @@ void drm_panel_remove(struct drm_panel *panel)
> mutex_lock(&panel_lock);
> list_del_init(&panel->list);
> mutex_unlock(&panel_lock);
> +
> + drm_panel_bridge_remove(panel->bridge);
> + panel->bridge = NULL;
> }
> EXPORT_SYMBOL(drm_panel_remove);
Given that drm_panel_add and drm_panel_remove are typically called at
probe/remove, it's pretty much equivalent to using devm. Both of these
solutions aren't safe, and the drm_panel lifetime is still broken.
I'd rather work on a solution that actually fixes those lifetime issues.
Maxime
Attachment:
signature.asc
Description: PGP signature
