Hi Bjorn, On 11/10/2014 02:52 PM, Bjorn Andersson wrote: > During the review of the Qualcomm SMD RPM regulators [1], I got (offline) > feedback that my implementation did not handle "sleep states". As the problem > is shared between all families of Qualcomm platforms I use [2] (family A) to > propose a solution (as I hope to get that merged sooner). > > The "sleep states" comment boils down to certain regulators (or rpm resources > in general) are used by the currently clocked/running CPU(s) and can not be > disabled while we're still running. This is the first flaw in the argument. There are certain regulators that are used to power the clocks for CPUs that can be disabled while we're running as long as the CPUs aren't using these clocks. I'll explain further down below. > Further more, these resources are shared > with peripherals in the system; e.g. LDO12 on PM8941 is used to clock the CPU > and WiFi/BT PLLs as well as providing power to the display in our devices. So > the suspend functionality in the regulator framework doesn't cut it. Furthermore, we can trigger a transition to the sleep set during idle paths so suspend definitely won't cut it. > > > The downstream solution to this is to expose 3 regulators per regulator > resource, each specified to control the active mode, sleep mode or both modes > respectively. Peripherals are directed to use the "both" regulator while the > CPUs are directed to the "active only" regulator. > > After reviewing this solution and looking at what it's actually achieving I > here propose flagging these regulators to have "deferred disable"; > * we consider the specific regulators as always-on _while running_ > * hence, disable and enable affect only the sleep state > * we update both active and sleep state with all other properties > > This gives us a single regulator exposed for the resource, that will be kept on > with parameters as specified by the clients if it's referenced and upon loosing > the last reference (disabling all consumers) it will be turned off when the > CPU(s) are sleeping. > > > As far as I can see this should give the same behaviour as we have downstream, > without the need for playing tricks with how we expose the regulators. However > there's plenty of details hidden in that code, so I hope to get some feedback > from the Qualcomm engineers on this. First some background. The Krait CPUs are clocked by dedicated per-cpu PLLs and a global PLL. The dedicated per-cpu PLLs are supplied by a regulator (actually a handful of them, but let's just assume one for the sake of argument). When we go to suspend or idle we will turn off these dedicated per-cpu PLLs and switch the CPUs to source off the global PLL. The global PLL is also used as the lowest rate that the CPUs can run at. We'd like to not communicate with the RPM unnecessarily during idle/suspend to turn off these resources when we go idle/suspend because it takes more time and thus more power. So the CPU really wants to only be voting for the HFPLL regulator supplies in the active set. This way, if we're not using the HFPLLs (i.e. the CPUs are all running off the global PLL), then we can disable the regulator in the active set (RPM code only caches sleep set so we won't be doing unnecessary flushes in the idle/suspend path). The clock driver will make sure to turn off the HFPLLs before we go into a sleep state that would trigger a switch from active to sleep set (commonly referred to as RPM notification). It very well could be that there are other consumers of the same regulator, but that doesn't matter to the CPU clock driver because it only cares about the active set. Now you may ask why can't the CPU clock driver disable the regulator when the HFPLL is disabled? We don't do that in this case because a) it causes more RPM communication overhead and b) we will be in atomic context when the HFPLL is disabled during idle/suspend and the regulator APIs are sleeping calls. In the non-idle/suspend path we will disable the regulator. Also the active/sleep sets are about more than just on/off state. We may have a situation where the active set voltage (or some other attribute like current, mode, etc.) is different than the sleep set voltage. For example, the CPU is supplied by a digital logic regulator that is shared with other digital logic in the SoC (GPU, wifi, etc.). The CPU may require some high voltage, but the GPU only needs some lower voltage. The suspend/idle code relies on the fact that the GPU is voting on the active+sleep regulator while the CPU is voting on the active only regulator so that the RPM can automatically switch between high voltage and low voltage when the CPU notifies the RPM that it's gone idle (or the CPU wakes up). -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
