linux-kernel - Re: [PATCH v6 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 21 Oct 2021 10:00:36 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Kevin Tang <kevin3.tang@...il.com>
Cc:     Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Sean Paul <sean@...rly.run>, David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>, pony1.wu@...il.com,
        Orson Zhai <orsonzhai@...il.com>,
        Chunyan Zhang <zhang.lyra@...il.com>,
        "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
        ML dri-devel <dri-devel@...ts.freedesktop.org>,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v6 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver

Hi,

On Wed, Oct 20, 2021 at 06:09:32PM +0800, Kevin Tang wrote:
> Maxime Ripard <maxime@...no.tech> 于2021年9月28日周二 下午5:28写道：
> > > > > +static int sprd_dsi_find_panel(struct sprd_dsi *dsi)
> > > > > +{
> > > > > +     struct device *dev = dsi->host.dev;
> > > > > +     struct device_node *child, *lcds_node;
> > > > > +     struct drm_panel *panel;
> > > > > +
> > > > > +     /* search /lcds child node first */
> > > > > +     lcds_node = of_find_node_by_path("/lcds");
> > > > > +     for_each_child_of_node(lcds_node, child) {
> > > > > +             panel = of_drm_find_panel(child);
> > > > > +             if (!IS_ERR(panel)) {
> > > > > +                     dsi->panel = panel;
> > > > > +                     return 0;
> > > > > +             }
> > > > > +     }
> > > > > +
> > > > > +     /*
> > > > > +      * If /lcds child node search failed, we search
> > > > > +      * the child of dsi host node.
> > > > > +      */
> > > > > +     for_each_child_of_node(dev->of_node, child) {
> > > > > +             panel = of_drm_find_panel(child);
> > > > > +             if (!IS_ERR(panel)) {
> > > > > +                     dsi->panel = panel;
> > > > > +                     return 0;
> > > > > +             }
> > > > > +     }
> > > > > +
> > > > > +     drm_err(dsi->drm, "of_drm_find_panel() failed\n");
> > > > > +     return -ENODEV;
> > > > > +}
> > > >
> > > > Just use devm_drm_of_get_bridge there
> > >
> > > We use drm_panel_init and drm_panel_add API to add panel, so here is a
> > > panel device, not a bridge.
> >
> > Like Sam said, the panel API is on its way out and is being superseded
> > by bridge_panels.
>
> If get a panel by devm_drm_of_get_bridge, how to use bridge api to
> access panel?

You don't.

You'd get a panel-bridge driver (drivers/gpu/drm/bridge/panel.c), that
behaves like a bridge and will call the panel functions itself.

And since it's a bridge, everything (enable, pre_enable, etc.) is called
by the core framework (in drm_atomic_helper_commit_modeset_enables for
enable and pre_enable).

> it seems that pre_enable/enable still needs to be implemented, so we
> need to add drm_bridge_func, then move the panel-related operations in
> drm_encoder_helper_funcs to drm_bridge_funcs callback?

You're confusing two things. Our comment wasn't that this DSI needed to
be converted to a bridge itself (which is what you're talking about),
but that it needs to use the bridge API instead of the panel API to deal
with whatever is connected at the other end of the DSI link.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)