From: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
To: sashiko-reviews@lists.linux.dev
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: Wed, 30 Sep 2026 22:07:53 +0800 [thread overview]
Message-ID: <a77004e6-c375-46fb-ba32-bc6f34bba2ab@oss.qualcomm.com> (raw)
In-Reply-To: <20260929061755.8BA321F000FF@smtp.kernel.org>
On 9/29/2026 2:17 PM, sashiko-bot@kernel.org wrote:
> 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?
>
No. The hardware accept this operation and no issue is found in tests.
>> 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?
>
It's acceptable to align with the commits. Actually this is a CAMSS
framework restriction which needs additional efforts. Will keep it the
same for TFE Full and TFE Lite in next revision.
Best Regards,
Hangxiang
--
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: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com>
To: sashiko-reviews@lists.linux.dev
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: Wed, 30 Sep 2026 22:07:53 +0800 [thread overview]
Message-ID: <a77004e6-c375-46fb-ba32-bc6f34bba2ab@oss.qualcomm.com> (raw)
In-Reply-To: <20260929061755.8BA321F000FF@smtp.kernel.org>
On 9/29/2026 2:17 PM, sashiko-bot@kernel.org wrote:
> 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?
>
No. The hardware accept this operation and no issue is found in tests.
>> 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?
>
It's acceptable to align with the commits. Actually this is a CAMSS
framework restriction which needs additional efforts. Will keep it the
same for TFE Full and TFE Lite in next revision.
Best Regards,
Hangxiang
next prev parent reply other threads:[~2026-09-30 14:08 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
2026-09-29 6:17 ` sashiko-bot
2026-09-30 14:07 ` Hangxiang Ma [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: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=a77004e6-c375-46fb-ba32-bc6f34bba2ab@oss.qualcomm.com \
--to=hangxiang.ma@oss.qualcomm.com \
--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 \
/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.