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: <a15bbbf1-549d-4603-ad6d-3a578b548184@oss.qualcomm.com>
Date: Tue, 18 Nov 2025 11:06:16 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Luca Weiss <luca.weiss@...rphone.com>,
        Bryan O'Donoghue <bod@...nel.org>, Robert Foss <rfoss@...nel.org>,
        Todor Tomov <todor.too@...il.com>,
        Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
 <conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>
Cc: ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-media@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/3] Add CAMSS support for SM6350

On 11/18/25 10:33 AM, Bryan O'Donoghue wrote:
> On 17/11/2025 12:53, Konrad Dybcio wrote:
>> On 11/16/25 3:30 PM, Bryan O'Donoghue wrote:
>>> On 14/11/2025 15:59, Luca Weiss wrote:
>>>> On Fri Nov 14, 2025 at 4:51 PM CET, Bryan O'Donoghue wrote:
>>>>> On 14/11/2025 11:15, Luca Weiss wrote:
>>>>>> Add bindings, driver and dts to support the Camera Subsystem on the
>>>>>> SM6350 SoC.
>>>>>>
>>>>>> These patches were tested on a Fairphone 4 smartphone with WIP sensor
>>>>>> drivers (Sony IMX576 and IMX582), the camera pipeline works properly as
>>>>>> far as I can tell.
>>>>>>
>>>>>> Though when stopping the camera stream, the following clock warning
>>>>>> appears in dmesg. But it does not interfere with any functionality,
>>>>>> starting and stopping the stream works and debugcc is showing 426.4 MHz
>>>>>> while the clock is on, and 'off' while it's off.
>>>>>>
>>>>>> Any suggestion how to fix this, is appreciated.
>>>>>>
>>>>>> [ 5738.590980] ------------[ cut here ]------------
>>>>>> [ 5738.591009] gcc_camera_axi_clk status stuck at 'on'
>>>>>> [ 5738.591049] WARNING: CPU: 0 PID: 6918 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>>>>>
>>>>> Do you have a full and complete kernel tree we could look at here ?
>>>>
>>>> Sure, this branch has everything in:
>>>>
>>>> https://github.com/sm6350-mainline/linux/tree/sm6350-6.17.y/
>>>>
>>>> For further refence, at least two other people have tested this branch
>>>> in postmarketOS, nothing particularly exciting to report from there,
>>>> apart from that the sdm-skin-thermal thermal zone (thermistor right next
>>>> to SoC) is currently configured with 55 degC as critical trip, which is
>>>> quickly achieved when starting a video recording, but that's not really
>>>> an issue with camss, but will need some tweaking regardless.
>>>>
>>>> https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7281
>>>
>>> diff --git a/drivers/clk/qcom/gcc-sm6350.c b/drivers/clk/qcom/gcc-sm6350.c
>>> index a4d6dff9d0f7f..229629ef82809 100644
>>> --- a/drivers/clk/qcom/gcc-sm6350.c
>>> +++ b/drivers/clk/qcom/gcc-sm6350.c
>>> @@ -908,9 +908,7 @@ static struct clk_branch gcc_camera_ahb_clk = {
>>>
>>>   static struct clk_branch gcc_camera_axi_clk = {
>>>          .halt_reg = 0x17018,
>>> -       .halt_check = BRANCH_HALT,
>>> -       .hwcg_reg = 0x17018,
>>> -       .hwcg_bit = 1,
>>
>> No reason to drop the hwcg description
>>
>>> +       .halt_check = BRANCH_VOTED,
>>
>> It'd be useful to explain why we should ignore the hw feedback in this case
>>
>>>          .clkr = {
>>>                  .enable_reg = 0x17018,
>>>                  .enable_mask = BIT(0),
>>
>> Konrad
> 
> vfe170 is what we have on sdm845
> 
> So I'm just asking Luca to try the sdm845 method of waggling this clock since what we have doesn't work.

It's of course going to work because this way you're not calling the
code that throws this error

I was curious whether you know the actual reason why this is being
done in some other GCC drivers

Konrad


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