Re: [RFC][PATCH 2/9] usb: gadget: add usb_gadget_start/stop()
From: Roger Quadros
Date: Fri Mar 20 2015 - 05:46:55 EST
On 20/03/15 09:18, Peter Chen wrote:
> On Thu, Mar 19, 2015 at 04:50:31PM +0200, Roger Quadros wrote:
>> On 19/03/15 16:09, Li Jun wrote:
>>> On Thu, Mar 19, 2015 at 12:14:39PM +0200, Roger Quadros wrote:
>>>> On 19/03/15 05:30, Peter Chen wrote:
>>>>> On Wed, Mar 18, 2015 at 03:55:56PM +0200, Roger Quadros wrote:
>>>>>> The OTG state machine needs a mechanism to start and
>>>>>> stop the gadget controller. Add usb_gadget_start()
>>>>>> and usb_gadget_stop().
>>>>>>
>>>>>> Signed-off-by: Roger Quadros <rogerq@xxxxxx>
>>>>>> ---
>>>>>> drivers/usb/gadget/udc/udc-core.c | 166 +++++++++++++++++++++++++++++++++++---
>>>>>> include/linux/usb/gadget.h | 3 +
>>>>>> 2 files changed, 158 insertions(+), 11 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/usb/gadget/udc/udc-core.c b/drivers/usb/gadget/udc/udc-core.c
>>>>>> index 5a81cb0..69b4123 100644
>>>>>> --- a/drivers/usb/gadget/udc/udc-core.c
>>>>>> +++ b/drivers/usb/gadget/udc/udc-core.c
>>>>>> @@ -35,6 +35,8 @@
>>>>>> * @dev - the child device to the actual controller
>>>>>> * @gadget - the gadget. For use by the class code
>>>>>> * @list - for use by the udc class driver
>>>>>> + * @running - udc is running
>>>>>
>>>>> Doesn't OTG FSM should know it?
>>>>
>>>> Not really, as the gadget driver might not have been loaded yet or userspace might
>>>> have disabled softconnect when the OTG FSM wants UDC to start.
>>>>
>>>> So only UDC knows if it has really started or not based on this flag.
>>>>
>>>
>>> why this can not be known by check the otg fsm state? i.e. if the device in
>>> b_peripheral or a_peripheral state, udc should had started, isn't it?
>>
>> If gadget function driver (which is different from UDC driver) is not yet loaded
>> then we can't start UDC even if otg fsm is in b_peripheral.
>> Also, if userspace has disabled softconnect we can't start UDC.
>>
>> So, b_peripheral != UDC_started.
>>
>> I've tried to address this issue by adding the checks in usb_gadget_start().
>>
>
> Ok, maybe we have different understanding for 'B-Device' at software,
> In spec, it says the Micro-AB receptacle with nothing connected can be
> 'B-Device', but in fact, we may not enable device mode before loading
> gadget driver, in chipidea fsm design, if the gadget driver is not
> loaded, the FSM will not start, and it is at OTG_STATE_UNDEFINED.
Right. I mixed up into thinking that we should respect the softconnect
while in OTG mode. It seems that we should ignore it.
>
> One more thing is we may need to find a place to issue SRP when we
> load gadget driver, since we may at b_idle at that time due to host
> closes the vbus (timeout for a_wait_bcon).
Issuing SRP should be done by the otg-fsm and not udc-core.
The udc-core can at the least call usb_otg_kick_fsm() after setting the gadget
driver so that otg-fsm knows that we now have a valid gadget and can take
necessary action. i.e. change from b_idle to b_srp_init and then to b_peripheral.
>
> What is the "softconnect" used for? In otg fsm, we use b_bus_req for FSM.
>
I understand now that we shouldn't bother with softconnect when we are in OTG fsm mode.
That solves our problem with the running flags.
So now, b_peripheral == UDC_started.
I will address this in v2.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/