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

Groups > linux.kernel > #1420564 > unrolled thread

[PATCH v11 08/14] usb: otg: add OTG/dual-role core

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

  [PATCH v11 08/14] usb: otg: add OTG/dual-role core Roger Quadros <rogerq@ti.com> - 2016-06-13 10:00 +0200
    Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-20 09:50 +0200
      Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Roger Quadros <rogerq@ti.com> - 2016-06-20 12:20 +0200
        Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Roger Quadros <rogerq@ti.com> - 2016-06-20 14:30 +0200
          Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-20 14:50 +0200
        Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-20 14:30 +0200
          Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Peter Chen <hzpeterchen@gmail.com> - 2016-06-21 08:50 +0200
            Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-21 09:30 +0200
              Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Peter Chen <hzpeterchen@gmail.com> - 2016-06-21 10:20 +0200
                Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-21 10:30 +0200
                  Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Peter Chen <hzpeterchen@gmail.com> - 2016-06-21 14:00 +0200
                    Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-21 14:40 +0200
                      Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Peter Chen <hzpeterchen@gmail.com> - 2016-06-21 15:30 +0200
                        Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-21 16:50 +0200
                          Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Peter Chen <hzpeterchen@gmail.com> - 2016-06-22 05:50 +0200
                            Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-22 09:00 +0200
                              Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Peter Chen <hzpeterchen@gmail.com> - 2016-06-22 09:40 +0200
                                Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-22 10:10 +0200
                            RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> - 2016-06-23 09:50 +0200
        RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> - 2016-06-21 04:40 +0200
          RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-21 09:30 +0200
      Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Peter Chen <hzpeterchen@gmail.com> - 2016-06-20 14:00 +0200
        Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-20 14:20 +0200
          Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Peter Chen <hzpeterchen@gmail.com> - 2016-06-21 08:40 +0200
            Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-21 09:30 +0200
              Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Peter Chen <hzpeterchen@gmail.com> - 2016-06-21 11:20 +0200
                Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-21 12:10 +0200
                  Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Tony Lindgren <tony@atomide.com> - 2016-06-21 13:00 +0200
                    Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-21 13:00 +0200
                  Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Peter Chen <hzpeterchen@gmail.com> - 2016-06-21 18:50 +0200
                    Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-22 09:00 +0200
                      Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Peter Chen <hzpeterchen@gmail.com> - 2016-06-22 10:00 +0200
                        Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-22 10:20 +0200
                      Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Roger Quadros <rogerq@ti.com> - 2016-06-22 10:00 +0200
                        Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Felipe Balbi <balbi@kernel.org> - 2016-06-22 10:20 +0200
                          Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Roger Quadros <rogerq@ti.com> - 2016-06-22 10:40 +0200
                        RE: [PATCH v11 08/14] usb: otg: add OTG/dual-role core Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> - 2016-06-23 09:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1427388

[Multipart message — attachments visible in raw view] — view raw

Hi,

Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> writes:
> Hi Roger,
>
>> From: Roger Quadros
>> Sent: Monday, June 20, 2016 7:13 PM
>> 
>> Hi,
>> 
>> On 20/06/16 10:45, Felipe Balbi wrote:
> < snip >
>> >> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> >> index f4fc0aa..1d74fb8 100644
>> >> --- a/include/linux/usb/gadget.h
>> >> +++ b/include/linux/usb/gadget.h
>> >> @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >>   * @in_epnum: last used in ep number
>> >>   * @mA: last set mA value
>> >>   * @otg_caps: OTG capabilities of this gadget.
>> >> + * @otg_dev: OTG controller device, if needs to be used with OTG core.
>> >
>> > do you really know of any platform which has a separate OTG controller?
>> >
>> 
>> Andrew had pointed out in [1] that Tegra210 has separate blocks for OTG, host
>> and gadget.
>> 
>> [1] http://article.gmane.org/gmane.linux.ports.tegra/22969
>> 
>> Yoshihiro,
>> 
>> How is the dual-role architecture on your Renesas platform?
>
> About the dual-role architecture, Renesas platform (R-Car H3) has a
> USB 2.0 host controller (EHCI/OHCI) with OTG function and a separate
> USB 2.0 peripheral controller (HS-USB).  The OTG function is related
> to some PHY control registers, so I intend to add the OTG/Dual-role
> core support into the phy driver (drivers/phy/phy-rcar-gen3-usb2.c).

that looks like a mux to me :-) thanks for the pointer

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1426523

On Mon, Jun 20, 2016 at 10:45:31AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros <rogerq@ti.com> writes:
> > It provides APIs for the following tasks
> >
> > - Registering an OTG/dual-role capable controller
> > - Registering Host and Gadget controllers to OTG core
> > - Providing inputs to and kicking the OTG state machine
> 
> I think I have already mentioned this, but after over 10 years of OTG,
> nobody seems to care about it, why are we still touching at all I don't
> know. For common non-OTG role-swapping we really don't need any of this
> and, quite frankly, I fail to see enough users for this.
> 
> Apparently there's only chipidea which, AFAICT, already had working
> dual-role before this OTG State Machine was added to the kernel.

Some users would like to know if vendor's platform is OTG compliance,
so we add it to pass usb.org USB OTG certification test.

For the real use case, some Carplay platforms need it.

> 
> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> > index f4fc0aa..1d74fb8 100644
> > --- a/include/linux/usb/gadget.h
> > +++ b/include/linux/usb/gadget.h
> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
> >   * @in_epnum: last used in ep number
> >   * @mA: last set mA value
> >   * @otg_caps: OTG capabilities of this gadget.
> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
> 
> do you really know of any platform which has a separate OTG controller?
> 

It may not be a real separate OTG controller. It can be a hardware part
(external connector, external IC, SoC OTG register area, etc) to handle vbus
,id and other signals which are used for role swap.

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1426533

[Multipart message — attachments visible in raw view] — view raw

Hi,

Peter Chen <hzpeterchen@gmail.com> writes:
>> Roger Quadros <rogerq@ti.com> writes:
>> > It provides APIs for the following tasks
>> >
>> > - Registering an OTG/dual-role capable controller
>> > - Registering Host and Gadget controllers to OTG core
>> > - Providing inputs to and kicking the OTG state machine
>> 
>> I think I have already mentioned this, but after over 10 years of OTG,
>> nobody seems to care about it, why are we still touching at all I don't
>> know. For common non-OTG role-swapping we really don't need any of this
>> and, quite frankly, I fail to see enough users for this.
>> 
>> Apparently there's only chipidea which, AFAICT, already had working
>> dual-role before this OTG State Machine was added to the kernel.
>
> Some users would like to know if vendor's platform is OTG compliance,
> so we add it to pass usb.org USB OTG certification test.

I strongly doubt that's really what they mean. IMHO, users want to know
if they can swap roles. Ask them if they are really going for OTG
certification. Ask them if they have an OPT tester. Ask them if they
really want all those timers. If they want HNP polling, etc etc etc.

So far, I haven't seen anybody talking about real USB OTG (the spec)
when they say OTG. Usually they just mean "a method for swapping between
host and peripheral roles, but we really don't want all the extra cost
of the OTG specification".

> For the real use case, some Carplay platforms need it.

Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
specification which is not OTG-compliant.

>> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> > index f4fc0aa..1d74fb8 100644
>> > --- a/include/linux/usb/gadget.h
>> > +++ b/include/linux/usb/gadget.h
>> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >   * @in_epnum: last used in ep number
>> >   * @mA: last set mA value
>> >   * @otg_caps: OTG capabilities of this gadget.
>> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
>> 
>> do you really know of any platform which has a separate OTG controller?
>> 
>
> It may not be a real separate OTG controller. It can be a hardware part
> (external connector, external IC, SoC OTG register area, etc) to handle vbus
> ,id and other signals which are used for role swap.

That's already solved. EXTCON solved that years back and OMAP has been
using EXTCON to program its UTMI mailbox.

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1427348

On Mon, Jun 20, 2016 at 03:08:15PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen <hzpeterchen@gmail.com> writes:
> >> Roger Quadros <rogerq@ti.com> writes:
> >> > It provides APIs for the following tasks
> >> >
> >> > - Registering an OTG/dual-role capable controller
> >> > - Registering Host and Gadget controllers to OTG core
> >> > - Providing inputs to and kicking the OTG state machine
> >> 
> >> I think I have already mentioned this, but after over 10 years of OTG,
> >> nobody seems to care about it, why are we still touching at all I don't
> >> know. For common non-OTG role-swapping we really don't need any of this
> >> and, quite frankly, I fail to see enough users for this.
> >> 
> >> Apparently there's only chipidea which, AFAICT, already had working
> >> dual-role before this OTG State Machine was added to the kernel.
> >
> > Some users would like to know if vendor's platform is OTG compliance,
> > so we add it to pass usb.org USB OTG certification test.
> 
> I strongly doubt that's really what they mean. IMHO, users want to know
> if they can swap roles. Ask them if they are really going for OTG
> certification. Ask them if they have an OPT tester. Ask them if they
> really want all those timers. If they want HNP polling, etc etc etc.
> 
> So far, I haven't seen anybody talking about real USB OTG (the spec)
> when they say OTG. Usually they just mean "a method for swapping between
> host and peripheral roles, but we really don't want all the extra cost
> of the OTG specification".
> 

That's what I thought before, but the request from the Marketing guy is
"To prove the SoC is OTG compliance, support HNP and SRP", don't you
see the SoC reference manual say "it supports HNP and SRP"?

If there is no request, who else wants to implement so complicated FSM
but seldom use cases, and go to pass OTG compliance test (tested by PET).

> > For the real use case, some Carplay platforms need it.
> 
> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
> specification which is not OTG-compliant.
> 

Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
states to finish role swap. Notice, it needs to swap role without
disconnect cable.

> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> >> > index f4fc0aa..1d74fb8 100644
> >> > --- a/include/linux/usb/gadget.h
> >> > +++ b/include/linux/usb/gadget.h
> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
> >> >   * @in_epnum: last used in ep number
> >> >   * @mA: last set mA value
> >> >   * @otg_caps: OTG capabilities of this gadget.
> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
> >> 
> >> do you really know of any platform which has a separate OTG controller?
> >> 
> >
> > It may not be a real separate OTG controller. It can be a hardware part
> > (external connector, external IC, SoC OTG register area, etc) to handle vbus
> > ,id and other signals which are used for role swap.
> 
> That's already solved. EXTCON solved that years back and OMAP has been
> using EXTCON to program its UTMI mailbox.
> 

No, that's not the same thing, it does not include the swap role.
Consider the use case the host driver is at host/ and udc driver is
at gadget/udc, how to finish to role swap?

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1427402

[Multipart message — attachments visible in raw view] — view raw

Hi,

Peter Chen <hzpeterchen@gmail.com> writes:
>> >> > It provides APIs for the following tasks
>> >> >
>> >> > - Registering an OTG/dual-role capable controller
>> >> > - Registering Host and Gadget controllers to OTG core
>> >> > - Providing inputs to and kicking the OTG state machine
>> >> 
>> >> I think I have already mentioned this, but after over 10 years of OTG,
>> >> nobody seems to care about it, why are we still touching at all I don't
>> >> know. For common non-OTG role-swapping we really don't need any of this
>> >> and, quite frankly, I fail to see enough users for this.
>> >> 
>> >> Apparently there's only chipidea which, AFAICT, already had working
>> >> dual-role before this OTG State Machine was added to the kernel.
>> >
>> > Some users would like to know if vendor's platform is OTG compliance,
>> > so we add it to pass usb.org USB OTG certification test.
>> 
>> I strongly doubt that's really what they mean. IMHO, users want to know
>> if they can swap roles. Ask them if they are really going for OTG
>> certification. Ask them if they have an OPT tester. Ask them if they
>> really want all those timers. If they want HNP polling, etc etc etc.
>> 
>> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> when they say OTG. Usually they just mean "a method for swapping between
>> host and peripheral roles, but we really don't want all the extra cost
>> of the OTG specification".
>> 
>
> That's what I thought before, but the request from the Marketing guy is
> "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> see the SoC reference manual say "it supports HNP and SRP"?
>
> If there is no request, who else wants to implement so complicated FSM
> but seldom use cases, and go to pass OTG compliance test (tested by PET).

I stand corrected :-)

So there is one user for this layer. And this user has its own role
control registers. I'm not convinced we need this large generic layer
for one user.

>> > For the real use case, some Carplay platforms need it.
>> 
>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>> specification which is not OTG-compliant.
>> 
>
> Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
> states to finish role swap.

What are you referring to as "finish role swap"? I don't get that.

> Notice, it needs to swap role without disconnect cable.

right, I can swap role without changing cable, but that's not OTG. The
mechanism for that, AFAICT, is not HNP. I don't know details about
CarPlay because the spec isn't public, but my understanding is that
CarPlay doesn't rely on anything from OTG spec.

>> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> >> > index f4fc0aa..1d74fb8 100644
>> >> > --- a/include/linux/usb/gadget.h
>> >> > +++ b/include/linux/usb/gadget.h
>> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >> >   * @in_epnum: last used in ep number
>> >> >   * @mA: last set mA value
>> >> >   * @otg_caps: OTG capabilities of this gadget.
>> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
>> >> 
>> >> do you really know of any platform which has a separate OTG controller?
>> >> 
>> >
>> > It may not be a real separate OTG controller. It can be a hardware part
>> > (external connector, external IC, SoC OTG register area, etc) to handle vbus
>> > ,id and other signals which are used for role swap.
>> 
>> That's already solved. EXTCON solved that years back and OMAP has been
>> using EXTCON to program its UTMI mailbox.
>> 
>
> No, that's not the same thing, it does not include the swap role.

Read your original comment:

"handle vbus, id and other signals which are *used for* role swap"

You didn't include role swap in your original comment. Semantics aside...

> Consider the use case the host driver is at host/ and udc driver is
> at gadget/udc, how to finish to role swap?

... why does the source code placement matter? And what do you mean by
"finish role swap"?

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1427496

On Tue, Jun 21, 2016 at 10:26:00AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> >> 
> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
> >> when they say OTG. Usually they just mean "a method for swapping between
> >> host and peripheral roles, but we really don't want all the extra cost
> >> of the OTG specification".
> >> 
> >
> > That's what I thought before, but the request from the Marketing guy is
> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> > see the SoC reference manual say "it supports HNP and SRP"?
> >
> > If there is no request, who else wants to implement so complicated FSM
> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
> 
> I stand corrected :-)
> 
> So there is one user for this layer. And this user has its own role
> control registers. I'm not convinced we need this large generic layer
> for one user.
> 

