On Wed, Aug 08, 2018 at 11:15:47PM +0100, Russell King - ARM Linux wrote:
> On Wed, Aug 08, 2018 at 03:09:30PM -0400, Sean Paul wrote:
> > > -static const struct drm_encoder_helper_funcs tda998x_encoder_helper_funcs = {
> > > - .dpms = tda998x_encoder_dpms,
> > > - .prepare = tda998x_encoder_prepare,
> > > - .commit = tda998x_encoder_commit,
> > > - .mode_set = tda998x_encoder_mode_set,
> > > -};
> >
> > Now that encoder is a stub, it should really be removed from here. The encoder
> > should be instantiated elsewhere and attach the bridge to itself. There are a
> > bunch of examples of this in bridge/
>
> That's not possible at present - this driver has to remain compatible
> with Armada and TI LCDC, both of which expect this driver to create
> the encoder.
Hmm, yeah, I just read that thread. I suppose once bridges play nice with
components the encoder can migrate into the drivers?
>
> In any case, bridges are buggy with unbinding/rebinding as I've pointed
> out several times in the past, but TDA998x used with Armada and TI LCDC
> as it currently stands are not. So, to do this as a full conversion to
> bridge and pushing the encoders into the DRM drivers results in a
> regression for these two DRM drivers. I'm not willing to accept such
> a regression, sorry.
>
> Thanks for the other cleanup suggestions, they can be done with a
> later patch (these changes have already been been merged.)
I still think you should get review from a bridge maintainer before it goes to
drm-next.
Sean
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
> According to speedtest.net: 13Mbps down 490kbps up
--
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
