Enable PDAF output for all modes, and also need to modify Embedded Line
Width to 11560 * 3 (two lines of Embedded Data + one line of PDAF).

Signed-off-by: Lee Jackson <lee.jackson@arducam.com>

Added 8000x6000 10-bit (cropped) @ 3fps mode for Arducam 64MP

Signed-off-by: Lee Jackson <lee.jackson@arducam.com>

Arducam 64MP has specific requirements for the line length, and if these
conditions are not met, the camera will not function properly. Under the
previous configuration, once a stream off operation is performed, the
camera will not output any data, even if a stream on operation is
performed. This prevents us from switching from 1280x720 to another
resolution.

Signed-off-by: Lee Jackson <lee.jackson@arducam.com>

commit 4e087133

 upstream.

According to CTA 861 the channel/speaker allocation info in the
audio infoframe only applies to uncompressed (PCM) audio streams.

The channel count info should indicate the number of channels
in the transmitted audio, which usually won't match the number of
channels used to transmit the compressed bitstream.

Some devices (eg some Sony TVs) will refuse to decode compressed
audio if these values are not set correctly.

To fix this we can simply set the channel count to 0 (which means
"refer to stream header") and set the channel/speaker allocation to 0
as well (which would mean stereo FL/FR for PCM, a safe value all sinks
will support) when transmitting compressed audio.

Signed-off-by: Matthias Reichl <hias@horus.com>
Link: https://lore.kernel.org/r/20230624165232.5751-1-hias@horus.com


Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 04b49b90

 upstream.

The SADs of compressed formats contain the channel and sample rate
info of the audio data inside the compressed stream, but when
building constraints we must use the rates and channels used to
transport the compressed streams.

eg 48kHz 6ch EAC3 needs to be transmitted as a 2ch 192kHz stream.

This patch fixes the constraints for the common AC3 and DTS formats,
the constraints for the less common MPEG, DSD etc formats are copied
directly from the info in the SADs as before as I don't have the specs
and equipment to test those.

Signed-off-by: Matthias Reichl <hias@horus.com>
Link: https://lore.kernel.org/r/20230624165216.5719-1-hias@horus.com


Signed-off-by: Takashi Iwai <tiwai@suse.de>

Add a speed parameter to the jedec-spi-nor overlay to allow much
faster accesses, taking the opportunity to simplify the internals.

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

Higher speeds have been shown to cause data corruption on a Pi 4,
possibly due to clock-stretching.

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



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

The temperature sensor enable register write got lost at some point.
Re-enable it.

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

In converting to using the standard u16_fract type, commit [1] made the
obvious mistake and failed to take account of the difference in
numerator and denominator ordering, breaking all uses of the cs43130
codec.

Fix it.

[1] commit e14bd35e ("ASoC: cs43130: Re-use generic struct u16_fract")

Fixes: e14bd35e

 ("ASoC: cs43130: Re-use generic struct u16_fract")
Signed-off-by: Phil Elwell <phil@raspberrypi.com>

The overlays configured both irq-gpio and an interrupts/
interrupt-parent configuration for the stmpe MFD device.

irq-gpio was reworked in 6.1 and has issues with the configuration
as provided. Removing it and using the interrupts/interrupt-parent
configuration works fine, so do that.

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



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

Ensure that the frame sequence counter is incremented only if a previous
frame start interrupt has occurred, or a frame start + frame end has
occurred simultaneously.

This corresponds the sequence number with the actual number of frames
produced by the sensor, not the number of frame buffers dequeued back
to userland.

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

This patch sets the driver modem line state to the actual line state
at driver startup.

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



Signed-off-by: Earl Schmidt <schmidt.earl.f@gmail.com>
Signed-off-by: Phil Elwell <phil@raspberrypi.com>

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>