You mean chipidea or dwc3? I have more comments below.

> >> > For the real use case, some Carplay platforms need it.
> >> 
> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
> >> specification which is not OTG-compliant.
> >> 
> >
> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
> > states to finish role swap.
> 
> What are you referring to as "finish role swap"? I don't get that.

Change current role from host to peripheral.

> 
> > Notice, it needs to swap role without disconnect cable.
> 
> right, I can swap role without changing cable, but that's not OTG. The
> mechanism for that, AFAICT, is not HNP. I don't know details about
> CarPlay because the spec isn't public, but my understanding is that
> CarPlay doesn't rely on anything from OTG spec.

Since it is non-public, I can't say much. Some flows of its role-swap
refers to On-The-Go and Embedded Host Supplement to the USB Revision 2.0
Specification. 

But OTG FSM is not the only way, the platform which can do role-swap
without disconnection can support it too.

> 
> >> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> >> >> > index f4fc0aa..1d74fb8 100644
> >> >> > --- a/include/linux/usb/gadget.h
> >> >> > +++ b/include/linux/usb/gadget.h
> >> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
> >> >> >   * @in_epnum: last used in ep number
> >> >> >   * @mA: last set mA value
> >> >> >   * @otg_caps: OTG capabilities of this gadget.
> >> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
> >> >> 
> >> >> do you really know of any platform which has a separate OTG controller?
> >> >> 
> >> >
> >> > It may not be a real separate OTG controller. It can be a hardware part
> >> > (external connector, external IC, SoC OTG register area, etc) to handle vbus
> >> > ,id and other signals which are used for role swap.
> >> 
> >> That's already solved. EXTCON solved that years back and OMAP has been
> >> using EXTCON to program its UTMI mailbox.
> >> 
> >
> > No, that's not the same thing, it does not include the swap role.
> 
> Read your original comment:
> 
> "handle vbus, id and other signals which are *used for* role swap"
> 
> You didn't include role swap in your original comment. Semantics aside...
> 
> > Consider the use case the host driver is at host/ and udc driver is
> > at gadget/udc, how to finish to role swap?
> 
> ... why does the source code placement matter? And what do you mean by
> "finish role swap"?
> 

Well, it depends on your driver design, do you want the host driver's
API is still be called when current role is peripheral? One typical
problem you can refer below:

commit 11c011a5e777c83819078a18672543f04482b3ec
Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Date:   Thu May 19 11:12:56 2016 +0100

    usb: echi-hcd: Add ehci_setup check before echi_shutdown
        


In some cases, the USB code (gadget/hcd->start/stop) needs to be called
during the role swap. For example, if you have mux driver, you may
need to call usb_remove_hcd when ID from 0 to 1. Without Roger's framework,
how can we do that?

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1427540

[Multipart message — attachments visible in raw view] — view raw

Hi,

Peter Chen <hzpeterchen@gmail.com> writes:
>> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> >> when they say OTG. Usually they just mean "a method for swapping between
>> >> host and peripheral roles, but we really don't want all the extra cost
>> >> of the OTG specification".
>> >> 
>> >
>> > That's what I thought before, but the request from the Marketing guy is
>> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
>> > see the SoC reference manual say "it supports HNP and SRP"?
>> >
>> > If there is no request, who else wants to implement so complicated FSM
>> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
>> 
>> I stand corrected :-)
>> 
>> So there is one user for this layer. And this user has its own role
>> control registers. I'm not convinced we need this large generic layer
>> for one user.
>> 
>
> You mean chipidea or dwc3? I have more comments below.

chipidea. From the point of OTG (or DRD) dwc3 is very
self-sufficient. HW itself tracks state machine, much like MUSB does.

>> >> > For the real use case, some Carplay platforms need it.
>> >> 
>> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>> >> specification which is not OTG-compliant.
>> >> 
>> >
>> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
>> > states to finish role swap.
>> 
>> What are you referring to as "finish role swap"? I don't get that.
>
> Change current role from host to peripheral.

Okay, we have two scenarios here:

1. You need full OTG compliance

	For this, granted, you need the state machine if your HW doesn't
	track it. This is a given. With only one user, however, perhaps
	we don't need a generic layer. There are not enough different
	setups to design a good enough generic layer. We will end up
	with a pseudo-generic framework which is coupled with its only
	user.

2. Dual-role support, without OTG compliance

	In this case, you don't need a stack. All you need is a signal
	to tell you state of ID pin and another to tell you state of
	VBUS level. If you have those, you don't need to walk an OTG
	state machine at all. You don't need any of those quirky OTG
	timers, agreed?

	Given the above, why would you even want to use a subset of OTG
	state machine to implement something that's _usually_ as simple
	as:

8<----------------------------------------------------------------------
	vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
        id = read(ID_STATE); /* could be a gpio_get_value() */

        set_role(id);
        set_vbus(vbus);
------------------------------------------------------------------------

>> > Notice, it needs to swap role without disconnect cable.
>> 
>> right, I can swap role without changing cable, but that's not OTG. The
>> mechanism for that, AFAICT, is not HNP. I don't know details about
>> CarPlay because the spec isn't public, but my understanding is that
>> CarPlay doesn't rely on anything from OTG spec.
>
> Since it is non-public, I can't say much. Some flows of its role-swap
> refers to On-The-Go and Embedded Host Supplement to the USB Revision 2.0
> Specification. 
>
> But OTG FSM is not the only way, the platform which can do role-swap
> without disconnection can support it too.

Right, all you need for CarPlay is what I wrote above. You don't need
full OTG compliance for that, right?

>> >> >> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
>> >> >> > index f4fc0aa..1d74fb8 100644
>> >> >> > --- a/include/linux/usb/gadget.h
>> >> >> > +++ b/include/linux/usb/gadget.h
>> >> >> > @@ -328,6 +328,7 @@ struct usb_gadget_ops {
>> >> >> >   * @in_epnum: last used in ep number
>> >> >> >   * @mA: last set mA value
>> >> >> >   * @otg_caps: OTG capabilities of this gadget.
>> >> >> > + * @otg_dev: OTG controller device, if needs to be used with OTG core.
>> >> >> 
>> >> >> do you really know of any platform which has a separate OTG controller?
>> >> >> 
>> >> >
>> >> > It may not be a real separate OTG controller. It can be a hardware part
>> >> > (external connector, external IC, SoC OTG register area, etc) to handle vbus
>> >> > ,id and other signals which are used for role swap.
>> >> 
>> >> That's already solved. EXTCON solved that years back and OMAP has been
>> >> using EXTCON to program its UTMI mailbox.
>> >> 
>> >
>> > No, that's not the same thing, it does not include the swap role.
>> 
>> Read your original comment:
>> 
>> "handle vbus, id and other signals which are *used for* role swap"
>> 
>> You didn't include role swap in your original comment. Semantics aside...
>> 
>> > Consider the use case the host driver is at host/ and udc driver is
>> > at gadget/udc, how to finish to role swap?
>> 
>> ... why does the source code placement matter? And what do you mean by
>> "finish role swap"?
>> 
>
> Well, it depends on your driver design, do you want the host driver's
> API is still be called when current role is peripheral? One typical
> problem you can refer below:

That's a driver bug and those needs to be fixed. This has nothing to do
with an OTG FSM, or lack thereof.

Here's what I plan on doing for dwc3 (as soon as I get some time):

request_threaded_irq(dwc->otg_irq, ...);

irqreturn_t dwc3_otg_irq_thread(int irq, void *_dwc)
{
	struct dwc3 *dwc = _dwc;
        u32 reg;

        reg = readl(OSTS);
        if (reg & PERIPHERAL)
        	dwc3_gadget_init(dwc);

	if (reg & HOST)
        	dwc3_host_init(dwc);

	if (reg & SESSION_END)
        	dwc3_disable_host_and_peripheral(dwc);

	return IRQ_HANDLED;
}

Then, when building the driver with OTG support, we never start Host or
peripheral by default. Only the OTG IRQ handler, since that becomes the
entry point.

That's all we need for DRD support on DWC3. As for OTG, it won't be much
different because the HW tracks OTG state machine. The only difference
will be implemeting HNP (just another big in IRQ handler) and SRP
(already implemented as gadget_wakeup())

> commit 11c011a5e777c83819078a18672543f04482b3ec
> Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Date:   Thu May 19 11:12:56 2016 +0100
>
>     usb: echi-hcd: Add ehci_setup check before echi_shutdown
>         
>
>
> In some cases, the USB code (gadget/hcd->start/stop) needs to be called
> during the role swap. For example, if you have mux driver, you may
> need to call usb_remove_hcd when ID from 0 to 1. Without Roger's framework,
> how can we do that?

You don't really need to remove the gadget. Just mask its interrupts and
ignore any calls to any gadget_driver ops, right? Likewise for
XHCI. Just clear RUN/STOP and no events will ever reach XHCI. But, from
the point of view of dwc3, it's simpler to unregister the platform
device we create for xhci-plat.c. I need no changes in XHCI to do that
and driver model will make sure to call xhci-plat's ->remove() which
will handle everything for me correctly.

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1427603

* Felipe Balbi <balbi@kernel.org> [160621 03:06]:
> 8<----------------------------------------------------------------------
> 	vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>         id = read(ID_STATE); /* could be a gpio_get_value() */
> 
>         set_role(id);
>         set_vbus(vbus);

We should use regulator framework API for set_vbus() because of
the delays involved bringing it up. And we already have separate
PHY and charger chips where VBUS is provided by the charger chip.

Regards,

Tony

[toc] | [prev] | [next] | [standalone]

#1427607

[Multipart message — attachments visible in raw view] — view raw

Hi,

Tony Lindgren <tony@atomide.com> writes:
> * Felipe Balbi <balbi@kernel.org> [160621 03:06]:
>> 8<----------------------------------------------------------------------
>> 	vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>>         id = read(ID_STATE); /* could be a gpio_get_value() */
>> 
>>         set_role(id);
>>         set_vbus(vbus);
>
> We should use regulator framework API for set_vbus() because of
> the delays involved bringing it up. And we already have separate
> PHY and charger chips where VBUS is provided by the charger chip.

yeah, no arguments there.

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1427948

On Tue, Jun 21, 2016 at 01:02:59PM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen <hzpeterchen@gmail.com> writes:
> >> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
> >> >> when they say OTG. Usually they just mean "a method for swapping between
> >> >> host and peripheral roles, but we really don't want all the extra cost
> >> >> of the OTG specification".
> >> >> 
> >> >
> >> > That's what I thought before, but the request from the Marketing guy is
> >> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> >> > see the SoC reference manual say "it supports HNP and SRP"?
> >> >
> >> > If there is no request, who else wants to implement so complicated FSM
> >> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
> >> 
> >> I stand corrected :-)
> >> 
> >> So there is one user for this layer. And this user has its own role
> >> control registers. I'm not convinced we need this large generic layer
> >> for one user.
> >> 
> >
> > You mean chipidea or dwc3? I have more comments below.
> 
> chipidea. From the point of OTG (or DRD) dwc3 is very
> self-sufficient. HW itself tracks state machine, much like MUSB does.

You mean HW can do state machine switch? If we are A device,
- Does the hardware knows if B device is HNP enabled or not?
- And if B device is HNP enabled, does it can switch itself from host
to peripheral when the B device is disconnected (a_suspend->a_peripheral)

Does hardware can really follow Figure 7-1: OTG A-device with HNP State
Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
2.0 Specification? And can pass PET test?

> 
> >> >> > For the real use case, some Carplay platforms need it.
> >> >> 
> >> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
> >> >> specification which is not OTG-compliant.
> >> >> 
> >> >
> >> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
> >> > states to finish role swap.
> >> 
> >> What are you referring to as "finish role swap"? I don't get that.
> >
> > Change current role from host to peripheral.
> 
> Okay, we have two scenarios here:
> 
> 1. You need full OTG compliance
> 
> 	For this, granted, you need the state machine if your HW doesn't
> 	track it. This is a given. With only one user, however, perhaps
> 	we don't need a generic layer. There are not enough different
> 	setups to design a good enough generic layer. We will end up
> 	with a pseudo-generic framework which is coupled with its only
> 	user.
> 
> 2. Dual-role support, without OTG compliance
> 
> 	In this case, you don't need a stack. All you need is a signal
> 	to tell you state of ID pin and another to tell you state of
> 	VBUS level. If you have those, you don't need to walk an OTG
> 	state machine at all. You don't need any of those quirky OTG
> 	timers, agreed?
> 
> 	Given the above, why would you even want to use a subset of OTG
> 	state machine to implement something that's _usually_ as simple
> 	as:
> 
> 8<----------------------------------------------------------------------
> 	vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>         id = read(ID_STATE); /* could be a gpio_get_value() */
> 
>         set_role(id);
>         set_vbus(vbus);
> ------------------------------------------------------------------------
> 

In fact, the individual driver can do it by itself. The chipidea driver
handles OTG and dual-role well currently. By considering this OTG/DRD
framework is worthwhile or not, we would like to see if it can
simplify DRD design for each driver, and can benefit the platforms which
has different drivers for host and peripheral to finish the role switch
well.

- The common start/stop host and peripheral operation
eg, when switch from host to peripheral, all drivers can use
usb_remove_hcd to finish it.
- A common workqueue to handle vbus and id event
- sysfs for role switch

> >> > Notice, it needs to swap role without disconnect cable.
> >> 
> >> right, I can swap role without changing cable, but that's not OTG. The
> >> mechanism for that, AFAICT, is not HNP. I don't know details about
> >> CarPlay because the spec isn't public, but my understanding is that
> >> CarPlay doesn't rely on anything from OTG spec.
> >
> > Since it is non-public, I can't say much. Some flows of its role-swap
> > refers to On-The-Go and Embedded Host Supplement to the USB Revision 2.0
> > Specification. 
> >
> > But OTG FSM is not the only way, the platform which can do role-swap
> > without disconnection can support it too.
> 
> Right, all you need for CarPlay is what I wrote above. You don't need
> full OTG compliance for that, right?
> 

OTG FSM is not necessary, other dual-role switch also can satisfy its
requirement.

