- Jun 23, 2022
-
-
Phil Elwell authored
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
The ramoops overlay enables the preservation of crash logs across a reboot. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
The pstore and ramoops modules together allow kernel crash logs to be preserved across a reboot. They have beeb configued as built-ins (rather than as modules) because the crash dump facility becomes available much earlier in the boot sequence, and a lot of new-kernel crashes happen early. Note that if systemd-pstore is enabled then the dmesg captures will be moved to /var/lib/systemd/pstore/ after the reboot. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
Zero 2 W and CM4S are 64-bit-capable, so their DTBs should be buildable in the arm64 tree. See (misplaced) comment in https://github.com/raspberrypi/linux/issues/4857 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
Now that the rpivid-vid-decoder driver is the default, this overlay is no longer needed. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
The rpi-vid-decoder driver has been the preferred option for a while, so make it the default. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Lee Jackson authored
Added overlays for enabling Arducam 64MP and add the relevant information to the README. Signed-off-by: Lee Jackson <info@arducam.com>
-
Lee Jackson authored
Include the driver module for the Arducam 64MP. Signed-off-by: Lee Jackson <info@arducam.com>
-
Lee Jackson authored
This commit updates the arducam_64mp driver to adverise support for embedded data streams. The arducam_64mp sensor subdevice overloads the media pad to differentiate between image stream (pad 0) and embedded data stream (pad 1) when performing the v4l2_subdev_pad_ops functions. Signed-off-by: Lee Jackson <info@arducam.com>
-
Lee Jackson authored
Add a driver for the Arducam 64MP camera sensor. Whilst the sensor supports 2 or 4 CSI2 data lanes, this driver currently only supports 2 lanes. The following Bayer modes are currently available: 9152x6944 10-bit @ 2.7fps 4624x3472 10-bit (binned) @ 10fps 3840x2160 10-bit (cropped/binned) @ 20fps 2312x1736 10-bit (binned) @ 30fps 1920x1080 10-bit (cropped/binned) @ 60fps 1280x720 10-bit (cropped/binned) @ 120fps Signed-off-by: Lee Jackson <info@arducam.com>
-
Lee Jackson authored
Add YAML device tree binding for Arducam 64MP CMOS image sensor, and the relevant MAINTAINERS entries. Signed-off-by: Lee Jackson <info@arducam.com>
-
Dom Cobley authored
See: https://forum.libreelec.tv/thread/24783-tv-avr-turns-back-on-right-after-turning-them-off While the kernel provides a :D flag for assuming device is connected, it doesn't stop this function from being called and generating a cec_phys_addr_invalidate message when hotplug is deasserted. That message provokes a flurry of CEC messages which for many users results in the TV switching back on again and it's very hard to get it to stay switched off. It seems to only occur with an AVR and TV connected but has been observed across a number of manufacturers. The issue started with https://github.com/raspberrypi/linux/pull/4371 and this provides an optional way of getting back the old behaviour Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-
Dave Stevenson authored
s_selection allows the crop region of an uncompressed pixel format to be specified, but it wasn't passing the setting on to the firmware. Depending on call order this would potentially mean that the crop wasn't actioned. Set the port format on s_selection if we have a component created. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
In particular for the encoder where the CAPTURE format dictates the parameters given to the codec we need to be able to set the value passed as the crop_height for the compressed format. There's no crop available for cropped modes, so always set crop_height to the requested height. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Phil Elwell authored
GPIOs 14 and 15 are currently labelled TXD0 and RXD0, which matches comments on the schematic but 1) doesn't reflect their likely usage (i.e. UART1) and 2) clashes with GPIOs 32 and 33. Adopt the common naming for those two pins on BT-equipped Pis - TXD1 and RXD1. See: https://github.com/raspberrypi/linux/issues/5058 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
GPIOs 14 and 15 are currently labelled TXD0 and RXD0, which matches comments on the schematic but 1) doesn't reflect their likely usage (i.e. UART1) and 2) clashes with GPIOs 32 and 33. Adopt the common naming for those two pins on BT-equipped Pis - TXD1 and RXD1. See: https://github.com/raspberrypi/linux/issues/5058 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Dave Stevenson authored
The HVS_PIXEL_ORDER_xxx defines apply to specific HVS_PIXEL_FORMAT_xxx modes, so add comments to make this obvious. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
The hardware supports the 332 8bpp and 4:4:4:4 16bpp formats, but the table of supported formats didn't include them. Add them in. In theory they are supported for T-format as well as linear, but without a way to test them just add them as linear for now. Suggested-by: vrazzer <teamvraz@pipmail.net> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
pixel_order is used for the earlier versions of the HVS, so is redundant on the 10:10:10:2 and 10bit YUV formats that are only supported on HVS5. Remove the assignment from the table to avoid confusion. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
vc4_plane_mode_set for HVS5 was using pixel_order unless pixel_order_hvs5 was non-zero, except 0 is a valid value for the pixel_order. Specify pixel_order_hvs5 for all formats and remove the conditional. Reported-by: vrazzer <teamvraz@pipmail.net> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Dave Stevenson authored
Same as the xRGB8888 formats, HVS5 has managed to swap the colour channels for the xRGB1555 formats as well. Add the relevant config for pixel_order_hvs5. Reported-by: vrazzer <teamvraz@pipmail.net> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
-
Phil Elwell authored
BCM2711 shares an interrupt betweem 5 SPI interfaces (0, 3, 4, 5 & 6). Another interrupt is shared between SPI1, SPI2 and UART1, which also affects BCM2835/6/7. Acting on an interrupt intended for another interface ought to be harmless (although potentially inefficient), but it can cause this driver to crash - presumably because some critical state is not ready. Add a test to the spi-bcm2835 interrupt service routine that interrupts are enabled on this interface to avoid the crash and improve efficiency. Suggested by GitHub user boe-pi. See: https://github.com/raspberrypi/linux/issues/5048 Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Phil Elwell authored
Compute Module 2 is a CM3 with a 2836. The DTS file reflects that. Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Dom Cobley authored
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-
Dom Cobley authored
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-
Stephen Boyd authored
commit 73e2d827 upstream. A static key warning splat appears during early boot on arm64 systems that credit randomness from devicetrees that contain an "rng-seed" property. This is because setup_machine_fdt() is called before jump_label_init() during setup_arch(). Let's swap the order of these two calls so that jump labels are initialized before the devicetree is unflattened and the rng seed is credited. static_key_enable_cpuslocked(): static key '0xffffffe51c6fcfc0' used before call to jump_label_init() WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xb0/0xb8 Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0+ #224 44b43e377bfc84bc99bb5ab885ff694984ee09ff pstate: 600001c9 (nZCv dAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : static_key_enable_cpuslocked+0xb0/0xb8 lr : static_key_enable_cpuslocked+0xb0/0xb8 sp : ffffffe51c393cf0 x29: ffffffe51c393cf0 x28: 000000008185054c x27: 00000000f1042f10 x26: 0000000000000000 x25: 00000000f10302b2 x24: 0000002513200000 x23: 0000002513200000 x22: ffffffe51c1c9000 x21: fffffffdfdc00000 x20: ffffffe51c2f0831 x19: ffffffe51c6fcfc0 x18: 00000000ffff1020 x17: 00000000e1e2ac90 x16: 00000000000000e0 x15: ffffffe51b710708 x14: 0000000000000066 x13: 0000000000000018 x12: 0000000000000000 x11: 0000000000000000 x10: 00000000ffffffff x9 : 0000000000000000 x8 : 0000000000000000 x7 : 61632065726f6665 x6 : 6220646573752027 x5 : ffffffe51c641d25 x4 : ffffffe51c13142c x3 : ffff0a00ffffff05 x2 : 40000000ffffe003 x1 : 00000000000001c0 x0 : 0000000000000065 Call trace: static_key_enable_cpuslocked+0xb0/0xb8 static_key_enable+0x2c/0x40 crng_set_ready+0x24/0x30 execute_in_process_context+0x80/0x90 _credit_init_bits+0x100/0x154 add_bootloader_randomness+0x64/0x78 early_init_dt_scan_chosen+0x140/0x184 early_init_dt_scan_nodes+0x28/0x4c early_init_dt_scan+0x40/0x44 setup_machine_fdt+0x7c/0x120 setup_arch+0x74/0x1d8 start_kernel+0x84/0x44c __primary_switched+0xc0/0xc8 ---[ end trace 0000000000000000 ]--- random: crng init done Machine model: Google Lazor (rev1 - 2) with LTE Cc: Hsin-Yi Wang <hsinyi@chromium.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Jason A. Donenfeld <Jason@zx2c4.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Fixes: f5bda35f ("random: use static branch for crng_ready()") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Link: https://lore.kernel.org/r/20220602022109.780348-1-swboyd@chromium.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
-
David Plowman authored
The minimum number of exposure lines value (IMX477_EXPOSURE_MIN) was previously 20 but this is not correct. The datasheet is not completely explicit, however the new value of 4 has been tested with all the sensor modes supported by this driver, and matches the lowest exposure value of 114us that could be achieved wtih Raspberry Pi's legacy firmware driver. Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
-
Dag Bakke authored
Add a patch to make the sensor readable via the IIO/hwmon bridge. Signed-off-by: Dag Bakke <dag@bakke.com>
-
Phil Elwell authored
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
-
Dom Cobley authored
These are no reliable without overclocking. See: https://github.com/raspberrypi/linux/issues/5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-
Dom Cobley authored
We have been using the more expensive flush operations rather than invalidate and clean since kernel rpi-5.9.y These are exposed with: 52f14535 Re-expose some dmi APIs for use in VCSM But I believe that commit was dropped when (non-cma) vc-sm was dropped, and didn't get updated when the commit was restored Signed-off-by: Dom Cobley <popcornmix@gmail.com>
-
Chris Lawrence authored
-
Chris Lawrence authored
-
Naushir Patuck authored
Add the V4L2_CID_LINK_FREQ menu control for the imx296. Report a single value of 1188 Mhz for the link frequency. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
-
Naushir Patuck authored
In order to behave in a similar manner to the rolling shutter sensors, set the gain delay to 1 frame. This simplifies userland control of the gain value. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
-
Naushir Patuck authored
The exposure lines control limits are adjusted appropriately during any change to the vblank control. This allows accurate framerate and exposure adjustments from userland. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
-
Naushir Patuck authored
Add support for hflip and vflip controls. Adjust the mbus_code value reported based on the currently programmed flips. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
-
Naushir Patuck authored
The 1/4 resolution derived mode does not stream correctly, so remove it from the advertised mode list. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
-
Naushir Patuck authored
Add a 1.5ms delay after coming out of standby. Add a 2ms delay after going into or coming out of streaming state. All delay values have been deduced from the sensor datasheet. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
-
Naushir Patuck authored
Switch the Bayer ordering advertised by the device driver from BGGR to RGGB. Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
-