Re: [PATCH v3 1/2] drm/bridge: add Silicon Image SiI9234 driver

2017-09-12 Thread Krzysztof Kozlowski
On Mon, Sep 11, 2017 at 1:42 PM, Maciej Purski  wrote:
>>> +   ctx->client[I2C_MHL] = client;
>>> +
>>> +   ctx->client[I2C_TPI] = i2c_new_dummy(adapter, I2C_TPI_ADDR);
>>> +   if (!ctx->client[I2C_TPI]) {
>>> +   dev_err(ctx->dev, "failed to create TPI client\n");
>>> +   return -ENODEV;
>>> +   }
>>> +
>>> +   ctx->client[I2C_HDMI] = i2c_new_dummy(adapter, I2C_HDMI_ADDR);
>>> +   if (!ctx->client[I2C_HDMI]) {
>>> +   dev_err(ctx->dev, "failed to create HDMI RX client\n");
>>> +   goto fail_tpi;
>>> +   }
>>> +
>>> +   ctx->client[I2C_CBUS] = i2c_new_dummy(adapter, I2C_CBUS_ADDR);
>>> +   if (!ctx->client[I2C_CBUS]) {
>>> +   dev_err(ctx->dev, "failed to create CBUS client\n");
>>> +   goto fail_hdmi;
>>> +   }
>>
>> You are using i2c_smbus_* calls. Why not converting to regmap_i2c? It is
>> preferred interface.
>
>
> According to my search, there are only 5 drivers, which use regmap_i2c and
> none of them in drm. If you think that it is really needed, could you please
> explain
> why?

There are slightly more than five drivers:

$ git grep regmap_init_i2c | wc -l
352

... and even more using regmap interface in generic (not i2c).

I think this is really wanted because for free you get:
1. locking,
2. proper locking - with lockdep and nested mutexes :),
3. caching of accesses,
4. handling of endianness,
5. optionally a trivial way of handling interrupts (regmap_irq_chip),

Also this brings unified interface for most of the drivers regardless
of protocol used beneath (I2C, SPI and even MMIO but for simple cases
MMIO might not have much sense). This last argument actually brings
the most benefit for me because it abstracts driver from trivial I2C
implementation and it could allow even easy code-reuse for e.g. SPI
version.


>>
>>> +
>>> +   return 0;
>>> +
>>> +fail_hdmi:
>>> +   i2c_unregister_device(ctx->client[I2C_HDMI]);
>>> +fail_tpi:
>>> +   i2c_unregister_device(ctx->client[I2C_TPI]);
>>> +
>>> +   return -ENODEV;
>>> +}
>>> +
>>> +static void sii9234_deinit_resources(struct sii9234 *ctx)
>>> +{
>>> +   i2c_unregister_device(ctx->client[I2C_CBUS]);
>>> +   i2c_unregister_device(ctx->client[I2C_HDMI]);
>>> +   i2c_unregister_device(ctx->client[I2C_TPI]);
>>> +}
>>> +
>>> +static inline struct sii9234 *bridge_to_sii9234(struct drm_bridge
>>> *bridge)
>>> +{
>>> +   return container_of(bridge, struct sii9234, bridge);
>>> +}
>>> +
>>> +static enum drm_mode_status sii9234_mode_valid(struct drm_bridge
>>> *bridge,
>>> +   const struct drm_display_mode
>>> *mode)
>>> +{
>>> +   if (mode->clock > MHL1_MAX_CLK)
>>> +   return MODE_CLOCK_HIGH;
>>> +
>>> +   return MODE_OK;
>>> +}
>>> +
>>> +static const struct drm_bridge_funcs sii9234_bridge_funcs = {
>>> +   .mode_valid = sii9234_mode_valid,
>>> +};
>>> +
>>> +static int sii9234_probe(struct i2c_client *client,
>>> + const struct i2c_device_id
>>> *id)
>>> +{
>>> +   struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
>>> +   struct sii9234 *ctx;
>>> +   struct device *dev = >dev;
>>> +   int ret;
>>> +
>>> +   ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>>> +   if (!ctx)
>>> +   return -ENOMEM;
>>> +
>>> +   ctx->dev = dev;
>>> +   mutex_init(>lock);
>>> +
>>> +   if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA))
>>> {
>>> +   dev_err(dev, "I2C adapter lacks SMBUS feature\n");
>>> +   return -EIO;
>>> +   }
>>> +
>>> +   if (!client->irq) {
>>> +   dev_err(dev, "no irq provided\n");
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   irq_set_status_flags(client->irq, IRQ_NOAUTOEN);
>>> +   ret = devm_request_threaded_irq(dev, client->irq, NULL,
>>> +   sii9234_irq_thread,
>>> +   IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
>>> +   "sii9234", ctx);
>>> +   if (ret < 0) {
>>> +   dev_err(dev, "failed to install IRQ handler\n");
>>> +   return ret;
>>> +   }
>>
>> You are setting up interrupts before initialization of I2C. Can the
>> interrupt happen in this short window?
>
>
> It can't happen, because in the previous line there is a status flag set to
> IRQ_NOAUTOEN. IRQs are enabled in sii9234_cable_in() function which is
> called after initialization of I2C.

Ah, okay, I missed that. Thanks!

Best regards,
Krzysztof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 1/2] drm/bridge: add Silicon Image SiI9234 driver

