From: sashiko-bot@kernel.org
To: "Wenmeng Liu" <wenmeng.liu@oss.qualcomm.com>
Cc: linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
robh@kernel.org, conor+dt@kernel.org, media-ci@linuxtv.org,
vkoul@kernel.org, neil.armstrong@linaro.org, olteanv@gmail.com
Subject: Re: [PATCH v7 10/23] media: qcom: camss: csid: Add support for CSID 980
Date: Sat, 14 Nov 2026 11:55:48 +0000 [thread overview]
Message-ID: <sashiko-outbox-214437@kernel.org> (raw)
In-Reply-To: <20261114-add-support-for-camss-on-sm8750-v7-10-8ff2a11835f6@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [High] media: qcom: camss: wrong dt_id calculation in
__csid_configure_rdi_stream()
- [Medium] media: qcom: camss: misplaced lane_cnt fallback in
camss-csid-980.c
- [Medium] media: qcom: camss: race on csid->reg_update and addr_update
in csid-980
--
commit ad1ff7fa26120bcd2005c8cf69d816599d94898f
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: csid: Add support for CSID 980
This commit adds the CSID 980 hardware operations driver and populates
the SM8750 CSID subdevice resource definitions.
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-980.c b/drivers/media/platform/qcom/camss/camss-csid-980.c
> new file mode 100644
> index 0000000000000..713db25cd8c65
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-csid-980.c
> @@ -0,0 +1,466 @@
[ ... ]
> +static void __csid_configure_rx(struct csid_device *csid,
> + struct csid_phy_config *phy)
> +{
> + int val;
> +
> + val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
> + val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
> + val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX)
> + << CSI2_RX_CFG0_PHY_NUM_SEL;
> + writel(val, csid->base + CSID_CSI2_RX_CFG0);
> +
> + val = CSI2_RX_CFG1_ECC_CORRECTION_EN;
> + writel(val, csid->base + CSID_CSI2_RX_CFG1);
> +}
[ ... ]
> +static void __csid_configure_rdi_stream(struct csid_device *csid, u8 enable, u8 port, u8 vc)
> +{
> + u8 lane_cnt = csid->phy.lane_cnt;
> + u32 val;
> +
> + /* Source pads matching RDI channels on hardware.
> + * E.g. Pad 1 -> RDI0, Pad 2 -> RDI1, etc.
> + */
> + struct v4l2_mbus_framefmt *input_format = &csid->fmt[MSM_CSID_PAD_FIRST_SRC + port];
> + const struct csid_format_info *format = csid_get_fmt_entry(csid->res->formats->formats,
> + csid->res->formats->nformats,
> + input_format->code);
> +
> + if (!lane_cnt)
> + lane_cnt = 4;
[Severity: Medium]
Was the lane_cnt fallback meant to be in __csid_configure_rx() instead of
__csid_configure_rdi_stream()?
In __csid_configure_rdi_stream(), lane_cnt is never read after being set,
which triggers a -Wunused-but-set-variable warning under W=1 (and precedes
the variable declarations below). Meanwhile, __csid_configure_rx() uses
phy->lane_cnt - 1 directly in signed int arithmetic, so if phy->lane_cnt
is 0 (for instance, when csid_set_stream() disables a stream after
csid_set_power() without an active sink link), val becomes -1 and corrupts
all fields written to CSID_CSI2_RX_CFG0.
> +
> + /*
> + * DT_ID is a two bit bitfield that is concatenated with
> + * the four least significant bits of the five bit VC
> + * bitfield to generate an internal CID value.
> + *
> + * CSID_RDI_CFG0(vc)
> + * DT_ID : 28:27
> + * VC : 26:22
> + * DT : 21:16
> + *
> + * CID : VC 3:0 << 2 | DT_ID 1:0
> + */
> + u8 dt_id = vc & 0x03;
> + u32 rdi_cfg0_offset = CSID_RDI_CFG0(port);
> + u32 rdi_cfg1_offset = CSID_RDI_CFG1(port);
> + u32 rdi_ctrl_offset = CSID_RDI_CTRL(port);
> +
> + val = RDI_CFG0_TIMESTAMP_EN;
> + val |= RDI_CFG0_TIMESTAMP_STB_SEL;
> + val |= RDI_CFG0_RETIME_BS;
> +
> + /* note: for non-RDI path, this should be format->decode_format */
> + val |= DECODE_FORMAT_PAYLOAD_ONLY << RDI_CFG0_DECODE_FORMAT;
> + val |= vc << RDI_CFG0_VC;
> + val |= format->data_type << RDI_CFG0_DT;
> + val |= dt_id << RDI_CFG0_DT_ID;
> + writel(val, csid->base + rdi_cfg0_offset);
[ ... ]
> +static void csid_configure_stream(struct csid_device *csid, u8 enable)
> +{
> + u8 i, k;
> +
> + __csid_configure_rx(csid, &csid->phy);
> +
> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_980; i++) {
> + if (csid->phy.en_vc & BIT(i)) {
> + __csid_configure_rdi_stream(csid, enable, i, 0);
[Severity: High]
Should dt_id in __csid_configure_rdi_stream() be derived from port & 0x03
rather than vc & 0x03?
csid_configure_stream() always passes vc = 0 while passing the RDI channel
index i as port. Calculating dt_id from vc sets RDI_CFG0_DT_ID to 0 for
every RDI channel, so RDI1, RDI2, and RDI3 all receive internal CID 0 and
cannot stream properly, matching the issue fixed for CSID GEN3 in commit
ad136e52634d ("media: qcom: camss: Fix RDI streaming for CSID GEN3") and
for CSID GEN2 in commit 618765634cef ("media: qcom: camss: Fix RDI
streaming for CSID GEN2").
[ ... ]
> +static irqreturn_t csid_isr(int irq, void *dev)
> +{
> + struct csid_device *csid = dev;
> + u32 val, buf_done_val;
> + u8 reset_done;
> + int i;
> +
> + val = readl(csid->base + CSID_TOP_IRQ_STATUS);
> + writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
> +
> + reset_done = val & INFO_RST_DONE;
> +
> + buf_done_val = readl(csid->base + CSID_BUF_DONE_IRQ_STATUS);
> + writel(buf_done_val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
> +
> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS_980; i++) {
> + if (csid->phy.en_vc & BIT(i)) {
> + val = readl(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
> + writel(val, csid->base + CSID_CSI2_RDIN_IRQ_CLEAR(i));
> +
> + if (val & INFO_RUP_DONE) {
> + __csid_addr_update_clear(csid, i);
> + __csid_reg_update_clear(csid, i);
> + }
> +
> + if (buf_done_val & BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i))
> + camss_buf_done(csid->camss, csid->id, i);
> + }
> + }
[Severity: Medium]
Can __csid_addr_update_clear() and __csid_reg_update_clear() in csid_isr()
race with concurrent updates to csid->reg_update and csid->addr_update?
In camss-vfe.c, vfe_queue_buffer_v2(), vfe_enable_output_v2(), and
vfe_buf_done() hold vfe->output_lock while calling the CSID addr_update
and reg_update callbacks, which perform non-atomic read-modify-write
updates on csid->reg_update and csid->addr_update. However, csid_isr()
clears bits in csid->addr_update and csid->reg_update before
camss_buf_done() is called and without holding vfe->output_lock:
CPU0 CPU1 (<hardirq>)
vfe_queue_buffer_v2()
spin_lock_irqsave(&vfe->output_lock)
__csid_addr_update(csid, i)
csid->reg_update |= AUP_RDI(i)
writel(csid->reg_update,
CSID_LITE_RUP_AUP_CMD)
csid_isr()
if (val & INFO_RUP_DONE)
__csid_addr_update_clear(csid, i)
csid->reg_update &= ~AUP_RDI(i)
__csid_reg_update(csid, i)
csid->reg_update |= RUP_RDI(i)
writel(csid->reg_update, ...) <-- overwrites CMD with AUP_RDI(i) cleared
On CSID Lite, where RUP and AUP share csid->reg_update and the
CSID_LITE_RUP_AUP_CMD register, this race can clear a newly queued AUP bit
in hardware before it is consumed, and across multiple active RDI ports it
can lose or retain stale update bits in csid->reg_update and
csid->addr_update.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261114-add-support-for-camss-on-sm8750-v7-0-8ff2a11835f6@oss.qualcomm.com?part=10
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-11-14 11:55 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-14 11:29 [PATCH v7 00/23] Add CAMSS support for SM8750 and Eliza Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 01/23] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add SM8750 CSI2 PHY Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 02/23] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Eliza " Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 03/23] dt-bindings: media: qcom,sm8750-camss: Add SM8750 CAMSS Wenmeng Liu
2026-11-14 11:42 ` sashiko-bot
2026-11-14 11:29 ` [PATCH v7 04/23] dt-bindings: media: qcom,eliza-camss: Add Eliza CAMSS Wenmeng Liu
2026-11-14 11:43 ` sashiko-bot
2026-11-14 11:29 ` [PATCH v7 05/23] dt-bindings: i2c: qcom-cci: Document Eliza compatible Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 06/23] phy: qcom-mipi-csi2: Add SM8750 support Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 07/23] media: qcom: camss: Add SM8750 compatible Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 08/23] media: qcom: camss: Add PM clock definitions for SM8750 Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 09/23] media: qcom: camss: csid: Scale the clocks with the CSI-2 link rate Wenmeng Liu
2026-11-14 12:07 ` sashiko-bot
2026-11-14 11:29 ` [PATCH v7 10/23] media: qcom: camss: csid: Add support for CSID 980 Wenmeng Liu
2026-11-14 11:55 ` sashiko-bot [this message]
2026-11-14 11:29 ` [PATCH v7 11/23] media: qcom: camss: vfe: Add support for VFE 980 Wenmeng Liu
2026-11-14 11:42 ` sashiko-bot
2026-11-14 11:29 ` [PATCH v7 12/23] media: qcom: camss: tpg: Add support for v2.3.0 TPG Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 13/23] media: qcom: camss: Add Eliza compatible Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 14/23] arm64: dts: qcom: sm8750: Add CAMSS and CSIPHY block definitions Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 15/23] arm64: dts: qcom: sm8750: Add CCI definitions Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 16/23] arm64: dts: qcom: sm8750: Add camera MCLK pinctrl Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 17/23] arm64: dts: qcom: sm8750-qrd: Enable S5KJN1 camera sensor Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 18/23] arm64: dts: qcom: eliza: Add CAMSS and CSIPHY block definitions Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 19/23] arm64: dts: qcom: eliza: Add CCI definitions Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 20/23] arm64: dts: qcom: eliza: Add camera MCLK pinctrl Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 21/23] arm64: dts: qcom: eliza-mtp: Add PM8010 PMICs Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 22/23] arm64: dts: qcom: eliza-mtp: Enable rear camera Wenmeng Liu
2026-11-14 11:29 ` [PATCH v7 23/23] arm64: dts: qcom: eliza-evk-imx577-camera: Add DT overlay Wenmeng Liu
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=sashiko-outbox-214437@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=media-ci@linuxtv.org \
--cc=neil.armstrong@linaro.org \
--cc=olteanv@gmail.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vkoul@kernel.org \
--cc=wenmeng.liu@oss.qualcomm.com \
/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