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. 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. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
