From: Stefan Nilsson XK <stefan.xk.nilsson(a)stericsson.com>
If there is only 1 function registered, and IRQ:s are supported and
currently enabled, call the callback handler directly
without checking the CCCR registers.
Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson(a)stericsson.com>
Signed-off-by: Per Forlin <per.forlin(a)linaro.org>
---
drivers/mmc/core/sdio_irq.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index b300161..25291bf 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -32,6 +32,20 @@ static int process_sdio_pending_irqs(struct mmc_card *card)
int i, ret, count;
unsigned char pending;
+ /*
+ * If there is only 1 function registered
+ * call irq directly without checking the CCCR registers.
+ */
+ if ((card->host->caps & MMC_CAP_SDIO_IRQ) &&
+ card->host->sdio_irqs && (card->sdio_funcs == 1))
+ for (i = 0; i < SDIO_MAX_FUNCS; i++) {
+ struct sdio_func *func = card->sdio_func[i];
+ if (func && func->irq_handler) {
+ func->irq_handler(func);
+ return 1;
+ }
+ }
+
ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_INTx, 0, &pending);
if (ret) {
printk(KERN_DEBUG "%s: error %d reading SDIO_CCCR_INTx\n",
--
1.7.4.1
From: Stefan Nilsson XK <stefan.xk.nilsson(a)stericsson.com>
If there is only 1 function registered it is possible to
improve performance by avoiding the overhead of reading the
CCCR registers and directly call the function handler.
Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson(a)stericsson.com>
Signed-off-by: Per Forlin <per.forlin(a)linaro.org>
---
drivers/mmc/core/sdio_irq.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index b300161..25291bf 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -32,6 +32,20 @@ static int process_sdio_pending_irqs(struct mmc_card *card)
int i, ret, count;
unsigned char pending;
+ /*
+ * If there is only 1 function registered
+ * call irq directly without checking the CCCR registers.
+ */
+ if ((card->host->caps & MMC_CAP_SDIO_IRQ) &&
+ card->host->sdio_irqs && (card->sdio_funcs == 1))
+ for (i = 0; i < SDIO_MAX_FUNCS; i++) {
+ struct sdio_func *func = card->sdio_func[i];
+ if (func && func->irq_handler) {
+ func->irq_handler(func);
+ return 1;
+ }
+ }
+
ret = mmc_io_rw_direct(card, 0, 0, SDIO_CCCR_INTx, 0, &pending);
if (ret) {
printk(KERN_DEBUG "%s: error %d reading SDIO_CCCR_INTx\n",
--
1.7.4.1
Enclosed you'll find a link to the agenda, minutes, actions and IRC logs
from the
Linaro kernel working group weekly meetings of May 2 , 2011.
https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-05-02
== Summary ==
* Updates on 11.05 Work Items
* Cycle 11.11 LDS sessions setup and ownership
Regards,
Mounir
Every time I boot plymouth is always killed by SEGV
Every few reboots the system will hang without continuing to boot at this
message:
init: udev-fallback-graphics main process (993) terminated with status 1
init: plymouth main process (538) killed by SEGV signal
init: plymouth-splash main process (998) terminated with status 2
init: plymouth-log main process (1026) terminated with status 1
Sometimes the system will hang during reboot as well, I think it may be
related to `plymouth-stop`, but I don't have strong evidence of that
currently.
My kernel config has only very minimal changes from `omap2plus_defconfig`
- enabling devtmpfs and automounting it
- disabling omap2, omap4, etc, except omap3
- disabling all boards except for overo
I don't think that plymouth is a particularly necessary service (especially
since I don't have a display), so my temporary solution is to disable it
like so:
cd /etc/init
ls plymouth*.conf | while read CONF
do
mv ${CONF} ${CONF}.off
done
Can anyone offer me any suggestions?
AJ ONeal
On behalf of the Linaro Infrastructure team I'm pleased to announce the
release of Linaro Image Tools 0.4.4.
Linaro Image Tools offer a set of tools for use with Linaro images.
Highlights of this release:
* Support for EfikaMX boards has been added
* Support for i.MX53 LOCO board has been added
* Support for SMDKV310 board has been added
* Usage of sudo has been made optional
* Changes to partition alignment
* The original boot script is stored in the boot partition
* Improvements to the btrfs support
* Support for multiple kernel have been added, in particular
for i.MX53, i.MX51 and OMAP4; also properly fixes U8500
* RAM size on Panda has been increased
* Support for device tree binaries has been added
The source tarball is available from:
https://launchpad.net/linaro-image-tools/trunk/0.4.4
Thanks,
Mattias Backman
I'm drafting the blueprint [1], and need your favors to collect LTP
(Linux Test Project [2]) result on boards that Linaro supports with
Natty kernel running on.
The example steps of the testing (I did on i.mx51 babbage with Beta-2
linaro-n-developer) are documented on Whiteboard of [1]. Please help
run the test on the boards you have except i.mx51, and send me the result.
I appreciate the effort.
[1] https://blueprints.launchpad.net/linux-linaro/+spec/linaro-kernel-o-ras-fix…
[2] http://ltp.sourceforge.net/
--
Regards,
Shawn
Hello all,
I want to introduce myself to the linaro-kernel and linaro-dev lists as I
just started at Linaro today in the role of Kernel Working Group Technical
Lead and will be working closely with all of you on enhancing the ARM Linux
ecosystem. I've been using Linux since 1993 and working with the Linux
kernel for over 10 years for a variety of companies including silicon
vendors, OSVs, and device vendors with a broad variety of experience
including ARM CPU and board bring up, hacking on a variety of device
drivers, maintaining a distro kernel, maintaining a few ARM
sub-architectures, educating HW vendors and new developers about the open
source development model, etc. I've been a bit out of the loop of the open
source community the last 1-2 years and am really excited to be involved
with Linaro working on community-focused technology enablement and
enhancement.
I expect this first week to be mostly focused on reading up on process,
existing deliverables, mailing list archives, etc to wrap my head around
where we are right now and where we're headed with the 11.11 release. I'll
be at LDS and look forward to meeting many of you next week and I want to
encourage anyone who won't be at LDS but has concerns, ideas, questions
related to the kernel WG to drop me an email.
Thanks!
~Deepak