Hi,
Peter Chen <hzpeterchen@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
