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

[Laurent Pinchart]

Hi Russell,

On Wednesday 19 Oct 2016 10:11:22 Russell King - ARM Linux wrote:
> On Wed, Oct 19, 2016 at 11:52:15AM +0300, Laurent Pinchart wrote:
> > On Wednesday 19 Oct 2016 09:16:30 Russell King - ARM Linux wrote:
> >> On Wed, Oct 19, 2016 at 10:54:06AM +0300, Laurent Pinchart wrote:
> >>> On Wednesday 19 Oct 2016 00:33:54 Jyri Sarha wrote:
> >>>> Remove obsolete drm_connector_register() call from tda998x_bind().
> >>>> All connectors are registered when drm_dev_register() is called by the
> >>>> master drm_device driver.
> >>>> 
> >>>> Signed-off-by: Jyri Sarha <jsarha at ti.com>
> >>> 
> >>> Acked-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> >>> 
> >>> By the way, any chance you would plan porting the driver to drm_bridge
> >>> ? :-)
> >>
> >> What's the point?
> > 
> > Avoiding code duplication. We currently have three APIs to handle external
> > encoders (drm encoder slave, drm bridge and the component-based method
> > used by tda998x only), which requires display drivers that want to
> > support multiple external encoders to use up to three APIs.
> 
> tda998x doesn't use the encoder slave anymore.  You somehow list component-
> based as a third alternative - it isn't, that's the native DRM non-bridge
> method.

The order in my list was random, component-based instantiation of external 
encoders is one method, not specifically the third one :-)

> 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.

-- 
Regards,

Laurent Pinchart