Optimize performance for single irq
Changes since v2.
* Rebase on mmc-next, change of line numbers no code changes.
Stefan Nilsson XK (1):
sdio: optimized SDIO IRQ handling for single irq
drivers/mmc/core/sdio_irq.c | 33 -
include/linux/mmc/card.h|1
From: Stefan Nilsson XK
If there is only 1 function interrupt registered it is possible to
improve performance by directly calling the irq handler
and avoiding the overhead of reading the CCCR registers.
Signed-off-by: Per Forlin
Acked-by: Ulf Hansson
Reviewed-by: Nicolas Pitre
---
drivers/m
Hi Per,
On Wed, May 11 2011, Per Forlin wrote:
> Optimize performance for single irq
>
> Changes since v2.
> * Rebase on mmc-next, change of line numbers no code changes.
>
> Stefan Nilsson XK (1):
> sdio: optimized SDIO IRQ handling for single irq
>
> drivers/mmc/core/sdio_irq.c | 33 ++
Optimize performance for single irq
Changes since v4.
* Proper rebase on mmc-next. In previous patch, a spelling-patch in sdio_irq
was accidentally rebased on top as well causing merge conflict.
Stefan Nilsson XK (1):
sdio: optimized SDIO IRQ handling for single irq
drivers/mmc/core/sdio_
From: Stefan Nilsson XK
If there is only 1 function interrupt registered it is possible to
improve performance by directly calling the irq handler
and avoiding the overhead of reading the CCCR registers.
Signed-off-by: Per Forlin
Acked-by: Ulf Hansson
Reviewed-by: Nicolas Pitre
---
drivers/m
Hi Per,
On Wed, May 11 2011, Per Forlin wrote:
> From: Stefan Nilsson XK
>
> If there is only 1 function interrupt registered it is possible to
> improve performance by directly calling the irq handler
> and avoiding the overhead of reading the CCCR registers.
>
> Signed-off-by: Per Forlin
> Ack
On Sat, May 7, 2011 at 12:39 AM, Nicolas Pitre wrote:
> On Fri, 6 May 2011, Ramana Radhakrishnan wrote:
>
>> On 6 May 2011 16:06, Ken Werner wrote:
>> >
>> > Currently the GCC ARM backend doesn't provide a pattern to inline 64bit
>> > __sync_* functions but the compiler emits __sync_*_8 function
On Wed, May 11, 2011 at 5:57 AM, Rajendra Nayak wrote:
> Quite often in the kernel, there are instances of clk_get calls
> being made with a NULL struct device pointer being passed.
> Not checking for such cases could lead to a NULL pointer
> dereference.
>
> Signed-off-by: Rajendra Nayak
Thanks
v6: typo fixes
v5: clarified that dtb should be aligned on a 64 bit boundary in RAM.
v3: added details to Documentation/arm/Booting
Acked-by: Tony Lindgren
Signed-off-by: Grant Likely
---
Documentation/arm/Booting | 33 ++--
Documentation/devicetree/booting-w
The dtb is passed to the kernel via register r2, which is the same
method that is used to pass an atags pointer. This patch modifies
__vet_atags to not clear r2 when it encounters a dtb image.
v2: fixed bugs pointed out by Nicolas Pitre
Tested-by: Tony Lindgren
Signed-off-by: Grant Likely
---
In preparation for adding device tree support, this patch consolidates
all of the atag-specific setup into a single function.
v5: - drop double printk("Machine; %s\n", ...); call.
- leave copying boot_command_line in setup_arch() since it isn't
atags specific.
v4: - adapt to the removal
Add some basic empty infrastructure for DT support on ARM.
v5: - Fix off-by-one error in size calculation of initrd
- Stop mucking with cmd_line, and load command line from dt into
boot_command_line instead which matches the behaviour of ATAGS booting
v3: - moved cmd_line export and init
If a dtb is passed to the kernel then the kernel needs to iterate
through compiled-in mdescs looking for one that matches and move the
dtb data to a safe location before it gets accidentally overwritten by
the kernel.
This patch creates a new function, setup_machine_fdt() which is
analogous to the
Hi Russell,
Here's the current state of the device tree patches for basic
infrastructure support. It's pretty much the same as the last series
I sent to you, except I've dropped the patches that add .dts files and
board support simply because the final location for storing .dtb files
is still up
On Wed, May 11, 2011 at 10:44:49PM +0200, Grant Likely wrote:
> Right now it merges cleanly with linux-next and the resulting tree
> builds and boots at least on qemu. Unless you really object, I'm
> going to ask Stephen to add the following branch to the /end/ of the
> list of trees for linux-nex
Hi
I am using Linaro gcc on Ubuntu/ARM. I am having a problem in building
a package that does not support thumb nor thumb2. When I typed "gcc -v"
I saw that "–with-mode=thumb" and I assume that means my gcc compiler
will try to optimize some code in thumb. So I assume I need to make my
Linaro comp
On Thursday, 12 May 2011, AKS wrote:
>
> What flag I have to pass in making? I mean what to type in after CCFLAGS=
> in make or what to be added in Makefile. Thanks!
Try using -marm.
Ramana
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linar
Dear Zach,
In message you wrote:
>
> Would you be able to join us at UDS
> (https://wiki.linaro.org/Events/2011-05-LDS)? We can also set up a
> conference line as well.
As discussed, I'll try and attend remotely.
But Heiko Schocher, one of our engineers, will be there and attend
both the linar
18 matches
Mail list logo