> >> 
> >> > Consider the use case the host driver is at host/ and udc driver is
> >> > at gadget/udc, how to finish to role swap?
> >> 
> >> ... why does the source code placement matter? And what do you mean by
> >> "finish role swap"?
> >> 
> >
> > Well, it depends on your driver design, do you want the host driver's
> > API is still be called when current role is peripheral? One typical
> > problem you can refer below:
> 
> That's a driver bug and those needs to be fixed. This has nothing to do
> with an OTG FSM, or lack thereof.
> 

To simplify the discussion, we consider dual-role switch first. If dual-role
needs a framework, then OTG can use the same one just different state
machine.

> (already implemented as gadget_wakeup())
> 
> > commit 11c011a5e777c83819078a18672543f04482b3ec
> > Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> > Date:   Thu May 19 11:12:56 2016 +0100
> >
> >     usb: echi-hcd: Add ehci_setup check before echi_shutdown
> >         
> >
> >
> > In some cases, the USB code (gadget/hcd->start/stop) needs to be called
> > during the role swap. For example, if you have mux driver, you may
> > need to call usb_remove_hcd when ID from 0 to 1. Without Roger's framework,
> > how can we do that?
> 
> You don't really need to remove the gadget. Just mask its interrupts and
> ignore any calls to any gadget_driver ops, right? Likewise for
> XHCI. Just clear RUN/STOP and no events will ever reach XHCI. But, from
> the point of view of dwc3, it's simpler to unregister the platform
> device we create for xhci-plat.c. I need no changes in XHCI to do that
> and driver model will make sure to call xhci-plat's ->remove() which
> will handle everything for me correctly.
> 

I admit it can do in a IP driver, eg both host and peripheral for the
single IP, eg chipidea, dwc3, etc. But how can we clear RUN/STOP bit
or what else for HCD at mux driver?

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1428476

[Multipart message — attachments visible in raw view] — view raw

Hi,

Peter Chen <hzpeterchen@gmail.com> writes:
>> Peter Chen <hzpeterchen@gmail.com> writes:
>> >> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> >> >> when they say OTG. Usually they just mean "a method for swapping between
>> >> >> host and peripheral roles, but we really don't want all the extra cost
>> >> >> of the OTG specification".
>> >> >> 
>> >> >
>> >> > That's what I thought before, but the request from the Marketing guy is
>> >> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
>> >> > see the SoC reference manual say "it supports HNP and SRP"?
>> >> >
>> >> > If there is no request, who else wants to implement so complicated FSM
>> >> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
>> >> 
>> >> I stand corrected :-)
>> >> 
>> >> So there is one user for this layer. And this user has its own role
>> >> control registers. I'm not convinced we need this large generic layer
>> >> for one user.
>> >> 
>> >
>> > You mean chipidea or dwc3? I have more comments below.
>> 
>> chipidea. From the point of OTG (or DRD) dwc3 is very
>> self-sufficient. HW itself tracks state machine, much like MUSB does.
>
> You mean HW can do state machine switch? If we are A device,
> - Does the hardware knows if B device is HNP enabled or not?

that's enabled through control message, keep a flag.

> - And if B device is HNP enabled, does it can switch itself from host
> to peripheral when the B device is disconnected (a_suspend->a_peripheral)

It cannot. It must rely on hnp polling which is, again, a control message.

> Does hardware can really follow Figure 7-1: OTG A-device with HNP State
> Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
> 2.0 Specification? And can pass PET test?

Seriously, what does this add to the conversation? It has already been
stated that there's nobody asking for OTG certification on dwc3. So all
of this is vaporware from the point of view of dwc3.

>> >> >> > For the real use case, some Carplay platforms need it.
>> >> >> 
>> >> >> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>> >> >> specification which is not OTG-compliant.
>> >> >> 
>> >> >
>> >> > Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
>> >> > states to finish role swap.
>> >> 
>> >> What are you referring to as "finish role swap"? I don't get that.
>> >
>> > Change current role from host to peripheral.
>> 
>> Okay, we have two scenarios here:
>> 
>> 1. You need full OTG compliance
>> 
>> 	For this, granted, you need the state machine if your HW doesn't
>> 	track it. This is a given. With only one user, however, perhaps
>> 	we don't need a generic layer. There are not enough different
>> 	setups to design a good enough generic layer. We will end up
>> 	with a pseudo-generic framework which is coupled with its only
>> 	user.
>> 
>> 2. Dual-role support, without OTG compliance
>> 
>> 	In this case, you don't need a stack. All you need is a signal
>> 	to tell you state of ID pin and another to tell you state of
>> 	VBUS level. If you have those, you don't need to walk an OTG
>> 	state machine at all. You don't need any of those quirky OTG
>> 	timers, agreed?
>> 
>> 	Given the above, why would you even want to use a subset of OTG
>> 	state machine to implement something that's _usually_ as simple
>> 	as:
>> 
>> 8<----------------------------------------------------------------------
>> 	vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>>         id = read(ID_STATE); /* could be a gpio_get_value() */
>> 
>>         set_role(id);
>>         set_vbus(vbus);
>> ------------------------------------------------------------------------
>> 
>
> In fact, the individual driver can do it by itself. The chipidea driver
> handles OTG and dual-role well currently. By considering this OTG/DRD
> framework is worthwhile or not, we would like to see if it can
> simplify DRD design for each driver, and can benefit the platforms which
> has different drivers for host and peripheral to finish the role switch
> well.

simplify how?  By adding unnecessary workqueues and a level indirection
that just goes back to the same driver?

>> > commit 11c011a5e777c83819078a18672543f04482b3ec
>> > Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> > Date:   Thu May 19 11:12:56 2016 +0100
>> >
>> >     usb: echi-hcd: Add ehci_setup check before echi_shutdown
>> >         
>> >
>> >
>> > In some cases, the USB code (gadget/hcd->start/stop) needs to be called
>> > during the role swap. For example, if you have mux driver, you may
>> > need to call usb_remove_hcd when ID from 0 to 1. Without Roger's framework,
>> > how can we do that?
>> 
>> You don't really need to remove the gadget. Just mask its interrupts and
>> ignore any calls to any gadget_driver ops, right? Likewise for
>> XHCI. Just clear RUN/STOP and no events will ever reach XHCI. But, from
>> the point of view of dwc3, it's simpler to unregister the platform
>> device we create for xhci-plat.c. I need no changes in XHCI to do that
>> and driver model will make sure to call xhci-plat's ->remove() which
>> will handle everything for me correctly.
>> 
>
> I admit it can do in a IP driver, eg both host and peripheral for the
> single IP, eg chipidea, dwc3, etc. But how can we clear RUN/STOP bit
> or what else for HCD at mux driver?

dwc3's OTG block has control of that, however, what I'll do is
platform_device_del() xhci-plat's device. Not one line changes inside
XHCI.

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1428523

