Please switch default, hwe, oem kernel flavours governor to CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y , such that advanced userspace utilities such as game-mode can be later used to rev-up to to performance, or rev-down to powersave.

[Julian Andres Klode]

[Impact]

 * Kernel should have sensible default governor set to CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y for the generic, hwe, raspi, riscv, oem kernel flavours in Focal and Groovy+.

 * ondemand.service must not be shipped by systemd package

 * kvm flavour, cloud-kernels flavours should continue using performance governor.

 * Users should be given control to rev-up to performance, or rev-down to powersave using other tools, i.e. game-mode and/or similar CLI or GUI tools (these are scheduled to be integrated on Ubuntu platform later).

[Test Case]

 * Boot ubuntu generic, hwe, or oem kernel

 * Check that default governor is ondemand

 * Check that ondemand.service is not active

[Regression Potential]

 * ondemand governor is the best kernel default as recently analyzed by colin king, it gives a balance bootspeed and power, giving as responsive machines whilst not wasting power. It is the best experience we can give our users by default.

[Other Info]

 * It is up to the user to elect/switch to powersave for maximum battery life, or to the performance for maximum processing power (i.e. gaming / computation).

[Julian Andres Klode (juliank)]

Someone probably needs to look at non-pstate systems as I have no idea about them.

[Sebastien Bacher (seb128)]

Tagging rls-gg-incoming so it's reviewed, that has a performance impact on desktop and ideally should have been discussed before landing rather than afterfact

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1885730

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Balint Reczey (rbalint)]

The commit message removing ondemand.service has several bug references, too:
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=65f46a7d14b335e5743350dbbc5b5ef1e72826f7

remove Ubuntu-specific ondemand.service
New processors handle scaling/throttling in internal firmware
(e.g. intel_pstate), and do not require OS config.

Additionally, nobody else does this, not even Debian.

And finally, this has caused problems for years, e.g.:

https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1497375
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1503773
https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1480320
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579278
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1806012
https://bugs.launchpad.net/charm-sysconfig/+bug/1873028

IMO the kernel is a better place for setting the default governor properly and can even set different governors in cloud-specific kernels.
If the decision is to control the governor in user space in Ubuntu I'd prefer a solution shipped in an other package because systemd does too many things already.

[Dimitri John Ledkov (xnox)]

@balint

Kernel has no facility to startup in one mode, and later transition to another.

I think maybe we should measure the difference between "performance, then on demand" vs "balanced performance".

If the difference is not significant, maybe we can simply change the kernel default to "balanced performance"

[Julian Andres Klode (juliank)]

@rbalint As said before the kernel messages and bugs are irrelevant and wrong. They pretend like intel_pstate is different, when in fact it's this script that is configuring it here. And yes, it needs OS config.

Nor do other distros not do this, but we do it differently. We set the CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y option, and then transition to that at the end of the boot. Other distributions do not set CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE and hence the kernel has powersave as the default.

By removing this script, we are diverging from other distros, not becoming closer to them - for pstates, anyway.

[Balint Reczey (rbalint)]

@xnox @juliank IMO there is no real need for different boot time and post-boot governor.

I think where we would like to save power or be less noisy the (possibly) faster boot does not have huge impact on user satisfaction.

I agree that fans should not be on all the time in laptops/desktops.

If we agree that there is no need for separate boot time and post-boot governor then I think the proper place to set the right default is the kernel.

I'd love to hear the Kernel Team's opinion on the matter because there were quite of lot of discussions in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579278 .

[Balint Reczey (rbalint)]

I have a freshly installed 20.10 system running on a 2012 MacBook Air (MBA 5,2) and it is completely silent and cold when being idle:

rbalint@chaos:~$ sudo cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: Cannot determine or is not supported.
  hardware limits: 800 MHz - 2.80 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 2.80 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 915 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes
    2600 MHz max turbo 4 active cores
    2600 MHz max turbo 3 active cores
    2600 MHz max turbo 2 active cores
    2800 MHz max turbo 1 active cores

@seb128, @juliank I'm not sure if there is anything to fix in the user space, but please report which laptops you experienced issues with. Those may need firmware/kernel fixes.

[Julian Andres Klode (juliank)]

The performance governor is the right choice for servers, but it's not the right choice on non-server platforms, it's also not the default kernel setting, it was set because we have the ondemand.service in userspace that can change it back to ondemand (or well we have the service because of that change in the kernel :D).

