From: bod@kernel.org
To: Robert Foss <rfoss@kernel.org>, Todor Tomov <todor.too@gmail.com>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans Verkuil <hverkuil@kernel.org>,
Loic Poulain <loic.poulain@oss.qualcomm.com>,
Hans Verkuil <hverkuil+cisco@kernel.org>,
Gjorgji Rosikopulos <quic_grosikop@quicinc.com>,
Milen Mitkov <quic_mmitkov@quicinc.com>,
Depeng Shao <quic_depengs@quicinc.com>,
Yongsheng Li <quic_yon@quicinc.com>
Cc: linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, Bryan O'Donoghue <bod@kernel.org>,
stable@vger.kernel.org
Subject: [PATCH v2 0/5] media: qcom: camss: Fix RDI streaming for various CSIDs
Date: Tue, 07 Apr 2026 11:17:21 +0100 [thread overview]
Message-ID: <20260407-camss-rdi-fix-v2-0-66f6c600fcff@kernel.org> (raw)
V2:
- Implements Vlad's suggestion to update/include comment in loop
for the Fixes:
- Puts into the first patch Loic's suggesiton on VC+DT
- Link to v1: https://lore.kernel.org/r/20260406-camss-rdi-fix-v1-0-d3f8b12473d0@kernel.org
V1:
A serious bug has been copy/pasted from CSID 170 into various different
implementations of the CSID.
In simple terms we have a broken model of enabling virtual channels which
needs to be rewritten.
Taking the CSID 680 as an example. The CSID can output ports RDI0, RDI1,
RDI2 and PIX.
Each CSIPHY can connect to any of the CSIDs. Each CSID has four output
ports RDI0, RDI1, RDI2 and PIX. To get Bayer statistics going we need the
CSID to write on the PIX port.
Each of the RDI/PIX ports can process any valid virtual channel.
When adding virtual channels a spurious association was made between
virtual channel and the above mentioned ports. In simple terms
vfeN_rdi0 will always be fixed to VCO
vfeN_rdi1 will always be fixed to VC1
vfeN_rdi2 will always be fixed to VC2
vfeN_pix will always be fixed to VC3
What this means in practice is that it is impossible to route a sensor
driving VC:0 to the PIX/Bayer path in upstream.
Given we have now gotten a mutli-stream support in the kernel upstream we
should move to that API in CAMSS.
First up though is to remove the breakage of invalid VC constrains and make
those available to stable.
Here's the practical example on CSID680.
This works:
media-ctl --reset
media-ctl -v -d /dev/media0 -V '"ov08x40 '2-0036'":0[fmt:SGRBG10/3856x2416 field:none]'
media-ctl -V '"msm_csiphy4":0[fmt:SGRBG10/3856x2416]'
media-ctl -V '"msm_csid0":0[fmt:SGRBG10/3856x2416]'
media-ctl -V '"msm_vfe0_rdi0":0[fmt:SGRBG10/3856x2416]'
media-ctl -l '"msm_csiphy4":1->"msm_csid0":0[1]'
media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
yavta -B capture-mplane -c -I -n 5 -f SGRBG10P -s 3856x2416 -F /dev/video3
This doesn't:
media-ctl --reset
media-ctl -v -d /dev/media0 -V '"ov08x40 '2-0036'":0[fmt:SGRBG10/3856x2416 field:none]'
media-ctl -V '"msm_csiphy4":0[fmt:SGRBG10/3856x2416]'
media-ctl -V '"msm_csid0":0[fmt:SGRBG10/3856x2416]'
media-ctl -V '"msm_vfe0_rdi2":0[fmt:SGRBG10/3856x2416]'
media-ctl -l '"msm_csiphy4":1->"msm_csid0":0[1]'
media-ctl -l '"msm_csid0":3->"msm_vfe0_rdi2":0[1]'
yavta -B capture-mplane -c -I -n 5 -f SGRBG10P -s 3856x2416 -F /dev/video5
The PIX path - Bayer stats requires more work still but in simple terms it
needs a pipeline like this:
media-ctl --reset
media-ctl -v -d /dev/media0 -V '"ov08x40 '2-0036'":0[fmt:SGRBG10/3856x2416 field:none]'
media-ctl -V '"msm_csiphy4":0[fmt:SGRBG10/3856x2416]'
media-ctl -V '"msm_csid0":0[fmt:SGRBG10/3856x2416]'
media-ctl -V '"msm_vfe0_pix":0[fmt:SGRBG10/3856x2416]'
media-ctl -l '"msm_csiphy4":1->"msm_csid0":0[1]'
media-ctl -l '"msm_csid0":3->"msm_vfe0_pix":0[1]'
media-ctl -d /dev/media0 -p
yavta -B capture-mplane -c -I -n 5 -f SGRBG10P -s 3856x2416 -F /dev/video6
But that can't work with the above sensor because that sensor puts out VC0
not VC3.
Constraining the CSID/VFE ports to individual VCs was never the intention
and since we have v4l2 subdev streams we should align CAMSS to that which
will ultimately allow us to map any VC to any port without _requiring_ a VC
to enable a particular port.
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
---
Bryan O'Donoghue (5):
media: qcom: camss: Fix RDI streaming for CSID 680
media: qcom: camss: Fix RDI streaming for CSID 340
media: qcom: camss: Fix RDI streaming for CSID GEN2
media: qcom: camss: Fix RDI streaming for CSID GEN3
media: qcom: camss: csid: Rename en_vc to en_port
drivers/media/platform/qcom/camss/camss-csid-340.c | 18 ++++----
drivers/media/platform/qcom/camss/camss-csid-680.c | 30 ++++++-------
.../media/platform/qcom/camss/camss-csid-gen2.c | 51 +++++++++++-----------
.../media/platform/qcom/camss/camss-csid-gen3.c | 34 +++++++--------
drivers/media/platform/qcom/camss/camss-csid.c | 10 ++---
drivers/media/platform/qcom/camss/camss-csid.h | 2 +-
6 files changed, 74 insertions(+), 71 deletions(-)
---
base-commit: 2211e826bd69c041534093735241182013dde7bc
change-id: 20260406-camss-rdi-fix-ddd769490ec2
Best regards,
--
Bryan O'Donoghue <bod@kernel.org>
next reply other threads:[~2026-04-07 10:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 10:17 bod [this message]
2026-04-07 10:17 ` [PATCH v2 1/5] media: qcom: camss: Fix RDI streaming for CSID 680 bod
2026-04-07 10:17 ` [PATCH v2 2/5] media: qcom: camss: Fix RDI streaming for CSID 340 bod
2026-04-07 10:17 ` [PATCH v2 3/5] media: qcom: camss: Fix RDI streaming for CSID GEN2 bod
2026-04-07 10:17 ` [PATCH v2 4/5] media: qcom: camss: Fix RDI streaming for CSID GEN3 bod
2026-04-07 10:17 ` [PATCH v2 5/5] media: qcom: camss: csid: Rename en_vc to en_port bod
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260407-camss-rdi-fix-v2-0-66f6c600fcff@kernel.org \
--to=bod@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=hverkuil+cisco@kernel.org \
--cc=hverkuil@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=loic.poulain@oss.qualcomm.com \
--cc=mchehab@kernel.org \
--cc=quic_depengs@quicinc.com \
--cc=quic_grosikop@quicinc.com \
--cc=quic_mmitkov@quicinc.com \
--cc=quic_yon@quicinc.com \
--cc=rfoss@kernel.org \
--cc=stable@vger.kernel.org \
--cc=todor.too@gmail.com \
--cc=vladimir.zapolskiy@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox