- Sep 14, 2023
-
-
Phil Elwell authored
For some reason, TASK_DELAY_ACCT was enabled in all our defconfigs except arm64/bcm2711_defconfig. Correct the oversight. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
See: https://github.com/raspberrypi/linux/issues/5516 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
James Hughes authored
Update audremap information to state pins 40,41 are not available on the CM4. Signed-off-by: James Hughes <(james.hughes@raspberrypi.com)>
-
Lee Jackson authored
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>
-
Lee Jackson authored
Added 8000x6000 10-bit (cropped) @ 3fps mode for Arducam 64MP Signed-off-by: Lee Jackson <lee.jackson@arducam.com>
-
Lee Jackson authored
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>
-
Matthias Reichl authored
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>
-
Matthias Reichl authored
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>
-
Phil Elwell authored
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>
-
Phil Elwell authored
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>
-
Naushir Patuck authored
The temperature sensor enable register write got lost at some point. Re-enable it. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
-
6by9 authored
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>
-
Naushir Patuck authored
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>
-
Phil Elwell authored
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>
-
Vinay Varma authored
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>
-
Jack Andersen authored
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>
-
Naushir Patuck authored
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>
-
Dom Cobley authored
Fixes: 654368fe ("bcm2835-dma: Need to keep PROT bits set in CS on 40bit controller") Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-
Dom Cobley authored
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>
-
Phil Elwell authored
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>
-
Dave Stevenson authored
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>
-
Dave Stevenson authored
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>
-
Dave Stevenson authored
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>
-
Dave Stevenson authored
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>
-
Phil Elwell authored
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>
-
Phil Elwell authored
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>
-
Dom Cobley authored
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>
-
Dom Cobley authored
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>
-
Dom Cobley authored
Resetting them to zero puts DMA channel into secure mode which makes further accesses impossible Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-
Dom Cobley authored
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>
-
Dom Cobley authored
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>
-
Dom Cobley authored
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>
-
Dom Cobley authored
It goes in info not extra Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Maxime Ripard authored
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>
-
Phil Elwell authored
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>
-
Phil Elwell authored
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>
-
Phil Elwell authored
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>
-
Phil Elwell authored
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>
-