Fans do not necessarily spin, and you might not actually notice any significant changes in power usage, but the expectation of a desktop user is that the CPU scales its frequencies down, which recent-ish Intel CPUs (Skylake+) on like a ThinkPad T480s - which manage the pstates in hardware instead of software like the old MacBook does - don't do.

If we compare this to Red Hat, what they do is CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y in RHEL and CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y in fedora.

Power usage, at 3-6% CPU usage:

Powersave: I see 0.9-1.4W power usage on the cores
Performance, I see 1.6-2.5W

[Julian Andres Klode (juliank)]

passing intel_pstate=disable_hwp on the kernel commandline causes the kernel to scale the Core i5-8250U down to 1.6 GHz in performance mode, but that's still a bit off from the 900 MHz it scales down to in powersave mode.

I believe Windows also does not run the CPUs in performance mode by default on mobile devices (but in balanced or balanced performance), I don't know about stationary ones.

Performance governor on laptops should be restricted to gamemode.

[Colin Ian King (colin-king)]

The choice was made from running analysis on a wide range of Intel machines, old and new. We are trying to select the optimal choice for a wide range of CPUs for a wide range of use cases. Generally speaking, the intel-pstate governor has deeper understanding of the processor features and can access CPU metrics that can guide it to making an informed choice.

From our understanding, The intel-pstate driver should be the optimal choice for Intel Sandy Bridge CPUs onwards. The intel-pstate driver supports only the performance and powersave governors. In benchmarking we didn't observe much computational difference between the too once the CPU is fully loaded. However, cranking up or cranking down the load one will discover that the performance setting is more responsive than powersave. The overall compute throughput when fully loaded is the same, it's just a case that powersave may take a little longer to crank up to the full speed.

It makes sense to default to powersave for most scenarios, especially for laptop users.

Pre-Intel Sandy Bridge or non-x86 CPUs will default back to the non-intel pstate governor.

So, question:

Which kernel(s) are you referring to?

[Julian Andres Klode (juliank)]

@Colin: I agree with all of that.

Our kernel-side default is not powersave, but performance, across generic and oem, at the very least:

$ grep CPU_FREQ_DEFAULT_GOV_.*=y /boot/config-5.*
/boot/config-5.4.0-26-generic:CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
/boot/config-5.4.0-42-generic:CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
/boot/config-5.6.0-1018-oem:CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
/boot/config-5.6.0-1020-oem:CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y

We used to set that to powersave (and ondemand on non-pstate) in ondemand.service, but have since removed the service in groovy.

I believe the default governor kernel-side outside Ubuntu is usually CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND, which translates to ondemand pre-pstates, and powersave on pstates (compare Fedora), whereas Enterprise systems usually pick PERFORMANCE too (compare RHEL)

- probably because most distributions focus on normal end users and enterprise on server and workstation. We don't have that distinction of course, so I'm not sure what the best way out is - default to powersave/ondemand and make server installer write performance - or vice versa default to performance and make ubiquity configure powersave for desktop.

[Dimitri John Ledkov (xnox)]

@colin-king @juliank

It feels to me that the oem flavour should default to (powersave/ondemand), as it is more-or-less laptop kernel flavour.

I feel like generic kernel flavour should remain on performance.

I feel like we should have a unit, that for chassis=laptop turns on (powersave/ondemand). Possibly shipped in like procps package. Or there should be like graphical desktop integration to control this (aka game mode).

Is there a per-chasis type setting in kernel? as in something like CONFIG_WHEN_ON_LAPTOP_DEFAULT_GOV_* ?

Do above actionable things make sense?

[Matthieu Baerts (matttbe)]

Hello!

Regarding the comment #8, I didn't get the same positive experience on my side. It was more closer to what is described in comment #9. See bug 1889479 for more details.

I would suggest switching back to powersave/ondemand either with a new service or the kernel config. Having a dedicated service could be confusing for people who try to change the kernel settings. But it could be more flexible.

Cheers,
Matt

[Dan Streetman (ddstreet)]

> I would suggest switching back to powersave/ondemand either with a new service or the kernel config.

re: new service, the existing package cpufrequtils (and related package cpufreqd) provides a configurable service to manage governor settings (and other related settings). The old ondemand service was not configurable at all and caused quite a bit of unexpected problems, as well as 'battling' (overriding) the cpufrequtils service when it was installed.

