From: Adam Wozniak <awozniak@irobot.com>
To: <linux-kernel@vger.kernel.org>, <linux-arm@lists.infradead.org>,
<linux-usb@vger.kernel.org>, "Agius, Frank" <fagius@irobot.com>
Subject: high cpu load on omap3 using musb
Date: Wed, 29 Jan 2014 08:44:57 -0800 [thread overview]
Message-ID: <52E93009.1090609@irobot.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]
With a USB 2.0 webcam attached to the OTG port on an OMAP3 (applies to
overo gumstix, beagleboard, probably others) we see a high CPU load in a
kworker thread.
Between 2.6.33 and 2.6.34 musb_core.c changed.
IRQ handlers changed with the result that a worker in musb_core.c got
scheduled far more frequently than needed.
I've included a patch below against 3.7, but i think it'll apply against
mainline.
[I apologize for any whitespace mangling. I've also attached the patch.]
I'd like more eyeballs to tell me if this is right. I'd also like to
know who I need to talk to to get this pushed into mainline.
--Adam
# The MUSB IRQ schedules work on every interrupt.
# This is unnecessary, and causes excessive CPU load.
#
# Here we only schedule work if there is something for
# the worker to do.
Index: git/drivers/usb/musb/musb_core.c
===================================================================
--- git.orig/drivers/usb/musb/musb_core.c
+++ git/drivers/usb/musb/musb_core.c
@@ -925,7 +925,9 @@ b_host:
}
#endif
- schedule_work(&musb->irq_work);
+ if (musb->xceiv->state != musb->xceiv_old_state) {
+ schedule_work(&musb->irq_work);
+ }
return handled;
}
[-- Attachment #2: musb_smartwork.patch --]
[-- Type: text/x-patch, Size: 560 bytes --]
# The MUSB IRQ schedules work on every interrupt.
# This is unnecessary, and causes excessive CPU load.
#
# Here we only schedule work if there is something for
# the worker to do.
Index: git/drivers/usb/musb/musb_core.c
===================================================================
--- git.orig/drivers/usb/musb/musb_core.c
+++ git/drivers/usb/musb/musb_core.c
@@ -925,7 +925,9 @@ b_host:
}
#endif
- schedule_work(&musb->irq_work);
+ if (musb->xceiv->state != musb->xceiv_old_state) {
+ schedule_work(&musb->irq_work);
+ }
return handled;
}
next reply other threads:[~2014-01-29 16:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-29 16:44 Adam Wozniak [this message]
2014-07-21 15:28 ` high cpu load on omap3 using musb Laurent Pinchart
2014-07-21 15:40 ` Felipe Balbi
2014-07-21 18:52 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52E93009.1090609@irobot.com \
--to=awozniak@irobot.com \
--cc=fagius@irobot.com \
--cc=linux-arm@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox