Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1487854 > unrolled thread

Re: [PATCH 1/2] dt: bindings: add allwinner,otg-routed property for phy-sun4i-usb

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/2] dt: bindings: add allwinner,otg-routed property for  phy-sun4i-usb Hans de Goede <hdegoede@redhat.com> - 2016-09-21 09:20 +0200
    Re: [PATCH 1/2] dt: bindings: add allwinner,otg-routed property for  phy-sun4i-usb Hans de Goede <hdegoede@redhat.com> - 2016-09-21 09:40 +0200

#1487854 — Re: [PATCH 1/2] dt: bindings: add allwinner,otg-routed property for phy-sun4i-usb

Hi,

On 09/21/2016 10:04 AM, Icenowy Zheng wrote:
> On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
> the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
> (which is a Host-only controller, but more stable and easy to implement).
>
> This property marks whether on a certain board which controller should be
> attached to the PHY.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>

Erm, I think that the idea here is to dynamically switch the routing
based on the id-pin of the otg connector. IOW use the musb controller
for device mode, and the ehci/ohci proper for proper host support
when in host mode.

Regards,

Hans



> ---
>  Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> index 287150d..5c11d57 100644
> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -36,6 +36,13 @@ Optional properties:
>  - usb1_vbus-supply : regulator phandle for controller usb1 vbus
>  - usb2_vbus-supply : regulator phandle for controller usb2 vbus
>
> +Optional properties for H3 or A64 SoCs:
> +- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
> +			 MUSB. (boolean, if this property is set, the OHCI/EHCI
> +			 controllers at PHY0 should be enabled and the MUSB
> +			 controller must *NOT* be enabled, and thus the PHY can
> +			 only work in host mode)
> +
>  Example:
>  	usbphy: phy@0x01c13400 {
>  		#phy-cells = <1>;
>

[toc] | [next] | [standalone]

#1487868

Hi,

On 09/21/2016 10:19 AM, Icenowy Zheng wrote:
>
>
> 21.09.2016, 15:10, "Hans de Goede" <hdegoede@redhat.com>:
>> Hi,
>>
>> On 09/21/2016 10:04 AM, Icenowy Zheng wrote:
>>>  On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
>>>  the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
>>>  (which is a Host-only controller, but more stable and easy to implement).
>>>
>>>  This property marks whether on a certain board which controller should be
>>>  attached to the PHY.
>>>
>>>  Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>>
>> Erm, I think that the idea here is to dynamically switch the routing
>> based on the id-pin of the otg connector. IOW use the musb controller
>> for device mode, and the ehci/ohci proper for proper host support
>> when in host mode.
>
> At least on some boards this implementation works...
>
> (I mean Pine64, which has two USB-A connectors)

Right and I think it is great that you're working on this.

But even with an A connector on the board, we can still use the device
mode (e.g. the SoC's native FEL mode will be used this way).

Notice that you can fake id-pin changes by echoing a mode to:

/sys/devices/platform/soc@01c00000/1c13000.usb/musb-hdrc.1.auto/mode

Valid values to echo are: host, peripheral and otg.

If you combine this with using either an USB A<->A cable, or using
the port normally as a host you should be able to develop and test
full otg support.

Eventually we will need a full otg support rather then your current solution
and I'm afraid that your solution may get in the way of full otg support.

Regards,

Hans

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web