> Having a dedicated service could be confusing for people who try to change the kernel settings.

indeed, it was, especially when there were multiple services to (try to) control the settings that conflicted with each other.

[Dan Streetman (ddstreet)]

> In benchmarking we didn't observe much computational difference between the too once the CPU is fully loaded. However, cranking up or cranking down the load one will discover that the performance setting is more responsive than powersave.

this is exactly the problem in production environments; workloads can be 'bursty' which can see not-insignificant performance reduction when using powersave. Many enterprise users even go so far as to disable C-states (and ASPM, and APST, etc...).

> It makes sense to default to powersave for most scenarios, especially for laptop users.

for laptop users, yeah. I question if 'most scenarios' is accurate.

[Balint Reczey (rbalint)]

I've added the OEM Solutions Group team for awareness. I'm not sure what the final fix will be since servers' and desktops'/laptops' ideal default seem to be different, but most likely the certification tests should be adjusted if we don't end up restoring the previous behaviour of the ondemand.service unconditionally.

The latest LTS release, 20.04 is not affected so the certification test changes are probably not very urgent.

[Colin Ian King (colin-king)]

@xnox,

one can detect the machine type from the DMI data (iff it is available and reliable).

e.g. on my laptop:

sudo dmidecode -s "chassis-type"
Notebook

on my desktop server:
sudo dmidecode -s "chassis-type"

There are quite a few chassis-type, see https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.7.1.pdf - page 36, section 7.4.1, table 16 "System Enclosure or Chassic Type".
*Note* some machines may have illegal data or omitted this information and it's DMI specific, so s390, arm64, ppc64el platforms most probably won't have this.

So some context. This performance governor was chosen for the boot default setting because it speeds up boot. I've performed some simple boot tests on an older generation Lenovo x220 (i3-2350M), timings are below for a 5.8 kernel:

Governor Kernel Userspace EndBoot
PEFORFMANCE 2.15s 10.37s 12.52s
POWERSAVE 2.87s 18.49s 21.37s
ONDEMAND 2.41s 10.46s 12.87s

So PERFORMANCE saves a few tenths of a second over ONDEMAND, hence this choice for boot. The setting thereafter is obviously more complex. I've compared the governor settings on the same laptop running idle, with 50% CPU utilization and 100% CPU utilization. I used powerstat to monitor CPU power, CPU freq and C7 (deep sleep) residency.

1. Idle.
  - power utilization roughly the same in power usage, but powersave clocks the CPU lowest. Note that the CPU freq is cranked up when measurements are taken, so it's hard to get a correct freq. measurement.

2. 50% CPU busy.
   - performance consumes most power (as expected) and the CPU is running marginally faster than on-demand.

3. 100% CPU busy.
   - performance and on-demand are comparable in terms of power consumption and CPU frequency.

PERFORMANCE essentially runs the CPU at higher frequency all the time, whereas ONDEMAND will scale up/down depending on the utilization. I believe the default should be ONDEMAND post boot as this is the most flexible option and will provide power saving when the system is less utilized. If users want to burn power and they can opt-in to manually setting to PERFORMANCE, but I think this should be opt-in rather than the default setting for any class of machine.

Finally, if we don't want the userspace changes, we could default the kernel to ONDEMAND and take a hit on slower boot performance.

To clarify I see the options as:

1. Boot with PERFORMANCE and fix the userspace to set ONDEMAND in the post-boot stage
2. Failing this, don't let userspace do anything smart post-boot and default to ONDEMAND

Attached are some data points I gathered with the 5.8 kernel.

[Colin Ian King (colin-king)]

Fix sent to mailing list for review: https://lists.ubuntu.com/archives/kernel-team/2020-August/112820.html

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Dimitri John Ledkov (xnox)]

Proof that we must not use performance governor attached, from one of my team mates.

[Julian Andres Klode (juliank)]

Why are we looking at focal now? The change to systemd only happened after the opening of groovy.

Data is tricky. There are a ton of different cpufreq drivers that are affected, and they all have different behavior. pstates alone has different behavior on newer intels that do pstates in hardware (hwp) vs those that do them in software.

[Julian Andres Klode (juliank)]

For example, the measurements on the X220 do not reflect situation on modern Intel systems, as they scale differently from Skylake and newer, as they do not have HWP.

