Hi Allen,
Am Mittwoch, 8. Mai 2019, 09:48:40 CEST schrieb allen:
> From: Allen Chen <allen.chen@xxxxxxxxxx>
>
> Add a DT binding documentation for IT6505.
>
> Signed-off-by: Allen Chen <allen.chen@xxxxxxxxxx>
>
> ---
> .../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.
>