2017-09-12 Thread Krzysztof Kozlowski
On Mon, Sep 11, 2017 at 3:39 PM, Marek Szyprowski
 wrote:
> Hi Krzysztof,
>
>
> On 2017-09-11 15:18, Krzysztof Kozlowski wrote:
>>
>> On Mon, Sep 11, 2017 at 1:42 PM, Maciej Purski 
>> wrote:
>
> +   ctx->client[I2C_MHL] = client;
> +
> +   ctx->client[I2C_TPI] = i2c_new_dummy(adapter, I2C_TPI_ADDR);
> +   if (!ctx->client[I2C_TPI]) {
> +   dev_err(ctx->dev, "failed to create TPI client\n");
> +   return -ENODEV;
> +   }
> +
> +   ctx->client[I2C_HDMI] = i2c_new_dummy(adapter, I2C_HDMI_ADDR);
> +   if (!ctx->client[I2C_HDMI]) {
> +   dev_err(ctx->dev, "failed to create HDMI RX client\n");
> +   goto fail_tpi;
> +   }
> +
> +   ctx->client[I2C_CBUS] = i2c_new_dummy(adapter, I2C_CBUS_ADDR);
> +   if (!ctx->client[I2C_CBUS]) {
> +   dev_err(ctx->dev, "failed to create CBUS client\n");
> +   goto fail_hdmi;
> +   }

 You are using i2c_smbus_* calls. Why not converting to regmap_i2c? It is
 preferred interface.
>>>
>>>
>>> According to my search, there are only 5 drivers, which use regmap_i2c
>>> and
>>> none of them in drm. If you think that it is really needed, could you
>>> please
>>> explain
>>> why?
>>
>> There are slightly more than five drivers:
>>
>> $ git grep regmap_init_i2c | wc -l
>> 352
>>
>> ... and even more using regmap interface in generic (not i2c).
>>
>> I think this is really wanted because for free you get:
>> 1. locking,
>> 2. proper locking - with lockdep and nested mutexes :),
>> 3. caching of accesses,
>> 4. handling of endianness,
>> 5. optionally a trivial way of handling interrupts (regmap_irq_chip),
>>
>> Also this brings unified interface for most of the drivers regardless
>> of protocol used beneath (I2C, SPI and even MMIO but for simple cases
>> MMIO might not have much sense). This last argument actually brings
>> the most benefit for me because it abstracts driver from trivial I2C
>> implementation and it could allow even easy code-reuse for e.g. SPI
>> version.
>
>
> Regmap make sense for multi-function chips, which require more than one
> client driver (so proper locking is important). It also makes sense if
> the chip is produced in more than one flavor (like i2c, spi, MMIO, etc).
>
> None of the above takes place in this case... So in case of this driver
> using regmap is IMHO an over-engineering.

Good points and true that setting up regmap requires some more code
around probe. However it will remove half or even more of your
interrupt handler. Less driver specific code, more generic code used.
Also current code around I2C (sii9234_writeb() etc) is not thread
safe... which for now is not a problem as the only entrance point is
the interrupt. Maybe it's fine then to use existing implementation
especially if you do not see any future enhancements to the driver.

Best regards,
Krzysztof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 1/2] drm/bridge: add Silicon Image SiI9234 driver

2017-09-11 Thread Marek Szyprowski

