-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Enable RTC UIE emulation to avoid error in hwclock output #5057
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The ISP can do H & V flips whilst resizing or converting the image, so expose that via V4L2_CID_[H|V]FLIP. Signed-off-by: Dave Stevenson <[email protected]>
The read and write functions did not use the correct pointer offset when dealing with an odd number of bytes after a DMA transfer. Also, only handle the remaining odd bytes if the DMA transfer completed successfully. Submitted-by: @madimario (GitHub) Signed-off-by: Phil Elwell <[email protected]>
Add YAML device tree binding for IMX519 CMOS image sensor, and the relevant MAINTAINERS entries. Signed-off-by: Lee Jackson <[email protected]>
Adds a driver for the 16MPix IMX519 CSI2 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: 4656x3496 10-bit @ 10fps 3840x2160 10-bit (cropped) @ 21fps 2328x1748 10-bit (binned) @ 30fps 1920x1080 10-bit (cropped/binned) @ 60fps 1280x720 10-bit (cropped/binned) @ 120fps Signed-off-by: Lee Jackson <[email protected]>
This commit updates the imx519 driver to adverise support for embedded data streams. The imx519 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 <[email protected]>
For cases where spare PWM outputs are available, but are desired to be addressed a standard outputs instead. Wraps a PWM channel as a new GPIO chip with the one output. Signed-off-by: Dave Stevenson <[email protected]>
Tested on Raspberry Pi running libcamera. Signed-off-by: David Plowman <[email protected]>
Tested on Raspberry Pi running libcamera. Signed-off-by: David Plowman <[email protected]>
Tested on Raspberry Pi running libcamera. Signed-off-by: David Plowman <[email protected]>
Tested on Raspberry Pi running libcamera. Signed-off-by: David Plowman <[email protected]>
Tested on Raspberry Pi running libcamera. Signed-off-by: David Plowman <[email protected]>
… space RAW color spaces are more usually reported as having full range quantization. Tested using libcamera. Signed-off-by: David Plowman <[email protected]>
The driver was making big assumptions about the source device using pad 0 and 1, which doesn't follow for more complex devices where Unicam's source device may be a sink device for something else. Read the pad numbers through media controller, and reference them appropriately. Signed-off-by: Dave Stevenson <[email protected]>
Adds Media Controller API support for more complex pipelines. libcamera is about to switch to using this mechanism for configuring sensors. This can be enabled by either a module parameter, or device tree. Various functions have been moved to group video-centric and mc-centric functions together. Based on a similar conversion done to ti-vpe. Signed-off-by: Dave Stevenson <[email protected]> media: bcm2835-unicam: Fixup for 5.18 and new get_mbus_config struct The number of active CSI2 data lanes has moved within the struct v4l2_mbus_config used by the get_mbus_config API call. Update the driver to match the changes in mainline. Signed-off-by: Dave Stevenson <[email protected]>
Signed-off-by: Gergo Koteles <[email protected]>
Signed-off-by: Gergo Koteles <[email protected]>
trigger_mode == 0 (default) => no effect / no registers written trigger_mode == 1 => source trigger_mode == 2 => sink This can be set e.g. in /boot/cmdline.txt as imx477.trigger_mode=N Signed-off-by: Jonas Jacob <[email protected]>
The support for this format by firmware is very limited and won't be faster than the arm. Signed-off-by: Dom Cobley <[email protected]>
An unwanted side effect of enabling the BRCMDBG config setting is redefining brcmf_info to be brcmf_err. This can be alarming to users and makes it harder to spot real errors, so don't do it. See: #4663 Signed-off-by: Phil Elwell <[email protected]>
Add the ability to load the names of alternative firmwares from the Device Tree node. This permits separate firmwares for 43436s and 43438 and allows downstream firmwares to coexist with upstream. Signed-off-by: Phil Elwell <[email protected]>
It is important to reinitialise the firmware array pointers to protect against the case that the brcmfmac driver is reprobed without first being unloaded. The potential hazard was noticed while investigating raspberrypi/firmware#1644 . Signed-off-by: Phil Elwell <[email protected]>
Add these missing V4L2 controls. Tested binned and full resolution modes in all four orientations using Raspberry Pi running libcamera. Signed-off-by: David Plowman <[email protected]>
Add a second (identical) set of device nodes to allow concurrent use of the ISP hardware by another user. This change effectively creates a second state structure (struct bcm2835_isp_dev) to maintain independent state for the second user. Node and media entity names are appened with the instance index appropriately. Further users can be added by changing the BCM2835_ISP_NUM_INSTANCES define. Signed-off-by: Naushir Patuck <[email protected]>
Fix a possible division by 0 bug when setting up the mmal port for the stats port. Signed-off-by: Naushir Patuck <[email protected]>
Following #4704. This is necessary to set up quantization for variable bitrate to avoid video flickering.
As happens occasionally, an upstream change has once again prevented spidev from being loaded via Device Tree. We now need "spidev" to be included in the new spi_device_id list, otherwise although the spidev driver gets loaded no /dev/spidev*.* entries will appear. Signed-off-by: Phil Elwell <[email protected]>
We are currently disabling PM in v3d because it causes a variety of errors: [ 13.521599] v3d fec00000.v3d: TLB clear wait idle pre-wait failed [ 13.621884] v3d fec00000.v3d: TLB clear wait idle failed [ 13.621906] v3d fec00000.v3d: MMU flush timeout pm_runtime_get_sync and friends can return -EACCES if disable_depth is non-zero, indicating that runtime PM is disabled (or not yet enabled). This is not an error, and can be ignored (although we should probably get to the bottom of the errors and re-enable it at some point). Signed-off-by: Phil Elwell <[email protected]>
Remove min_buffers_needed=1 from src queue init. Src buffers are bound to media requests therefore this setting is not needed and generates a WARN in kernel 5.16. Signed-off-by: John Cox <[email protected]>
The ft5x06 is unreliable in sending touch up events, so some touch IDs can become stuck in the detected state. Ensure that IDs that are unreported by the controller are released. Signed-off-by: Dave Stevenson <[email protected]>
Matching #4419, the ISP block (which is also used on the input of the encoder, and output of the decoder) needs the base address of all planes to be aligned to multiples of 32. This includes the chroma planes of YUV420 and YVU420. If the height is only a multiple of 2 (not 4), then you get an odd number of lines in the second plane, which means the 3rd plane starts at a multiple of bytesperline/2. Set the minimum bytesperline alignment to 64 for those formats so that the plane alignment is always right. Signed-off-by: Dave Stevenson <[email protected]>
The 1/4 resolution derived mode does not stream correctly, so remove it from the advertised mode list. Signed-off-by: Naushir Patuck <[email protected]>
Add support for hflip and vflip controls. Adjust the mbus_code value reported based on the currently programmed flips. Signed-off-by: Naushir Patuck <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <[email protected]>
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 <[email protected]>
commit 73e2d82 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 <[email protected]> Cc: Douglas Anderson <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Jason A. Donenfeld <[email protected]> Cc: Dominik Brodowski <[email protected]> Fixes: f5bda35 ("random: use static branch for crng_ready()") Signed-off-by: Stephen Boyd <[email protected]> Reviewed-by: Jason A. Donenfeld <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
Signed-off-by: Dom Cobley <[email protected]>
Signed-off-by: Dom Cobley <[email protected]>
Compute Module 2 is a CM3 with a 2836. The DTS file reflects that. Signed-off-by: Phil Elwell <[email protected]>
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: #5048 Signed-off-by: Phil Elwell <[email protected]>
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 <[email protected]> Signed-off-by: Dave Stevenson <[email protected]>
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 <[email protected]> Signed-off-by: Dave Stevenson <[email protected]>
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 <[email protected]>
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 <[email protected]> Signed-off-by: Dave Stevenson <[email protected]>
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 <[email protected]>
The Kconfig entry says:
That doesn't sound very appealing. Are you certain this won't end penalising users who don't care about the interrupt? |
It will always be a trade-off, but as I've seen so many problems and errors messages with many different RTCs, it would be worthwhile, from my perspective; why not test it more widely with 5.18 first? – Here it works great without negative side-effects or performance issues since quite some months... |
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: #5058 Signed-off-by: Phil Elwell <[email protected]>
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: #5058 Signed-off-by: Phil Elwell <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 #4371 and this provides an optional way of getting back the old behaviour Signed-off-by: Dom Cobley <[email protected]>
Solves #3282