[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090623111430D.fujita.tomonori@lab.ntt.co.jp>
Date: Tue, 23 Jun 2009 11:14:22 +0900
From: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To: vapier@...too.org
Cc: linux-kernel@...r.kernel.org,
uclinux-dist-devel@...ckfin.uclinux.org
Subject: Re: [PATCH 2/2] Blackfin: fix dma-mapping build errors
On Mon, 22 Jun 2009 21:54:46 -0400
Mike Frysinger <vapier@...too.org> wrote:
> The recent deprecation of dma_sync_{sg,single} ironically broke Blackfin
> systems.
Oops, sorry about that.
> This is because we don't define dma_sync_sg_for_cpu at all, so
> until the DMA asm-generic conversion/cleanup is done after the next
> release, simply redirect the dma_sync_sg_for_cpu to the debug version.
This doesn't look correct (though it works). dma-debug.h is supposed
to be used by architectures that support DMA_API_DEBUG feature
(blackfin doesn't support it). dma_sync_sg_for_cpu is not the
debug version of dma_sync_sg_for_cpu.
I think that simply adding dummy dma_sync_single_for_device() is a
proper solution (as blackfin already does wrt dma_sync_single_for_cpu
and dma_sync_single_for_device).
Architectures are also supposed to have dma_sync_sg_for_cpu and
dma_sync_sg_for_device, so let's add both.
diff --git a/arch/blackfin/include/asm/dma-mapping.h b/arch/blackfin/include/asm/dma-mapping.h
index d7d9148..6997836 100644
--- a/arch/blackfin/include/asm/dma-mapping.h
+++ b/arch/blackfin/include/asm/dma-mapping.h
@@ -95,4 +95,17 @@ static inline void dma_sync_single_for_device(struct device *dev,
enum dma_data_direction dir)
{
}
+
+static inline void dma_sync_sg_for_cpu(struct device *dev,
+ struct scatterlist *sg,
+ int nents, enum dma_data_direction dir)
+{
+}
+
+static inline void dma_sync_sg_for_device(struct device *dev,
+ struct scatterlist *sg,
+ int nents, enum dma_data_direction dir)
+{
+}
+
#endif /* _BLACKFIN_DMA_MAPPING_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists