1 Corner/Voltage Regulator Pairs
1.1 RBCPR
New platform uses RBCPR (RapidBridge Core Power Reduction) hardware feature, with that voting for absolute voltage of VDD CX is not required. Hence vote for corner of VDD CX which uses nominal corner voltage on VDD CX.
There's CPR for the CPU voltage and there's CPR for the digital voltage. The RPM controls the latter, and so all we have on the Linux side is an API to request corners, not voltages, for digital logic. Almost everything in the SoC is using the digital voltage, so having USB be the only consumer of this voltage and then be the only driver telling the RPM what corner or voltage we want here is potentially very dangerous.
Consider the case where USB goes to runtime suspend and USB driver says it only needs "low" voltage. This might cause RPM to go and lower the voltage because no other master in the system is asking for anything else besides "low". But we may have other hardware blocks using the digital logic supply in the system, e.g. GPU is running at max speed, and those blocks need "high" voltage. We just browned out the GPU.
So maybe we should just remove this code from the USB driver for now? By default the voltage is nominal, and when the bus clocks are maxed out the voltage goes to the highest level. So as long as RPM bus clocks are maxed this code is not doing anything.
My plan for handling corners is to hide it behind the OPP(Operating Performance Points) framework and/or generic power domains. The digital logic supply is really a regulator that supplies a large power domain called CX. All the digital logic in the SoC lives within this power domain. As an aside, it's quite typical that a hardware block sits in a few domains: digital, analog, memories, etc. so this may require us to expand the ability for devices to be in multiple PM domains at one time. But regardless, the frequency that a device in the digital logic domain is running at is used to pick a voltage that is "maxed" across all devices and factors into the voltage requirement of the domain. Another way to put it is that each device casts a "vote" for the CX voltage based on their frequency and the largest uV wins and is set.
This is further complicated by CPR, which takes away the uV units from this calculation and transforms that into a "corner". Each hardware block now knows what voltage "corner" it needs for CX when their clock is at a particular frequency. We'll probably need to add some sort of "corner" property to the OPP binding to express this. Hopefully it can be a generic power domain level thing (keep reading!).
So I'm thinking each device gets an OPP table of frequency to voltage/corner pairs. Devices would change their OPP through OPP framework and this would adjust the clk and voltage/corner appropriately. To make things generic between voltages and corners, we could hide that part behind the genpd framework by having OPP pick a "power level" that the power domain should be at. On SoCs where the power domain is supplied by a regulator the level would be translated into a uV (probably need some sort of level to uV table in DT or just put that in the code). On SoCs where the power domain is supplied by a regulator with corners, the level would be used as is and sent to the RPM. OPP framework wouldn't care, as long as the genpd driver handles the voltage vs. corner stuff.
