Ported pcie-brcmstb bounce buffer implementation to ARM64.
This enables full 4G RAM usage on Raspberry Pi in 64-bit mode.

Signed-off-by: Yaroslav Rosomakho <yaroslavros@gmail.com>

PCIe advanced error reporting is supported by the root complex, so make
use of it.

Signed-off-by: Jonathan Bell <jonathan@raspberrypi.org>

Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi>

On RaspberryPi, only the first 1Gb can be used for DMA[1].

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2019-July/665986.html



Signed-off-by: Andrei Gherzan <andrei@balena.io>

The new i2c overlays for pi4 (i2c3, i2c4, i2c5, i2c6) have a
standardised interface that allows pin groups to be chosen
atomically rather than as individual pins. Add i2c0 and i2c1
overlays to fit the naming scheme and parameter usage, deprecating
i2c0-bcm2708 and i2c1-bcm2708.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>

The dpi overlays use the fb device tree node as a place to hang the
necessary pinctrl changes. With one of the VC4 overlays loaded, the
fb node is disabled so the changes have no effect.

Modify the overlays to also use the vc4 node, to cover both use
cases.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>

The Raspberry Pi 4 uses the brcmstb thermal driver rather than brcm2835,
based on the device tree compatible string 'brcm,avs-tmon-bcm2838'. With
CONFIG_BRCMSTB_THERMAL enabled, reading temperature from
/sys/class/thermal/thermal_zone0/temp works as expected instead of
returning EINVAL.

Fixes: https://github.com/raspberrypi/linux/issues/3071


Signed-off-by: Allen Wild <allenwild93@gmail.com>

Add support for the PCF2129 RTC to i2c-rtc and i2c-rtc-gpio overlays.
Also add rv3028 to i2c-rtc-gpio (it was missed previously), and don't
attempt to set an alternate address for the PCF2127.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>

commit 7a9b6be9 upstream.

When adding the MFD dependency for power domains and WDT in bcm2835, I
added it only on the arm32 side and missed it for arm64.

Fixes: 5e6acc3e

 ("bcm2835-pm: Move bcm2835-watchdog's DT probe to an MFD.")
Signed-off-by: Eric Anholt <eric@anholt.net>
Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>

The BCM2835 I2C blocks have a register to set the clock-stretch
timeout - how long the device is allowed to hold SCL low - in bus
cycles. The current driver doesn't write to the register, therefore
the default value of 64 cycles is being used for all devices.

Set the timeout to the value recommended for SMBus - 35ms.

See: https://github.com/raspberrypi/linux/issues/3064



Signed-off-by: Phil Elwell <phil@raspberrypi.org>

Seen on a VLI VL805 PCIe to USB controller. For non-stream endpoints
at least, if the xHC halts on a particular TRB due to an error then
the DCS field in the Out Endpoint Context maintained by the hardware
is not updated with the current cycle state.

Using the quirk XHCI_EP_CTX_BROKEN_DCS and instead fetch the DCS bit
from the TRB that the xHC stopped on.

See: https://github.com/raspberrypi/linux/issues/3060



Signed-off-by: Jonathan Bell <jonathan@raspberrypi.org>

pl011_tx_chars takes a "from_irq" parameter to reduce the number of
register accesses. When from_irq is true the function assumes that the
FIFO is half empty and writes up to half a FIFO's worth of bytes
without polling the FIFO status register, the reasoning being that
the function is being called as a result of the TX interrupt being
raised. This logic would work were it not for the fact that
pl011_rx_chars, called from pl011_int before pl011_tx_chars, releases
the spinlock before calling tty_flip_buffer_push.

A user thread writing to the UART claims the spinlock and ultimately
calls pl011_tx_chars with from_irq set to false. This reverts to the
older logic that polls the FIFO status register before sending every
byte. If this happen on an SMP system during the section of the IRQ
handler where the spinlock has been released, then by the time the TX
interrupt handler is called, the FIFO may already be full, and any
further writes are likely to be lost.

The fix involves adding a per-port flag that is true iff running from
within the interrupt handler and the spinlock has not yet been released.
This flag is then used as the value for the from_irq parameter of
pl011_tx_chars, causing polling to be used in the unsafe case.

Fixes: 1e84d223

 ("serial/amba-pl011: Refactor and simplify TX FIFO handling")

Signed-off-by: Phil Elwell <phil@raspberrypi.org>

The "bus" parameter has two functions - providing unique names for
multiple instances of the overlay, and allowing the number of the bus
(i.e. "i2c-<bus>") to be specified. The second function hasn't worked
as intended because the overlay doesn't include a "reg" property and
the firmware intentionally won't create a "reg" property if one doesn't
already exist.

Allow the bus numbering scheme to work as intended by providing a "reg"
with a default value that means "the next available one".

See: https://github.com/raspberrypi/linux/issues/3062



Signed-off-by: Phil Elwell <phil@raspberrypi.org>

Commit 9de93b04 upstream.

Probe function fails to recognize that upstream clock actually
doesn't yet exist because clock driver has not been initialized.
Actually try to go get the clock and test for its existence
before trying to set up a downstream clock based upon it.

This fixes a bug that causes the i2c driver not to work with
monolithic kernels.

Fixes: bebff81f

 ("i2c: bcm2835: Model Divider in CCF")
Signed-off-by: Annaliese McDermond <nh6z@nh6z.net>
Acked-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Commit 4a5cfa39 upstream.

If any of the clock code in the probe fails and returns, the IRQ
will not be freed.  Moving the IRQ request to last allows it to
be freed on any errors further up in the probe function.  devm_
calls can apparently not be used because there are some potential
race conditions that will arise.

