[PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver

[Rob Herring]

On Mon, Nov 14, 2016 at 06:54:17PM +0200, Jyri Sarha wrote:
> Add very basic ti-ftp410 DVI transmitter driver. The only feature
> separating this from a completely dummy bridge is the EDID read
> support trough DDC I2C. Even that functionality should be in a
> separate generic connector driver. However, because of missing DRM
> infrastructure support the connector is implemented within the bridge
> driver. Some tfp410 HW specific features may be added later if needed,
> because there is a set of registers behind i2c if it is connected.
> 
> This implementations is tested against my new tilcdc bridge support
> and it works with BeagleBone DVI-D Cape Rev A3. A DT binding document
> is also added.
> 
> Signed-off-by: Jyri Sarha <jsarha at ti.com>
> ---
>  .../bindings/display/bridge/ti,tfp410.txt          |  41 ++++
>  drivers/gpu/drm/bridge/Kconfig                     |   7 +
>  drivers/gpu/drm/bridge/Makefile                    |   1 +
>  drivers/gpu/drm/bridge/ti-tfp410.c                 | 223 +++++++++++++++++++++
>  4 files changed, 272 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
>  create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> new file mode 100644
> index 0000000..7446b2b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> @@ -0,0 +1,41 @@
> +TFP410 DVI bridge bindings
> +
> +Required properties:
> +	- compatible: "ti,tfp410"
> +
> +Optional properties
> +	- reg: I2C address. If and only if present the driver node
> +	  should be placed into the i2c controller node where the
> +	  tfp410 i2c is connected to (the current implementation does
> +	  not yet support this).

So this chip can work without programming I guess?

reg should only be not present if I2C is not connected in the design. It 
can't be a function of what the driver supports. In otherwords, you 
can't be moving this node around based on when you add I2C control.

Rob