| Message ID | alpine.DEB.2.02.1410251424350.22875@kaball.uk.xensource.com |
|---|---|
| State | New |
| Headers | show |
On Sat, 2014-10-25 at 14:29 +0100, Stefano Stabellini wrote: > > Your suggestions and looking more at the code gave me another idea, that > I think is clean and at the same time suitable for 3.18. > What do you think of the following? It is simple, self-contained and > doesn't need a new flag in struct device. of_dma_is_coherent looks to be quite expensive though (walks up the Device Tree doing strcmps on each property of each node until it finds the one it is looking for. Ian.
On Sat, 25 Oct 2014, Ian Campbell wrote: > On Sat, 2014-10-25 at 14:29 +0100, Stefano Stabellini wrote: > > > > Your suggestions and looking more at the code gave me another idea, that > > I think is clean and at the same time suitable for 3.18. > > What do you think of the following? It is simple, self-contained and > > doesn't need a new flag in struct device. > > of_dma_is_coherent looks to be quite expensive though (walks up the > Device Tree doing strcmps on each property of each node until it finds > the one it is looking for. It takes spin_locks too! Too bad, I think I'll have to ditch it. In that case I'l try the new flag in struct device approach.
On 25/10/14 17:15, Stefano Stabellini wrote: > On Sat, 25 Oct 2014, Ian Campbell wrote: >> On Sat, 2014-10-25 at 14:29 +0100, Stefano Stabellini wrote: >>> >>> Your suggestions and looking more at the code gave me another idea, that >>> I think is clean and at the same time suitable for 3.18. >>> What do you think of the following? It is simple, self-contained and >>> doesn't need a new flag in struct device. >> >> of_dma_is_coherent looks to be quite expensive though (walks up the >> Device Tree doing strcmps on each property of each node until it finds >> the one it is looking for. > > It takes spin_locks too! > Too bad, I think I'll have to ditch it. In that case I'l try the new > flag in struct device approach. If you're having to make changes to struct device, this is looking like a series for 3.19 (not 3.18). David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Mon, 27 Oct 2014, David Vrabel wrote: > On 25/10/14 17:15, Stefano Stabellini wrote: > > On Sat, 25 Oct 2014, Ian Campbell wrote: > >> On Sat, 2014-10-25 at 14:29 +0100, Stefano Stabellini wrote: > >>> > >>> Your suggestions and looking more at the code gave me another idea, that > >>> I think is clean and at the same time suitable for 3.18. > >>> What do you think of the following? It is simple, self-contained and > >>> doesn't need a new flag in struct device. > >> > >> of_dma_is_coherent looks to be quite expensive though (walks up the > >> Device Tree doing strcmps on each property of each node until it finds > >> the one it is looking for. > > > > It takes spin_locks too! > > Too bad, I think I'll have to ditch it. In that case I'l try the new > > flag in struct device approach. > > If you're having to make changes to struct device, this is looking like > a series for 3.19 (not 3.18). After looking more into it, I went for adding the flag to dev_archdata under arm and arm64. Let's see what the maintainers say. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
diff --git a/arch/arm/xen/mm32.c b/arch/arm/xen/mm32.c index 6153d61..2b259f1 100644 --- a/arch/arm/xen/mm32.c +++ b/arch/arm/xen/mm32.c @@ -2,10 +2,16 @@ #include <linux/dma-mapping.h> #include <linux/gfp.h> #include <linux/highmem.h> +#include <linux/of_address.h> #include <xen/features.h> +static inline bool is_dma_coherent(struct device *dev) +{ + return of_dma_is_coherent(dev->of_node); +} + /* functions called by SWIOTLB */ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,