A CPU with HWP (hardware P-states) behaves as you'd expect sort of - it runs at close to max frequency all the time, and scales down extremely in non-performance modes. It scales up and down faster than older models, given that HWP does the frequency scaling inside the CPU.

Disabling HWP gives you X220-style old scaling which is slower, and does not go as far down as the HWP scaling.

[Colin Ian King (colin-king)]

Thanks Julian, I'd like to find range of recent kit and do a full analysis. I fear that what ever the default, it will be suboptimal for some configurations.

[Dimitri John Ledkov (xnox)]

@julian Ubuntu Desktop in 20.04.2 will receive the 20.10's kernel by default and thus will adopt the 20.10 default. Imho the linux-generic (ga) kernel should also be updated to the same default, to make it the same across -generic, -hwe, -oem kernel flavours in 20.04. Because in 20.04, defaulting to performance governor is wrong too.

[Dimitri John Ledkov (xnox)]

@colin-king with or without additional measurements default to performance and relying on userspace to switch to ondemand at some later point during boot is wrong. It means we are risking melting laptops and catching fire. I.e. boot machine, walk away, it sits in the initrd at the LUKS unlock prompt melting the desk and everything around it.

[Matthieu Baerts (matttbe)]

@Dimitry: Are we not safe on 20.04 because the "ondemand" systemd service is still there and will switch to "ondemand" CPU freq governor after boot?

This service has been removed in systemd 245.5-1. Are there plan to backport this to 20.04.2?

[Colin Ian King (colin-king)]

From my understanding, focal has systemd 245.4-4, so we don't yet need to backport this kernel chnage to focal. If it is deemed necessary to backport this to focal kernels please let me know.

[Timo Aaltonen (tjaalton)]

not needed for oem-5,6 which is (mostly) focal only

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 5.8.0-19.20

