public inbox for linux-ide@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>, Roger Quadros <rogerq@ti.com>,
	"hdegoede@redhat.com" <hdegoede@redhat.com>,
	axboe@kernel.dk, iommu@lists.linux-foundation.org,
	linux-ide@vger.kernel.org, linux-omap@vger.kernel.org,
	jejb@linux.ibm.com, martin.petersen@oracle.com, "Nori,
	Sekhar" <nsekhar@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>,
	Tony Lindgren <tony@atomide.com>
Subject: Re: SATA broken with LPAE
Date: Thu, 27 Jun 2019 11:15:30 +0200	[thread overview]
Message-ID: <20190627091530.GA11809@lst.de> (raw)
In-Reply-To: <20190627090753.b5xfpnsicynnqj5c@shell.armlinux.org.uk>

On Thu, Jun 27, 2019 at 10:07:53AM +0100, Russell King - ARM Linux admin wrote:
> dmabounce has only ever been used with specific devices that have weird
> setups.  Otherwise, we've never expected what you describe on ARM.  I
> also don't recognise your assertion about the way the DMA API should
> behave as ever having been documented as a requirement for architectures
> to implement.

That requirement has basically always been there since at least the
2.6.x days.  The history here is that when 64-bit architectures showed
up they all had iommus, so this wasn't an issue.  Next was x86 with
highmem, which added special bounce buffering for block I/O and networking
only.  Then ia64 showed up that didn't always have an iommu and swiotlb
was added as a "software IOMMU".  At this point we had to bounce buffering
schemes for block and networking, while everything else potentially
DMAing to higher memory relied on swiotlb, which was picked up by
basically every architecture that could have memory not covered by a
32-bit mask and didn't have an iommu.  Except it seems arm never did
that and has been lucky as people didn't try anything that is not
block or networking on their extended physical address space.

  reply	other threads:[~2019-06-27  9:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-26  8:43 SATA broken with LPAE Roger Quadros
2019-06-26 12:53 ` Christoph Hellwig
2019-06-27  9:07   ` Russell King - ARM Linux admin
2019-06-27  9:15     ` Christoph Hellwig [this message]
2019-06-27 10:09       ` Russell King - ARM Linux admin

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=20190627091530.GA11809@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=hdegoede@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jejb@linux.ibm.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=martin.petersen@oracle.com \
    --cc=nsekhar@ti.com \
    --cc=rogerq@ti.com \
    --cc=tony@atomide.com \
    --cc=vigneshr@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox