linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: robh@kernel.org, vigneshr@ti.com, konrad.wilk@oracle.com,
	linux@armlinux.org.uk, linux-kernel@vger.kernel.org,
	iommu@lists.linux-foundation.org,
	Robin Murphy <robin.murphy@arm.com>,
	hch@lst.de, linux-arm-kernel@lists.infradead.org, rogerq@ti.com
Subject: Re: [PoC] arm: dma-mapping: direct: Apply dma_pfn_offset only when it is valid
Date: Thu, 30 Jan 2020 08:53:32 +0100	[thread overview]
Message-ID: <20200130075332.GA30735@lst.de> (raw)
In-Reply-To: <75843c71-1718-8d61-5e3d-edba6e1b10bd@ti.com>

[skipping the DT bits, as I'm everything but an expert on that..]

On Mon, Jan 27, 2020 at 04:00:30PM +0200, Peter Ujfalusi wrote:
> I agree on the phys_to_dma(). It should fail for addresses which does
> not fall into any of the ranges.
> It is just a that we in Linux don't have the concept atm for ranges, we
> have only _one_ range which applies to every memory address.

what does atm here mean?

We have needed multi-range support for quite a while, as common broadcom
SOCs do need it.  So patches for that are welcome at least from the
DMA layer perspective (kinda similar to your pseudo code earlier)

> > Nobody's disputing that the current dma_direct_supported()
> > implementation is broken for the case where ZONE_DMA itself is offset
> > from PA 0; the more pressing question is why Christoph's diff, which was
> > trying to take that into account, still didn't work.
> 
> I understand that this is a bit more complex than I interpret it, but
> the k2g is broken and currently the simplest way to make it work is to
> use the arm dma_ops in case the pfn_offset is not 0.
> It will be easy to test dma-direct changes trying to address the issue
> in hand, but will allow k2g to be usable at the same time.

Well, using the legacy arm dma ops means we can't use swiotlb if there
is an offset, which is also wrong for lots of common cases, including
the Rpi 4.  I'm still curious why my patch didn't work, as I thought
it should.  We'll need to find the minimum change to make it work
for now without switching ops, even if it isn't the correct one, and
then work from there.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-01-30  7:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-09 14:20 add swiotlb support to arm32 Christoph Hellwig
2019-07-09 14:20 ` [PATCH 1/2] dma-mapping check pfn validity in dma_common_{mmap, get_sgtable} Christoph Hellwig
2019-07-09 14:20 ` [PATCH 2/2] arm: use swiotlb for bounce buffer on LPAE configs Christoph Hellwig
2019-07-24 17:23   ` Nicolas Saenz Julienne
2019-07-24 17:55     ` Christoph Hellwig
2019-12-19 13:10   ` Peter Ujfalusi
2019-12-19 15:02     ` Christoph Hellwig
2019-12-19 15:20       ` Peter Ujfalusi
2020-01-08  8:28         ` Peter Ujfalusi
2020-01-08 12:21           ` Robin Murphy
2020-01-08 14:00             ` Peter Ujfalusi
2020-01-08 15:20               ` Robin Murphy
2020-01-09 14:49                 ` Christoph Hellwig
2020-01-14 10:43                   ` Peter Ujfalusi
2020-01-14 16:43                     ` [PoC] arm: dma-mapping: direct: Apply dma_pfn_offset only when it is valid Peter Ujfalusi
2020-01-14 18:19                       ` Robin Murphy
2020-01-15 11:50                         ` Peter Ujfalusi
2020-01-16 19:13                           ` Robin Murphy
2020-01-27 14:00                             ` Peter Ujfalusi
2020-01-30  7:53                               ` Christoph Hellwig [this message]
2020-01-30 13:04                                 ` Peter Ujfalusi
2020-01-30 16:40                                   ` Christoph Hellwig
2020-01-31 13:59                                     ` Peter Ujfalusi
2020-01-31 14:00                                     ` Peter Ujfalusi
2020-01-31 14:00                                     ` Peter Ujfalusi
2020-02-03 17:08                                       ` Christoph Hellwig
2020-02-05 10:19                                         ` Peter Ujfalusi
2019-07-17 13:21 ` add swiotlb support to arm32 Vignesh Raghavendra
2019-07-19 12:33   ` Christoph Hellwig
2019-07-24 15:37   ` 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=20200130075332.GA30735@lst.de \
    --to=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=peter.ujfalusi@ti.com \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=rogerq@ti.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;
as well as URLs for NNTP newsgroup(s).