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

On Mar 29, 2006, at 5:05 PM, Andrew Grover wrote:

On 3/28/06, Kumar Gala [off-list ref] wrote:

quoted

Do you only get callback when a channel is available?

Yes

quoted

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 PIO
comes into the picture..?)

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()?

quoted

A client should only request multiple channel to handle multiple
concurrent operations.

Correct, if there aren't any CPU concurrency issues then 1 channel
will use the device's full bandwidth (unless some other client has
acquired the other channels and is using them, of course.)

quoted

quoted

This gets around the problem of DMA clients registering (and  
therefore
not getting) channels simply because they init before the DMA device
is discovered.

What do you expect to happen in a system in which the channels are
over subscribed?

Do you expect the DMA device driver to handle scheduling of channels
between multiple clients?

It does the simplest thing that could possibly work right now:
channels are allocated first come first serve. When there is a need,
it should be straightforward to allow multiple clients to share DMA
channels.

Sounds good for a start.  Have you given any thoughts on handling  
priorities between clients?

I need to take a look at the latest patches. How would you guys like  
modifications?

- k