From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH V6 00/12] Tegra xHCI support Date: Wed, 25 Feb 2015 22:15:45 +0100 Message-ID: <20150225211539.GA7884@mithrandir> References: <1416874644-12070-1-git-send-email-abrestic@chromium.org> <20150225160110.GA26610@ulmo> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andrew Bresticker Cc: Stephen Warren , Alexandre Courbot , "linux-tegra@vger.kernel.org" , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Jassi Brar , Linus Walleij , Greg Kroah-Hartman , Mathias Nyman , Grant Likely , Alan Stern , Arnd Bergmann , Olof Johansson , Kishon Vijay Abraham I , Felipe Balbi , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" "linux-arm-kernel@lists.infradead.org" List-Id: linux-tegra@vger.kernel.org --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 25, 2015 at 09:27:36AM -0800, Andrew Bresticker wrote: > Hi Thierry, >=20 > > Sorry for taking so awfully long to look at this. I've spent some time > > looking at various pieces of documentation and I concluded that > > representing the port assignment as muxing options doesn't seem right > > after all. Instead I've come up with an alternate proposal (attached). > > Could you take a look and see if that sounds reasonable to you? >=20 > Thanks for taking a look at this. I've been meaning to pick this > series back up, but haven't had quite enough bandwidth lately. >=20 > This all looks good to me, just one comment below: >=20 > > +PHY nodes: > > +---------- > > + > > +An optional child node named "phys" can contain nodes describing addit= ional > > +properties of each PHY. Only USB3 and UTMI PHYs can be complemented in= this > > +way, in which case the name of each node must match one of the followi= ng: > > + > > + usb3-0, usb3-1, utmi-0, utmi-1, utmi-2 > > + > > +Required properties for USB3 PHYs: > > +- nvidia,lanes: specifies the name of the lane that this USB3 PHY uses > > +- nvidia,port: specifies the number of the USB2 port that is used for = this > > + USB3 PHY > > + > > +Optional properties for UTMI PHYs: > > +- vbus-supply: regulator providing the VBUS voltage for the UTMI pad >=20 > What about the HSIC PHYs? Shouldn't they be represented as PHY nodes as = well? Yes, they could. The PCIe and SATA PHYs could as well. I haven't included them because they currently don't take any properties. In addition to that, perhaps some of the nvidia,hsic-* properties could be moved into the PHY nodes, too. But they're also properties of the pin, so keeping them in the pinmux nodes seems fine as well. On a slightly different topic, I've been trying to wrap my head around the use of the nvidia,port property and my conclusion was that in fact one of the physical ports is shared between USB2 and USB3. That is the utmi-2 PHY and usb3-0 PHY go to the very same port. The vbus-supply specified in the Jetson TK1 DTS would support that (it's associated with utmi-2 but named vdd_usb3_reg, and the USB3 port doesn't work without it). Can you confirm that? Thierry --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU7jt0AAoJEN0jrNd/PrOhzSMP/0Q40Ixv0t+IhXpCoNr8m32K DV2spBizq/lpeCC5HCQ1OXF51r9zNuD+ikKtQ6MwFGAZdAoQxLCVwLrCIRtK+h/J DbJut3sc7OMflFYgGwLqAKzXo5Qc2W6wwp89I0Ntsvyyct35ycbQVIT6EIhcW1Iy ONa+8/uGN4l++DM5Vr46vUPvu3f6CKz0zSNLOu7L5y6Rc3W3lgU4haUd/XtkmRN8 yubu/i5+fx3A9f+3PJXXWw8MsYrUUxl/sqnnOUfNM6XYnrMRu9/UqeKs9SHx7Utk HuiDH54h1vaIIinxGUspZV18Oeg6ZShlTs3JDSvmB7z5tHg6OnpmA/En4mtoBaEi WWF/TESPNWJaR3lQmncshqKB848iJnFq9aAKg47CMNbke6LLyCSFv6qhhG30qkvu dFUQFb+uoUU201KHGZ1hu+QCJpALpfg+R+OHGMauXuohqirb1ei7pGCJV+0kXqKf Q9fDwqwVCvF+Ax6caILCE+XEWR3xbWmTJhKEsH26ZRMkdBTUbn3uJ9trU1Z1TO4Z hS/YYkNiexvu1z7fO7LlTHVHuWQy/HejGW06eg7oS9urJeNTi0yOR5JzLOexa1A3 AHuM4pkNqF9gOf+MLml7UbuFBbc9Lxp2++U+GextNxK1ZWN1xQ1vGIWcUKYh3FH5 Ol1yNiP53x6iUlADSPDz =IcuG -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3--