[RFC PATCHv2] usb: move hub init and LED blink work to power efficient workqueue

[RFC PATCHv2] usb: move hub init and LED blink work to power efficient workqueue

[Zoran Markovic]

From: Shaibal Dutta <shaibal.dutta@broadcom.com>

Allow the scheduler to select the best CPU to handle hub initalization
and LED blinking work. This extends idle residency times on idle CPUs
and conserves power.

This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Xenia Ragiadakou <burzalodowa@gmail.com>
Cc: Julius Werner <jwerner@chromium.org>
Cc: Krzysztof Mazur <krzysiek@podlesie.net>
Cc: Matthias Beyer <mail@beyermatthias.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com>
[zoran.markovic@linaro.org: Rebased to latest kernel. Added commit message.
Changed reference from system to power efficient workqueue for LEDs in
check_highspeed() and hub_port_connect_change().]
Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
---
 drivers/usb/core/hub.c |   19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index babba88..e11a7e9 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -504,7 +504,8 @@ static void led_work (struct work_struct *work)
 		changed++;
 	}
 	if (changed)
-		schedule_delayed_work(&hub->leds, LED_CYCLE_PERIOD);
+		queue_delayed_work(system_power_efficient_wq,
+				&hub->leds, LED_CYCLE_PERIOD);
 }
 
 /* use a short timeout for hub/port status fetches */
