- Sep 14, 2023
-
-
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>
-
Dave Stevenson authored
The values and ranges of V4L2_CID_VBLANK are all computed, so there is no reason for it to be a read only control. Remove the register values from the mode lists, add the handler, and remove the read only flag. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The device tree bindings define the relevant regulators for the sensor, so update the driver to request the regulators and control them at the appropriate times. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Registers 0x0202 and 0x0203 are written via the control handler for V4L2_CID_EXPOSURE, so are not needed from the mode lists. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The binned modes set DIG_CROP_X_OFFSET and DIG_CROP_IMAGE_WIDTH to less than the full image, even though the image being captured is meant to be a scaled version of the full array size. Reduce X_OFFSET to 0, and increase IMAGE_WIDTH to the full array. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The output image is defined as being 4208x3118 pixels in size. Y_ADD_STA register was set to 0, and Y_ADD_END to 3118, giving 3119 lines total. The datasheet lists a requirement for Y_ADD_STA to be a multiple of a power of 2 depending on binning/scaling mode (2 for full pixel, 4 for x2-bin/scale, 8 for (x2-bin)+(x2-subsample) or x4-bin, or 16 for (x4-bin)+(x2-subsample)). (Y_ADD_END – Y_ADD_STA + 1) also has to be a similar power of 2. The current configuration for the full res modes breaks that second requirement, and we can't increase Y_ADD_STA to 1 to retain exactly the same field of view as that then breaks the first requirement. For the binned modes, they are worse off as 3118 is not a multiple of 4. Increase the main mode to 4208x3120 so that it is the same FOV as the binned modes, with Y_ADD_STA at 0. Fix Y_ADD_STA and Y_ADD_END for the binned modes so that they meet the sensor requirements. This does change the Bayer order as the default configuration is for H&V flips to be enabled, so readout is from Y_STA_END to Y_ADD_STA, and this patch has changed Y_STA_END. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The IMX258_FLL_* defines are unused. Remove them. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dom Cobley authored
This reverts commit fb577dc8.
-
Phil Elwell authored
Add NETFILTER_XTABLES_COMPAT=y, which is no longer enabled by default. And regenerate the defconfigs following the usual version bump churn. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
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>
-
Phil Elwell authored
The kernel needs to recognise the default BDADDRs used by the Bluetooth modems, so add a few more that we care about. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
The kernel Bluetooth framework understands that devices may not be programmed with valid Bluetooth addresses. It also has the ability to override a Bluetooth address with the value of the local-bd-address DT property, but it ignores the validity of the existing address when doing so. Add a new boolean property, fallback-bd-address, which indicates that the given local-bd-address property should only be used if the device does not already have a valid BDADDR. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-