DRM i2c module or bridge ?

[Emil Velikov]

On 12 November 2015 at 13:18, Thierry Reding <thierry.reding at gmail.com> 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