Hi, This patch set trys to prepare for support of usb port power off mechanism on non-ACPI devices. The port power off mechasnism has been discussed for some time[1][2], and support for ACPI devices has been in shape: - usb port device is introduced - port connect type is introduced and set via ACPI - usb root port power can be switched on/off via ACPI The above has been merged to upstream, and Tianyu is pushing patches[3] to enable auto port power feature. So it is time to discuss how to support it for non-ACPI usb devices, and there are many embedded system in which some of usb devices are hardwired(often self-powered) into board, such as, beagle board, pandaboard, Arndaleboard, etc. So powering on/off these devices may involve platform dependent way, just like ACPI power control is used in Tianyu's patch. This patch set introduces power controller to hide the power switch implementation detail to usb subsytem, in theroy it can be used to other devices and subsystem, and the power controller instance is stored as device's resource. So the power controller can be used to power on/off the power supply from the usb port, and makes support of port power off possible on non-ACPI devices. Associating power controller with one device(such as usb port) which providing power logically is not an easy thing, because platform dependent knowledge(port topology, hardware power domain on the port, ...) has to be applied and the usb port device isn't a platform device and it is created during hub probe(). So looks there is no general approach to do it. This patchset introduces one global device ADD/DEL notifier in driver core, so when a new device is added, one match function in platform code is called to check if the device can be associated with the power controller. This patchset implements the match function on OMAP4 based Pandaboard, and defines the power controller to control power for lan95xx hub and ethernet device. Another idea of associating power controller with port device is by introducing usb port driver, and move all this port power control stuff from platform code to port driver, which is just what I think of and looks doable. I'd like to get some feedback about which one is better, then I can do it in next cycle. Also the two things on Pandaboard have been done at the same time: - powering on the two devices can be delayed to the ehci-omap root hub probing. - the regulatores which are used for these two hardwired and self-powered devices are moved out from ehci-omap driver In fact, Andy Green has been working[4][5] on the above two things, but which isn't the main purpose of these patches, and they might be seen as byproduct of the patchset. Inevitably, there are some overlap between Andy's work and this patchset, hope we can compare, discuss and figure out the perfect solution. arch/arm/mach-omap2/board-omap4panda.c | 99 +++++++++++++++++++++++++++- drivers/base/core.c | 21 ++++++ drivers/base/power/Makefile | 1 + drivers/base/power/power_controller.c | 110 ++++++++++++++++++++++++++++++++ drivers/usb/core/hub.c | 31 ++++++++- drivers/usb/host/ehci-omap.c | 36 ----------- include/linux/device.h | 13 ++++ include/linux/power_controller.h | 48 ++++++++++++++ include/linux/usb/port.h | 16 +++++ kernel/power/Kconfig | 6 ++ 10 files changed, 339 insertions(+), 42 deletions(-) Thanks, -- Ming Lei [1], http://marc.info/?t=134818354900003&r=1&w=2 [2], http://marc.info/?t=134303384500003&r=1&w=2 [3], http://marc.info/?l=linux-usb&m=135314427413307&w=2 [4], http://marc.info/?t=135393394700003&r=1&w=2 [5], http://www.spinics.net/lists/linux-omap/msg83191.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
