summaryrefslogtreecommitdiff
path: root/drivers/media
AgeCommit message (Collapse)AuthorFilesLines
2023-03-20media: i2c: imx290: Add the error code to logs in start_streamingDave Stevenson1-6/+6
imx290_start_streaming logs what failed, but not the error code from that function. Add it into the log message. 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>
2023-03-20media: i2c: imx290: Add support for H & V FlipsDave Stevenson1-5/+46
The sensor supports H & V flips, so add the relevant hooks for V4L2_CID_HFLIP and V4L2_CID_VFLIP to configure them. Note that the Bayer order is maintained as the readout area shifts by 1 pixel in the appropriate direction (note the comment about the top margin being 8 pixels whilst the bottom margin is 9). The V4L2_SEL_TGT_CROP region is therefore adjusted appropriately. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.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>
2023-03-20media: i2c: imx290: Add support for 74.25MHz external clockDave Stevenson1-16/+116
The sensor supports either a 37.125 or 74.25MHz external, but the driver only supported 37.125MHz. Add the relevant register configuration for either clock frequency option. 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>
2023-03-20media: i2c: imx290: Remove duplicated write to IMX290_CTRL_07Dave Stevenson1-1/+0
IMX290_CTRL_07 was written from both imx290_global_init_settings and imx290_1080p_settings and imx290_720p_settings. Remove it from imx290_global_init_settings as the setting varies based on the mode. 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>
2023-03-20media: i2c: imx290: VMAX is mode dependentDave Stevenson1-3/+6
The default VMAX for 60fps in 720p mode is 750 according to the datasheet, however the driver always left it at 1125 thereby stopping 60fps being achieved. Make VMAX (and therefore V4L2_CID_VBLANK) mode dependent so that 720p60 can be achieved. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.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>
2023-03-20media: i2c: imx290: Convert V4L2_CID_VBLANK to read/writeDave Stevenson1-10/+48
The driver exposed V4L2_CID_VBLANK 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. V4L2_CID_VBLANK also sets the limits for the exposure control, therefore exposure ranges have to be updated when vblank changes (either via s_ctrl, or via changing mode). Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: i2c: imx290: Convert V4L2_CID_HBLANK to read/writeDave Stevenson1-14/+19
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>
2023-03-20media: i2c: imx290: Use CSI timings as per datasheetDave Stevenson1-20/+106
Commit "98e0500eadb7 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 <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>
2023-03-20media: i2c: imx290: Support 60fps in 2 lane operationDave Stevenson1-14/+3
Commit "97589ad61c73 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 "98e0500eadb7 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 <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>
2023-03-20media: i2c: imx290: Fix the pixel rate at 148.5Mpix/sDave Stevenson1-11/+5
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 <dave.stevenson@raspberrypi.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>
2023-03-20media: i2c: imx290: Add V4L2_SUBDEV_FL_HAS_EVENTS and subscribe hooksDave Stevenson1-1/+9
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 <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>
2023-03-20media: i2c: imx290: Set the colorspace fields in the formatDave Stevenson1-0/+4
The colorspace fields were left untouched in imx290_set_fmt which lead to a v4l2-compliance failure. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.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>
2023-03-20media: i2c: imx290: Match kernel coding style on whitespaceDave Stevenson1-5/+4
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 <dave.stevenson@raspberrypi.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>
2023-03-20media: i2c: imx290: Add support for the mono sensor variantDave Stevenson1-14/+61
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 <dave.stevenson@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-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>
2023-03-20media: i2c: ov5647: Use bus-locked i2c_transfer()Jacopo Mondi1-12/+18
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: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: i2c: ov5647: Add test pattern controlValentine Barshak1-1/+25
This adds V4L2_CID_TEST_PATTERN control support. Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Tommaso Merciai <tomm.merciai@gmail.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: i2c: imx290: Use device_property_read_u32() directlyAndy Shevchenko1-2/+2
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: 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>
2023-03-20media: i2c: imx290: Make use of get_unaligned_le24(), put_unaligned_le24()Andy Shevchenko1-2/+7
Since we have a proper endianness converters for LE 24-bit data use them. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-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>
2023-03-20media: subdev: Add V4L2_SUBDEV_ROUTING_NO_MULTIPLEXINGTomi Valkeinen1-3/+33
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: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: subdev: Split V4L2_SUBDEV_ROUTING_NO_STREAM_MIXTomi Valkeinen1-4/+11
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 <tomi.valkeinen@ideasonboard.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: subdev: Use 'shall' instead of 'may' in route validationTomi Valkeinen1-1/+1
Route validation docs use the word 'may'. Change that to 'shall' for emphasis. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: i2c: st-vgxy61: Use VGXY61_NB_POLARITIES instead of hardcoded value ↵Benjamin Mugnier1-1/+1
in tx_from_ep 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: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: i2c: st-vgxy61: Fix control flow error on probeBenjamin Mugnier1-4/+4
In case of error 'update_hdr' now goes through 'power_off' instead of returning, effectively shutting down the sensor. Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: i2c: st-vgxy61: Move 'detect' call to 'power_on'Benjamin Mugnier1-6/+6
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 <benjamin.mugnier@foss.st.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: i2c: st-vgxy61: Remove duplicate default mode set on probeBenjamin Mugnier1-1/+0
At this stage the default mode is unknown. This is done correctly by vgxy61_fill_framefmt right after. Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: v4l2-core: zero field base in struct v4l2_framebufferHans Verkuil2-7/+12
Make sure this field is always 0 since destructive overlays are no longer supported. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: v4l2-core: drop v4l2_window clipping and bitmap supportHans Verkuil2-118/+25
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 <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: vivid: drop bitmap and clipping output overlay supportHans Verkuil4-103/+1
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 <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: vivid: drop overlay supportHans Verkuil5-438/+6
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 <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: bttv: drop overlay supportHans Verkuil7-763/+11
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 <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: saa7134: drop overlay supportHans Verkuil4-453/+4
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 <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: saa7146: drop overlay supportHans Verkuil3-642/+6
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 <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: common: btcx-risc.h: drop obsolete headerHans Verkuil1-29/+0
This header is no longer used, drop it. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: zoran: drop two obsolete prototypes from zoran_device.hHans Verkuil1-2/+0
These overlay-related functions no longer exist, so drop them from the header. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: stm32: dma2d: remove unused fb_bufHans Verkuil1-2/+0
Drop the unused struct v4l2_framebuffer fb_buf in struct dma2d_ctx. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> CC: Hugues Fruchet <hugues.fruchet@foss.st.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: pvrusb2: VIDEO_PVRUSB2 depends on DVB_CORE to use dvb_* symbolsTom Rix1-1/+1
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: platform: cros-ec: Add Gladios/Lisbon to the match tableKevin Chiu1-0/+4
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: mtk-jpegenc: Fix a compilation issueoushixiong1-1/+1
‘mtk8195_jpegenc_drvdata’ defined but not used [-Werror=unused-variable] Signed-off-by: oushixiong <oushixiong@kylinos.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: stm32-dcmi: Enable incoherent buffer allocationMarek Vasut1-0/+1
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: pci: tw68: Fix null-ptr-deref bug in buf prepare and finishharperchen1-7/+9
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: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: platform: via: Handle error for dma_set_maskharperchen1-1/+3
As the potential failure of the dma_set_mask(), we fix this bug by checking its return value and performing proper error handling. Signed-off-by: harperchen <harperchen1110@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: cx23885: Fix a null-ptr-deref bug in buffer_prepare() and buffer_finish()harperchen2-7/+10
When the driver calls cx23885_risc_buffer() to prepare the buffer, the function call dma_alloc_coherent may fail, resulting in a empty buffer risc->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 cx23885_risc_buffer() and the value of risc->cpu before buffer free. Signed-off-by: harperchen <harperchen1110@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: amphion: decoder implement display delay enableMing Qian3-2/+37
amphion vpu support a low latency mode, when V4L2_CID_MPEG_VIDEO_DEC_DISPLAY_DELAY_ENABLE is enabled, decoder can display frame immediately after it's decoded. Only h264 is support yet. Fixes: 6de8d628df6e ("media: amphion: add v4l2 m2m vpu decoder stateful driver") Signed-off-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: platform: cros-ec: Add aurash to the match tableZoey Wu1-0/+2
The Google aurash device uses the same approach as the Google Brask which enables the HDMI CEC via the cros-ec-cec driver. Signed-off-by: Zoey Wu <zoey_wu@wistron.corp-partner.google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: platform: mtk-mdp3: Add missing check and free for ida_allocJiasheng Jiang1-1/+7
Add the check for the return value of the ida_alloc in order to avoid NULL pointer dereference. Moreover, free allocated "ctx->id" if mdp_m2m_open fails later in order to avoid memory leak. Fixes: 61890ccaefaf ("media: platform: mtk-mdp3: add MediaTek MDP3 driver") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: platform: stm32: use devm_platform_get_and_ioremap_resource()Ye Xingchen1-4/+1
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by: Ye Xingchen <ye.xingchen@zte.com.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: platform: renesas: use devm_platform_get_and_ioremap_resource()Ye Xingchen1-4/+1
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by: Ye Xingchen <ye.xingchen@zte.com.cn> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: dw100: use devm_platform_get_and_ioremap_resource()Ye Xingchen1-3/+1
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Signed-off-by: Ye Xingchen <ye.xingchen@zte.com.cn> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: bdisp: Add missing check for create_workqueueJiasheng Jiang1-0/+2
Add the check for the return value of the create_workqueue in order to avoid NULL pointer dereference. Fixes: 28ffeebbb7bd ("[media] bdisp: 2D blitter driver using v4l2 mem2mem framework") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2023-03-20media: imx-jpeg: Bounds check sizeimage accessKees Cook1-0/+5
The call of mxc_jpeg_get_plane_size() from mxc_jpeg_dec_irq() sets plane_no argument to 1. The compiler sees that it's possible to end up with an access beyond the bounds of sizeimage, if mem_planes was too large: if (plane_no >= fmt->mem_planes) // mem_planes = 2+ return 0; if (fmt->mem_planes == fmt->comp_planes) // comp_planes != mem_planes return q_data->sizeimage[plane_no]; if (plane_no < fmt->mem_planes - 1) // mem_planes = 2 return q_data->sizeimage[plane_no]; comp_planes == 0 or 1 is safe. comp_planes > 2 would be out of bounds. (This isn't currently possible given the contents of mxc_formats, though.) Silence the warning by bounds checking comp_planes for future robustness. Seen with GCC 13: In function 'mxc_jpeg_get_plane_size', inlined from 'mxc_jpeg_dec_irq' at ../drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c:729:14: ../drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c:641:42: warning: array subscript 2 is above array bounds of 'u32[2]' {aka 'unsigned int[2]'} [-Warray-bounds=] 641 | size += q_data->sizeimage[i]; | ~~~~~~~~~~~~~~~~~^~~ In file included from ../drivers/media/platform/nxp/imx-jpeg/mxc-jpeg-hw.h:112, from ../drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c:63: ../drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.h: In function 'mxc_jpeg_dec_irq': ../drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.h:84:41: note: while referencing 'sizeimage' 84 | u32 sizeimage[MXC_JPEG_MAX_PLANES]; | ^~~~~~~~~ Cc: Mirela Rabulea <mirela.rabulea@nxp.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-30 05:12:54 +0300