- 20 Mar, 2023 13 commits
-
-
Dave Stevenson authored
The driver exposed V4L2_CID_HBLANK as a read only control to allow for exposure calculations and determination of the frame rate. Convert to a read/write control so that the frame rate can be controlled. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Dave Stevenson authored
Commit "98e0500e media: i2c: imx290: Add configurable link frequency and pixel rate" added support for the increased link frequencies on 2 data lanes, but didn't update the CSI timing registers in accordance with the datasheet. Use the specified settings. Signed-off-by:
-
Dave Stevenson authored
Commit "97589ad6 media: i2c: imx290: Add support for 2 data lanes" added support for running in two lane mode (instead of 4), but without changing the link frequency that resulted in a max of 30fps. Commit "98e0500e media: i2c: imx290: Add configurable link frequency and pixel rate" then doubled the link frequency when in 2 lane mode, but didn't undo the correction for running at only 30fps, just extending horizontal blanking instead. Remove the 30fps limit on 2 lane by correcting the register config in accordance with the datasheet for 60fps operation over 2 lanes. Signed-off-by:
-
Dave Stevenson authored
The datasheet lists the link frequency changes between 1080p and 720p modes. This is correct that the link frequency changes as measured on an oscilloscope. Link frequency is not necessarily the same as pixel rate. The datasheet gives standard configurations for 1080p and 720p modes at a number of frame rates. Looking at the 1080p mode it gives: HMAX = 0x898 = 2200 VMAX = 0x465 = 1125 2200 * 1125 * 60fps = 148.5MPix/s Looking at the 720p mode it gives: HMAX = 0xce4 = 3300 VMAX = 0x2ee = 750 3300 * 750 * 60fps = 148.5Mpix/s This driver currently scales the pixel rate proportionally to the link frequency, however the above shows that this is not the correct thing to do, and currently all frame rate and exposure calculations give incorrect results. Correctly report the pixel rate as being 148.5MPix/s under any mode. Signed-off-by:
-
Dave Stevenson authored
Any V4L2 subdevice that implements controls and declares V4L2_SUBDEV_FL_HAS_DEVNODE should also declare V4L2_SUBDEV_FL_HAS_EVENTS and implement subscribe_event and unsubscribe_event hooks. This driver didn't and would therefore fail v4l2-compliance testing. Add the relevant hooks. Signed-off-by:
-
Dave Stevenson authored
The colorspace fields were left untouched in imx290_set_fmt which lead to a v4l2-compliance failure. Signed-off-by:
-
Dave Stevenson authored
Fix up a couple of coding style issues regarding missing blank lines after declarations, double blank lines, and incorrect indentation. Signed-off-by:
-
Dave Stevenson authored
The IMX290 module is available as either mono or colour (Bayer). Update the driver so that it can advertise the correct mono formats instead of the colour ones. Signed-off-by:
-
Dave Stevenson authored
The IMX290 module is available as either monochrome or colour and the variant is not detectable at runtime. Add a new compatible string for the monochrome version, based on the full device name IMX290LLR. For consistency, add a new compatible string for the colour version based on the IMX290LQR full device name, and deprecate the current ambiguous compatible string. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Jacopo Mondi authored
The ov5647_read() functions calls i2c_master_send() and i2c_master_read() in sequence. However this leaves space for other clients to contend the bus and insert an unrelated transaction in between the two calls. Replace the two calls with a single i2c_transfer() one, that locks the bus in between the transactions. Signed-off-by:
Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by:
Tommaso Merciai <tomm.merciai@gmail.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Valentine Barshak authored
This adds V4L2_CID_TEST_PATTERN control support. Signed-off-by:
Valentine Barshak <valentine.barshak@cogentembedded.com> Signed-off-by:
-
Andy Shevchenko authored
No need to call fwnode_property_read_u32(dev_fwnode()), when we have already existing helper. So use it. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
-
Andy Shevchenko authored
Since we have a proper endianness converters for LE 24-bit data use them. Signed-off-by:
-
- 19 Mar, 2023 27 commits
-
-
Tomi Valkeinen authored
A common case with subdev routing is that on the subdevice just before the DMA engines (video nodes), no multiplexing is allowed on the source pads, as the DMA engine can only handle a single stream. In some other situations one might also want to do the same check on the sink side. Add new routing validation flags to check these: V4L2_SUBDEV_ROUTING_NO_SINK_MULTIPLEXING and V4L2_SUBDEV_ROUTING_NO_SOURCE_MULTIPLEXING. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by:
-
Tomi Valkeinen authored
V4L2_SUBDEV_ROUTING_NO_STREAM_MIX routing validation flag means that all routes from a sink pad must go to the same source pad and all routes going to the same source pad must originate from the same sink pad. This does not cover all use cases. For example, if a device routes all streams from a single sink pad to any of the source pads, but streams from multiple sink pads can go to the same source pad, the current flag is too restrictive. Split the flag into two parts, V4L2_SUBDEV_ROUTING_NO_SINK_STREAM_MIX and V4L2_SUBDEV_ROUTING_NO_SOURCE_STREAM_MIX, which add the restriction only on one side of the device. Together they mean the same as V4L2_SUBDEV_ROUTING_NO_STREAM_MIX. Signed-off-by:
-
Tomi Valkeinen authored
Route validation docs use the word 'may'. Change that to 'shall' for emphasis. Signed-off-by:
-
Benjamin Mugnier authored
tx_from_ep's for loop uses '5' as bound, while in fact it refers to the number of polarities. Replace it by VGXY61_NB_POLARITIES for factorization. Signed-off-by:
Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by:
-
Benjamin Mugnier authored
In case of error 'update_hdr' now goes through 'power_off' instead of returning, effectively shutting down the sensor. Signed-off-by:
-
Benjamin Mugnier authored
Previously the device detection was performed after patching. Move it right after the reset to make sure we have the correct sensor before trying to patch it. Signed-off-by:
-
Benjamin Mugnier authored
At this stage the default mode is unknown. This is done correctly by vgxy61_fill_framefmt right after. Signed-off-by:
-
Hans Verkuil authored
Support for clipping for overlays has been removed, update the documentation. Support for destructive overlay support has been removed as well, also update the documentation for this. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Hans Verkuil authored
Make sure this field is always 0 since destructive overlays are no longer supported. Signed-off-by:
-
Hans Verkuil authored
These two capabilities are no longer supported, so no longer define them when compiling the kernel. Signed-off-by:
-
Hans Verkuil authored
There are no longer any drivers that support clipping and bitmap support for the capture or output overlay interfaces, so drop this. Always set the bitmap, clips and clipcount fields to 0, and remove the compat32 support. Signed-off-by:
-
Hans Verkuil authored
This test driver is the only remaining driver still using the clipping and bitmap method. Drop support for this so we can remove this in the V4L2 API as well. Signed-off-by:
-
Hans Verkuil authored
Destructive overlay support (i.e. where the video frame is DMA-ed straight into a framebuffer) is effectively dead. It was a necessary evil in the early days when computers were not fast enough to copy SDTV video frames around, but today that's no longer a problem. It requires access to the framebuffer memory, which is a bad idea and very hard to do safely. In addition, in drm it is today almost impossible to get hold of the framebuffer address. So drop support for this. Signed-off-by:
-
Hans Verkuil authored
Destructive overlay support (i.e. where the video frame is DMA-ed straight into a framebuffer) is effectively dead. It was a necessary evil in the early days when computers were not fast enough to copy SDTV video frames around, but today that's no longer a problem. It requires access to the framebuffer memory, which is a bad idea and very hard to do safely. In addition, in drm it is today almost impossible to get hold of the framebuffer address. So drop support for this. Signed-off-by:
-
Hans Verkuil authored
Destructive overlay support (i.e. where the video frame is DMA-ed straight into a framebuffer) is effectively dead. It was a necessary evil in the early days when computers were not fast enough to copy SDTV video frames around, but today that's no longer a problem. It requires access to the framebuffer memory, which is a bad idea and very hard to do safely. In addition, in drm it is today almost impossible to get hold of the framebuffer address. So drop support for this. Signed-off-by:
-
Hans Verkuil authored
Destructive overlay support (i.e. where the video frame is DMA-ed straight into a framebuffer) is effectively dead. It was a necessary evil in the early days when computers were not fast enough to copy SDTV video frames around, but today that's no longer a problem. It requires access to the framebuffer memory, which is a bad idea and very hard to do safely. In addition, in drm it is today almost impossible to get hold of the framebuffer address. So drop support for this. Signed-off-by:
-
Hans Verkuil authored
This header is no longer used, drop it. Signed-off-by:
-
Hans Verkuil authored
These overlay-related functions no longer exist, so drop them from the header. Signed-off-by:
-
Hans Verkuil authored
Drop the unused struct v4l2_framebuffer fb_buf in struct dma2d_ctx. Signed-off-by:
-
Hans Verkuil authored
The documentation on how to create your own Raspberry Pi CEC debugger was a bit out of date. Update it to the Raspberry Pi 4B, drop the mention of the RTC and a link to a picture that no longer works. Also reorganize the text to make it easier to follow and change the pins to match the pins I use. Signed-off-by:
-
Daniel Lundberg Pedersen authored
p_s32 and p_s64 were added to the v4l2_ext_control struct, so these should have documentation as well. Signed-off-by:
Daniel Lundberg Pedersen <dlp@qtec.com> Signed-off-by:
-
Tom Rix authored
A rand config causes this link error vmlinux.o: In function `pvr2_dvb_create': (.text+0x8af1d2): undefined reference to `dvb_register_adapter' The rand config has CONFIG_VIDEO_PVRUSB2=y CONFIG_VIDEO_DEV=y CONFIG_DVB_CORE=m VIDEO_PVRUSB2 should also depend on DVB_CORE. Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Kevin Chiu authored
The Google Gladios/Lisbon device uses the same approach as the Google Brask which enables the HDMI CEC via the cros-ec-cec driver. Signed-off-by:
Kevin Chiu <kevin.chiu.17802@gmail.com> Signed-off-by:
-
Dan Carpenter authored
The buf[4] value comes from the user via ts_play(). It is a value in the u8 range. The final length we pass to av7110_ipack_instant_repack() is "len - (buf[4] + 1) - 4" so add a check to ensure that the length is not negative. It's not clear that passing a negative len value does anything bad necessarily, but it's not best practice. With the new bounds checking the "if (!len)" condition is no longer possible or required so remove that. Fixes: fd46d16d ("V4L/DVB (11759): dvb-ttpci: Add TS replay capability") Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
oushixiong authored
‘mtk8195_jpegenc_drvdata’ defined but not used [-Werror=unused-variable] Signed-off-by:
oushixiong <oushixiong@kylinos.cn> Signed-off-by:
-
Marek Vasut authored
Set allow_cache_hints to 1 for the vb2_queue capture queue in the STM32MP15xx DCMI V4L2 driver. This allows us to allocate buffers with the V4L2_MEMORY_FLAG_NON_COHERENT set. On STM32MP15xx SoCs, this enables caching for this memory, which improves performance when being read from CPU. This change should be safe from race conditions since videobuf2 already invalidates or flushes the appropriate cache lines in its prepare() and finish() methods. Tested on a STM32MP157F SoC. Resulted in 4x buffer access speedup. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
harperchen authored
When the driver calls tw68_risc_buffer() to prepare the buffer, the function call dma_alloc_coherent may fail, resulting in a empty buffer buf->cpu. Later when we free the buffer or access the buffer, null ptr deref is triggered. This bug is similar to the following one: https://git.linuxtv.org/media_stage.git/commit/?id=2b064d91440b33fba5b452f2d1b31f13ae911d71. We believe the bug can be also dynamically triggered from user side. Similarly, we fix this by checking the return value of tw68_risc_buffer() and the value of buf->cpu before buffer free. Signed-off-by:
harperchen <harperchen1110@gmail.com> Signed-off-by:
-
