On Mar 29, 2006, at 5:05 PM, Andrew Grover wrote:
On 3/28/06, Kumar Gala [EMAIL PROTECTED] wrote:
Do you only get callback when a channel is available?
Yes
How do you
decide to do to provide PIO to the client?
The client is responsible for using any channels it gets, or falling
back to
On 3/30/06, Kumar Gala [EMAIL PROTECTED] wrote:
I was under the impression that the DMA engine would provide a sync
cpu based memcpy (PIO) if a real HW channel wasn't avail, if this is
left to the client that's fine. So how does the client know he
should use normal memcpy()?
It has to keep
On 3/28/06, Kumar Gala [EMAIL PROTECTED] wrote:
Do you only get callback when a channel is available?
Yes
How do you
decide to do to provide PIO to the client?
The client is responsible for using any channels it gets, or falling
back to memcpy() if it doesn't get any. (I don't understand how
On 3/16/06, Kumar Gala [EMAIL PROTECTED] wrote:
It would seem that when a client registers (or shortly there after
when they call dma_async_client_chan_request()) they would expect to
get the number of channels they need by some given time period.
For example, lets say a client registers but
On Mar 28, 2006, at 12:44 PM, Andrew Grover wrote:
On 3/16/06, Kumar Gala [EMAIL PROTECTED] wrote:
It would seem that when a client registers (or shortly there after
when they call dma_async_client_chan_request()) they would expect to
get the number of channels they need by some given time
On 3/28/06, Kumar Gala [EMAIL PROTECTED] wrote:
Also, what do you think about adding an operation type (MEMCPY, XOR,
CRYPTO_AES, etc). We can than validate if the operation type
expected is supported by the devices that exist.
No objections, but this speculative support doesn't need to
On Mar 28, 2006, at 4:01 PM, Andrew Grover wrote:
On 3/28/06, Kumar Gala [EMAIL PROTECTED] wrote:
Also, what do you think about adding an operation type (MEMCPY,
XOR,
CRYPTO_AES, etc). We can than validate if the operation type
expected is supported by the devices that exist.
No
Hi!
--- /dev/null
+++ b/drivers/dma/dmaengine.c
@@ -0,0 +1,360 @@
+/*
+Copyright(c) 2004 - 2006 Intel Corporation. All rights reserved.
+
+This program is free software; you can redistribute it and/or modify it
Chris Leech [EMAIL PROTECTED] wrote:
+void dma_async_device_cleanup(struct kref *kref);
Declarations go in header files, please. Or give it static scope.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Provides an API for offloading memory copies to DMA devices
Signed-off-by: Chris Leech [EMAIL PROTECTED]
---
drivers/Kconfig |2
drivers/Makefile |1
drivers/dma/Kconfig | 13 ++
drivers/dma/Makefile |1
drivers/dma/dmaengine.c | 360
On Fri, Mar 03, 2006 at 01:42:20PM -0800, Chris Leech wrote:
+void dma_async_device_unregister(struct dma_device* device)
+{
...
+ kref_put(device-refcount, dma_async_device_cleanup);
+ wait_for_completion(device-done);
+}
This looks like a bug: device is dereferenced after it is
From: Chris Leech [EMAIL PROTECTED]
Date: Fri, 03 Mar 2006 13:42:20 -0800
+static spinlock_t dma_list_lock;
Please use DEFINE_SPINLOCK().
+static void dma_chan_free_rcu(struct rcu_head *rcu) {
Newline before the brace please.
+static void dma_async_device_cleanup(struct kref *kref) {
12 matches
Mail list logo
