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
WARNING: multiple messages have this Message-ID (diff)
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
next prev parent reply other threads:[~2026-09-29 6:17 UTC|newest]
Thread overview: 58+ 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 ` 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-29 6:00 ` Hangxiang Ma
2026-09-30 10:33 ` Krzysztof Kozlowski
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:00 ` Hangxiang Ma
2026-09-29 6:08 ` sashiko-bot
2026-09-29 6:08 ` sashiko-bot
2026-09-30 12:54 ` Hangxiang Ma
2026-09-30 12:54 ` Hangxiang Ma
2026-09-30 10:34 ` Krzysztof Kozlowski
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 ` 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 ` 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:00 ` Hangxiang Ma
2026-09-29 6:17 ` sashiko-bot
2026-09-29 6:17 ` sashiko-bot
2026-09-30 13:01 ` Hangxiang Ma
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:00 ` Hangxiang Ma
2026-09-29 6:17 ` sashiko-bot
2026-09-29 6:17 ` sashiko-bot
2026-09-30 13:54 ` Hangxiang Ma
2026-09-30 13:54 ` Hangxiang Ma
2026-10-03 5:32 ` 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:00 ` Hangxiang Ma
2026-09-29 6:17 ` sashiko-bot [this message]
2026-09-29 6:17 ` sashiko-bot
2026-09-30 14:07 ` Hangxiang Ma
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:00 ` Hangxiang Ma
2026-09-29 6:12 ` sashiko-bot
2026-09-29 6:12 ` sashiko-bot
2026-09-30 14:12 ` Hangxiang Ma
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:00 ` Hangxiang Ma
2026-09-29 6:11 ` sashiko-bot
2026-09-29 6:11 ` sashiko-bot
2026-09-30 14:17 ` Hangxiang Ma
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 ` 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:00 ` Hangxiang Ma
2026-09-29 6:07 ` sashiko-bot
2026-09-29 6:07 ` sashiko-bot
2026-09-30 14:23 ` Hangxiang Ma
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.