Linux-PM Archive on lore.kernel.org
 help / color / Atom feed
From: David Dai <daidavid1@codeaurora.org>
To: Stephen Boyd <swboyd@chromium.org>,
	bjorn.andersson@linaro.org, georgi.djakov@linaro.org,
	robh+dt@kernel.org
Cc: evgreen@google.com, ilina@codeaurora.org,
	seansw@qti.qualcomm.com, elder@linaro.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: interconnect: Update Qualcomm SDM845 DT bindings
Date: Wed, 24 Jul 2019 10:22:57 -0700
Message-ID: <8efd5c48-5d3a-97e1-1dec-6a9cdc4c8ef6@codeaurora.org> (raw)
In-Reply-To: <5d3868a9.1c69fb81.876aa.ac30@mx.google.com>


On 7/24/2019 7:18 AM, Stephen Boyd wrote:
> Quoting David Dai (2019-07-23 14:48:42)
>> On 7/23/2019 7:42 AM, Stephen Boyd wrote:
>>> Quoting David Dai (2019-07-19 13:32:23)
>>>> +- compatible : shall contain only one of the following:
>>>> +                       "qcom,sdm845-bcm-voter",
>>>> +
>>>> +Examples:
>>>> +
>>>> +apps_rsc: rsc@179c0000 {
>>> But there isn't a reg property.
>> I'll change this to the generic example with just apps_rsc: rsc {
>>>> +       label = "apps_rsc";
>>> Is label required?
> Any answer?
Not required.
>>>> +       compatible = "qcom,rpmh-rsc";
>>>> +
>>>> +       apps_bcm_voter: bcm_voter {
>>>> +               compatible = "qcom,sdm845-bcm-voter";
>>>> +       };
>>>> +}
>>>> +
>>>> +disp_rsc: rsc@179d0000 {
>>>> +       label = "disp_rsc";
>>>> +       compatible = "qcom,rpmh-rsc";
>>>> +
>>>> +       disp_bcm_voter: bcm_voter {
>>>> +               compatible = "qcom,sdm845-bcm-voter";
>>>> +       };
>>>> +}
>>>> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt b/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
>>>> index 5c4f1d9..27f9ed9 100644
>>>> --- a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
>>>> +++ b/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
> [...]
>>>> +
>>>> +mem_noc: interconnect@1380000 {
>>>> +       compatible = "qcom,sdm845-mem_noc";
>>>> +       reg = <0 0x1380000 0 0x27200>;
>>>> +       #interconnect-cells = <1>;
>>>> +       qcom,bcm-voter = <&apps_bcm_voter>, <&disp_bcm_voter>;
>>>> +};
>>> How does a consumer target a particular RSC? For example, how can
>>> display decide to use the disp_bcm_voter node from mem_noc here? Maybe
>>> you can add that consumer to the example?
>> I was thinking that the association between the bcm voters and the icc
>> nodes would be handled by the interconnect provider, and that there
>> would be a set of display specific icc nodes with their own unique IDs
>> that the consumers could reference. I will mention this as part of the
>> description and provide an example.
>>
>> Ex: interconnects = <&mmss_noc MASTER_MDP0_DISP &mem_noc SLAVE_EBI_DISP>;
>>
> It looks backwards to me. Don't the consumers want to consume a
> particular RSC, i.e. apps or display RSC, so they can choose where to
> put the bcm vote and then those RSCs want to find MMIO registers for
> mmss_noc or mem_noc that they have to write to tune something else like
> QoS? If the MMIO space is the provider then I'm lost how it can
> differentiate between the RSCs that may be targetting the particular
> NoC.
The way that I view this is that the consumers consume both bandwidth 
and QoS from these physical NoC devices by getting some path between two 
endpoints on these different NoCs and applying some constraints. The NoC 
providers can accomplish that either by writing to MMIO spaces or by 
talking to some remote processor/hardware to tune its clock speed. The 
consumer doesn't interact with the RSCs directly, but can select a 
different bcm voter based on the endpoints that are associated with a 
particular bcm(apps or disp rsc). Each node(endpoints) will have its own 
BCM designation and an unique bcm voter.
> Maybe I've just completely missed something and this is all decided
> already. If so, sorry, I'm just trying to understand.
No problem, this just means I need to do a better job of explaining.

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-19 20:32 [PATCH 0/2] Redefine interconnect provider DT nodes for SDM845 David Dai
2019-07-19 20:32 ` [PATCH 1/2] dt-bindings: interconnect: Update Qualcomm SDM845 DT bindings David Dai
2019-07-21 19:10   ` Bjorn Andersson
2019-07-23 14:42   ` Stephen Boyd
2019-07-23 21:48     ` David Dai
2019-07-24 14:18       ` Stephen Boyd
2019-07-24 17:22         ` David Dai [this message]
2019-07-24 18:27           ` Stephen Boyd
2019-07-24 20:42             ` David Dai
2019-07-19 20:32 ` [PATCH 2/2] arm64: dts: sdm845: Redefine interconnect provider DT nodes David Dai
2019-07-21 19:13   ` Bjorn Andersson
2019-07-23 18:24     ` David Dai

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8efd5c48-5d3a-97e1-1dec-6a9cdc4c8ef6@codeaurora.org \
    --to=daidavid1@codeaurora.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=elder@linaro.org \
    --cc=evgreen@google.com \
    --cc=georgi.djakov@linaro.org \
    --cc=ilina@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=seansw@qti.qualcomm.com \
    --cc=swboyd@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-PM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-pm/0 linux-pm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-pm linux-pm/ https://lore.kernel.org/linux-pm \
		linux-pm@vger.kernel.org linux-pm@archiver.kernel.org
	public-inbox-index linux-pm


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-pm


AGPL code for this site: git clone https://public-inbox.org/ public-inbox