Re: [PATCH] drm/vc4: dsi: Only register our component once a DSI device is attached

[Maxime Ripard]

Hi,

On Mon, Jun 21, 2021 at 05:18:22PM +0100, Dave Stevenson wrote:
> Hi Maxime
> 
> On Mon, 21 Jun 2021 at 17:05, Maxime Ripard <maxime@xxxxxxxxxx> wrote:
> >
> > Hi Laurent,
> >
> > On Sun, Jun 20, 2021 at 04:44:33AM +0300, Laurent Pinchart wrote:
> > > Hi Maxime,
> > >
> > > I'm testing this, and I'm afraid it causes an issue with all the
> > > I2C-controlled bridges. I'm focussing on the newly merged ti-sn65dsi83
> > > driver at the moment, but other are affected the same way.
> > >
> > > With this patch, the DSI component is only added when the DSI device is
> > > attached to the host with mipi_dsi_attach(). In the ti-sn65dsi83 driver,
> > > this happens in the bridge attach callback, which is called when the
> > > bridge is attached by a call to drm_bridge_attach() in vc4_dsi_bind().
> > > This creates a circular dependency, and the DRM/KMS device is never
> > > created.
> >
> > We discussed it on IRC, but it makes more sense here.
> >
> > The thing is, that patch is fixing a circular dependency we discussed
> > with Andrzej a year ago:
> >
> > https://lore.kernel.org/dri-devel/20200630132711.ezywhvoiuv3swo57@xxxxxxxxxxx/
> >
> > It seems like we have to choose between having the panels or bridges
> > working :/
> 
> The Pi panel using the panel-raspberrypi-touchscreen driver is flawed
> as it controls the power to the FT5406 touchscreen element as well as
> the display. If DRM powers down the display, power goes to the
> touchscreen too, but the edt-ft5x06 touchscreen driver has no notion
> of this :-(
> 
> The two parts have been broken into bridge/tc358762 and
> regulator/rpi-panel-attiny-regulator which then allows the edt-ft5x06
> driver to keep control over power. I haven't had it be 100% reliable
> though, so I'm still investigating as time allows, but this seems like
> the better solution than panel-raspberrypi-touchscreen.
> 
> With the tc358762 node back under the DSI host node, I think that
> circular dependency you were trying to solve goes away.
> However with sn65dsi83 being I2C configured, is that an issue again?

Even though getting rid of the old driver make it less likely and
reverting that commit make it less likely, we still have the same
fundamental issue.

One thing we could do would be to always register the DSI encoder and
report the connector as connected if the panel has probed. However, I'm
not sure how it helps with a bridge.

Bridges over i2c don't seem too far-fetched to consider too.

Maxime

Attachment: signature.asc
Description: PGP signature