From patchwork Mon Oct 15 12:47:49 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Niklas Cassel X-Patchwork-Id: 984167 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=devicetree-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="BMKivcKb"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 42YdXV5XBtz9sCw for ; Mon, 15 Oct 2018 23:48:26 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726593AbeJOUdd (ORCPT ); Mon, 15 Oct 2018 16:33:33 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:39170 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726319AbeJOUdc (ORCPT ); Mon, 15 Oct 2018 16:33:32 -0400 Received: by mail-lj1-f194.google.com with SMTP id p1-v6so17353638ljg.6 for ; Mon, 15 Oct 2018 05:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=/PR/U/AX2RhoMph28nvtYnU8rTDBHHGBQ0O/iaGYqvc=; b=BMKivcKbI+x0Y4sWpJHyolHUxOS9s69ieyfa99V458mPoNYUMIuroBbEwPbJbmHDg6 8PM68u5UTeeu/idBG7+XcKuk0ePD7PYE/HU+b2w+4OWS2EL1bQ9RhQKz6p8iIa6ImrJu BNTpxn/9m0Qgq+lP8aXALxw3TIdIHLEIN2aZ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=/PR/U/AX2RhoMph28nvtYnU8rTDBHHGBQ0O/iaGYqvc=; b=PKWl17rICXsIxJPUGXHCy3UzOmKYsMr/VbcFTvo8aHe69/LcCgY5p2/A+gzWq4lT1h cKrXzaJzTeLwEUJjW6o3Pz+Oc/SJ5f+tH0D+agFg1KkZUccZXuQCK9zPDsxBSYFENAxs 5h4rqabk9YJKKjPgYIvJ4bNH6PisPAJ9NPRgM9SXkI3zXG5yfUgNZWNwqP31SByHTysP CtMgZ/8GF0bPMv5WFnbqIdbvDxVlpfK7mDdPU2MLGtGuLcs5GbMd8Y51TY/lTmXXXbjn ACmBEdWjqPS6VJRedJiCU7cBY9rAjcx+l7LTm/CLste2eSPdT7KA1SrlAtcmAu0vS+BK 5j0A== X-Gm-Message-State: ABuFfoi+704kSPm3iL6yBXKl4qMrUzbqmKB24/METkdDm7Fb58e9aRk7 W2ivJrsGU5dTslzOxGMIBFiOkw== X-Google-Smtp-Source: ACcGV63nATLtJnR/+LKQNNBhTAtjx5cN+8M4024GUJXOenZlN6yUfsm0tNlNXF3aXMiw6W1+CaiQjQ== X-Received: by 2002:a2e:8589:: with SMTP id b9-v6mr10900340lji.122.1539607700587; Mon, 15 Oct 2018 05:48:20 -0700 (PDT) Received: from centauri.lan (h-229-118.A785.priv.bahnhof.se. [5.150.229.118]) by smtp.gmail.com with ESMTPSA id h87-v6sm2440966lji.9.2018.10.15.05.48.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 Oct 2018 05:48:19 -0700 (PDT) From: Niklas Cassel To: viresh.kumar@linaro.org, sboyd@kernel.org, andy.gross@linaro.org, ulf.hansson@linaro.org, collinsd@codeaurora.org, mka@chromium.org, robh@kernel.org, rnayak@codeaurora.org Cc: devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Niklas Cassel Subject: [RFC PATCH] dt-bindings: opp: Extend qcom-opp bindings with properties needed for CPR Date: Mon, 15 Oct 2018 14:47:49 +0200 Message-Id: <20181015124749.27276-1-niklas.cassel@linaro.org> X-Mailer: git-send-email 2.17.2 In-Reply-To: <20180627045234.27403-3-rnayak@codeaurora.org> References: <20180627045234.27403-3-rnayak@codeaurora.org> Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org 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 --- 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-: 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 and matching qcom,fuse-level- property + will be enabled for all OPPs. If the platform doesn't pick a specific + or the doesn't match with any qcom,fuse-level- + properties, then qcom,fuse-level property shall be used, if present.