Re: [PATCH v2 4/6] drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Wed, Aug 11, 2021 at 01:51:28PM -0700, Rob Clark wrote:
> On Wed, Aug 11, 2021 at 1:39 PM Stephen Boyd wrote:
> > Quoting Rob Clark (2021-08-11 09:20:30)
> > > On Wed, Aug 11, 2021 at 5:15 AM Laurent Pinchart wrote:
> > > > On Tue, Aug 10, 2021 at 10:26:33PM -0700, Stephen Boyd wrote:
> > > > > Quoting Laurent Pinchart (2021-06-23 17:03:02)
> > > > > > To simplify interfacing with the panel, wrap it in a panel-bridge and
> > > > > > let the DRM bridge helpers handle chaining of operations.
> > > > > >
> > > > > > This also prepares for support of DRM_BRIDGE_ATTACH_NO_CONNECTOR, which
> > > > > > requires all components in the display pipeline to be represented by
> > > > > > bridges.
> > > > > >
> > > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > > > > > Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > > > ---
> > > > >
> > > > > With this patch applied I get two eDP devices on Lazor sc7180 (it is the
> > > > > arch/arm64/boot/dts/qcom/sc7180-trogdor-lazor*.dts files if you're
> > > > > looking for more info). As far as I can tell, we should only have one
> > > > > eDP device on the board, for the bridge.
> > > > >
> > > > > localhost ~ # ls -l /sys/class/drm/card1-eDP*
> > > > > lrwxrwxrwx. 1 root root 0 Aug 10 22:24 /sys/class/drm/card1-eDP-1 ->
> > > > > ../../devices/platform/soc@0/ae00000.mdss/drm/card1/card1-eDP-1
> > > > > lrwxrwxrwx. 1 root root 0 Aug 10 22:24 /sys/class/drm/card1-eDP-2 ->
> > > > > ../../devices/platform/soc@0/ae00000.mdss/drm/card1/card1-eDP-2
> > > >
> > > > Indeed.
> > > >
> > > > Does the display driver use the DRM connector bridge helper and
> > > > DRM_BRIDGE_ATTACH_NO_CONNECTOR on that platform ?
> > >
> > > There haven't been any recent changes about how we attach the bridge,
> > > it doesn't pass DRM_BRIDGE_ATTACH_NO_CONNECTOR.. tbh I've not been
> > > having time to follow too closely the recent changes with bridge stuff
> > > myself.
> > >
> > > But now with this patch we have both the ti bridge and the panel
> > > bridge creating a connector..  removing the connector created by the
> > > ti bridge "fixes" things, but not sure if that would break something
> > > on other platforms.  I guess there should now always be a panel
> > > bridge, so removing ti_sn_bridge_connector_init() would be a sane
> > > thing to do?
> >
> > So this patch works. We don't want to make the connector in this driver
> > for the next bridge because this driver is making the connector. I guess
> > eventually we'll drop this flag when this driver stops making the
> > connector here?
> >
> > ---8<---
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index cd0fccdd8dfd..a8d4818484aa 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -741,7 +741,7 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
> >
> >         /* Attach the next bridge */
> >         ret = drm_bridge_attach(bridge->encoder, pdata->next_bridge,
> > -                               &pdata->bridge, flags);
> > +                               &pdata->bridge, flags | DRM_BRIDGE_ATTACH_NO_CONNECTOR);
> >         if (ret < 0)
> >                 goto err_dsi_detach;
> 
> I kinda think *all* bridges that create a connector (whether optional
> or not) should OR in NO_CONNECTOR when attaching the next downstream
> bridge.. since you never want multiple connectors

Yes, that sounds reasonable to me. Stephen, would you like to set a
patch ?

-- 
Regards,

Laurent Pinchart