- 13 Dec, 2023 6 commits
-
-
Ming Qian authored
mutext_lock should not be called in condition of wait_event, otherwise, when CONFIG_DEBUG_ATOMIC_SLEEP is enabled, we may meet the following warning: do not call blocking ops when !TASK_RUNNING; state=2 WARNING: CPU: 5 PID: 741 at kernel/sched/core.c:9859 __might_sleep+0x80/0xa4 Hardware name: Freescale i.MX8QM MEK (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __might_sleep+0x80/0xa4 lr : __might_sleep+0x80/0xa4 sp : ffffffc0123738a0 x29: ffffffc0123738a0 x28: ffffffc009194c48 x27: ffffffc00bbc1050 x26: ffffff8814b282f0 x25: ffffff8814b280d0 x24: ffffff8814b28080 x23: 0000000000000001 x22: 0000000000000032 x21: ffffffc00bbc1000 x20: 000000000000011b x19: ffffffc009324670 x18: 00000000fffffffd x17: 30303c5b20746120 x16: 74657320323d6574 x15: 617473203b474e49 x14: 00058b5b8b9aa1f1 x13: ffffffc00903cda0 x12: 00000000d744fcc9 x11: 000000000000001c x10: 00000000000009a0 x9 : ffffffc0090201f4 x8 : ffffff8828245000 x7 : 0000000000000001 x6 : 0000000000000001 x5 : 00000000410fd080 x4 : 0000000000000002 x3 : ffffff8815aab4c8 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8828244600 Call trace: __might_sleep+0x80/0xa4 mutex_lock+0x2c/0x80 sync_session_response+0x110/0x310 vpu_session_send_cmd+0x18c/0x244 vpu_session_start+0x38/0x70 vdec_start_session+0x1b4/0x3e0 vpu_vb2_start_streaming+0xa0/0x1c4 vb2_start_streaming+0x74/0x160 vb2_core_qbuf+0x488/0x650 vb2_qbuf+0x9c/0x100 v4l2_m2m_qbuf+0x7c/0x224 v4l2_m2m_ioctl_qbuf+0x20/0x2c v4l_qbuf+0x50/0x6c __video_do_ioctl+0x174/0x3f0 video_usercopy+0x210/0x7cc video_ioctl2+0x20/0x30 v4l2_ioctl+0x48/0x6c we need to refine check_is_responsed() to remove the mutext_lock, each cmd has a monotonically increasing id, and cmds are executed sequentially, so we can check the id of the last reponsed cmd, then determine whether a command has been responded or not. Signed-off-by:
Ming Qian <ming.qian@nxp.com> CC: Xiaolei Wang <xiaolei.wang@windriver.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl>
-
Randy Dunlap authored
This driver uses the API that is provided by GENERIC_ALLOCATOR API, so select it to prevent build errors: riscv32-linux-ld: drivers/media/platform/chips-media/wave5/wave5-vpu.o: in function `.L37': wave5-vpu.c:(.text+0x468): undefined reference to `of_gen_pool_get' riscv32-linux-ld: drivers/media/platform/chips-media/wave5/wave5-vdi.o: in function `.L116': wave5-vdi.c:(.text+0xaac): undefined reference to `gen_pool_dma_alloc' riscv32-linux-ld: drivers/media/platform/chips-media/wave5/wave5-vdi.o: in function `wave5_vdi_free_sram': wave5-vdi.c:(.text+0xb60): undefined reference to `gen_pool_free_owner' Fixes: 9707a625 ("media: chips-media: wave5: Add the v4l2 layer") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Nas Chung <nas.chung@chipsnmedia.com> Cc: Jackson Lee <jackson.lee@chipsnmedia.com> Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: linux-media@vger.kernel.org Signed-off-by:
Sebastian Fricke <sebastian.fricke@collabora.com> Signed-off-by:
-
Mattijs Korpershoek authored
The display frame region information received from the vpu also contains the frame display index: info->index_frame_display. This index, being a s32, can be negative when a skip option is passed. In that case, its value is DECODED_IDX_FLAG_SKIP (-2). When disp_idx == -2, the following exception occurs: [ 1530.782246][ T1900] Hardware name: Texas Instruments AM62P5 SK (DT) [ 1530.788501][ T1900] pstate: a0400005 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1530.796144][ T1900] pc : wave5_vpu_dec_get_output_info+0x300/0x308 [wave5] [ 1530.803060][ T1900] lr : wave5_vpu_dec_get_output_info+0x80/0x308 [wave5] [ 1530.809873][ T1900] sp : ffffffc00b85bc00 [ 1530.813872][ T1900] x29: ffffffc00b85bc00 x28: 0000000000000000 x27: 0000000000000001 [ 1530.821695][ T1900] x26: 00000000fffffffd x25: 00000000ffffffff x24: ffffff8812820000 [ 1530.829516][ T1900] x23: ffffff88199f7840 x22: ffffff8873f5e000 x21: ffffffc00b85bc58 [ 1530.837336][ T1900] x20: 0000000000000000 x19: ffffff88199f7920 x18: ffffffc00a899030 [ 1530.845156][ T1900] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000198487 [ 1530.852975][ T1900] x14: ffffffc009f2b650 x13: 0000000000058016 x12: 0000000005000000 [ 1530.860795][ T1900] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 1530.868615][ T1900] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000004086 [ 1530.876434][ T1900] x5 : 0000000000000001 x4 : ffffffc001454b94 x3 : ffffffc001454d94 [ 1530.884256][ T1900] x2 : ffffffc00b8201d0 x1 : 0000000000000020 x0 : 0000000000000000 [ 1530.892087][ T1900] Call trace: [ 1530.895225][ T1900] wave5_vpu_dec_get_output_info+0x300/0x308 [wave5] [ 1530.901788][ T1900] wave5_vpu_dec_finish_decode+0x6c/0x3dc [wave5] [ 1530.908081][ T1900] wave5_vpu_irq_thread+0x140/0x168 [wave5] [ 1530.913856][ T1900] irq_thread_fn+0x44/0xa4 [ 1530.918154][ T1900] irq_thread+0x15c/0x288 [ 1530.922330][ T1900] kthread+0x104/0x1d4 [ 1530.926247][ T1900] ret_from_fork+0x10/0x20 [ 1530.930520][ T1900] Code: 2a1f03ea 2a1f03eb 35ffef2c 17ffff74 (d42aa240) [ 1530.937296][ T1900] ---[ end trace 0000000000000000 ]--- [ 1530.942596][ T1900] Kernel panic - not syncing: BRK handler: Fatal exception [ 1530.949629][ T1900] SMP: stopping secondary CPUs [ 1530.954244][ T1900] Kernel Offset: disabled [ 1530.958415][ T1900] CPU features: 0x00,00000000,00800184,0000421b [ 1530.964496][ T1900] Memory Limit: none Move the disp_info assignment after testing that the index is positive to avoid the exception. Fixes: 45d1a2b9 ("media: chips-media: wave5: Add vpuapi layer") Signed-off-by:
Mattijs Korpershoek <mkorpershoek@baylibre.com> Reviewed-by:
Nicolas Dufresne <nicolas.dufresne@collabora.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a dev_dbg message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Lukas Bulwahn authored
Commit 26dde1be ("media: chips-media: wave5: Add wave5 driver to maintainers file") adds the MAINTAINERS section WAVE5 VPU CODEC DRIVER referring to the 'cnm,wave5.yaml' media devicetree binding, but the file actually added in the commit de4b9f7e ("dt-bindings: media: wave5: add yaml devicetree bindings") is named 'cnm,wave521c.yaml'. Correct the file entry in WAVE5 VPU CODEC DRIVER. Fixes: 26dde1be ("media: chips-media: wave5: Add wave5 driver to maintainers file") Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by:
-
Dan Carpenter authored
We already verified that "ret" is zero a few lines earlier. Delete this duplicate check. Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
-
- 12 Dec, 2023 1 commit
-
-
Luca Weiss authored
Not all SC7280 devices ship with ChromeOS firmware. Other devices need PAS for image authentication. That requires the predefined virtual address ranges to be passed via scm calls. Define them to enable Venus on non-CrOS SC7280 devices. Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by:
Vikash Garodia <quic_vgarodia@quicinc.com> Signed-off-by:
Luca Weiss <luca.weiss@fairphone.com> Signed-off-by:
Stanimir Varbanov <stanimir.k.varbanov@gmail.com> Signed-off-by:
-
- 09 Dec, 2023 21 commits
-
-
Laurent Pinchart authored
Supported media bus codes on the resizer sink pad are identical to the ISP source pad. The .enum_mbus_code() handler thus delegates the enumeration to the ISP's operation. This is problematic for two reasons: - Format enumeration on the ISP source pad is dependent on the format configured on the ISP sink pad for the same subdev state (TRY or ACTIVE), while format enumeration on the resizer sink pad should return all formats supported by the resizer subdev, regardless of the ISP configuration. - Delegating the operation involves creating a fake v4l2_subdev_state on the stack to pass to the ISP .enum_mbus_code() handler. This gets in the way of evolution of both the ISP enumeration handler and, more generally, the V4L2 subdev state infrastructure. Fix those two issues by implementing format enumeration manually for the resizer. Link: https://lore.kernel.org/r/20231126020948.2700-1-laurent.pinchart@ideasonboard.comReviewed-by:
Paul Elder <paul.elder@ideasonboard.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org>
-
Paul Elder authored
Add a counter to debugfs to count the number of frame-end interrupts. Link: https://lore.kernel.org/r/20231201140433.2126011-4-paul.elder@ideasonboard.comSigned-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by:
-
Paul Elder authored
Add register dump for the ISP image stabilizer module to debugfs. This helps debugging issues related to digital zoom. Link: https://lore.kernel.org/r/20231201140433.2126011-3-paul.elder@ideasonboard.comSigned-off-by:
-
Paul Elder authored
Consolidate the wraparound fields in the memory interface interrupt status registers, so that it can be more succinctly expressed by taking the stream ID (main or self) as a parameter. Link: https://lore.kernel.org/r/20231201140433.2126011-2-paul.elder@ideasonboard.comSigned-off-by:
-
Tomi Valkeinen authored
In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the interrupts and then apparently assumes that the interrupt handler won't be running, and proceeds in the stop procedure. This is not the case, as the interrupt handler can already be running, which would lead to the ISP being disabled while the interrupt handler handling a captured frame. This brings up two issues: 1) the ISP could be powered off while the interrupt handler is still running and accessing registers, leading to board lockup, and 2) the interrupt handler code and the code that disables the streaming might do things that conflict. It is not clear to me if 2) causes a real issue, but 1) can be seen with a suitable delay (or printk in my case) in the interrupt handler, leading to board lockup. Link: https://lore.kernel.org/r/20231207-rkisp-irq-fix-v3-4-358a2c871a3c@ideasonboard.com Tested-by: Adam Ford <aford173@gmail.com> #imx8mp-beacon Signed-off-by:
-
Tomi Valkeinen authored
Store the IRQ lines used by the driver for easy access. These are needed in future patches which fix IRQ race issues. Link: https://lore.kernel.org/r/20231207-rkisp-irq-fix-v3-3-358a2c871a3c@ideasonboard.com Tested-by: Adam Ford <aford173@gmail.com> #imx8mp-beacon Signed-off-by:
-
Tomi Valkeinen authored
The IRQ handler rkisp1_isr() calls sub-handlers, all of which returns an irqreturn_t value, but rkisp1_isr() ignores those values and always returns IRQ_HANDLED. Fix this by collecting the return values, and returning IRQ_HANDLED or IRQ_NONE as appropriate. Link: https://lore.kernel.org/r/20231207-rkisp-irq-fix-v3-2-358a2c871a3c@ideasonboard.com Tested-by: Adam Ford <aford173@gmail.com> #imx8mp-beacon Signed-off-by:
-
Tomi Valkeinen authored
In all known platforms the ISP has dedicated IRQ lines, but for some reason the driver uses IRQF_SHARED. Supporting IRQF_SHARED properly requires handling interrupts even when our device is disabled, and the driver does not handle this. To avoid adding such code, and to be sure the driver won't accidentally be used in a platform with shared interrupts, let's drop the IRQF_SHARED flag. Link: https://lore.kernel.org/r/20231207-rkisp-irq-fix-v3-1-358a2c871a3c@ideasonboard.com Tested-by: Adam Ford <aford173@gmail.com> #imx8mp-beacon Signed-off-by:
-
Tomi Valkeinen authored
Add missing call to v4l2_subdev_cleanup() to fix memory leak. Link: https://lore.kernel.org/r/20231122-rkisp-fixes-v2-2-78bfb63cdcf8@ideasonboard.com Fixes: 2cce0a36 ("media: rkisp1: isp: Use V4L2 subdev active state") Reviewed-by:
Tommaso Merciai <tomm.merciai@gmail.com> Signed-off-by:
-
Tomi Valkeinen authored
Add missing calls to media_device_cleanup() to fix memory leak. Link: https://lore.kernel.org/r/20231122-rkisp-fixes-v2-1-78bfb63cdcf8@ideasonboard.com Fixes: d65dd852 ("media: staging: rkisp1: add Rockchip ISP1 base driver") Reviewed-by:
-
Mehdi Djait authored
The bus-type belongs to the endpoint's properties and should therefore be moved. Link: https://lore.kernel.org/r/20231115164407.99876-1-mehdi.djait@bootlin.com Fixes: 6a0eaa25 ("media: dt-bindings: media: rkisp1: Add port for parallel interface") Signed-off-by:
Mehdi Djait <mehdi.djait@bootlin.com> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Alexander Stein authored
The extended address registers are missing in the debug output register list. These are only available on 36-Bit DMA platforms. Due to the prolonged name, the output width has to be adjusted as well. Link: https://lore.kernel.org/r/20231207110918.1338524-1-alexander.stein@ew.tq-group.comSigned-off-by:
-
Tomi Valkeinen authored
The driver always enables the clocks at probe() and disables them only at remove(). It is not clear why the driver does this, as it supports runtime PM, and enables and disables the clocks in the runtime resume and suspend callbacks. Also, in the case runtime PM is not available, the driver calls the resume and suspend callbacks manually from probe() and remove(). Drop the unnecessary clock enable, thus enabling the clocks only when actually needed. Link: https://lore.kernel.org/r/20231122-imx-csis-v2-2-e44b8dc4cb66@ideasonboard.com Fixes: 7807063b ("media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7") Signed-off-by:
-
Tomi Valkeinen authored
The driver always calls mipi_csis_runtime_suspend() and mipi_csis_clk_disable() in remove(). This causes multiple WARNs from the kernel, as the clocks get disabled too many times. Fix the remove() to call mipi_csis_runtime_suspend() and mipi_csis_clk_disable() in a way that reverses what is done in probe(). Link: https://lore.kernel.org/r/20231122-imx-csis-v2-1-e44b8dc4cb66@ideasonboard.com Fixes: 7807063b ("media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7") Signed-off-by:
-
Laurent Pinchart authored
Include all the headers that the driver needs explicitly instead of relying on indirect inclusion. While at it, drop a few unneeded headers. Signed-off-by:
-
Ricardo Ribalda authored
The device does not implement the power line frequency control correctly. It is a UVC 1.5 device, but implements the control as a UVC 1.1 device. Add the corresponding control mapping override. Bus 003 Device 002: ID 2b7e:b752 SunplusIT Inc HD Camera Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.01 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x2b7e idProduct 0xb752 bcdDevice 0.04 iManufacturer 1 SunplusIT Inc iProduct 2 HD Camera iSerial 3 01.00.00 bNumConfigurations 1 Cc: Yunke Cao <yunkec@chromium.org> Signed-off-by:
Ricardo Ribalda <ribalda@chromium.org> Signed-off-by:
-
Laurent Pinchart authored
When selecting an alternate setting, the driver loops over all available alternate settings to find the one with the lowest bandwidth high enough for the selected format and resolution. While all alternate settings should have different packet sizes, some buggy devices report multiple alternate settings with the same size. The driver happens to pick the last one in this case. In theory this should work fine, but in real life we have device bugs. The Ali Corp. Newmine Camera (0402:8841) exposes four alternate settings with the same packet size. The first three seem to work fine, while selecting the last one results in lots of transmission errors. Switch to using the first best alternate setting when multiple are present. This should be safe (last famous words), as sniffing USB traffic with the faulty device shows that Windows 10 picks the first alternate setting, and devices are typically tested on Windows. Closes: https://lore.kernel.org/linux-media/Nh6D0WI--3-9@tutanota.com/Reported-by:
Karel Janda <karel1@tutanota.com> Suggested-by:
-
Ricardo Ribalda authored
The device does not implement the control properly. Fixes v4l2-compliance error: info: checking control 'Power Line Frequency' (0x00980918) fail: v4l2-test-controls.cpp(552): could not set valid menu item 3 Signed-off-by:
-
Hans Verkuil authored
The vb2 read support requests 1 buffer, leaving it to the driver to increase this number to something that works. Unfortunately, drivers do not deal with this reliably, and in fact this caused problems for the bttv driver and reading from /dev/vbiX, causing every other VBI frame to be all 0. Instead, request as the number of buffers whatever is the maximum of 2 and q->min_buffers_needed+1. In order to start streaming you need at least q->min_buffers_needed queued buffers, so add 1 buffer for processing. And if that field is 0, then choose 2 (again, one buffer is being filled while the other one is being processed). This certainly makes more sense than requesting just 1 buffer, and the VBI bttv support is now working again. It turns out that the old videobuf1 behavior of bttv was to allocate 8 (video) and 4 (vbi) buffers when used with read(). After the vb2 conversion that changed to 2 for both. With this patch it is 3, which is really all you need. Signed-off-by:
Dr. David Alan Gilbert <dave@treblig.org> Signed-off-by:
-
Hans Verkuil authored
The old (now removed) videobuf framework had an optional vbi hack where the sequence number of the frame counter was copied in the last 4 bytes of the buffer. This hack was active only for the read() interface (so not for streaming I/O), and it was enabled by bttv. This allowed applications that used read() for the VBI data to match it with the corresponding video frame. When bttv was converted to vb2 this hack was forgotten, but some old applications rely on this. So add this back, but this time in the bttv driver rather than in the vb2 framework. Signed-off-by:
-
Hans Verkuil authored
The start_streaming callback returned 0 or 1 instead of a proper error code. Fix that. Signed-off-by:
-
- 08 Dec, 2023 7 commits
-
-
Sakari Ailus authored
For the purpose of setting old non-pad based sub-device try format as a basis for VIDIOC_TRY_FMT implementation, there is no need to set the format in the sub-device state. Drop the assignment to the state, which would result in a NULL pointer dereference. Fixes: fd17e3a9 ("media: i2c: Use accessors for pad config 'try_*' fields") Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Sakari Ailus authored
For the purpose of setting old non-pad based sub-device try format as a basis for VIDIOC_TRY_FMT implementation, there is no need to set the format in the sub-device state. Drop the assignment to the state, which would result in a NULL pointer dereference. Fixes: fd17e3a9 ("media: i2c: Use accessors for pad config 'try_*' fields") Signed-off-by:
-
Sakari Ailus authored
For the purpose of setting old non-pad based sub-device try format as a basis for VIDIOC_TRY_FMT implementation, there is no need to set the format in the sub-device state. Drop the assignment to the state, which would result in a NULL pointer dereference. Fixes: fd17e3a9 ("media: i2c: Use accessors for pad config 'try_*' fields") Signed-off-by:
-
Sakari Ailus authored
For the purpose of setting old non-pad based sub-device try format as a basis for VIDIOC_TRY_FMT implementation, there is no need to set the format in the sub-device state. Drop the assignment to the state, which would result in a NULL pointer dereference. Fixes: fd17e3a9 ("media: i2c: Use accessors for pad config 'try_*' fields") Signed-off-by:
-
Sakari Ailus authored
For the purpose of setting old non-pad based sub-device try format as a basis for VIDIOC_TRY_FMT implementation, there is no need to set the format in the sub-device state. Drop the assignment to the state, which would result in a NULL pointer dereference. Fixes: fd17e3a9 ("media: i2c: Use accessors for pad config 'try_*' fields") Signed-off-by:
-
Sakari Ailus authored
For the purpose of setting old non-pad based sub-device try format as a basis for VIDIOC_TRY_FMT implementation, there is no need to set the format in the sub-device state. Drop the assignment to the state, which would result in a NULL pointer dereference. Fixes: fd17e3a9 ("media: i2c: Use accessors for pad config 'try_*' fields") Signed-off-by:
-
Sakari Ailus authored
Select V4L2_CCI_I2C Kconfig option which the CCS driver now depends on. Fixes: 52932211 ("media: ccs: Use V4L2 CCI for accessing sensor registers") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312060941.CYiHppAp-lkp@intel.com/Signed-off-by:
-
- 07 Dec, 2023 5 commits
-
-
Michael Tretter authored
Add support for the multi-planar variants of NV12. The RGA is now able to exchange DMABUFs with other devices that only support multi-planar NV12, for example the Hantro JPEG encoder. Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Signed-off-by:
-
Michael Tretter authored
Multi-planar formats may have multiple planes that must be handled and correctly mapped into a continuous buffer for the RGA by using the DMA descriptors. The plane offsets in the continuous mapping may now start at page boundaries and the previous calculation based on the frame sizes is only valid for planar buffers in a single memory. Therefore, the offsets must be detected and set while creating the mapping. Signed-off-by:
-
Michael Tretter authored
Switch to the multi-planar API, which allows to handle buffers with separate planes. The RGA driver doesn't expose multi-planar formats, yet. The existing contiguous planar formats can be used with the multi-planar API as well, but the multi-planar API is required for multi-planar formats. Signed-off-by:
-
Michael Tretter authored
Use the provided V4L2_TYPE_IS_{OUTPUT,CAPTURE} macros to check if the buffer or queue is OUTPUT or CAPTURE. The macros work also work for the _MPLANE buffer and queue types and make it easier to switch to the multi-planar API. Signed-off-by: -
Michael Tretter authored
The local variable allows to simplify the accessed to the format and makes it easier to change the type of the format. Signed-off-by:
-
