Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-05-25 Thread Olof Johansson
On Thu, May 25, 2006 at 10:59:40AM -0700, Olof Johansson wrote: > Is there a specific reason for why you chose to export 3 different > memcpu calls? They're all just wrapped to the same internals. > > It would seem to make sense to have the client do their own > page_address(page) + offset calcula

Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-05-25 Thread Olof Johansson
Hi, On Tue, May 23, 2006 at 05:20:12PM -0700, Chris Leech wrote: > +EXPORT_SYMBOL(dma_async_memcpy_buf_to_buf); > +EXPORT_SYMBOL(dma_async_memcpy_buf_to_pg); > +EXPORT_SYMBOL(dma_async_memcpy_pg_to_pg); Is there a specific reason for why you chose to export 3 different memcpu calls? They're all

Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-05-23 Thread Nathan Lynch
Andrew Morton wrote: > Chris Leech <[EMAIL PROTECTED]> wrote: > > > > + for_each_cpu(i) > > That's about to be deleted. Please use for_each_possible_cpu(). > > That's if for_each_possible_cpu() is appropriate. It is -- those loops traverse chan->local, which is alloc_percpu'd, which allocates

Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-05-23 Thread Andrew Morton
Chris Leech <[EMAIL PROTECTED]> wrote: > > +/** > + * dma_client_chan_free - release a DMA channel > + * @chan: &dma_chan > + */ > +void dma_chan_cleanup(struct kref *kref) > +{ > +struct dma_chan *chan = container_of(kref, struct dma_chan, refcount); > +chan->device->device_free_cha

Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-05-23 Thread Andrew Morton
Chris Leech <[EMAIL PROTECTED]> wrote: > > + for_each_cpu(i) That's about to be deleted. Please use for_each_possible_cpu(). That's if for_each_possible_cpu() is appropriate. Perhaps it should be using for_each_present_cpu(), or for_each_online_cpu(). That's why for_each_cpu() is going awa

[PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-05-23 Thread Chris Leech
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 | 408 +++

[PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-05-08 Thread Chris Leech
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 | 408 +++

Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-03-31 Thread Andrew Grover
On 3/31/06, Kumar Gala <[EMAIL PROTECTED]> wrote: > > Currently the code updates these variables (kept per cpu) every time a > > copy is queued. See include/linux/dmaengine.h. > > Might it be better to update when the transfer is done incase of an > error? The queueing function is really in the be

Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-03-31 Thread Kumar Gala
On Mar 31, 2006, at 2:04 PM, Andrew Grover wrote: On 3/31/06, Ingo Oeser <[EMAIL PROTECTED]> wrote: Kumar Gala wrote: Fair, but wouldn't it be better to have the association per client. Maybe leave the one as a summary and have a dir per client with similar stats that are for each client and

Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-03-31 Thread Andrew Grover
On 3/31/06, Ingo Oeser <[EMAIL PROTECTED]> wrote: > Kumar Gala wrote: > > Fair, but wouldn't it be better to have the association per client. > > > > Maybe leave the one as a summary and have a dir per client with > > similar stats that are for each client and add a per channel summary > > at the t

Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-03-31 Thread Ingo Oeser
Kumar Gala wrote: > On Mar 30, 2006, at 12:36 PM, Andrew Grover wrote: > > Wellit's true they're useful for debugging but I would put them in > > the category of system statistics that shouldn't go in debugfs. I > > think they are like /proc/interrupts' interrupt counts or the TX/RX > > stats r

Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-03-30 Thread Kumar Gala
On Mar 30, 2006, at 12:36 PM, Andrew Grover wrote: On 3/30/06, Kumar Gala <[EMAIL PROTECTED]> wrote: What is the utility of exporting memcpy_count, and bytes_transferred to userspace via sysfs? Is this really for debug (and thus should be under debugfs?) Wellit's true they're useful for

Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-03-30 Thread Andrew Grover
On 3/30/06, Kumar Gala <[EMAIL PROTECTED]> wrote: > What is the utility of exporting memcpy_count, and bytes_transferred > to userspace via sysfs? Is this really for debug (and thus should be > under debugfs?) Wellit's true they're useful for debugging but I would put them in the category of

Re: [PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-03-30 Thread Kumar Gala
On Mar 29, 2006, at 4:55 PM, Chris Leech wrote: 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 |

[PATCH 1/9] [I/OAT] DMA memcpy subsystem

2006-03-29 Thread Chris Leech
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 | 405 +++