DRM i2c module or bridge ?

[Emil Velikov]

Hi Archit,

On 7 December 2015 at 08:47, Archit Taneja <architt at codeaurora.org> wrote:
> On 11/12/2015 07:20 PM, Emil Velikov wrote:
>> 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.
>
>
> 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