On Wed, Jun 22, 2016 at 09:56:22AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen <hzpeterchen@gmail.com> writes:
> >> Peter Chen <hzpeterchen@gmail.com> writes:
> >> >> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
> >> >> >> when they say OTG. Usually they just mean "a method for swapping between
> >> >> >> host and peripheral roles, but we really don't want all the extra cost
> >> >> >> of the OTG specification".
> >> >> >> 
> >> >> >
> >> >> > That's what I thought before, but the request from the Marketing guy is
> >> >> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
> >> >> > see the SoC reference manual say "it supports HNP and SRP"?
> >> >> >
> >> >> > If there is no request, who else wants to implement so complicated FSM
> >> >> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
> >> >> 
> >> >> I stand corrected :-)
> >> >> 
> >> >> So there is one user for this layer. And this user has its own role
> >> >> control registers. I'm not convinced we need this large generic layer
> >> >> for one user.
> >> >> 
> >> >
> >> > You mean chipidea or dwc3? I have more comments below.
> >> 
> >> chipidea. From the point of OTG (or DRD) dwc3 is very
> >> self-sufficient. HW itself tracks state machine, much like MUSB does.
> >
> > You mean HW can do state machine switch? If we are A device,
> > - Does the hardware knows if B device is HNP enabled or not?
> 
> that's enabled through control message, keep a flag.
> 
> > - And if B device is HNP enabled, does it can switch itself from host
> > to peripheral when the B device is disconnected (a_suspend->a_peripheral)
> 
> It cannot. It must rely on hnp polling which is, again, a control message.
> 
> > Does hardware can really follow Figure 7-1: OTG A-device with HNP State
> > Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
> > 2.0 Specification? And can pass PET test?
> 
> Seriously, what does this add to the conversation? It has already been
> stated that there's nobody asking for OTG certification on dwc3. So all
> of this is vaporware from the point of view of dwc3.

This is just a technical question that I can't understand your words
"HW itself tracks state machine"?

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1428534

[Multipart message — attachments visible in raw view] — view raw

Hi,

Peter Chen <hzpeterchen@gmail.com> writes:
>> >> >> >> So far, I haven't seen anybody talking about real USB OTG (the spec)
>> >> >> >> when they say OTG. Usually they just mean "a method for swapping between
>> >> >> >> host and peripheral roles, but we really don't want all the extra cost
>> >> >> >> of the OTG specification".
>> >> >> >> 
>> >> >> >
>> >> >> > That's what I thought before, but the request from the Marketing guy is
>> >> >> > "To prove the SoC is OTG compliance, support HNP and SRP", don't you
>> >> >> > see the SoC reference manual say "it supports HNP and SRP"?
>> >> >> >
>> >> >> > If there is no request, who else wants to implement so complicated FSM
>> >> >> > but seldom use cases, and go to pass OTG compliance test (tested by PET).
>> >> >> 
>> >> >> I stand corrected :-)
>> >> >> 
>> >> >> So there is one user for this layer. And this user has its own role
>> >> >> control registers. I'm not convinced we need this large generic layer
>> >> >> for one user.
>> >> >> 
>> >> >
>> >> > You mean chipidea or dwc3? I have more comments below.
>> >> 
>> >> chipidea. From the point of OTG (or DRD) dwc3 is very
>> >> self-sufficient. HW itself tracks state machine, much like MUSB does.
>> >
>> > You mean HW can do state machine switch? If we are A device,
>> > - Does the hardware knows if B device is HNP enabled or not?
>> 
>> that's enabled through control message, keep a flag.
>> 
>> > - And if B device is HNP enabled, does it can switch itself from host
>> > to peripheral when the B device is disconnected (a_suspend->a_peripheral)
>> 
>> It cannot. It must rely on hnp polling which is, again, a control message.
>> 
>> > Does hardware can really follow Figure 7-1: OTG A-device with HNP State
>> > Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
>> > 2.0 Specification? And can pass PET test?
>> 
>> Seriously, what does this add to the conversation? It has already been
>> stated that there's nobody asking for OTG certification on dwc3. So all
>> of this is vaporware from the point of view of dwc3.
>
> This is just a technical question that I can't understand your words
> "HW itself tracks state machine"?

It's simple, really: HW knows that it starts in B_IDLE. All automatic
state changes, HW will do:

B_IDLE -> A_IDLE -> A_WAIT_VRISE -> A_WAIT_BCON -> A_HOST
B_IDLE -> B_WAIT_ACON -> B_PERIPHERAL

Some state changes need SW intervention, for those you need to kick the
correct event so HW makes the state change. But register will still tell
you correct state after HW switches to it.

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1428524

[Multipart message — attachments visible in raw view] — view raw

Hi Felipe,

On 22/06/16 09:56, Felipe Balbi wrote:
> 
> Hi,
> 
> Peter Chen <hzpeterchen@gmail.com> writes:
>>> Peter Chen <hzpeterchen@gmail.com> writes:
>>>>>>> So far, I haven't seen anybody talking about real USB OTG (the spec)
>>>>>>> when they say OTG. Usually they just mean "a method for swapping between
>>>>>>> host and peripheral roles, but we really don't want all the extra cost
>>>>>>> of the OTG specification".
>>>>>>>
>>>>>>
>>>>>> That's what I thought before, but the request from the Marketing guy is
>>>>>> "To prove the SoC is OTG compliance, support HNP and SRP", don't you
>>>>>> see the SoC reference manual say "it supports HNP and SRP"?
>>>>>>
>>>>>> If there is no request, who else wants to implement so complicated FSM
>>>>>> but seldom use cases, and go to pass OTG compliance test (tested by PET).
>>>>>
>>>>> I stand corrected :-)
>>>>>
>>>>> So there is one user for this layer. And this user has its own role
>>>>> control registers. I'm not convinced we need this large generic layer
>>>>> for one user.
>>>>>
>>>>
>>>> You mean chipidea or dwc3? I have more comments below.
>>>
>>> chipidea. From the point of OTG (or DRD) dwc3 is very
>>> self-sufficient. HW itself tracks state machine, much like MUSB does.
>>
>> You mean HW can do state machine switch? If we are A device,
>> - Does the hardware knows if B device is HNP enabled or not?
> 
> that's enabled through control message, keep a flag.
> 
>> - And if B device is HNP enabled, does it can switch itself from host
>> to peripheral when the B device is disconnected (a_suspend->a_peripheral)
> 
> It cannot. It must rely on hnp polling which is, again, a control message.
> 
>> Does hardware can really follow Figure 7-1: OTG A-device with HNP State
>> Diagram at On-The-Go and Embedded Host Supplement to the USB Revision
>> 2.0 Specification? And can pass PET test?
> 
> Seriously, what does this add to the conversation? It has already been
> stated that there's nobody asking for OTG certification on dwc3. So all
> of this is vaporware from the point of view of dwc3.
> 
>>>>>>>> For the real use case, some Carplay platforms need it.
>>>>>>>
>>>>>>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>>>>>>> specification which is not OTG-compliant.
>>>>>>>
>>>>>>
>>>>>> Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
>>>>>> states to finish role swap.
>>>>>
>>>>> What are you referring to as "finish role swap"? I don't get that.
>>>>
>>>> Change current role from host to peripheral.
>>>
>>> Okay, we have two scenarios here:
>>>
>>> 1. You need full OTG compliance
>>>
>>> 	For this, granted, you need the state machine if your HW doesn't
>>> 	track it. This is a given. With only one user, however, perhaps
>>> 	we don't need a generic layer. There are not enough different
>>> 	setups to design a good enough generic layer. We will end up
>>> 	with a pseudo-generic framework which is coupled with its only
>>> 	user.
>>>
>>> 2. Dual-role support, without OTG compliance
>>>
>>> 	In this case, you don't need a stack. All you need is a signal
>>> 	to tell you state of ID pin and another to tell you state of
>>> 	VBUS level. If you have those, you don't need to walk an OTG
>>> 	state machine at all. You don't need any of those quirky OTG
>>> 	timers, agreed?
>>>
>>> 	Given the above, why would you even want to use a subset of OTG
>>> 	state machine to implement something that's _usually_ as simple
>>> 	as:
>>>
>>> 8<----------------------------------------------------------------------
>>> 	vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>>>         id = read(ID_STATE); /* could be a gpio_get_value() */
>>>
>>>         set_role(id);
>>>         set_vbus(vbus);
>>> ------------------------------------------------------------------------
>>>
>>
>> In fact, the individual driver can do it by itself. The chipidea driver
>> handles OTG and dual-role well currently. By considering this OTG/DRD
>> framework is worthwhile or not, we would like to see if it can
>> simplify DRD design for each driver, and can benefit the platforms which
>> has different drivers for host and peripheral to finish the role switch
>> well.
> 
> simplify how?  By adding unnecessary workqueues and a level indirection
> that just goes back to the same driver?