Fixes: bebff81f

 ("i2c: bcm2835: Model Divider in CCF")
Signed-off-by: Annaliese McDermond <nh6z@nh6z.net>
Acked-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Rename the various pi3- overlays to be more generic, listing
the devices they apply to in the README. The original names are
retained for backwards compatibility as files that just include
the new versions - the README marks them as being deprecated.

See: https://github.com/raspberrypi/firmware/issues/1174



Signed-off-by: Phil Elwell <phil@raspberrypi.org>

As a result of being loaded by the POE HAT EEPROM, the rpi-poe overlay
doesn't expose parameters in the usual way; instead it adds them to
the base Device Tree, and the user is expected to use "dtparam=..."
to access them.

To make the documentation correct and to protect users who load the
overlay explicitly, expecting to be able to use the parameters, add
real parameters to the overlay as well.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>

This reverts commit a2c73e18

.
An alternative version was accepted upstream. Revert this patch to
apply that one.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>

Apparently this is a vestigial setting and should be removed.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>

Fix a few minor checkpatch complaints to make the driver clean

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>

Due to a misunderstanding of the DMA mapping APIs, I made
the wrong decision on how to implement this.

Rework to use dma_alloc_coherent instead of the CMA
API. This also allows it to be built as a module easily.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>

The cache flushing ioctls are used by the Pi3 HEVC hw-assisted
decoder as it needs finer grained flushing control than dma_ops
allow.
These cache calls are not present for ARM64, therefore disable
them. We are not actively supporting 64bit kernels at present,
and the use case of the HEVC decoder is fairly limited.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>

The gpio-fan overlay was submitted for the 4.14 kernel where the second
value in the Device Tree gpios declaration was ignored (thanks to an
old-style driver), allowing the fan-control output to be active-high
even though the declaration appears to request it be active-low.
The gpio-fan driver in 4.19 uses GPIO descriptors and honours the
active-low flag that the overlay (accidentally?) supplies.

Change/correct the flags field to mark the GPIO as active-high.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>

This driver is used in the device tree for the emmc2 node.

See #3032

Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>

And all Rabbit's friends-and-relations.

See: https://github.com/raspberrypi/linux/issues/3042



Signed-off-by: Phil Elwell <phil@raspberrypi.org>

See: https://github.com/raspberrypi/linux/issues/3042



Signed-off-by: Phil Elwell <phil@raspberrypi.org>

Downstream Raspberry Pi dts files add "coherent_pool=1M" to the kernel
command line to aid the dwc_otg driver, but this excluded Pi 4 which
uses a new XCHI interface instead. UAS also benefits from a larger
coherent_pool value, so replicate the addition in bcm2711-rpi-4-b.dts.

See: https://github.com/raspberrypi/linux/pull/3040



Signed-off-by: Phil Elwell <phil@raspberrypi.org>

Adds signalling for BT601/709/2020, and limited/full range
(on BT601).

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>

"4600e91b

 Pulled in the multi frame buffer support from the Pi3 repo"
pulled back in the code for allocating the framebuffer from the CMA
heap.
Revert it again.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>

Signed-off-by: Chris G Miller <chris@creative-electronics.net>

commit aacd152e

 upstream.

This commit is fixing a smatch warning:
drivers/w1/slaves/w1_ds2413.c:61 state_read() warn: impossible condition '(*buf == 255) => ((-128)-127 == 255)'
by creating additional u8 variable for the bus reading and comparision

Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 3856032a

 ("w1: ds2413: when the slave is not responding during read, select it again")
Signed-off-by: Mariusz Bialonczyk <manio@skyboo.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3856032a

 upstream.

The protocol is not allowing to obtain a byte of 0xff for PIO_ACCESS_READ
call. It is very likely that the slave was not addressed properly and
it is just not respoding (leaving the bus in logic high state) during
the read of sampled PIO value.
We cannot just call w1_reset_resume_command() because the problem will
persist, instead try selecting (addressing) the slave again.

Signed-off-by: Mariusz Bialonczyk <manio@skyboo.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c50d09a8

 upstream.

The state_read() was calling PIO_ACCESS_READ once and bail out if it
failed for this first time.
This commit is improving this to trying more times before it give up,
similarly as the write call is currently doing.

Signed-off-by: Mariusz Bialonczyk <manio@skyboo.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae2ee27a upstream.

Make the output_write simpler.
Based on Jean-Francois Dagenais code from:
49695ac4

 ("w1: ds2408: reset on output_write retry with readback")

Signed-off-by: Mariusz Bialonczyk <manio@skyboo.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e3743d8

 upstream.

The ds2805 has a structure named: w1_family_2d, which surely
comes from a w1_ds2431 module. This commit fixes this name to
prevent confusion and mark a correct family name.

Signed-off-by: Mariusz Bialonczyk <manio@skyboo.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The dwc2 overlay no longer uses the dwc2_usb label, and the latest
ovmerge (which generates the upstream overlay) removes unused labels.
Update the checked-in version to match.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>

See: https://github.com/raspberrypi/linux/issues/3013



Signed-off-by: Phil Elwell <phil@raspberrypi.org>

Kernels since 4.19 have required the correct manufacture name in the
compatible string for I2C devices, and unfortunately the one for the
Dallas/Maxim DS1307 should have been "dallas,ds1307" and not
"maxim,ds1307".

See: https://github.com/raspberrypi/linux/issues/3013



Signed-off-by: Phil Elwell <phil@raspberrypi.org>

I've attempted to follow the upstream conventions in the DT commits,
but this is just presented here initially as a talking point.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>