Message-ID: <5729B598.5030902@ti.com>
Date:	Wed, 4 May 2016 11:40:56 +0300
From:	Roger Quadros <rogerq@...com>
To:	Jun Li <jun.li@....com>, Peter Chen <hzpeterchen@...il.com>
CC:	"stern@...land.harvard.edu" <stern@...land.harvard.edu>,
	"balbi@...nel.org" <balbi@...nel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"peter.chen@...escale.com" <peter.chen@...escale.com>,
	"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
	"jun.li@...escale.com" <jun.li@...escale.com>,
	"mathias.nyman@...ux.intel.com" <mathias.nyman@...ux.intel.com>,
	"tony@...mide.com" <tony@...mide.com>,
	"Joao.Pinto@...opsys.com" <Joao.Pinto@...opsys.com>,
	"abrestic@...omium.org" <abrestic@...omium.org>,
	"r.baldyga@...sung.com" <r.baldyga@...sung.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>
Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core

On 04/05/16 11:03, Jun Li wrote:
> Hi
> 
>> -----Original Message-----
>> From: Roger Quadros [mailto:rogerq@...com]
>> Sent: Wednesday, May 04, 2016 2:37 PM
>> To: Peter Chen <hzpeterchen@...il.com>
>> Cc: Jun Li <jun.li@....com>; stern@...land.harvard.edu; balbi@...nel.org;
>> gregkh@...uxfoundation.org; peter.chen@...escale.com;
>> dan.j.williams@...el.com; jun.li@...escale.com;
>> mathias.nyman@...ux.intel.com; tony@...mide.com; Joao.Pinto@...opsys.com;
>> abrestic@...omium.org; r.baldyga@...sung.com; linux-usb@...r.kernel.org;
>> linux-kernel@...r.kernel.org; linux-omap@...r.kernel.org
>> Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
>>
>> Peter,
>>
>> On 04/05/16 06:35, Peter Chen wrote:
>>> On Tue, May 03, 2016 at 06:44:46PM +0300, Roger Quadros wrote:
>>>> Hi,
>>>>
>>>> On 03/05/16 10:06, Jun Li wrote:
>>>>> Hi
>>>>>
>>>>>>>>>>>>>  /**
>>>>>>>>>>>>> + * usb_gadget_start - start the usb gadget controller and
>>>>>>>>>>>>> +connect to bus
>>>>>>>>>>>>> + * @gadget: the gadget device to start
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * This is external API for use by OTG core.
>>>>>>>>>>>>> + *
>>>>>>>>>>>>> + * Start the usb device controller and connect to bus
>>>>>>>>>>>>> +(enable
>>>>>> pull).
>>>>>>>>>>>>> + */
>>>>>>>>>>>>> +static int usb_gadget_start(struct usb_gadget *gadget) {
>>>>>>>>>>>>> +	int ret;
>>>>>>>>>>>>> +	struct usb_udc *udc = NULL;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	dev_dbg(&gadget->dev, "%s\n", __func__);
>>>>>>>>>>>>> +	mutex_lock(&udc_lock);
>>>>>>>>>>>>> +	list_for_each_entry(udc, &udc_list, list)
>>>>>>>>>>>>> +		if (udc->gadget == gadget)
>>>>>>>>>>>>> +			goto found;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +	dev_err(gadget->dev.parent, "%s: gadget not
>> registered.\n",
>>>>>>>>>>>>> +		__func__);
>>>>>>>>>>>>> +	mutex_unlock(&udc_lock);
>>>>>>>>>>>>> +	return -EINVAL;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +found:
>>>>>>>>>>>>> +	ret = usb_gadget_udc_start(udc);
>>>>>>>>>>>>> +	if (ret)
>>>>>>>>>>>>> +		dev_err(&udc->dev, "USB Device Controller didn't
>>>>>>>> start: %d\n",
>>>>>>>>>>>>> +			ret);
>>>>>>>>>>>>> +	else
>>>>>>>>>>>>> +		usb_udc_connect_control(udc);
>>>>>>>>>>>>
>>>>>>>>>>>> For drd, it's fine, but for real otg, gadget connect should
>>>>>>>>>>>> be done by
>>>>>>>>>>>> loc_conn() instead of gadget start.
>>>>>>>>>>>
>>>>>>>>>>> It is upto the OTG state machine to call gadget_start() when
>>>>>>>>>>> it needs to connect to the bus (i.e. loc_conn()). I see no
>>>>>>>>>>> point in calling gadget start before.
>>>>>>>>>>>
>>>>>>>>>>> Do you see any issue in doing so?
>>>>>>>>>>
>>>>>>>>>> This is what OTG state machine does:
>>>>>>>>>> case OTG_STATE_B_PERIPHERAL:
>>>>>>>>>>      otg_chrg_vbus(otg, 0);
>>>>>>>>>>      otg_loc_sof(otg, 0);
>>>>>>>>>>      otg_set_protocol(fsm, PROTO_GADGET);
>>>>>>>>>>      otg_loc_conn(otg, 1);
>>>>>>>>>>      break;
>>>>>>>>
>>>>>>>> On second thoughts, after seen the OTG state machine.
>>>>>>>> otg_set_protocol(fsm, PROTO_GADGET); is always followed by
>>>>>>>> otg_loc_conn(otg, 1); And whenever protocol changes to anything
>>>>>>>> other the PROTO_GADGET, we use otg_loc_conn(otg, 0);
>>>>>>>>
>>>>>>>> So otg_loc_conn seems redundant. Can we just get rid of it?
>>>>>>>>
>>>>>>>> usb_gadget_start() implies that gadget controller starts up and
>>>>>>>> enables pull.
>>>>>>>> usb_gadget_stop() implies that gadget controller disables pull
>>>>>>>> and
>>>>>> stops.
>>>>>>>>
>>>>>>>>
>>>>>>>> Can you please explain why just these 2 APIs are not sufficient
>>>>>>>> for full OTG?
>>>>>>>>
>>>>>>>> Do we want anything to happen between gadget controller
>>>>>>>> start/stop and pull on/off?
>>>>>>>
>>>>>>> "loc_conn" is a standard output parameter in OTG spec, it deserves
>>>>>>> a separate api, yes, current implementation of OTG state machine
>>>>>>> code seems allow you to combine the 2 things into one, but don't
>>>>>>> do that, because they do not always happen together, e.g. for
>>>>>>> peripheral only B device (also a part OTG spec: section 7.3), will
>>>>>>> be fixed in gadget mode, but it will do gadget connect and
>>>>>>> disconnect in its diff states, so, to make the framework common,
>> let's keep them separated.
>>>>>>
>>>>>> I'm sorry but I didn't understand your comment about "it will do
>>>>>> gadget connect and disconnect in its diff states"
>>>>>
>>>>> Gadget connect means loc_conn(1).
>>>>>
>>>>>>
>>>>>> I am reading the OTG v2.0 specification and loc_conn is always true
>>>>>> when b_peripheral or a_peripheral is true and false otherwise.
>>>>>
>>>>> If you only talk about these 2 states, yes, loc_conn is ture.
>>>>>
>>>>>>
>>>>>> loc_conn is just an internal state variable and it corresponds to
>>>>>> our
>>>>>> gadget_start/stop() state.
>>>>>
>>>>> It's not an internal variable, there are OTG state machine
>>>>> parameters tables(table 7-x) in OTG spec which have clear lists
>>>>> which are "internal variable", which are "input", which are "output"...
>>>>>
>>>>> Those APIs are driven directly from OTG spec, easily understood so
>>>>> code reader can know what's those APIs for. For real OTG, I don't
>>>>> see the benefit if get rid of it.
>>>>
>>>> OK, no issues if we don't get rid of it. But I am still in favor of
>>>> doing a connect in usb_gadget_start(), because
>>>>
>>>> 1) If we split connect/disconnect() and usb_gadget_start/stop() then
>>>> there is additional overhead of keeping track whether connect was
>>>> called or not during usb_gadget_stop(). Plus we need to take care
>>>> that users don't call connect/disconnect outside of start/stop. It is
>> just complicating things.
>>>>
>>>> 2) for many controllers there is no difference between run/stop and
>>>> connect/disconnect. i.e. a single register bit controls both.
>>>>
>>>> 3) it fits well with the OTG specification. OTG specification says
>>>> that loc_conn *variable* must be true *after* the device has signalled
>> a connect.
>>>> So OTG state machine can safely set loc_conn variable to true after
>>>> doing otg_set_protocol(fsm, PROTO_GADGET); and set it to false
>> otherwise.
>>>>
>>>> Note, OTG specification does not say to take any action based on
>> loc_conn.
>>>> It is just a connect indicator variable. So we might have to fix this
>>>> in the OTG state machine.
>>>>
>>>> My suggestion is to keep it simple for now. Try the OTG
>>>> implementation, and later if we find issues then extend it as required.
>>>>
>>>
>>> Just talked with Jun, he is worried if loc_conn != pullup_dp at some
>>> situations. So, how about only calling start gadget at
>>> usb_start_gadget,
>>
>> Which situations?
> 
> When to pull-up DP is decided by application (while vbus is on),
> not only by driver state machine.

So when OTG state is B_PERIPHERAL or A_PERIPHERAL we still want DP pull-up
to be disabled?

> 
>>
>>> and pullup_dp at drd_set_state (see below).
>>>
>>>
>>> static void drd_set_state(struct otg_fsm *fsm, enum usb_otg_state
>>> new_state) {
>>> 	struct usb_otg *otg = container_of(fsm, struct usb_otg, fsm);
>>>
>>> 	if (otg->state == new_state)
>>> 		return;
>>>
>>> 	fsm->state_changed = 1;
>>> 	dev_dbg(otg->dev, "otg: set state: %s\n",
>>> 		usb_otg_state_string(new_state));
>>> 	switch (new_state) {
>>> 	case OTG_STATE_B_IDLE:
>>> +		usb_udc_vbus_handler(gadget, false);
>>
>> This is redundant, When we switch from PROTO_GADGET to PROTO_UNDEF we do a
>> usb_gadget_stop(), and a usb_gadget_disconnect() is done there.
>>
>>> 		drd_set_protocol(fsm, PROTO_UNDEF);
>>> 		otg_drv_vbus(otg, 0);
>>> 		break;
>>> 	case OTG_STATE_B_PERIPHERAL:
>>> 		drd_set_protocol(fsm, PROTO_GADGET);
>>> +		usb_udc_vbus_handler(gadget, true);
>>
>> This is redundant as well since usb_gadget_start() is doing a
>> usb_gadget_connect().
>>
>>> 		otg_drv_vbus(otg, 0);
>>> 		break;
>>> 	......
>>> 	};
>>>
>>> }
>>>
>>> When the OTG FSM is added to this framework, it can keep
>>> usb_fsm->ops->loc_conn, and using the current FSM.
>>>
>>
>> I have no strong opinions for or against usb_fsm->ops->loc_conn.
>> Although strictly speaking, we shouldn't take any action based on loc_conn.
> 
> Strictly speaking(OTG spec), all you does is for loc_conn, but you think
> it's start_gadget.
> 
>> It is just a state variable indicator.
> 
> Nobody check this "indicator".
> 
> Of cos, this is not a big deal, you can define the new API as is,
> do udc_start() + gadget_connect() in one shot, it's up to user to
> decide if use your usb_otg_start_gadget(), in case of udc_start()
> followed by gadget_connect() is not wanted, user can/need do udc_start()
> and something else before do gadget_connect.

Please don't get me wrong. I want the full OTG state machine to be able
to use usb_otg_start/stop_gadget().

Just trying to understand the real problem.

cheers,
-roger

Powered by blists - more mailing lists