Linux Streaming DMA ReMapping without Unmapping - linux-device-driver

Question

I have noticed that the signature of pci_unmap_sg(I show dma_unmap_sg_attrs, which is called by pci_unmap_sg through two macros and has clear parameter naming) includes the direction and attributes.
static inline void dma_unmap_sg_attrs(
struct device *dev,
struct scatterlist *sg,
int nents,
enum dma_data_direction dir,
struct dma_attrs *attrs)
I wonder why it is necessary to know about the direction and attributes for unmapping. Initially i thought mapping was a bit like malloc and free. But seeing this I wonder if something like the following is legal:
dma_map_sg_attrs(..., dir=DMA_BIDIRECTIONAL,...);
...
dma_unmap_sg_attrs(..., dir=DMA_FROM_DEVICE ,...);
//continue use in TO_DEVICE direction
or
dma_map_sg_attrs(..., dir=DMA_TO_DEVICE,...);
...
dma_map_sg_attrs(..., dir=DMA_FROM_DEVICE ,...);
//start bidirectional use
Also can I do this (stream data via DMA from one device to the other if they cant directly dma each other):
dma_map_sg_attrs(dev1, ..., dir=DMA_FROM_DEVICE ,...);
dma_map_sg_attrs(dev2, ..., dir=DMA_TO_DEVICE ,...);
I tried digging into the function, but ended at get_dma_ops which gets function pointers from a global. But how to follow this code further is another question
Update
I find the synchronization api even more confusing:
pci_dma_sync_sg_for_cpu(
struct pci_dev *hwdev,
struct scatterlist *sg,
int nelems,
int direction
)
What is the reason for this api to know the direction? Is there no way for the api to remember the original mapping direction and is it thus to eleminate sync_for_cpu if we mapped as DMA_TO_DEVICE only?

Answer 1

The answer would be simple and robust simultaneously. It depends how deep you know the CPU architecture you are using. The problem with DMA is CPU caches. CPU cache has to be coherent for DMA. Thus, we have different directions in the sync API since we may access data from both sides DMA and CPU. And like you know already the sync API is a cause of direction parameter in the map API.
P.S. It's not anyhow the comprehensive answer. For that you have to go through specific literature and documentation. I suggest you to start with Documentation/DMA*.txt files.

Answer 2

The tipps from Andy were right, while I thought that most of the DMA_ATTR_* wont help me since my device does the ordering so there is no way for the kernel to handle some of them, however if you look at DMA_ATTR_SKIP_SYNC_CPU you find (from DMA-attributes.txt):
71 DMA_ATTR_SKIP_CPU_SYNC
72 ----------------------
73
74 By default dma_map_{single,page,sg} functions family transfer a given
75 buffer from CPU domain to device domain. Some advanced use cases might
76 require sharing a buffer between more than one device. This requires
77 having a mapping created separately for each device and is usually
78 performed by calling dma_map_{single,page,sg} function more than once
79 for the given buffer with device pointer to each device taking part in
80 the buffer sharing. The first call transfers a buffer from 'CPU' domain
81 to 'device' domain, what synchronizes CPU caches for the given region
82 (usually it means that the cache has been flushed or invalidated
83 depending on the dma direction). However, next calls to
84 dma_map_{single,page,sg}() for other devices will perform exactly the
85 same synchronization operation on the CPU cache. CPU cache synchronization
86 might be a time consuming operation, especially if the buffers are
87 large, so it is highly recommended to avoid it if possible.
88 DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of
89 the CPU cache for the given buffer assuming that it has been already
90 transferred to 'device' domain. This attribute can be also used for
91 dma_unmap_{single,page,sg} functions family to force buffer to stay in
92 device domain after releasing a mapping for it. Use this attribute with
93 care!