Re: [PATCH 1/3] dt-bindings: Add binding for IT6505.

[Heiko Stuebner <heiko@sntech.de>]

Hi Allen,

Am Mittwoch, 8. Mai 2019, 09:48:40 CEST schrieb allen:
> From: Allen Chen <allen.chen@ite.com.tw>
> 
> Add a DT binding documentation for IT6505.
> 
> Signed-off-by: Allen Chen <allen.chen@ite.com.tw>
> 
> ---
>  .../bindings/display/bridge/ite,it6505.txt         | 30 ++++++++++++++++++++++
>  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>  2 files changed, 31 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6505.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6505.txt b/Documentation/devicetree/bindings/display/bridge/ite,it6505.txt
> new file mode 100644
> index 0000000..c3506ac
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.txt
> @@ -0,0 +1,30 @@
> +iTE it6505 DP bridge bindings
> +
> +Required properties:
> +        - compatible: "ite,it6505"
> +        - reg: i2c address of the bridge
> +        - ovdd-supply: I/O voltage
> +        - pwr18-supply: Core voltage
> +        - interrupts: interrupt specifier of INT pin
> +        - reset-gpios: gpio specifier of RESET pin
> +
> +Example:
> +	it6505dptx: it6505dptx@5c {
> +                compatible = "ite,it6505";
> +                status = "okay";

binding examples should not contain a "status" property.
Also as this is a board-specific i2c device, you shouldn't need
a status property in the board dts as well, as the default is
"okay" anyway.


> +                interrupt-parent = <&pio>;
> +                interrupts = <152 IRQ_TYPE_EDGE_RISING 152 0>;
> +                reg = <0x5c>;
> +                pinctrl-names = "default";
> +                pinctrl-0 = <&it6505_pins>;
> +                ovdd-supply = <&mt6358_vsim1_reg>;
> +                pwr18-supply = <&it6505_pp18_reg>;
> +                reset-gpios = <&pio 179 1>;
> +                hpd-gpios = <&pio 9 0>;

This is missing from the property-list above.

> +                extcon = <&usbc_extcon>;

Not documented as well. Also this looks like it is the same functionality
as on rk3399-gru devices and circumvents the Type-C subsystem entirely
when handling the display-port alt-mode of the typec port.

At least on rk3399-gru the extcon from the chromeos-ec delivered the
status and allowed chaning settings of the hidden type-c controller
(fusb302 in that case). And while that works for ChromeOS devices this
makes it impossible for other devices to sanely use the chip as well.


The kernels type-c framework did develop a lot more in the meantime,
so this "hack" should probably not spread to more parts and instead should
use the type-c framework.

I pestered Guenter last year at ELCE about making cros-ec-pd a part of
the kernel's type-c subsystem, but I guess nobody had the time so far.

 

> +                port {
> +                        it6505_in: endpoint {
> +                                remote-endpoint = <&dpi_out>;

Ports usage also it not documented above. 


Heiko

> +                        };
> +                };
> +        };
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 2c3fc51..c088646 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -184,6 +184,7 @@ iom	Iomega Corporation
>  isee	ISEE 2007 S.L.
>  isil	Intersil
>  issi	Integrated Silicon Solutions Inc.
> +ite	iTE Tech. Inc.
>  itead	ITEAD Intelligent Systems Co.Ltd
>  iwave  iWave Systems Technologies Pvt. Ltd.
>  jdi	Japan Display Inc.
>