At a high FPS with RAW10, there is frame corruption for 480p because the
rate_factor of 2 is used with the normal 2x2 bining [1]. This commit
ties the rate_factor to the selected binning mode. For the 480p mode,
analog 2x2 binning mode with a rate_factor of 2 is always used. For the
1232p mode the normal 2x2 binning mode is used for RAW10 while analog
2x2 binning mode is used for RAW8.

[1] https://github.com/raspberrypi/linux/issues/5493



Signed-off-by: Vinay Varma <varmavinaym@gmail.com>

A DSI write is issued in st7701_prepare even when the probed panel
runs on SPI. In practice, this results in a panic with the
vc4-kms-dpi-hyperpixel2r overlay active.

Perform the equivalent write over SPI in this case.

Signed-off-by: Jack Andersen <jackoalan@gmail.com>

Disable enumerating and setting of the 2x2 binned mode entirely as it
does not seem to work for either mono or colour sensor variants.

Signed-off-by: Naushir Patuck <naush@raspberrypi.com>

Fixes: 654368fe ("bcm2835-dma: Need to keep PROT bits set in CS on 40bit controller")

Signed-off-by: Dom Cobley <popcornmix@gmail.com>

There is a problem with the current abort scheme
when dma is blocked on a DREQ which prevents halting.

This is triggered by SPI driver which aborts dma
in this state and so leads to a halt timeout.

Discussion with Broadcom suggests the sequence:

CS.ACTIVE=0
while (CS.OUTSTANDING_TRANSACTIONS == 0)
  wait()
DEBUG.RESET=1

should be safe on a dma40 channel.

Unfortunately the non-dma40 channels don't have
OUTSTANDING_TRANSACTIONS, so we need a more
complicated scheme.

We attempt to abort the channel, which will work
if there is no blocked DREQ.

It it times out, we can assume there is no AXI
transfer in progress and reset anyway.

The length of the timeout is observed at ~20us.

Signed-off-by: Dom Cobley <popcornmix@gmail.com>

As of [1], using PPS_FETCH on a 64-bit ARM kernel with a 32-bit userland
is broken, returning a timeout. This is because the requested 4-byte
alignment for struct pps_ktime_compat (illegal on arm64) results in the
timeout flags field being uninitialised.

Make the hack specific to X86_64 builds with CONFIG_COMPAT defined.

