linux-kernel - Re: [PATCH 1/2] dt-bindings: interconnect: Update Qualcomm SDM845 DT bindings

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: <150445a8-a6be-aa46-026b-1ad254128037@codeaurora.org>
Date:   Wed, 24 Jul 2019 13:42:19 -0700
From:   David Dai <daidavid1@...eaurora.org>
To:     Stephen Boyd <swboyd@...omium.org>, bjorn.andersson@...aro.org,
        georgi.djakov@...aro.org, robh+dt@...nel.org
Cc:     evgreen@...gle.com, ilina@...eaurora.org, seansw@....qualcomm.com,
        elder@...aro.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        linux-pm@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: interconnect: Update Qualcomm SDM845 DT
 bindings


On 7/24/2019 11:27 AM, Stephen Boyd wrote:
> Quoting David Dai (2019-07-24 10:22:57)
>> 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.
> Ok. I get it now. The MMIO nodes will be interconnect providers and
> they'll know what RSCs they can use by exposing the same RSC "resource"
> multiple times for each RSC that can be targeted? This is what the
> postfix is with _DISP on your examples? Presumably there's an _APPS
> version of the same prefixed endpoint in case the consumer wants to use
> the APPS RSC instead of the DISP one, or maybe there's just no postfix
> in this case because APPS is the "default".

Right, the suffixes will denote the RSC association and will default to 
APPS otherwise.

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