All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	Michal Nazarewicz <mina86@mina86.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent
Date: Mon, 8 Feb 2016 17:59:25 +0000	[thread overview]
Message-ID: <56B8D77D.3050305@arm.com> (raw)
In-Reply-To: <20160208175054.GD15443@leverpostej>

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@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

WARNING: multiple messages have this Message-ID (diff)
From: robin.murphy@arm.com (Robin Murphy)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent
Date: Mon, 8 Feb 2016 17:59:25 +0000	[thread overview]
Message-ID: <56B8D77D.3050305@arm.com> (raw)
In-Reply-To: <20160208175054.GD15443@leverpostej>

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
>

  reply	other threads:[~2016-02-08 18:03 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-08 17:30 [RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent Brian Starkey
2016-02-08 17:30 ` Brian Starkey
2016-02-08 17:30 ` [RESEND2 PATCH 1/3] memremap: add MEMREMAP_WC flag Brian Starkey
2016-02-08 17:30   ` Brian Starkey
2016-02-08 18:30   ` Greg Kroah-Hartman
2016-02-08 18:30     ` Greg Kroah-Hartman
2016-02-09  9:15     ` Brian Starkey
2016-02-09  9:15       ` Brian Starkey
2016-02-16 11:14       ` Brian Starkey
2016-02-16 11:14         ` Brian Starkey
2016-02-17  0:43         ` Greg Kroah-Hartman
2016-02-17  0:43           ` Greg Kroah-Hartman
2016-02-17 10:07           ` Brian Starkey
2016-02-17 10:07             ` Brian Starkey
2016-02-08 20:03   ` Andrew Morton
2016-02-08 20:03     ` Andrew Morton
2016-02-09 10:23     ` Brian Starkey
2016-02-09 10:23       ` Brian Starkey
2016-02-17 11:53       ` Brian Starkey
2016-02-17 11:53         ` Brian Starkey
2016-02-17 19:02         ` Andrew Morton
2016-02-17 19:02           ` Andrew Morton
2016-02-08 17:30 ` [RESEND2 PATCH 2/3] drivers: dma-coherent: use MEMREMAP_WC for DMA_MEMORY_MAP Brian Starkey
2016-02-08 17:30   ` Brian Starkey
2016-02-08 17:30 ` [RESEND2 PATCH 3/3] drivers: dma-coherent: use memset_io for DMA_MEMORY_IO mappings Brian Starkey
2016-02-08 17:30   ` Brian Starkey
2016-02-08 17:50 ` [RESEND2 PATCH 0/3] Fix kernel panic in dma-coherent Mark Rutland
2016-02-08 17:50   ` Mark Rutland
2016-02-08 17:59   ` Robin Murphy [this message]
2016-02-08 17:59     ` Robin Murphy
2016-02-08 18:04     ` Mark Rutland
2016-02-08 18:04       ` Mark Rutland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56B8D77D.3050305@arm.com \
    --to=robin.murphy@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=brian.starkey@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mina86@mina86.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.