Hi Archit, On 7 December 2015 at 08:47, Archit Taneja <architt@xxxxxxxxxxxxxx> wrote: > On 11/12/2015 07:20 PM, Emil Velikov wrote: >> 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. > > > Please refer to the following thread for a similar discussion: > > http://lists.freedesktop.org/archives/dri-devel/2015-July/087097.html > Thanks for the link, I've already seen the discussion. Yet I did not find it as "clear cut" as Thierry's answer. >> >> 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. > > > We still have a requirement for such encoders in the SoC world. A SoC > may provide a particular kind of encoder output, but we might need to > convert that into another type of encoded output. There are multiple > reasons why we might want to do this (SoC limitations, support old > encoded formats like LVDS, weird requirements on some boards). > > There is also a trend of re-use of the same third party encoder IPs > across multiple SoCs. Having bridges for such IPs is helpful too. > Reusing things drivers multiple SoC is great imho. As Rob mentioned in another thread - albeit (slightly) awkward one could port the i2c driver to a bridge one, as as al the users of the former are converted it can be nuked. We'll get there one day :-) -Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
