Hi Rob,
Thanks for review.
On 12/09/2015 04:47 AM, Rob Herring wrote:
> On Tue, Dec 08, 2015 at 02:49:05PM +0100, Andrzej Hajda wrote:
>> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
>> via I2C bus.
>>
>> Signed-off-by: Andrzej Hajda <a.hajda@xxxxxxxxxxx>
>> ---
>> .../bindings/video/bridge/sil-sii8620.txt | 34 ++++++++++++++++++++++
>> 1 file changed, 34 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
>>
>> diff --git a/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
>> new file mode 100644
>> index 0000000..29f3f35
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
>> @@ -0,0 +1,34 @@
>> +Silicon Image SiI8620 bridge bindings
> Bridging what to what?
HDMI/MHL, I will add it in next iteration.
>
>> +
>> +Required properties:
>> + - compatible: "sil,sii8620"
>> + - reg: i2c address of the bridge
>> + - cvcc10-supply: Digital Core Supply Voltage (1.0V)
>> + - iovcc18-supply: I/O Supply Voltage (1.8V)
>> + - int-gpios: gpio specifier of INT pin
> Assuming INT means interrupt, this should use interrupts property.
OK.
>
>> + - reset-gpios: gpio specifier of RESET pin
>> + - clocks, clock-names: specification and name of "xtal" clock
>> + - 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:
>> + sii8620@39 {
>> + reg = <0x39>;
>> + compatible = "sil,sii8620";
>> + cvcc10-supply = <&ldo36_reg>;
>> + iovcc18-supply = <&ldo34_reg>;
>> + int-gpio = <&gpf0 2 0>;
>> + reset-gpio = <&gpv7 0 0>;
>> + clocks = <&pmu_system_controller 0>;
>> + clock-names = "xtal";
>> + assigned-clocks = <&pmu_system_controller 0>;
>> + assigned-clock-parents = <&xxti>;
> These aren't listed in the doc.
I will remove them.
>
>> +
>> + port {
>> + mhl_to_hdmi: endpoint {
>> + remote-endpoint = <&hdmi_to_mhl>;
>> + };
>> + };
> I'd like to see this have a port to a connector node, too. Possibly
> that can come later.
MHL standard is connector agnostic, usually MHL wires are routed
via multi-function microUSB connector, which can serve also for
USB/charging/UART....
There is additional logic to determine which cable is currently
connected, usually
implemented by extcon driver.
I am not sure if/how it should be represented in DT. What do you think
about it?
Regards
Andrzej
>
> Rob
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
