All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Cc: Tom Lendacky <thomas.lendacky-5C7GfCeVMHo@public.gmane.org>,
	Konrad Rzeszutek Wilk
	<konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>,
	x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Muli Ben-Yehuda <mulix-BzGcCpaT2IbYtjvyW6yDsg@public.gmane.org>,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Subject: Re: [PATCH 04/13] x86: use generic swiotlb_ops
Date: Mon, 12 Mar 2018 09:26:33 +0100	[thread overview]
Message-ID: <20180312082633.GA5724@lst.de> (raw)
In-Reply-To: <825d4b49-8fa2-e670-75e3-77a88258af3a-5wv7dgnIgG8@public.gmane.org>

On Thu, Mar 08, 2018 at 04:03:12PM +0000, Robin Murphy wrote:
>> Also fix the sta2x11 case.  For that SOC the dma map ops need an
>> additional physical to dma address translations.  For swiotlb buffers
>> that is done throught the phys_to_dma helper, but the sta2x11_dma_ops
>> also added an additional translation on the return value from
>> x86_swiotlb_alloc_coherent, which is only correct if that functions
>> returns a direct allocation and not a swiotlb buffer.  With the
>> generic swiotlb and dma-direct code phys_to_dma is not always used
>> and the separate sta2x11_dma_ops can be replaced with a simple
>> bit that marks if the additional physical to dma address translation
>> is needed.
>
> FWIW, last time I looked I got the impression that STA2x11 could just use 
> dma_pfn_offset - the comments and a2p/p2a logic in sta2x11-fixup.c 
> certainly imply that the underlying hardware situation is pretty much 
> exactly that for which dma_pfn_offset exists.

That probably is the case.  But without access to the hardware I don't
feel like doing this deeper surgery.  And even without that this case
provides a great simplification.

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Christoph Hellwig <hch@lst.de>,
	x86@kernel.org, Tom Lendacky <thomas.lendacky@amd.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-kernel@vger.kernel.org, Muli Ben-Yehuda <mulix@mulix.org>,
	iommu@lists.linux-foundation.org,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH 04/13] x86: use generic swiotlb_ops
Date: Mon, 12 Mar 2018 09:26:33 +0100	[thread overview]
Message-ID: <20180312082633.GA5724@lst.de> (raw)
In-Reply-To: <825d4b49-8fa2-e670-75e3-77a88258af3a@arm.com>

On Thu, Mar 08, 2018 at 04:03:12PM +0000, Robin Murphy wrote:
>> Also fix the sta2x11 case.  For that SOC the dma map ops need an
>> additional physical to dma address translations.  For swiotlb buffers
>> that is done throught the phys_to_dma helper, but the sta2x11_dma_ops
>> also added an additional translation on the return value from
>> x86_swiotlb_alloc_coherent, which is only correct if that functions
>> returns a direct allocation and not a swiotlb buffer.  With the
>> generic swiotlb and dma-direct code phys_to_dma is not always used
>> and the separate sta2x11_dma_ops can be replaced with a simple
>> bit that marks if the additional physical to dma address translation
>> is needed.
>
> FWIW, last time I looked I got the impression that STA2x11 could just use 
> dma_pfn_offset - the comments and a2p/p2a logic in sta2x11-fixup.c 
> certainly imply that the underlying hardware situation is pretty much 
> exactly that for which dma_pfn_offset exists.