What do you mean by same driver?
Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can be 3 totally
independent drivers unlike dwc3 where you have a single driver in control of
both host and gadget.

Questions not clear to me are:
1) Which driver handles ID/VBUS events and makes a decision to do the role swap?
Probably the PHY/MUX driver?
2) How does it perform the role swap? Probably a register write to the PHY/MUX
without needing to stop/start controllers? Easy case is both controllers can
run in co-existence without interference. Is there any platform other than dwc3
where this is not the case?
3) Even if host and gadget controllers can operate in coexistence, there is no need for
both to be running for embedded applications which are usually power conservative.
How can we achieve that?

> 
>>>> commit 11c011a5e777c83819078a18672543f04482b3ec
>>>> Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>>> Date:   Thu May 19 11:12:56 2016 +0100
>>>>
>>>>     usb: echi-hcd: Add ehci_setup check before echi_shutdown
>>>>         
>>>>
>>>>
>>>> In some cases, the USB code (gadget/hcd->start/stop) needs to be called
>>>> during the role swap. For example, if you have mux driver, you may
>>>> need to call usb_remove_hcd when ID from 0 to 1. Without Roger's framework,
>>>> how can we do that?
>>>
>>> You don't really need to remove the gadget. Just mask its interrupts and
>>> ignore any calls to any gadget_driver ops, right? Likewise for
>>> XHCI. Just clear RUN/STOP and no events will ever reach XHCI. But, from
>>> the point of view of dwc3, it's simpler to unregister the platform
>>> device we create for xhci-plat.c. I need no changes in XHCI to do that
>>> and driver model will make sure to call xhci-plat's ->remove() which
>>> will handle everything for me correctly.
>>>
>>
>> I admit it can do in a IP driver, eg both host and peripheral for the
>> single IP, eg chipidea, dwc3, etc. But how can we clear RUN/STOP bit
>> or what else for HCD at mux driver?
> 
> dwc3's OTG block has control of that, however, what I'll do is
> platform_device_del() xhci-plat's device. Not one line changes inside
> XHCI.
> 

Let's talk about how non dwc3 based platforms can get it done.

Yoshihiro-san, could you please share your platform requirements from dual-role
perspective?

cheers,
-roger

[toc] | [prev] | [next] | [standalone]

#1428538

[Multipart message — attachments visible in raw view] — view raw

Hi,

Roger Quadros <rogerq@ti.com> writes:
>>>>>>>>> For the real use case, some Carplay platforms need it.
>>>>>>>>
>>>>>>>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>>>>>>>> specification which is not OTG-compliant.
>>>>>>>>
>>>>>>>
>>>>>>> Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
>>>>>>> states to finish role swap.
>>>>>>
>>>>>> What are you referring to as "finish role swap"? I don't get that.
>>>>>
>>>>> Change current role from host to peripheral.
>>>>
>>>> Okay, we have two scenarios here:
>>>>
>>>> 1. You need full OTG compliance
>>>>
>>>> 	For this, granted, you need the state machine if your HW doesn't
>>>> 	track it. This is a given. With only one user, however, perhaps
>>>> 	we don't need a generic layer. There are not enough different
>>>> 	setups to design a good enough generic layer. We will end up
>>>> 	with a pseudo-generic framework which is coupled with its only
>>>> 	user.
>>>>
>>>> 2. Dual-role support, without OTG compliance
>>>>
>>>> 	In this case, you don't need a stack. All you need is a signal
>>>> 	to tell you state of ID pin and another to tell you state of
>>>> 	VBUS level. If you have those, you don't need to walk an OTG
>>>> 	state machine at all. You don't need any of those quirky OTG
>>>> 	timers, agreed?
>>>>
>>>> 	Given the above, why would you even want to use a subset of OTG
>>>> 	state machine to implement something that's _usually_ as simple
>>>> 	as:
>>>>
>>>> 8<----------------------------------------------------------------------
>>>> 	vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>>>>         id = read(ID_STATE); /* could be a gpio_get_value() */
>>>>
>>>>         set_role(id);
>>>>         set_vbus(vbus);
>>>> ------------------------------------------------------------------------
>>>>
>>>
>>> In fact, the individual driver can do it by itself. The chipidea driver
>>> handles OTG and dual-role well currently. By considering this OTG/DRD
>>> framework is worthwhile or not, we would like to see if it can
>>> simplify DRD design for each driver, and can benefit the platforms which
>>> has different drivers for host and peripheral to finish the role switch
>>> well.
>> 
>> simplify how?  By adding unnecessary workqueues and a level indirection
>> that just goes back to the same driver?
>
> What do you mean by same driver?

dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
layer jumps to a callback that goes back to dwc3 to e.g. start
peripheral side.

See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.

> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
> be 3 totally independent drivers unlike dwc3 where you have a single
> driver in control of both host and gadget.

That's a totally different issue and one not being tackled by OTG
layer, because there are no such users yet. We can't design anything
based solely on speculation of what might happen.

If there aren't enough users, there is no way to design a good generic
layer.

> Questions not clear to me are:
>
> 1) Which driver handles ID/VBUS events and makes a decision to do the
> role swap?  Probably the PHY/MUX driver?

This is implementation dependent. For TI's USB subsystem, we have PMIC
sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
has no intervention.

For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
internal mux (much like TI's UTMI mailbox, but slightly different) to
switch between a separate XHCI or a separate dwc3. The same mux can be
put in HW-mode where SW has no intervention.

In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
driver just detects role (at least for Type-C based plats) and executes
_DSM with correct arguments [1]. _DSM will program internal MUX, toggle
VBUS and, for type-C, toggle VCONN when needed.

> 2) How does it perform the role swap? Probably a register write to the
> PHY/MUX without needing to stop/start controllers? Easy case is both
> controllers can run in co-existence without interference. Is there any
> platform other than dwc3 where this is not the case?

Again speculation. But to answer your question, only dwc3 is in such a
case today. But even for dwc3 we can have DRD with a much, much simpler
setup as I have already explained.

> 3) Even if host and gadget controllers can operate in coexistence,
> there is no need for both to be running for embedded applications
> which are usually power conservative.  How can we achieve that?

Now you're also speculating that you're running on embedded applications
and that we _can_ power off parts of the IP. I happen to know that we
can't power off XHCI part of dwc3 in TI's SoC because that's fed by same
Clocks and power rails as the peripheral side.

