Re: [PATCH v2 4/5] clk: qcom: camcc-sc8280xp: Add sc8280xp CAMCC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux