Re: Dual-role behavior with USB-C?

[Peter Chen]

On Wed, Dec 13, 2017 at 02:37:14PM +0200, Heikki Krogerus wrote:
> Hi guys,
> 
> > > I think the USB-OTG PHY is part of i.MX6UL SoC?
> > 
> > Yes, but it is just USB PHY, not PD PHY. You need external pure CC-logic
> > chip (like PTN5150), or Type-C PD chip (like PTN5110) to support CC
> > or PD event.
> 
> Oh cool, PTP5150 seems to function autonomously if needed! So it would
> have worked even without driver support initially.
> 

Yes, if you configure PTN5150 as DRP, the ID pin for SoC will change
accordingly.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dual-role behavior with USB-C?

[Takashi Matsuzawa]

Hello.
Now I am waiting for my USB-C breakout board to just re-using it for connecting 
to conventional micr-A/B receptacle.

BTW, Looking into schematic, another board HiKey960 with USB-C receptacle seems 
to have USB-C controller in its circuit.

>OK, from those schematics we can clearly see that the CC lines are
>really connected to the USB_OTG_ID signal. I guess the idea has been
>to attempt to get the USB_OTG_ID signal pulled down to ground when the
>partner is UFP (device) and has the CC line connected to the ground
>with the resistor Rd. That should put the board into host mode, but
>I guess it's not working.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dual-role behavior with USB-C?

[Heikki Krogerus]

Hi guys,

On Wed, Dec 13, 2017 at 10:43:50AM +0800, Peter Chen wrote:
> On Wed, Dec 13, 2017 at 01:17:23AM +, Takashi Matsuzawa wrote:
> > Hello.
> > 
> > >If you have a Type-C connector on your board, then you also should
> > >have a USB Type-C PHY that takes care of CC logic. The host-to-device
> > >relationship is determined using the Configuration Channel (CC) that
> > >goes through the USB Type-C cable. Note that CC is not the same as ID!
> > 
> > I am playing with i.MX6 pico board, which has USB-OTG receptacle with USB-C 
> > physical shape. 
> > http://download.wandboard.org/hobbitboard-imx6ul/documentation/pico-imx6ul-emmc-hobbit-reva1-hardware-manual-20160328.pdf

OK, from those schematics we can clearly see that the CC lines are
really connected to the USB_OTG_ID signal. I guess the idea has been
to attempt to get the USB_OTG_ID signal pulled down to ground when the
partner is UFP (device) and has the CC line connected to the ground
with the resistor Rd. That should put the board into host mode, but
I guess it's not working.

With Type-C to Type-C connections, in case the partner is DFP (host)
or DRP (dual-role), that configuration will just confuse the partner.
The partner will now see that the CC is pulled high and probable think
that your board is also DFP (host), i.e. your board and the partner
connected to it, both think they need to be in device mode.

I don't think there are actually any guarantees that connecting the CC
lines to the ID input on the board will work in any scenario. There
really should be a CC-logic chip if dual-role support was needed. For
device mode only, simply connecting the CC lines to the ground from
the connector would have been enough.

> > I think the USB-OTG PHY is part of i.MX6UL SoC?
> 
> Yes, but it is just USB PHY, not PD PHY. You need external pure CC-logic
> chip (like PTN5150), or Type-C PD chip (like PTN5110) to support CC
> or PD event.

Oh cool, PTP5150 seems to function autonomously if needed! So it would
have worked even without driver support initially.


Cheers,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dual-role behavior with USB-C?

[Peter Chen]

On Wed, Dec 13, 2017 at 01:17:23AM +, Takashi Matsuzawa wrote:
> Hello.
> 
> >If you have a Type-C connector on your board, then you also should
> >have a USB Type-C PHY that takes care of CC logic. The host-to-device
> >relationship is determined using the Configuration Channel (CC) that
> >goes through the USB Type-C cable. Note that CC is not the same as ID!
> 
> I am playing with i.MX6 pico board, which has USB-OTG receptacle with USB-C 
> physical shape. 
> http://download.wandboard.org/hobbitboard-imx6ul/documentation/pico-imx6ul-emmc-hobbit-reva1-hardware-manual-20160328.pdf
> 
> I think the USB-OTG PHY is part of i.MX6UL SoC?

