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 24CE2C77B7C for ; Fri, 26 May 2023 08:51:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242799AbjEZIu7 (ORCPT ); Fri, 26 May 2023 04:50:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237004AbjEZIu6 (ORCPT ); Fri, 26 May 2023 04:50:58 -0400 Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 49196128 for ; Fri, 26 May 2023 01:50:56 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-4f3ba703b67so451459e87.1 for ; Fri, 26 May 2023 01:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1685091054; x=1687683054; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=vFgq2+VVrviL7UALj9pqiFm5m6vdqKFWr7xuBpXEGgk=; b=ME1+1zcdcnrW6W4YFgkJY1I+UtG6/knxC7rNTHRZcgSM65ZRaaM3RkNSBBfDbBa6FU jw/VX2m07hj8QVYd2l74yQUINdMLICa9Oh4jqTlcVTA03+F9s3TdNzDcQIzxUdo40B9d p/O8jNChmQHvRz4y2q7Oe8OzM2C2vfiNu0I+OUyqFXtkKwCX9c1yH8ViS4T6P3FC6SyT NXF5XEPuQ3qeUM4dfs/pS88L7OJOsZE5uOeI7h6OsFYioA53ZA0vO9VC4NYpDB11xS9/ MzgWJuFbwum+WYKpWuVHsfpXi7+TAlqfG4Fr9XeObmZCsNWvF/W1mrLQnon99FphY4ix raHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685091054; x=1687683054; h=content-transfer-encoding:in-reply-to:subject:from:references:cc:to :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=vFgq2+VVrviL7UALj9pqiFm5m6vdqKFWr7xuBpXEGgk=; b=LByV44OnhDWuVbdrR0t51n0Nn2HdW7ByWAKkG+GwWuuQKrXz2al3cWhjaO+q6Tfh/r ZWbL8arvOz2AM8y+lvNmw01Ki04AAzKXqMUoWSmU1OY4SqeDh3q4lYKIeFpbCsoSPurE rzXcru5RbFGMjCN3fNWwKrABPQYvkI/xYD5piF3fwdS4tlQ9fmad18LkXVn4t1HBVu4s pO+GUgEZJ1CMae6MQMPjDiAjtD6d1YrARzSwhTUHiIzLu4Rb6ZyzSAu1WzBqCDlXEdLC RcqXWoO6GDiG7hWFw4e5MocsSHxvhbEaxfGHO3hKZbbHjllD0G6EgOXEVGGwf7kkj+I/ 2vUw== X-Gm-Message-State: AC+VfDwaBdacb+dFe2AQSKvZ1yorXJKK9vxYigWEL93xiVVPlU4/ljtH 7CCY6NhmYNWzhFrSo01UZjnjgQ== X-Google-Smtp-Source: ACHHUZ6SBk/LbQLpRdgponALylw72ijErfTNlvdTRC9EnogFDghqyrnhNRt206k+lEMedSeVjT/SeQ== X-Received: by 2002:ac2:4571:0:b0:4f3:f98c:77fc with SMTP id k17-20020ac24571000000b004f3f98c77fcmr307628lfm.8.1685091054513; Fri, 26 May 2023 01:50:54 -0700 (PDT) Received: from [192.168.1.101] (abyj77.neoplus.adsl.tpnet.pl. [83.9.29.77]) by smtp.gmail.com with ESMTPSA id d16-20020ac25450000000b004f3b2d3fc25sm542344lfn.10.2023.05.26.01.50.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 May 2023 01:50:54 -0700 (PDT) Message-ID: <41f5b7a9-d927-e468-d1ea-291ad35ba943@linaro.org> Date: Fri, 26 May 2023 10:50:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Stephan Gerhold Cc: Bjorn Andersson , Andy Gross , Srinivas Kandagatla , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, phone-devel@vger.kernel.org, ~postmarketos/upstreaming@lists.sr.ht References: <20230510-msm8916-regulators-v1-0-54d4960a05fc@gerhold.net> <20230510-msm8916-regulators-v1-8-54d4960a05fc@gerhold.net> From: Konrad Dybcio Subject: Re: [PATCH 8/8] arm64: dts: qcom: msm8916-pm8916: Mark always-on regulators In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 26.05.2023 08:36, Stephan Gerhold wrote: > On Fri, May 26, 2023 at 02:28:52AM +0200, Konrad Dybcio wrote: >> On 26.05.2023 01:39, Konrad Dybcio wrote: >>> On 17.05.2023 20:48, Stephan Gerhold wrote: >>>> Some of the regulators must be always-on to ensure correct operation of >>>> the system, e.g. PM8916 L2 for the LPDDR RAM, L5 for most digital I/O >>>> and L7 for the CPU PLL (strictly speaking the CPU PLL might only need >>>> an active-only vote but this is not supported for regulators in >>>> mainline currently). >>> Would you be interested in implementing this? > > At least on MSM8916 there is currently no advantage implementing this. > The "active-only" votes only have the CPU as limited use case. S1 (aka > MSM8916_VDDCX) and L3 (MSM8916_VDDMX) are both used via rpmpd/power > domains which already provides separate active-only variants. L7 (for > the CPU PLL) is the only other regulator used in "active-only" mode. > However, at least on MSM8916 L7 seems to stay always-on no matter what I > do, so having an active-only vote on L7 doesn't provide any advantage. In this case it may be more important that we tell RPM that we want it to be active-only, even if it ultimately makes a different decision. You probably played with this more, but my guess would be that not letting off of an a-s vote could confuse the algos > >> Actually, I think currently all votes are active-only votes and what >> we're missing is sleep-only (and active-sleep if we vote on both) > > If you only send the "active" votes but no "sleep" votes for a resource > then the RPM firmware treats it as active+sleep, see [1]. > The active/sleep separation only starts once a separate sleep vote has > been sent for a resource for the first time. > > Therefore, all requests from the SMD regulator driver apply for both > active+sleep at the moment. > > [1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/blob/LA.BR.1.2.9.1-02310-8x16.0/drivers/regulator/rpm-smd-regulator.c#L202-204 /me *dies* that's a design decision if i've ever seen one.. > >>> >>> Ancient downstream defines a second device (vregname_ao) and basically >>> seems to select QCOM_SMD_(ACTIVE/SLEEP)_STATE based on that.. >>> >>> Looks like `struct regulator` stores voltage in an array that wouldn't >>> you know it, depends on the PM state. Perhaps that could be something >>> to explore! >>> > > Don't get confused by the similar naming here. RPM sleep votes are > unrelated to the "system suspend" voltages the regulator framework > supports. :) > > RPM sleep votes become active if the cpuidle reaches the deepest state > for the (cpu/)cluster(/CCI). This can happen anytime at runtime when the > system is idle long enough. On the other hand, the regulator suspend > voltages are meant to become active during system suspend (where all the > devices get suspended as well). Yes and pm_genpd tracks that very meticulously, at least in the case of PSCI. > > Since we do have "active-only" support in rpmpd I think the question is > if it is worth bringing the feature also to regulators. Perhaps one > could simply treat all regulators that are needed by the CPU as power > domain. That would make sense.. > > For example, L7 on MSM8916 is fixed at 1.8V so while it doesn't have > corners the simple enable/disable votes could also be sent via rpmpd. > In some places in downstream L7 is also called VDDPX, similar to > VDDCX and VDDMX which are already in rpmpd. Yeah, anything available from RPM is only vaguely categorized as being a clock/regulator/bus, sometimes wrongly (see: bus clocks in rpmcc) so there's some flexibility here. Konrad > > Thanks, > Stephan