From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752883AbbGNCI4 (ORCPT ); Mon, 13 Jul 2015 22:08:56 -0400 Received: from mail-by2on0135.outbound.protection.outlook.com ([207.46.100.135]:38240 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752179AbbGNCIy (ORCPT ); Mon, 13 Jul 2015 22:08:54 -0400 Authentication-Results: spf=fail (sender IP is 192.88.158.2) smtp.mailfrom=freescale.com; vger.kernel.org; dkim=none (message not signed) header.d=none; Date: Tue, 14 Jul 2015 08:59:44 +0800 From: Peter Chen To: Andrew Bresticker CC: Roger Quadros , Alan Stern , Felipe Balbi , Greg Kroah-Hartman , Dan Williams , , "Mathias Nyman" , , , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , , "linux-tegra@vger.kernel.org" Subject: Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality Message-ID: <20150714005942.GB31197@shlinux2> References: <1436350777-28056-1-git-send-email-rogerq@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1BFFO11OLC001;1:nRukWXV9peKCq3iBzVUlZPDuMQPWy0FDnW52O/F/rD4vcoL5RJIhwoeWmN8Fxt0N4sPMnkickZoXiZQfla+OEWDZnCo2qVyUnLnjRXEZakaxXanQnNXV3QaIIACLWle5V5k7bQm7E4+kgPK2L6jgGSEDXBDC1BLHwyzM8VBwaOBG4fO1fvjLHatQqxc41SWmHhnJRVO0W6q1+gl+1Yb88KBj80l6aIxqJsTkuX2rELUufn696KYgR968ZwNNUpO2xoRYrXB+7ba0VOt7ls1O1VHT7rqwWVu8YNfqMHI895L4gqQJv5FUQP39ExDPX6TgvcX/KAfUBwtwtc+89oGeBVCcYERAqE2GxlihCMNGH0xrCmoiVls5Akh8XDMplEwntEYKskYrMxHk6316YglA558bJTMBlEKQHz2QH3F5nS9u1fEp9bO/luzOWrRRDBJ+M/bUou6ttNO1kU3pEJofDQ== X-Forefront-Antispam-Report: CIP:192.88.158.2;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(1060300003)(2980300002)(339900001)(51704005)(377454003)(189002)(24454002)(164054003)(76104003)(199003)(4290100001)(33656002)(561944003)(110136002)(77156002)(86362001)(105606002)(2950100001)(77096005)(87936001)(5001960100002)(97756001)(83506001)(23726002)(46406003)(47776003)(62966003)(4001350100001)(92566002)(50986999)(85426001)(50466002)(19580405001)(106466001)(46102003)(6806004)(19580395003)(110436001)(104016003)(54356999)(33716001)(76176999);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR0301MB1220;H:az84smr01.freescale.net;FPR:;SPF:Fail;MLV:sfv;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;BN3PR0301MB1220;2:8I6kSyE/LEW5kPEj6taa+CQQJ5XdyvVfyBZF9/wc0kRaIbfXP+5Sn+6cvOt8BryL;3:OND63A2BIXCOgwnIQYpqzTEUVQQkW2b4QjOIemXjX6ME78MLAexzXROiy50+jDNKIq4dcnSQVov/V/2d4ITNu2H0kv7IucioOHGN2nScOHoifINZmg/gtfZtpu9d3VJHCtH4mBkndThCdiZNbUsXTdvp2VKNkziA6SD5LVmdkMmFNcW5D2DYykJA/qSXV8o/6k8Qn6duFy25efTFOgWx3zEv8WFeiKcFAHCX13ldRbM=;25:kl3VNMnoExz6hZ9uoQ76cg/7HXppilFkzy2TXdjCkhMLA6OqzKboALUiUMgSLezmO9ci2cyOheHHZHC+edW22stFt1DX4RVnYLK1dYFV39hACXYBQFh7gCZ7bWsymCavcJh9jpkBrLPjQ4nYY6SMJKvQV1FZASGePzEtC0JKKBIdw+oPsAKvOsAYXSrYR+8iJrJHiEhy8ZAoEWgc+38QJrkBL3mlsfakCCZDotlJt5ojdWQV2L4wabeFvD0TGBrTyN7GD2AX0gzFA5wrW5k4Mg==;20:1s0sAngaLSmSTwLNBIQd8wz3ad1b/2bLQqTXsPmNrPNnpLqiOdoKCnURptkwjyvtJC3qgCUyRlpVgtm6dLVf7CJrJoTktB0i5Bl6NxImrOqrCUUaO3CPjzoZTKGns6iZRXOQCc83hglu8aq0lrZFlQAfVksd1Zwar8kBWu52fjamcQvGWBOPtWbz5czSqRUvAB8qOCPQyLpoD7vXmjN8O5aicD8wsPZWYTHUTKGbHHaXdhJEm7D6YAYCYL5Rel0nPTdGcEXNQJtFMG1IYHcJ5czfeAeQbpawDiER8aT1wNM+SAKCOBOcfsdXNbotDit9iAM9hZJB5Xz6qitEedXrF6jdMStf6Do4acOhn5rqmGQ= X-Microsoft-Antispam: UriScan:;BCL:1;PCL:0;RULEID:;SRVR:BN3PR0301MB1220; BN3PR0301MB1220: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:1;PCL:0;RULEID:(601004)(5005006)(1201001)(3002001);SRVR:BN3PR0301MB1220;BCL:1;PCL:0;RULEID:;SRVR:BN3PR0301MB1220; X-Microsoft-Exchange-Diagnostics: 1;BN3PR0301MB1220;4:9A8ElLUEZ8xnMDTxf/qIGpdsaTwS1CSNX8QQTCznMjxnnMftJwYTSTlZqu0BFENoAhysR/VZ1ZsTVF/aNmXmYvFF/0/1nJa/12OYbl7x3Hopmc/8cMfzGSZTIUtbcQ1WY/9zMQzjFcOKXO+nT03x7KH1ddXfbh54jYu2X27bremmez2Xi6C5PNzDI5573JLDsOn054d4nKOJMxz/U4DXtdaP80qz3y6Xpu6i1kt18tpn2kQv1ncUYZS+qvHw+vb7eAGjwXdpwpNCTGKKL25Cir+3C7Q4yMr4oJ61qTWGyoUl7qWQHt85VNIBiAiMuOYB X-Forefront-PRVS: 0637FCE711 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BN3PR0301MB1220;23:o0R742yzsHosssAQKTb6l4DwHQh3hsagLBWAykq?= =?us-ascii?Q?Em/+JmajgE4yt/dr/7rptesoj6AWltfGOt71jMhZzI5zccTkiKLTOsu1nQ54?= =?us-ascii?Q?M8M/t9gYAOucT4H4Ht2PLhTdXc6egInmTb0+dI6H3VxZVCZfr505KHE5HVkK?= =?us-ascii?Q?t/E/EToiFbllHDhClXKOkY/rWCaiMzGiiSUZ6hu3ZLci6PR4u8Ne9yQHDPoU?= =?us-ascii?Q?DMXXnSNs01Odw52ynMhVrDeLj3Tvps9nbn4YcUB8CuU1vou1aifh/vaIt8Kz?= =?us-ascii?Q?0LivlLs4Oe8/pPxXK+J79pn+pf1xZD/YX9UwREO3RJvr+Y8HocMJWmsQIz70?= =?us-ascii?Q?AyPY/e+iQxoXT0JbTTAZTVg/l3tgm0y2Zr2GVWFaORUODhYpTq0YqsZqedaU?= =?us-ascii?Q?+WaUd4v4aYzULtYaL/ezuiRQPOk83p/9ZJrWdng2KSboY2zMdrSPwl7SDpWN?= =?us-ascii?Q?lb+gxUZKTwoEjD0WFUqKYPhwhszT4h0cdIHs/yBdfomttnKw3MdX1U4wEhXu?= =?us-ascii?Q?qOPKlpu7XxRu1bXtNUNq1dFe985esfX/BVTBSUsBkbqiao5LrI37B3YrnUyk?= =?us-ascii?Q?AYwi5tf4iG4Z7Rtgrnw/8GEbOn7800mezVs33n6AQ6U+WPWG9PCKPrW6FNq0?= =?us-ascii?Q?ifWnHOM8HYQdlceAziSJZG38antS3kle4/0t106gOJGFoP5u5hQ57xfEgcW/?= =?us-ascii?Q?2XJzfncBLLtSoTG08BWpF9iMUC1JQnLpR5m30LPFOX+ihcKHfiGOBuAvoP1z?= =?us-ascii?Q?VJ917reTyy/SzC8hB4b4Kuaj/JOFkPs4Z4gPKOfk7rW+UaOD7BzQGiS9zqms?= =?us-ascii?Q?jav7xWppS2Mshqc4NJ9WictoxwqK7nfGI7I4VjPg5HrRGh4vhBmm4F1LZMCB?= =?us-ascii?Q?8YpwSr+XXDJeuKatNcqfwqnYT7LYeRlSocZVbCxY9nt+mkkoqODGA3RGW+4Z?= =?us-ascii?Q?t4kTl9/fpTzht+VaDBnpogQQEAPnMGj95J9sq8vODhT8xScu3smOqgU8pVUp?= =?us-ascii?Q?R1Z3xneOUH4xRGkW/RRB4R/Bnvt24rz1n7kOOmmvqkZemSETQKPCaklka8ZF?= =?us-ascii?Q?Dfz6zuOIBG4O4N8WPFn0snO1vfGTl43FyEhNCJuQrKADioMEwY0iNjRnY6gf?= =?us-ascii?Q?EtZashszZ41o=3D?= X-Microsoft-Exchange-Diagnostics: 1;BN3PR0301MB1220;5:ib2qjqy8EpHNkpkFoYObzAyU3nzXrt//n8/N5wMzFlONwBBx97jyyA3i4fND5Eimv+V72WInAe1v0YWEJhWfSQ6kSWDQ/lq5sx+VQGl42qgRmSMx6IuNQfh2nDc10Tqgwn92YTHoUW36vFQ9hGb0hw==;24:cjYXp2r5QFGGhBboW3uxvqwsxssaVMNlhepT0oGbM8YvGk0BrDiwA5zh8N/2dzuJp7BLgLQ3HXb2gAMNuOUYFJdcalWAABhmGHC/VoDMo80=;20:JWXSM2nxgIk9MlKEOmH6zTNkGGZPu7ItZf5w+ytedIjonnJWRzrVpOrS+O+ztcP+jurjDMOARUFbWlpFf2ndHg== X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2015 02:08:50.5688 (UTC) X-MS-Exchange-CrossTenant-Id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=710a03f5-10f6-4d38-9ff4-a80b81da590d;Ip=[192.88.158.2];Helo=[az84smr01.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1220 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 13, 2015 at 12:14:43PM -0700, 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. Hi Andrew, I think your problem is how to add your core driver to manage device and host functionality together, and once you find how (through padctl/type-c controller) to do it based on current code, it will be clear how to use roger proposal framework at that time. Most of current core drivers, we use extcon driver (through gpio) or USB vbus/id pin (through internal registers) to manager roles. > > 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? > > Thanks, > Andrew -- Best Regards, Peter Chen From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Chen Subject: Re: [PATCH v3 00/11] USB: OTG/DRD Core functionality Date: Tue, 14 Jul 2015 08:59:44 +0800 Message-ID: <20150714005942.GB31197@shlinux2> References: <1436350777-28056-1-git-send-email-rogerq@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andrew Bresticker Cc: Roger Quadros , Alan Stern , Felipe Balbi , Greg Kroah-Hartman , Dan Williams , jun.li@freescale.com, Mathias Nyman , tony@atomide.com, Joao.Pinto@synopsys.com, "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , linux-omap@vger.kernel.org, "linux-tegra@vger.kernel.org" List-Id: linux-omap@vger.kernel.org On Mon, Jul 13, 2015 at 12:14:43PM -0700, 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. Hi Andrew, I think your problem is how to add your core driver to manage device and host functionality together, and once you find how (through padctl/type-c controller) to do it based on current code, it will be clear how to use roger proposal framework at that time. Most of current core drivers, we use extcon driver (through gpio) or USB vbus/id pin (through internal registers) to manager roles. > > 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? > > Thanks, > Andrew -- Best Regards, Peter Chen