Yes, but it is just USB PHY, not PD PHY. You need external pure CC-logic
chip (like PTN5150), or Type-C PD chip (like PTN5110) to support CC
or PD event.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dual-role behavior with USB-C?

[Peter Chen]

On Tue, Dec 12, 2017 at 07:01:34AM +, Takashi Matsuzawa wrote:
> Hello.
> Thank you very much for your comment.
> 
> > Since USB OTG FSM has not been accepted by industry during last ten years, 
> > we decide
> > to give up maintaining OTG FSM at Linux kernel. For role switch use case, 
> > please use
> >  /sys/../role instead, see below commit for detail:
> > 
> >  
> > https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/commit/drivers/usb/chipidea/core.c?h=ci-for-usb-
>  next=a932a8041ff9941a244619555f1c75ecf299f662
> 
> I am still learning so just point me to existing memo  / notes which I should 
> look into, before go furher.
> 
> 1) HNP aware devices
> 
> That means it does not work (or will not work) with HNP-aware device anymore, 
> or I can expect that it still works when I enable CONFIG_USB_OTG and 
> CONFIG_USB_OTG_FSM?

Afaik, there is no fully HNP aware device, if you know any, please tell me.

> 
> 2) role I/F.
> 
> As for the role I/F.
> I tried like below and confirmed that the role value changes gadget <-> host. 
>  And new bus is added can see on lsusb output, when I change the role from 
> gadget to host.
> 
> echo host > /sys/bus/platform/devices/ci_hdrc.0/role
> 
> However, I am still confused since it does not more.
> Say, I have two boards A and B connected with C-C cable.
> And by command like above, I set A host role and B gadget role, and also load 
> mass storage driver on B.
> 
> I expect to see on B is enumerated as mass storage device attached to the 
> newly added bus on A, but I cannot see it on lsusb output.
> Not sure I am missing / skipping steps.

Maybe vbus is not there or the gadget does not pull DP up correctly.

> 
> 3) USB-C lines
> 
> As for USB-C receptacle on my board, I can see the following.  In my case I 
> am just trying to use it in place of old one (micro-A/B receptacle), but I 
> wonder if I further need kernel configuration specific to TYPEC.
> 

For your hardware, I don't think you need.

> board    cable
>     
> USB_OTG_DP - Dp1/Dp2
> USB_OTG_DN - Dn1/Dn2
> USB_OTG_ID - CC1/CC2
> 

You said the role has switched successfully, it is not related Type-C
issue, it is the controller driver issue, please focus on if vbus
is there and if the gadget pull DP up.

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dual-role behavior with USB-C?

[Takashi Matsuzawa]

Hello.

>If you have a Type-C connector on your board, then you also should
>have a USB Type-C PHY that takes care of CC logic. The host-to-device
>relationship is determined using the Configuration Channel (CC) that
>goes through the USB Type-C cable. Note that CC is not the same as ID!

I am playing with i.MX6 pico board, which has USB-OTG receptacle with USB-C 
physical shape. 
http://download.wandboard.org/hobbitboard-imx6ul/documentation/pico-imx6ul-emmc-hobbit-reva1-hardware-manual-20160328.pdf

I think the USB-OTG PHY is part of i.MX6UL SoC?
I am also trying different cable configurations (e.g. C-A(f)+A(m)-C) to see if 
behavior changes.

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dual-role behavior with USB-C?

[Heikki Krogerus]

Hi Takashi,

On Tue, Dec 12, 2017 at 07:01:34AM +, Takashi Matsuzawa wrote:
> Hello.
> Thank you very much for your comment.
> 
> > Since USB OTG FSM has not been accepted by industry during last ten years, 
> > we decide
> > to give up maintaining OTG FSM at Linux kernel. For role switch use case, 
> > please use
> >  /sys/../role instead, see below commit for detail:
> > 
> >  
> > https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/commit/drivers/usb/chipidea/core.c?h=ci-for-usb-
>  next=a932a8041ff9941a244619555f1c75ecf299f662
> 
> I am still learning so just point me to existing memo? / notes which I should
> look into, before go furher.
> 
> 1) HNP aware devices
> 
> That means it does not work (or will not work) with HNP-aware device anymore,
> or I can expect that it still works when I enable CONFIG_USB_OTG and
> CONFIG_USB_OTG_FSM?
> 
> 2) role I/F.
> 
> As for the role I/F.
> I tried like below and confirmed that the role value changes gadget <-> host.?
> And new bus is added can see on lsusb output, when I change the role from
> gadget to host.
> 
> echo host > /sys/bus/platform/devices/ci_hdrc.0/role
> 
> However, I am still confused since it does not more.
> Say, I have two boards A and B connected with C-C cable.
> And by command like above, I set A host role and B gadget role, and also load
> mass storage driver on B.
> 
> I expect to see on B is enumerated as mass storage device attached to the
> newly added bus on A, but I cannot see it on lsusb output.
> Not sure I am missing / skipping steps.
> 
> 3) USB-C lines
> 
> As for USB-C receptacle on my board, I can see the following.? In my case I am
> just trying to use it in place of old one (micro-A/B receptacle), but I wonder
> if I further need kernel configuration specific to TYPEC.
> 
> board? ? cable
> ? ? 
> USB_OTG_DP - Dp1/Dp2
> USB_OTG_DN - Dn1/Dn2
> USB_OTG_ID - CC1/CC2

If you have a Type-C connector on your board, then you also should
have a USB Type-C PHY that takes care of CC logic. The host-to-device
relationship is determined using the Configuration Channel (CC) that
goes through the USB Type-C cable. Note that CC is not the same as ID!

USB Type-C and USB Power Delivery follow their own state machines
that are completely separate from OTG FSM. USB OTG is in practice not
compatible with USB Type-C, and we should not even talk about OTG with
USB Type-C. In mainline, the USB Type-C and USB Power Delivery state
machines are implemented in drivers/usb/typec/tcpm.c .

It is also possible to use stand-alone USB Type-C or USB Power
Delivery controllers that handle the state machines inside their
firmware, however I don't think you have those on your board, as I
would expect everything to just work without any software control
needed if you had.

But in any case, the Type-C PHY on your board will do at least two
basic things:
1) Determine the initial role: DFP (Host) or UFP (device).
2) Resolve the cable orientation: normal or upside-down.

After that, depending on the components you have on the board, you
will possible need to configure a mux that routes the correct data
pairs to the USB controller (depending on the orientation of the
cable), and then you need to configure the role of the controller
(there is no support for this in mainline for the Chipidea USB
controller). On top of those things, if you are acting as the host,
you will also have somekind of a regulator for the VBUS of course, but
also for the VCONN.

So it is likely that we are missing driver support for some of the
components on your board. Can you share some details about your the
board you are using?

After all the needed components are supported, then the initial
role will be determined automatically, and in case of the Type-C to
Type-C connections (where both partners are dual-role) you can also
use the USB Type-C Connector Class ABI to request role swapping:

% echo  > /sys/class/typec/port0/data_role


Cheers,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dual-role behavior with USB-C?

[Takashi Matsuzawa]

Hello.
Thank you very much for your comment.

> Since USB OTG FSM has not been accepted by industry during last ten years, we 
> decide
> to give up maintaining OTG FSM at Linux kernel. For role switch use case, 
> please use
>  /sys/../role instead, see below commit for detail:
> 
>  
> https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/commit/drivers/usb/chipidea/core.c?h=ci-for-usb-
 next=a932a8041ff9941a244619555f1c75ecf299f662

I am still learning so just point me to existing memo  / notes which I should 
look into, before go furher.

1) HNP aware devices

