media: iris: Fix DMA coherency and frame interval enumeration issues - #900
media: iris: Fix DMA coherency and frame interval enumeration issues#900gouravk-qualcomm wants to merge 3 commits into
Conversation
…perty While testing with some higher resolution clips, the venus hardware triggers a fault due to wrong input data being received. Corruption was also observed in the captured output when the client dumped it to a file. On debugging, this was traced to the venus node not declaring dma-coherent. As a result, DMA buffers shared between the CPU and the venus video hardware/controller are not guaranteed to be I/O coherent: CPU writes to an input buffer can remain in CPU caches without being visible to the video hardware when it reads the same buffer, so the hardware receives input data that does not match what the CPU wrote. Likewise, on the capture path, data written by the video hardware to the output buffer may not be visible to the CPU, so the client reads stale or partial data, resulting in corruption. Add the dma-coherent property to the venus node so that DMA buffers shared between the CPU and the video hardware and controller remain coherent. Link: https://lore.kernel.org/all/20260801-iris-fixes-dma-pseq-fint-v1-1-aba0cb22f6ab@oss.qualcomm.com/ Fixes: 37613ae ("arm64: dts: qcom: sc7280: Add venus DT node") Cc: stable@vger.kernel.org Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
…nus node While testing with some higher resolution clips, the venus hardware triggers a fault due to wrong input data being received. Corruption was also observed in the captured output when the client dumped it to a file. On debugging, this was traced to the venus node not declaring dma-coherent. As a result, DMA buffers shared between the CPU and the venus video hardware/controller are not guaranteed to be I/O coherent: CPU writes to an input buffer can remain in CPU caches without being visible to the video hardware when it reads the same buffer, so the hardware receives input data that does not match what the CPU wrote. Likewise, on the capture path, data written by the video hardware to the output buffer may not be visible to the CPU, so the client reads stale or partial data, resulting in corruption. Add the dma-coherent property to the venus node so that DMA buffers shared between the CPU and the video hardware and controller remain coherent. Link: https://lore.kernel.org/all/20260801-iris-fixes-dma-pseq-fint-v1-2-aba0cb22f6ab@oss.qualcomm.com/ Fixes: 37613ae ("arm64: dts: qcom: sc7280: Add venus DT node") Cc: stable@vger.kernel.org Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
|
Merge Check Failed: CR Not Eligible for Merge CR 4515234 is not eligible for merge. The parent software image for kernel.qli.2.0 is not development complete. Entity: Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations. |
|
Merge Check Failed: CR Not Eligible for Merge CR 4446385 is not eligible for merge. The parent software image for kernel.qli.2.0 is not development complete. Entity: Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations. |
2dd820a to
989bfb9
Compare
|
Merge Check Failed: CR Not Eligible for Merge CR 4446385 is not eligible for merge. The parent software image for kernel.qli.2.0 is not development complete. Entity: Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations. |
… framerates iris_enum_frameintervals() advertised frame intervals using V4L2_FRMIVAL_TYPE_STEPWISE with step=1/MAXIMUM_FPS where MAXIMUM_FPS is 480. This caused client to enumerate only framerates of the form MAXIMUM_FPS/n (where n is a positive integer), restricting support to exact divisors of MAXIMUM_FPS (e.g., 480, 240, 160, 120, 96, 80, 60, 30, 24, 1). Framerates that are not exact divisors of MAXIMUM_FPS, such as 29 fps, 25 fps, were excluded from the enumerated list. There is no hardware restriction to framerates that are exact divisors of MAXIMUM_FPS. This caused GStreamer caps negotiation to fail with an "internal data stream error" when encoding content at such framerates. Fix this by using V4L2_FRMIVAL_TYPE_CONTINUOUS. With CONTINUOUS type, GStreamer creates a continuous framerate range [1, max_fps], allowing any integer framerate within the range to pass caps negotiation. The step field is set to 1/1 as required by the V4L2 specification for continuous frame intervals. Link: https://lore.kernel.org/all/20260801-iris-fixes-dma-pseq-fint-v1-4-aba0cb22f6ab@oss.qualcomm.com/ Fixes: a688243 ("media: iris: Add support for ENUM_FRAMESIZES/FRAMEINTERVALS for encoder") Cc: stable@vger.kernel.org Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
989bfb9 to
0c7f7ab
Compare
This series contains two independent fixes for the Qualcomm iris video driver:
DMA coherency fix for sc7280 venus node (
dt-bindings): The venus DT node was missingdma-coherent, so DMA buffers shared between the CPU and the venus hardware were not guaranteed I/O coherent. This caused hardware faults with high-resolution clips and data corruption in captured output. Addsdma-coherentto the binding and to the sc7280 venus node.Frame interval enumeration fix (
iris_vidc.c):iris_enum_frameintervals()usedV4L2_FRMIVAL_TYPE_STEPWISEwith a fixed step of1/480, which only allowed framerates that are exact divisors of 480 fps (480, 240, 120, 60, 30, ...). Non-divisor framerates like 29 or 25 fps were rejected, breaking GStreamer caps negotiation ("internal data stream error"). Switches toV4L2_FRMIVAL_TYPE_CONTINUOUSso any integer framerate in[1, max_fps]is accepted, as there's no hardware restriction to divisor framerates.CRs-fixed: 4515234,4446385