From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755375AbbGPSaD (ORCPT ); Thu, 16 Jul 2015 14:30:03 -0400 Received: from mail-qg0-f50.google.com ([209.85.192.50]:36317 "EHLO mail-qg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753140AbbGPS37 (ORCPT ); Thu, 16 Jul 2015 14:29:59 -0400 MIME-Version: 1.0 In-Reply-To: <55A65F98.203@ti.com> References: <1436350777-28056-1-git-send-email-rogerq@ti.com> <55A65F98.203@ti.com> Date: Thu, 16 Jul 2015 11:29:58 -0700 X-Google-Sender-Auth: LCPdpd-spa1THw4Ljl1YmST4y_Y Message-ID: Subject: Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality From: Andrew Bresticker To: Roger Quadros Cc: Alan Stern , Felipe Balbi , Greg Kroah-Hartman , Peter Chen , Dan Williams , jun.li@freescale.com, Mathias Nyman , Tony Lindgren , Joao.Pinto@synopsys.com, "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-omap@vger.kernel.org, "linux-tegra@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Roger, On Wed, Jul 15, 2015 at 6:26 AM, Roger Quadros wrote: > Hi Andrew, > > On 13/07/15 22:14, Andrew Bresticker wrote: >> Hi Roger, >> >> On Wed, Jul 8, 2015 at 3:19 AM, Roger Quadros wrote: >>> Usage model: >>> ----------- >>> >>> - The OTG controller device is assumed to be the parent of >>> the host and gadget controller. It must call usb_otg_register() >>> before populating the host and gadget devices so that the OTG >>> core is aware that it is an OTG device before the host & gadget >>> register. The OTG controller must provide struct otg_fsm_ops * >>> which will be called by the OTG core depending on OTG bus state. >> >> I'm wondering if the requirement that the OTG controller be the parent >> of the USB host/device-controllers makes sense. For some context, I'm >> working on adding dual-role support for Tegra210, specifically on a >> system with USB Type-C. On Tegra, the USB host-controller and USB >> device-controller are two separate IP blocks (XUSB host and XUSB >> device) with another, separate, IP block (XUSB padctl) for the USB PHY >> and OTG support. In the non-Type-C case, your OTG framework could >> work well, though it's debatable as to whether or not the XUSB padctl >> device should be a parent to the XUSB host/device-controller devices >> (currently it isn't - it's just a PHY provider). But in the Type-C >> case, it's an off-chip embedded controller that determines the >> dual-role status of the Type-C port, so the above requirement doesn't >> make sense at all. >> >> My idea was to have the OTG/DRD controller explicitly specify its host >> and device controllers, so in DT, something like: >> >> otg-controller { >> ... >> device-controller = <&usb_device>; >> host-controller = <&usb_host>; >> ... >> }; >> >> usb_device: usb-device@.... { >> ... >> }; >> >> usb_host: usb-host@... { >> ... >> }; >> >> What do you think? > > I agree that we need to support your use case but how to do it > is not yet clear to me. > > In your above example the otg controller knows what are the host > and gadget controllers but the host/gadget devices don't > know who is their otg controller. > > So the problem is that when usb_otg_register_hcd/gadget() is called > we need to get a handle to the otg controller. > > One solution I see is to iterate over the registered otg_controller_list > and check if we match the host/gadget controller in there. > > Then there is also a possibility that host/gadget controllers get > registered before the OTG controller. Then we can't know for sure if > the host/gadget controller was meant for dual-role operation or not > and it will resort to single role operation. > > Any idea to prevent the above situation? > > Maybe we need to add some logic in host/gadget cores to check if the port > is meant for dual-role use and defer probe if OTG controller is not yet > registered? In the DT case, I think we could add an "otg-controller" property to the host and gadget nodes, and in usb_otg_register_{hcd,gadget}() check for that property and defer probe if the referenced OTG controller has not yet been registered. Not sure how to indicate that a host/gadget is meant for dual-role operation on non-DT platforms though. Thanks, Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Bresticker Subject: Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality Date: Thu, 16 Jul 2015 11:29:58 -0700 Message-ID: References: <1436350777-28056-1-git-send-email-rogerq@ti.com> <55A65F98.203@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <55A65F98.203-l0cyMroinI0@public.gmane.org> Sender: linux-tegra-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Roger Quadros Cc: Alan Stern , Felipe Balbi , Greg Kroah-Hartman , Peter Chen , Dan Williams , jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org, Mathias Nyman , Tony Lindgren , Joao.Pinto-HKixBCOQz3hWk0Htik3J/w@public.gmane.org, "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-omap@vger.kernel.org Hi Roger, On Wed, Jul 15, 2015 at 6:26 AM, Roger Quadros wrote: > Hi Andrew, > > On 13/07/15 22:14, Andrew Bresticker wrote: >> Hi Roger, >> >> On Wed, Jul 8, 2015 at 3:19 AM, Roger Quadros wrote: >>> Usage model: >>> ----------- >>> >>> - The OTG controller device is assumed to be the parent of >>> the host and gadget controller. It must call usb_otg_register() >>> before populating the host and gadget devices so that the OTG >>> core is aware that it is an OTG device before the host & gadget >>> register. The OTG controller must provide struct otg_fsm_ops * >>> which will be called by the OTG core depending on OTG bus state. >> >> I'm wondering if the requirement that the OTG controller be the parent >> of the USB host/device-controllers makes sense. For some context, I'm >> working on adding dual-role support for Tegra210, specifically on a >> system with USB Type-C. On Tegra, the USB host-controller and USB >> device-controller are two separate IP blocks (XUSB host and XUSB >> device) with another, separate, IP block (XUSB padctl) for the USB PHY >> and OTG support. In the non-Type-C case, your OTG framework could >> work well, though it's debatable as to whether or not the XUSB padctl >> device should be a parent to the XUSB host/device-controller devices >> (currently it isn't - it's just a PHY provider). But in the Type-C >> case, it's an off-chip embedded controller that determines the >> dual-role status of the Type-C port, so the above requirement doesn't >> make sense at all. >> >> My idea was to have the OTG/DRD controller explicitly specify its host >> and device controllers, so in DT, something like: >> >> otg-controller { >> ... >> device-controller = <&usb_device>; >> host-controller = <&usb_host>; >> ... >> }; >> >> usb_device: usb-device@.... { >> ... >> }; >> >> usb_host: usb-host@... { >> ... >> }; >> >> What do you think? > > I agree that we need to support your use case but how to do it > is not yet clear to me. > > In your above example the otg controller knows what are the host > and gadget controllers but the host/gadget devices don't > know who is their otg controller. > > So the problem is that when usb_otg_register_hcd/gadget() is called > we need to get a handle to the otg controller. > > One solution I see is to iterate over the registered otg_controller_list > and check if we match the host/gadget controller in there. > > Then there is also a possibility that host/gadget controllers get > registered before the OTG controller. Then we can't know for sure if > the host/gadget controller was meant for dual-role operation or not > and it will resort to single role operation. > > Any idea to prevent the above situation? > > Maybe we need to add some logic in host/gadget cores to check if the port > is meant for dual-role use and defer probe if OTG controller is not yet > registered? In the DT case, I think we could add an "otg-controller" property to the host and gadget nodes, and in usb_otg_register_{hcd,gadget}() check for that property and defer probe if the referenced OTG controller has not yet been registered. Not sure how to indicate that a host/gadget is meant for dual-role operation on non-DT platforms though. Thanks, Andrew