From: Rob Herring <robh@kernel.org>
To: John Stultz <john.stultz@linaro.org>
Cc: lkml <linux-kernel@vger.kernel.org>,
Yu Chen <chenyu56@huawei.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Rutland <mark.rutland@arm.com>,
ShuFan Lee <shufan_lee@richtek.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Chunfeng Yun <chunfeng.yun@mediatek.com>,
Felipe Balbi <balbi@kernel.org>,
Hans de Goede <hdegoede@redhat.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Jun Li <lijun.kernel@gmail.com>,
Valentin Schneider <valentin.schneider@arm.com>,
Guillaume Gardet <Guillaume.Gardet@arm.com>,
Jack Pham <jackp@codeaurora.org>,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v7 7/8] dt-bindings: misc: Add bindings for HiSilicon usb hub and data role switch functionality on HiKey960
Date: Wed, 18 Dec 2019 10:37:38 -0600 [thread overview]
Message-ID: <20191218163738.GA12358@bogus> (raw)
In-Reply-To: <20191212014233.32799-8-john.stultz@linaro.org>
On Thu, Dec 12, 2019 at 01:42:32AM +0000, John Stultz wrote:
> From: Yu Chen <chenyu56@huawei.com>
>
> This patch adds binding documentation to support usb hub and usb
> data role switch of Hisilicon HiKey960 Board.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> CC: ShuFan Lee <shufan_lee@richtek.com>
> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: Chunfeng Yun <chunfeng.yun@mediatek.com>
> Cc: Yu Chen <chenyu56@huawei.com>
> Cc: Felipe Balbi <balbi@kernel.org>
> Cc: Hans de Goede <hdegoede@redhat.com>
> Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
> Cc: Jun Li <lijun.kernel@gmail.com>
> Cc: Valentin Schneider <valentin.schneider@arm.com>
> Cc: Guillaume Gardet <Guillaume.Gardet@arm.com>
> Cc: Jack Pham <jackp@codeaurora.org>
> Cc: linux-usb@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Yu Chen <chenyu56@huawei.com>
> Signed-off-by: John Stultz <john.stultz@linaro.org>
> ---
> v3: Reworked as usb-role-switch intermediary
>
> v7: Switched over to YAML dt binding description
> ---
> .../bindings/misc/hisilicon-hikey-usb.yaml | 85 +++++++++++++++++++
> 1 file changed, 85 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.yaml
>
> diff --git a/Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.yaml b/Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.yaml
> new file mode 100644
> index 000000000000..1fc3b198ef73
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.yaml
> @@ -0,0 +1,85 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2019 Linaro Ltd.
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/misc/hisilicon-hikey-usb.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: HiKey960 onboard USB GPIO Hub
> +
> +maintainers:
> + - John Stultz <john.stultz@linaro.org>
> +
> +description: |
> + Supports the onboard HiKey960 USB GPIO hub, which acts as a
> + role-switch intermediary to detect the state of the USB-C
> + port, to switch the hub into dual-role USB-C or host mode,
> + which enables the onboard USB-A host ports.
Honestly I'm torn between whatever works for you because this is pretty
"special" dev board design and it should more accurately match the
hardware design. I think we can do the later and it doesn't really need
anything new.
> +
> + Schematics about the hub can be found here:
> + https://github.com/96boards/documentation/raw/master/consumer/hikey/hikey960/hardware-docs/HiKey960_Schematics.pdf
> +
> +properties:
> + compatible:
> + items:
> + - const: hisilicon,gpio_hubv1
As a whole this is HiSilicon specific, but really it is not. It's really
just a hub, a mux, and connectors for which we have bindings for. I
think you need to model the actual hub in DT. We have 2 ways already to
describe hubs in DT: a I2C device or USB device.
AIUI, the board looks something like this:
ctrl -> mux --> hub -> type-a connector
+-> type-c connector
If the hub I2C is not used, then you could do something like this:
ctrl {
mux-controls = <&usb_gpio_mux>;
connector@0 {
// type C connector binding
};
hub@1 {
// USB device binding
};
};
Or if I2C is used and the hub is under the I2C controller:
ctrl {
port@0 {
mux-controls = <&usb_gpio_mux>;
endpoint@0 { // mux state 0
remote-endpoint = <&usb_c_connector_port>;
};
endpoint@1 { // mux state 1
remote-endpoint = <&usb_hub_port>;
};
};
The only new bindings you really need are adding 'mux-controls' to the
USB host controller and the hub binding (we already have a few).
If the USB2 and USB3 signals come from 2 different host controller
nodes, then I think it will need to look like the 2nd case regardless
of I2C. (It's strange that USB3 was not routed to Type-C connector. Can
you do USB2 on Type-C and USB3 on hub simultaneously? You need USB2 to
enumerate, right?)
> +
> + typec-vbus-gpios:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: phandle to the typec-vbus gpio
This should be modeled as a GPIO regulator, and belongs as part of a
connector node. See bindings/connector/usb-connector.txt.
> +
> + otg-switch-gpios:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: phandle to the otg-switch gpio
This would be the gpio-mux binding instead.
> +
> + hub-vdd33-en-gpios:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: phandle to the hub 3.3v power enablement gpio
This should be modeled as a GPIO regulator.
What about the reset line on the hub?
> +
> + usb-role-switch:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description: Support role switch.
This normally is a controller property. Role switch is foreign to the
hub, so doesn't really belong there for sure.
> +
> + port:
> + description: |
> + any connector to the data bus of this controller should be modelled
> + using the OF graph bindings specified, if the "usb-role-switch"
> + property is used. Note for this driver, two ports are supported,
> + the first being the endpoint that will be notified by this driver,
> + and the second being the endpoint that notifies this driver of a
> + role switch.
> +
> +
> +required:
> + - compatible
> + - typec-vbus-gpios
> + - otg-switch-gpios
> + - hub-vdd33-en-gpios
> + - usb-role-switch
> + - port
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + hisi_hikey_usb: hisi_hikey_usb {
> + compatible = "hisilicon,gpio_hubv1";
> + typec-vbus-gpios = <&gpio25 2 GPIO_ACTIVE_HIGH>;
> + otg-switch-gpios = <&gpio25 6 GPIO_ACTIVE_HIGH>;
> + hub-vdd33-en-gpios = <&gpio5 6 GPIO_ACTIVE_HIGH>;
> + usb-role-switch;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hikey_usb_ep0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&dwc3_role_switch>;
> + };
> + hikey_usb_ep1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&rt1711h_ep>;
> + };
> + };
> + };
> --
> 2.17.1
>
next prev parent reply other threads:[~2019-12-18 16:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-12 1:42 [PATCH v7 0/8] HiKey960 USB support John Stultz
2019-12-12 1:42 ` [PATCH v7 1/8] usb: dwc3: Registering a role switch in the DRD code John Stultz
2019-12-12 1:42 ` [PATCH v7 2/8] dt-bindings: usb: generic: Add role-switch-default-mode binding John Stultz
2019-12-12 1:42 ` [PATCH v7 3/8] usb: dwc3: Add support for " John Stultz
2019-12-12 1:42 ` [PATCH v7 4/8] dt-bindings: usb: dwc3: Allow clock list & resets to be more flexible John Stultz
2019-12-12 1:42 ` [PATCH v7 5/8] usb: dwc3: Rework clock initialization " John Stultz
2019-12-12 1:42 ` [PATCH v7 6/8] usb: dwc3: Rework resets " John Stultz
2019-12-12 1:42 ` [PATCH v7 7/8] dt-bindings: misc: Add bindings for HiSilicon usb hub and data role switch functionality on HiKey960 John Stultz
2019-12-18 16:37 ` Rob Herring [this message]
2019-12-18 17:21 ` John Stultz
2019-12-18 19:56 ` Rob Herring
2020-01-22 18:28 ` John Stultz
2019-12-12 1:42 ` [PATCH v7 8/8] misc: hisi_hikey_usb: Driver to support onboard USB gpio hub on Hikey960 John Stultz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191218163738.GA12358@bogus \
--to=robh@kernel.org \
--cc=Guillaume.Gardet@arm.com \
--cc=andy.shevchenko@gmail.com \
--cc=balbi@kernel.org \
--cc=chenyu56@huawei.com \
--cc=chunfeng.yun@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hdegoede@redhat.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=jackp@codeaurora.org \
--cc=john.stultz@linaro.org \
--cc=lijun.kernel@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=shufan_lee@richtek.com \
--cc=suzuki.poulose@arm.com \
--cc=valentin.schneider@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).