On 30/09/2023 17:39, Konrad Dybcio wrote:
+static struct clk_branch camcc_gdsc_clk = {
+ .halt_reg = 0xc1e4,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0xc1e4,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "camcc_gdsc_clk",
+ .parent_hws = (const struct clk_hw*[]){
+ &camcc_xo_clk_src.clkr.hw,
+ },
+ .num_parents = 1,
+ .flags = CLK_IS_CRITICAL | CLK_SET_RATE_PARENT,
"meh"
Is this clock only necessary for the GDSC to turn on?
Most of this code is autogenerated in downstream as I understand it a
script is run against some definition the RTL one would hope.
I think that is probably how the gdsc clocks for the camcc are marked
like this upstream already too.
grep CRITICAL drivers/clk/qcom/*camcc*
drivers/clk/qcom/camcc-sc7280.c: .flags = CLK_IS_CRITICAL |
CLK_SET_RATE_PARENT,
drivers/clk/qcom/camcc-sm8250.c: .flags = CLK_IS_CRITICAL |
CLK_SET_RATE_PARENT,
drivers/clk/qcom/camcc-sm8450.c: .flags = CLK_IS_CRITICAL |
CLK_SET_RATE_PARENT,
I can tell you what clocks this clock but I can't tell you where that
clock routes too, so the best/only source of information I have is the
flag that comes from the autogenerated downstream code.
I think the safe thing to do is to leave the flag as is TBH.
---
bod
