From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felipe Balbi Subject: Re: [RFC PATCH 1/5] drivers : introduce device_path api Date: Tue, 11 Dec 2012 12:09:03 +0200 Message-ID: <20121211100903.GF19367@arwen.pp.htv.fi> References: <20121127170223.GB2687@kroah.com> <50BF55B3.1030205@ti.com> <50C5B003.9060904@ti.com> <50C70495.40500@ti.com> Reply-To: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="juZjCTNxrMaZdGZC" Return-path: Content-Disposition: inline In-Reply-To: <50C70495.40500-l0cyMroinI0@public.gmane.org> Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Roger Quadros Cc: Jassi Brar , Greg KH , Alan Stern , Ming Lei , Felipe Balbi , Andy Green , linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, keshava_mgowda-l0cyMroinI0@public.gmane.org, USB list List-Id: linux-omap@vger.kernel.org --juZjCTNxrMaZdGZC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 11, 2012 at 12:01:57PM +0200, Roger Quadros wrote: > On 12/11/2012 11:12 AM, Jassi Brar wrote: > > On Mon, Dec 10, 2012 at 3:18 PM, Roger Quadros wrote: > >> On 12/06/2012 04:34 PM, Jassi Brar wrote: > >>>> > >>>> Yes, this is where we can think of a generic PHY driver to make sure= thy > >>>> PHY has necessary resources enabled. In the Panda case it would be t= he > >>>> PHY clock and RESET gpio. > >>>> > >>> I wonder if ehci-omap should assume, besides regulator, a clock might > >>> also be need to setup for the transceiver chip. > >>> Maybe "usbhs_bdata" in board-omap4panda.c should have > >>> .reset_gpio_port[0] =3D GPIO_HUB_NRESET ? > >>> > >> > >> Just like the regulator, reset_gpio_port has nothing to do with OMAP > >> EHCI. So we would want to get rid of that too from the OMAP USB driver. > >> > > Looking at the code I realized we already book resources only for > > populated ports. Saving power from LAN9514 chip would come from a > > separate solution. So, for now when our transceiver, USB3320, has > > simple hardwired configuration probably just platform_data/DT would > > do. When we come across some programmable transceiver (like USB3503 > > over i2c), that might warrant a separate PHY driver. Still I don't > > think we could have a 'generic' phy driver. > >=20 > Yes I2C based Phys might need a different driver. At least we could have > a generic PHY driver for all ULPI based phys. (NOTE: the USB3320 is also > configurable and can work in OTG mode) we already do, that's what nop-xceiv is for. --=20 balbi --juZjCTNxrMaZdGZC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQxwY/AAoJEIaOsuA1yqREpi8P+wbOJQJaUnUyYURGICVrlzBl 4tKNqWULzoScgyEBMIosmBZDTRNk/Yx69SeWDE1R/Bs+d/A7tWUYr3oHzz/cYgRO pLw4e24/NUy9WjR5Dsxo1HH7+vxxPzNCEL3NSzIWWditR22bwK27XIEFXXzYk+5S TQeTVg9aKy5y6V7lgRDnfAX9nZE6jSac4YuveGBM+IffffNlI07KC6qz+e6pDwPm VZydonH0SG4vfPA0Lnr/PvnklYevtfXyEdMABNtjmj9Ta/6OkaXf6oS3FMs1+7XC YKgCMuWLpRw9AawO84vaWGzcWwTbsvB/Ta08CeMed61GxcxLNnICgLEC/rTL2VZY uRCW5PgK8IxQsLPCjYiS1TpphqHEHyPx62yBmf5OCYtxmkJ5dZlNZObz/ihS1EqW lSR8er58vyf4gy6tx5erZOsLV+XSc/CKXnvn099eWkHdDQaU9UCG9ZkNy5F4qrI/ 0FUj5M2K9VGrYdUqsWlYDqIr3rWhQtjIX4crF/quBtGkprjPFRrMaQuSgpytLkgP Poo8s1AtAWvqPRpblD7nlTMog1Cq1JzRHGtL8SmyJp8UmgVYspTDqtk7WVAcTqSh 6zU0MNPWpQDwLzhupDZ9njScsmHMTzlY+UJJXTuK9kDCU+nGblbCEEQoEeY60yx2 34vnGtB9/oPMnVp/yGSR =ctqg -----END PGP SIGNATURE----- --juZjCTNxrMaZdGZC-- -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html