Re: [PATCH v3 0/3] Add CAMSS support for SM6350

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 2/18/26 7:12 PM, Imran Shaik wrote:
> 
> 
> On 17-02-2026 05:31 pm, Konrad Dybcio wrote:
>> On 2/17/26 12:56 PM, Imran Shaik wrote:
>>>
>>>
>>> On 16-02-2026 04:34 pm, Konrad Dybcio wrote:
>>>> On 2/13/26 2:15 PM, 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'
>>>>
>>>> FWIW 845 has .halt_check = BRANCH_VOTED here, which translates into
>>>> 'dont check the state at disable', this one has BRANCH_HALT (i.e. spin
>>>> and keep checking the hw state)
>>>>
>>>> +Taniya would BRANCH_VOTED be fitting for 6350 too? ^
>>>>
>>>
>>> The parent RCG of this clock is under NoC control, and seems like there is no vote on the NoC while disabling this clock, hence this issue is observed.
>>>
>>> The BRANCH_HALT_VOTED/BRANCH_HALT_SKIP should help, or if the NoC voting is removed after the clock disable then also this issue should be resolved.
>>
>> This is very useful, thanks for the insight!
>>
>> Is any of these solutions specifically preferred from your side?
>>
>> Konrad
> 
> From clock controllers side we can use the BRANCH_HALT_SKIP as this covers both enable/disable scenarios. But this needs to be checked further from consumer driver side as well to handle the NoC voting properly.

I'm going to read that as "better to just fix the user" then, since this
splat essentially acts as a mining canary for incorrect ordering

Worse off, the camss driver currently doesn't consume that clock for
sdm845.. (clock-names entry "gcc_camera_axi" is nowhere to be seen in there)

Konrad