All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Murzin <vladimir.murzin@arm.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org,
	Mark Rutland <mark.rutland@arm.com>,
	Joerg Roedel <jroedel@suse.de>,
	sza@esh.hu, Yoshinori Sato <ysato@users.sourceforge.jp>,
	alexandre.torgue@st.com, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org,
	Michal Nazarewicz <mina86@mina86.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Doug Ledford <dledford@redhat.com>, Rich Felker <dalias@libc.org>,
	arnd@arndb.de, kbuild-all@01.org,
	Rob Herring <robh+dt@kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	akpm@linux-foundation.org,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	robin.murphy@arm.com, Roger Quadros <rogerq@ti.com>
Subject: Re: [PATCH v4 0/7] ARM: Fix dma_alloc_coherent() and friends for NOMMU
Date: Wed, 24 May 2017 09:49:15 +0100	[thread overview]
Message-ID: <cd1a0875-8fcc-98a6-dae3-1c54778bd8d5@arm.com> (raw)
In-Reply-To: <20170523200439.GE22219@n2100.armlinux.org.uk>

On 23/05/17 21:04, Russell King - ARM Linux wrote:
> On Mon, May 15, 2017 at 09:52:58AM +0100, Vladimir Murzin wrote:
>> Ping again...
> 
> Apart from the one comment, the ARM bits look fine to me - but I'm
> not saying anything about the lib/dma-noop.c or the drivers/base
> changes.
> 
> What's the dependency between the ARM bits and those bits?

In case only ARM bits would be applied machines w/o cache support continue to
work, for machines which have cache support coherent DMA allocation would fail
(a bit better than just silently corrupt data), Benjamin's case would be
broken because PATCH 7/7 depends on PATCH 2/7. In general, the goal of the
patch set can't be achieved without changes in dma-coherent.c and dma-noop.c,
but I'm open to any option to make progress with this series.

Thanks
Vladimir


> 
>> On 02/05/17 09:32, Vladimir Murzin wrote:
>>> Gentle ping!
>>>
>>> On 24/04/17 11:16, Vladimir Murzin wrote:
>>>> It seem that addition of cache support for M-class CPUs uncovered
>>>> latent bug in DMA usage. NOMMU memory model has been treated as being
>>>> always consistent; however, for R/M CPU classes memory can be covered
>>>> by MPU which in turn might configure RAM as Normal i.e. bufferable and
>>>> cacheable. It breaks dma_alloc_coherent() and friends, since data can
>>>> stuck in caches now or be buffered.
>>>>
>>>> This patch set is trying to address the issue by providing region of
>>>> memory suitable for consistent DMA operations. It is supposed that
>>>> such region is marked by MPU as non-cacheable. Robin suggested to
>>>> advertise such memory as reserved shared-dma-pool, rather then using
>>>> homebrew command line option, and extend dma-coherent to provide
>>>> default DMA area in the similar way as it is done for CMA (PATCH
>>>> 4/7). It allows us to offload all bookkeeping on generic coherent DMA
>>>> framework, and it seems that it might be reused by other architectures
>>>> like c6x and blackfin.
>>>>
>>>> While reviewing/testing previous vesrions of the patch set it turned
>>>> out that dma-coherent does not take into account "dma-ranges" device
>>>> tree property, so it is addressed in PATCH 3/7.
>>>>
>>>> For ARM, dedicated DMA region is required for cases other than:
>>>>  - MMU/MPU is off
>>>>  - cpu is v7m w/o cache support
>>>>  - device is coherent
>>>>
>>>> In case one of the above conditions is true dma operations are forced
>>>> to be coherent and wired with dma_noop_ops.
>>>>
>>>> To make life easier NOMMU dma operations are kept in separate
>>>> compilation unit.
>>>>
>>>> Since the issue was reported in the same time as Benjamin sent his
>>>> patch [1] to allow mmap for NOMMU, his case is also addressed in this
>>>> series (PATCH 1/7 and PATCH 2/7).
>>>>
>>>> Thanks!
>>>>
>>>> [1] http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8633/1
>>>>
>>>> Cc: Joerg Roedel <jroedel@suse.de>
>>>> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
>>>> Cc: Michal Nazarewicz <mina86@mina86.com>
>>>> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> Cc: Alan Stern <stern@rowland.harvard.edu>
>>>> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
>>>> Cc: Rich Felker <dalias@libc.org>
>>>> Cc: Roger Quadros <rogerq@ti.com>
>>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Doug Ledford <dledford@redhat.com>
>>>>
>>>> Changelog:
>>>> 	    v3 -> v4
>>>> 	       - rebased on v4.11-rc7
>>>> 	       - made CONFIG_ARM_DMA_MEM_BUFFERABLE optional for CPU_V7M
>>>> 	       - added Arnd's Acked-by
>>>>
>>>> 	    v2 -> v3
>>>> 	       - fixed warnings reported by Alexandre and kbuild robot
>>>>
>>>> 	    v1 -> v2
>>>> 	       - rebased on v4.11-rc1
>>>> 	       - added Robin's Reviewed-by
>>>> 	       - dedicated flag is introduced to use dev->dma_pfn_offset
>>>> 	         rather than mem->device_base in case memory region is
>>>> 		 configured via device tree (so Tested-by discarded there)
>>>>
>>>> 	RFC v6 -> v1
>>>> 	       - dropped RFC tag
>>>> 	       - added Alexandre's Tested-by
>>>>
>>>>
>>>> Vladimir Murzin (7):
>>>>   dma: Take into account dma_pfn_offset
>>>>   dma: Add simple dma_noop_mmap
>>>>   drivers: dma-coherent: Account dma_pfn_offset when used with device
>>>>     tree
>>>>   drivers: dma-coherent: Introduce default DMA pool
>>>>   ARM: NOMMU: Introduce dma operations for noMMU
>>>>   ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus
>>>>   ARM: dma-mapping: Remove traces of NOMMU code
>>>>
>>>>  .../bindings/reserved-memory/reserved-memory.txt   |   3 +
>>>>  arch/arm/Kconfig                                   |   1 +
>>>>  arch/arm/include/asm/dma-mapping.h                 |   2 +-
>>>>  arch/arm/mm/Kconfig                                |   4 +-
>>>>  arch/arm/mm/Makefile                               |   5 +-
>>>>  arch/arm/mm/dma-mapping-nommu.c                    | 253 +++++++++++++++++++++
>>>>  arch/arm/mm/dma-mapping.c                          |  29 +--
>>>>  drivers/base/dma-coherent.c                        |  74 +++++-
>>>>  lib/dma-noop.c                                     |  29 ++-
>>>>  9 files changed, 355 insertions(+), 45 deletions(-)
>>>>  create mode 100644 arch/arm/mm/dma-mapping-nommu.c
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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: vladimir.murzin@arm.com (Vladimir Murzin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 0/7] ARM: Fix dma_alloc_coherent() and friends for NOMMU
Date: Wed, 24 May 2017 09:49:15 +0100	[thread overview]
Message-ID: <cd1a0875-8fcc-98a6-dae3-1c54778bd8d5@arm.com> (raw)
In-Reply-To: <20170523200439.GE22219@n2100.armlinux.org.uk>

On 23/05/17 21:04, Russell King - ARM Linux wrote:
> On Mon, May 15, 2017 at 09:52:58AM +0100, Vladimir Murzin wrote:
>> Ping again...
> 
> Apart from the one comment, the ARM bits look fine to me - but I'm
> not saying anything about the lib/dma-noop.c or the drivers/base
> changes.
> 
> What's the dependency between the ARM bits and those bits?

In case only ARM bits would be applied machines w/o cache support continue to
work, for machines which have cache support coherent DMA allocation would fail
(a bit better than just silently corrupt data), Benjamin's case would be
broken because PATCH 7/7 depends on PATCH 2/7. In general, the goal of the
patch set can't be achieved without changes in dma-coherent.c and dma-noop.c,
but I'm open to any option to make progress with this series.

Thanks
Vladimir