That means it does not work (or will not work) with HNP-aware device anymore, 
or I can expect that it still works when I enable CONFIG_USB_OTG and 
CONFIG_USB_OTG_FSM?

2) role I/F.

As for the role I/F.
I tried like below and confirmed that the role value changes gadget <-> host.  
And new bus is added can see on lsusb output, when I change the role from 
gadget to host.

echo host > /sys/bus/platform/devices/ci_hdrc.0/role

However, I am still confused since it does not more.
Say, I have two boards A and B connected with C-C cable.
And by command like above, I set A host role and B gadget role, and also load 
mass storage driver on B.

I expect to see on B is enumerated as mass storage device attached to the newly 
added bus on A, but I cannot see it on lsusb output.
Not sure I am missing / skipping steps.

3) USB-C lines

As for USB-C receptacle on my board, I can see the following.  In my case I am 
just trying to use it in place of old one (micro-A/B receptacle), but I wonder 
if I further need kernel configuration specific to TYPEC.

board    cable
    
USB_OTG_DP - Dp1/Dp2
USB_OTG_DN - Dn1/Dn2
USB_OTG_ID - CC1/CC2



Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Dual-role behavior with USB-C?

[Peter Chen]

 
> 
> Hello.
> 
> Just in case if you already have pointer or experience with this, any 
> suggestion is
> highly appreciated.
> 
> Some of the recent i.MX boards has USB-C socket for USB-OTG port, and I wonder
> how I can try the following steps (Dual-role behavior testing) with USB-C 
> sockets.
> 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kernel.
> org%2Fdoc%2FDocumentation%2Fusb%2Fchipidea.txt=02%7C01%7Cpeter.c
> hen%40nxp.com%7Cc2f36f5be257466d78b608d53e8e2d57%7C686ea1d3bc2b4c6f
> a92cd99c5c301635%7C0%7C0%7C636483702729739829=6slKCmxytnXl%
> 2BP4J73NlXm6CPtVSq3GGsXqSXO%2Bn5fY%3D=0
> 
> The steps involves micro-A and micro-B plugs, but for my board only USB-C plug
> can be inserted.
> (I tried C-C cable to connect two boards, but nothing happened - both of the 
> boards
> stayed in gadget role, neither becoming the host).
> 
> I have confirmed my board can act as host (can detect a device attached and 
> shown
> on lsusb output) or gadget (by loading mass storage driver, it can be shown as
> external disk from my PC).
> 
> (Well, however these behaviors are not stable yet with my local build image.)
> 
> Anyway:
> 
> - How can I conduct test steps outlined in chipidea.txt memo.

Since USB OTG FSM has not been accepted by industry during last ten years, we 
decide
to give up maintaining OTG FSM at Linux kernel. For role switch use case, 
please use
/sys/../role instead, see below commit for detail:

https://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/commit/drivers/usb/chipidea/core.c?h=ci-for-usb-next=a932a8041ff9941a244619555f1c75ecf299f662

Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dual-role behavior with USB-C?

[Takashi Matsuzawa]

Hello.

Just in case if you already have pointer or experience with this, any 
suggestion is highly appreciated.

Some of the recent i.MX boards has USB-C socket for USB-OTG port, and I wonder 
how I can try the following steps (Dual-role behavior testing) with USB-C 
sockets.

https://www.kernel.org/doc/Documentation/usb/chipidea.txt

The steps involves micro-A and micro-B plugs, but for my board only USB-C plug 
can be inserted.
(I tried C-C cable to connect two boards, but nothing happened - both of the 
boards stayed in gadget role, neither becoming the host).

I have confirmed my board can act as host (can detect a device attached and 
shown on lsusb output) or gadget (by loading mass storage driver, it can be 
shown as external disk from my PC).

(Well, however these behaviors are not stable yet with my local build image.)

Anyway:

- How can I conduct test steps outlined in chipidea.txt memo.
How can I interpret it with UCB-C ports (may be using appropriate cables) or is 
there alternative test steps?

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html