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