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"?
