[RFC] ARM: dts: bcm2711: Fix DMA constrains for newer BCM2711 boards

The commit 3d2cbb644836 ("ARM: dts: bcm2711: Move emmc2 into its own bus")
assumed that all bootloader pass the FDT modified by the firmware to the
kernel. But this is not always the case (e.g. Fedora) and cause boot
issues for boards with a BCM2711 C0 SoC (RPi 400, CM4, newer RPi 4 B)
which does have different DMA constraints.

Since we are not able to detect the SoC revision, let's assume a BCM2711
C0 SoC for bcm2711.dtsi and move the restricted DMA constrains to a
separate RPi 4 B board file just for the old SoC revision.

Fixes: 3d2cbb644836 ("ARM: dts: bcm2711: Move emmc2 into its own bus")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm/boot/dts/Makefile               |  1 +
 arch/arm/boot/dts/bcm2711-rpi-4-b-b0.dts | 22 ++++++++++++++++++++++
 arch/arm/boot/dts/bcm2711.dtsi           | 11 +++--------
 3 files changed, 26 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b-b0.dts

On 5/4/2022 2:43 PM, Stefan Wahren wrote:
> Hi,
> 
> Am 13.04.22 um 18:27 schrieb Stefan Wahren:
>> The commit 3d2cbb644836 ("ARM: dts: bcm2711: Move emmc2 into its own 
>> bus")
>> assumed that all bootloader pass the FDT modified by the firmware to the
>> kernel. But this is not always the case (e.g. Fedora) and cause boot
>> issues for boards with a BCM2711 C0 SoC (RPi 400, CM4, newer RPi 4 B)
>> which does have different DMA constraints.
>>
>> Since we are not able to detect the SoC revision, let's assume a BCM2711
>> C0 SoC for bcm2711.dtsi and move the restricted DMA constrains to a
>> separate RPi 4 B board file just for the old SoC revision.
>>
>> Fixes: 3d2cbb644836 ("ARM: dts: bcm2711: Move emmc2 into its own bus")
>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> since there wasn't any feedback yet, i want to ping ...

Could not we just rely on the VPU patching the Device Tree instead of 
having to differentiate the 2711 revision and having to use different 
DTS/DTBs?

Also, can we consider that the older B0 are less predominant in the wild 
than the C0 nowadays, especially with the shortages going on is that 
even remotely the case?

Am 18.05.22 um 22:18 schrieb Florian Fainelli:
>
>
> On 5/4/2022 2:43 PM, Stefan Wahren wrote:
>> Hi,
>>
>> Am 13.04.22 um 18:27 schrieb Stefan Wahren:
>>> The commit 3d2cbb644836 ("ARM: dts: bcm2711: Move emmc2 into its own 
>>> bus")
>>> assumed that all bootloader pass the FDT modified by the firmware to 
>>> the
>>> kernel. But this is not always the case (e.g. Fedora) and cause boot
>>> issues for boards with a BCM2711 C0 SoC (RPi 400, CM4, newer RPi 4 B)
>>> which does have different DMA constraints.
>>>
>>> Since we are not able to detect the SoC revision, let's assume a 
>>> BCM2711
>>> C0 SoC for bcm2711.dtsi and move the restricted DMA constrains to a
>>> separate RPi 4 B board file just for the old SoC revision.
>>>
>>> Fixes: 3d2cbb644836 ("ARM: dts: bcm2711: Move emmc2 into its own bus")
>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>> since there wasn't any feedback yet, i want to ping ...
>
> Could not we just rely on the VPU patching the Device Tree instead of 
> having to differentiate the 2711 revision and having to use different 
> DTS/DTBs?
As long as every bootloader in the boot chain take care everything is 
fine. The problem is the VPU firmware is closed source, so only a few 
people knows about the hardware differences. So the idea was to make it 
more transparent and yes i'm also not happy with this patch.
>
> Also, can we consider that the older B0 are less predominant in the 
> wild than the C0 nowadays, especially with the shortages going on is 
> that even remotely the case?
So your idea is to make C0 the default and let the firmware patch the B0 
part? I must confess that i never tested this.