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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.