Hi Krzysztof,

On 2017-09-11 15:18, Krzysztof Kozlowski wrote:

On Mon, Sep 11, 2017 at 1:42 PM, Maciej Purski  wrote:

+   ctx->client[I2C_MHL] = client;
+
+   ctx->client[I2C_TPI] = i2c_new_dummy(adapter, I2C_TPI_ADDR);
+   if (!ctx->client[I2C_TPI]) {
+   dev_err(ctx->dev, "failed to create TPI client\n");
+   return -ENODEV;
+   }
+
+   ctx->client[I2C_HDMI] = i2c_new_dummy(adapter, I2C_HDMI_ADDR);
+   if (!ctx->client[I2C_HDMI]) {
+   dev_err(ctx->dev, "failed to create HDMI RX client\n");
+   goto fail_tpi;
+   }
+
+   ctx->client[I2C_CBUS] = i2c_new_dummy(adapter, I2C_CBUS_ADDR);
+   if (!ctx->client[I2C_CBUS]) {
+   dev_err(ctx->dev, "failed to create CBUS client\n");
+   goto fail_hdmi;
+   }

You are using i2c_smbus_* calls. Why not converting to regmap_i2c? It is
preferred interface.


According to my search, there are only 5 drivers, which use regmap_i2c and
none of them in drm. If you think that it is really needed, could you please
explain
why?

There are slightly more than five drivers:

$ git grep regmap_init_i2c | wc -l
352

... and even more using regmap interface in generic (not i2c).

I think this is really wanted because for free you get:
1. locking,
2. proper locking - with lockdep and nested mutexes :),
3. caching of accesses,
4. handling of endianness,
5. optionally a trivial way of handling interrupts (regmap_irq_chip),

Also this brings unified interface for most of the drivers regardless
of protocol used beneath (I2C, SPI and even MMIO but for simple cases
MMIO might not have much sense). This last argument actually brings
the most benefit for me because it abstracts driver from trivial I2C
implementation and it could allow even easy code-reuse for e.g. SPI
version.


Regmap make sense for multi-function chips, which require more than one
client driver (so proper locking is important). It also makes sense if
the chip is produced in more than one flavor (like i2c, spi, MMIO, etc).

None of the above takes place in this case... So in case of this driver
using regmap is IMHO an over-engineering.

> ...

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 1/2] drm/bridge: add Silicon Image SiI9234 driver

2017-09-11 Thread Maciej Purski

Hi Krzysztof,
thank you for your comments.

On 08.09.2017 at 19:05, Krzysztof Kozlowski wrote:


On Tue, Sep 05, 2017 at 04:01:38PM +0200, Maciej Purski wrote:

SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interface to perform this operation.

This patch is based on the code refactored by Tomasz Stanislawski
, which was initially developed by:
Adam Hampson 
Erik Gilling 
Shankar Bandal 
Dharam Kumar 

Signed-off-by: Maciej Purski 
---
  .../devicetree/bindings/display/bridge/sii9234.txt |  34 +
  drivers/gpu/drm/bridge/Kconfig |   8 +
  drivers/gpu/drm/bridge/Makefile|   1 +
  drivers/gpu/drm/bridge/sii9234.c   | 993 +
  4 files changed, 1036 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/bridge/sii9234.txt
  create mode 100644 drivers/gpu/drm/bridge/sii9234.c

diff --git a/Documentation/devicetree/bindings/display/bridge/sii9234.txt 
b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
new file mode 100644
index 000..3ce7413
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
@@ -0,0 +1,34 @@
+Silicon Image SiI9234 HDMI/MHL bridge bindings
+
+Required properties:
+   - compatible : "sil,sii9234".
+   - reg : I2C address for TPI interface, use 0x39
+   - avcc33-supply : MHL/USB Switch Supply Voltage (3.3V)
+   - iovcc18-supply : I/O Supply Voltage (1.8V)
+   - avcc12-supply : TMDS Analog Supply Voltage (1.2V)
+   - cvcc12-supply : Digital Core Supply Voltage (1.2V)
+   - interrupts, interrupt-parent: interrupt specifier of INT pin
+   - reset-gpios: gpio specifier of RESET pin (active low)
+   - video interfaces: Device node can contain video interface port
+   node for HDMI encoder according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   sii9234@39 {
+   compatible = "sil,sii9234";
+   reg = <0x39>;
+   avcc33-supply = <>;
+   iovcc18-supply = <>;
+   avcc12-supply = <>;
+   cvcc12-supply = <>;
+   reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <>;
+   interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+
+   port {
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index adf9ae0..9dba16fd 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -84,6 +84,14 @@ config DRM_SII902X
---help---
  Silicon Image sii902x bridge chip driver.
  
+config DRM_SII9234

+   tristate "Silicon Image SII9234 HDMI/MHL bridge"
+   depends on OF
+   ---help---
+ Say Y here if you want support for the MHL interface.
+ It is an I2C driver, that detects connection of MHL bridge
+ and starts encapsulation of HDMI signal.
+
  config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index defcf1e..e3d5eb0 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
  obj-$(CONFIG_DRM_SII902X) += sii902x.o
+obj-$(CONFIG_DRM_SII9234) += sii9234.o
  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c
new file mode 100644
index 000..b70d69a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sii9234.c
@@ -0,0 +1,993 @@
+/*
+ * Copyright (C) 2017 Samsung Electronics
+ *
+ * Authors:
+ *Tomasz Stanislawski 
+ *Maciej Purski 
+ *
+ * Based on sii9234 driver created by:
+ *Adam Hampson 
+ *Erik Gilling 
+ *Shankar Bandal 
+ *Dharam Kumar 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ 

Re: [PATCH v3 1/2] drm/bridge: add Silicon Image SiI9234 driver

2017-09-09 Thread Krzysztof Kozlowski
On Tue, Sep 05, 2017 at 04:01:38PM +0200, Maciej Purski wrote:
> SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
> It is controlled via I2C bus. Its interaction with other
> devices in video pipeline is performed mainly on HW level.
> The only interaction it does on device driver level is
> filtering-out unsupported video modes, it exposes drm_bridge
> interface to perform this operation.
> 
> This patch is based on the code refactored by Tomasz Stanislawski
> , which was initially developed by:
> Adam Hampson 
> Erik Gilling 
> Shankar Bandal 
> Dharam Kumar 
> 
> Signed-off-by: Maciej Purski 
> ---
>  .../devicetree/bindings/display/bridge/sii9234.txt |  34 +
>  drivers/gpu/drm/bridge/Kconfig |   8 +
>  drivers/gpu/drm/bridge/Makefile|   1 +
>  drivers/gpu/drm/bridge/sii9234.c   | 993 
> +
>  4 files changed, 1036 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/sii9234.txt
>  create mode 100644 drivers/gpu/drm/bridge/sii9234.c
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/sii9234.txt 
> b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
> new file mode 100644
> index 000..3ce7413
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
> @@ -0,0 +1,34 @@
> +Silicon Image SiI9234 HDMI/MHL bridge bindings
> +
> +Required properties:
> + - compatible : "sil,sii9234".
> + - reg : I2C address for TPI interface, use 0x39
> + - avcc33-supply : MHL/USB Switch Supply Voltage (3.3V)
> + - iovcc18-supply : I/O Supply Voltage (1.8V)
> + - avcc12-supply : TMDS Analog Supply Voltage (1.2V)
> + - cvcc12-supply : Digital Core Supply Voltage (1.2V)
> + - interrupts, interrupt-parent: interrupt specifier of INT pin
> + - reset-gpios: gpio specifier of RESET pin (active low)
> + - video interfaces: Device node can contain video interface port
> + node for HDMI encoder according to [1].
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> + sii9234@39 {
> + compatible = "sil,sii9234";
> + reg = <0x39>;
> + avcc33-supply = <>;
> + iovcc18-supply = <>;
> + avcc12-supply = <>;
> + cvcc12-supply = <>;
> + reset-gpios = < 4 GPIO_ACTIVE_LOW>;
> + interrupt-parent = <>;
> + interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
> +
> + port {
> + mhl_to_hdmi: endpoint {
> + remote-endpoint = <_to_mhl>;
> + };
> + };
> + };
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index adf9ae0..9dba16fd 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -84,6 +84,14 @@ config DRM_SII902X
>   ---help---
> Silicon Image sii902x bridge chip driver.
>  
> +config DRM_SII9234
> + tristate "Silicon Image SII9234 HDMI/MHL bridge"
> + depends on OF
> + ---help---
> +   Say Y here if you want support for the MHL interface.
> +   It is an I2C driver, that detects connection of MHL bridge
> +   and starts encapsulation of HDMI signal.
> +
>  config DRM_TOSHIBA_TC358767
>   tristate "Toshiba TC358767 eDP bridge"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index defcf1e..e3d5eb0 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
> +obj-$(CONFIG_DRM_SII9234) += sii9234.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> diff --git a/drivers/gpu/drm/bridge/sii9234.c 
> b/drivers/gpu/drm/bridge/sii9234.c
> new file mode 100644
> index 000..b70d69a
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/sii9234.c
> @@ -0,0 +1,993 @@
> +/*
> + * Copyright (C) 2017 Samsung Electronics
> + *
> + * Authors:
> + *Tomasz Stanislawski 
> + *Maciej Purski 
> + *
> + * Based on sii9234 driver created by:
> + *Adam Hampson 
> + *Erik Gilling 
> + *Shankar Bandal 
> + *Dharam Kumar 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the 

[PATCH v3 1/2] drm/bridge: add Silicon Image SiI9234 driver

2017-09-05 Thread Maciej Purski
SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
It is controlled via I2C bus. Its interaction with other
devices in video pipeline is performed mainly on HW level.
The only interaction it does on device driver level is
filtering-out unsupported video modes, it exposes drm_bridge
interface to perform this operation.

This patch is based on the code refactored by Tomasz Stanislawski
, which was initially developed by:
Adam Hampson 
Erik Gilling 
Shankar Bandal 
Dharam Kumar 

Signed-off-by: Maciej Purski 
---
 .../devicetree/bindings/display/bridge/sii9234.txt |  34 +
 drivers/gpu/drm/bridge/Kconfig |   8 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/sii9234.c   | 993 +
 4 files changed, 1036 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/sii9234.txt
 create mode 100644 drivers/gpu/drm/bridge/sii9234.c

diff --git a/Documentation/devicetree/bindings/display/bridge/sii9234.txt 
b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
new file mode 100644
index 000..3ce7413
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
@@ -0,0 +1,34 @@
+Silicon Image SiI9234 HDMI/MHL bridge bindings
+
+Required properties:
+   - compatible : "sil,sii9234".
+   - reg : I2C address for TPI interface, use 0x39
+   - avcc33-supply : MHL/USB Switch Supply Voltage (3.3V)
+   - iovcc18-supply : I/O Supply Voltage (1.8V)
+   - avcc12-supply : TMDS Analog Supply Voltage (1.2V)
+   - cvcc12-supply : Digital Core Supply Voltage (1.2V)
+   - interrupts, interrupt-parent: interrupt specifier of INT pin
+   - reset-gpios: gpio specifier of RESET pin (active low)
+   - video interfaces: Device node can contain video interface port
+   node for HDMI encoder according to [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   sii9234@39 {
+   compatible = "sil,sii9234";
+   reg = <0x39>;
+   avcc33-supply = <>;
+   iovcc18-supply = <>;
+   avcc12-supply = <>;
+   cvcc12-supply = <>;
+   reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <>;
+   interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+
+   port {
+   mhl_to_hdmi: endpoint {
+   remote-endpoint = <_to_mhl>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index adf9ae0..9dba16fd 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -84,6 +84,14 @@ config DRM_SII902X
---help---
  Silicon Image sii902x bridge chip driver.
 
+config DRM_SII9234
+   tristate "Silicon Image SII9234 HDMI/MHL bridge"
+   depends on OF
+   ---help---
+ Say Y here if you want support for the MHL interface.
+ It is an I2C driver, that detects connection of MHL bridge
+ and starts encapsulation of HDMI signal.
+
 config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index defcf1e..e3d5eb0 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
+obj-$(CONFIG_DRM_SII9234) += sii9234.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/sii9234.c b/drivers/gpu/drm/bridge/sii9234.c
new file mode 100644
index 000..b70d69a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/sii9234.c
@@ -0,0 +1,993 @@
+/*
+ * Copyright (C) 2017 Samsung Electronics
+ *
+ * Authors:
+ *Tomasz Stanislawski 
+ *Maciej Purski 
+ *
+ * Based on sii9234 driver created by:
+ *Adam Hampson 
+ *Erik Gilling 
+ *Shankar Bandal 
+ *Dharam Kumar 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A