All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Christoph Hellwig <hch@lst.de>, Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	openrisc@lists.librecores.org, iommu@lists.linux-foundation.org,
	linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: provide in-place uncached remapping for dma-direct v2
Date: Mon, 2 Mar 2020 16:05:12 +0000	[thread overview]
Message-ID: <4fe14c57-78d4-6590-a4c4-14fbe061238e@arm.com> (raw)
In-Reply-To: <20200224194446.690816-1-hch@lst.de>

On 24/02/2020 7:44 pm, Christoph Hellwig wrote:
> Hi all,
> 
> this series provides support for remapping places uncached in-place in
> the generic dma-direct code, and moves openrisc over from its own
> in-place remapping scheme.  The arm64 folks also had interest in such
> a scheme to avoid problems with speculating into cache aliases.
> 
> Also all architectures that always use small page mappings for the
> kernel and have non-coherent DMA should look into enabling this
> scheme, as it is much more efficient than the vmap remapping.
> 
> Changes since v1:
>   - share the arch hook for inline remap and uncached segment support
> 

For the whole series:

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

I think we might ultimately want to fiddle around a bit more in 
dma_direct_alloc_pages() to give ARCH_HAS_DMA_SET_UNCACHED clear 
precedence over DMA_DIRECT_REMAP if they have to coexist, but let's land 
these patches first as a solid foundation.

Thanks,
Robin.

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Christoph Hellwig <hch@lst.de>, Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org, openrisc@lists.librecores.org,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: provide in-place uncached remapping for dma-direct v2
Date: Mon, 2 Mar 2020 16:05:12 +0000	[thread overview]
Message-ID: <4fe14c57-78d4-6590-a4c4-14fbe061238e@arm.com> (raw)
In-Reply-To: <20200224194446.690816-1-hch@lst.de>

On 24/02/2020 7:44 pm, Christoph Hellwig wrote:
> Hi all,
> 
> this series provides support for remapping places uncached in-place in
> the generic dma-direct code, and moves openrisc over from its own
> in-place remapping scheme.  The arm64 folks also had interest in such
> a scheme to avoid problems with speculating into cache aliases.
> 
> Also all architectures that always use small page mappings for the
> kernel and have non-coherent DMA should look into enabling this
> scheme, as it is much more efficient than the vmap remapping.
> 
> Changes since v1:
>   - share the arch hook for inline remap and uncached segment support
> 

For the whole series:

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

I think we might ultimately want to fiddle around a bit more in 
dma_direct_alloc_pages() to give ARCH_HAS_DMA_SET_UNCACHED clear 
precedence over DMA_DIRECT_REMAP if they have to coexist, but let's land 
these patches first as a solid foundation.

Thanks,
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Christoph Hellwig <hch@lst.de>, Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org, openrisc@lists.librecores.org,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: provide in-place uncached remapping for dma-direct v2
Date: Mon, 2 Mar 2020 16:05:12 +0000	[thread overview]
Message-ID: <4fe14c57-78d4-6590-a4c4-14fbe061238e@arm.com> (raw)
In-Reply-To: <20200224194446.690816-1-hch@lst.de>

On 24/02/2020 7:44 pm, Christoph Hellwig wrote:
> Hi all,
> 
> this series provides support for remapping places uncached in-place in
> the generic dma-direct code, and moves openrisc over from its own
> in-place remapping scheme.  The arm64 folks also had interest in such
> a scheme to avoid problems with speculating into cache aliases.
> 
> Also all architectures that always use small page mappings for the
> kernel and have non-coherent DMA should look into enabling this
> scheme, as it is much more efficient than the vmap remapping.
> 
> Changes since v1:
>   - share the arch hook for inline remap and uncached segment support
> 

For the whole series:

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

I think we might ultimately want to fiddle around a bit more in 
dma_direct_alloc_pages() to give ARCH_HAS_DMA_SET_UNCACHED clear 
precedence over DMA_DIRECT_REMAP if they have to coexist, but let's land 
these patches first as a solid foundation.

Thanks,
Robin.

_______________________________________________
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 <robin.murphy@arm.com>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] provide in-place uncached remapping for dma-direct v2
Date: Mon, 2 Mar 2020 16:05:12 +0000	[thread overview]
Message-ID: <4fe14c57-78d4-6590-a4c4-14fbe061238e@arm.com> (raw)
In-Reply-To: <20200224194446.690816-1-hch@lst.de>

On 24/02/2020 7:44 pm, Christoph Hellwig wrote:
> Hi all,
> 
> this series provides support for remapping places uncached in-place in
> the generic dma-direct code, and moves openrisc over from its own
> in-place remapping scheme.  The arm64 folks also had interest in such
> a scheme to avoid problems with speculating into cache aliases.
> 
> Also all architectures that always use small page mappings for the
> kernel and have non-coherent DMA should look into enabling this
> scheme, as it is much more efficient than the vmap remapping.
> 
> Changes since v1:
>   - share the arch hook for inline remap and uncached segment support
> 

For the whole series:

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

I think we might ultimately want to fiddle around a bit more in 
dma_direct_alloc_pages() to give ARCH_HAS_DMA_SET_UNCACHED clear 
precedence over DMA_DIRECT_REMAP if they have to coexist, but let's land 
these patches first as a solid foundation.

Thanks,
Robin.

  parent reply	other threads:[~2020-03-02 16:05 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-24 19:44 provide in-place uncached remapping for dma-direct v2 Christoph Hellwig
2020-02-24 19:44 ` [OpenRISC] " Christoph Hellwig
2020-02-24 19:44 ` Christoph Hellwig
2020-02-24 19:44 ` Christoph Hellwig
2020-02-24 19:44 ` Christoph Hellwig
2020-02-24 19:44 ` [PATCH 1/5] dma-direct: remove the cached_kernel_address hook Christoph Hellwig
2020-02-24 19:44   ` [OpenRISC] " Christoph Hellwig
2020-02-24 19:44   ` Christoph Hellwig
2020-02-24 19:44   ` Christoph Hellwig
2020-02-24 19:44 ` [PATCH 2/5] dma-direct: consolidate the error handling in dma_direct_alloc_pages Christoph Hellwig
2020-02-24 19:44   ` [OpenRISC] " Christoph Hellwig
2020-02-24 19:44   ` Christoph Hellwig
2020-02-24 19:44   ` Christoph Hellwig
2020-02-24 19:44 ` [PATCH 3/5] dma-direct: make uncached_kernel_address more general Christoph Hellwig
2020-02-24 19:44   ` [OpenRISC] " Christoph Hellwig
2020-02-24 19:44   ` Christoph Hellwig
2020-02-24 19:44   ` Christoph Hellwig
2020-02-24 19:44 ` [PATCH 4/5] dma-direct: provide a arch_dma_clear_uncached hook Christoph Hellwig
2020-02-24 19:44   ` [OpenRISC] " Christoph Hellwig
2020-02-24 19:44   ` Christoph Hellwig
2020-02-24 19:44   ` Christoph Hellwig
2020-02-24 21:53   ` Ira Weiny
2020-02-24 21:53     ` [OpenRISC] " Ira Weiny
2020-02-24 21:53     ` Ira Weiny
2020-02-24 21:53     ` Ira Weiny
2020-02-24 21:56     ` Christoph Hellwig
2020-02-24 21:56       ` [OpenRISC] " Christoph Hellwig
2020-02-24 21:56       ` Christoph Hellwig
2020-02-24 21:56       ` Christoph Hellwig
2020-02-24 19:44 ` [PATCH 5/5] openrisc: use the generic in-place uncached DMA allocator Christoph Hellwig
2020-02-24 19:44   ` [OpenRISC] " Christoph Hellwig
2020-02-24 19:44   ` Christoph Hellwig
2020-02-24 19:44   ` Christoph Hellwig
2020-02-25 10:09   ` Stafford Horne
2020-02-25 10:09     ` [OpenRISC] " Stafford Horne
2020-02-25 10:09     ` Stafford Horne
2020-02-25 10:09     ` Stafford Horne
2020-03-02 16:05 ` Robin Murphy [this message]
2020-03-02 16:05   ` [OpenRISC] provide in-place uncached remapping for dma-direct v2 Robin Murphy
2020-03-02 16:05   ` Robin Murphy
2020-03-02 16:05   ` Robin Murphy

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=4fe14c57-78d4-6590-a4c4-14fbe061238e@arm.com \
    --to=robin.murphy@arm.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jonas@southpole.se \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=openrisc@lists.librecores.org \
    --cc=shorne@gmail.com \
    --cc=stefan.kristiansson@saunalahti.fi \
    --cc=will@kernel.org \
    /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.