lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181022054550.zlreptvlqn4z2jtq@vireshk-i7>
Date:   Mon, 22 Oct 2018 11:15:50 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Niklas Cassel <niklas.cassel@...aro.org>
Cc:     sboyd@...nel.org, andy.gross@...aro.org, ulf.hansson@...aro.org,
        collinsd@...eaurora.org, mka@...omium.org, robh@...nel.org,
        rnayak@...eaurora.org, devicetree@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] dt-bindings: opp: Extend qcom-opp bindings with
 properties needed for CPR

On 15-10-18, 14:47, Niklas Cassel wrote:
> Extend qcom-opp bindings with properties needed for Core Power Reduction
> (CPR).
> 
> CPR is included in a great variety of Qualcomm SoC, e.g. msm8916 and
> msm8996, and was first introduced in msm8974.
> 
> Signed-off-by: Niklas Cassel <niklas.cassel@...aro.org>
> ---
> Hello Rob, Rajendra,
> 
> Sorry for not replying sooner.
> Since Rob wanted the binding to be complete before merging,
> this is my proposal to extend the OPP binding with properties
> needed to support CPR (both for msm8916 and msm8996).
> I've discussed the proposal with Viresh, and this proposal
> seems better than what I previously suggested here:
> https://lore.kernel.org/lkml/20181005204424.GA29500@centauri.lan/
> 
>  .../devicetree/bindings/opp/qcom-opp.txt      | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/opp/qcom-opp.txt b/Documentation/devicetree/bindings/opp/qcom-opp.txt
> index db4d970c7ec7..3ab5dd84de86 100644
> --- a/Documentation/devicetree/bindings/opp/qcom-opp.txt
> +++ b/Documentation/devicetree/bindings/opp/qcom-opp.txt
> @@ -23,3 +23,22 @@ Required properties:
>  representing a corner/level that's communicated with a remote microprocessor
>  (usually called the RPM) which then translates it into a certain voltage on
>  a voltage rail.
> +
> +Optional properties:
> +- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. Even
> +  though a power domain doesn't need a opp-hz, there can be devices in the
> +  power domain that need to know the highest supported frequency for each
> +  corner/level (e.g. CPR), in order to properly initialize the hardware.
> +
> +- qcom,fuse-level: A positive value representing the fuse corner/level
> +  associated with this OPP node. Sometimes several corners/levels shares
> +  a certain fuse corner/level. A fuse corner/level contains e.g. ref uV,
> +  min uV, and max uV.
> +
> +- qcom,fuse-level-<name>: Named qcom,fuse-level property. This is exactly
> +  similar to the above qcom,fuse-level property, but allows multiple
> +  fuse corners/levels to be provided for the same OPP. At runtime, the
> +  platform can pick a <name> and matching qcom,fuse-level-<name> property
> +  will be enabled for all OPPs. If the platform doesn't pick a specific
> +  <name> or the <name> doesn't match with any qcom,fuse-level-<name>
> +  properties, then qcom,fuse-level property shall be used, if present.

LGTM.

-- 
viresh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