From: sashiko-bot@kernel.org
To: "Andrew Gigena" <mail@andrewgigena.dev>
Cc: devicetree@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org,
media-ci@linuxtv.org
Subject: Re: [PATCH v2 3/5] media: qcom: camss: Match VFE lite clocks by name prefix
Date: Fri, 06 Nov 2026 03:36:31 +0000 [thread overview]
Message-ID: <sashiko-outbox-200652@kernel.org> (raw)
In-Reply-To: <20261106-sm8150-v7.4-rc1-camss-v2-3-39ee37787b00@andrewgigena.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] media: qcom: camss: vfe_match_clock_names() matches vfe_lite_* clocks
--
commit 6c95d1dba299c3fc78f8daef87dbf333ccf58408
Author: Andrew Gigena <mail@andrewgigena.dev>
media: qcom: camss: Match VFE lite clocks by name prefix
This commit updates vfe_match_clock_names() to match any clock starting
with "vfe_lite" when the VFE is a lite instance, so that numbered VFE-lite
clocks (such as vfe_lite0 and vfe_lite1) have their rates configured even
when vfe->id does not match the lite instance index.
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> index 2680a9914765f..9866ac09eefd7 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
> @@ -914,6 +914,7 @@ static int vfe_match_clock_names(struct vfe_device *vfe,
> return (!strcmp(clock->name, vfe_name) ||
> !strcmp(clock->name, vfe_lite_name) ||
> !strcmp(clock->name, "vfe_lite") ||
> + (vfe->res->is_lite && !strncmp(clock->name, "vfe_lite", 8)) ||
[Severity: High]
Does an 8-byte prefix match on "vfe_lite" in vfe_match_clock_names() also
match auxiliary VFE-lite clocks such as "vfe_lite_src", "vfe_lite_ahb",
"vfe_lite_csid", and "vfe_lite_cphy_rx" (whereas full VFE instances only
match exact "vfe%d" names and ignore "vfe%d_src", "vfe%d_fast_ahb",
"vfe%d_csid", and "vfe%d_cphy_rx")?
When starting a VFE-lite stream, vfe_get() calls vfe_set_clock_rates() on
initial power-up and vfe_check_clock_rates() on subsequent calls, and both
treat every clock matching vfe_match_clock_names() with non-zero
clock_rate entries as a core VFE clock that must support min_rate.
On SDM845, vfe_res_845 in drivers/media/platform/qcom/camss/camss.c lists
"vfe_lite_src" after "vfe_lite":
.clock = { "camnoc_axi", "cpas_ahb", "slow_ahb_src",
"soc_ahb", "vfe_lite",
"vfe_lite_src", "csi2",
"csi2_src"},
.clock_rate = { { 0 },
{ 0 },
{ 80000000 },
{ 0 },
{ 19200000, 100000000, 320000000, 404000000, 480000000, 600000000 },
{ 320000000 },
In drivers/clk/qcom/camcc-sdm845.c, cam_cc_ife_lite_clk ("vfe_lite") is a
child branch of cam_cc_ife_lite_clk_src ("vfe_lite_src") with
CLK_SET_RATE_PARENT. Because "vfe_lite_src" now matches
vfe_match_clock_names():
- When min_rate >= 320 MHz, vfe_set_clock_rates() finds no frequency above
min_rate in the single-entry { 320000000 } table for "vfe_lite_src" and
fails with -EINVAL ("Pixel clock is too high for VFE").
- When min_rate < 320 MHz or min_rate == 0 (where "vfe_lite" picks 600
MHz), the subsequent loop iteration for "vfe_lite_src" calls
clk_set_rate() with 320 MHz on the parent RCG, overwriting the rate just
set via "vfe_lite".
Similarly, on SM8550 (vfe_res_8550), SA8775P / QCS8300 (vfe_res_8775p),
and X1E80100 (vfe_res_x1e80100), the VFE-lite resource tables define
non-zero clock_rate entries for "vfe_lite_ahb", "vfe_lite_csid", and
"vfe_lite_cphy_rx" capping at 400 MHz while "vfe_lite" goes up to 480 MHz
or 600 MHz:
.clock = { "cpas_ahb", "gcc_axi_hf", "cpas_vfe_lite",
"vfe_lite_ahb", "vfe_lite_csid", "vfe_lite_cphy_rx",
"vfe_lite", "camnoc_axi"},
.clock_rate = {
{ 0 },
{ 0 },
{ 0 },
{ 300000000, 400000000, 400000000, 400000000 },
{ 400000000, 400000000, 400000000, 400000000 },
{ 400000000, 400000000, 400000000, 400000000 },
{ 480000000, 600000000, 600000000, 600000000 },
This causes two issues on those platforms:
- When min_rate > 400 MHz, vfe_set_clock_rates() fails with -EINVAL
because those auxiliary clocks have no rate above 400 MHz.
- In drivers/clk/qcom/camcc-sm8550.c and drivers/clk/qcom/camcc-sa8775p.c,
cam_cc_ife_lite_ahb_clk ("vfe_lite_ahb") is parented to
cam_cc_slow_ahb_clk_src, which maxes out at 80 MHz in hardware. When
vfe_get() is called a second time while vfe->power_count > 0 (for
example from csid_set_power() -> parent_dev_ops->get() during
v4l2_pipeline_pm_get(), or when enabling a second RDI line),
vfe_check_clock_rates() checks clk_get_rate(clock->clk) < min_rate on
"vfe_lite_ahb", sees 80 MHz, and returns -EBUSY whenever min_rate > 80
MHz.
Would it be safer to ensure the character following "vfe_lite" is not '_'
(e.g. checking clock->name[8] != '_' or isdigit(clock->name[8])) so that
only "vfe_lite" and numbered "vfe_liteN" clocks are matched?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261106-sm8150-v7.4-rc1-camss-v2-0-39ee37787b00@andrewgigena.dev?part=3
next prev parent reply other threads:[~2026-11-06 3:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 3:24 [PATCH v2 0/5] media: qcom: camss: Add SM8150 CAMSS support Andrew Gigena via B4 Relay
2026-11-06 3:24 ` [PATCH v2 1/5] dt-bindings: i2c: qcom-cci: Document SM8150 compatible Andrew Gigena via B4 Relay
2026-11-06 12:09 ` Krzysztof Kozlowski
2026-11-06 3:24 ` [PATCH v2 2/5] dt-bindings: media: qcom,sm8150-camss: Add SM8150 CAMSS Andrew Gigena via B4 Relay
2026-11-06 3:36 ` sashiko-bot
2026-11-06 11:20 ` Vladimir Zapolskiy
2026-11-06 11:46 ` Bryan O'Donoghue
2026-11-06 11:34 ` Bryan O'Donoghue
2026-11-06 12:15 ` Krzysztof Kozlowski
2026-11-06 3:24 ` [PATCH v2 3/5] media: qcom: camss: Match VFE lite clocks by name prefix Andrew Gigena via B4 Relay
2026-11-06 3:36 ` sashiko-bot [this message]
2026-11-06 11:26 ` Bryan O'Donoghue
2026-11-06 3:24 ` [PATCH v2 4/5] media: qcom: camss: Add support for SM8150 Andrew Gigena via B4 Relay
2026-11-06 11:27 ` Bryan O'Donoghue
2026-11-06 3:24 ` [PATCH v2 5/5] arm64: dts: qcom: sm8150: Add CAMSS and CCI nodes Andrew Gigena via B4 Relay
2026-11-06 3:41 ` sashiko-bot
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-200652@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=mail@andrewgigena.dev \
--cc=media-ci@linuxtv.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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