| Message ID | 20190909095807.18709-1-nsaenzjulienne@suse.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | Raspberry Pi 4 DMA addressing support | expand |
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? Are there any config.txt tweaks necessary?
On Mon, 2019-09-09 at 21:33 +0200, 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? No, I boot directly. > Are there any config.txt tweaks necessary? I'm using the foundation's arm64 stub. Though I'm not 100% it's needed anymore with the latest firmware. config.txt: arm_64bit=1 armstub=armstub8-gic.bin enable_gic=1 enable_uart=1 Apart from that the series is based on today's linux-next plus your RPi4 bringup patches.
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. Regards, Matthias > Are there any config.txt tweaks necessary? > >
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). Anyway, I found at least, that the following compatibles need to be added: "brcm,bcm2838-cprman" "brcm,bcm2838-gpio" Without at least the cprman driver update, you won't see anything. "brcm,bcm2838-rng200" is also a candidate. I also suppose we will need to add "brcm,bcm2838" to arch/arm/mach-bcm/bcm2711.c, but I haven't verified this. Regards, Matthias > Regards, > Matthias > >> Are there any config.txt tweaks necessary? >> >> > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
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?
Am 12.09.19 um 19:18 schrieb Matthias Brugger: > > 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. Do you mean the DTB provided at runtime? You mean the merged U-Boot changes, doesn't work with my Raspberry Pi series? > 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). > > Anyway, I found at least, that the following compatibles need to be added: > > "brcm,bcm2838-cprman" > "brcm,bcm2838-gpio" > > Without at least the cprman driver update, you won't see anything. > > "brcm,bcm2838-rng200" is also a candidate. > > I also suppose we will need to add "brcm,bcm2838" to > arch/arm/mach-bcm/bcm2711.c, but I haven't verified this. How about changing this in the downstream kernel? Which is much easier. > > Regards, > Matthias > >> Regards, >> Matthias >> >>> Are there any config.txt tweaks necessary? >>> >>> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 12/09/2019 21:32, Stefan Wahren wrote: > > Am 12.09.19 um 19:18 schrieb Matthias Brugger: >> >> 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. > > Do you mean the DTB provided at runtime? > Yes. > You mean the merged U-Boot changes, doesn't work with my Raspberry Pi > series? > Unfortunately that is exactly the state right now. >> 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). >> >> Anyway, I found at least, that the following compatibles need to be added: >> >> "brcm,bcm2838-cprman" >> "brcm,bcm2838-gpio" >> >> Without at least the cprman driver update, you won't see anything. >> >> "brcm,bcm2838-rng200" is also a candidate. >> >> I also suppose we will need to add "brcm,bcm2838" to >> arch/arm/mach-bcm/bcm2711.c, but I haven't verified this. > How about changing this in the downstream kernel? Which is much easier. >> >> Regards, >> Matthias >> >>> Regards, >>> Matthias >>> >>>> Are there any config.txt tweaks necessary? >>>> >>>> >>> _______________________________________________ >>> linux-arm-kernel mailing list >>> linux-arm-kernel@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
On 12/09/2019 21:32, Stefan Wahren wrote: > > Am 12.09.19 um 19:18 schrieb Matthias Brugger: >> >> 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. > > Do you mean the DTB provided at runtime? > > You mean the merged U-Boot changes, doesn't work with my Raspberry Pi > series? > >> 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). >> >> Anyway, I found at least, that the following compatibles need to be added: >> >> "brcm,bcm2838-cprman" >> "brcm,bcm2838-gpio" >> >> Without at least the cprman driver update, you won't see anything. >> >> "brcm,bcm2838-rng200" is also a candidate. >> >> I also suppose we will need to add "brcm,bcm2838" to >> arch/arm/mach-bcm/bcm2711.c, but I haven't verified this. > How about changing this in the downstream kernel? Which is much easier. I'm not sure I understand what you want to say. My goal is to use the upstream kernel with the device tree blob provided by the FW. If you talk about the downstream kernel, I suppose you mean we should change this in the FW DT blob and in the downstream kernel. That would work for me. Did I understand you correctly? >> >> Regards, >> Matthias >> >>> Regards, >>> Matthias >>> >>>> Are there any config.txt tweaks necessary? >>>> >>>> >>> _______________________________________________ >>> linux-arm-kernel mailing list >>> linux-arm-kernel@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > >
Am 13.09.19 um 10:09 schrieb Matthias Brugger: > > On 12/09/2019 21:32, Stefan Wahren wrote: >> Am 12.09.19 um 19:18 schrieb Matthias Brugger: >>> 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. >> Do you mean the DTB provided at runtime? >> >> You mean the merged U-Boot changes, doesn't work with my Raspberry Pi >> series? >> >>> 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). >>> >>> Anyway, I found at least, that the following compatibles need to be added: >>> >>> "brcm,bcm2838-cprman" >>> "brcm,bcm2838-gpio" >>> >>> Without at least the cprman driver update, you won't see anything. >>> >>> "brcm,bcm2838-rng200" is also a candidate. >>> >>> I also suppose we will need to add "brcm,bcm2838" to >>> arch/arm/mach-bcm/bcm2711.c, but I haven't verified this. >> How about changing this in the downstream kernel? Which is much easier. > I'm not sure I understand what you want to say. My goal is to use the upstream > kernel with the device tree blob provided by the FW. The device tree blob you are talking is defined in this repository: https://github.com/raspberrypi/linux So the word FW is misleading to me. > If you talk about the > downstream kernel, I suppose you mean we should change this in the FW DT blob > and in the downstream kernel. That would work for me. > > Did I understand you correctly? Yes So i suggest to add the upstream compatibles into the repo mentioned above. Sorry, but in case you decided as a U-Boot developer to be compatible with a unreviewed DT, we also need to make U-Boot compatible with upstream and downstream DT blobs. > >>> Regards, >>> Matthias >>> >>>> Regards, >>>> Matthias >>>> >>>>> Are there any config.txt tweaks necessary? >>>>> >>>>> >>>> _______________________________________________ >>>> linux-arm-kernel mailing list >>>> linux-arm-kernel@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>>> >>> _______________________________________________ >>> linux-arm-kernel mailing list >>> linux-arm-kernel@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>
On 13/09/2019 10:50, Stefan Wahren wrote: > Am 13.09.19 um 10:09 schrieb Matthias Brugger: >> >> On 12/09/2019 21:32, Stefan Wahren wrote: >>> Am 12.09.19 um 19:18 schrieb Matthias Brugger: >>>> 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. >>> Do you mean the DTB provided at runtime? >>> >>> You mean the merged U-Boot changes, doesn't work with my Raspberry Pi >>> series? >>> >>>> 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). >>>> >>>> Anyway, I found at least, that the following compatibles need to be added: >>>> >>>> "brcm,bcm2838-cprman" >>>> "brcm,bcm2838-gpio" >>>> >>>> Without at least the cprman driver update, you won't see anything. >>>> >>>> "brcm,bcm2838-rng200" is also a candidate. >>>> >>>> I also suppose we will need to add "brcm,bcm2838" to >>>> arch/arm/mach-bcm/bcm2711.c, but I haven't verified this. >>> How about changing this in the downstream kernel? Which is much easier. >> I'm not sure I understand what you want to say. My goal is to use the upstream >> kernel with the device tree blob provided by the FW. > > The device tree blob you are talking is defined in this repository: > > https://github.com/raspberrypi/linux > > So the word FW is misleading to me. > No, it's part of https://github.com/raspberrypi/firmware.git file boot/bcm2711-rpi-4-b.dtb >> If you talk about the >> downstream kernel, I suppose you mean we should change this in the FW DT blob >> and in the downstream kernel. That would work for me. >> >> Did I understand you correctly? > > Yes > > So i suggest to add the upstream compatibles into the repo mentioned above. > > Sorry, but in case you decided as a U-Boot developer to be compatible > with a unreviewed DT, we also need to make U-Boot compatible with > upstream and downstream DT blobs. > Well RPi3 is working with the DT blob provided by the FW, as I mentioned earlier if we can use this DTB we can work towards one binary that can boot both RPi3 and RPi4. On the other hand we can rely on the FW to detect the amount of memory our RPi4 has. That said, I agree that we should make sure that U-Boot can boot with both DTBs, the upstream one and the downstream. Now the question is how to get to this. I'm a bit puzzled that by talking about "unreviewed DT" you insinuate that bcm2711 compatible is already reviewed and can't be changed. From what I can see none of these compatibles got merged for now, so we are still at time to change them. Apart from the point Florian made, to stay consistent with the RPi SoC naming, it will save us work, both in the kernel and in U-Boot, as we would need to add both compatibles to the code-base. Regards, Matthias >> >>>> Regards, >>>> Matthias >>>> >>>>> Regards, >>>>> Matthias >>>>> >>>>>> Are there any config.txt tweaks necessary? >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> linux-arm-kernel mailing list >>>>> linux-arm-kernel@lists.infradead.org >>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>>>> >>>> _______________________________________________ >>>> linux-arm-kernel mailing list >>>> linux-arm-kernel@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>> >
Am 13.09.19 um 11:25 schrieb Matthias Brugger: > > On 13/09/2019 10:50, Stefan Wahren wrote: >> Am 13.09.19 um 10:09 schrieb Matthias Brugger: >>> On 12/09/2019 21:32, Stefan Wahren wrote: >>>> Am 12.09.19 um 19:18 schrieb Matthias Brugger: >>>>> 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. >>>> Do you mean the DTB provided at runtime? >>>> >>>> You mean the merged U-Boot changes, doesn't work with my Raspberry Pi >>>> series? >>>> >>>>> 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). >>>>> >>>>> Anyway, I found at least, that the following compatibles need to be added: >>>>> >>>>> "brcm,bcm2838-cprman" >>>>> "brcm,bcm2838-gpio" >>>>> >>>>> Without at least the cprman driver update, you won't see anything. >>>>> >>>>> "brcm,bcm2838-rng200" is also a candidate. >>>>> >>>>> I also suppose we will need to add "brcm,bcm2838" to >>>>> arch/arm/mach-bcm/bcm2711.c, but I haven't verified this. >>>> How about changing this in the downstream kernel? Which is much easier. >>> I'm not sure I understand what you want to say. My goal is to use the upstream >>> kernel with the device tree blob provided by the FW. >> The device tree blob you are talking is defined in this repository: >> >> https://github.com/raspberrypi/linux >> >> So the word FW is misleading to me. >> > No, it's part of > https://github.com/raspberrypi/firmware.git > file boot/bcm2711-rpi-4-b.dtb The compiled DT blobs incl. the kernel image are stored in this artifact repository. But the sources for the kernel and the DT are in the Linux repo. This is necessary to be compliant to the GPL. > >>> If you talk about the >>> downstream kernel, I suppose you mean we should change this in the FW DT blob >>> and in the downstream kernel. That would work for me. >>> >>> Did I understand you correctly? >> Yes >> >> So i suggest to add the upstream compatibles into the repo mentioned above. >> >> Sorry, but in case you decided as a U-Boot developer to be compatible >> with a unreviewed DT, we also need to make U-Boot compatible with >> upstream and downstream DT blobs. >> > Well RPi3 is working with the DT blob provided by the FW, as I mentioned earlier > if we can use this DTB we can work towards one binary that can boot both RPi3 > and RPi4. On the other hand we can rely on the FW to detect the amount of memory > our RPi4 has. > > That said, I agree that we should make sure that U-Boot can boot with both DTBs, > the upstream one and the downstream. Now the question is how to get to this. I'm > a bit puzzled that by talking about "unreviewed DT" you insinuate that bcm2711 > compatible is already reviewed and can't be changed. From what I can see none of > these compatibles got merged for now, so we are still at time to change them. Stephen Boyd was okay with clk changes except of a small nit. So i fixed this is as he suggested in a separate series. Unfortunately this hasn't be applied yet [1]. The i2c, pinctrl and the sdhci changes has been applied yet. In my opinion it isn't the job of the mainline kernel to adapt to a vendor device tree. It's the vendor device tree which needs to be fixed. Sorry, but this is my holiday. I will back after the weekend. Best regards Stefan [1] - https://www.spinics.net/lists/linux-clk/msg40534.html > > Apart from the point Florian made, to stay consistent with the RPi SoC naming, > it will save us work, both in the kernel and in U-Boot, as we would need to add > both compatibles to the code-base. > > Regards, > Matthias > >>>>> Regards, >>>>> Matthias >>>>> >>>>>> Regards, >>>>>> Matthias >>>>>> >>>>>>> Are there any config.txt tweaks necessary? >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> linux-arm-kernel mailing list >>>>>> linux-arm-kernel@lists.infradead.org >>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>>>>> >>>>> _______________________________________________ >>>>> linux-arm-kernel mailing list >>>>> linux-arm-kernel@lists.infradead.org >>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 13/09/2019 12:08, Stefan Wahren wrote: > Am 13.09.19 um 11:25 schrieb Matthias Brugger: >> >> On 13/09/2019 10:50, Stefan Wahren wrote: >>> Am 13.09.19 um 10:09 schrieb Matthias Brugger: >>>> On 12/09/2019 21:32, Stefan Wahren wrote: >>>>> Am 12.09.19 um 19:18 schrieb Matthias Brugger: >>>>>> 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. >>>>> Do you mean the DTB provided at runtime? >>>>> >>>>> You mean the merged U-Boot changes, doesn't work with my Raspberry Pi >>>>> series? >>>>> >>>>>> 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). >>>>>> >>>>>> Anyway, I found at least, that the following compatibles need to be added: >>>>>> >>>>>> "brcm,bcm2838-cprman" >>>>>> "brcm,bcm2838-gpio" >>>>>> >>>>>> Without at least the cprman driver update, you won't see anything. >>>>>> >>>>>> "brcm,bcm2838-rng200" is also a candidate. >>>>>> >>>>>> I also suppose we will need to add "brcm,bcm2838" to >>>>>> arch/arm/mach-bcm/bcm2711.c, but I haven't verified this. >>>>> How about changing this in the downstream kernel? Which is much easier. >>>> I'm not sure I understand what you want to say. My goal is to use the upstream >>>> kernel with the device tree blob provided by the FW. >>> The device tree blob you are talking is defined in this repository: >>> >>> https://github.com/raspberrypi/linux >>> >>> So the word FW is misleading to me. >>> >> No, it's part of >> https://github.com/raspberrypi/firmware.git >> file boot/bcm2711-rpi-4-b.dtb > The compiled DT blobs incl. the kernel image are stored in this artifact > repository. But the sources for the kernel and the DT are in the Linux > repo. This is necessary to be compliant to the GPL. Got it, thanks for clarifying. >> >>>> If you talk about the >>>> downstream kernel, I suppose you mean we should change this in the FW DT blob >>>> and in the downstream kernel. That would work for me. >>>> >>>> Did I understand you correctly? >>> Yes >>> >>> So i suggest to add the upstream compatibles into the repo mentioned above. >>> >>> Sorry, but in case you decided as a U-Boot developer to be compatible >>> with a unreviewed DT, we also need to make U-Boot compatible with >>> upstream and downstream DT blobs. >>> >> Well RPi3 is working with the DT blob provided by the FW, as I mentioned earlier >> if we can use this DTB we can work towards one binary that can boot both RPi3 >> and RPi4. On the other hand we can rely on the FW to detect the amount of memory >> our RPi4 has. >> >> That said, I agree that we should make sure that U-Boot can boot with both DTBs, >> the upstream one and the downstream. Now the question is how to get to this. I'm >> a bit puzzled that by talking about "unreviewed DT" you insinuate that bcm2711 >> compatible is already reviewed and can't be changed. From what I can see none of >> these compatibles got merged for now, so we are still at time to change them. > > Stephen Boyd was okay with clk changes except of a small nit. So i fixed > this is as he suggested in a separate series. Unfortunately this hasn't > be applied yet [1]. > > The i2c, pinctrl and the sdhci changes has been applied yet. > > In my opinion it isn't the job of the mainline kernel to adapt to a > vendor device tree. It's the vendor device tree which needs to be fixed. > I agree with that. But if we can make this easier by choosing a compatible which fits downstream without violating upstream and it makes sense with the naming scheme of the RPi, I think that's a good argument. > Sorry, but this is my holiday. I will back after the weekend. > Sure, enjoy. I'll be on travel for the next two weeks but will try to keep up with emails. Regards, Matthias > Best regards > Stefan > > [1] - https://www.spinics.net/lists/linux-clk/msg40534.html > >> >> Apart from the point Florian made, to stay consistent with the RPi SoC naming, >> it will save us work, both in the kernel and in U-Boot, as we would need to add >> both compatibles to the code-base. >> >> Regards, >> Matthias >> >>>>>> Regards, >>>>>> Matthias >>>>>> >>>>>>> Regards, >>>>>>> Matthias >>>>>>> >>>>>>>> Are there any config.txt tweaks necessary? >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> linux-arm-kernel mailing list >>>>>>> linux-arm-kernel@lists.infradead.org >>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>>>>>> >>>>>> _______________________________________________ >>>>>> linux-arm-kernel mailing list >>>>>> linux-arm-kernel@lists.infradead.org >>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Matthias, [drop uninvolved receiver] Am 13.09.19 um 12:39 schrieb Matthias Brugger: > >>>>> If you talk about the >>>>> downstream kernel, I suppose you mean we should change this in the FW DT blob >>>>> and in the downstream kernel. That would work for me. >>>>> >>>>> Did I understand you correctly? >>>> Yes >>>> >>>> So i suggest to add the upstream compatibles into the repo mentioned above. >>>> >>>> Sorry, but in case you decided as a U-Boot developer to be compatible >>>> with a unreviewed DT, we also need to make U-Boot compatible with >>>> upstream and downstream DT blobs. >>>> >>> Well RPi3 is working with the DT blob provided by the FW, as I mentioned earlier >>> if we can use this DTB we can work towards one binary that can boot both RPi3 >>> and RPi4. On the other hand we can rely on the FW to detect the amount of memory >>> our RPi4 has. >>> >>> That said, I agree that we should make sure that U-Boot can boot with both DTBs, >>> the upstream one and the downstream. Now the question is how to get to this. I'm >>> a bit puzzled that by talking about "unreviewed DT" you insinuate that bcm2711 >>> compatible is already reviewed and can't be changed. From what I can see none of >>> these compatibles got merged for now, so we are still at time to change them. >> Stephen Boyd was okay with clk changes except of a small nit. So i fixed >> this is as he suggested in a separate series. Unfortunately this hasn't >> be applied yet [1]. >> >> The i2c, pinctrl and the sdhci changes has been applied yet. >> >> In my opinion it isn't the job of the mainline kernel to adapt to a >> vendor device tree. It's the vendor device tree which needs to be fixed. >> > I agree with that. But if we can make this easier by choosing a compatible which > fits downstream without violating upstream and it makes sense with the naming > scheme of the RPi, I think that's a good argument. i spend a lot of my spare time to prepare these patch series in order to get a clean solution. Either mixing bcm2711/bcm2838 or changing everything to bcm2838 in the upstream tree has the following drawbacks: - additional review time and delay of the Raspberry Pi 4 support - harder to understand for developer/reviewer without RPi knowledge Btw currently u-boot only uses bcm2711, so it would be nice to keep that. So my suggestion is to add bcm2711 compatibles in the downstream tree. Best regards Stefan > >> Sorry, but this is my holiday. I will back after the weekend. >> > Sure, enjoy. I'll be on travel for the next two weeks but will try to keep up > with emails. > > Regards, > Matthias > >> Best regards >> Stefan >> >> [1] - https://www.spinics.net/lists/linux-clk/msg40534.html >> >>> Apart from the point Florian made, to stay consistent with the RPi SoC naming, >>> it will save us work, both in the kernel and in U-Boot, as we would need to add >>> both compatibles to the code-base. >>> >>> Regards, >>> Matthias >>> >>>>>>> Regards, >>>>>>> Matthias >>>>>>> >>>>>>>> Regards, >>>>>>>> Matthias >>>>>>>> >>>>>>>>> Are there any config.txt tweaks necessary? >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> linux-arm-kernel mailing list >>>>>>>> linux-arm-kernel@lists.infradead.org >>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> linux-arm-kernel mailing list >>>>>>> linux-arm-kernel@lists.infradead.org >>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 16/09/2019 21:19, Stefan Wahren wrote: > Hi Matthias, > > [drop uninvolved receiver] > > Am 13.09.19 um 12:39 schrieb Matthias Brugger: >> >>>>>> If you talk about the >>>>>> downstream kernel, I suppose you mean we should change this in the FW DT blob >>>>>> and in the downstream kernel. That would work for me. >>>>>> >>>>>> Did I understand you correctly? >>>>> Yes >>>>> >>>>> So i suggest to add the upstream compatibles into the repo mentioned above. >>>>> >>>>> Sorry, but in case you decided as a U-Boot developer to be compatible >>>>> with a unreviewed DT, we also need to make U-Boot compatible with >>>>> upstream and downstream DT blobs. >>>>> >>>> Well RPi3 is working with the DT blob provided by the FW, as I mentioned earlier >>>> if we can use this DTB we can work towards one binary that can boot both RPi3 >>>> and RPi4. On the other hand we can rely on the FW to detect the amount of memory >>>> our RPi4 has. >>>> >>>> That said, I agree that we should make sure that U-Boot can boot with both DTBs, >>>> the upstream one and the downstream. Now the question is how to get to this. I'm >>>> a bit puzzled that by talking about "unreviewed DT" you insinuate that bcm2711 >>>> compatible is already reviewed and can't be changed. From what I can see none of >>>> these compatibles got merged for now, so we are still at time to change them. >>> Stephen Boyd was okay with clk changes except of a small nit. So i fixed >>> this is as he suggested in a separate series. Unfortunately this hasn't >>> be applied yet [1]. >>> >>> The i2c, pinctrl and the sdhci changes has been applied yet. >>> >>> In my opinion it isn't the job of the mainline kernel to adapt to a >>> vendor device tree. It's the vendor device tree which needs to be fixed. >>> >> I agree with that. But if we can make this easier by choosing a compatible which >> fits downstream without violating upstream and it makes sense with the naming >> scheme of the RPi, I think that's a good argument. > > i spend a lot of my spare time to prepare these patch series in order to > get a clean solution. > > Either mixing bcm2711/bcm2838 or changing everything to bcm2838 in the > upstream tree has the following drawbacks: > > - additional review time and delay of the Raspberry Pi 4 support > - harder to understand for developer/reviewer without RPi knowledge On the other hand it get's confusing that the SoC for RPi4 is called bcm2711 while all the others are named bcm283x. Anyway if the majority prefers bcm2711 so shall it be and let's get forward instead :) > > Btw currently u-boot only uses bcm2711, so it would be nice to keep that. > Yes that's true. We already identified the compatible we'll need to add to U-Boot to also boot with the upstream DTS. I'll send a patch to the U-Boot mailinglist. > So my suggestion is to add bcm2711 compatibles in the downstream tree. > Ok, can you take care of it, or shall I send a pull request/open a bug? Regards, Matthias > Best regards > Stefan > >> >>> Sorry, but this is my holiday. I will back after the weekend. >>> >> Sure, enjoy. I'll be on travel for the next two weeks but will try to keep up >> with emails. >> >> Regards, >> Matthias >> >>> Best regards >>> Stefan >>> >>> [1] - https://www.spinics.net/lists/linux-clk/msg40534.html >>> >>>> Apart from the point Florian made, to stay consistent with the RPi SoC naming, >>>> it will save us work, both in the kernel and in U-Boot, as we would need to add >>>> both compatibles to the code-base. >>>> >>>> Regards, >>>> Matthias >>>> >>>>>>>> Regards, >>>>>>>> Matthias >>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Matthias >>>>>>>>> >>>>>>>>>> Are there any config.txt tweaks necessary? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> linux-arm-kernel mailing list >>>>>>>>> linux-arm-kernel@lists.infradead.org >>>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> linux-arm-kernel mailing list >>>>>>>> linux-arm-kernel@lists.infradead.org >>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi Matthias, Am 17.09.19 um 11:04 schrieb Matthias Brugger: > > On 16/09/2019 21:19, Stefan Wahren wrote: >> Hi Matthias, >> >> [drop uninvolved receiver] >> >> Am 13.09.19 um 12:39 schrieb Matthias Brugger: >>>>>>> If you talk about the >>>>>>> downstream kernel, I suppose you mean we should change this in the FW DT blob >>>>>>> and in the downstream kernel. That would work for me. >>>>>>> >>>>>>> Did I understand you correctly? >>>>>> Yes >>>>>> >>>>>> So i suggest to add the upstream compatibles into the repo mentioned above. >>>>>> >>>>>> Sorry, but in case you decided as a U-Boot developer to be compatible >>>>>> with a unreviewed DT, we also need to make U-Boot compatible with >>>>>> upstream and downstream DT blobs. >>>>>> >>>>> Well RPi3 is working with the DT blob provided by the FW, as I mentioned earlier >>>>> if we can use this DTB we can work towards one binary that can boot both RPi3 >>>>> and RPi4. On the other hand we can rely on the FW to detect the amount of memory >>>>> our RPi4 has. >>>>> >>>>> That said, I agree that we should make sure that U-Boot can boot with both DTBs, >>>>> the upstream one and the downstream. Now the question is how to get to this. I'm >>>>> a bit puzzled that by talking about "unreviewed DT" you insinuate that bcm2711 >>>>> compatible is already reviewed and can't be changed. From what I can see none of >>>>> these compatibles got merged for now, so we are still at time to change them. >>>> Stephen Boyd was okay with clk changes except of a small nit. So i fixed >>>> this is as he suggested in a separate series. Unfortunately this hasn't >>>> be applied yet [1]. >>>> >>>> The i2c, pinctrl and the sdhci changes has been applied yet. >>>> >>>> In my opinion it isn't the job of the mainline kernel to adapt to a >>>> vendor device tree. It's the vendor device tree which needs to be fixed. >>>> >>> I agree with that. But if we can make this easier by choosing a compatible which >>> fits downstream without violating upstream and it makes sense with the naming >>> scheme of the RPi, I think that's a good argument. >> i spend a lot of my spare time to prepare these patch series in order to >> get a clean solution. >> >> Either mixing bcm2711/bcm2838 or changing everything to bcm2838 in the >> upstream tree has the following drawbacks: >> >> - additional review time and delay of the Raspberry Pi 4 support >> - harder to understand for developer/reviewer without RPi knowledge > On the other hand it get's confusing that the SoC for RPi4 is called bcm2711 > while all the others are named bcm283x. one could argue this is a complete new SoC. But i got your point. > Anyway if the majority prefers bcm2711 > so shall it be and let's get forward instead :) > >> Btw currently u-boot only uses bcm2711, so it would be nice to keep that. >> > Yes that's true. We already identified the compatible we'll need to add to > U-Boot to also boot with the upstream DTS. I'll send a patch to the U-Boot > mailinglist. Since the upstream DTS isn't completely stable yet, maybe you better wait until it has been accepted. > >> So my suggestion is to add bcm2711 compatibles in the downstream tree. >> > Ok, can you take care of it, or shall I send a pull request/open a bug? I'll send a send a pull request and hope the RPi guys are happy with it. Btw the clk changes has been applied. Stefan
Hi Matthias, Am 17.09.19 um 20:03 schrieb Stefan Wahren: > Hi Matthias, > > Am 17.09.19 um 11:04 schrieb Matthias Brugger: >> On 16/09/2019 21:19, Stefan Wahren wrote: >>> Hi Matthias, >>> >>> [drop uninvolved receiver] >>> >>> Am 13.09.19 um 12:39 schrieb Matthias Brugger: >>> >>> So my suggestion is to add bcm2711 compatibles in the downstream tree. >>> >> Ok, can you take care of it, or shall I send a pull request/open a bug? > I'll send a send a pull request and hope the RPi guys are happy with it. the pull request is prepared [1], but didn't had the time to test against U-Boot. Stefan [1] - https://github.com/raspberrypi/linux/pull/3244 > > Btw the clk changes has been applied. > > Stefan > >
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. - On a Synquacer box[1] with 32G of memory. - On an ACPI based Huawei TaiShan server[2] with 256G of memory. - On a QEMU virtual machine running arm64's OpenSUSE Tumbleweed. That's all. Regards, Nicolas [1] https://www.96boards.org/product/developerbox/ [2] https://e.huawei.com/en/products/cloud-computing-dc/servers/taishan-server/taishan-2280-v2 --- Changes in v5: - Fix issue with swiotlb initialization Changes in v4: - Rebased to linux-next - Fix issue when NUMA=n and ZONE_DMA=n - Merge two max_zone_dma*_phys() functions Changes in v3: - Fixed ZONE_DMA's size to 1G - Update mmzone.h's comment to match changes in arm64 - Remove all dma-direct patches Changes in v2: - Update comment to reflect new zones split - ZONE_DMA will never be left empty - Try another approach merging both ZONE_DMA comments into one - Address Christoph's comments - If this approach doesn't get much traction I'll just drop the patch from the series as it's not really essential Nicolas Saenz Julienne (4): arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() arm64: rename variables used to calculate ZONE_DMA32's size arm64: use both ZONE_DMA and ZONE_DMA32 mm: refresh ZONE_DMA and ZONE_DMA32 comments in 'enum zone_type' arch/arm64/Kconfig | 4 ++ arch/arm64/include/asm/page.h | 2 + arch/arm64/mm/init.c | 71 +++++++++++++++++++++++++---------- include/linux/mmzone.h | 45 ++++++++++++---------- 4 files changed, 83 insertions(+), 39 deletions(-)