On Wed, 18 Apr 2018 10:02:12 +0200 Peter Rosin <peda@xxxxxxxxxx> wrote: > On 2018-04-18 09:36, Boris Brezillon wrote: > > On Tue, 17 Apr 2018 15:10:51 +0200 > > Peter Rosin <peda@xxxxxxxxxx> wrote: > > > >> When the of-graph points to a tda998x-compatible HDMI encoder, register > >> as a component master and bind to the encoder/connector provided by > >> the tda998x driver. > > > > Can't we do the opposite: make the tda998x driver expose its devices as > > drm bridges. I'd rather not add another way to connect external > > encoders (or bridges) to display controller drivers, especially since, > > when I asked DRM maintainers/devs what was the good approach to > > represent such external encoders they pointed me to the drm_bridge > > interface. > > From the cover letter: > > "However, I don't know if the tilcdc driver is interfacing with the > tda998x driver in a sane and modern way" > > So, which way is the future? Should bridges become components or should > existing bridge-like components no longer be components? Are there others? Well, what I've been told a while ago is that drm_bridge will take over drm_encoder_slave and custom drm_encoder/drm_connector implementations when it comes to representing bridges. AFAIU, using the component framework to bind all elements of the pipeline to the display controller is orthogonal to how you represent elements in the pipeline. I mean, you could have a bridge that registers as a component so that display controllers drivers who want to use the component framework don't have to re-code the component-to-bridge glue every time, and those who don't use the component framework can still get access to the bridge. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
