[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877fdjovef.fsf@linux.intel.com>
Date: Tue, 21 Jun 2016 10:26:00 +0300
From: Felipe Balbi <balbi@...nel.org>
To: Peter Chen <hzpeterchen@...il.com>
Cc: Roger Quadros <rogerq@...com>, peter.chen@...escale.com,
tony@...mide.com, gregkh@...uxfoundation.org,
dan.j.williams@...el.com, mathias.nyman@...ux.intel.com,
Joao.Pinto@...opsys.com, sergei.shtylyov@...entembedded.com,
jun.li@...escale.com, grygorii.strashko@...com,
yoshihiro.shimoda.uh@...esas.com, robh@...nel.org, nsekhar@...com,
b-liu@...com, joe@...ches.com, linux-usb@...r.kernel.org,
linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core
Hi,
Peter Chen <hzpeterchen@...il.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
Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)
Powered by blists - more mailing lists