All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, will@kernel.org,
	robin.murphy@arm.com, m.szyprowski@samsung.com, hch@lst.de,
	phil@raspberrypi.org, stefan.wahren@i2se.com,
	f.fainelli@gmail.com, mbrugger@suse.com,
	Jisheng.Zhang@synaptics.com
Subject: Re: [RFC 2/4] arm64: mm: parse dma-ranges in order to better estimate arm64_dma_phys_limit
Date: Wed, 24 Jul 2019 14:54:25 +0100	[thread overview]
Message-ID: <20190724135425.GB44864@arrakis.emea.arm.com> (raw)
In-Reply-To: <20190717153135.15507-3-nsaenzjulienne@suse.de>

On Wed, Jul 17, 2019 at 05:31:33PM +0200, Nicolas Saenz Julienne wrote:
> The dma physical limit has so far been calculated based on the memory
> size and the assumption that dma would be at least able to address the
> first 4 GB. This turned out no to be true with the Raspberry Pi 4
> which, on it's main interconnect, can only address the first GB of
> memory, even though it might have up to 4 GB.
> 
> With the current miscalculated dma physical limit the contiguous memory
> reserve is located in an inaccessible area for most of the board's
> devices.
> 
> To solve this we now scan the device tree for the 'dma-ranges' property
> on the root or interconnect nodes, which allows us to calculate the
> lowest common denominator dma physical limit. If no dma-ranges is
> available, we'll default to the old scheme.
> 
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
>  arch/arm64/mm/init.c | 61 +++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 57 insertions(+), 4 deletions(-)

I'd rather have this parsing in the core code, returning setting the
minimum DMA mask (or range, address etc.) that covers all devices/buses
described.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: stefan.wahren@i2se.com, f.fainelli@gmail.com, will@kernel.org,
	phil@raspberrypi.org, linux-kernel@vger.kernel.org,
	Jisheng.Zhang@synaptics.com, mbrugger@suse.com,
	robin.murphy@arm.com, hch@lst.de,
	linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com
Subject: Re: [RFC 2/4] arm64: mm: parse dma-ranges in order to better estimate arm64_dma_phys_limit
Date: Wed, 24 Jul 2019 14:54:25 +0100	[thread overview]
Message-ID: <20190724135425.GB44864@arrakis.emea.arm.com> (raw)
In-Reply-To: <20190717153135.15507-3-nsaenzjulienne@suse.de>

On Wed, Jul 17, 2019 at 05:31:33PM +0200, Nicolas Saenz Julienne wrote:
> The dma physical limit has so far been calculated based on the memory
> size and the assumption that dma would be at least able to address the
> first 4 GB. This turned out no to be true with the Raspberry Pi 4
> which, on it's main interconnect, can only address the first GB of
> memory, even though it might have up to 4 GB.
> 
> With the current miscalculated dma physical limit the contiguous memory
> reserve is located in an inaccessible area for most of the board's
> devices.
> 
> To solve this we now scan the device tree for the 'dma-ranges' property
> on the root or interconnect nodes, which allows us to calculate the
> lowest common denominator dma physical limit. If no dma-ranges is
> available, we'll default to the old scheme.
> 
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
>  arch/arm64/mm/init.c | 61 +++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 57 insertions(+), 4 deletions(-)

I'd rather have this parsing in the core code, returning setting the
minimum DMA mask (or range, address etc.) that covers all devices/buses
described.

-- 
Catalin

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

  reply	other threads:[~2019-07-24 13:54 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-17 15:31 [RFC 0/4] Raspberry Pi 4 DMA addressing support Nicolas Saenz Julienne
2019-07-17 15:31 ` Nicolas Saenz Julienne
2019-07-17 15:31 ` Nicolas Saenz Julienne
2019-07-17 15:31 ` [RFC 1/4] arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() Nicolas Saenz Julienne
2019-07-17 15:31   ` Nicolas Saenz Julienne
2019-07-17 15:31 ` [RFC 2/4] arm64: mm: parse dma-ranges in order to better estimate arm64_dma_phys_limit Nicolas Saenz Julienne
2019-07-17 15:31   ` Nicolas Saenz Julienne
2019-07-24 13:54   ` Catalin Marinas [this message]
2019-07-24 13:54     ` Catalin Marinas
2019-07-17 15:31 ` [RFC 3/4] dma-direct: add dma_direct_min_mask Nicolas Saenz Julienne
2019-07-17 15:31   ` Nicolas Saenz Julienne
2019-07-17 15:31   ` Nicolas Saenz Julienne
2019-07-18  9:15   ` Christoph Hellwig
2019-07-18  9:15     ` Christoph Hellwig
2019-07-18  9:15     ` Christoph Hellwig
2019-07-18 11:18     ` Nicolas Saenz Julienne
2019-07-18 11:18       ` Nicolas Saenz Julienne
2019-07-18 11:18       ` Nicolas Saenz Julienne
2019-07-19 13:08       ` Nicolas Saenz Julienne
2019-07-19 13:08         ` Nicolas Saenz Julienne
2019-07-19 13:08         ` Nicolas Saenz Julienne
2019-07-24 13:51         ` Catalin Marinas
2019-07-24 13:51           ` Catalin Marinas
2019-07-24 13:51           ` Catalin Marinas
2019-07-24 13:56           ` Christoph Hellwig
2019-07-24 13:56             ` Christoph Hellwig
2019-07-24 13:56             ` Christoph Hellwig
2019-07-24 14:27             ` Nicolas Saenz Julienne
2019-07-24 14:27               ` Nicolas Saenz Julienne
2019-07-24 14:27               ` Nicolas Saenz Julienne
2019-07-17 15:31 ` [RFC 4/4] arm64: mm: set direct_dma_min_mask according to dma-ranges Nicolas Saenz Julienne
2019-07-17 15:31   ` Nicolas Saenz Julienne

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=20190724135425.GB44864@arrakis.emea.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=Jisheng.Zhang@synaptics.com \
    --cc=f.fainelli@gmail.com \
    --cc=hch@lst.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mbrugger@suse.com \
    --cc=nsaenzjulienne@suse.de \
    --cc=phil@raspberrypi.org \
    --cc=robin.murphy@arm.com \
    --cc=stefan.wahren@i2se.com \
    --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.