- Sep 14, 2023
-
-
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>
-
Phil Elwell authored
Retrieve the system timer base address directly from DT. Signed-off-by:
Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
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>
-
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
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>
-
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
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>
-
Phil Elwell authored
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>
-
Phil Elwell authored
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>
-
Phil Elwell authored
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>
-
Phil Elwell authored
Move common pin group declarations into the shared bcm2711-rpi-ds.dtsi. No functional change. Signed-off-by:
Phil Elwell <phil@raspberrypi.com>
-
Jose Maria Casanova Crespo authored
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>
-
Dave Stevenson authored
The sensor supports H & V flips, but the controls were READ_ONLY. Note that the Bayer order changes with these flips, therefore they set the V4L2_CTRL_FLAG_MODIFY_LAYOUT property. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Sony have advised that there are variants of the IMX258 sensor which require slightly different register configuration to the mainline imx258 driver defaults. There is no available run-time detection for the variant, so add configuration via the DT compatible string. The Vision Components imx258 module supports PDAF, so add the register differences for that variant Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
There are a number of variants of the imx258 modules that can not be differentiated at runtime, so add compatible strings for them. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
imx258.yaml doesn't include the vendor prefix of sony, so rename to add it. Update the id entry and MAINTAINERS to match. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
With the binned modes, there is little point in faithfully reproducing the horizontal line length of 5352 pixels on the CSI2 bus, and the FIFO between the pixel array and MIPI serialiser allows us to remove that dependency. Allow the pixel array to run with the normal settings, with the MIPI serialiser at half the rate. This requires some additional information for the link frequency to pixel rate function that needs to be added to the configuration tables. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
With a read only control there is limited point in advertising a minimum and maximum for the control, so change to set the value, min, and max all to the selected pixel rate. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Whilst not documented, register 0x0103 bit 0 is the soft reset for the sensor, so send it before trying to configure the sensor. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The sensor has a register CIT_LSHIFT which extends the exposure and frame times by the specified power of 2 for longer exposure times. Add support for this by configuring this register via V4L2_CID_VBLANK and extending the V4L2_CID_EXPOSURE range accordingly. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The data sheet states that the maximum value for registers 0x0340/0x0341 FRM_LENGTH_LINES is 65525(decimal), not the 0xFFFF defined in this driver. Correct this limit. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The sensor supports the clock lane either remaining in HS mode during frame blanking, or dropping to LP11. Add configuration of the mode via V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Libcamera requires the cropping information for each mode, so add this information to the driver. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
V4L2 sensor drivers are expected are expected to clip the supported exposure range based on the VBLANK configured. IMX258 wasn't doing that as register 0x350 (FRM_LENGTH_CTL) switches it to a mode where frame length tracks coarse exposure time. Disable this mode and clip the range for V4L2_CID_EXPOSURE appropriately based on V4L2_CID_VBLANK. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Extends the driver to also support 2 data lanes. Frame rates are obviously more restricted on 2 lanes, but some hardware simply hasn't wired more up. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
There's no reason why the clock must be 19.2MHz and nothing else (indeed this isn't even a frequency listed in the datasheet), so add support for 24MHz as well. The PLL settings result in slightly different link frequencies, so parameterise those. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com>
-