diff options
author | FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> | 2010-03-10 18:23:31 -0500 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2010-03-12 18:52:42 -0500 |
commit | 0acedc124aca35f5cce9d4ee288dc372bf517e09 (patch) | |
tree | 699113a95be38de29457d0cc71139d9c82efba3e /Documentation | |
parent | f41b177157718abe9a93868bb76e47d4a6f3681d (diff) |
dma-mapping.h: add the dma_unmap state API
Adds the following macros:
DECLARE_DMA_UNMAP_ADDR(ADDR_NAME)
DECLARE_DMA_UNMAP_LEN(LEN_NAME)
dma_unmap_addr(PTR, ADDR_NAME)
dma_unmap_addr_set(PTR, ADDR_NAME, VAL)
dma_unmap_len(PTR, LEN_NAME)
dma_unmap_len_set(PTR, LEN_NAME, VAL)
The API corresponds to the pci_unmap state API. We'll move to this new
generic API from the PCI specific API in the long term. As
include/asm-generic/pci-dma-compat.h does, the pci_unmap API simply calls
the new generic API for some time.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: James Bottomley <James.Bottomley@suse.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/DMA-API.txt | 58 |
1 files changed, 58 insertions, 0 deletions
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 364a6cb444a5..29a48fbae779 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt | |||
@@ -472,6 +472,64 @@ void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t dma_addr, | |||
472 | .... | 472 | .... |
473 | 473 | ||
474 | 474 | ||
475 | Part Ie - Optimizing Unmap State Space Consumption | ||
476 | -------------------------------- | ||
477 | |||
478 | On some platforms, dma_unmap_{single,page}() is simply a nop. | ||
479 | Therefore, keeping track of the mapping address and length is a waste | ||
480 | of space. Instead of filling your drivers up with ifdefs and the like | ||
481 | to "work around" this (which would defeat the whole purpose of a | ||
482 | portable API) the following facilities are provided. | ||
483 | |||
484 | Actually, instead of describing the macros one by one, we'll | ||
485 | transform some example code. | ||
486 | |||
487 | 1) Use DEFINE_DMA_UNMAP_{ADDR,LEN} in state saving structures. | ||
488 | Example, before: | ||
489 | |||
490 | struct ring_state { | ||
491 | struct sk_buff *skb; | ||
492 | dma_addr_t mapping; | ||
493 | __u32 len; | ||
494 | }; | ||
495 | |||
496 | after: | ||
497 | |||
498 | struct ring_state { | ||
499 | struct sk_buff *skb; | ||
500 | DEFINE_DMA_UNMAP_ADDR(mapping); | ||
501 | DEFINE_DMA_UNMAP_LEN(len); | ||
502 | }; | ||
503 | |||
504 | 2) Use dma_unmap_{addr,len}_set to set these values. | ||
505 | Example, before: | ||
506 | |||
507 | ringp->mapping = FOO; | ||
508 | ringp->len = BAR; | ||
509 | |||
510 | after: | ||
511 | |||
512 | dma_unmap_addr_set(ringp, mapping, FOO); | ||
513 | dma_unmap_len_set(ringp, len, BAR); | ||
514 | |||
515 | 3) Use dma_unmap_{addr,len} to access these values. | ||
516 | Example, before: | ||
517 | |||
518 | dma_unmap_single(dev, ringp->mapping, ringp->len, | ||
519 | DMA_FROM_DEVICE); | ||
520 | |||
521 | after: | ||
522 | |||
523 | dma_unmap_single(dev, | ||
524 | dma_unmap_addr(ringp, mapping), | ||
525 | dma_unmap_len(ringp, len), | ||
526 | DMA_FROM_DEVICE); | ||
527 | |||
528 | It really should be self-explanatory. We treat the ADDR and LEN | ||
529 | separately, because it is possible for an implementation to only | ||
530 | need the address in order to perform the unmap operation. | ||
531 | |||
532 | |||
475 | Part II - Advanced dma_ usage | 533 | Part II - Advanced dma_ usage |
476 | ----------------------------- | 534 | ----------------------------- |
477 | 535 | ||