Hello,

On Monday, June 20, 2011 4:33 PM KyongHo Cho wrote:

On Mon, Jun 20, 2011 at 4:50 PM, Marek Szyprowski
[off-list ref] wrote:

quoted

+static inline void set_dma_ops(struct device *dev, struct dma_map_ops

*ops)

quoted

+{
+ ? ? ? dev->archdata.dma_ops = ops;
+}
+

Who calls set_dma_ops()?
In the mach. initialization part?

Yes, some board, machine or device bus initialization code is supposed to
call this function. Just 'git grep dma_set_ops' and you will see. In my
patch series one of the clients of set_dma_ops function is dmabounce 
framework (it is called in dmabounce_register_dev() function).

What if a device driver does not want to use arch's dma_map_ops
when machine init procedure set a dma_map_ops?

Could you elaborate on this case? The whole point of dma-mapping framework
is to hide the implementation of DMA mapping operation from the driver. 
The driver should never fiddle with dma map ops directly.

Even though, may arch defiens their dma_map_ops in archdata of device
structure,
I think it is not a good idea that is device structure contains a
pointer to dma_map_ops
that may not be common to all devices in a board.

It is up to the board/bus startup code to set dma ops correctly.

I also think that it is better to attach and to detach dma_map_ops
dynamically.

What's the point of such operations? Why do you want to change dma
mapping methods in runtime?

Moreover, a mapping is not permanent in our Exynos platform
because a System MMU may be turned off while runtime.

This is theoretically possible. The System MMU (Samsung IOMMU
controller) driver can change dma_map_ops back to NULL on remove moving
back the client device to generic ARM dma mapping implementation.

DMA API must come with IOMMU API to initialize IOMMU in runtime.

I don't understand what's the problem here. 

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center