Skip to content
  1. Jul 21, 2020
  3. Jul 13, 2020
  5. Jul 12, 2020
  7. Jul 09, 2020
  9. Jul 07, 2020
  11. Jul 05, 2020
  13. Jul 04, 2020
    • Dave Stevenson's avatar
      dtoverlays: Fixup imx219 and imx477 overlays due to parsing failures · b71ade40
      Dave Stevenson authored 
      

imx219 overlay failed to detect as CSI2 as it was missing any
of the CSI2 properties on the Unicam end of the configuration.
Clean up imx477 as well to include all the relevant properties.

Fixes: "dt/dtoverlays: Fix up base DT and overlays for updated Unicam driver"

Signed-off-by: default avatarDave Stevenson <dave.stevenson@raspberrypi.com>
      b71ade40
    • Lukas Wunner's avatar
      irqchip/bcm2835: Quiesce IRQs left enabled by bootloader · 9fc9bd87
      Lukas Wunner authored 
      [ Upstream commit bd59b343 ]

Per the spec, the BCM2835's IRQs are all disabled when coming out of
power-on reset.  Its IRQ driver assumes that's still the case when the
kernel boots and does not perform any initialization of the registers.
However the Raspberry Pi Foundation's bootloader leaves the USB
interrupt enabled when handing over control to the kernel.

Quiesce IRQs and the FIQ if they were left enabled and log a message to
let users know that they should update the bootloader once a fixed
version is released.

If the USB interrupt is not quiesced and the USB driver later on claims
the FIQ (as it does on the Raspberry Pi Foundation's downstream kernel),
interrupt latency for all other peripherals increases and occasional
lockups occur.  That's because both the FIQ and the normal USB interrupt
fire simultaneously:

On a multicore Raspberry Pi, if normal interrupts are routed to CPU 0
and the FIQ to CPU 1 (hardcoded in the Foundation's kernel), then a USB
interrupt causes CPU 0 to spin in bcm2836_chained_handle_irq() until the
FIQ on CPU 1 has cleared it.  Other peripherals' interrupts are starved
as long.  I've seen CPU 0 blocked for up to 2.9 msec.  eMMC throughput
on a Compute Module 3 irregularly dips to 23.0 MB/s without this commit
but remains relatively constant at 23.5 MB/s with this commit.

The lockups occur when CPU 0 receives a USB interrupt while holding a
lock which CPU 1 is trying to acquire while the FIQ is temporarily
disabled on CPU 1.  At best users get RCU CPU stall warnings, but most
of the time the system just freezes.

Fixes: 89214f00

 ("ARM: bcm2835: add interrupt controller driver")
Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
Signed-off-by: default avatarMarc Zyngier <maz@kernel.org>
Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: default avatarNicolas Saenz Julienne <nsaenzjulienne@suse.de>
Link: https://lore.kernel.org/r/f97868ba4e9b86ddad71f44ec9d8b3b7d8daa1ea.1582618537.git.lukas@wunner.de
      9fc9bd87