Re: [try#1 PATCH 5/7] omap4: panda: add smsc95xx regulator and reset dependent on root hub

[Andy Green <andy.green@linaro.org>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html