Hi, Well, I'm not any less busy than yesterday, as it turns out, but I'm expecting that to continue tomorrow, so I may as well have a look at it now. :-)
On Tuesday, December 04, 2012 12:10:32 PM Alan Stern wrote: > [CC: list trimmed; the people who were on it should be subscribed to at > least one of the lists anyway.] > [...] > > > Not only regulators involved, clock or other things might be involved too. > > Also the same power domain might be shared with more than one port, > > so it is better to introduce power domain to the problem. Looks > > generic_pm_domain is overkill, so I introduced power controller which > > only focuses on power on/off and being shared by multiple devices. > > Even though it is overkill, it may be better than introducing a new > abstraction. After all, this is exactly the sort of thing that PM > domains were originally created to handle. > > Rafael, do you have any advice on this? The generic_pm_domain > structure is fairly complicated, there's a lot of code in > drivers/base/power/domain.c (it's the biggest source file in its > directory), and I'm not aware of any documentation. Yeah, documentation is missing, which obviously is my fault. That code is designed to cover the case in which multiple devices share a "power switch" that can be used to remove power from all of them at once (eg. through a register write). It also assumes that there will be a "stop" operation, such as "disable clock", allowing each device in the domain to be put into a shallow low-power state (individually) without the necessity to save its state. Device states only have to be saved when the "power switch" is about to be used, which generally happens when they all have been "stopped" (their runtime PM status is RPM_SUSPENDED). The "stop" operation may be defined in a different way for each device in the domain (actually, that applies to the "save state", "restore state", and "start" - opposite to "stop" - operations too) and PM QoS latency constraints are used to decide if and when to turn the whole domain off. Moreover, it supports hierarchies of power domains that may be pretty much arbitarily complicated. A big part of this code is for the handling of system suspend/resume in such a way that it is consistent with runtime PM. For USB ports I'd recommend to use something simpler. :-) Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
