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 period.
For example, lets say a client registers but no dma device exists.
They will never get called to be aware of this condition.
I would think most clients would either spin until they have all the
channels they need or fall back to a non-async mechanism.
Clients *are* expected to fall back to non-async if they are not given
channels. The reason it was implemented with callbacks for
added/removed was that the client may be initializing before the
channels are enumerated. For example, the net subsystem will ask for
channels and not get them for a while, until the ioatdma PCI device is
found and its driver loads. In this scenario, we'd like the net
subsystem to be given these channels, instead of them going unused.
Fair, I need to think on that a little more.
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 be in our
initial patchset.
I don't consider it speculative. The patch is for a generic DMA
engine interface. That interface should encompass all users. I have
a security/crypto DMA engine that I'd like to front with the generic
DMA interface today. Also, I believe there is another Intel group
with an XOR engine that had a similar concept called ADMA posted a
while ago.
http://marc.theaimsgroup.com/?t=112603120100004&r=1&w=2
Shouldn't we also have a dma_async_client_chan_free()?
Well we could just define it to be chan_request(0) but it doesn't seem
to be needed. Also, the allocation mechanism we have for channels is
different from alloc/free's semantics, so it may be best to not muddy
the water in this area.
Can you explain what the semantics are.
It's been a little while since I posted so my thoughts on the subject
are going to take a little while to come back to me :)
- kumar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
