Hi,
> +/*
> + * This file provides Date & Time support (no alarms) for PT7C4338 chip.
> + *
> + * This file is based on drivers/rtc/rtc-ds1307.c
Please explain why you can't use rtc-ds1307 directly (or with slight
modifications). I might have missed something but the register-set looks
identical
Hello all,
I'm trying to use the vmsplice/splice combination to so socket writes in
zero-copy mode since it seems to be the big
bottle neck in my application.
Here's a simplified code:
// This buffer is actually outside kernel space,
// in reserved contiguous physical memory (custom kernel comp
Signed-off-by: Alexandre Bounine
Cc: Matt Porter
---
MAINTAINERS |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6f99e12..f9630d6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5164,6 +5164,7 @@ F:drivers/char/random.c
RAPIDIO
The dmatest code relies on the DMAEngine API to automatically call
dma_unmap_single() on src buffers. The flags it passes are incorrect,
fix them.
Signed-off-by: Ira W. Snyder
---
drivers/dma/dmatest.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/dma
This is a purely cosmetic cleanup. It is nice to have related functions
right next to each other in the code.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 116 +++--
1 files changed, 64 insertions(+), 52 deletions(-)
diff --git a/drivers/d
Hello everyone,
I've been chasing random infrequent controller lockups in the fsldma driver
for a long time. I finally managed to find the problem and fix it. I'm not
quite sure about the exact sequence of events which causes the race
condition, but it is related to using the hardware registers to
This adds better tracking to link descriptor allocations, callbacks, and
frees. This makes it much easier to track errors with link descriptors.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/dri
This makes debugging the driver much easier when multiple channels are
running concurrently. In addition, you can see how much descriptor
memory each channel has allocated via the dmapool API in sysfs.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 69 +
The original dma_halt() function set the CA (channel abort) bit on both
the 83xx and 85xx controllers. This is incorrect on the 83xx, where this
bit means TEM (transfer error mask) instead. The 83xx doesn't support
channel abort, so we only do this operation on 85xx.
Signed-off-by: Ira W. Snyder
This fixes some minor violations of the coding style. It also changes
the style of the device_prep_dma_*() function definitions so they are
identical.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 29 +
drivers/dma/fsldma.h |4 ++--
2 files changed, 15
Enabling poisoning in the dmapool API quickly showed that the DMA
controller was fetching descriptors that should not have been in use.
This has caused intermittent controller lockups during testing.
I have been unable to figure out the exact set of conditions which cause
this to happen. However,
Previous to this patch, the dma_run_dependencies() function has been
called while holding desc_lock. This function can call tx_submit() for
other descriptors, which may try to re-grab the lock. Avoid this by
moving the descriptors to be cleaned up to a temporary list, and
dropping the lock before c
This merges the fsl_chan_ld_cleanup() function into the dma_do_tasklet()
function to reduce locking overhead. In the best case, we will be able
to keep the DMA controller busy while we are freeing used descriptors.
In all cases, the spinlock is grabbed two times fewer than before on
each transactio
On upcoming hardware, we have a PCI adapter with two functions, one of
which uses MSI and the other uses MSI-X. This adapter, when MSI is
disabled using the "old" firmware interface (RTAS_CHANGE_FN), still
signals an MSI-X interrupt and triggers an EEH. We are working with the
vendor to ensure that
The RTAS IRQ fixup code relies on a less-than-clear edge condition for
verifying a given device is not using MSI or MSI-X. Make that more clear
with a comment.
Signed-off-by: Nishanth Aravamudan
Cc: Milton Miller
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
---
arch/powerpc/platforms/pserie
On 03.03.2011 [11:39:23 -0800], Nishanth Aravamudan wrote:
> On upcoming hardware, we have a PCI adapter with two functions, one of
> which uses MSI and the other uses MSI-X. This adapter, when MSI is
> disabled using the "old" firmware interface (RTAS_CHANGE_FN), still
> signals an MSI-X interrupt
From: Richard Cochran
Date: Mon, 28 Feb 2011 08:57:03 +0100
> This really might be the last review of the PTP hardware clock patch
> series. These patches apply on top of the timers/core branch in the
> tip tree.
I'm find with the networking portions so:
Acked-by: David S. Miller
I am assumin
On Thu, Mar 3, 2011 at 9:54 AM, Ira W. Snyder wrote:
> Previous to this patch, the dma_run_dependencies() function has been
> called while holding desc_lock. This function can call tx_submit() for
> other descriptors, which may try to re-grab the lock. Avoid this by
> moving the descriptors to be
On Wed, 2011-03-02 at 11:20 -0600, Tseng-Hui (Frank) Lin wrote:
> Move SPRN_PID declearations in various locations into one place.
Applied.
> Signed-off-by: Tseng-Hui (Frank) Lin
>
> ---
> arch/powerpc/include/asm/reg.h | 10 ++
> arch/powerpc/include/asm/reg_booke.h |3 ---
On Wed, 2011-03-02 at 11:20 -0600, Tseng-Hui (Frank) Lin wrote:
> +#define CPU_FTR_ICSWX LONG_ASM_CONST(0x1000)
Do we want a userspace visible feature as well ? Or some other way to
inform userspace that we support icswx ?
> index acac35d..b0c2549 100644
> --- a/arc
On Thu, 2011-03-03 at 11:39 -0800, Nishanth Aravamudan wrote:
> On upcoming hardware, we have a PCI adapter with two functions, one of
> which uses MSI and the other uses MSI-X. This adapter, when MSI is
> disabled using the "old" firmware interface (RTAS_CHANGE_FN), still
> signals an MSI-X interr
On 04.03.2011 [12:05:29 +1100], Michael Ellerman wrote:
> On Thu, 2011-03-03 at 11:39 -0800, Nishanth Aravamudan wrote:
> > On upcoming hardware, we have a PCI adapter with two functions, one of
> > which uses MSI and the other uses MSI-X. This adapter, when MSI is
> > disabled using the "old" firm
On Thu, 2011-03-03 at 17:41 -0800, Nishanth Aravamudan wrote:
> On 04.03.2011 [12:05:29 +1100], Michael Ellerman wrote:
> > On Thu, 2011-03-03 at 11:39 -0800, Nishanth Aravamudan wrote:
> > > On upcoming hardware, we have a PCI adapter with two functions, one of
> > > which uses MSI and the other u
On Thu, 2011-03-03 at 17:41 -0800, Nishanth Aravamudan wrote:
> On 04.03.2011 [12:05:29 +1100], Michael Ellerman wrote:
> > On Thu, 2011-03-03 at 11:39 -0800, Nishanth Aravamudan wrote:
> > > On upcoming hardware, we have a PCI adapter with two functions, one of
..
> > > Signed-off-by: Nishanth Ara
On Fri, 2011-03-04 at 14:06 +1100, Michael Ellerman wrote:
> On Thu, 2011-03-03 at 17:41 -0800, Nishanth Aravamudan wrote:
> > On 04.03.2011 [12:05:29 +1100], Michael Ellerman wrote:
> > > Cc: Me :)
> > Sorry! I was in a hurry to get this out the door, my fault. Note, you
> > don't show up per scr
On 04.03.2011 [14:01:24 +1100], Michael Ellerman wrote:
> On Thu, 2011-03-03 at 17:41 -0800, Nishanth Aravamudan wrote:
> > On 04.03.2011 [12:05:29 +1100], Michael Ellerman wrote:
> > > On Thu, 2011-03-03 at 11:39 -0800, Nishanth Aravamudan wrote:
> > > > On upcoming hardware, we have a PCI adapter
26 matches
Mail list logo
