[PATCH v3 12/19] drm/mcde: dsi: don't create a panel_bridge

[Maxime Ripard]

On Thu, Sep 24, 2026 at 09:51:53AM +0200, Linus Walleij wrote:
> Hi Luca,
> 
> sorry for my slowness!
> 
> On Thu, Sep 24, 2026 at 9:01 AM Luca Ceresoli <luca.ceresoli at bootlin.com> wrote:
> > On Tue Sep 22, 2026 at 9:09 AM CEST, Maxime Ripard wrote:
> 
> > >> -    } else if (bridge) {
> > >> +    if (!bridge) {
> > >> +            dev_err(dev, "no bridge\n");
> > >> +            return -ENODEV;
> > >> +    } else if (!drm_bridge_is_panel(bridge)) {
> > >>              /* TODO: AV8100 HDMI encoder goes here for example */
> > >>              dev_info(dev, "connected to non-panel bridge (unsupported)\n");
> > >>              return -ENODEV;
> > >
> > > I wonder if we still need that branch. Every panel is a bridge now, and
> > > it looks like we don't have any specific panel handling in this driver,
> > > so I guess it supports bridges already?
> > >
> > > Linus, do you know why this condition was here in the first place?
> >
> > I had the same thought while writing the patch, but I chose to be
> > conservative.
> >
> > Linus, unless you have more info I'm going to apply the patch as
> > is. Removing this special case would be welcome as a later patch.
> 
> I'd say go ahead as-is.

I'm fine with that, but I really want this removed at some point.

> I do have the idea to code up and submit the AV8100 encoder
> and I have the hardware to test it, but every other user should
> be using panels directly, and I would be the only non-panel
> user so I can deal with it when it comes up.

It won't change a thing. All existing "panel" users will be bridge users
after this patch is merged. So whether you want to enable a bridge or
not shouldn't matter, the only thing that does is whether the existing
users would still work.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20260924/17b7f883/attachment.sig>