@@ -1046,7 +1047,8 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
 		if (type == HUB_INIT) {
 			delay = hub_power_on(hub, false);
 			PREPARE_DELAYED_WORK(&hub->init_work, hub_init_func2);
-			schedule_delayed_work(&hub->init_work,
+			queue_delayed_work(system_power_efficient_wq,
+					&hub->init_work,
 					msecs_to_jiffies(delay));
 
 			/* Suppress autosuspend until init is done */
@@ -1200,7 +1202,8 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
 		/* Don't do a long sleep inside a workqueue routine */
 		if (type == HUB_INIT2) {
 			PREPARE_DELAYED_WORK(&hub->init_work, hub_init_func3);
-			schedule_delayed_work(&hub->init_work,
+			queue_delayed_work(system_power_efficient_wq,
+					&hub->init_work,
 					msecs_to_jiffies(delay));
 			return;		/* Continues at init3: below */
 		} else {
@@ -1214,7 +1217,8 @@ static void hub_activate(struct usb_hub *hub, enum hub_activation_type type)
 	if (status < 0)
 		dev_err(hub->intfdev, "activate --> %d\n", status);
 	if (hub->has_indicators && blinkenlights)
-		schedule_delayed_work(&hub->leds, LED_CYCLE_PERIOD);
+		queue_delayed_work(system_power_efficient_wq,
+				&hub->leds, LED_CYCLE_PERIOD);
 
 	/* Scan all ports that need attention */
 	kick_khubd(hub);
@@ -4316,7 +4320,8 @@ check_highspeed (struct usb_hub *hub, struct usb_device *udev, int port1)
 		/* hub LEDs are probably harder to miss than syslog */
 		if (hub->has_indicators) {
 			hub->indicator[port1-1] = INDICATOR_GREEN_BLINK;
-			schedule_delayed_work (&hub->leds, 0);
+			queue_delayed_work(system_power_efficient_wq,
+					&hub->leds, 0);
 		}
 	}
 	kfree(qual);
@@ -4545,7 +4550,9 @@ static void hub_port_connect_change(struct usb_hub *hub, int port1,
 				if (hub->has_indicators) {
 					hub->indicator[port1-1] =
 						INDICATOR_AMBER_BLINK;
-					schedule_delayed_work (&hub->leds, 0);
+					queue_delayed_work(
+						system_power_efficient_wq,
+						&hub->leds, 0);
 				}
 				status = -ENOTCONN;	/* Don't retry */
 				goto loop_disable;
-- 
1.7.9.5

Re: [RFC PATCHv2] usb: move hub init and LED blink work to power efficient workqueue

[Alan Stern]

On Sat, 1 Feb 2014, Zoran Markovic wrote:

> From: Shaibal Dutta <shaibal.dutta@broadcom.com>
> 
> Allow the scheduler to select the best CPU to handle hub initalization
> and LED blinking work. This extends idle residency times on idle CPUs
> and conserves power.
> 
> This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
> Cc: Xenia Ragiadakou <burzalodowa@gmail.com>
> Cc: Julius Werner <jwerner@chromium.org>
> Cc: Krzysztof Mazur <krzysiek@podlesie.net>
> Cc: Matthias Beyer <mail@beyermatthias.de>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
> Cc: Thomas Pugliese <thomas.pugliese@gmail.com>
> Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com>
> [zoran.markovic@linaro.org: Rebased to latest kernel. Added commit message.
> Changed reference from system to power efficient workqueue for LEDs in
> check_highspeed() and hub_port_connect_change().]
> Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>

Acked-off-by: Alan Stern <stern@rowland.harvard.edu>

Is there some reason why schedule_delayed_work() doesn't use the 
power-efficient work queue by default?

Alan Stern

Re: [RFC PATCHv2] usb: move hub init and LED blink work to power efficient workqueue

[Zoran Markovic]

I believe there may still be use cases where you want to wake up the
same CPU that scheduled the work.

Thanks for the Ack. Can you please queue this for 3.14?

Regards, Zoran

On 2 February 2014 08:10, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Sat, 1 Feb 2014, Zoran Markovic wrote:
>
>> From: Shaibal Dutta <shaibal.dutta@broadcom.com>
>>
>> Allow the scheduler to select the best CPU to handle hub initalization
>> and LED blinking work. This extends idle residency times on idle CPUs
>> and conserves power.
>>
>> This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
>>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: Alan Stern <stern@rowland.harvard.edu>
>> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
>> Cc: Xenia Ragiadakou <burzalodowa@gmail.com>
>> Cc: Julius Werner <jwerner@chromium.org>
>> Cc: Krzysztof Mazur <krzysiek@podlesie.net>
>> Cc: Matthias Beyer <mail@beyermatthias.de>
>> Cc: Dan Williams <dan.j.williams@intel.com>
>> Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
>> Cc: Thomas Pugliese <thomas.pugliese@gmail.com>
>> Signed-off-by: Shaibal Dutta <shaibal.dutta@broadcom.com>
>> [zoran.markovic@linaro.org: Rebased to latest kernel. Added commit message.
>> Changed reference from system to power efficient workqueue for LEDs in
>> check_highspeed() and hub_port_connect_change().]
>> Signed-off-by: Zoran Markovic <zoran.markovic@linaro.org>
>
> Acked-off-by: Alan Stern <stern@rowland.harvard.edu>
>
> Is there some reason why schedule_delayed_work() doesn't use the
> power-efficient work queue by default?
>
> Alan Stern
>

Re: [RFC PATCHv2] usb: move hub init and LED blink work to power efficient workqueue

[Alan Stern]

Please don't top-post.

On Fri, 7 Feb 2014, Zoran Markovic wrote:

> I believe there may still be use cases where you want to wake up the
> same CPU that scheduled the work.

Won't the majority of cases not care which CPU is used?  Therefore,
shouldn't the default behavior be to use the power-efficient work
queue?

> Thanks for the Ack. Can you please queue this for 3.14?

That's up to Greg KH.  He may decide it's not important enough to go 
into 3.14, and delay it until 3.15.

Alan Stern

Re: [RFC PATCHv2] usb: move hub init and LED blink work to power efficient workqueue

[Greg Kroah-Hartman]

On Fri, Feb 07, 2014 at 10:20:57AM -0500, Alan Stern wrote:
> Please don't top-post.
> 
> On Fri, 7 Feb 2014, Zoran Markovic wrote:
> 
> > I believe there may still be use cases where you want to wake up the
> > same CPU that scheduled the work.
> 
> Won't the majority of cases not care which CPU is used?  Therefore,
> shouldn't the default behavior be to use the power-efficient work
> queue?
> 
> > Thanks for the Ack. Can you please queue this for 3.14?
> 
> That's up to Greg KH.  He may decide it's not important enough to go 
> into 3.14, and delay it until 3.15.

It's 3.15 material, as it doesn't fix a regression at this point in
time.

I'll queue it up when I get to it in a week or so, thanks.

greg k-h