[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f6e948cb-7d3f-72b6-b153-58afb1304c49@linaro.org>
Date: Thu, 19 Mar 2020 18:03:58 +0000
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Stephen Boyd <swboyd@...omium.org>, balbi@...nel.org,
gregkh@...uxfoundation.org, linux-usb@...r.kernel.org
Cc: linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
bjorn.andersson@...aro.org, jackp@...eaurora.org, robh@...nel.org,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>, devicetree@...r.kernel.org
Subject: Re: [PATCH 2/7] dt-bindings: usb: dwc3: Add a gpio-usb-connector
example
On 19/03/2020 16:40, Stephen Boyd wrote:
> Quoting Bryan O'Donoghue (2020-03-19 08:22:14)
>> On 19/03/2020 01:08, Stephen Boyd wrote:
>>>
>>> Maybe it should be a virtual node at the root of the DT if it's GPIO
>>> controlled? And then the phy can be connected to the usb connector
>>> through the graph binding.
>>
>> Graph binding can probably work.
>>
>> Re: the PHY.
>>
>> For myself the hardware model is
>>
>> Connector -> PHY -> Host controller -> Host controller wrapper
>>
>> Only
>>
>> Connector -> Host controller -> Host controller wrapper
>>
>> care about the USB role though.
>>
>> If your PHY did care about the role, you'd really need to write a
>> connector/phy type-c type driver, to detect the state and toggle your
>> PHY bits before doing usb_role_switch_set_role() back to DWC3.
>>
>
> Yes some PHYs do care about the role. Sometimes they have to toggle some
> bit to switch between host and gadget mode for example. I haven't fully
> read this patch series but maybe the PHY can be the one that controls
> the gpio for the connector?
Previous version of the PHY from 2019 had extcon toggling vbus.
Since extcon is going away, we moved go usb-gpio
https://lwn.net/ml/devicetree/20190905175802.GA19599@jackp-linux.qualcomm.com/
https://lwn.net/ml/devicetree/5d71edf5.1c69fb81.1f307.fdd6@mx.google.com/
usb-gpio-conn handle VBUS and notifies via the USB role switch API.
Which if the connector is a child of the controller "just works" but,
maybe with a little bit of work DT <port> references could do the same
thing and the connector wouldn't need to be declared as a child.
> We (ChromeOS) need to integrate the type-c connector class, etc. on
> sc7180 with the dwc3 driver and the current thinking has the type-c
> connectors underneath the cros_ec node because the EC is the type-c
> manager. The EC will have a type-c driver associated with it.
right and you don't want, doesn't work or doesn't make sense, to declare
cros_ec as a child of DWC3, fair enough.
I guess a DT remote-endpoint{} will do the job.
Something like:
arch/arm64/boot/dts/freescale/imx8mn-evk.dtsi
---
bod
Powered by blists - more mailing lists