linux-kernel - [PATCH 0/1] media: camss: fix VFE bpl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20230518215235.1668871-1-andrey.konovalov@linaro.org>
Date:   Fri, 19 May 2023 00:52:34 +0300
From:   Andrey Konovalov <andrey.konovalov@...aro.org>
To:     rfoss@...nel.org, todor.too@...il.com, bryan.odonoghue@...aro.org
Cc:     agross@...nel.org, andersson@...nel.org, konrad.dybcio@...aro.org,
        mchehab@...nel.org, linux-media@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Andrey Konovalov <andrey.konovalov@...aro.org>
Subject: [PATCH 0/1] media: camss: fix VFE bpl_alignment for sdm845 and sm8250

I tried to capture an image from SGRBG10_1X10/3280x2464 camera sensor on db845c
board (sdm845), and from SRGGB10_1X10/3280x2464 camera sensor on RB5 (qrb5165 /
sm8250). The captured frames contained incorrect image.

These formats are 4100 bytes per line. 4100 aligned by 8 is 4104. 4100 aligned
by 16 is 4112.

After looking at the frame data captured with the current bpl_alignment value
of 8 bytes, it becomes clear that the lines are not 4104 bytes long, but are
actually 4112 bytes long. That is the current bpl_alignment value is set
incorrectly.

With bpl_alignment set to 8 bytes (the value currently used by the camss
driver):
* on db845c capturing may stall after a few frames are captured OK
* the captured frames are corrupted:
  As the actual stride is 8 bytes more than expected, the 2nd line
  has 8 bytes from the 1st line tail in the beginning, and the actual
  data in the 2nd line are offset by these 8 bytes; the 3d line data
  are offset by 16 bytes etc. When the offset reaches the line length,
  one line starts with 0 offset again, the next line gets 8-byte offset
  etc. This results in "chainsaw shift" of lines in the captured image
  and messed up colours. Also a small part from the end of the actual frame
  (8 bytes times frame height) is not captured as it doesn't fit into the
  allocated buffer.
* "arm-smmu: Unhandled context fault" messages in dmesg output

Changing bpl_alignment to 16 bytes fixed all these issues:
* no capture stalls on db845c
* correct image in the captured frames
* "arm-smmu: Unhandled context fault" messages are gone

I've also used the patch
https://lore.kernel.org/lkml/20230503075340.45755-1-y.oudjana@protonmail.com/
as without it the camss driver is broken in media_tree - yavta fails with
error 22 (invalid argument).

Here is an example console log from db845c with bpl_alignment=8 (stride 4104):
-----8<-----
$ yavta -B capture-mplane --capture=5 -n 5 -I -f SGRBG10P -s 3280x2464 --file=ov8856-SGRBG10-3280x2464-#.bin /dev/video6
Device /dev/video6 opened.
Device `Qualcomm Camera Subsystem' on `platform:acb3000.camss' (driver 'qcom-camss') supports video, capture, with mplanes.
Video format set: SGRBG10P (41416770) 3280x2464 field none, 1 planes:
 * Stride 4104, buffer size 10112256
Video format: SGRBG10P (41416770) 3280x2464 field none, 1 planes:
 * Stride 4104, buffer size 10112256
5 buffers requested.
length: 1 offset: 4098861152 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0xffffa305b000. 
<snip>
length: 1 offset: 4098861152 timestamp type/source: mono/EoF
Buffer 4/0 mapped at address 0xffffa09c7000.
0 (0) [-] none 0 10112256 B 818.593063 818.594398 8.942 fps ts mono/EoF
1 (1) [-] none 1 10112256 B 818.661186 818.662596 14.679 fps ts mono/EoF
2 (2) [-] none 2 10112256 B 818.727812 818.729342 15.009 fps ts mono/EoF
3 (3) [-] none 3 10112256 B 818.781710 818.794871 18.554 fps ts mono/EoF
<stalls after 4 of 5 frames captured>
^C
$
-----8<-----

The corresponding part of dmesg output:
-----8<-----
[  658.608956] arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0xff9a5000, fsynr=0x3c0013, cbfrsynra=0x810, cb=14
[  658.676875] arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0xfd9a5000, fsynr=0x3c0013, cbfrsynra=0x810, cb=14
[  658.743863] arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0xfc9a5000, fsynr=0x3c0013, cbfrsynra=0x810, cb=14
[  658.810016] arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0xfb9a5000, fsynr=0x3c0013, cbfrsynra=0x810, cb=14
### several seconds after Ctrl-C is pressed at the console:
[  670.950533] qcom-camss acb3000.camss: VFE idle timeout - resetting
-----8<-----

Andrey Konovalov (1):
  media: camss: set VFE bpl_alignment to 16 for sdm845 and sm8250

 drivers/media/platform/qcom/camss/camss-vfe.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
2.34.1