From patchwork Wed Jul 13 06:52:55 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 590106 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 0D3CFCCA481 for ; Wed, 13 Jul 2022 06:53:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234351AbiGMGxT (ORCPT ); Wed, 13 Jul 2022 02:53:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234306AbiGMGxM (ORCPT ); Wed, 13 Jul 2022 02:53:12 -0400 Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABFF4E026F for ; Tue, 12 Jul 2022 23:53:10 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id j3so9453926pfb.6 for ; Tue, 12 Jul 2022 23:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=B5ZVa04kRBVsEindUIYNf6ytMtDp5QyGf3BkvnYuSLo=; b=QP/u/T0Zn0sbzDr0g4rRZI3+mPlW6nvAlDfIjKtlXGlhSDvWYp+TpvU0yegvocg1u2 w4UDLxOm5HzPvn4r51loynKH5CaH0ImYuEnP1qk6DZ/P0gUJpMs+4DUQ/bMlAqDqUoPp FwLEvZmWYyJ27b2GtMOq3jJSi9rgFkkvAq/8hZQFETDA2udNvM//uK6+B3L9cuLbX+Bl 5ve7JEpd4OEO6GWGizYazj9RhRPrBfFwUDifkcPYCAMmyg88KwUVTPyOyrg5JniWXBE/ g8Hof0zhE1hs/PwLcuHyw3VGeImX263og4NrhCuDqfElX2ihvq/tpM/f8p8a96Q/gkY9 2DWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=B5ZVa04kRBVsEindUIYNf6ytMtDp5QyGf3BkvnYuSLo=; b=JxlW16ndqzj6b73koWMJROA55e5hz5W9HTHbPIHpgU4eDlBn8Vpj88H2na0c/PAnwu 3ckulhBkq+dd6PgLmSfZRUAuRCiHyK+cki8iXuLjSN3b7VEsiN9ifw8frYla2J9ASHfk DrD4sOMmil/E64nan8sIsKwMUUdbDxHQNxdCf1TkALinWLkBuElPhYBeWCyT4wX5Eqfm kuF66S3+CbzuEmnoDKFL1MNyBYFeLY9X5Hh5qcF+boBX4hP3XNeJ/aN9fzyT0sMljze5 dqH7p92cxdb3PMzpa+d61lKua3xUXoyfUnFqb/c5keJuowbgbbqjKzWiVd4pKy20u3ln oQ8w== X-Gm-Message-State: AJIora8mWDKlTfFHrGTpYwc9cK6+Em4zMU3LwFMdJvczuV8IaBdfkVPm BSO/ILYn/HgM5ad6HVcnnXvXdA== X-Google-Smtp-Source: AGRyM1uTZpJm2P8dATZcH3RdrFjl8ifHeSxvTOCvASA8RYlc1lZ7b74RCRbcVk0iS4454/cUMBAlzA== X-Received: by 2002:a63:ee0f:0:b0:412:b2e7:55d6 with SMTP id e15-20020a63ee0f000000b00412b2e755d6mr1744417pgi.554.1657695190221; Tue, 12 Jul 2022 23:53:10 -0700 (PDT) Received: from localhost ([122.171.18.80]) by smtp.gmail.com with ESMTPSA id i3-20020a639d03000000b003fd1deccd4dsm7182171pgd.59.2022.07.12.23.53.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jul 2022 23:53:09 -0700 (PDT) From: Viresh Kumar To: Bjorn Andersson , Manivannan Sadhasivam , Andy Gross , Krzysztof Kozlowski , "Rafael J. Wysocki" , Rob Herring , Viresh Kumar Cc: Vincent Guittot , Johan Hovold , devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: [RFC PATCH 0/4] cpufreq: qcom-hw: Move clocks to CPU node Date: Wed, 13 Jul 2022 12:22:55 +0530 Message-Id: X-Mailer: git-send-email 2.31.1.272.g89b43f80a514 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi, A recent patch series, targeting enhancements in the OPP core, ended up breaking cpufreq on some of the Qualcomm platforms [1]. Necessary adjustments are made in the OPP core, a bit hacky though, to get it working for now but it would be better to solve the problem at hand in a cleaner way. And this patchset is an attempt towards the same. cpufreq-hw is a hardware engine, which takes care of frequency management for CPUs. The engine manages the clocks for CPU devices, but it isn't the end consumer of the clocks, which are the CPUs in this case. For this reason, it looks incorrect to keep the clock related properties in the cpufreq-hw node. They should really be present at the end user, i.e. the CPUs. The case was simple currently as all the devices, i.e. the CPUs, that the engine manages share the same clock names. What if the clock names are different for different CPUs or clusters ? How will keeping the clock properties in the cpufreq-hw node work in that case ? This design creates further problems for frameworks like OPP, which expects all such details (clocks) to be present in the end device node itself, instead of another related node. This patchset moves the clock properties to the node that uses them instead, i.e. the CPU nodes and makes necessary adjustments at other places. After this is applied, I can drop the unnecessary change from the OPP core, but I wanted to discuss if this is a step in the right direction or not first and so the RFC. --- Viresh [1] https://lore.kernel.org/lkml/YsxSkswzsqgMOc0l@hovoldconsulting.com/ Viresh Kumar (4): dt-bindings: cpufreq-qcom-hw: Move clocks to CPU nodes arm64: dts: qcom: Move clocks to CPU nodes cpufreq: qcom-cpufreq-hw: Clocks are moved to CPU nodes cpufreq: qcom-cpufreq-hw: Register config_clks helper .../bindings/cpufreq/cpufreq-qcom-hw.yaml | 31 ++++---- arch/arm64/boot/dts/qcom/sc7180.dtsi | 19 ++++- arch/arm64/boot/dts/qcom/sc7280.dtsi | 18 ++++- arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 ++++- arch/arm64/boot/dts/qcom/sm6350.dtsi | 18 ++++- arch/arm64/boot/dts/qcom/sm8150.dtsi | 19 ++++- arch/arm64/boot/dts/qcom/sm8250.dtsi | 18 ++++- arch/arm64/boot/dts/qcom/sm8350.dtsi | 19 ++++- arch/arm64/boot/dts/qcom/sm8450.dtsi | 18 ++++- drivers/cpufreq/qcom-cpufreq-hw.c | 75 ++++++++++++++----- 10 files changed, 199 insertions(+), 55 deletions(-)