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 6CB02C64EC7 for ; Tue, 28 Feb 2023 08:19:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230376AbjB1ITc (ORCPT ); Tue, 28 Feb 2023 03:19:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230183AbjB1ITb (ORCPT ); Tue, 28 Feb 2023 03:19:31 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3CAFEC46; Tue, 28 Feb 2023 00:19:29 -0800 (PST) Received: from [192.168.1.100] (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id 52A386602E18; Tue, 28 Feb 2023 08:19:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1677572368; bh=fVVg1Oe8kqqB/BkhS1jgx+11KmQgwD13uKhiAsbngls=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=nO1R7DBBcZRJXbkS/4Q9JMHKaByMPOYF6twaPuQC0x0mlQ64uYAZ6L5fpJ8UP/Ldp cRz6cmWxej3svM0Bw0sdUu0MdPwO3S3pq9zrkeOht9dph+Et3I5r/XlDW8/Hzp9JMP c9Mgw6YCNXsgLxDyxaSqhl5bZPcnYJu7DJmo88ETktaPsbH72qGxZUpsfOGBsTfCvz H4RcBAHmYEQTqFnQWKjDAm1ttYy9WyCbOb9aFJB4JRc7ArUk/GpBmVSOgATTdEPPb+ pMx3jb2lrUQp4geUGEiUIgly2Zvhc0HPVH3E4zzr9mJrlHVYdqc5agCbVPqO1L1dW3 DLpp8QuoYqPig== Message-ID: <5e7f9d22-b918-bdfc-931c-0e679c1e946d@collabora.com> Date: Tue, 28 Feb 2023 09:19:24 +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 To: Dmitry Baryshkov Cc: Konrad Dybcio , 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> Content-Language: en-US From: AngeloGioacchino Del Regno In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org 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. >>> >>> 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. Cheers! Angelo > SoCs. Other than that, I have no additional comments for that series. >