linux-kernel - Re: [PATCH] media: qcom: camss: Enable setting the rate to camnoc_rt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <628b0080-9977-4230-85ca-8685562e3fa6@linaro.org>
Date: Thu, 16 Oct 2025 17:59:04 +0300
From: Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>
To: Loic Poulain <loic.poulain@....qualcomm.com>,
 Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Krzysztof Kozlowski <krzk@...nel.org>,
 Hangxiang Ma <hangxiang.ma@....qualcomm.com>, Robert Foss
 <rfoss@...nel.org>, Andi Shyti <andi.shyti@...nel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Todor Tomov <todor.too@...il.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>, linux-i2c@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: [PATCH] media: qcom: camss: Enable setting the rate to
 camnoc_rt_axi clock

On 10/16/25 15:22, Loic Poulain wrote:
> On Thu, Oct 16, 2025 at 1:50 PM Bryan O'Donoghue
> <bryan.odonoghue@...aro.org> wrote:
>>>>>
>>>>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
>>>>> index ee08dbbddf88..09b29ba383f1 100644
>>>>> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
>>>>> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
>>>>> @@ -914,7 +914,8 @@ 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") ||
>>>>> -           !strcmp(clock->name, "camnoc_axi"));
>>>>> +           !strcmp(clock->name, "camnoc_axi") ||
>>>>> +           !strcmp(clock->name, "camnoc_rt_axi"));
>>>>
>>>> Just use camnoc_axi for both. Look at your bindings - why do you keep
>>>> different names for same signal?
>>>
>>> I think the correct question to ask is:
>>>
>>> Is camnoc_axi going to represent the other (NRT) clock in this
>>> setting?
>>>
>>> Konrad
>>
>> I'm - perhaps naively - assuming this clock really is required ... and
>> that both will be needed concurrently.
> 
> AFAIU, the NRT clock is not in use for the capture part, and only
> required for the offline processing engine (IPE, OPE), which will
> likely be described as a separated node.
> 

Does it mean the clock handling should be removed from QCM2290 or
X1E80100 VFEx resources? Has it been tested/verified?

-- 
Best wishes,
Vladimir