On 11/28/2012 11:06 PM, the mail apparently from Roger Quadros included:
Hi Roger -
On 11/28/2012 02:59 PM, Andy Green wrote:
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
The regulators are made a device_asset of the EHCI logical root hub by
passing them through the hsusb -> mfd path. Although the ehci-related
platform_device is created at boot time, it is not instantiated until the
ehci-hcd module is inserted if it is modular.
Since the regulator is an asset of the ehci-omap.0 device, it's turned on
during successful probe and off when the device is removed.
Without power control, the ULPI PHY + SMSC9614 on the Panda eats 700-900mW
all the time, which is around the same as the idle power of the SoC and
rest of the board.
This allows us to start off with it depowered, and only power it if the
ehci-hcd module is inserted. When the module is removed, it's depowered
again.
...
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 98f3287..2a0fdf9 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -501,6 +501,7 @@ void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
}
ehci_data.phy_reset = pdata->phy_reset;
ohci_data.es2_compatibility = pdata->es2_compatibility;
+ ehci_data.assets = pdata->assets;
Just wondering if it makes more sense to tie the regulator and clock
assets on the Panda to LAN95xx platform device instead of ehci_omap's
platform device.
The only thing we need to do is add a dummy platform device for the
LAN9xx chip and probe it in the smsc9xx driver.
The benefit of this is we can choose to power up/down the LAN9xx device
by insmod/rmmod smsc0xx driver and still have other OMAP USB ports
functional.
what do you think?
I think it's cool but I am not sure it hangs together. Just to make
sure we're on the same page, the "LAN95XX platform device" doesn't exist
at the moment, right?
With hsusb mfd -> ehci the platform device can be made from boot because
the memory-mapped hardware is always there. As soon as the driver
appears, it can be probed and made into a real live device and
everything is straight.
But when the platform_device would represent a usb device, that's not
quite the same. AIUI the usb stack only creates the device when it has
probed a vid:pid and identified a driver that claims to serve it.
If the power for the HUB+ETH was controlled by an asset on the probe for
the HUB+ETH device, isn't that never going to happen? The usb stack
can't see the vid+pid for smsc95xx device until we give it power (it's
connected but off), in this scheme we don't give it power until
something ran probe for an smsc95xx device?
There's another quirk on Panda that makes trouble too, after enabling
power on the HUB+ETH chip, we must reset it. But the same reset signal
resets the ULPI PHY too. So if the powering deadlock was solved we
would still run into a problem where we caused ULPI errors bringing up
the smsc95xx, if ehci+ULPI was already going. It's a violation of the
independence of the ULPI and [usb device on other side of ulpi] caused
by the Panda design using the same reset signal. That is why the current
approach gets power + reset over with once at the time we would anyway
want to reset the ULPI PHY.
However I think what you're saying about binding to hub power is good.
The hub ports are not devices, but it would be possible to bind an asset
array to them and make the pre- and post- code functions.
But AFAIK neither that, nor the platform_device idea for smsc95xx even
get off the ground without a device_path type addressing scheme, because
you are targeting from the board file specific logical devices that only
exist later after other probes.
I think it will be possible to address objections around the "pathiness"
by being able to seed the path match with a platform_device pointer
(there exists in the board file time a platform_device for ehci-omap.0
...) and just matching the remainder on a single usb device's name, like
"*-1.1-1".
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
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
