[RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent

[RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent

[Brian Starkey]

Hi,

I'm resending these again to try and garner some interest. Without
this series, dma-coherent cannot be used on arm64 platforms. The
decision to add MEMREMAP_WC came out of a previous discussion with
Dan Williams and Catalin Marinas about the same problem[1].

These patches implement a MEMREMAP_WC flag for memremap(), which can
be used to obtain writecombine mappings. This is then used for setting
up dma_coherent_mem regions which use the DMA_MEMORY_MAP flag.
They apply cleanly on 4.5-rc3.

Patch 3 makes sure that the appropriate memset function is used
when zeroing coherent allocations, which fixes an alignment fault on
arm64.

Best Regards,
Brian

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390857.html

Brian Starkey (3):
  memremap: add MEMREMAP_WC flag
  drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP
  drivers: dma-coherent: use memset_io for DMA_MEMORY_IO

 drivers/base/dma-coherent.c |   25 ++++++++++++++++++++-----
 include/linux/io.h          |    1 +
 kernel/memremap.c           |   15 +++++++++++++--
 3 files changed, 34 insertions(+), 7 deletions(-)

-- 
1.7.9.5

[RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

[Brian Starkey]

Add a flag to memremap() for writecombine mappings. Mappings satisfied
by this flag will not be cached, however writes may be delayed or
combined into more efficient bursts. This is most suitable for
buffers written sequentially by the CPU for use by other DMA devices.

Signed-off-by: Brian Starkey <brian.starkey@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 include/linux/io.h |    1 +
 kernel/memremap.c  |   15 +++++++++++++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/include/linux/io.h b/include/linux/io.h
index 32403b5..e2c8419 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -135,6 +135,7 @@ enum {
 	/* See memremap() kernel-doc for usage description... */
 	MEMREMAP_WB = 1 << 0,
 	MEMREMAP_WT = 1 << 1,
+	MEMREMAP_WC = 1 << 2,
 };
 
 void *memremap(resource_size_t offset, size_t size, unsigned long flags);
diff --git a/kernel/memremap.c b/kernel/memremap.c
index e517a16..3849987 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -41,11 +41,13 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
  * memremap() - remap an iomem_resource as cacheable memory
  * @offset: iomem resource start address
  * @size: size of remap
- * @flags: either MEMREMAP_WB or MEMREMAP_WT
+ * @flags: any of MEMREMAP_WB, MEMREMAP_WT and MEMREMAP_WC
  *
  * memremap() is "ioremap" for cases where it is known that the resource
  * being mapped does not have i/o side effects and the __iomem
- * annotation is not applicable.
+ * annotation is not applicable. In the case of multiple flags, the different
+ * mapping types will be attempted in the order listed below until one of
+ * them succeeds.
  *
  * MEMREMAP_WB - matches the default mapping for "System RAM" on
  * the architecture.  This is usually a read-allocate write-back cache.
@@ -57,6 +59,10 @@ static void *try_ram_remap(resource_size_t offset, size_t size)
  * cache or are written through to memory and never exist in a
  * cache-dirty state with respect to program visibility.  Attempts to
  * map "System RAM" with this mapping type will fail.
+ *
+ * MEMREMAP_WC - establish a writecombine mapping, whereby writes may
+ * be coalesced together (e.g. in the CPU's write buffers), but is otherwise
+ * uncached. Attempts to map "System RAM" with this mapping type will fail.
  */
 void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 {
@@ -101,6 +107,11 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
 		addr = ioremap_wt(offset, size);
 	}
 
+	if (!addr && (flags & MEMREMAP_WC)) {
+		flags &= ~MEMREMAP_WC;
+		addr = ioremap_wc(offset, size);
+	}
+
 	return addr;
 }
 EXPORT_SYMBOL(memremap);
-- 
1.7.9.5

[RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

[Greg Kroah-Hartman]

On Mon, Feb 08, 2016 at 05:30:50PM +0000, Brian Starkey wrote:
> Add a flag to memremap() for writecombine mappings. Mappings satisfied
> by this flag will not be cached, however writes may be delayed or
> combined into more efficient bursts. This is most suitable for
> buffers written sequentially by the CPU for use by other DMA devices.
> 
> Signed-off-by: Brian Starkey <brian.starkey@arm.com>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
>  include/linux/io.h |    1 +
>  kernel/memremap.c  |   15 +++++++++++++--
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/io.h b/include/linux/io.h
> index 32403b5..e2c8419 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -135,6 +135,7 @@ enum {
>  	/* See memremap() kernel-doc for usage description... */
>  	MEMREMAP_WB = 1 << 0,
>  	MEMREMAP_WT = 1 << 1,
> +	MEMREMAP_WC = 1 << 2,

You didn't update the documentation :(

[RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

[Brian Starkey]

Hi Greg,

On Mon, Feb 08, 2016 at 10:30:06AM -0800, Greg KH wrote:
>On Mon, Feb 08, 2016 at 05:30:50PM +0000, Brian Starkey wrote:
>> diff --git a/include/linux/io.h b/include/linux/io.h
>> index 32403b5..e2c8419 100644
>> --- a/include/linux/io.h
>> +++ b/include/linux/io.h
>> @@ -135,6 +135,7 @@ enum {
>>  	/* See memremap() kernel-doc for usage description... */
>>  	MEMREMAP_WB = 1 << 0,
>>  	MEMREMAP_WT = 1 << 1,
>> +	MEMREMAP_WC = 1 << 2,
>
>You didn't update the documentation :(
>

Maybe I missed something, but I don't think there's anything to update
here? Like the comment says, the flags are documented in the memremap()
kernel-doc (which I did update - see the next two hunks of this patch).

Thanks,

Brian

[RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

[Brian Starkey]

Hi Greg,

Is the documentation OK? Is there any chance of you picking up this
series?

I can rebase onto -next if that's the right place, but they still apply
on 4.5-rc4 and fix a panic, so I thought perhaps they could make 4.5.

Thanks,
Brian

On Tue, Feb 09, 2016 at 09:15:02AM +0000, Brian Starkey wrote:
>Hi Greg,
>
>On Mon, Feb 08, 2016 at 10:30:06AM -0800, Greg KH wrote:
>>On Mon, Feb 08, 2016 at 05:30:50PM +0000, Brian Starkey wrote:
>>>diff --git a/include/linux/io.h b/include/linux/io.h
>>>index 32403b5..e2c8419 100644
>>>--- a/include/linux/io.h
>>>+++ b/include/linux/io.h
>>>@@ -135,6 +135,7 @@ enum {
>>> 	/* See memremap() kernel-doc for usage description... */
>>> 	MEMREMAP_WB = 1 << 0,
>>> 	MEMREMAP_WT = 1 << 1,
>>>+	MEMREMAP_WC = 1 << 2,
>>
>>You didn't update the documentation :(
>>
>
>Maybe I missed something, but I don't think there's anything to update
>here? Like the comment says, the flags are documented in the memremap()
>kernel-doc (which I did update - see the next two hunks of this patch).
>
>Thanks,
>
>Brian

[RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

[Greg Kroah-Hartman]

On Tue, Feb 16, 2016 at 11:14:26AM +0000, Brian Starkey wrote:
> Hi Greg,
> 
> Is the documentation OK? Is there any chance of you picking up this
> series?
> 
> I can rebase onto -next if that's the right place, but they still apply
> on 4.5-rc4 and fix a panic, so I thought perhaps they could make 4.5.

I think memory stuff like this goes through Andrew's tree, not mine...

thanks,

greg k-h

[RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

[Brian Starkey]

On Tue, Feb 16, 2016 at 04:43:51PM -0800, Greg Kroah-Hartman wrote:
>On Tue, Feb 16, 2016 at 11:14:26AM +0000, Brian Starkey wrote:
>> Hi Greg,
>>
>> Is the documentation OK? Is there any chance of you picking up this
>> series?
>>
>> I can rebase onto -next if that's the right place, but they still apply
>> on 4.5-rc4 and fix a panic, so I thought perhaps they could make 4.5.
>
>I think memory stuff like this goes through Andrew's tree, not mine...

Right, fair enough. I was just blindly working off get_maintainer.pl

Cheers,

Brian
>
>thanks,
>
>greg k-h
>

[RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

[Andrew Morton]

On Mon,  8 Feb 2016 17:30:50 +0000 Brian Starkey <brian.starkey@arm.com> wrote:

> Add a flag to memremap() for writecombine mappings. Mappings satisfied
> by this flag will not be cached, however writes may be delayed or
> combined into more efficient bursts. This is most suitable for
> buffers written sequentially by the CPU for use by other DMA devices.
> 
> ...

The patch generally looks OK to me.  It generates rejects against
linux-next because of some janitorial changes in memremap.c.


> @@ -101,6 +107,11 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
>  		addr = ioremap_wt(offset, size);
>  	}
>  
> +	if (!addr && (flags & MEMREMAP_WC)) {
> +		flags &= ~MEMREMAP_WC;
> +		addr = ioremap_wc(offset, size);
> +	}
> +
>  	return addr;
>  }

The modifications of `flags' is unneeded (and the compiler will remove
it).  And generally the modification of incoming args is a bit nasty
IMO - I find it's better to treat them as const - part of the calling
environment which can be relied upon to be unaltered as the code
evolves.

[RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

[Brian Starkey]

Hi Andrew,

Thanks for taking a look,

On Mon, Feb 08, 2016 at 12:03:17PM -0800, Andrew Morton wrote:
>On Mon,  8 Feb 2016 17:30:50 +0000 Brian Starkey <brian.starkey@arm.com> wrote:
>The patch generally looks OK to me.  It generates rejects against
>linux-next because of some janitorial changes in memremap.c.
>

Ah yeah, so it does - sorry. I was hoping this could make it into 4.5,
but I can rebase onto linux-next if that's better. Annoyingly it only
conflicts because of a couple of quotation marks.

>
>> @@ -101,6 +107,11 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
>>  		addr = ioremap_wt(offset, size);
>>  	}
>>
>> +	if (!addr && (flags & MEMREMAP_WC)) {
>> +		flags &= ~MEMREMAP_WC;
>> +		addr = ioremap_wc(offset, size);
>> +	}
>> +
>>  	return addr;
>>  }
>
>The modifications of `flags' is unneeded (and the compiler will remove
>it).  And generally the modification of incoming args is a bit nasty
>IMO - I find it's better to treat them as const - part of the calling
>environment which can be relied upon to be unaltered as the code
>evolves.
>

To be honest I was just mirroring the rest of the function. I guess
the idea was filtering the different mapping types in case one of the
'mappers' can handle multiple flags or something. I'll remove it if
you like, I just thought that extending the functionality in-keeping
with the current semantics was a better evolution - let me know.

Thanks,
Brian

[RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

[Brian Starkey]

Hi Andrew,

Would you pick these up if I rebase onto linux-next?

How strongly do you feel about the input argument modification vs.
staying in-line with the rest of the function?

Thanks,

Brian

On Tue, Feb 09, 2016 at 10:23:00AM +0000, Brian Starkey wrote:
>Hi Andrew,
>
>Thanks for taking a look,
>
>On Mon, Feb 08, 2016 at 12:03:17PM -0800, Andrew Morton wrote:
>>On Mon,  8 Feb 2016 17:30:50 +0000 Brian Starkey <brian.starkey@arm.com> wrote:
>>The patch generally looks OK to me.  It generates rejects against
>>linux-next because of some janitorial changes in memremap.c.
>>
>
>Ah yeah, so it does - sorry. I was hoping this could make it into 4.5,
>but I can rebase onto linux-next if that's better. Annoyingly it only
>conflicts because of a couple of quotation marks.
>
>>
>>>@@ -101,6 +107,11 @@ void *memremap(resource_size_t offset, size_t size, unsigned long flags)
>>> 		addr = ioremap_wt(offset, size);
>>> 	}
>>>
>>>+	if (!addr && (flags & MEMREMAP_WC)) {
>>>+		flags &= ~MEMREMAP_WC;
>>>+		addr = ioremap_wc(offset, size);
>>>+	}
>>>+
>>> 	return addr;
>>> }
>>
>>The modifications of `flags' is unneeded (and the compiler will remove
>>it).  And generally the modification of incoming args is a bit nasty
>>IMO - I find it's better to treat them as const - part of the calling
>>environment which can be relied upon to be unaltered as the code
>>evolves.
>>
>
>To be honest I was just mirroring the rest of the function. I guess
>the idea was filtering the different mapping types in case one of the
>'mappers' can handle multiple flags or something. I'll remove it if
>you like, I just thought that extending the functionality in-keeping
>with the current semantics was a better evolution - let me know.
>
>Thanks,
>Brian

[RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag

[Andrew Morton]

On Wed, 17 Feb 2016 11:53:48 +0000 Brian Starkey <brian.starkey@arm.com> wrote:

> Hi Andrew,
> 
> Would you pick these up if I rebase onto linux-next?

Sure.

> How strongly do you feel about the input argument modification vs.
> staying in-line with the rest of the function?

I see no reason why memremap() is modifying `flags' as it proceeds -
these flags are all disjoint so it's pointless.  I suggest you simply
take all that out in a preparatory patch.

[RESEND2 PATCH 2/3] drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP

[Brian Starkey]

When the DMA_MEMORY_MAP flag is used, memory which can be accessed
directly should be returned, so use memremap(..., MEMREMAP_WC) to
provide a writecombine mapping.

Signed-off-by: Brian Starkey <brian.starkey@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
---
 drivers/base/dma-coherent.c |   20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index 55b8398..f98359a 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -2,6 +2,7 @@
  * Coherent per-device memory handling.
  * Borrowed from i386
  */
+#include <linux/io.h>
 #include <linux/slab.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
@@ -31,7 +32,10 @@ static int dma_init_coherent_memory(phys_addr_t phys_addr, dma_addr_t device_add
 	if (!size)
 		goto out;
 
-	mem_base = ioremap(phys_addr, size);
+	if (flags & DMA_MEMORY_MAP)
+		mem_base = memremap(phys_addr, size, MEMREMAP_WC);
+	else
+		mem_base = ioremap(phys_addr, size);
 	if (!mem_base)
 		goto out;
 
@@ -58,8 +62,12 @@ static int dma_init_coherent_memory(phys_addr_t phys_addr, dma_addr_t device_add
 
 out:
 	kfree(dma_mem);
-	if (mem_base)
-		iounmap(mem_base);
+	if (mem_base) {
+		if (flags & DMA_MEMORY_MAP)
+			memunmap(mem_base);
+		else
+			iounmap(mem_base);
+	}
 	return 0;
 }
 
@@ -67,7 +75,11 @@ static void dma_release_coherent_memory(struct dma_coherent_mem *mem)
 {
 	if (!mem)
 		return;
-	iounmap(mem->virt_base);
+
+	if (mem->flags & DMA_MEMORY_MAP)
+		memunmap(mem->virt_base);
+	else
+		iounmap(mem->virt_base);
 	kfree(mem->bitmap);
 	kfree(mem);
 }
-- 
1.7.9.5

[RESEND2 PATCH 3/3] drivers: dma-coherent: use memset_io for DMA_MEMORY_IO mappings

[Brian Starkey]

Use memset_io() for DMA_MEMORY_IO mappings which are mapped as I/O
memory, and regular memset() for DMA_MEMORY_MAP mappings.

This fixes the below alignment fault on arm64 for DMA_MEMORY_IO
mappings, where memset() uses the DC ZVA instruction which is
invalid on device memory.

   Unhandled fault: alignment fault (0x96000061) at 0xffffff8000380000
   Internal error: : 96000061 [#1] PREEMPT SMP
   Modules linked in: hdlcd(+) clk_scpi
   CPU: 4 PID: 1355 Comm: systemd-udevd Not tainted 4.4.0-rc1+ #5
   Hardware name: ARM Juno development board (r0) (DT)
   task: ffffffc9763eee00 ti: ffffffc9758c4000 task.ti: ffffffc9758c4000
   PC is at __efistub_memset+0x1ac/0x200
   LR is at dma_alloc_from_coherent+0xb0/0x120
   pc : [<ffffffc00030ff2c>] lr : [<ffffffc00042a918>] pstate: 400001c5
   sp : ffffffc9758c79a0
   x29: ffffffc9758c79a0 x28: ffffffc000635cd0
   x27: 0000000000000124 x26: ffffffc000119ef4
   x25: 0000000000010000 x24: 0000000000000140
   x23: ffffffc07e9ac3a8 x22: ffffffc9758c7a58
   x21: ffffffc9758c7a68 x20: 0000000000000004
   x19: ffffffc07e9ac380 x18: 0000000000000001
   x17: 0000007fae1bbba8 x16: ffffffc0001b2d1c
   x15: ffffffffffffffff x14: 0ffffffffffffffe
   x13: 0000000000000010 x12: ffffff800837ffff
   x11: ffffff800837ffff x10: 0000000040000000
   x9 : 0000000000000000 x8 : ffffff8000380000
   x7 : 0000000000000000 x6 : 000000000000003f
   x5 : 0000000000000040 x4 : 0000000000000000
   x3 : 0000000000000004 x2 : 000000000000ffc0
   x1 : 0000000000000000 x0 : ffffff8000380000

Signed-off-by: Brian Starkey <brian.starkey@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
 drivers/base/dma-coherent.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index f98359a..4e4ad30 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -193,7 +193,10 @@ int dma_alloc_from_coherent(struct device *dev, ssize_t size,
 	 */
 	*dma_handle = mem->device_base + (pageno << PAGE_SHIFT);
 	*ret = mem->virt_base + (pageno << PAGE_SHIFT);
-	memset(*ret, 0, size);
+	if (mem->flags & DMA_MEMORY_MAP)
+		memset(*ret, 0, size);
+	else
+		memset_io(*ret, 0, size);
 	spin_unlock_irqrestore(&mem->spinlock, flags);
 
 	return 1;
-- 
1.7.9.5

[RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent

[Mark Rutland]

On Mon, Feb 08, 2016 at 05:30:49PM +0000, Brian Starkey wrote:
> Hi,
> 
> I'm resending these again to try and garner some interest. Without
> this series, dma-coherent cannot be used on arm64 platforms.

I think you need to characterize that a bit better. I see plenty of
instances of 'dma-coherent' in dts files, assuming you mean the DT
dma-coehrent property.

If not, feel free to stop reading now.

Currently dma-coherent isn't well-defined, but it's de-facto semantics
are that a device makes accesses which are coherent with data accesses
made by CPUs with Normal, Inner Shareable, Inner Write-Back Cacheable,
Outer Write-Back Cacheable attributes.

> The decision to add MEMREMAP_WC came out of a previous discussion with
> Dan Williams and Catalin Marinas about the same problem[1].

As pgprot_writecombine is Normal Non-Cacheable, this is a completely
different idea of coherency to that described by the DT dma-coherent
property.

We should not overload that to mean different things.

Thanks,
Mark.

> These patches implement a MEMREMAP_WC flag for memremap(), which can
> be used to obtain writecombine mappings. This is then used for setting
> up dma_coherent_mem regions which use the DMA_MEMORY_MAP flag.
> They apply cleanly on 4.5-rc3.
> 
> Patch 3 makes sure that the appropriate memset function is used
> when zeroing coherent allocations, which fixes an alignment fault on
> arm64.
> 
> Best Regards,
> Brian
> 
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390857.html
> 
> Brian Starkey (3):
>   memremap: add MEMREMAP_WC flag
>   drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP
>   drivers: dma-coherent: use memset_io for DMA_MEMORY_IO
> 
>  drivers/base/dma-coherent.c |   25 ++++++++++++++++++++-----
>  include/linux/io.h          |    1 +
>  kernel/memremap.c           |   15 +++++++++++++--
>  3 files changed, 34 insertions(+), 7 deletions(-)
> 
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent

[Robin Murphy]

Hi Mark,

On 08/02/16 17:50, Mark Rutland wrote:
> On Mon, Feb 08, 2016 at 05:30:49PM +0000, Brian Starkey wrote:
>> Hi,
>>
>> I'm resending these again to try and garner some interest. Without
>> this series, dma-coherent cannot be used on arm64 platforms.
>
> I think you need to characterize that a bit better. I see plenty of
> instances of 'dma-coherent' in dts files, assuming you mean the DT
> dma-coehrent property.
>
> If not, feel free to stop reading now.

Terminology overload: the dma-coherent DT property is about devices 
having cache-coherent access to system memory within the linear map. The 
dma-coherent thing here is pretty much the precise opposite of that - 
namely creating CPU mappings for memory which belongs to the device 
itself and may be behind an I/O bus (e.g. a framebuffer on a video card).

> Currently dma-coherent isn't well-defined,

True dat.

Robin.

> but it's de-facto semantics
> are that a device makes accesses which are coherent with data accesses
> made by CPUs with Normal, Inner Shareable, Inner Write-Back Cacheable,
> Outer Write-Back Cacheable attributes.
>
>> The decision to add MEMREMAP_WC came out of a previous discussion with
>> Dan Williams and Catalin Marinas about the same problem[1].
>
> As pgprot_writecombine is Normal Non-Cacheable, this is a completely
> different idea of coherency to that described by the DT dma-coherent
> property.
>
> We should not overload that to mean different things.
>
> Thanks,
> Mark.
>
>> These patches implement a MEMREMAP_WC flag for memremap(), which can
>> be used to obtain writecombine mappings. This is then used for setting
>> up dma_coherent_mem regions which use the DMA_MEMORY_MAP flag.
>> They apply cleanly on 4.5-rc3.
>>
>> Patch 3 makes sure that the appropriate memset function is used
>> when zeroing coherent allocations, which fixes an alignment fault on
>> arm64.
>>
>> Best Regards,
>> Brian
>>
>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/390857.html
>>
>> Brian Starkey (3):
>>    memremap: add MEMREMAP_WC flag
>>    drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP
>>    drivers: dma-coherent: use memset_io for DMA_MEMORY_IO
>>
>>   drivers/base/dma-coherent.c |   25 ++++++++++++++++++++-----
>>   include/linux/io.h          |    1 +
>>   kernel/memremap.c           |   15 +++++++++++++--
>>   3 files changed, 34 insertions(+), 7 deletions(-)
>>
>> --
>> 1.7.9.5
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

[RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent

[Mark Rutland]

On Mon, Feb 08, 2016 at 05:59:25PM +0000, Robin Murphy wrote:
> Hi Mark,
> 
> On 08/02/16 17:50, Mark Rutland wrote:
> >On Mon, Feb 08, 2016 at 05:30:49PM +0000, Brian Starkey wrote:
> >>Hi,
> >>
> >>I'm resending these again to try and garner some interest. Without
> >>this series, dma-coherent cannot be used on arm64 platforms.
> >
> >I think you need to characterize that a bit better. I see plenty of
> >instances of 'dma-coherent' in dts files, assuming you mean the DT
> >dma-coehrent property.
> >
> >If not, feel free to stop reading now.
> 
> Terminology overload: the dma-coherent DT property is about devices
> having cache-coherent access to system memory within the linear map.
> The dma-coherent thing here is pretty much the precise opposite of
> that - namely creating CPU mappings for memory which belongs to the
> device itself and may be behind an I/O bus (e.g. a framebuffer on a
> video card).

Phew.

Sorry for the noise, and thanks for setting me straight!

Mark.