From: sashiko-bot@kernel.org
To: "Hangxiang Ma" <hangxiang.ma@oss.qualcomm.com>
Cc: conor+dt@kernel.org, vkoul@kernel.org,
devicetree@vger.kernel.org, olteanv@gmail.com,
neil.armstrong@linaro.org, linux-phy@lists.infradead.org,
robh@kernel.org, media-ci@linuxtv.org
Subject: Re: [PATCH v17 07/11] media: qcom: camss: vfe: Add support for VFE Gen4
Date: Tue, 29 Sep 2026 06:17:55 +0000 [thread overview]
Message-ID: <20260929061755.8BA321F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260928-kaanapali-camss-v17-7-dcf3fd37f76c@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] camss: hardware constraint violation due to unconditional AUP_UPDATE loop in CSID
- [High] camss: subsystem API violation where IFE Lite's 4th RDI line is incorrectly configured as PIX
--
commit def99c6cf972d2305c4c27701233f42e411f7857
Author: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
media: qcom: camss: vfe: Add support for VFE Gen4
This commit adds support for the VFE Gen4 (TFE) found on the Kaanapali SoC.
It configures the hardware blocks and clock requirements, while deferring
REG_UPDATE and AUP_UPDATE until after CSID configuration completes.
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
[ ... ]
> @@ -552,7 +554,9 @@ int vfe_enable_output_v2(struct vfe_line *line)
> output->gen2.active_num++;
> ops->vfe_wm_update(vfe, output->wm_idx[0],
> output->buf[i]->addr[0], line);
> - ops->reg_update(vfe, line->id);
> +
> + if (!vfe->res->reg_update_after_csid_config)
> + ops->reg_update(vfe, line->id);
> }
>
> spin_unlock_irqrestore(&vfe->output_lock, flags);
[Severity: High]
The commit message states: "the number of AUP_UPDATE requests must match the
number of buffers queued to the write master while it is being enabled."
In vfe_enable_output_v2(), the VFE loop shown above queues pending buffers
dynamically up to CAMSS_INIT_BUF_COUNT, but breaks early if userspace queued
fewer buffers. By setting reg_update_after_csid_config to true for Kaanapali,
this defers the update to CSID.
However, the corresponding CSID code at csid_configure_stream() in
camss-csid-gen4.c blindly issues AUP_UPDATEs matching the maximum buffer
count:
for (k = 0; k < CAMSS_INIT_BUF_COUNT; k++)
__csid_aup_update(csid, i);
If userspace queues fewer buffers before starting the stream, does this cause
a mismatch between the generated AUP_UPDATEs and the actually queued buffers,
violating the hardware constraint?
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
[ ... ]
> @@ -158,6 +158,157 @@ static const struct camss_subdev_resources csid_res_kaanapali[] = {
[ ... ]
> + /* VFE3 - IFE Lite */
> + {
> + .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb",
> + "vfe_lite_ahb", "vfe_lite",
> + "cpas_vfe_lite", "camnoc_rt_axi",
> + "camnoc_nrt_axi", "qdss_debug_xo" },
> + .clock_rate = { { 0 },
> + { 0 },
> + { 0 },
> + { 0 },
> + { 266666667, 400000000, 480000000 },
> + { 0 },
> + { 200000000, 300000000, 400000000, 480000000 },
> + { 0 },
> + { 0 } },
> + .reg = { "vfe_lite0" },
> + .interrupt = { "vfe_lite0" },
> + .vfe = {
> + .line_num = 4,
> + .is_lite = true,
[Severity: High]
The commit message explicitly states: "Support is currently limited to three
output lines, matching the constraints of the CAMSS framework."
But line_num is initialized to 4 for the IFE Lite blocks.
Since the CAMSS framework hardcodes VFE_LINE_PIX to index 3, does configuring
4 lines cause the 4th line (RDI3 with id 3) to be incorrectly subjected to
PIX-specific logic? For example, in vfe_try_format(), this would force a raw
RDI dump stream to use PIX format tables and validation:
if (line->id == VFE_LINE_PIX) {
struct v4l2_rect *rect;
rect = __vfe_get_crop(line, sd_state, which);
fmt->width = rect->width;
fmt->height = rect->height;
}
Is this initialization to 4 lines unintentional given the 3-line limit
mentioned in the commit?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-kaanapali-camss-v17-0-dcf3fd37f76c@oss.qualcomm.com?part=7
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-09-29 6:17 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 6:00 [PATCH v17 00/11] media: qcom: camss: Add Kaanapali support Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 01/11] dt-bindings: phy: qcom,x1e80100-csi2-phy: Add Kaanapali CSI2 PHY Hangxiang Ma
2026-09-30 10:33 ` Krzysztof Kozlowski
2026-09-29 6:00 ` [PATCH v17 02/11] media: dt-bindings: Add CAMSS device for Kaanapali Hangxiang Ma
2026-09-29 6:08 ` sashiko-bot
2026-09-30 12:54 ` Hangxiang Ma
2026-09-30 10:34 ` Krzysztof Kozlowski
2026-09-29 6:00 ` [PATCH v17 03/11] media: qcom: camss: Add Kaanapali compatible Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 04/11] phy: qcom-mipi-csi2: Parametrise the common status register offset Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 05/11] media: qcom: camss: csiphy: Add support for v2.4.0 two-phase CSIPHY Hangxiang Ma
2026-09-29 6:17 ` sashiko-bot
2026-09-30 13:01 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 06/11] media: qcom: camss: csid: Add support for CSID Gen4 Hangxiang Ma
2026-09-29 6:17 ` sashiko-bot
2026-09-30 13:54 ` Hangxiang Ma
2026-10-03 5:32 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 07/11] media: qcom: camss: vfe: Add support for VFE Gen4 Hangxiang Ma
2026-09-29 6:17 ` sashiko-bot [this message]
2026-09-30 14:07 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 08/11] media: qcom: camss: tpg: Add support for v2.4.0 TPG Hangxiang Ma
2026-09-29 6:12 ` sashiko-bot
2026-09-30 14:12 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 09/11] arm64: dts: qcom: kaanapali: Add CAMSS and CSIPHY block definitions Hangxiang Ma
2026-09-29 6:11 ` sashiko-bot
2026-09-30 14:17 ` Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 10/11] arm64: dts: qcom: kaanapali: Add CCI controller nodes Hangxiang Ma
2026-09-29 6:00 ` [PATCH v17 11/11] arm64: dts: qcom: kaanapali: Add camera MCLK pinctrl Hangxiang Ma
2026-09-29 6:07 ` sashiko-bot
2026-09-30 14:23 ` Hangxiang Ma
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=20260929061755.8BA321F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hangxiang.ma@oss.qualcomm.com \
--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 \
/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