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
