[FE training-materials-updates] kernel-dma: remove non-sense comment

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Mon Mar 3 12:35:03 CET 2014

Repository : git://git.free-electrons.com/training-materials.git

On branch  : master
Link       : http://git.free-electrons.com/training-materials/commit/?id=039dc8a4ea91564784a737cb25f2a8599539d947


commit 039dc8a4ea91564784a737cb25f2a8599539d947
Author: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>
Date:   Mon Mar 3 12:29:49 2014 +0100

    kernel-dma: remove non-sense comment
    To prevent the CPU from accessing the DMA buffer while it is mapped,
    using "locking" doesn't make any sense. It's not at all about locking,
    it's simply about making sure the driver does not access it. It has
    nothing to do with locking in the sense of spinlocks or mutexes.
    Signed-off-by: Thomas Petazzoni <thomas.petazzoni at free-electrons.com>


 .../kernel-driver-development-dma.tex              |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/slides/kernel-driver-development-dma/kernel-driver-development-dma.tex b/slides/kernel-driver-development-dma/kernel-driver-development-dma.tex
index a8bf242..65eb110 100644
--- a/slides/kernel-driver-development-dma/kernel-driver-development-dma.tex
+++ b/slides/kernel-driver-development-dma/kernel-driver-development-dma.tex
@@ -154,8 +154,7 @@ void dma_unmap_single(struct device *dev, dma_addr_t handdle,
   \item When the mapping is active: only the device should access the
     buffer (potential cache issues otherwise).
-  \item The CPU can access the buffer only after unmapping! Use
-    locking to prevent CPU access to the buffer.
+  \item The CPU can access the buffer only after unmapping!
   \item Another reason: if required, this API can create an
     intermediate bounce buffer (used if the given buffer is not usable
     for DMA).

More information about the training-materials-updates mailing list