That probably is the case.  But without access to the hardware I don't
feel like doing this deeper surgery.  And even without that this case
provides a great simplification.

  parent reply	other threads:[~2018-03-12  8:26 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-05 17:46 use generic dma-direct and swiotlb code for x86 Christoph Hellwig
2018-03-05 17:46 ` [PATCH 08/13] iommu/intel-iommu: cleanup intel_{alloc,free}_coherent Christoph Hellwig
2018-03-05 17:46 ` [PATCH 10/13] set_memory.h: provide set_memory_{en,de}crypted stubs Christoph Hellwig
2018-03-05 17:46 ` [PATCH 11/13] dma-direct: handle the memory encryption bit in common code Christoph Hellwig
     [not found]   ` <20180305174655.9878-12-hch-jcswGhMUV9g@public.gmane.org>
2018-03-12 18:29     ` Tom Lendacky
2018-03-12 18:29       ` Tom Lendacky
     [not found]       ` <114e27be-5814-4258-4985-af08763c8a74-5C7GfCeVMHo@public.gmane.org>
2018-03-12 19:48         ` Tom Lendacky
2018-03-12 19:48           ` Tom Lendacky
     [not found]           ` <0c9d3e4a-8407-282a-73eb-21d28047e0e3-5C7GfCeVMHo@public.gmane.org>
2018-03-13 13:10             ` Christoph Hellwig
2018-03-13 13:10               ` Christoph Hellwig
     [not found]               ` <20180313131005.GA6260-jcswGhMUV9g@public.gmane.org>
2018-03-14 15:44                 ` Tom Lendacky
2018-03-14 15:44                   ` Tom Lendacky
     [not found]                   ` <69e98163-beca-fb8a-a26b-66dfeef2f689-5C7GfCeVMHo@public.gmane.org>
2018-03-19 10:39                     ` Christoph Hellwig
2018-03-19 10:39                       ` Christoph Hellwig
     [not found]                       ` <20180319103939.GA23333-jcswGhMUV9g@public.gmane.org>
2018-03-19 13:17                         ` Tom Lendacky
2018-03-19 13:17                           ` Tom Lendacky
     [not found] ` <20180305174655.9878-1-hch-jcswGhMUV9g@public.gmane.org>
2018-03-05 17:46   ` [PATCH 01/13] x86: remove X86_PPRO_FENCE Christoph Hellwig
2018-03-05 17:46     ` Christoph Hellwig
     [not found]     ` <20180305174655.9878-2-hch-jcswGhMUV9g@public.gmane.org>
2018-03-08 21:06       ` Konrad Rzeszutek Wilk
2018-03-08 21:06         ` Konrad Rzeszutek Wilk
2018-03-05 17:46   ` [PATCH 02/13] x86: remove dma_alloc_coherent_mask Christoph Hellwig
2018-03-05 17:46     ` Christoph Hellwig
     [not found]     ` <20180305174655.9878-3-hch-jcswGhMUV9g@public.gmane.org>
2018-03-08 21:30       ` Konrad Rzeszutek Wilk
2018-03-08 21:30         ` Konrad Rzeszutek Wilk
2018-03-05 17:46   ` [PATCH 03/13] x86: use dma-direct Christoph Hellwig
2018-03-05 17:46     ` Christoph Hellwig
2018-03-05 17:46   ` [PATCH 04/13] x86: use generic swiotlb_ops Christoph Hellwig
2018-03-05 17:46     ` Christoph Hellwig
     [not found]     ` <20180305174655.9878-5-hch-jcswGhMUV9g@public.gmane.org>
2018-03-08 16:03       ` Robin Murphy
2018-03-08 16:03         ` Robin Murphy
     [not found]         ` <825d4b49-8fa2-e670-75e3-77a88258af3a-5wv7dgnIgG8@public.gmane.org>
2018-03-12  8:26           ` Christoph Hellwig [this message]
2018-03-12  8:26             ` Christoph Hellwig
2018-03-05 17:46   ` [PATCH 05/13] x86/amd_gart: look at coherent_dma_mask instead of GFP_DMA Christoph Hellwig
2018-03-05 17:46     ` Christoph Hellwig
2018-03-05 17:46   ` [PATCH 06/13] x86/amd_gart: use dma_direct_{alloc,free} Christoph Hellwig
2018-03-05 17:46     ` Christoph Hellwig
2018-03-05 17:46   ` [PATCH 07/13] iommu/amd_iommu: " Christoph Hellwig
2018-03-05 17:46     ` Christoph Hellwig
2018-03-05 17:46   ` [PATCH 09/13] x86: remove dma_alloc_coherent_gfp_flags Christoph Hellwig
2018-03-05 17:46     ` Christoph Hellwig
2018-03-05 17:46   ` [PATCH 12/13] swiotlb: remove swiotlb_set_mem_attributes Christoph Hellwig
2018-03-05 17:46     ` Christoph Hellwig
2018-03-05 17:46 ` [PATCH 13/13] swiotlb: remove swiotlb_{alloc,free}_coherent Christoph Hellwig

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=20180312082633.GA5724@lst.de \
    --to=hch-jcswghmuv9g@public.gmane.org \
    --cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mulix-BzGcCpaT2IbYtjvyW6yDsg@public.gmane.org \
    --cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \
    --cc=thomas.lendacky-5C7GfCeVMHo@public.gmane.org \
    --cc=x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.