Skip to content
  1. Jan 30, 2020
  3. Jan 29, 2020
    • Phil Elwell's avatar
      overlays: Correct the eth_led* colour assignments · f6e7d78b
      Phil Elwell authored 
      See: https://github.com/raspberrypi/firmware/issues/1311



Signed-off-by: default avatarPhil Elwell <phil@raspberrypi.org>
      f6e7d78b
    • Tim Gover's avatar
      usb: xhci: Raspberry Pi FW loader for VIA VL805 · c74b1b53
      Tim Gover authored 
      

The VL805 FW may either be loaded from an SPI EEPROM or alternatively
loaded directly by the VideoCore firmware. A PCI reset will reset
the VL805 XHCI controller on the Raspberry Pi4 requiring the firmware
to be reloaded if an SPI EEPROM is not present.

Use a VideoCore mailbox to trigger the loading of the VL805
firmware (if necessary) after a PCI reset.

Signed-off-by: default avatarTim Gover <tim.gover@raspberrypi.org>
      c74b1b53
    • Phil Elwell's avatar
      tty: amba-pl011: Avoid rare write-when-full error · 65aa6ec0
      Phil Elwell authored 
      

Under some circumstances on BCM283x processors data loss can be
observed - a single byte missing from the TX output stream. These bytes
are always the last byte of a batch of 8 written from pl011_tx_chars
when from_irq is true, meaning that the FIFO full flag is not checked
before writing.

The transmit optimisation relies on the FIFO being half-empty when the
TX interrupt is raised. Instrumenting the driver further showed that
the failure case correlated with the TX FIFO full flag being set at the
point where the last byte was written to the data register, which
explains the data loss but not how the FIFO appeared to be prematurely
full. A possible explanation is that a FIFO write was in flight at the
time the interrupt was raised, but as yet there is no hypothesis as to
how this might occur.

In the absence of a clear understanding of the failure mechanism, avoid
the problem by checking the FIFO levels before writing the last byte of
the group, which will have minimal performance impact.

Signed-off-by: default avatarPhil Elwell <phil@raspberrypi.org>
      65aa6ec0
    • Phil Elwell's avatar
      ARM: dts: Remove bcm2838-rpi-4-b.dts · 760e4663
      Phil Elwell authored 
      

Upstream are not going to use the bcm2838 identifier, so begin the
cleanup by removing the suggested upstream Pi 4 .dts file.

Signed-off-by: default avatarPhil Elwell <phil@raspberrypi.org>
      760e4663
    • Phil Elwell's avatar
      bcm2838.dtsi: Use BCM2711 PCIe compatible string · d9cebcf9
      Phil Elwell authored 
      

The BCM2711 PCIe controller has a limited address range in the B0
silicon, and the driver uses a compatible string to identify the
limitation. The current Pi 4 firmware will override the compatible
string if it detects a downstream DTB and it is running on a newer
revision but set the default value to enable the workaround for
backwards-compatibility with old firmware.

Signed-off-by: default avatarPhil Elwell <phil@raspberrypi.org>
      d9cebcf9
    • Phil Elwell's avatar
      pcie-brcmstb: Bounce buffer support is for BCM2711B0 · 5d676bc2
      Phil Elwell authored 
      

Add a new compatible string to identify BCM2711B0, as later revisions
don't require the bounce buffer support.

Signed-off-by: default avatarPhil Elwell <phil@raspberrypi.org>
      5d676bc2
    • Phil Elwell's avatar
      ARM: dts: Declare RPi 4B SD card power regulator · ef9c38e6
      Phil Elwell authored 
      

Later revisions of the Raspberry Pi 4B have a separate control over the
SD card power. Expose that control to Linux as a fixed regulator with
a GPIO enable.

Signed-off-by: default avatarPhil Elwell <phil@raspberrypi.org>
      ef9c38e6
    • Phil Elwell's avatar
      mmc: sdhci-iproc: Fix vmmc regulators on iProc · f857c6d2
      Phil Elwell authored 
      

The Linux support for controlling card power via regulators appears to
be contentious. I would argue that the default behaviour is contrary to
the SDHCI spec - turning off the power writes a reserved value to the
SD Bus Voltage Select field of the Power Control Register, which
seems to kill the Arasan/iProc controller - but fortunately there is a
hook in sdhci_ops to override the behaviour. Borrow the implementation
from sdhci_arasan_set_power.

Signed-off-by: default avatarPhil Elwell <phil@raspberrypi.org>
      f857c6d2
  5. Jan 28, 2020
  7. Jan 27, 2020
  9. Jan 24, 2020
  11. Jan 23, 2020
  13. Jan 22, 2020
  15. Jan 21, 2020
  17. Jan 20, 2020
    • Ed Spiridonov's avatar
      Add universal device tree overlay for SPI devices · 0d72d83e
      Ed Spiridonov authored 
      

Just specify the SPI address and device name ("compatible" property).
This overlay lacks any device-specific parameter support!
(some of them could be added later)

Examples:
1. SPI NOR flash on spi0.1, maximum SPI clock frequency 45MHz:
    dtoverlay=anyspi:spi0-1,dev="jedec,spi-nor",speed=45000000
2. MCP3204 ADC on spi1.2, maximum SPI clock frequency 500kHz:
    dtoverlay=anyspi:spi1-2,dev="microchip,mcp3204"

Signed-off-by: default avatarEd Spiridonov <edo.rus@gmail.com>
      0d72d83e
  19. Jan 18, 2020