lkml.org 
[lkml]   [2023]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2 4/5] clk: qcom: camcc-sc8280xp: Add sc8280xp CAMCC
From
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

\
 
 \ /
  Last update: 2023-10-01 00:54    [W:0.055 / U:2.912 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site