[1] commit c2a49fe8 ("pps: fix padding issue with PPS_FETCH for
    ioctl_compat")

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


Fixes: c2a49fe8 ("pps: fix padding issue with PPS_FETCH for ioctl_compat")
Signed-off-by: Phil Elwell <phil@raspberrypi.com>

Now that transfers aren't aborted immediately (and uncleanly) on
errors, and the FIFOs are always drained after all transfers, we
can implement I2C_M_IGNORE_NAK by ignoring the returned error
value.

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

If a transaction is aborted immediately on ERR being reported,
then the bus is not returned to the STOP condition, and devices
generally get very upset.

Handle the ERR and CLKT conditions only when TA is not set.

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

On error condition, note the error return code, but still
handle the FIFOs in the normal way rather than relying on
C_CLEAR flushing everything cleanly.

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

Rather than always reading the maximum number of points supported
by the chip (which may be as high as 10), read the number of
active points first, and read data for just those.
In most cases this will result in less data on the I2C bus,
with only the maximum touch points taking more due to a second
read that has to configure the start address.

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

Rather than deleting the upstream stdout-path declaration, overwrite
it with one selecting serial0, which will always be the UART mapped
to the 40-pin header (provided enable_uart=1 is specified). Doing
so has the advantage that earlycon can be configured just by adding
"earlycon" to the command line.

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

The arm64 initialisation uses the physical address reachable by all
DMA controllers to set the size of ZONE_DMA. This fails on BCM2711
with the current dts files because the declaration of the I/O space
fools it into thinking the legacy 30-bit DMA channels can see most
of the 32-bit space.

Take advantage of the simple nature of the implementation by adding
a node with a restricted dma-ranges property solely so to act as the
limiting factor in the calculation.

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



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

Now we wait for write responses and have a burst
size of 4, we can set the fifo threshold much higher.

Set it to 28 (of the 32 entry size) to keep fifo
fuller and reduce chance of underflow.

Signed-off-by: Dom Cobley <popcornmix@gmail.com>

Also tweak the flags:
Remove NO_WAIT_RESP (27)
Add BURST_LENGTH (30)

The AXI path from DMA controller to HDMI audio fifo
is long, and may have considerable delay.

When using DMA without waiting for responses it is
very easy to overfill the fifo as when the fifo
removes DREQ there may be large numbers of writes
in flight.

This means the DREQ fifo threshold must be set low
enough to accommodate the maximum number of in flight
writes (unknown by something like 24),
which means the 32 element fifo only requests data
when it contains fewer than 8 entries, making it
susceptable to underflow.

If we wait for write responses we can set the DREQ
fifo threshold much higher as there are a controlled
number of writes in flight.

However the overall bandwidth is reduced by setting
this, so also enable a burstsize of 4 to improve
bandwidth.

Signed-off-by: Dom Cobley <popcornmix@gmail.com>

Resetting them to zero puts DMA channel into secure mode
which makes further accesses impossible

Signed-off-by: Dom Cobley <popcornmix@gmail.com>

Add a control bit to enable a multi-beat burst on a DMA.
This improves DMA performance and is required for HDMI audio.

Signed-off-by: Dom Cobley <popcornmix@gmail.com>

The sequence we were doing was not safe.

Clearing CS meant BCM2835_DMA_WAIT_FOR_WRITES was cleared
and so polling BCM2835_DMA_WAITING_FOR_WRITES has no benefit

Broadcom have provided a recommended sequence to abort
a dma lite channel, so switch to that.

Signed-off-by: Dom Cobley <popcornmix@gmail.com>

It wasn't aborting the transfer and caused stop/start
of hdmi audio dma to be unreliable.

New sequence approved by Broadcom.

Signed-off-by: Dom Cobley <popcornmix@gmail.com>

It goes in info not extra

Signed-off-by: Dom Cobley <popcornmix@gmail.com>

The bcm2835_dma_create_cb_chain() function is in charge of building up
the descriptors chain for a given transfer.

It was initially supporting only the BCM2835-style DMA controller, and
was later expanded to support controllers with 40-bits channels that use
a different descriptor layout.

However, some part of the function only use the old style descriptor,
even when building a chain of new-style descriptors, resulting in weird
bugs.

Fixes: 9a52a991 ("bcm2835-dma: Add proper 40-bit DMA support")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

bcm2711_dma40_memcpy has some code strictly equivalent to the
to_bcm2711_cbaddr() function. Let's use it instead.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>

For 40 bits channels, the position is reported by reading the upper byte
in the SRCI/DESTI registers. However the driver adds that upper byte
with an 8-bits left shift, while it should be 32.

Fixes: 9a52a991 ("bcm2835-dma: Add proper 40-bit DMA support")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>

Add an i2s_dma4 parameter to make the I2S interface use 40-bit DMA
channels, taking the opportunity to remove some duplication.

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

Contrary to what struct snd_dmaengine_dai_dma_data suggests, the
configuration of addresses of DMA slave interfaces should be done in
CPU physical addresses.

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

Contrary to what struct snd_dmaengine_dai_dma_data suggests, the
configuration of addresses of DMA slave interfaces should be done in
CPU physical addresses.

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

Contrary to what struct snd_dmaengine_dai_dma_data suggests, the
configuration of addresses of DMA slave interfaces should be done in
CPU physical addresses.

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

Retrieve the system timer base address directly from DT.

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

Although the system timer is largely ignored in favour of the ARM local
timers, retain the DT node so that the bcm2835-sdhost logging can find
the timer in a cleaner fashion.

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

Contrary to what struct snd_dmaengine_dai_dma_data suggests, the
configuration of addresses of DMA slave interfaces should be done in
CPU physical addresses.

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

Contrary to what struct snd_dmaengine_dai_dma_data suggests, the
configuration of addresses of DMA slave interfaces should be done in
CPU physical addresses.

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

Slave addresses for DMA are meant to be supplied as physical addresses
(contrary to what struct snd_dmaengine_dai_dma_data does).

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

Contrary to what struct snd_dmaengine_dai_dma_data suggests, the
configuration of addresses of DMA slave interfaces should be done in
CPU physical addresses.

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

Slave addresses for DMA are meant to be supplied as physical addresses
(contrary to what struct snd_dmaengine_dai_dma_data does). It is up to
the DMA controller driver to perform the translation based on its own
view of the world, as described in Device Tree.

Now that the Pi Device Trees have the correct peripheral mappings,
replace the hacky address munging with phys_to_dma().

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

Step one of using DMA addresses the intended way is to make sure that
the mapping between CPU physical addresses and DMA addresses in Device
Tree is complete and correct.

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

Now that the base bcm2711 base dts files give the added I/O interfaces
references to the default pinctrl nodes, remove the same from their
respective overlays.

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



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

Give all the extended I/O interfaces - I2C3-6, SPI3-6 and UART2-5 -
sensible default pinctrl references.

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



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

Move common pin group declarations into the shared bcm2711-rpi-ds.dtsi.
No functional change.

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

Two new debugfs interfaces are implemented:

- gpu_usage: exposes the total runtime since boot of each
of the 5 scheduling queues available at V3D (BIN, RENDER,
CSD, TFU, CACHE_CLEAN). So if the interface is queried at
two different points of time the usage percentage of each
of the queues can be calculated.

- gpu_pid_usage: exposes the same information but to the
level of detail of each process using the V3D driver. The
runtime for process using the driver is stored. So the
percentages of usage by PID can be calculated with
measures at different timestamps.

The storage of gpu_pid_usage stats is only done if
the debugfs interface is polled during the last 70 seconds.
If a process does not submit a GPU job during last 70
seconds its stats will also be purged.

Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>

It has been observed that edge events can be lost when GPIO edges occur
close to each other. Investigation suggests this is due to a hardware
bug, although no mechanism has been identified.

Work around the event loss by moving the IRQ acknowledgement into the
main ISR, adding missing events by explicit level-change detection.

See: https://forums.raspberrypi.com/viewtopic.php?t=350295



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

The XFRM_INTERFACE option enables "a virtual interface to route IPsec
traffic". Add that as a module, enabling statistics and "sub policy"
at the same time.

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



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