On 26-11-20, 19:45, AngeloGioacchino Del Regno wrote: > On new SoCs (SDM845 onwards) the Operating State Manager (OSM) is > being programmed in the bootloader and write-protected by the > hypervisor, leaving to the OS read-only access to some of its > registers (in order to read the Lookup Tables and also some > status registers) and write access to the p-state register, for > for the OS to request a specific performance state to trigger a > DVFS switch on the CPU through the OSM hardware. > > On old SoCs though (MSM8998, SDM630/660 and variants), the > bootloader will *not* initialize the OSM (and the CPRh, as it > is a requirement for it) before booting the OS, making any > request to trigger a performance state change ineffective, as > the hardware doesn't have any Lookup Table, nor is storing any > parameter to trigger a DVFS switch. In this case, basically all > of the OSM registers are *not* write protected for the OS, even > though some are - but write access is granted through SCM calls. > > This commit introduces support for OSM programming, which has to > be done on these old SoCs that were distributed (almost?) always > with a bootloader that does not do any CPRh nor OSM init before > booting the kernel. > In order to program the OSM on these SoCs, it is necessary to > fullfill a "special" requirement: the Core Power Reduction > Hardened (CPRh) hardware block must be initialized, as the OSM > is "talking" to it in order to perform the Voltage part of DVFS; > here, we are calling initialization of this through Linux generic > power domains, specifically by requesting a genpd attach from the > qcom-cpufreq-hw driver, which will give back voltages associated > to each CPU frequency that has been declared in the OPPs, scaled > and interpolated with the previous one, and will also give us > parameters for the Array Power Mux (APM) and mem-acc, in order > for this driver to be then able to generate the Lookup Tables > that will be finally programmed to the OSM hardware. > > After writing the parameters to the OSM and enabling it, all the > programming work will never happen anymore until a OS reboot, so > all of the allocations and "the rest" will be disposed-of: this > is done mainly to leave the code that was referred only to the > new SoCs intact, as to also emphasize on the fact that the OSM > HW is, in the end, the exact same; apart some register offsets > that are slightly different, the entire logic is the same. > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxxx> > --- > drivers/cpufreq/qcom-cpufreq-hw.c | 914 +++++++++++++++++++++++++++++- > 1 file changed, 884 insertions(+), 30 deletions(-) This is a lot of code, I need someone from Qcom's team to review it and make sure it doesn't break anything for the existing platforms. -- viresh
