BCM2711 - Upstream Linux 5.5 backport #3385

lategoodbye · 2019-12-27T15:49:41Z

This pull requests tries to reduce the delta between downstream and current upstream development. Since Linux 5.4 LTS has been released i don't see any point to backport 5.5 changes into 4.19.

In short the PR contain the following 5.5 changes:

BCM2711 board support
timer cleanup
U-Boot fix
Backport of Bluetooth, GENET, RNG

Unfortunately there is no complete backward compatibility of GENET, since the PHY mode was wrong before.

This PR doesn't contain all 5.5 DTS changes:

generic pinctrl (fundamental change which might break some overlays)
HDMI (might break graphics)
CMA fix (breaks Kodi, needs to be investigated further)

I tried to keep the changes as minimal as possible.

This PR has been tested with bcm2711_defconfig.

popcornmix · 2020-01-02T20:09:52Z

ARM: dts: bcm2711: force CMA into first GB of memory stops kodi (installed from raspberry pi repo) from working.
It fails with:

DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
Failed to create scanout resource
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
Failed to create scanout resource
terminate called after throwing an instance of 'std::runtime_error'
  what():  eglSwapBuffers failed

lategoodbye · 2020-01-02T20:20:56Z

@popcornmix Thanks for testing. I can drop this patch, but this needs to be investigated further.

@vianpl Any ideas?

lategoodbye · 2020-01-03T11:18:23Z

I dropped the CMA fix and updated the initial comment.

vianpl · 2020-01-03T11:32:16Z

Here's my guess. By configuring CMA in the device tree the kernel stops reacting to the command line options. I bet the Kodi install is updating the CMA size trough the kernel command line, which is not being taken into account. The only way to do it after this patch is by using overlays.

popcornmix · 2020-01-03T12:01:44Z

With cma not in cmdline.txt and without the cma patch:

[    0.000000] cma: Reserved 256 MiB at 0x000000001bc00000

With cma=512M in cmdline.txt and without the cma patch:

[    0.000000] cma: Reserved 512 MiB at 0x000000000bc00000

with cma not in cmdline.txt and the cma patch:

[    0.000000] Reserved memory: created CMA memory pool at 0x0000000029c00000, size 32 MiB

With cma=512M in cmdline.txt and the cma patch:

[    0.000000] Reserved memory: created CMA memory pool at 0x0000000029c00000, size 32 MiB

All these have the vc4-fkms-v3d overlay which attempts to increase CMA to 256M (@pelwell can confirm but I think the overlay ends up modifying the cmdline kernel sees).
But we only ever get 32M of CMA with the patch.

So should cma=<> on cmdline still work? Is there a way to make it do so?

vianpl · 2020-01-03T12:17:49Z

With cma not in cmdline.txt and without the cma patch:
[    0.000000] cma: Reserved 256 MiB at 0x000000001bc00000
With cma=512M in cmdline.txt and without the cma patch:
[    0.000000] cma: Reserved 512 MiB at 0x000000000bc00000
with cma not in cmdline.txt and the cma patch:
[    0.000000] Reserved memory: created CMA memory pool at 0x0000000029c00000, size 32 MiB
With cma=512M in cmdline.txt and the cma patch:
[    0.000000] Reserved memory: created CMA memory pool at 0x0000000029c00000, size 32 MiB

This is the behavior I observed upstream. I double checked the code, command line is explicitly ignored.

All these have the vc4-fkms-v3d overlay which attempts to increase CMA to 256M (@pelwell can confirm but I think the overlay ends up modifying the cmdline kernel sees).
But we only ever get 32M of CMA with the patch.

I think the overlay could be easily updated to work with the new CMA setup. We'd just need to update the size property in the CMA node instead of altering the command line.

So should cma=<> on cmdline still work? Is there a way to make it do so?

Well I guess this is something we should discuss with people upstream. I'd say the command line should take precedence to the DTB. At least for it's size. But I guess we'd have to investigate further. There are not so many users of DTB defined CMAs, so we might be the first with such needs.

pelwell · 2020-01-03T13:55:53Z

I'd be happy with a DTB-only solution - patching the command line from an overlay always seemed a bit ugly.

vianpl · 2020-01-03T13:57:24Z

@pelwell I'm still on holidays until the 7th, but if you can wait until then I'll be happy to have a got at it.

popcornmix · 2020-01-03T14:07:35Z

I'd be happy with a DTB-only solution - patching the command line from an overlay always seemed a bit ugly.

As long as there's an easy way for users to adjust it. The HEVC V4L2 driver for example wants a lot of CMA to play 10bit 4K video (256M is not enough), and we have examples of high CMA settings causing kernel allocation failures, so we can't just unconditionally set it high.

A config.txt setting that causes firmware to adjust cma value in DTB should be okay if cmdline.txt solution isn't possible.

pelwell · 2020-01-03T15:37:19Z

I'd make it a dtparam.

vianpl · 2020-01-09T20:22:30Z

I've been working on the following small series to address the CMA issue. See the first two patches here: https://github.com/vianpl/linux/commits/bcm283x-cma-unification.

With the DT patch it'll be trivial to update all overlays that change CMA sizes. And if the cmdline/DT precendence patch doesn't make it we can always create an extra overlay to edit CMA sizes trough a dtparam.

Will this overall approach be acceptable to you?

pelwell · 2020-01-10T10:41:45Z

I've commented on one of the patches, but to summarise: I'm happy with it, but I'd like a label on the linux,cma node for overlays (or aliases) to target.

lategoodbye · 2020-01-11T21:25:46Z

Since i dropped the CMA patch, this could be a separate pull request. This pull request is rebased now.

popcornmix · 2020-01-13T12:51:51Z

The patches (excluding CMA one) seemed fine in my limited testing, so no objections.

This reverts commit adac895, because this issue is already addressed by commit 19ec6bb. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

commit 4b2d246 upstream. The fixed clocks doesn't form some kind of bus. So let's remove it. This fixes the follow DT schema warnings: clocks: clock@3:reg:0: [3] is too short clocks: clock@4:reg:0: [4] is too short clocks: $nodename:0: 'clocks' does not match '^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$' clocks: #size-cells:0:0: 0 is not one of [1, 2] clocks: 'ranges' is a required property clock@3: 'reg' does not match any of the regexes: 'pinctrl-[0-9]+' clock@4: 'reg' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

During Raspberry Pi 4 upstream discussion Tim Gover confirmed that the system timer also exists on BCM2711. So move it back to bcm283x.dtsi and overwrite the interrupt definition in bcm2838.dtsi. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

According to Eric Anholt the pixelvalves doesn't exists on BCM2711. So move it to bcm2835-common.dtsi. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

We need to declare the proper device type, otherwise U-Boot won't boot with this devicetree. While we are this let the bootloader set the actual memory size. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

The CYW43455 on the Raspberry Pi 4 doesn't use an external pin as lower power clock anymore. So drop the GPIO clock from pinctrl. While we are at this add the missing declaration of hardware flow control. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

According to devicetree specification the node name should describe the general class of device like ethernet or interrupt-controller. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

The intc label isn't defined in bcm283x.dtsi, so we cannot use it there. So move it to bcm2835-common.dtsi. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

After moving bcm2835-system-timer to bcm283x.dtsi there is no need for the always-on for armv7-timer anymore. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

…iendly" This reverts commit 0f66932.

This reverts commit a377688.

This adds the missing support for the PHY mode RGMII_RXID. It's necessary for the Raspberry Pi 4. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

This backport all genet differences (different compatible, right PHY mode, board specific stuff) from upstream. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

Make the BCM2711 a different machine, but keep it in board_bcm2835. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

commit 0f95b09 upstream. BCM2711 features a RNG200 hardware random number generator block. So make the driver available. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Stephen Brennan <stephen@brennan.io> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

This adds the ability to use the RNG with an upstream kernel. Keep the old one for backward compatibility. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

lategoodbye · 2020-01-15T18:50:04Z

Pull request rebased

lategoodbye · 2020-01-17T10:07:57Z

@pelwell Are there any objections with this pull request?

pelwell · 2020-01-17T10:11:00Z

I'm just giving it a quick smoke test prior to merging.

pelwell · 2020-01-17T11:17:23Z

Note to self: If you ever experiment with different armstubs, be sure to delete them before regression testing.

lategoodbye · 2020-01-17T11:55:35Z

Thanks

lategoodbye force-pushed the rpi-5.4-rpi4-backport branch from f2cb698 to f50d2c1 Compare January 3, 2020 10:41

popcornmix force-pushed the rpi-5.4.y branch 2 times, most recently from 75bb710 to 53c77f0 Compare January 6, 2020 12:41

lategoodbye force-pushed the rpi-5.4-rpi4-backport branch from f50d2c1 to c2ccf70 Compare January 11, 2020 21:22

lategoodbye changed the title ~~RFC: BCM2711 - Upstream Linux 5.5 backport~~ BCM2711 - Upstream Linux 5.5 backport Jan 11, 2020

popcornmix force-pushed the rpi-5.4.y branch from 30757c9 to 0005d9b Compare January 14, 2020 14:35

lategoodbye mentioned this pull request Jan 15, 2020

Enable hwmon for thermal zones #3307

Merged

lategoodbye added 9 commits January 15, 2020 19:47

Revert "mmc: sdhci: Mask "spurious" interrupts"

d3ad1c7

This reverts commit adac895, because this issue is already addressed by commit 19ec6bb. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

ARM: dts: bcm283x: Move pixelvalve to bcm2835-common.dtsi

bd45d95

According to Eric Anholt the pixelvalves doesn't exists on BCM2711. So move it to bcm2835-common.dtsi. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

ARM: dts: bcm2838-rpi-4-b: Fix memory node

3eb0a2f

We need to declare the proper device type, otherwise U-Boot won't boot with this devicetree. While we are this let the bootloader set the actual memory size. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

ARM: dts: bcm2838: Backport node names from upstream

6c38ec0

According to devicetree specification the node name should describe the general class of device like ethernet or interrupt-controller. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

ARM: dts: bcm283x: Move intc label to bcm2835-common.dtsi

24a0162

The intc label isn't defined in bcm283x.dtsi, so we cannot use it there. So move it to bcm2835-common.dtsi. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

ARM: dts: bcm2838: Remove always-on from armv7-timer

de26374

After moving bcm2835-system-timer to bcm283x.dtsi there is no need for the always-on for armv7-timer anymore. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

lategoodbye added 7 commits January 15, 2020 19:47

Revert "phy: bcm54213pe: configure the LED outputs to be more user-fr…

fe1a2ff

…iendly" This reverts commit 0f66932.

Revert "phy: broadcom: split out the BCM54213PE from the BCM54210E IDs"

f8a3207

This reverts commit a377688.

net: bcmgenet: Add RGMII_RXID support

6b5698a

This adds the missing support for the PHY mode RGMII_RXID. It's necessary for the Raspberry Pi 4. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

ARM: dts: bcm2838: Backport genet from upstream

568882d

This backport all genet differences (different compatible, right PHY mode, board specific stuff) from upstream. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

ARM: bcm: Backport BCM2711 support from upstream

e856c9c

Make the BCM2711 a different machine, but keep it in board_bcm2835. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

ARM: dts: bcm2838: Add upstream RNG compatible

1bb3430

This adds the ability to use the RNG with an upstream kernel. Keep the old one for backward compatibility. Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

lategoodbye force-pushed the rpi-5.4-rpi4-backport branch from c2ccf70 to 1bb3430 Compare January 15, 2020 18:48

pelwell merged commit 436302f into raspberrypi:rpi-5.4.y Jan 17, 2020

lategoodbye deleted the rpi-5.4-rpi4-backport branch February 11, 2020 19:43

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

BCM2711 - Upstream Linux 5.5 backport #3385

BCM2711 - Upstream Linux 5.5 backport #3385

lategoodbye commented Dec 27, 2019 •

edited

Loading

popcornmix commented Jan 2, 2020

lategoodbye commented Jan 2, 2020

lategoodbye commented Jan 3, 2020

vianpl commented Jan 3, 2020

popcornmix commented Jan 3, 2020

vianpl commented Jan 3, 2020

pelwell commented Jan 3, 2020

vianpl commented Jan 3, 2020

popcornmix commented Jan 3, 2020

pelwell commented Jan 3, 2020

vianpl commented Jan 9, 2020

pelwell commented Jan 10, 2020

lategoodbye commented Jan 11, 2020

popcornmix commented Jan 13, 2020

lategoodbye commented Jan 15, 2020

lategoodbye commented Jan 17, 2020

pelwell commented Jan 17, 2020

pelwell commented Jan 17, 2020

lategoodbye commented Jan 17, 2020

BCM2711 - Upstream Linux 5.5 backport #3385

BCM2711 - Upstream Linux 5.5 backport #3385

Conversation

lategoodbye commented Dec 27, 2019 • edited Loading

popcornmix commented Jan 2, 2020

lategoodbye commented Jan 2, 2020

lategoodbye commented Jan 3, 2020

vianpl commented Jan 3, 2020

popcornmix commented Jan 3, 2020

vianpl commented Jan 3, 2020

pelwell commented Jan 3, 2020

vianpl commented Jan 3, 2020

popcornmix commented Jan 3, 2020

pelwell commented Jan 3, 2020

vianpl commented Jan 9, 2020

pelwell commented Jan 10, 2020

lategoodbye commented Jan 11, 2020

popcornmix commented Jan 13, 2020

lategoodbye commented Jan 15, 2020

lategoodbye commented Jan 17, 2020

pelwell commented Jan 17, 2020

pelwell commented Jan 17, 2020

lategoodbye commented Jan 17, 2020

lategoodbye commented Dec 27, 2019 •

edited

Loading