Re: [PATCH v1 0/4] Split SDM845 interconnect nodes and consolidate RPMh support

[Evan Green]

On Sun, Dec 15, 2019 at 9:59 PM David Dai <daidavid1@xxxxxxxxxxxxxx> 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"?