Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

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

On 11/24/12 00:25, the mail apparently from Alan Stern included:
> On Fri, 23 Nov 2012, Felipe Balbi wrote:
>
>>> Thanks for the example. The only problem is, how do we associate a
>>> regulator to a specific port in the system.
>>
>> heh, that's the 1 million dollar question, isn't it ? :-)
>>
>> that's what we need to figure out now. Luckily we have Alan Stern
>> helping us out ;-)
>
> Some people might think having me around to interfere was not so lucky
> after all...  :-)
>
> First question: Should we worry about individual ports?  Ordinarily I'd
> say No, because hubs always power up all of their ports.  But with Lan
> Tianyu's recent work, that won't be true any more.  In this case, it's
> conceivable that the user might want to power-off the LAN95xx in order
> to save energy, even though ehci-hcd is still loaded and managing other
> USB devices.
>
> Either way, the regulator has to be associated with _something_: either
> a root-hub port or the host controller itself.  And this will most
> likely have to be done before the port's or the controller's struct
> device exists.
>
> Something like Andy's scheme might work.  It would require the kernel
> to parse name strings in various formats, which could get complicated.
> It would be great if the difficult parts could be stuck in the PM core
> somewhere.

If we're just looking at fixing the current "magic regulator name" 
scheme of "hsusb0" so that it can work with abstract devices like any 
hub / port, we could invert what my original "device path" scheme did.

So instead of having a parser (which boiled down quite small, but is 
complicated by usb%d being the same for different usb drivers), we could 
just add a helper function that walks the device parents to generate a 
string representing the device instance.  Like

int device_path_generate(struct device *device, char *name, int len);

if you called it from the hub driver's probe function (or anything 
else's probe function) with the new hub device pointer, it might fill 
name with "ehci1/usbhub1-1/1-1.1" or somesuch.

That is then used in the hub probe function as the magic regulator name, 
if a regulator exists of that name it gets managed according to logical 
hub device lifecycle, same as the omap bit does at the moment.

That way it'll work with DT alright (you just arrange the regulator name 
to be "ehci1/usbhub1-1/1-1.1" or whatever) and you're just trying to 
sell device_path_generate() to someone else, which should be pretty small.

-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