Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp188909pxv; Wed, 7 Jul 2021 23:53:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzQD/WlbUWz2HkQYpomLQapRk2ImG2PzQLMiuaZvMRTZMxLgqHFdH0m7rklHbhkzwcXXPhS X-Received: by 2002:a17:907:2089:: with SMTP id pv9mr28482208ejb.246.1625727201641; Wed, 07 Jul 2021 23:53:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625727201; cv=none; d=google.com; s=arc-20160816; b=yLIegruddaFswnyfg0KNutx4HMxY5TE4uyoBNZMzo7cpDQgPR7kGQ9ofrJYl9WcEVF 7VOo7qPU0IikYQ81ls7KHv4tjV2k2gDcGlnLP2RVCL2ljNsFnKR5rMmu65uPNTd9GlKS qFFvIMkTDes1hR1eb7GlboBg9XaqhuyAsnZjo3LhkCP82gzR3/9rSdpMD4lknMsG/MeO WlC3veAxxXPEbmQe6kRVHYjYetfkDeIh2ANVNbsl3Tg1mFhLUuDTIyFtbyNIEIIrCfL1 icB0thTVSnqX8jRSwjywOLB0RzPxjPccJrVNbItRaw5Yc6CoJvNLVGSvXIXkj0JVvtRD pjnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:user-agent:from :references:in-reply-to:mime-version:dkim-signature; bh=HVD5y86eZda4zsbe0B5h51p+U8LmjsDcgy/cp1cHfiw=; b=YtwSxjqEX4T5arvvvFuzZG/IGiBXSJftioPR7siR/WgJ9E4LIpM1WGsZxudBoaK825 deJzLAJYoH29dwp6oQPDTZr1deWEO26BZ9ecAEyUhVz058N4PTaJaY8o3LDehvvfpmd7 +s+RFxfBSuxhydlL1HDKKmv8JwzqHVP43ZQgr3uxSHmF6p3yYLUatbcSrOnAYJ7noWEZ aIL7y4rpmOvhQKGsXlJqbfTg+ZwTIwS9uX2h6wrPcxImeU8A7mQUA0UfOOV4X8kKWy6T ixxtpxeWjAXcqXHzqs8/IU8M3imK2AouwPTpjx99rqTzkws1uDCyGGuq6Zse3W37Jb5R et9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=maO7t2jN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b1si2298091ejb.600.2021.07.07.23.52.58; Wed, 07 Jul 2021 23:53:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=maO7t2jN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229768AbhGHGyW (ORCPT + 99 others); Thu, 8 Jul 2021 02:54:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59758 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229756AbhGHGyW (ORCPT ); Thu, 8 Jul 2021 02:54:22 -0400 Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D69E5C061574 for ; Wed, 7 Jul 2021 23:51:39 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id 59-20020a9d0ac10000b0290462f0ab0800so4851019otq.11 for ; Wed, 07 Jul 2021 23:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:user-agent:date:message-id :subject:to:cc; bh=HVD5y86eZda4zsbe0B5h51p+U8LmjsDcgy/cp1cHfiw=; b=maO7t2jNZuoibZMBU8a+fE5saykw+uyETAlE6DBaxuGJWyKbRsLkQniBtfYnTMUpU7 soWO4Hzh+XJ2IxeklQU4q2ciYvv2J+reQ+i4U94xFKK5M5BgmU22TTB4jfHqOL8BWHNC FX7Pur7coMrSF3RK2+8c0bOxNdQnwCX7QaN6A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from :user-agent:date:message-id:subject:to:cc; bh=HVD5y86eZda4zsbe0B5h51p+U8LmjsDcgy/cp1cHfiw=; b=hWi6pDeS5Vzr3ddby74FiAo6okhcvfg206pb1rXGWmfXBQFaLvaomjUf7ASZKDryNB F8FqNmuR9paqsNCSoErqBqmzBmKeou6E1RkEbkc9IhijbGWUOZ2GbHlZohKi6DLjIIOh vrv/H9fMfKDvunOn1QXNVWjCKnNYMc0bY62ZUrDzSjRomwixIAQ06avJ3K0fNG5Odqme m3GPdwmFQJe+E+XrG+cmaZySrvlR7gtS2wnr0RtmotkVrueU3OSXZZEFuTK7BEtSroU7 Wyxjm8xwY+8aWxSzx+rSQn2ptoBskecF1uUEj5j5SViFn90AIrGDo7Uts9kPLlprDThD gJiw== X-Gm-Message-State: AOAM5311848gFcjtxQhZpwEs03a1ylVSvKkV7XPJSDf4Jp6wME9a1x4V X6mFR4Tg2bkWFiC4KkTOHZvzcG0f+OUwYuWT4SQsVg== X-Received: by 2002:a05:6830:1353:: with SMTP id r19mr22942548otq.233.1625727099195; Wed, 07 Jul 2021 23:51:39 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 8 Jul 2021 06:51:38 +0000 MIME-Version: 1.0 In-Reply-To: <8da6e99f-ae80-b9a5-4fe9-6cc467ea65d0@codeaurora.org> References: <20210703005416.2668319-1-bjorn.andersson@linaro.org> <20210703005416.2668319-2-bjorn.andersson@linaro.org> <8da6e99f-ae80-b9a5-4fe9-6cc467ea65d0@codeaurora.org> From: Stephen Boyd User-Agent: alot/0.9.1 Date: Thu, 8 Jul 2021 06:51:38 +0000 Message-ID: Subject: Re: [PATCH 1/2] soc: qcom: rpmhpd: Use corner in power_off To: Bjorn Andersson , Rajendra Nayak Cc: Andy Gross , Dmitry Baryshkov , Ulf Hansson , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Rajendra Nayak (2021-07-07 22:03:53) > > > On 7/8/2021 10:05 AM, Bjorn Andersson wrote: > > On Wed 07 Jul 19:21 CDT 2021, Stephen Boyd wrote: > > > >> Quoting Bjorn Andersson (2021-07-02 17:54:15) > >>> rpmhpd_aggregate_corner() takes a corner as parameter, but in > >>> rpmhpd_power_off() the code requests the level of the first corner > >>> instead. > >>> > >>> In all (known) current cases the first corner has level 0, so this > >>> change should be a nop, but in case that there's a power domain with a > >>> non-zero lowest level this makes sure that rpmhpd_power_off() actually > >>> requests the lowest level - which is the closest to "power off" we can > >>> get. > >>> > >>> While touching the code, also skip the unnecessary zero-initialization > >>> of "ret". > >>> > >>> Fixes: 279b7e8a62cc ("soc: qcom: rpmhpd: Add RPMh power domain driver") > >>> Signed-off-by: Bjorn Andersson > >>> --- > >> > >> I think this is why qcom folks talk about "virtual corner" and "physical > >> corner" because there's the one in command DB and the one in hardware. > > > > I think the driver uses "level" and "corner" to denote the two different > > number spaces, so I think we're good...now that we after this patch > > don't pass a "level" as "corner" during power_off ;) Alright then nothing to do. Yay? > > > >> Maybe we should change rpmhpd_aggregate_corner() to call the argument > >> 'vcorner'? > > > > So "virtual corner" is "corner" and "physical corner" is level? I.e. 256 > > is a "physical corner"? > > I haven't heard of anything called a 'physical corner'. These were always > referred to as virtual corners, on older platforms it was just one contiguous > number space, on newer ones we added another higher level sparse number space > just for more fun :) > Command DB refers to these as hlvl and vlvl, I haven;t yet figured out what their > full forms are :/ Ah maybe I'm mixing up CPR terms with this stuff. I suspect hlvl is "hardware level" and vlvl is "virtual level", but probably should have been "software level". As far as I remember, the command DB layer was stacked on top so that they could insert more levels in between two levels in the hardware number space and not have to change all the rpmh clients out there (of which there could be many considering all the independent operating systems running on the SoC). For example, [0, 128, 256] maps to [0, 1, 2] and then they realize they need to jam another level between 1 and 2 so they remap 256 to 3 so everyone keeps considering 256 as the previous vlvl to clear the way for 2 to be reused as 198 or something like that. I don't think this ever really changes after the device ships, but it lets them decouple rpmh firmware updates from the rest of the system. As long as they're kept as far apart in vlvl space as there are numbers in hlvl space they can easily do this remap trick and hardware can treat it as levels that bounce around physical voltages that are monotonically increasing.