linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	 "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	 Linux Memory Management List <linux-mm@kvack.org>,
	iommu@lists.linux-foundation.org,
	 Rob Herring <robh+dt@kernel.org>,
	linux-rpi-kernel@lists.infradead.org,
	 Will Deacon <will@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711
Date: Fri, 9 Oct 2020 09:37:39 +0200	[thread overview]
Message-ID: <CAMj1kXG+7Lq=rgUfyU_XS9LrJwpUiC8nKsRPom+R0=phuXioHQ@mail.gmail.com> (raw)
In-Reply-To: <20201009071013.GA12208@lst.de>

On Fri, 9 Oct 2020 at 09:11, Christoph Hellwig <hch@lst.de> wrote:
>
> On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote:
> > Sadly I just realised that the series is incomplete, we have RPi4 users that
> > want to boot unsing ACPI, and this series would break things for them. I'll
> > have a word with them to see what we can do for their use-case.
>
> Stupid question:  why do these users insist on a totally unsuitable
> interface?  And why would we as Linux developers care to support such
> a aims?
>

The point is really whether we want to revert changes in Linux that
made both DT and ACPI boot work without quirks on RPi4. Having to
check the RPi4 compatible string or OEM id in core init code is awful,
regardless of whether you boot via ACPI or via DT.

The problem with this hardware is that it uses a DMA mask which is
narrower than 32, and the arm64 kernel is simply not set up to deal
with that at all. On DT, we have DMA ranges properties and the likes
to describe such limitations, on ACPI we have _DMA methods as well as
DMA range attributes in the IORT, both of which are now handled
correctly. So all the information is there, we just have to figure out
how to consume it early on.

Interestingly, this limitation always existed in the SoC, but it
wasn't until they started shipping it with more than 1 GB of DRAM that
it became a problem. This means issues like this could resurface in
the future with existing SoCs when they get shipped with more memory,
and so I would prefer fixing this in a generic way.

Also, I assume papering over the issue like this does not fix the
kdump issue fundamentally, it just works around it, and so we might
run into this again in the future.


  reply	other threads:[~2020-10-09  7:37 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01 16:17 [PATCH 0/4] arm64: Default to 32-bit wide ZONE_DMA Nicolas Saenz Julienne
2020-10-01 16:17 ` [PATCH 1/4] of/fdt: Update zone_dma_bits when running in bcm2711 Nicolas Saenz Julienne
2020-10-01 17:15   ` Catalin Marinas
2020-10-01 17:23     ` Catalin Marinas
2020-10-01 17:31       ` Nicolas Saenz Julienne
2020-10-01 20:02         ` Rob Herring
2020-10-02 11:55         ` Catalin Marinas
2020-10-08 10:05           ` Nicolas Saenz Julienne
2020-10-08 10:13             ` Catalin Marinas
2020-10-08 19:43               ` Ard Biesheuvel
2020-10-09  3:59                 ` Jeremy Linton
2020-10-09  8:37                   ` Nicolas Saenz Julienne
2020-10-09  7:10             ` Christoph Hellwig
2020-10-09  7:37               ` Ard Biesheuvel [this message]
2020-10-09  8:36                 ` Nicolas Saenz Julienne
2020-10-09  9:13                   ` Ard Biesheuvel
2020-10-09 13:33                     ` Nicolas Saenz Julienne
2020-10-09 15:24                     ` Lorenzo Pieralisi
2020-10-09 16:23                       ` Ard Biesheuvel
2020-10-09 17:10                         ` Catalin Marinas
2020-10-10 10:36                           ` Ard Biesheuvel
2020-10-10 10:53                             ` Nicolas Saenz Julienne
2020-10-10 12:38                               ` Catalin Marinas
2020-10-12  6:47                           ` Christoph Hellwig
2020-10-12  8:47                             ` Catalin Marinas
2020-10-02  9:05   ` kernel test robot
2020-10-01 16:17 ` [PATCH 2/4] dma-direct: Turn zone_dma_bits default value into a define Nicolas Saenz Julienne
2020-10-01 16:17 ` [PATCH 3/4] arm64: Default to 32-bit ZONE_DMA Nicolas Saenz Julienne
2020-10-01 17:19   ` Catalin Marinas
2020-10-01 16:17 ` [PATCH 4/4] mm: Update DMA zones description Nicolas Saenz Julienne
2020-10-01 17:19   ` Catalin Marinas

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='CAMj1kXG+7Lq=rgUfyU_XS9LrJwpUiC8nKsRPom+R0=phuXioHQ@mail.gmail.com' \
    --to=ardb@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=nsaenzjulienne@suse.de \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.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 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).