Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752743Ab3IROWZ (ORCPT ); Wed, 18 Sep 2013 10:22:25 -0400 Received: from bear.ext.ti.com ([192.94.94.41]:42772 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751462Ab3IROWW (ORCPT ); Wed, 18 Sep 2013 10:22:22 -0400 Date: Wed, 18 Sep 2013 09:21:18 -0500 From: Felipe Balbi To: Mark Rutland CC: Felipe Balbi , Kumar Gala , "rob.herring@calxeda.com" , Pawel Moll , Stephen Warren , Ian Campbell , "devicetree@vger.kernel.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] usb: dwc3: core: clarify usb-phy array binding Message-ID: <20130918142118.GJ21559@radagast> Reply-To: References: <1376062832-23288-1-git-send-email-galak@codeaurora.org> <20130809162848.GW27325@e106331-lin.cambridge.arm.com> <1A03353A-9299-4D73-9786-4ECBC1DD4E05@codeaurora.org> <20130812180553.GD27954@radagast> <20130813133410.GO27165@e106331-lin.cambridge.arm.com> <20130827185329.GT3005@radagast> <20130828160151.GA17229@e106331-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZG+WKzXzVby2T9Ro" Content-Disposition: inline In-Reply-To: <20130828160151.GA17229@e106331-lin.cambridge.arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4211 Lines: 113 --ZG+WKzXzVby2T9Ro Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Aug 28, 2013 at 05:01:51PM +0100, Mark Rutland wrote: > > > So it's not physically possible for someone to just wire up a single = phy > > > to the device, either USB2-only or USB3? > >=20 > > of course it is :-) In fact, TI has done it. But it causes a whole bunch > > of other problems to support that sort of model. For one, in some > > systems, a clock generated by the USB3 PHY is backfed into the IP and if > > USB3 PHY isn't running, the dwc3 IP won't start. >=20 > That sounds like a mess. But unless I've misunderstood, that doesn't well, it is :-) > sound like a general problem with having one phy, but rather an > integration issue on a specific system? Presumably in that case as long > as the phy was brought up before poking the rest of the IP, the unit > would function correctly. right, but what 'brings up' the PHY is usb_phy_init(). If we don't add usb3phy to DTS or skip usb3phy in case maximum-speed < superspeed, then we're screwed :-) > > I even wrote a patch making USB3 PHY optional, but didn't push it > > exactly because it broke some other systems and I can't guarantee users > > won't mess up their DTS/pdata. >=20 > Does that mean that their dts or pdata are wrong at the moment, but > they're spared because the driver bails out due to a missing phy? If > their pdata's wrong, that should be fixable relatively easily, but if > the dt is wrong then I'm not sure how we can support those systems > sensibly. That sounds like an ideal candidate for a dt quirks > mechanism... hmm, the idea of the patch was: switch (maximum-speed) { case SUPER: grab_and_initialize_usb3_phy(); grab_and_initialize_usb2_phy(); break; case HIGH: case FULL: case LOW: grab_and_initialize_usb2_phy(); break; } now, imagine someone wants to run his dwc3 in highspeed mode, we wouldn't initialize USB3 PHY which could cause the whole IP to break. I tried poking around on device's registers to see if there was any way to detect that the IP needs somethin back from USB3 PHY, but couldn't find anything. Since we can't know how the IP was integrated, it's best to leave it alone and require NOP xceiv to be used. > > > You can describe the USB2-only case in the dt by only listing the fir= st > > > phy (though the driver won't support it as it expects both to be > > > present), but it's impossible to describe that you've wired up a sing= le > > > phy that's USB3 capable. > >=20 > > you might be right there... >=20 > Would it be possible to have something like (an optional) usb-phy-names? > If not present, we assume the current situation, if present then we use > it to figure out which phys are present. Maybe I'm missing something > that makes that impossible? you're missing the point regarding the IP possibly needing something back from the PHY (e.g. a clock which PHY generates). --=20 balbi --ZG+WKzXzVby2T9Ro Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJSObbdAAoJEIaOsuA1yqRE6IYQAKF8C18dLDvC69UJMAwoKC9S lyQO39Xra/UeqjFCPjrsO651v3nSR+7w9gAy6p5Yal1VANBqkUigTtjPCNLPkQ68 7pj+rSKt3FXX5gTLLx8G9TNRLADcVvRzdVTQJlh1pVj+wXoeQ4hQUdV1LdS5QTJX x1oo+mMVF3ahdflnyEcRchAsctm7iO4WdlwxFo2tW3XbyHVkZhgq8CbPQn+PZIfg LQNlDMSSc8lCge2dCoIhYgS8/avNmckeTq/rG2Cpy7jF525eMUqJNI9SwUWzByAT 7Yho+Z9O5wmrRpQuOacm5BdmuFGe70P3o5XKnmLbIMXnC90g9Hr/1RyA9gfqq5Vn 2xvL4rMK09rN9k0SMNn4/ZYyVODQVIxz6kxmNJju4fVob/3Ao/yo2DRVGdTG53TU YwrB9jsl1I8+4AGTlj1d0528YHorqRhwNn/l3znqh651nT7IoKvyvyCniw1nNrYF pFcOJZcwM6kgqdsZxK4cp08FHHjRtNH5pwGhiat65KcEaMJvQh0MgnizHrzmhrpN hirRE/AN8DuQVXDXvEuK9iDEx418j6xN4+UN+Yk+pGYyqptBs+ewrApHVDQnNd7t GJKfB6ZBcidmo/5b9qb/iST/0FnMmqvycYppYGclEgTfhhwfuyou3F8Dt0QmErwe 9ota4HKfY+LVKg2o3u5L =7jUi -----END PGP SIGNATURE----- --ZG+WKzXzVby2T9Ro-- -- 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/