Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support

From: Florian Fainelli <f.fainelli@gmail.com>
To: Matthias Brugger <matthias.bgg@gmail.com>,
	Matthias Brugger <mbrugger@suse.com>,
	Stefan Wahren <wahrenst@gmx.net>,
	catalin.marinas@arm.com, marc.zyngier@arm.com,
	robh+dt@kernel.org, linux-mm@kvack.org,
	linux-arm-kernel@lists.infradead.org,
	linux-riscv@lists.infradead.org, hch@lst.de,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Cc: robin.murphy@arm.com, linux-kernel@vger.kernel.org,
	linux-rpi-kernel@lists.infradead.org, phill@raspberrypi.org,
	will@kernel.org, m.szyprowski@samsung.com
Subject: Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
Date: Thu, 12 Sep 2019 10:27:23 -0700	[thread overview]
Message-ID: <abc4b2b9-41ee-16f0-5102-6032182738be@gmail.com> (raw)
In-Reply-To: <09f82f88-a13a-b441-b723-7bb061a2f1e3@gmail.com>

On 9/12/19 10:18 AM, Matthias Brugger wrote:
> 
> 
> On 10/09/2019 11:27, Matthias Brugger wrote:
>>
>>
>> On 09/09/2019 21:33, Stefan Wahren wrote:
>>> Hi Nicolas,
>>>
>>> Am 09.09.19 um 11:58 schrieb Nicolas Saenz Julienne:
>>>> Hi all,
>>>> this series attempts to address some issues we found while bringing up
>>>> the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow
>>>> up of these discussions:
>>>> v4: https://lkml.org/lkml/2019/9/6/352
>>>> v3: https://lkml.org/lkml/2019/9/2/589
>>>> v2: https://lkml.org/lkml/2019/8/20/767
>>>> v1: https://lkml.org/lkml/2019/7/31/922
>>>> RFC: https://lkml.org/lkml/2019/7/17/476
>>>>
>>>> The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can
>>>> only address the first GB: their DMA address range is
>>>> 0xc0000000-0xfc000000 which is aliased to the first GB of physical
>>>> memory 0x00000000-0x3c000000. Note that only some peripherals have these
>>>> limitations: the PCIe, V3D, GENET, and 40-bit DMA channels have a wider
>>>> view of the address space by virtue of being hooked up trough a second
>>>> interconnect.
>>>>
>>>> Part of this is solved on arm32 by setting up the machine specific
>>>> '.dma_zone_size = SZ_1G', which takes care of reserving the coherent
>>>> memory area at the right spot. That said no buffer bouncing (needed for
>>>> dma streaming) is available at the moment, but that's a story for
>>>> another series.
>>>>
>>>> Unfortunately there is no such thing as 'dma_zone_size' in arm64. Only
>>>> ZONE_DMA32 is created which is interpreted by dma-direct and the arm64
>>>> arch code as if all peripherals where be able to address the first 4GB
>>>> of memory.
>>>>
>>>> In the light of this, the series implements the following changes:
>>>>
>>>> - Create both DMA zones in arm64, ZONE_DMA will contain the first 1G
>>>>   area and ZONE_DMA32 the rest of the 32 bit addressable memory. So far
>>>>   the RPi4 is the only arm64 device with such DMA addressing limitations
>>>>   so this hardcoded solution was deemed preferable.
>>>>
>>>> - Properly set ARCH_ZONE_DMA_BITS.
>>>>
>>>> - Reserve the CMA area in a place suitable for all peripherals.
>>>>
>>>> This series has been tested on multiple devices both by checking the
>>>> zones setup matches the expectations and by double-checking physical
>>>> addresses on pages allocated on the three relevant areas GFP_DMA,
>>>> GFP_DMA32, GFP_KERNEL:
>>>>
>>>> - On an RPi4 with variations on the ram memory size. But also forcing
>>>>   the situation where all three memory zones are nonempty by setting a 3G
>>>>   ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support.
>>>>
>>> i like to test this series on Raspberry Pi 4 and i have some questions
>>> to get arm64 running:
>>>
>>> Do you use U-Boot? Which tree?
>>
>> If you want to use U-Boot, try v2019.10-rc4, it should have everything you need
>> to boot your kernel.
>>
> 
> Ok, here is a thing. In the linux kernel we now use bcm2711 as SoC name, but the
> RPi4 devicetree provided by the FW uses mostly bcm2838. U-Boot in its default
> config uses the devicetree provided by the FW, mostly because this way you don't
> have to do anything to find out how many RAM you really have. Secondly because
> this will allow us, in the near future, to have one U-boot binary for both RPi3
> and RPi4 (and as a side effect one binary for RPi1 and RPi2).

Fairly sure we had the conversation a few weeks ago about whether to
chose bcm2711 or bcm2838 for the compatible string. In all cases, the
actual HW this designates is the same, but there was a consistency
argument that 2838, is numerically + 1 than its predecessor and might be
how the RPi would be announced, even if the chip silkscreen says 2711.

If we start adding 2711, does that mean we should also add 2708/09/10 to
existing 2835/36/37 compatible strings or has that ship sailed?
-- 
Florian

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