On Thu, Aug 22, 2013 at 02:43:38PM -0700, David Hawkins wrote:
> Hi S.Saravanan,
>
> > I have a custom board with four MPC8640 nodes connected over
> > a transparent PCI express switch . In this configuration one node is
> > configured as host(Root Complex) and others as agents(End Point). Thus
>
On Thu, Apr 11, 2013 at 12:39:00PM -0600, Chris Friesen wrote:
> On 04/11/2013 12:12 PM, Kumar Gala wrote:
> >
> > On Apr 11, 2013, at 10:44 AM, Chris Friesen wrote:
> >
> >>
> >> Hi all,
> >>
> >> We've got a powerpc system that uses u-boot. In our environment on
> >> bootup u-boot does a DHCP to
On Thu, Aug 09, 2012 at 04:19:35PM +0800, qiang@freescale.com wrote:
> Hi all,
>
> The following 8 patches enabling fsl-dma and talitos offload raid
> operations for improving raid performance and balancing CPU load.
>
> These patches include talitos, fsl-dma and carma module (caram uses
> so
: the bad descriptors are only for simulating an exception interrupt.
> This case can illustrate the potential risk in current fsl-dma very well.
>
> Cc: Dan Williams
> Cc: Dan Williams
> Cc: Vinod Koul
> Cc: Li Yang
> Signed-off-by: Qiang Liu
> Signed-off-by: Ira W. Snyd
On Thu, Aug 02, 2012 at 07:21:51AM +, Liu Qiang-B32616 wrote:
> > -Original Message-
> > From: Ira W. Snyder [mailto:i...@ovro.caltech.edu]
> > Sent: Thursday, August 02, 2012 1:25 AM
> > To: Liu Qiang-B32616
> > Cc: linux-cry...@vger.kernel.org; linuxp
e() to spin_lock_bh(). All
manipulation of protected fields is done using tasklet context or
weaker, which makes spin_lock_bh() the correct choice.
"""
Other than that,
Acked-by: Ira W. Snyder
> Cc: Dan Williams
> Cc: Vinod Koul
> Cc: Li Yang
> Cc: Timur T
On Wed, Aug 01, 2012 at 04:50:27PM +0800, qiang@freescale.com wrote:
> From: Qiang Liu
>
> Fix a warning of unitialized value when compile with -Wuninitialized.
>
Looks good to me.
Acked-by: Ira W. Snyder
> Cc: Dan Williams
> Cc: Vinod Koul
> Cc: Li Yang
>
hardware will halt
in response to a programming error, and generate a PE interrupt. See
section 12.5.3.3 (pg 568).
The driver, as it is written, will never recover from such a condition.
Since you are complaining about this situation, do you intend to fix it?
> Cc: Dan Williams
> Cc: Da
ldma driver exclusively.
> Cc: Dan Williams
> Cc: Vinod Koul
> Cc: Li Yang
> Signed-off-by: Qiang Liu
> Acked-by: Ira W. Snyder
> ---
> drivers/dma/fsldma.c | 31 ---
> 1 files changed, 0 insertions(+), 31 deletions(-)
>
> diff
On Wed, Aug 01, 2012 at 04:49:43PM +0800, qiang@freescale.com wrote:
> From: Qiang Liu
>
> Move the function fsldma_cleanup_descriptor() and fsl_chan_xfer_ld_queue()
> ahead of its invoke function for avoiding redundant definition.
>
> Cc: Dan Williams
> Cc: Vinod Koul
> Cc: Li Yang
> Sig
From: "Ira W. Snyder"
These drivers set the DMA_INTERRUPT capability bit when requesting a DMA
controller channel. This was historical, and is no longer needed.
Recent changes to the drivers/dma/fsldma.c driver have removed support
for this flag. This makes the carma drivers unable
From: Qiang Liu
Fix a warning of unitialized value when compile with -Wuninitialized.
Cc: Dan Williams
Cc: Vinod Koul
Cc: Li Yang
Signed-off-by: Qiang Liu
Cc: Kim Phillips
---
drivers/dma/fsldma.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/fsldma.
From: "Ira W. Snyder"
The current fsldma driver does not support the async_tx API. This is due
to a bug: all descriptors are released when the hardware is finished
with them. The async_tx API requires that the ACK bit is set by software
before descriptors are freed.
This bug is
From: "Ira W. Snyder"
This function will be modified in the next patch in the series. By
moving the function in a patch separate from the changes, it will make
review easier.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 96 +--
From: "Ira W. Snyder"
The use of spin_lock_irqsave() was a stronger locking mechanism than was
actually needed in many cases.
As the current code is written, spin_lock_bh() everywhere is sufficient.
The next patch in this series will add some code to hardware interrupt
context. Thi
From: "Ira W. Snyder"
There are several places where descriptors are freed using identical
code. Put this code into a function to reduce code duplication.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 32 ++--
1 files changed, 14 inserti
From: Qiang Liu
Delete attribute DMA_INTERRUPT because fsl-dma doesn't support this function,
exception will be thrown if talitos is used to offload xor at the same time.
Cc: Dan Williams
Cc: Vinod Koul
Cc: Li Yang
Signed-off-by: Qiang Liu
Acked-by: Ira W. Snyder
---
drivers/dma/fsl
From: "Ira W. Snyder"
Hello everyone,
This is my alternative (simpler) attempt at solving the problems reported
by Qiang Liu with the async_tx API and MD RAID hardware offload support
when using the Freescale DMA driver.
The bug is caused by this driver freeing descriptors before
On Tue, Jul 31, 2012 at 04:09:28AM +, Liu Qiang-B32616 wrote:
> > -Original Message-
> > From: Ira W. Snyder [mailto:i...@ovro.caltech.edu]
> > Sent: Tuesday, July 31, 2012 5:10 AM
> > To: Liu Qiang-B32616
> > Cc: linux-cry...@vger.kernel.org; linuxppc-
ta+0xa0/0x17c
> [ecf41d70] [c0421cf4] __raid_run_ops+0x874/0xe10
> [ecf41df0] [c0426ee4] handle_stripe+0x820/0x25e8
> [ecf41e90] [c0429080] raid5d+0x3d4/0x5b4
> [ecf41f40] [c04329b8] md_thread+0x138/0x16c
> [ecf41f90] [c008277c] kthread+0x8c/0x90
> [ecf41ff0] [c0011630] kernel_thread+0x
On Mon, Jul 30, 2012 at 12:48:41PM -0500, Timur Tabi wrote:
> qiang@freescale.com wrote:
> >
> > Add memory copy self test when probe device, fsl-dma will be disabled
> > if self test failed.
>
> Is this a real problem that can occur? The DMA driver used to have a
> self-test, but I removed
On Tue, Jul 17, 2012 at 07:06:33AM +, Liu Qiang-B32616 wrote:
> > -Original Message-
> > From: Ira W. Snyder [mailto:i...@ovro.caltech.edu]
> > Sent: Tuesday, July 17, 2012 4:01 AM
> > To: Liu Qiang-B32616
> > Cc: linux-cry...@vger.kernel.org; linuxppc-
: Dan Williams
> Cc: Vinod Koul
> Cc: Li Yang
> Cc: Ira W. Snyder
> Signed-off-by: Qiang Liu
> ---
> drivers/dma/fsldma.c | 378 +
> drivers/dma/fsldma.h |1 +
> 2 files changed, 225 insertions(+), 154 deletion
On Wed, Jul 11, 2012 at 05:01:25PM +0800, Qiang Liu wrote:
> Modify the release process of dma descriptor for avoiding exception when
> enable config NET_DMA, release dma descriptor from 1st to last second, the
> last descriptor which is reserved in current descriptor register may not be
> complete
ese are only the ones which I maintain.
Other than that, you can add my:
Acked-by: Ira W. Snyder
> Cc: Dan Williams
> Cc: Vinod Koul
> Cc: Li Yang
> Signed-off-by: Qiang Liu
> ---
> drivers/dma/fsldma.c | 31 ---
> 1 files changed, 0 insertions
On Wed, Jun 13, 2012 at 05:21:22PM +0200, Guillaume Dargaud wrote:
> Hello all,
> I just updated to the most recent kernel and a driver I wrote last year
> won't compile:
> xad.c:534:2: error: implicit declaration of function
> 'of_register_platform_driver'
>
> I see references to this function
On Thu, Feb 16, 2012 at 01:48:20PM -0600, Timur Tabi wrote:
> Ira W. Snyder wrote:
>
> > No. I don't have the ability to connect my P2020 up to an FPGA to
> > recreate the DMA workload that causes this on my 8349EA. I can run the
> > dmatest module, if you'd l
On Thu, Feb 16, 2012 at 01:34:00PM -0600, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > This leads me to believe that this occurs mostly (but not always)
> > concurrent with the end-of-chain interrupt.
>
> Have you tested this on an 85xx platform?
>
No. I don't h
On Thu, Feb 16, 2012 at 05:50:47PM +, Tabi Timur-B04825 wrote:
> On Thu, Jan 26, 2012 at 2:58 PM, Ira W. Snyder wrote:
> > The mpc8349ea has been observed to generate spurious end of segments
> > interrupts despite the fact that they are not enabled by this driver.
> &g
The mpc8349ea has been observed to generate spurious end of segments
interrupts despite the fact that they are not enabled by this driver.
Check for them and ignore them to avoid a kernel error message.
Signed-off-by: Ira W. Snyder
Cc: Dan Williams
---
Changes v1 -> v2:
- skip the descrip
On Fri, Jan 27, 2012 at 08:25:37AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2012-01-26 at 13:00 -0800, Ira W. Snyder wrote:
> >
> > @@ -970,7 +984,13 @@ static ssize_t data_en_show(struct device *dev, struct
> > device_attribute *attr,
> >
k spinlock. The DMA callback checks the
boolean to know whether to re-enable FPGA interrupts before it returns.
Now that it is fixed, the driver keeps FPGA interrupts disabled when it
expects that they are disabled, fixing the bug.
Signed-off-by: Ira W. Snyder
Cc: Benjamin Herrenschmidt
---
drive
Lockdep occasionally complains with the message:
INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
This is caused by calling videobuf_dma_unmap() under spin_lock_irq(). To
fix the warning, we drop the lock before unmapping and freeing the
buffer.
Signed-off-by: Ira W. Snyder
Cc: Benja
The mpc8349ea has been observed to generate spurious end of segments
interrupts despite the fact that they are not enabled by this driver.
Check for them and ignore them to avoid a kernel error message.
Signed-off-by: Ira W. Snyder
Cc: Dan Williams
---
drivers/dma/fsldma.c | 10 ++
1
On Wed, Jan 11, 2012 at 07:54:55AM +, Shi Xuelin-B29237 wrote:
> Hello Iris,
>
> As we discussed in the previous patch, I add one smp_mb() in fsl_tx_status.
> In my testing with iozone, this smp_mb() could cause 1%~2% performance
> degradation.
> Anyway it is acceptable for me. Do you have an
On Sat, Jan 07, 2012 at 09:50:10AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2012-01-06 at 14:34 -0800, Ira W. Snyder wrote:
> > A kernel oops/panic prints an instruction dump showing several
> > instructions before and after the instruction which caused the
> > oops/pan
ion dump:
<4>[ 51.388186] 7c000110 7cf8 5400077c 552907f6 7d290378 992b0003
4e800020 3801
<4>[ 51.395986] 3d20c03a 9009a114 7c0004ac 3920 <98090000> 4e800020
3803ffd0 2b89
Signed-off-by: Ira W. Snyder
Cc: Paul Mackerras
Cc: Benjamin Herrenschmidt
Cc: linuxpp
On Fri, Dec 02, 2011 at 03:47:27AM +, Shi Xuelin-B29237 wrote:
> Hi Iris,
>
> >I'm convinced that "smp_rmb()" is needed when removing the spinlock. As
> >noted, Documentation/memory-barriers.txt says that stores on one CPU can be
> >observed by another CPU in a different order.
> >Previously,
to provide as
much evidence for this belief as I can, in the form of documentation in
the kernel source tree. If you can cite some documentation that shows I
am wrong, I will happily change my mind!
Ira
> -Original Message-
> From: Ira W. Snyder [mailto:i...@ovro.caltech.edu]
> Sent:
c shouldn't assume it only runs on powerpc. I wouldn't be
surprised to see fsldma running on an iMX someday (ARM processor).
My interpretation says that the change introduces the possibility that
fsl_tx_status() returns the wrong answer for an extremely small time
window, on SMP only, based
It never makes it to main memory before CPU2 fetches the
old value of 19.
I don't think you should see any performance impact from the smp_mb()
operation.
Thanks,
Ira
> -Original Message-
> From: Ira W. Snyder [mailto:i...@ovro.caltech.edu]
> Sent: 2011年11月23日 2:59
>
On Tue, Nov 22, 2011 at 12:55:05PM +0800, b29...@freescale.com wrote:
> From: Forrest Shi
>
> dma status check function fsl_tx_status is heavily called in
> a tight loop and the desc lock in fsl_tx_status contended by
> the dma status update function. this caused the dma performance
>
On Mon, May 23, 2011 at 11:12:41AM +0200, Andre Schwarz wrote:
> Ira,
>
> we have a pretty old PCI device driver here that needs some basic rework
> running on 2.6.27 on several MPC83xx.
> It's a simple char-device with "give me some data" implemented using
> read() resulting in zero-copy DMA to
On Thu, May 19, 2011 at 02:13:41PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2011-02-11 at 15:34 -0800, Ira W. Snyder wrote:
> > Hello everyone,
> >
> > This is the seventh posting of these drivers, taking into account comments
> > from earlier postings. I've
On Fri, May 06, 2011 at 12:00:34PM +, Kushwaha Prabhakar-B32579 wrote:
> Hi,
>
> I want to use this patch as base patch for "FSL 85xx platform" to support
> PCIe Agent.
> The work looks to be little old now. So wanted to understand if any
> development has happened further on it.
>
> In cas
On Wed, Apr 20, 2011 at 09:21:00PM +0200, Schwarz,Andre wrote:
> Hi,
>
> I'm facing an issue with tmpfs mounts on PowerPC (mpc83xx specifically).
>
> After "mount -t tmpfs tmpfs /tmp -o size=16m" I can fill the machine's mem
> (512MiB) until oom becomes active.
>
> I can't see this on any other
On Fri, Apr 08, 2011 at 04:12:13AM -0500, Kumar Gala wrote:
> Grant,
>
> I'm being lazy, can you give any quick insight on the following compile
> warning:
>
> drivers/dma/fsldma.c:1457:2: warning: initialization from incompatible
> pointer type
> drivers/dma/fsldma.c: In function 'fsldma_init'
t;&mpic>;
> interrupts = <23 2>;
> };
> };
>
>
Your DTS file looks fine. It is what I would expect to see. The channels
are not allocated by anything here.
Turning on CONFIG_DMADEVICES_DEBUG may give
On Wed, Apr 06, 2011 at 12:40:58PM -0700, Chuck Ketcham wrote:
> All,
>
> I have a Freescale P2020 Reference Design Board. I am investigating the
> possibility of using the dmaengine capability in the 2.6.32.13 kernel to
> transfer data from memory out onto the PCIe bus. As a first step, I tho
transaction.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 108 +
1 files changed, 46 insertions(+), 62 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 526579d..d300de4 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers
cleanup.
At the same time, add support for automatic unmapping of src and dst
buffers, as offered by the DMAEngine API.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 131 --
1 files changed, 95 insertions(+), 36 deletions(-)
diff --git
explicitly track the state
of the hardware, rather than try to guess what it is doing based on the
register values.
This has passed dmatest with 10 threads per channel, 10 iterations
per thread several times without error. Previously, this would fail
within a few seconds.
Signed-off-by: Ira W
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
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. S
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
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
blems on 85xx controller
- only set correct bits for 83xx in dma_halt()
Ira W. Snyder (9):
dmatest: fix automatic buffer unmap type
fsldma: move related helper functions near each other
fsldma: use channel name in printk output
fsldma: improve link descriptor debugging
fsldma: minor co
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
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
transaction.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 114 +
1 files changed, 49 insertions(+), 65 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 48e48c7..40babc1 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers
cleanup.
At the same time, add support for automatic unmapping of src and dst
buffers, as offered by the DMAEngine API.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 132 --
1 files changed, 95 insertions(+), 37 deletions(-)
diff --git
explicitly track the state
of the hardware, rather than try to guess what it is doing based on the
register values.
This has passed dmatest with 10 threads per channel, 10 iterations
per thread several times without error. Previously, this would fail
within a few seconds.
Signed-off-by: Ira W
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
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. S
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 | 60
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
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
o Felix Radensky for testing on a P2020 (85xx DMA IP core).
I wouldn't have been able to track down the problems on 85xx without his
dilligent testing.
v1 -> v2:
- reordered patches (dmatest change is first now)
- fix problems on 85xx controller
- only set correct bits for 83xx in dma_halt()
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
On Wed, Mar 02, 2011 at 07:49:57AM +0200, Felix Radensky wrote:
> Hi Ira,
>
> On 03/01/2011 09:52 PM, Ira W. Snyder wrote:
> > On Tue, Mar 01, 2011 at 08:55:15AM -0800, Ira W. Snyder wrote:
> >
> > [ big snip ]
> >
> >
> > I'd still like the
On Tue, Mar 01, 2011 at 08:55:15AM -0800, Ira W. Snyder wrote:
[ big snip ]
>
> Thanks, this is exactly what I was going to ask for next. :)
>
> I really don't understand why the P2020 DMA controller isn't behaving
> nicely after my patches.
>
> Can you run a
On Tue, Mar 01, 2011 at 07:52:39AM +0200, Felix Radensky wrote:
> Hi Ira,
>
> On 03/01/2011 02:21 AM, Ira W. Snyder wrote:
> > On Mon, Feb 28, 2011 at 11:27:40PM +0200, Felix Radensky wrote:
> >> Hi Ira,
> >>
> >> On 02/28/2011 11:11 PM, Ira W. Snyder
On Mon, Feb 28, 2011 at 11:27:40PM +0200, Felix Radensky wrote:
> Hi Ira,
>
> On 02/28/2011 11:11 PM, Ira W. Snyder wrote:
> > On Mon, Feb 28, 2011 at 10:15:49PM +0200, Felix Radensky wrote:
> >> Hi Ira,
> >>
> >>> Thank you very much Felix. The dmesg
It looks like you used the dmatest module in multi-channel mode last
time. One channel makes it easier to debug:
modprobe dmatest max_channels=1 threads_per_chan=2 iterations=1
Thanks for your help in debugging this. Hopefully this is the last
patch to test. :)
Ira
>From 58bc23c3b68f8db0aa09
put shows that the controller
never got an interrupt for the second transaction. The patch below has
extra debugging information that may help determine why this happens.
Please apply it and re-run the test.
The last section of dmesg (after "Freeing unused kernel memory") is all
I need.
On Mon, Feb 28, 2011 at 01:36:38PM +0200, Felix Radensky wrote:
> Hi Ira,
>
> I've tried your patches with linux-2.6.38-rc6 on P2020RDB.
> DMA test fails with the following errors if threads_per_chan != 1
>
> dma0chan0-copy1: terminating after 1 tests, 1 failures (status 0)
> dma0chan0-copy2: #0:
explicitly track the state
of the hardware, rather than try to guess what it is doing based on the
register values.
This has passed dmatest with 10 threads per channel, 10 iterations
per thread several times without error. Previously, this would fail
within a few seconds.
Signed-off-by: Ira W
cleanup.
At the same time, add support for automatic unmapping of src and dst
buffers, as offered by the DMAEngine API.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 132 --
1 files changed, 95 insertions(+), 37 deletions(-)
diff --git
transaction.
Signed-off-by: Ira W. Snyder
---
drivers/dma/fsldma.c | 114 +
1 files changed, 49 insertions(+), 65 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 4014790..3dc27a9 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers
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
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 | 60
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
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
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
to see this go into 2.6.39. I think we can get it
reviewed before then. :)
Ira W. Snyder (8):
fsldma: move related helper functions near each other
fsldma: use channel name in printk output
fsldma: improve link descriptor debugging
fsldma: minor codingstyle and consistency fixes
fsldma: fi
On Mon, Feb 14, 2011 at 12:03:59PM +0200, Ohad Ben-Cohen wrote:
> On Mon, Feb 14, 2011 at 12:01 PM, Jamie Iles wrote:
> > On Fri, Feb 11, 2011 at 03:19:51PM -0600, Meador Inge wrote:
> >> 1. Hardware specific bits somewhere under '.../arch/*'. Drivers
> >> for the MPIC message register
worth of
correlation data from the FPGAs. This lowers the realtime scheduling
requirements for the userspace process reading the device.
Signed-off-by: Ira W. Snyder
---
drivers/misc/Kconfig|1 +
drivers/misc/Makefile |1 +
drivers/misc/carma/Kconfig |
This adds support for programming the data processing FPGAs on the OVRO
CARMA board. These FPGAs have a special programming sequence that
requires that we program the Freescale DMA engine, which is only
available inside the kernel.
Signed-off-by: Ira W. Snyder
---
drivers/misc/carma/Kconfig
finished. The PPS
driver will be posted seperately from this patch series; it is very
generic.
Thanks to everyone who has provided comments on earlier versions!
Ira W. Snyder (2):
misc: add CARMA DATA-FPGA Access Driver
misc: add CARMA DATA-FPGA Programmer support
drivers/misc/Kconfig
This adds support for programming the data processing FPGAs on the OVRO
CARMA board. These FPGAs have a special programming sequence that
requires that we program the Freescale DMA engine, which is only
available inside the kernel.
Signed-off-by: Ira W. Snyder
---
drivers/misc/carma/Kconfig
worth of
correlation data from the FPGAs. This lowers the realtime scheduling
requirements for the userspace process reading the device.
Signed-off-by: Ira W. Snyder
---
drivers/misc/Kconfig|1 +
drivers/misc/Makefile |1 +
drivers/misc/carma/Kconfig |
series; it is very
generic.
Thanks to everyone who has provided comments on earlier versions!
Ira W. Snyder (2):
misc: add CARMA DATA-FPGA Access Driver
misc: add CARMA DATA-FPGA Programmer support
drivers/misc/Kconfig|1 +
drivers/misc/Makefile |
On Wed, Feb 09, 2011 at 03:42:31PM -0800, Dmitry Torokhov wrote:
> On Wed, Feb 09, 2011 at 03:35:45PM -0800, Ira W. Snyder wrote:
> > On Wed, Feb 09, 2011 at 10:27:40AM -0800, Dmitry Torokhov wrote:
> >
> > [ snip stuff I've already fixed in the next version ]
On Wed, Feb 09, 2011 at 10:27:40AM -0800, Dmitry Torokhov wrote:
[ snip stuff I've already fixed in the next version ]
> >
> > The requirement is that the device stay open during reconfiguration.
> > This provides for that. Readers just block for as long as the device is
> > not producing data.
On Wed, Feb 09, 2011 at 12:33:25AM -0800, Dmitry Torokhov wrote:
> Hi Ira,
>
> On Tue, Feb 08, 2011 at 03:37:46PM -0800, Ira W. Snyder wrote:
> > This driver allows userspace to access the data processing FPGAs on the
> > OVRO CARMA board. It has two modes of operation:
&g
On Wed, Feb 09, 2011 at 04:30:23PM -, David Laight wrote:
>
> > This driver allows userspace to access the data processing
> > FPGAs on the OVRO CARMA board. It has two modes of operation:
> >
> > 1) random access
> >
> > This allows users to poke any DATA-FPGA registers by using mmap to m
This adds support for programming the data processing FPGAs on the OVRO
CARMA board. These FPGAs have a special programming sequence that
requires that we program the Freescale DMA engine, which is only
available inside the kernel.
Signed-off-by: Ira W. Snyder
---
drivers/misc/carma/Kconfig
worth of
correlation data from the FPGAs. This lowers the realtime scheduling
requirements for the userspace process reading the device.
Signed-off-by: Ira W. Snyder
---
drivers/misc/Kconfig|1 +
drivers/misc/Makefile |1 +
drivers/misc/carma/Kconfig |
posted seperately from this patch series; it is very
generic.
Thanks to everyone who has provided comments on earlier versions!
Ira W. Snyder (2):
misc: add CARMA DATA-FPGA Access Driver
misc: add CARMA DATA-FPGA Programmer support
drivers/misc/Kconfig|1 +
On Tue, Feb 08, 2011 at 09:50:29AM -0800, Dmitry Torokhov wrote:
> On Tue, Feb 08, 2011 at 09:20:46AM -0800, Ira W. Snyder wrote:
> > On Mon, Feb 07, 2011 at 11:33:10PM -0800, Dmitry Torokhov wrote:
> > > > +static void data_free_buffer(struct device *dev,
1 - 100 of 209 matches
Mail list logo