> 
>> On 02/05/17 09:32, Vladimir Murzin wrote:
>>> Gentle ping!
>>>
>>> On 24/04/17 11:16, Vladimir Murzin wrote:
>>>> It seem that addition of cache support for M-class CPUs uncovered
>>>> latent bug in DMA usage. NOMMU memory model has been treated as being
>>>> always consistent; however, for R/M CPU classes memory can be covered
>>>> by MPU which in turn might configure RAM as Normal i.e. bufferable and
>>>> cacheable. It breaks dma_alloc_coherent() and friends, since data can
>>>> stuck in caches now or be buffered.
>>>>
>>>> This patch set is trying to address the issue by providing region of
>>>> memory suitable for consistent DMA operations. It is supposed that
>>>> such region is marked by MPU as non-cacheable. Robin suggested to
>>>> advertise such memory as reserved shared-dma-pool, rather then using
>>>> homebrew command line option, and extend dma-coherent to provide
>>>> default DMA area in the similar way as it is done for CMA (PATCH
>>>> 4/7). It allows us to offload all bookkeeping on generic coherent DMA
>>>> framework, and it seems that it might be reused by other architectures
>>>> like c6x and blackfin.
>>>>
>>>> While reviewing/testing previous vesrions of the patch set it turned
>>>> out that dma-coherent does not take into account "dma-ranges" device
>>>> tree property, so it is addressed in PATCH 3/7.
>>>>
>>>> For ARM, dedicated DMA region is required for cases other than:
>>>>  - MMU/MPU is off
>>>>  - cpu is v7m w/o cache support
>>>>  - device is coherent
>>>>
>>>> In case one of the above conditions is true dma operations are forced
>>>> to be coherent and wired with dma_noop_ops.
>>>>
>>>> To make life easier NOMMU dma operations are kept in separate
>>>> compilation unit.
>>>>
>>>> Since the issue was reported in the same time as Benjamin sent his
>>>> patch [1] to allow mmap for NOMMU, his case is also addressed in this
>>>> series (PATCH 1/7 and PATCH 2/7).
>>>>
>>>> Thanks!
>>>>
>>>> [1] http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8633/1
>>>>
>>>> Cc: Joerg Roedel <jroedel@suse.de>
>>>> Cc: Christian Borntraeger <borntraeger@de.ibm.com>
>>>> Cc: Michal Nazarewicz <mina86@mina86.com>
>>>> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
>>>> Cc: Alan Stern <stern@rowland.harvard.edu>
>>>> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
>>>> Cc: Rich Felker <dalias@libc.org>
>>>> Cc: Roger Quadros <rogerq@ti.com>
>>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Doug Ledford <dledford@redhat.com>
>>>>
>>>> Changelog:
>>>> 	    v3 -> v4
>>>> 	       - rebased on v4.11-rc7
>>>> 	       - made CONFIG_ARM_DMA_MEM_BUFFERABLE optional for CPU_V7M
>>>> 	       - added Arnd's Acked-by
>>>>
>>>> 	    v2 -> v3
>>>> 	       - fixed warnings reported by Alexandre and kbuild robot
>>>>
>>>> 	    v1 -> v2
>>>> 	       - rebased on v4.11-rc1
>>>> 	       - added Robin's Reviewed-by
>>>> 	       - dedicated flag is introduced to use dev->dma_pfn_offset
>>>> 	         rather than mem->device_base in case memory region is
>>>> 		 configured via device tree (so Tested-by discarded there)
>>>>
>>>> 	RFC v6 -> v1
>>>> 	       - dropped RFC tag
>>>> 	       - added Alexandre's Tested-by
>>>>
>>>>
>>>> Vladimir Murzin (7):
>>>>   dma: Take into account dma_pfn_offset
>>>>   dma: Add simple dma_noop_mmap
>>>>   drivers: dma-coherent: Account dma_pfn_offset when used with device
>>>>     tree
>>>>   drivers: dma-coherent: Introduce default DMA pool
>>>>   ARM: NOMMU: Introduce dma operations for noMMU
>>>>   ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus
>>>>   ARM: dma-mapping: Remove traces of NOMMU code
>>>>
>>>>  .../bindings/reserved-memory/reserved-memory.txt   |   3 +
>>>>  arch/arm/Kconfig                                   |   1 +
>>>>  arch/arm/include/asm/dma-mapping.h                 |   2 +-
>>>>  arch/arm/mm/Kconfig                                |   4 +-
>>>>  arch/arm/mm/Makefile                               |   5 +-
>>>>  arch/arm/mm/dma-mapping-nommu.c                    | 253 +++++++++++++++++++++
>>>>  arch/arm/mm/dma-mapping.c                          |  29 +--
>>>>  drivers/base/dma-coherent.c                        |  74 +++++-
>>>>  lib/dma-noop.c                                     |  29 ++-
>>>>  9 files changed, 355 insertions(+), 45 deletions(-)
>>>>  create mode 100644 arch/arm/mm/dma-mapping-nommu.c
>>>>
>>>
>>>
>>> _______________________________________________
>>> linux-arm-kernel mailing list
>>> linux-arm-kernel at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>
>>
> 

  reply	other threads:[~2017-05-24  8:49 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24 10:16 [PATCH v4 0/7] ARM: Fix dma_alloc_coherent() and friends for NOMMU Vladimir Murzin
2017-04-24 10:16 ` Vladimir Murzin
2017-04-24 10:16 ` [PATCH v4 1/7] dma: Take into account dma_pfn_offset Vladimir Murzin
2017-04-24 10:16   ` Vladimir Murzin
2017-04-24 10:16 ` [PATCH v4 2/7] dma: Add simple dma_noop_mmap Vladimir Murzin
2017-04-24 10:16   ` Vladimir Murzin
2017-04-24 10:16 ` [PATCH v4 3/7] drivers: dma-coherent: Account dma_pfn_offset when used with device tree Vladimir Murzin
2017-04-24 10:16   ` Vladimir Murzin
2017-04-24 10:16 ` [PATCH v4 4/7] drivers: dma-coherent: Introduce default DMA pool Vladimir Murzin
2017-04-24 10:16   ` Vladimir Murzin
2017-04-24 10:16 ` [PATCH v4 5/7] ARM: NOMMU: Introduce dma operations for noMMU Vladimir Murzin
2017-04-24 10:16   ` Vladimir Murzin
2017-04-24 10:16 ` [PATCH v4 6/7] ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus Vladimir Murzin
2017-04-24 10:16   ` Vladimir Murzin
2017-05-23 20:01   ` Russell King - ARM Linux
2017-05-23 20:01     ` Russell King - ARM Linux
2017-05-23 20:33     ` Arnd Bergmann
2017-05-23 20:33       ` Arnd Bergmann
2017-05-24  8:31       ` Vladimir Murzin
2017-05-24  8:31         ` Vladimir Murzin
2017-05-24  8:36         ` Arnd Bergmann
2017-05-24  8:36           ` Arnd Bergmann
2017-05-24  9:08           ` Vladimir Murzin
2017-05-24  9:08             ` Vladimir Murzin
2017-05-24  9:20             ` Arnd Bergmann
2017-05-24  9:20               ` Arnd Bergmann
2017-04-24 10:16 ` [PATCH v4 7/7] ARM: dma-mapping: Remove traces of NOMMU code Vladimir Murzin
2017-04-24 10:16   ` Vladimir Murzin
2017-05-02  8:32 ` [PATCH v4 0/7] ARM: Fix dma_alloc_coherent() and friends for NOMMU Vladimir Murzin
2017-05-02  8:32   ` Vladimir Murzin
2017-05-15  8:52   ` Vladimir Murzin
2017-05-15  8:52     ` Vladimir Murzin
2017-05-23 20:04     ` Russell King - ARM Linux
2017-05-23 20:04       ` Russell King - ARM Linux
2017-05-24  8:49       ` Vladimir Murzin [this message]
2017-05-24  8:49         ` Vladimir Murzin

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=cd1a0875-8fcc-98a6-dae3-1c54778bd8d5@arm.com \
    --to=vladimir.murzin@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexandre.torgue@st.com \
    --cc=arnd@arndb.de \
    --cc=borntraeger@de.ibm.com \
    --cc=dalias@libc.org \
    --cc=dledford@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jroedel@suse.de \
    --cc=kbuild-all@01.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=mina86@mina86.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=rogerq@ti.com \
    --cc=stern@rowland.harvard.edu \
    --cc=sza@esh.hu \
    --cc=ysato@users.sourceforge.jp \
    /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.