[1] https://lkml.org/lkml/2016/6/21/658

-- 
balbi

[toc] | [prev] | [next] | [standalone]

#1428551

[Multipart message — attachments visible in raw view] — view raw

On 22/06/16 11:14, Felipe Balbi wrote:
> 
> Hi,
> 
> Roger Quadros <rogerq@ti.com> writes:
>>>>>>>>>> For the real use case, some Carplay platforms need it.
>>>>>>>>>
>>>>>>>>> Carplay does *NOT* rely on OTG. Apple has its own proprietary and closed
>>>>>>>>> specification which is not OTG-compliant.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM
>>>>>>>> states to finish role swap.
>>>>>>>
>>>>>>> What are you referring to as "finish role swap"? I don't get that.
>>>>>>
>>>>>> Change current role from host to peripheral.
>>>>>
>>>>> Okay, we have two scenarios here:
>>>>>
>>>>> 1. You need full OTG compliance
>>>>>
>>>>> 	For this, granted, you need the state machine if your HW doesn't
>>>>> 	track it. This is a given. With only one user, however, perhaps
>>>>> 	we don't need a generic layer. There are not enough different
>>>>> 	setups to design a good enough generic layer. We will end up
>>>>> 	with a pseudo-generic framework which is coupled with its only
>>>>> 	user.
>>>>>
>>>>> 2. Dual-role support, without OTG compliance
>>>>>
>>>>> 	In this case, you don't need a stack. All you need is a signal
>>>>> 	to tell you state of ID pin and another to tell you state of
>>>>> 	VBUS level. If you have those, you don't need to walk an OTG
>>>>> 	state machine at all. You don't need any of those quirky OTG
>>>>> 	timers, agreed?
>>>>>
>>>>> 	Given the above, why would you even want to use a subset of OTG
>>>>> 	state machine to implement something that's _usually_ as simple
>>>>> 	as:
>>>>>
>>>>> 8<----------------------------------------------------------------------
>>>>> 	vbus = read(VBUS_STATE); /* could be a gpio_get_value() */
>>>>>         id = read(ID_STATE); /* could be a gpio_get_value() */
>>>>>
>>>>>         set_role(id);
>>>>>         set_vbus(vbus);
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>
>>>> In fact, the individual driver can do it by itself. The chipidea driver
>>>> handles OTG and dual-role well currently. By considering this OTG/DRD
>>>> framework is worthwhile or not, we would like to see if it can
>>>> simplify DRD design for each driver, and can benefit the platforms which
>>>> has different drivers for host and peripheral to finish the role switch
>>>> well.
>>>
>>> simplify how?  By adding unnecessary workqueues and a level indirection
>>> that just goes back to the same driver?
>>
>> What do you mean by same driver?
> 
> dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC
> layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG
> layer jumps to a callback that goes back to dwc3 to e.g. start
> peripheral side.
> 
> See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3.
> 
>> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can
>> be 3 totally independent drivers unlike dwc3 where you have a single
>> driver in control of both host and gadget.
> 
> That's a totally different issue and one not being tackled by OTG
> layer, because there are no such users yet. We can't design anything
> based solely on speculation of what might happen.
> 
> If there aren't enough users, there is no way to design a good generic
> layer.
> 
>> Questions not clear to me are:
>>
>> 1) Which driver handles ID/VBUS events and makes a decision to do the
>> role swap?  Probably the PHY/MUX driver?
> 
> This is implementation dependent. For TI's USB subsystem, we have PMIC
> sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI
> mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW
> has no intervention.
> 
> For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an
> internal mux (much like TI's UTMI mailbox, but slightly different) to
> switch between a separate XHCI or a separate dwc3. The same mux can be
> put in HW-mode where SW has no intervention.
> 
> In any case, for Intel's stuff most of the magic happens in ASL. Our PHY
> driver just detects role (at least for Type-C based plats) and executes
> _DSM with correct arguments [1]. _DSM will program internal MUX, toggle
> VBUS and, for type-C, toggle VCONN when needed.
> 
>> 2) How does it perform the role swap? Probably a register write to the
>> PHY/MUX without needing to stop/start controllers? Easy case is both
>> controllers can run in co-existence without interference. Is there any
>> platform other than dwc3 where this is not the case?
> 
> Again speculation. But to answer your question, only dwc3 is in such a
> case today. But even for dwc3 we can have DRD with a much, much simpler
> setup as I have already explained.
> 
>> 3) Even if host and gadget controllers can operate in coexistence,
>> there is no need for both to be running for embedded applications
>> which are usually power conservative.  How can we achieve that?
> 
> Now you're also speculating that you're running on embedded applications
> and that we _can_ power off parts of the IP. I happen to know that we
> can't power off XHCI part of dwc3 in TI's SoC because that's fed by same
> Clocks and power rails as the peripheral side.
> 
> [1] https://lkml.org/lkml/2016/6/21/658
> 
For TI's case it is dwc3 and you are implementing the role swap in the dwc3
driver where you do intend to remove the XHCI platform device. So I'm not
much concerned about that.

I was concerned about other platforms. I guess I'll let the other platform
people speak up as to what they need.

--
cheers,
-roger

[toc] | [prev] | [next] | [standalone]

#1429538

Hi Roger-san,

< snip >
> >>>> commit 11c011a5e777c83819078a18672543f04482b3ec
> >>>> Author: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> >>>> Date:   Thu May 19 11:12:56 2016 +0100
> >>>>
> >>>>     usb: echi-hcd: Add ehci_setup check before echi_shutdown
> >>>>
> >>>>
> >>>>
> >>>> In some cases, the USB code (gadget/hcd->start/stop) needs to be called
> >>>> during the role swap. For example, if you have mux driver, you may
> >>>> need to call usb_remove_hcd when ID from 0 to 1. Without Roger's framework,
> >>>> how can we do that?
> >>>
> >>> You don't really need to remove the gadget. Just mask its interrupts and
> >>> ignore any calls to any gadget_driver ops, right? Likewise for
> >>> XHCI. Just clear RUN/STOP and no events will ever reach XHCI. But, from
> >>> the point of view of dwc3, it's simpler to unregister the platform
> >>> device we create for xhci-plat.c. I need no changes in XHCI to do that
> >>> and driver model will make sure to call xhci-plat's ->remove() which
> >>> will handle everything for me correctly.
> >>>
> >>
> >> I admit it can do in a IP driver, eg both host and peripheral for the
> >> single IP, eg chipidea, dwc3, etc. But how can we clear RUN/STOP bit
> >> or what else for HCD at mux driver?
> >
> > dwc3's OTG block has control of that, however, what I'll do is
> > platform_device_del() xhci-plat's device. Not one line changes inside
> > XHCI.
> >
> 
> Let's talk about how non dwc3 based platforms can get it done.
> 
> Yoshihiro-san, could you please share your platform requirements from dual-role
> perspective?

My platform requirements about dual-role are:
- Initial settings of all host, gadget and OTG IP registers are needed before enters [AB]-device recognition procedure.
- In the recognition procedures, a software needs:
 - to check ID pin related register in OTG
 - to set OTG IP registers to change the role
  - and then host or gadget can start.
- In the disconnect detection procedures, a software needs similar checkings/settings with the recognition.

Best regards,
Yoshihiro Shimoda

> cheers,
> -roger

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web