Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753778AbcD1JzV (ORCPT ); Thu, 28 Apr 2016 05:55:21 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:38322 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753422AbcD1JzS (ORCPT ); Thu, 28 Apr 2016 05:55:18 -0400 Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core To: Jun Li , "stern@rowland.harvard.edu" , "balbi@kernel.org" , "gregkh@linuxfoundation.org" , "peter.chen@freescale.com" References: <1459865117-7032-1-git-send-email-rogerq@ti.com> <1459865117-7032-10-git-send-email-rogerq@ti.com> <571E23D7.5070501@ti.com> <5720A106.1030702@ti.com> CC: "dan.j.williams@intel.com" , "jun.li@freescale.com" , "mathias.nyman@linux.intel.com" , "tony@atomide.com" , "Joao.Pinto@synopsys.com" , "abrestic@chromium.org" , "r.baldyga@samsung.com" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-omap@vger.kernel.org" From: Roger Quadros Message-ID: <5721DDE5.7060708@ti.com> Date: Thu, 28 Apr 2016 12:54:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5720A106.1030702@ti.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4901 Lines: 161 Hi, On 27/04/16 14:22, Roger Quadros wrote: > On 26/04/16 03:07, Jun Li wrote: >> Hi >> >>> -----Original Message----- >>> From: Roger Quadros [mailto:rogerq@ti.com] >>> Sent: Monday, April 25, 2016 10:04 PM >>> To: Jun Li ; stern@rowland.harvard.edu; balbi@kernel.org; >>> gregkh@linuxfoundation.org; peter.chen@freescale.com >>> Cc: dan.j.williams@intel.com; jun.li@freescale.com; >>> mathias.nyman@linux.intel.com; tony@atomide.com; Joao.Pinto@synopsys.com; >>> abrestic@chromium.org; r.baldyga@samsung.com; linux-usb@vger.kernel.org; >>> linux-kernel@vger.kernel.org; linux-omap@vger.kernel.org >>> Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core >>> >>> Hi, >>> >>> On 21/04/16 09:38, 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? cheers, -roger >> >> You intend to abstract something common in this api when start gadget, >> which should be called by otg_set_protocol(fsm, PROTO_GADGET); and >> drd_set_protocol(fsm, PROTO_GADGET); right? >> >> So you may move usb_udc_connect_control(IMO usb_gadget_connect() >> is better)out of usb_gadget_start(), then for drd: >> >> case OTG_STATE_B_PERIPHERAL: >> drd_set_protocol(fsm, PROTO_GADGET); >> otg_drv_vbus(otg, 0); >> usb_gadget_connect(); > > OK. I understand now. I'll implement your suggestion. Thanks. > > cheers, > -roger > >>>> >>>>> + >>>>> + mutex_unlock(&udc_lock); >>>>> + >>>>> + return ret; >>>>> +} >>>>> + >>>>> +/** >>>>> + * usb_gadget_stop - disconnect from bus and stop the usb gadget >>>>> + * @gadget: The gadget device we want to stop >>>>> + * >>>>> + * This is external API for use by OTG core. >>>>> + * >>>>> + * Disconnect from the bus (disable pull) and stop the >>>>> + * gadget controller. >>>>> + */ >>>>> +static int usb_gadget_stop(struct usb_gadget *gadget) { >>>>> + 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: >>>>> + usb_gadget_disconnect(udc->gadget); >>>> >>>> Likewise, gadget disconnect also should be done by loc_conn() instead >>>> of gadget stop. >>>> >>>>> + udc->driver->disconnect(udc->gadget); >>>>> + usb_gadget_udc_stop(udc); >>>>> + mutex_unlock(&udc_lock); >>>>> + >>>>> + return 0; >>>>> +} >>>>> + >>>> >>>> Li Jun >>>> > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >