From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932964AbbA3Qdv (ORCPT ); Fri, 30 Jan 2015 11:33:51 -0500 Received: from comal.ext.ti.com ([198.47.26.152]:40898 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752727AbbA3Qdt (ORCPT ); Fri, 30 Jan 2015 11:33:49 -0500 Date: Fri, 30 Jan 2015 10:33:52 -0600 From: Felipe Balbi To: David Cohen CC: Heikki Krogerus , Felipe Balbi , Greg Kroah-Hartman , Baolu Lu , , , Kishon Vijay Abraham I Subject: Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY Message-ID: <20150130163352.GF15318@saruman.tx.rr.com> Reply-To: References: <20150126125503.GB28539@kuha.fi.intel.com> <20150126192337.GA13936@psi-dev26.jf.intel.com> <20150127092856.GD28539@kuha.fi.intel.com> <20150127173801.GA8441@psi-dev26.jf.intel.com> <20150128142024.GA2378@kuha.fi.intel.com> <20150128180255.GA7551@psi-dev26.jf.intel.com> <20150129141412.GA2570@kuha.fi.intel.com> <20150129162023.GF21217@saruman.tx.rr.com> <20150130092956.GE2570@kuha.fi.intel.com> <20150130162038.GB20689@psi-dev26.jf.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pyE8wggRBhVBcj8z" Content-Disposition: inline In-Reply-To: <20150130162038.GB20689@psi-dev26.jf.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --pyE8wggRBhVBcj8z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 30, 2015 at 08:20:38AM -0800, David Cohen wrote: > On Fri, Jan 30, 2015 at 11:29:56AM +0200, Heikki Krogerus wrote: > > Hi, > >=20 > > > > You can't really compare a bus like i2c, which can't enumerate devi= ces > > > > natively, to ULPI which can. > > >=20 > > > why not ? The BIOS might not need to use the PHY (or USB) at all, it = can > > > very well decide to never turn it on, right ? > >=20 > > If ULPI was seen as a bus, then no. BIOS would have definitely left > > the PHY on. In fact, if we would have just asked the BIOS writers to > > leave it on, they would not have any problem with that, even without > > the bus. >=20 > That's a really wrong assumption. ULPI bus depends on dwc3 to be > functional and dwc3 depends on phy to be functional to complete its > power on sequence. We can't ask BIOS to let both up and running all the > time. >=20 > FWIW we *cannot* rely on ULPI bus enumeration to probe ULPI devices, > because it requires the ULPI device to be previously functional which > can't happen before the enumeration. Even if we ask BIOS to let phy > functional after boot, what happens when we remove modules and load it > again? Should we ask BIOS to power on the components again in order to > probe and power it on? It's a circular dependency you're creating. do we need both CS and RESET for phy to be functional ? Since we need PHY functional during ulpi bus enumeration phase, the only way would be to have the ULPI bus code itself grab those GPIOs (as long as it's gpiod_get_optional() we should be fine) and toggle them before enumerating the bus. The only problem is doing that for every driver_register() :-s --=20 balbi --pyE8wggRBhVBcj8z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUy7JvAAoJEIaOsuA1yqREF8MP/1oyd/Li4w2u4PmYt6VTHdz7 5IgrBLiCxM8nBZLQZ5FHUfx2S4hXC+HYZh7U3kJqhjyfU+6y614ziXXWe38Iqwaw AmpcG9tgrCKIszvsiWAygeApAUR1pldn31K3bvNRcKOB3oezFK72NUpHE1h6gU9W vfnjGyLoUyVqWiLA0v+qQVINdJzNys78C5nXDYOwI9NwfwDbTM7K2XxyvPksIMmn Ue/1huQojp75S5UjB5NXF9rDe3AKZ4t6kuBmJ+vcU3Dqbg0YuBTX7/BmKSloEvtv lOvug3y+aYMmgBkGqwYJ5skUmQGOLjdiJDkmJCeKkOUr56/RXndDxDArwQS3IHUm T6rQVwLQ28pollr2QBQVysqZXo6Ld4Nq5aDIx95aZN1yjL6PzO6e9L+Dzn+7uX2h CR+eBSH9sdVDGZ+EDt9FP94QBEN4O3KsX6HjYKggKcAJ7Q8D9dHReJDWdQkJiK/X 5vqmqZlBg014BT+fU3TEIi7ahcEve9JMQeIHCaW+r15Pw8UadEOsOln9TEIv07JX Y4DbuJRUTCM8AZb8Jj/WpUQZt8240BJXVnGniRUBiE8rPjggFrR7WqXT0oI7TxDF YZI9XcLElQSmSln5/Pc/H5C46SIVoBr1TDu8SZAt1tsNaJohavT7ZC0I/J4WdPvt usTTYHM/S+CQruuxNXhv =Heao -----END PGP SIGNATURE----- --pyE8wggRBhVBcj8z--