---------------
linux (5.8.0-19.20) groovy; urgency=medium

  * groovy/linux: 5.8.0-19.20 -proposed tracker (LP: #1895120)

  * Please switch default, hwe, oem kernel flavours governor to
    CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y , such that advanced userspace
    utilities such as game-mode can be later used to rev-up to to performance,
    or rev-down to powersave. (LP: #1885730)
    - [Config] Set the default CPU governor to ONDEMAND

  * Packaging resync (LP: #1786013)
    - update dkms package versions
    - [Packaging] update variants

  * [WD19TB] external DP failed with DRM error message (LP: #1886165)
    - drm/i915/tgl+: Use the correct DP_TP_* register instances in MST encoders
    - drm/i915/tgl+: Fix TBT DPLL fractional divider for 38.4MHz ref clock

  * Groovy update: v5.8.8 upstream stable release (LP: #1895097)
    - hwmon: (pmbus/isl68137) remove READ_TEMPERATURE_1 telemetry for RAA228228
    - HID: quirks: Always poll three more Lenovo PixArt mice
    - drm/msm/dpu: Fix reservation failures in modeset
    - drm/msm/dpu: Fix scale params in plane validation
    - drm/msm/dpu: fix unitialized variable error
    - tty: serial: qcom_geni_serial: Drop __init from qcom_geni_console_setup
    - drm/msm: add shutdown support for display platform_driver
    - hwmon: (applesmc) check status earlier.
    - nvmet: Disable keep-alive timer when kato is cleared to 0h
    - drm/msm: enable vblank during atomic commits
    - habanalabs: unmap PCI bars upon iATU failure
    - habanalabs: validate packet id during CB parse
    - habanalabs: set clock gating according to mask
    - habanalabs: proper handling of alloc size in coresight
    - habanalabs: set max power according to card type
    - habanalabs: validate FW file size
    - habanalabs: check correct vmalloc return code
    - drm/msm/a6xx: fix gmu start on newer firmware
    - gfs2: add some much needed cleanup for log flushes that fail
    - hv_utils: return error if host timesysnc update is stale
    - hv_utils: drain the timesync packets on onchannelcallback
    - ceph: don't allow setlease on cephfs
    - i2c: iproc: Fix shifting 31 bits
    - drm/omap: fix incorrect lock state
    - irqchip/ingenic: Leave parent IRQ unmasked on suspend
    - cpuidle: Fixup IRQ state
    - nbd: restore default timeout when setting it to zero
    - s390: don't trace preemption in percpu macros
    - drm/amd/display: should check error using DC_OK
    - drm/amd/display: Reject overlay plane configurations in multi-display
      scenarios
    - drivers: gpu: amd: Initialize amdgpu_dm_backlight_caps object to 0 in
      amdgpu_dm_update_backlight_caps
    - drm/amd/display: Revert HDCP disable sequence change
    - drm/amd/display: Fix passive dongle mistaken as active dongle in EDID
      emulation
    - drm/amd/display: Keep current gain when ABM disable immediately
    - drm/amd/display: Retry AUX write when fail occurs
    - drm/amd/display: Fix memleak in amdgpu_dm_mode_config_init
    - xen/xenbus: Fix granting of vmalloc'd memory
    - fsldma: fix very broken 32-bit ppc ioread64 functionality
    - dmaengine: of-dma: Fix of_dma_router_xla...

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux-riscv - 5.8.0-3.3

---------------
linux-riscv (5.8.0-3.3) groovy; urgency=medium

  * groovy/linux-riscv: 5.8.0-3.3 -proposed tracker (LP: #1896666)

  * Miscellaneous Ubuntu changes
    - [Config] update config for CONFIG_VGACON_SOFT_SCROLLBACK

  [ Ubuntu: 5.8.0-20.21 ]

  * groovy/linux: 5.8.0-20.21 -proposed tracker (LP: #1896668)
  * Lenovo ThinkBook 14-IML Touchpad not showing up in /proc/bus/input/devices
    (LP: #1853277)
    - i2c: core: Call i2c_acpi_install_space_handler() before
      i2c_acpi_register_devices()
  * Enable LTR for endpoints behind VMD (LP: #1896598)
    - SAUCE: PCI/ASPM: Enable LTR for endpoints behind VMD
  * Remove duplicated code in ip_defrag.sh of kselftests/net (LP: #1894062)
    - Revert "UBUNTU: SAUCE: selftests: net: ip_defrag: modprobe missing
      nf_defrag_ipv6 support"
  * [SRU] [Focal/OEM-5.6/Groovy]Fix AMD usb host controller lost after stress S3
    (LP: #1893914)
    - SAUCE: xhci: workaround for S3 issue on AMD SNPS 3.0 xHC
  * debian/rules editconfigs does not work on s390x to change s390x only configs
    (LP: #1863116)
    - [Packaging] kernelconfig -- only update/edit configurations on architectures
      we have compiler support
  * [Ubuntu 20.10] zPCI DMA tables and bitmap leak on hard unplug (PCI Event
    0x0304) (LP: #1896216)
    - s390/pci: fix leak of DMA tables on hard unplug
  * md: improve IO accounting (LP: #1891151)
    - md: improve io stats accounting
  * Groovy update: v5.8.10 upstream stable release (LP: #1896078)
    - ARM: OMAP2+: Fix an IS_ERR() vs NULL check in _get_pwrdm()
    - ARM: dts: logicpd-torpedo-baseboard: Fix broken audio
    - ARM: dts: logicpd-som-lv-baseboard: Fix broken audio
    - ARM: dts: logicpd-som-lv-baseboard: Fix missing video
    - regulator: push allocation in regulator_ena_gpio_request() out of lock
    - regulator: remove superfluous lock in regulator_resolve_coupling()
    - ARM: dts: socfpga: fix register entry for timer3 on Arria10
    - ARM: dts: omap5: Fix DSI base address and clocks
    - ARM: dts: ls1021a: fix QuadSPI-memory reg range
    - ARM: dts: imx7ulp: Correct gpio ranges
    - arm64: dts: imx: Add missing imx8mm-beacon-kit.dtb to build
    - ARM: dts: imx7d-zii-rmu2: fix rgmii phy-mode for ksz9031 phy
    - RDMA/rtrs-srv: Replace device_register with device_initialize and device_add
    - RDMA/rxe: Fix memleak in rxe_mem_init_user
    - RDMA/rxe: Drop pointless checks in rxe_init_ports
    - RDMA/rxe: Fix panic when calling kmem_cache_create()
    - RDMA/bnxt_re: Do not report transparent vlan from QP1
    - RDMA/bnxt_re: Fix the qp table indexing
    - RDMA/bnxt_re: Static NQ depth allocation
    - RDMA/bnxt_re: Fix driver crash on unaligned PSN entry address
    - RDMA/bnxt_re: Remove the qp from list only if the qp destroy succeeds
    - drm/sun4i: add missing put_device() call in sun8i_r40_tcon_tv_set_mux()
    - arm64: dts: imx8mq: Fix TMU interrupt property
    - drm/sun4i: Fix dsi dcs long write function
    - scsi: qla2xxx: Fix regression on sparc64
    - scsi: libsas: Set data_dir as DMA_NONE if libata marks qc as NODATA
    - drm/virtio: fix unblank
    - RDMA/core: Fix unsafe l...

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux-raspi - 5.8.0-1003.6

---------------
linux-raspi (5.8.0-1003.6) groovy; urgency=medium

  * groovy/linux-raspi: 5.8.0-1003.6 -proposed tracker (LP: #1898142)

  * Please switch default, hwe, oem kernel flavours governor to
    CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y , such that advanced userspace
    utilities such as game-mode can be later used to rev-up to to performance,
    or rev-down to powersave. (LP: #1885730)
    - [Config] raspi: Set the default CPU governor to ONDEMAND

  * groovy/linux-raspi: Upstream raspberrypi patchset 2020-09-16 (LP: #1896436)
    - Revert "raspberrypi-cpufreq: Only report integer pll divisor frequencies"
    - staging: vchiq_arm: children inherit DMA config
    - ARM: dts: 2711 DMA can address 36 bits
    - bcm2835-dma: Advertise the full DMA range
    - add CONFIG_CRYPTO_USER_API_HASH=m
    - configs: Adding remaining crypto API modules
    - configs: Restore missing cgroups to BCM2835-7
    - ARM: dts: Add UART skip-init properties for U-boot
    - drm/vc4: Remove UIF from the list of modifiers returned by
      format_mod_supported
    - ARM: proc-v7: Force misalignment of early stmia
    - overlays: Fix sc16is75x overlays w.r.t. serdev
    - overlays: Delete spi0-hw-cs
    - overlays: Add maxtherm overlay for MAX6675/31855
    - configs: add CONFIG_SENSORS_IIO_HWMON=m
    - dtoverlays: Add the iio_hwmon driver to correct ADC issues
    - dts: bcm2711: Disable DVP by default
    - config: Add USB gadget support to bcm2711 config
    - overlays: Regenerate upstream-pi4
    - drm/vc4: Increase the number of planes per crtc in FKMS.
    - drm/vc4: Set the possible crtcs mask correctly for planes with FKMS
    - staging: vc04_services: codec: Fix incorrect buffer cleanup
    - staging: vc04_service: codec: Allow start_streaming to update the buffernum
    - staging: vc04_services: codec: Fix component enable/disable
    - configs: Add USB_GADGET=m to bcmrpi3_defconfig
    - update rpi-display-overlay.dts pins for 5.4
    - dtoverlays: Add overlay for the PCA953x family of GPIO expanders
    - rtc: rv3028: Write BSM and TCE/TCR to EEPROM
    - rtc: rv3028: Refresh RAM on EEPROM write
    - dt/overlays: Add PiFace Digital Device Tree Overlay
    - configs: Regenerate defconfigs
    - configs: Restore CONFIG_CFG80211_WEXT=y
    - media: bcm2835: unicam: Select MEDIA_CONTROLLER and VIDEO_V4L2_SUBDEV_API
    - staging: media: rpivid: Select MEDIA_CONTROLLER and
      MEDIA_CONTROLLER_REQUEST_API
    - staging: vc04_services: codec: Select MEDIA_CONTROLLER
    - staging: vc04_services: isp: Select MEDIA_CONTROLLER
    - configs: Add CONFIG_UEVENT_HELPER=y
    - overlays: Updated MCP3008 compatible strings.
    - RESET_CONTROLLER needs to be activated to compile Broadcom BCM2835 clock
      support
    - ARM: dts: bcm2711: Enable support for DDR52 eMMC
    - staging: vc04_services: ISP: Fix dmabuf error check in S_CTRL
    - ARM: dts: bcm2708.dtsi: Don't delete the cpus node
    - configs: Add I2C_HID=m
    - configs: Add CONFIG_SPS30=m
    - configs: Enable upstream cpufreq driver for pi0/pi1
    - ARM: dts: bcm2835: Use the L2 non-allocating alias
    - media: bcm2835-unicam:...