[v1,0/4] Split SDM845 interconnect nodes and consolidate RPMh support

Message

David Dai Dec. 16, 2019, 5:58 a.m. UTC

While there are no current consumers of the SDM845 interconnect device in
devicetree, take this opportunity to redefine the interconnect device nodes
as the previous definitions of using a single child node under the apps_rsc
device did not accurately capture the description of the hardware.
The Network-On-Chip (NoC) interconnect devices should be represented in a
manner akin to QCS404 platforms[1] where there is a separation of NoC devices
and its RPM/RPMh counterparts.

The bcm-voter devices are representing the RPMh devices that the interconnect
providers need to communicate with and there can be more than one instance of
the Bus Clock Manager (BCM) which can live under different instances of Resource
State Coordinators (RSC). There are display use cases where consumers may need
to target a different bcm-voter (Some display specific RSC) than the default,
and there needs to be a way to represent this connection in devicetree.

This patches series extends the discussions[2][3] involving the SDM845
interconnect bindings by adding accompanying driver implementations
using the split NoC devices. Some of the code used to support the SDM845
provider driver are refactored into common modules that can used by other
RPMh based interconnect providers such as SC7180[4]. The first patch also
updates existing sdm845 binding documentation to DT schema format using
json-schema.

[1]: https://lkml.org/lkml/2019/6/13/143
[2]: https://lkml.org/lkml/2019/7/19/1063
[3]: https://lkml.org/lkml/2019/10/16/1793
[4]: https://lkml.org/lkml/2019/11/26/389

David Dai (4):
  dt-bindings: interconnect: Update Qualcomm SDM845 DT bindings
  interconnect: qcom: Consolidate interconnect RPMh support
  interconnect: qcom: sdm845: Split qnodes into their respective NoCs
  arm64: dts: sdm845: Redefine interconnect provider DT nodes

 .../bindings/interconnect/qcom,bcm-voter.yaml      |   45 +
 .../bindings/interconnect/qcom,sdm845.txt          |   24 -
 .../bindings/interconnect/qcom,sdm845.yaml         |  108 ++
 arch/arm64/boot/dts/qcom/sdm845.dtsi               |   61 +-
 drivers/interconnect/qcom/Kconfig                  |    8 +
 drivers/interconnect/qcom/Makefile                 |    6 +
 drivers/interconnect/qcom/bcm-voter.c              |  356 +++++++
 drivers/interconnect/qcom/bcm-voter.h              |   28 +
 drivers/interconnect/qcom/icc-rpmh.c               |  158 +++
 drivers/interconnect/qcom/icc-rpmh.h               |  150 +++
 drivers/interconnect/qcom/sdm845.c                 | 1122 ++++++++------------
 include/dt-bindings/interconnect/qcom,sdm845.h     |  263 ++---
 12 files changed, 1523 insertions(+), 806 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,bcm-voter.yaml
 delete mode 100644 Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
 create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml
 create mode 100644 drivers/interconnect/qcom/bcm-voter.c
 create mode 100644 drivers/interconnect/qcom/bcm-voter.h
 create mode 100644 drivers/interconnect/qcom/icc-rpmh.c
 create mode 100644 drivers/interconnect/qcom/icc-rpmh.h

Comments

Evan Green Jan. 7, 2020, 11:45 p.m. UTC | #1

On Sun, Dec 15, 2019 at 9:59 PM David Dai <[e-mail]> wrote:
>
> While there are no current consumers of the SDM845 interconnect device in
> devicetree, take this opportunity to redefine the interconnect device nodes
> as the previous definitions of using a single child node under the apps_rsc
> device did not accurately capture the description of the hardware.
> The Network-On-Chip (NoC) interconnect devices should be represented in a
> manner akin to QCS404 platforms[1] where there is a separation of NoC devices
> and its RPM/RPMh counterparts.
>
> The bcm-voter devices are representing the RPMh devices that the interconnect
> providers need to communicate with and there can be more than one instance of
> the Bus Clock Manager (BCM) which can live under different instances of Resource
> State Coordinators (RSC). There are display use cases where consumers may need
> to target a different bcm-voter (Some display specific RSC) than the default,
> and there needs to be a way to represent this connection in devicetree.

So for my own understanding, the problem here is that things want to
vote for interconnect bandwidth within a specific RSC context? Where
normally the RSC context is simply "Apps@EL1", we might also have
"Apps@EL3" for trustzone, or in the case we're coding for,
"display-specific RSC context". I guess this context might stay on
even if Apps@EL1 votes are entirely discounted or off? So then would
there be an additional interconnect provider for "display context RSC"
next to apps_bcm_voter? Would that expose all the same nodes as
apps_bcm_voter, or a different set of nodes?

Assuming it's exposing some of the same nodes as apps_bcm_voter, the
other way to do this would be increasing #interconnect-cells, and
putting the RSC context there. Did you choose not to go that way
because nearly all the clients would end up specifying the same thing
of "Apps@EL1"?

David Dai Jan. 14, 2020, 11:36 p.m. UTC | #2

Hi Evan,

On 1/7/2020 3:45 PM, Evan Green wrote:
> On Sun, Dec 15, 2019 at 9:59 PM David Dai <[e-mail]> wrote:
>> While there are no current consumers of the SDM845 interconnect device in
>> devicetree, take this opportunity to redefine the interconnect device nodes
>> as the previous definitions of using a single child node under the apps_rsc
>> device did not accurately capture the description of the hardware.
>> The Network-On-Chip (NoC) interconnect devices should be represented in a
>> manner akin to QCS404 platforms[1] where there is a separation of NoC devices
>> and its RPM/RPMh counterparts.
>>
>> The bcm-voter devices are representing the RPMh devices that the interconnect
>> providers need to communicate with and there can be more than one instance of
>> the Bus Clock Manager (BCM) which can live under different instances of Resource
>> State Coordinators (RSC). There are display use cases where consumers may need
>> to target a different bcm-voter (Some display specific RSC) than the default,
>> and there needs to be a way to represent this connection in devicetree.
> So for my own understanding, the problem here is that things want to
> vote for interconnect bandwidth within a specific RSC context? Where
> normally the RSC context is simply "Apps@EL1", we might also have
> "Apps@EL3" for trustzone, or in the case we're coding for,
> "display-specific RSC context". I guess this context might stay on
> even if Apps@EL1 votes are entirely discounted or off?
That's correct, the state of those votes are tied to the state of that 
execution environment. So even if the Apps CPU goes into a low power 
mode, other context specific vote will still stick.
>   So then would
> there be an additional interconnect provider for "display context RSC"
> next to apps_bcm_voter? Would that expose all the same nodes as
> apps_bcm_voter, or a different set of nodes?

We trim down the topology to what each execution environment needs, so 
each EE really only "sees" a subset of the entire SoC's topology. In 
this specific case, the display context RSC would only expose a small 
subset of the topology that Apps@EL1 would see.

>
> Assuming it's exposing some of the same nodes as apps_bcm_voter, the
> other way to do this would be increasing #interconnect-cells, and
> putting the RSC context there. Did you choose not to go that way
> because nearly all the clients would end up specifying the same thing
> of "Apps@EL1"?
That's correct, the majority of the consumers will stay with default 
Apps@EL1 context.