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 >
next prev parent 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: linkBe 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.