On 12/03/2012 05:00 AM, Ming Lei wrote: > On Mon, Dec 3, 2012 at 12:02 AM, Andy Green <andy.green@xxxxxxxxxx> wrote: >> On 02/12/12 23:01, the mail apparently from Ming Lei included: >> >>> Power controller is an abstract on simple power on/off switch. >>> >>> One power controller can bind to more than one device, which >>> provides power logically, for example, we can think one usb port >>> in hub provides power to the usb device attached to the port, even >>> though the power is supplied actually by other ways, eg. the usb >>> hub is a self-power device. From hardware view, more than one >>> device can share one power domain, and power controller can power >>> on if one of these devices need to provide power, and power off if >>> all these devices don't need to provide power. >> >> >> What stops us using struct regulator here? If you have child regulators >> supplied by a parent supply, isn't that the right semantic already without >> introducing a whole new thing? Apologies if I missed the point. > > There are two purposes: > > One is to hide the implementation details of the power controller because > the user doesn't care how it is implemented, maybe clock, regulator, gpio > and other platform dependent stuffs involved, so the patch simplify the usage > from the view of users. > Which user are you talking about? AFAIK for Panda we only need a regulator and a clock for each root port. IMHO we should just use the existing regulator and clock frameworks. > Another is that several users may share one power controller, and the > introduced power controller can help users to use it. > True. e.g. the same regulator could be used to power 3 root hub ports in a ganged setup. But the regulator framework is sufficient to deal with that. Each port will call regulator_get() and regulator_enable() and the physical regulator won't be disabled till all of them have called regulator_disable(). regards, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
