Re: [PATCH 2/4] drm/i2c: tda998x: Remove obsolete drm_connector_register() call

[Russell King - ARM Linux <linux@armlinux.org.uk>]

On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote:
> Hi Russell,
> 
> On Wednesday 19 Oct 2016 10:11:22 Russell King - ARM Linux wrote:
> > In any case, I don't agree with converting it to a DRM bridge - that will
> > mean that we have to split the driver into two pieces, the bridge part
> > handling the mode set specifics, and a connector/encoder part which
> > handles the detection/edid stuff.
> > 
> > We might as well keep the whole thing as the classical connector/encoder
> > rather than introducing this additional layer of complexity.
> 
> We have different ways to instantiate external HDMI encoders, and that's not 
> good. I believe everybody agrees that drm encoder slave has to go, so that's 
> already one problem solved (or rather solvable, it still requires someone to 
> do the work). We will then be left with two different methods, drm bridge and 
> non-bridge component-based instantiation. We need to somehow merge the two, 
> and I'm open to discussions on how the end result should look like.

I think you're idea really doesn't work - and I think your idea that
component-based is somehow separate from other methods is wrong.

Look at iMX for example - even converting all the code that could be
a bridge to be a bridge will not get rid of its use of the component
instantiation, because you still have other components that need to
come from elsewhere.  The same is true of armada as well.

Moreover, as I've already said, converting tda998x to a DRM bridge
will not get rid of the encoder/connector part, because it _is_ a
connector in the DRM sense - it provides the detection and EDID
reading.

So, what would we achieve by splitting the driver into a DRM bridge
and DRM encoder/connector?

We would still need the component helper to manage the binding of
the connector part, which would also then have to register a DRM
bridge in addition to a DRM encoder and providing the DRM connector
as we can't have two device drivers bound to the same i2c device.
What we get is more complexity in the driver.

We can see this with what happened to the DW-HDMI driver - that still
needs the component helper, and it provides a DRM bridge, DRM encoder
and DRM connector parts.  The only reason it made sense to split the
DW-HDMI driver was due to the differences between the Rockchip and
Freescale implementations.  Such differences do not exist for TDA998x.
So even here, your idea that "DRM bridge" vs "non-DRM bridge component
based" doesn't work - we have "DRM bridge component based" because of
the problem that I'm illustrating here.

So, again, I ask: what's the point of needlessly splitting the code
between an encoder/connector and a bridge?

You seem to be forcing the DRM bridge model onto drivers with no
regard for its appropriateness for those drivers.  If it pushes
more complexity into drivers, the model is wrong.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel