Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752174AbbGMRoX (ORCPT ); Mon, 13 Jul 2015 13:44:23 -0400 Received: from relmlor2.renesas.com ([210.160.252.172]:12169 "EHLO relmlie1.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751917AbbGMRoU convert rfc822-to-8bit (ORCPT ); Mon, 13 Jul 2015 13:44:20 -0400 X-IronPort-AV: E=Sophos;i="5.15,463,1432566000"; d="scan'208";a="191425851" From: Phil Edworthy To: Sergei Shtylyov , "Kishon Vijay Abraham I" CC: Rob Herring , Pawel Moll , "Mark Rutland" , Ian Campbell , Kumar Gala , Yoshihiro Shimoda , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-usb@vger.kernel.org" , "linux-sh@vger.kernel.org" Subject: RE: [PATCH v3] phy: rcar-gen2 usb: Add Host/Function switching for USB0 Thread-Topic: [PATCH v3] phy: rcar-gen2 usb: Add Host/Function switching for USB0 Thread-Index: AQHQuKwjcYvjF2RvDkeFG+0NoRt2Cp3U67UAgAQ2M3CAABbzAIAASK4AgAAhc4CAAAC1AIAACFwAgAAGwcA= Date: Mon, 13 Jul 2015 17:44:09 +0000 Message-ID: References: <1436270121-25924-1-git-send-email-phil.edworthy@renesas.com> <559FF47A.5000001@cogentembedded.com> <55A39030.1030601@cogentembedded.com> <55A3E937.2050804@cogentembedded.com> <55A3F0D2.2080908@cogentembedded.com> In-Reply-To: <55A3F0D2.2080908@cogentembedded.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cogentembedded.com; dkim=none (message not signed) header.d=none; x-originating-ip: [193.141.220.21] x-microsoft-exchange-diagnostics: 1;SIXPR06MB0924;5:3aQfYqkF1ioBrQ7dSq8P6h7wEzAjMOmwP35WfUyj+hP2QFWK9p959a8Za6ZKtJgKLVRvUvdE8U/fh2A6xydFsDsxBhSd+lIj1mthEsQuEsMt04BuOy8UXi+t8meM+RQLy9lXjJdaGGokIkdYpBcJjg==;24:3Wy0PEDvDm7HYyVgZmDX0lIccGETwNK8FazLIHRezEIk8+Ydsv6ymEtD0PkrsN5ZC3Qyu4Jw6cY2tzfn9xgu4/szkT/I9MScWUqtp+TouME=;20:NQ1PToKE9WXmCpgot7AnKvvYvQtRSz4S9dQS1HCLHg1vzLHwKfHRaWU6S8aaV6QQ5fSpfTcN+VBxCWqpfQeCComN2ZbgoV5mmmVTzFJQxS9IcBhxBBRN6ouSHInB0evKawE8rqJweZ6OPnuGPdCUYEhQ2kEuGOrJvREz0TQx5eA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SIXPR06MB0924; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:SIXPR06MB0924;BCL:0;PCL:0;RULEID:;SRVR:SIXPR06MB0924; x-forefront-prvs: 0636271852 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(24454002)(51704005)(479174004)(377454003)(76576001)(86362001)(74316001)(66066001)(5001960100002)(2950100001)(40100003)(106116001)(46102003)(102836002)(189998001)(92566002)(122556002)(33656002)(2900100001)(93886004)(5002640100001)(77096005)(76176999)(2656002)(87936001)(5003600100002)(54356999)(77156002)(62966003)(50986999);DIR:OUT;SFP:1102;SCL:1;SRVR:SIXPR06MB0924;H:SIXPR06MB0639.apcprd06.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: renesas.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2015 17:44:09.2802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a X-MS-Exchange-Transport-CrossTenantHeadersStamped: SIXPR06MB0924 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3415 Lines: 86 Hi Sergei, On 13 July 2015 18:10, Sergei wrote: > On 07/13/2015 07:55 PM, Phil Edworthy wrote: > > >>>>>>> Instead of statically selecting the PHY connection to either the > >>>>>>> USBHS (Function) or PCI0 (Host) IP blocks, this change allows the > >>>>>>> dts to specifiy gpio pins for the vbus and id signals. Additional > > >>>>>> These GPIOs don't have anything to do with the PHY, they're > interfacing > > >>>> Perhaps that was too strong statement but nevertheless... > > >>> Looking at your MAX3355 extcon driver, I can't see how it would work on it's > >>> own. > > >> I've added the 'extcon' support into the Renesas USBHS driver, so that it > >> should be able to sense the ID pin status. > > >>> The system needs to sense vbus in order to determine that the board > >>> has been plugged into a USB Host. Ok, so in summary, the max3355 device has two ways to communicate vbus back to a processor. You can either use the vbus signal or the status1/2 signals connected as gpios. The status1/2 signals give HNP information for OTG and are preferred, but depending on the board, they might not be available. > >>> My intention is to make the USB PHY driver listen for extcon events instead > >>> of directly accessing the ID and VBUS signals, but otherwise behave in the > >>> same way it currently does. > > >> I'm not sure the PHY driver should be interested in that... > > > Then how is the PHY going to know when to switch between pci0 (host) and > > hsusb (function)? > > As I said, I planted the extcon hooks directly into USBHS (merged patch) > and USB HCD code (unmerged, low quality hack). Unless I am missing something, the problem I see with this is that it will not dynamically switch between Host and Gadget, hence my suggestion that the USB PHY driver be interested in the extcon events. > >>> After reading some other threads, I also intend to set up a fixed regulator > >>> for the MAX3355 device to setup the shutdown and vbus enable pins. I > know > >>> that the vbus enable should really be controlled some other way depending > >>> on the role, but for the moment I think it's ok just to enable it always. > > >> It's OK only in the host mode. > >> I don't think we need regulators. SHDN- is already supported by the driver > >> (though it only drives it high at start-up time), in fact it was the only reason > >> not to use gpio. > > >>> Do you think that is the correct way to progress this? > > >> I didn't have a clear picture how to implement the OTG support at the time > >> of writing the MAX3355 driver; actually, I was tasked to only support ID p[in > >> sensing. > > > Right, so the max3355 driver needs some changes to include vbus handling. > > Are you working on this, or should I take it on? > > No, not working yet, I have other things on my plate still... Ok, thanks for your comments! Hopefully I'll find the time to have a stab at this. > >> Note that there's some ongoing effort now on linux-usb to support OTG > >> functionality. > > > Yes, I need to spend some time reading that list! > > > Thanks > > Phil > > WBR, Sergei Thanks Phil -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/