Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Message-ID: <ec8a0350-aac8-443e-854a-652179a5d6bb@linaro.org>
Date:   Sat, 30 Sep 2023 23:53:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 4/5] clk: qcom: camcc-sc8280xp: Add sc8280xp CAMCC
Content-Language: en-US
To:     Konrad Dybcio <konrad.dybcio@linaro.org>,
        Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
        andersson@kernel.org, agross@kernel.org, mturquette@baylibre.com,
        sboyd@kernel.org, robh+dt@kernel.org,
        krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
        jonathan@marek.ca, quic_tdas@quicinc.com,
        vladimir.zapolskiy@linaro.org
Cc:     linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20230930134114.1816590-1-bryan.odonoghue@linaro.org>
 <20230930134114.1816590-5-bryan.odonoghue@linaro.org>
 <ba0399d3-c3a5-0458-3668-e734fafe2f1a@linaro.org>
From:   Bryan O'Donoghue <bryan.odonoghue@linaro.org>
In-Reply-To: <ba0399d3-c3a5-0458-3668-e734fafe2f1a@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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