Re: [RFC][PATCH 2/9] usb: gadget: add usb_gadget_start/stop()

[Roger Quadros]

On 20/03/15 11:46, Roger Quadros wrote:
> 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.

To clarify further. Is it right to assume that OTG FSM will not be started till
both gadget UDC driver _AND_ gadget function driver are loaded?

And it will be stopped when either of them unloads.

This simplifies things a lot.

cheers,
-roger

> 
>>
>> 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-usb" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
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/