On Wed, Feb 6, 2019 at 8:11 AM Jorge Ramirez
<jorge.ramirez-ortiz@xxxxxxxxxx> wrote:
>
> On 2/5/19 12:02, Jorge Ramirez wrote:
> > On 1/30/19 21:02, Rob Herring wrote:
> >> On Tue, Jan 29, 2019 at 12:35:14PM +0100, Jorge Ramirez-Ortiz wrote:
> >>> Binding description for Qualcomm's Synopsys 1.0.0 super-speed PHY
> >>> controller embedded in QCS404.
> >>>
> >>> Based on Sriharsha Allenki's <sallenki@xxxxxxxxxxxxxx> original
> >>> definitions.
> >>>
> >>> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@xxxxxxxxxx>
> >>> ---
> >>> .../devicetree/bindings/usb/qcom,usb-ssphy.txt | 73 ++++++++++++++++++++++
> >>> 1 file changed, 73 insertions(+)
> >>> create mode 100644 Documentation/devicetree/bindings/usb/qcom,usb-ssphy.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/usb/qcom,usb-ssphy.txt b/Documentation/devicetree/bindings/usb/qcom,usb-ssphy.txt
> >>> new file mode 100644
> >>> index 0000000..8ef6e39
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/usb/qcom,usb-ssphy.txt
> >>> @@ -0,0 +1,73 @@
> >>> +Qualcomm Synopsys 1.0.0 SS phy controller
> >>> +===========================================
> >>> +
> >>> +Synopsys 1.0.0 ss phy controller supports SS usb connectivity on Qualcomm
> >>> +chipsets
> >>> +
> >>> +Required properties:
> >>> +
> >>> +- compatible:
> >>> + Value type: <string>
> >>> + Definition: Should contain "qcom,usb-ssphy".
> >>
> >> This is in no way specific enough.
> >
> > ok. will remove the old unused bindings and reuse qcom,dwc3-ss-usb-phy
> >
> >>
> >>> +
> >>> +- reg:
> >>> + Value type: <prop-encoded-array>
> >>> + Definition: USB PHY base address and length of the register map.
> >>> +
> >>> +- #phy-cells:
> >>> + Value type: <u32>
> >>> + Definition: Should be 0. See phy/phy-bindings.txt for details.
> >>> +
> >>> +- clocks:
> >>> + Value type: <prop-encoded-array>
> >>> + Definition: See clock-bindings.txt section "consumers". List of
> >>> + three clock specifiers for reference, phy core and
> >>> + pipe clocks.
> >>> +
> >>> +- clock-names:
> >>> + Value type: <string>
> >>> + Definition: Names of the clocks in 1-1 correspondence with the "clocks"
> >>> + property. Must contain "ref", "phy" and "pipe".
> >>> +
> >>> +- vdd-supply:
> >>> + Value type: <phandle>
> >>> + Definition: phandle to the regulator VDD supply node.
> >>> +
> >>> +- vdda1p8-supply:
> >>> + Value type: <phandle>
> >>> + Definition: phandle to the regulator 1.8V supply node.
> >>> +
> >>> +
> >>> +Optional child nodes:
> >>> +
> >>> +- vbus-supply:
> >>> + Value type: <phandle>
> >>> + Definition: phandle to the VBUS supply node.
> >>
> >> Does the phy actually get supplied by Vbus? If not, then Vbus supply
> >> should be defined in a USB connector node.
> >
> > yes per the documentation vbus can optionally be routed to the phy to
> > drive a signal to the controller.
>
>
> funny enough when vbus is optionally routed to the phy is not to be
> controlled like we do when the vbus-supply property is present.
>
> So to all effects no, you are right, the phy does not get supplied by VBUS.
>
> would defining the connector like this be enough?
>
> usb3_phy: usb3-phy@78000 {
> compatible = "qcom,snps-usb-ssphy";
> [...]
> usb3_c_connector: usb3-c-connector {
> compatible = "usb-c-connector";
> label = "USB-C";
> type = "micro";
> vbus-supply = <&usb3_vbus_reg>;
> };
> };
IIRC, the connector node is defined to go under either the USB
controller or a USB-C controller (if a separate chip controlling the
USB-PD and alternate modes). We generally don't put PHYs into a node
topology, but keep them as a phandle reference.
Rob
