Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 21 Oct 2021 10:00:36 +0200
From:   Maxime Ripard <maxime@cerno.tech>
To:     Kevin Tang <kevin3.tang@gmail.com>
Cc:     Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
        Daniel Vetter <daniel@ffwll.ch>,
        Rob Herring <robh+dt@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>, pony1.wu@gmail.com,
        Orson Zhai <orsonzhai@gmail.com>,
        Chunyan Zhang <zhang.lyra@gmail.com>,
        "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
        ML dri-devel <dri-devel@lists.freedesktop.org>,
        devicetree@vger.kernel.org
Subject: Re: [PATCH v6 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver
Message-ID: <20211021080036.w7xgrwggrm6lnnlz@gilmour>
References: <20210813145302.3933-1-kevin3.tang@gmail.com>
 <20210813145302.3933-7-kevin3.tang@gmail.com>
 <20210917154047.leojvqjqjj2sg34l@gilmour>
 <CAFPSGXZbqh0f6kEoQaq_Nt677ksVS6QPdAa5==KVVAszSAuasw@mail.gmail.com>
 <20210928092805.wbc4ev3ze7a7zgqr@gilmour>
 <CAFPSGXZta-oJ7Hp3AyiGjpXr5e42g3r24Su6-L6HOwMR4QU5Zw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="i6g4hmj32as2fgck"
Content-Disposition: inline
In-Reply-To: <CAFPSGXZta-oJ7Hp3AyiGjpXr5e42g3r24Su6-L6HOwMR4QU5Zw@mail.gmail.com>
Precedence: bulk


--i6g4hmj32as2fgck
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, Oct 20, 2021 at 06:09:32PM +0800, Kevin Tang wrote:
> Maxime Ripard <maxime@cerno.tech> =E4=BA=8E2021=E5=B9=B49=E6=9C=8828=E6=
=97=A5=E5=91=A8=E4=BA=8C =E4=B8=8B=E5=8D=885:28=E5=86=99=E9=81=93=EF=BC=9A
> > > > > +static int sprd_dsi_find_panel(struct sprd_dsi *dsi)
> > > > > +{
> > > > > +     struct device *dev =3D dsi->host.dev;
> > > > > +     struct device_node *child, *lcds_node;
> > > > > +     struct drm_panel *panel;
> > > > > +
> > > > > +     /* search /lcds child node first */
> > > > > +     lcds_node =3D of_find_node_by_path("/lcds");
> > > > > +     for_each_child_of_node(lcds_node, child) {
> > > > > +             panel =3D of_drm_find_panel(child);
> > > > > +             if (!IS_ERR(panel)) {
> > > > > +                     dsi->panel =3D 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 =3D of_drm_find_panel(child);
> > > > > +             if (!IS_ERR(panel)) {
> > > > > +                     dsi->panel =3D 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

--i6g4hmj32as2fgck
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYXEeJAAKCRDj7w1vZxhR
xerMAQDbIo8QFD7KUkFklmhedJmVHyFchTfLdfiE1FF1+eH9kgD/ZjeaSdS2M5UF
gG3hG8RoV0DSuQhW0hjs7vqZVdfd9wc=
=cWgY
-----END PGP SIGNATURE-----

--i6g4hmj32as2fgck--