On 12/06/2012 04:34 PM, Jassi Brar wrote: > On Wed, Dec 5, 2012 at 7:39 PM, Roger Quadros <rogerq@xxxxxx> wrote: >> Hi Jassi, >> >> On 12/01/2012 09:49 AM, Jassi Brar wrote: >>> On Tue, Nov 27, 2012 at 10:32 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >>>> On Tue, Nov 27, 2012 at 11:30:11AM -0500, Alan Stern wrote: >>>>> >>>>> We should have a more generic solution in a more central location, like >>>>> the device core. >>>>> >>>>> For example, each struct platform_device could have a list of resources >>>>> to be enabled when the device is bound to a driver and disabled when >>>>> the device is unbound. Such a list could include regulators, clocks, >>>>> and whatever else people can invent. >>>>> >>>>> In this case, when it is created the ehci-omap.0 platform device could >>>>> get an entry pointing to the LAN95xx's regulator. Then the regulator >>>>> would automatically be turned on when the platform device is bound to >>>>> the ehci-omap driver. >>>>> >>>>> How does this sound? >>>> >>>> That sounds much better, and it might come in handy for other types of >>>> devices than platform devices, so feel free to put this on the core >>>> 'struct device' instead if needed. >>>> >>> Isn't enabling/disabling of clocks and regulators what >>> dev.probe()/remove() of any driver already does? >>> If we mean only board specific setup/teardown, still it would mean >>> having the device core to do an extra 'probe' call when the current >>> probe() is already meant to do whatever it takes to bring the device >>> up. To my untrained eyes, it seem like messing with the >>> probe()/remove()'s semantics. >>> IMHO, if we really must implement something like that, may be we >>> should employ some 'broadcast mechanism' so that anything anywhere in >>> kernel knows which new device has been probed()/removed() >>> successfully. I haven't thought exactly how because I am not sure even >>> that would be the right way to approach PandaBoard's problem. >>> >>> Looking at "Figure 15 – Panda USBB1 Interface Block Diagram" of >>> http://pandaboard.org/sites/default/files/board_reference/pandaboard-es-b/panda-es-b-manual.pdf >>> gives me visions ... >>> >>> 1) OMAP doesn't provide the USB root-hub, but only ULPIPHY. It is >>> USB3320C chip that employs OMAP's ULPIPHY to provide the root-hub. So >>> we should have a platform device for USB3320C, the probe() of which >>> should simply >> >> Actually the EHCI controller within OMAP provides the root hub with 3 >> ports but no PHY. One of them is connected to the USB3320 which is just >> a ULPI PHY. >> >>> a) Enable REFCLK (FREF_CLK3_OUT) >>> b) Reset itself by cycling RESETB (GPIO_62) >>> c) Create one "ehci-omap" platform device >> >> c) is not appropriate. ehci-omap must be created before usb3320. >> >>> (or in appropriate order if the above isn't) >>> That way insmod/rmmod'ing the USB3320C driver would power-up/down the >>> whole subsystem. >> >> 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 the >> 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] = 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. > >> The LAN95xx chip still needs to be powered up and the PHY driver isn't >> the right place for that (though it could be done there as a hack). The >> closest we can get to emulating right USB behavior is to map the >> SET/CLEAR PORT_FEATURE of the root hub port to the regulator that powers >> the LAN95xx. >> >> This way, we still don't fall in the dynamically probed space, so we >> could still provide the regulator information to the ehci hub via >> platform data and handle the regulator in ehci_hub_control >> (Set/ClearPortFeature). I'm looking at this as a software workaround for >> all platforms not implementing the EHCI set port power feature >> correctly. The same could be repeated for other HCDs as well if required. >> > IMHO it's not a matter of platforms not implementing EHCI set port > power feature correctly, we should think about onboard devices > connected to onboard non-root hubs. Setups like LAN9514 on Panda (HSIC > too ?) that don't run on VBUS of USB, would like their local supply to > be treated as if it came from the parent hub's port i.e, tie together > the USB's set port power control with their OOB regulated power supply > (U9 on PandaBoard). > On Pandaboards we are still talking about root hub ports. Do you know any of such platforms which power their USB devices out of band for _non_ root hub ports? Assuming they do exist, the only solution is to match platform data for dynamically probed devices and deal with the regulators in the hub/port driver. Something like Andy already proposed. regards, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
