From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35F5CC678D7 for ; Fri, 13 Jan 2023 14:03:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241136AbjAMOD4 (ORCPT ); Fri, 13 Jan 2023 09:03:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241254AbjAMOCr (ORCPT ); Fri, 13 Jan 2023 09:02:47 -0500 Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 996C610BD for ; Fri, 13 Jan 2023 06:00:36 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id v25so33210140lfe.12 for ; Fri, 13 Jan 2023 06:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=BBkjCgH/S4+zja9GzwYgpPsdNEZWlR+52ok1y+g6x/E=; b=oZ/Q9thIkb7M5vKCG2gaS2Zjd3chlHTyxpb4Svy0Yen3DrkgHo7G4si+LrfxrVxsZt qe1r1IDkgCx4LR9MJ3dw4t36fyAvgDnYrTHXnUypoFsRhYEGPhJJrn3+g0bEky/A6Yce bmLtIMJ32+trXS2sOqFbEjpenMzeaGB4x5YhxP3uyNiMuSArpHLojm36qfqEwAXidg1v js722w5yaC3yN46ER1WfMYC3PQ7mOiL7mg4pDDDVN84KcqdZruqjPkwGhlbrvzVzk3FO QlUIWzz/dWei1W23Sc1Cutu64WibED7SWZWyzvyckIXuh49Gv8T4Ik64aBuU9DLkZxWU tQxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BBkjCgH/S4+zja9GzwYgpPsdNEZWlR+52ok1y+g6x/E=; b=47gmE4v3Nz2lUJAgC8PM22TTmbBzINaRZu9OiySDU0pIGsZPF+/brE/8Zx4wQCCJ2S NyCP95qZE1+jVgG//T1WR4Xt7JQXTn1JQw4IhDExBKlwHEvk9gS/LXkOVGaidylYzxle kMSm/ZmOtV4F/3n/ElFv2ZR89uAMAsQjhp0mwVa3nCBibUEMd0MexEoTOc0TkqrwQQ6z xR//tpO5jEUfR6WYLHnjAmM6apaK0vrdP9weHAEluCEv5OzTTdH4Wm8uNrwkt8mUTsl7 eq3l/uBNM5jMfENA19Ai9+7xPetz5d6prmuWsVCCTXLeyV8IgZBLTSl2gHO9csi5bQDo jUZA== X-Gm-Message-State: AFqh2kof23qIZPiK+DIAhPfc8npa3QXElkt5avQLBp4m8PmKhZn0aV9q D5rqDXje/s5sdIpSlow834aqvw== X-Google-Smtp-Source: AMrXdXuvV49S07ZHejZTWVcmIs/UwlOQ5p3FIP5cG/I1LHaUe2FHtfATf3m3ppAtkCP+BOudCV9e6Q== X-Received: by 2002:ac2:491d:0:b0:4ca:faa4:af15 with SMTP id n29-20020ac2491d000000b004cafaa4af15mr20122639lfi.66.1673618434896; Fri, 13 Jan 2023 06:00:34 -0800 (PST) Received: from [192.168.1.101] (abym53.neoplus.adsl.tpnet.pl. [83.9.32.53]) by smtp.gmail.com with ESMTPSA id q11-20020a056512210b00b004cc9042c9cfsm1897868lfr.158.2023.01.13.06.00.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Jan 2023 06:00:33 -0800 (PST) Message-ID: <3cb18e7f-27ca-1e3f-94e7-6f767a026b07@linaro.org> Date: Fri, 13 Jan 2023 15:00:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH 10/13] clk: qcom: cpu-8996: fix ACD initialization Content-Language: en-US To: Dmitry Baryshkov , Andy Gross , Bjorn Andersson , Stephen Boyd , Michael Turquette , Rob Herring , Krzysztof Kozlowski , Taniya Das Cc: linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org References: <20230111192004.2509750-1-dmitry.baryshkov@linaro.org> <20230111192004.2509750-11-dmitry.baryshkov@linaro.org> <1c8d38e0-2f9d-9e89-5e21-e74ac7851727@linaro.org> From: Konrad Dybcio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 13.01.2023 11:44, Dmitry Baryshkov wrote: > On 12/01/2023 16:35, Konrad Dybcio wrote: >> >> >> On 11.01.2023 20:20, Dmitry Baryshkov wrote: >>> The vendor kernel applies different order while programming SSSCTL and >>> L2ACDCR registers on power and performance clusters. However it was >>> demonstrated that doing this upstream results in the board reset. Make >>> both clusters use the same sequence, which fixes the reset. >>> >>> Signed-off-by: Dmitry Baryshkov >>> --- >> I think we should look for the source of why this doesn't work, >> e.g. does downstream program it earlier somewhere? Are we >> missing something else that may bite later? > > I'm not sure what is the reason for downstream doing init in such sequence. Right now I'm sure that doing ACD init with the provided sequence fails the boot in some conditions. There might be the difference in the CPU init order. Or any other ordering issue. Or the lack of the CPR. Or Kryo LDO programming. There is a huge difference between vendor's 3.18 and the current 6.x. > > I propose to take the patch in, as it fixes the boot and runtime issue and revisit it later if any of the problems occur. I don't fancy such approach usually, but without the documentation I don't see a way to find any particular reason for programming pwr and perf using the different order of operations. Ack, let's do that. Reviewed-by: Konrad Dybcio One more thing, I noticed that downstream calls ACD init on `CPU_STARTING` event instead of `PRE_RATE_CHANGE`, see [1]. Are we "over-programming" ACD too much, or is it intended/fine? Konrad [1] https://git.codelinaro.org/clo/la/kernel/msm-3.18/-/blob/LA.UM.7.5.r1-05300-8x96.0/drivers/clk/msm/clock-cpu-8996.c#L1522-1540 > >> >> Konrad >>>   drivers/clk/qcom/clk-cpu-8996.c | 20 ++++++++------------ >>>   1 file changed, 8 insertions(+), 12 deletions(-) >>> >>> diff --git a/drivers/clk/qcom/clk-cpu-8996.c b/drivers/clk/qcom/clk-cpu-8996.c >>> index 47c58bb5f21a..1c00eb629b61 100644 >>> --- a/drivers/clk/qcom/clk-cpu-8996.c >>> +++ b/drivers/clk/qcom/clk-cpu-8996.c >>> @@ -475,9 +475,9 @@ static int qcom_cpu_clk_msm8996_register_clks(struct device *dev, >>>       return ret; >>>   } >>>   -#define CPU_AFINITY_MASK 0xFFF >>> -#define PWRCL_CPU_REG_MASK 0x3 >>> -#define PERFCL_CPU_REG_MASK 0x103 >>> +#define CPU_CLUSTER_AFFINITY_MASK 0xf00 >>> +#define PWRCL_AFFINITY_MASK 0x000 >>> +#define PERFCL_AFFINITY_MASK 0x100 >>>     #define L2ACDCR_REG 0x580ULL >>>   #define L2ACDTD_REG 0x581ULL >>> @@ -498,21 +498,17 @@ static void qcom_cpu_clk_msm8996_acd_init(struct regmap *regmap) >>>       if (val == 0x00006a11) >>>           goto out; >>>   -    hwid = read_cpuid_mpidr() & CPU_AFINITY_MASK; >>> - >>>       kryo_l2_set_indirect_reg(L2ACDTD_REG, 0x00006a11); >>>       kryo_l2_set_indirect_reg(L2ACDDVMRC_REG, 0x000e0f0f); >>>       kryo_l2_set_indirect_reg(L2ACDSSCR_REG, 0x00000601); >>>   -    if (PWRCL_CPU_REG_MASK == (hwid | PWRCL_CPU_REG_MASK)) { >>> -        regmap_write(regmap, PWRCL_REG_OFFSET + SSSCTL_OFFSET, 0xf); >>> -        kryo_l2_set_indirect_reg(L2ACDCR_REG, 0x002c5ffd); >>> -    } >>> +    kryo_l2_set_indirect_reg(L2ACDCR_REG, 0x002c5ffd); >>>   -    if (PERFCL_CPU_REG_MASK == (hwid | PERFCL_CPU_REG_MASK)) { >>> -        kryo_l2_set_indirect_reg(L2ACDCR_REG, 0x002c5ffd); >>> +    hwid = read_cpuid_mpidr(); >>> +    if ((hwid & CPU_CLUSTER_AFFINITY_MASK) == PWRCL_AFFINITY_MASK) >>> +        regmap_write(regmap, PWRCL_REG_OFFSET + SSSCTL_OFFSET, 0xf); >>> +    else >>>           regmap_write(regmap, PERFCL_REG_OFFSET + SSSCTL_OFFSET, 0xf); >>> -    } >>>     out: >>>       spin_unlock_irqrestore(&qcom_clk_acd_lock, flags); >