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, > > > > > > You can't really compare a bus like i2c, which can't enumerate devices > > > > natively, to ULPI which can. > > > > > > 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 ? > > > > 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. > > 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. > > 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 -- balbi
signature.asc
Description: Digital signature
