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 D5340C7EE2E for ; Tue, 28 Feb 2023 13:01:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229530AbjB1NBf (ORCPT ); Tue, 28 Feb 2023 08:01:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231523AbjB1NBe (ORCPT ); Tue, 28 Feb 2023 08:01:34 -0500 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D5CA63019E for ; Tue, 28 Feb 2023 05:01:31 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id r27so13029044lfe.10 for ; Tue, 28 Feb 2023 05:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1677589290; 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=FmcENpXNJMP3+mRcBEtL4u5TWOcKvk1vpFTsGy9hwFM=; b=VrZ/pzNMVRji1QXeGg83jSBpLU91PqZRnN0EshQ8nl80gpDPBt/Ni7olYSRbt5H2zA ncW9bBeyB7t8Pi04F6n4YFBY6GUYnvYabHf10AQpNR1BnlUDm1Pc57khoAldzPplTTU3 Y9o6dXtZkfOIFcElCVRyx9mzhK1qbNvKpJGyx4+mxvyPna1akGlfSbPM7PKrn8aE9pT3 tikPks45aQwDG6CpMXEXd+qI/65kqBpO5TNTeMw3nSrQ0yk7TVq4FvbEfvX2ngRFhZM8 4Mq4aeVf6mB0/RUivTOPMiAxApMveTnqhCsCwKkHccHVGeqUZat+AvLfZYU0v5J2WO+v EWZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677589290; 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=FmcENpXNJMP3+mRcBEtL4u5TWOcKvk1vpFTsGy9hwFM=; b=j3Tz/sJvUFaj2LaJzNMDsQ9fGBZunAGAcbJ1Ts2e5RNFYUT2HpajZ57TM6jANJJap2 tgEdDKjK1x7TTlrFWNYaV2uZ9oDyK4TIjV+OgQWQr4tjg3/4WlFXZeHDfhLYv0lqp68v cP0emn8gihkDoC58fl1OIpfaSTP9lVjqBUZw0+cYQyZ6Ip+Zaqcv6pbYJiIhytKkU0m+ VcG6QnffSfOUGRLmRuolLD8K8/cjEOBs+jbiFfgK6Z/PGxl1PylcQMND9i8iyLBME793 VUcQTBzbYj1U1s3OeY8vk6sMp2Hac/ZohjnGU/k+5XNCEEHys6l01tfQ9eIX9OFp7Mj0 bJ4g== X-Gm-Message-State: AO0yUKVOTDfgvjWx8H1zWc+vgxQe/W1d2PE2HyBqs2Lp630hCRqgLZo0 LrIdCw8kAxFw1ddBwaH633efNg== X-Google-Smtp-Source: AK7set+xxjCs4P3sX8/fDJiixYPr+PmoXyz7rzf6qHqL+iRZCbnxRVf0GMVJO8FuBGAkHB0PngojZQ== X-Received: by 2002:a19:5511:0:b0:4e1:13fa:bf07 with SMTP id n17-20020a195511000000b004e113fabf07mr602899lfe.43.1677589289993; Tue, 28 Feb 2023 05:01:29 -0800 (PST) Received: from [192.168.1.101] (abym99.neoplus.adsl.tpnet.pl. [83.9.32.99]) by smtp.gmail.com with ESMTPSA id j27-20020ac2551b000000b004dc4cb4f9c4sm1332478lfk.35.2023.02.28.05.01.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Feb 2023 05:01:29 -0800 (PST) Message-ID: Date: Tue, 28 Feb 2023 14:01:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v10 5/6] soc: qcom: Add support for Core Power Reduction v3, v4 and Hardened Content-Language: en-US To: AngeloGioacchino Del Regno , Dmitry Baryshkov Cc: Andy Gross , Bjorn Andersson , Rob Herring , Krzysztof Kozlowski , Viresh Kumar , Nishanth Menon , Stephen Boyd , Niklas Cassel , Liam Girdwood , Mark Brown , Robert Marko , linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, AngeloGioacchino Del Regno References: <20230217-topic-cpr3h-v10-0-67aed8fdfa61@linaro.org> <20230217-topic-cpr3h-v10-5-67aed8fdfa61@linaro.org> <153ef3e0-9978-d201-44ad-3a5e55eeef4f@linaro.org> <8c105a4f-f450-8fbf-ff0b-5629a47c1463@collabora.com> <8a813713-c60d-4726-0c62-de032db99ede@collabora.com> <5e7f9d22-b918-bdfc-931c-0e679c1e946d@collabora.com> From: Konrad Dybcio In-Reply-To: <5e7f9d22-b918-bdfc-931c-0e679c1e946d@collabora.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On 28.02.2023 09:19, AngeloGioacchino Del Regno wrote: > Il 27/02/23 14:20, Dmitry Baryshkov ha scritto: >> On Mon, 27 Feb 2023 at 15:06, AngeloGioacchino Del Regno >> wrote: >>> >>> Il 27/02/23 13:01, Dmitry Baryshkov ha scritto: >>>> >>>> I took a glance at the 'cpufreq: qcom-hw: Implement CPRh aware OSM programming' >>>> patch, it doesn't seem to use the header (maybe I checked the older version of the >>>> patch). As for me, this is another signal that cpr_ext_data should come together >>>> with the LUT programming rather than with the CPRh itself. >>>> >>>>> Konrad, perhaps you can send the cpufreq-hw commits in a separate series, in >>>>> which cover letter you mention a dependency on this one? >>>>> That would *clearly* show the full picture to reviewers. If by "the cpufreq-hw commits" you mean the OSM enablement, that's the plan! I just don't think sending it parallel to this series makes a whole lot of sense logistically (even though it does logically), as they both are quite gigantic.. For reference, here's the last revision that made it to lkml, I think: https://lore.kernel.org/phone-devel/20210701105730.322718-7-angelogioacchino.delregno@somainline.org/ >>>> >>>> Yes, that would be great. A small note regarding those patches. I see that you >>>> patched the qcom-cpufreq-hw.c. This way first the driver programs the LUT, then it >>>> reads it back to setup the OPPs. Would it be easier to split OSM-not-programmed >>>> driver? >>>> >>> >>> When I engineered that solution, I kept the cpufreq-hw reading *again* the values >>> from OSM to keep the driver *fully* compatible with the bootloader-programmed OSM >>> flow, which makes one thing (in my opinion) perfectly clear: that programming >>> sequence is exactly the same as what happens "under the hood" on SDM845 (and later) >>> but performed here-instead-of-there (linux instead of bootloader), with the actual >>> scaling driver being 100% the same between the two flows in the end. >>> >>> Having two drivers as you suggested would indeed achieve the same, but wouldn't be >>> any easier... if you do that, you'd have to *somehow* make sure that the >>> programming driver does its job before the cpufreq driver tries to read the OSM >>> status, adding one more link to an already long chain. >>> >>> Besides, I remember that this question got asked a while ago on the mailing lists >>> and there was a short discussion about it: >>> >>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2555580.html >> >> Ack, I see. Maybe splitting LUT programming to a separate source file >> would emphasise the fact that it is only required for some (older) > > Maybe. I'm not sure it's worth adding a new helper file, but I don't really have > any strong arguments against... > > Konrad, your call. qcom-cpufreq-hw.c is currently a driver for a small subset of the functionality that's available from the hardware behind it. Hence I reckon it'd only be correct to also keep all the "proper" setup there, as it concerns the same hardware, just that previously one did not need to utilize it fully, as the boot firmware ever so graciously performed that exact same setup with elevated privileges and before jumping to HLOS. Konrad > > Cheers! > Angelo > >> SoCs. Other than that, I have no additional comments for that series. >>