All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Robin Murphy <robin.murphy@arm.com>
Cc: drinkcat@chromium.org, devicetree@vger.kernel.org,
	heikki.krogerus@linux.intel.com, saravanak@google.com,
	suzuki.poulose@arm.com, gregkh@linuxfoundation.org,
	linux-kernel@vger.kernel.org, bgolaszewski@baylibre.com,
	iommu@lists.linux-foundation.org, robh+dt@kernel.org,
	Claire Chang <tientzu@chromium.org>,
	dan.j.williams@intel.com, treding@nvidia.com,
	frowand.list@gmail.com, hch@lst.de
Subject: Re: [PATCH 1/4] dma-mapping: Add bounced DMA ops
Date: Tue, 14 Jul 2020 13:01:41 +0200	[thread overview]
Message-ID: <20200714110141.GD16178@lst.de> (raw)
In-Reply-To: <4a2451f9-57d8-2e83-e1d6-f144f37173c0@arm.com>

On Mon, Jul 13, 2020 at 12:55:43PM +0100, Robin Murphy wrote:
> On 2020-07-13 10:12, Claire Chang wrote:
>> The bounced DMA ops provide an implementation of DMA ops that bounce
>> streaming DMA in and out of a specially allocated region. Only the
>> operations relevant to streaming DMA are supported.
>
> I think there are too many implicit assumptions here - apparently that 
> coherent allocations will always be intercepted by 
> dma_*_from_dev_coherent(), and that calling into dma-direct won't actually 
> bounce things a second time beyond where you thought they were going, 
> manage coherency for a different address, and make it all go subtly wrong. 
> Consider "swiotlb=force", for instance...
>
> Again, plumbing this straight into dma-direct so that SWIOTLB can simply 
> target a different buffer and always bounce regardless of masks would seem 
> a far better option.

I haven't really had time to read through the details, but I agree that
any bouncing scheme should reuse the swiotlb code and not invent a
parallel infrastructure.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Claire Chang <tientzu@chromium.org>,
	robh+dt@kernel.org, frowand.list@gmail.com, hch@lst.de,
	m.szyprowski@samsung.com, treding@nvidia.com,
	gregkh@linuxfoundation.org, saravanak@google.com,
	suzuki.poulose@arm.com, dan.j.williams@intel.com,
	heikki.krogerus@linux.intel.com, bgolaszewski@baylibre.com,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org, tfiga@chromium.org,
	drinkcat@chromium.org
Subject: Re: [PATCH 1/4] dma-mapping: Add bounced DMA ops
Date: Tue, 14 Jul 2020 13:01:41 +0200	[thread overview]
Message-ID: <20200714110141.GD16178@lst.de> (raw)
In-Reply-To: <4a2451f9-57d8-2e83-e1d6-f144f37173c0@arm.com>

On Mon, Jul 13, 2020 at 12:55:43PM +0100, Robin Murphy wrote:
> On 2020-07-13 10:12, Claire Chang wrote:
>> The bounced DMA ops provide an implementation of DMA ops that bounce
>> streaming DMA in and out of a specially allocated region. Only the
>> operations relevant to streaming DMA are supported.
>
> I think there are too many implicit assumptions here - apparently that 
> coherent allocations will always be intercepted by 
> dma_*_from_dev_coherent(), and that calling into dma-direct won't actually 
> bounce things a second time beyond where you thought they were going, 
> manage coherency for a different address, and make it all go subtly wrong. 
> Consider "swiotlb=force", for instance...
>
> Again, plumbing this straight into dma-direct so that SWIOTLB can simply 
> target a different buffer and always bounce regardless of masks would seem 
> a far better option.

I haven't really had time to read through the details, but I agree that
any bouncing scheme should reuse the swiotlb code and not invent a
parallel infrastructure.

  reply	other threads:[~2020-07-14 11:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13  9:12 [PATCH 0/4] Bounced DMA support Claire Chang
2020-07-13  9:12 ` Claire Chang
2020-07-13  9:12 ` [PATCH 1/4] dma-mapping: Add bounced DMA ops Claire Chang
2020-07-13  9:12   ` Claire Chang
2020-07-13 11:55   ` Robin Murphy
2020-07-13 11:55     ` Robin Murphy
2020-07-14 11:01     ` Christoph Hellwig [this message]
2020-07-14 11:01       ` Christoph Hellwig
2020-07-15  3:46       ` Claire Chang
2020-07-15  3:46         ` Claire Chang
2020-07-15  9:04         ` Claire Chang
2020-07-15  9:04           ` Claire Chang
2020-07-28  5:05           ` Claire Chang
2020-07-28  5:05             ` Claire Chang
2020-07-13  9:12 ` [PATCH 2/4] dma-mapping: Add bounced DMA pool Claire Chang
2020-07-13  9:12   ` Claire Chang
2020-07-13  9:12 ` [PATCH 3/4] dt-bindings: of: Add plumbing for " Claire Chang
2020-07-13  9:12   ` Claire Chang
2020-07-13  9:12 ` [PATCH 4/4] " Claire Chang
2020-07-13  9:12   ` Claire Chang
2020-07-13 11:39 ` [PATCH 0/4] Bounced DMA support Robin Murphy
2020-07-13 11:39   ` Robin Murphy
2020-07-15  3:43   ` Claire Chang
2020-07-15  3:43     ` Claire Chang
2020-07-15 17:53     ` Robin Murphy
2020-07-15 17:53       ` 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=20200714110141.GD16178@lst.de \
    --to=hch@lst.de \
    --cc=bgolaszewski@baylibre.com \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=saravanak@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tientzu@chromium.org \
    --cc=treding@nvidia.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.