On 12 November 2015 at 13:18, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > On Thu, Nov 12, 2015 at 12:48:51PM +0000, Emil Velikov wrote: >> Hello Thierry, all, >> >> Inspired by a recent discussion I was started wondering - where is the >> cut between DRM i2c modules (most of which encoders/transmitters) and >> bridge drivers (again some of which i2c encoders) ? Does anyone has >> some pointers on the topic ? > > DRM bridge is a superset of I2C encoders, so everything that I2C encoder > drivers do they should be able to do with DRM bridges, and more. There > isn't a strict guideline here, but I think there's general agreement > that new drivers should be using the DRM bridge framework. The primary > reason is that bridges integrate seamlessly with the driver model, that > is, the drivers that implement them are regular drivers that register > with the corresponding bus and get bound to a device, whereas the I2C > encoder infrastructure is mostly about manually instantiating devices. > > For existing drivers I guess they could all be converted, but doing so > may require a bit of work. They also tend to work as-is, so finding > volunteers to do the conversion is probably going to be difficult given > the lack of motivation. > > Thierry > >> Based on the above I did a very quick search for third party IP >> modules in the DRM subsystem: >> >> * i915 >> dvo_ch7017.c >> dvo_ch7xxx.c >> dvo_ivch.c >> dvo_ns2501.c >> dvo_sil164.c >> dvo_tfp410.c > > It looks like these use some framework that's custom to the i915 driver > but could otherwise easily be DRM bridges. > >> * gma500 >> tc35876x-dsi-lvds.c > > This seems to be some sort of hybrid bridge and panel driver. > >> * sti >> sti_hdmi_tx3g0c55phy.c >> sti_hdmi_tx3g4c28phy.c > > These seem to implement some sort of PHY interface, but from a quick > look moving these to the PHY framework seems overkill. They seem no good > fit for DRM bridge because they are not separate devices, but rather the > SoC generation specific bits of the STi HDMI driver. > >> (and for posterity) >> * i2c >> adv7511.c >> ch7006_drv.c >> sil164_drv.c >> tda998x_drv.c >> >> >> * bridge >> dw_hdmi.c >> nxp-ptn3460.c >> parade-ps8622.c >> >> >> By the looks of it, we can move rework (some of?) the above into >> i2c/bridge modules and in other cases (sil164) just use the existing >> one ? I'm neither volunteering nor suggesting people must work of >> these, merely curious. > > My take on this is that it's probably best to keep the above in their > current form. If they need to be shared across multiple hardware setups > it might make sense to convert them to DRM bridge drivers. > > For new drivers it's probably best to make them bridge drivers from the > start. > Thanks for the comprehensive reply Thierry. Pretty sure there are other people wondering about these - this should straighten things out. Just a small note: considering that most desktop GPUs are moving (have moved ?) away from third party encoders/transmitters I doubt we'll be seeing any movements on that front. Cheers, Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
