On Wed, Aug 11, 2021 at 1:39 PM Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote: > > Quoting Rob Clark (2021-08-11 09:20:30) > > On Wed, Aug 11, 2021 at 5:15 AM Laurent Pinchart > > <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > > > > > > Hi Stephen, > > > > > > 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@xxxxxxxxxxxxxxxx> > > > > > Reviewed-by: Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> > > > > > --- > > > > > > > > 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 BR, -R
