summaryrefslogtreecommitdiff
path: root/drivers/cpufreq
AgeCommit message (Collapse)AuthorFilesLines
2024-01-11cpufreq: dt-platdev: Add JH7110 SOC to the allowlistMason Huo1-0/+2
Add the compatible strings for supporting the generic cpufreq driver on the StarFive JH7110 SoC. Signed-off-by: Mason Huo <mason.huo@starfivetech.com>
2023-08-03cpufreq: intel_pstate: Drop ACPI _PSS states table patchingRafael J. Wysocki1-14/+0
commit e8a0e30b742f76ebd0f3b196973df4bf65d8fbbb upstream. After making acpi_processor_get_platform_limit() use the "no limit" value for its frequency QoS request when _PPC returns 0, it is not necessary to replace the frequency corresponding to the first _PSS return package entry with the maximum turbo frequency of the given CPU in intel_pstate_init_acpi_perf_limits() any more, so drop the code doing that along with the comment explaining it. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Hagar Hemdan <hagarhem@amazon.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19cpufreq: mediatek: correct voltages for MT7622 and MT7623Daniel Golle1-3/+10
[ Upstream commit f85534113f5ae90a52521cdb9e9977a43ee42626 ] The MT6380 regulator typically used together with MT7622 does not support the current maximum processor and SRAM voltage in the cpufreq driver (1360000uV). For MT7622 limit processor and SRAM supply voltages to 1350000uV to avoid having the tracking algorithm request unsupported voltages from the regulator. On MT7623 there is no separate SRAM supply and the maximum voltage used is 1300000uV. Create dedicated platform data for MT7623 to cover that case as well. Fixes: 0883426fd07e3 ("cpufreq: mediatek: Raise proc and sram max voltage for MT7622/7623") Suggested-by: Jia-wei Chang <Jia-wei.Chang@mediatek.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19cpufreq: intel_pstate: Fix energy_performance_preference for passiveTero Kristo1-0/+2
[ Upstream commit 03f44ffb3d5be2fceda375d92c70ab6de4df7081 ] If the intel_pstate driver is set to passive mode, then writing the same value to the energy_performance_preference sysfs twice will fail. This is caused by the wrong return value used (index of the matched energy_perf_string), instead of the length of the passed in parameter. Fix by forcing the internal return value to zero when the same preference is passed in by user. This same issue is not present when active mode is used for the driver. Fixes: f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive mode with HWP enabled") Reported-by: Niklas Neronin <niklas.neronin@intel.com> Signed-off-by: Tero Kristo <tero.kristo@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-05cpufreq: amd-pstate: Add ->fast_switch() callbackGautham R. Shenoy1-7/+30
commit 4badf2eb1e986bdbf34dd2f5d4c979553a86fe54 upstream. Schedutil normally calls the adjust_perf callback for drivers with adjust_perf callback available and fast_switch_possible flag set. However, when frequency invariance is disabled and schedutil tries to invoke fast_switch. So, there is a chance of kernel crash if this function pointer is not set. To protect against this scenario add fast_switch callback to amd_pstate driver. Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State") Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Signed-off-by: Wyes Karny <wyes.karny@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-05cpufreq: amd-pstate: Update policy->cur in amd_pstate_adjust_perf()Wyes Karny1-1/+7
commit 3bf8c6307bad5c0cc09cde982e146d847859b651 upstream. Driver should update policy->cur after updating the frequency. Currently amd_pstate doesn't update policy->cur when `adjust_perf` is used. Which causes /proc/cpuinfo to show wrong cpu frequency. Fix this by updating policy->cur with correct frequency value in adjust_perf function callback. - Before the fix: (setting min freq to 1.5 MHz) [root@amd]# cat /proc/cpuinfo | grep "cpu MHz" | sort | uniq --count 1 cpu MHz : 1777.016 1 cpu MHz : 1797.160 1 cpu MHz : 1797.270 189 cpu MHz : 400.000 - After the fix: (setting min freq to 1.5 MHz) [root@amd]# cat /proc/cpuinfo | grep "cpu MHz" | sort | uniq --count 1 cpu MHz : 1753.353 1 cpu MHz : 1756.838 1 cpu MHz : 1776.466 1 cpu MHz : 1776.873 1 cpu MHz : 1777.308 1 cpu MHz : 1779.900 183 cpu MHz : 1805.231 1 cpu MHz : 1956.815 1 cpu MHz : 2246.203 1 cpu MHz : 2259.984 Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State") Signed-off-by: Wyes Karny <wyes.karny@amd.com> [ rjw: Subject edits ] Cc: 5.17+ <stable@vger.kernel.org> # 5.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-05-11cpufreq: use correct unit when verify cur freqSanjay Chandrashekara1-1/+1
[ Upstream commit 44295af5019f1997d038ad2611086a2d1e2af167 ] cpufreq_verify_current_freq checks() if the frequency returned by the hardware has a slight delta with the valid frequency value last set and returns "policy->cur" if the delta is within "1 MHz". In the comparison, "policy->cur" is in "kHz" but it's compared against HZ_PER_MHZ. So, the comparison range becomes "1 GHz". Fix this by comparing against KHZ_PER_MHZ instead of HZ_PER_MHZ. Fixes: f55ae08c8987 ("cpufreq: Avoid unnecessary frequency updates due to mismatch") Signed-off-by: Sanjay Chandrashekara <sanjayc@nvidia.com> [ sumit gupta: Commit message update ] Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11cpufreq: qcom-cpufreq-hw: Revert adding cpufreq qosBjorn Andersson1-14/+0
[ Upstream commit e2b47e585931a988c856fd4ba31e1296f749aee3 ] The OSM/EPSS hardware controls the frequency of each CPU cluster based on requests from the OS and various throttling events in the system. While throttling is in effect the related dcvs interrupt will be kept high. The purpose of the code handling this interrupt is to continuously report the thermal pressure based on the throttled frequency. The reasoning for adding QoS control to this mechanism is not entirely clear, but the introduction of commit 'c4c0efb06f17 ("cpufreq: qcom-cpufreq-hw: Add cpufreq qos for LMh")' causes the scaling_max_frequncy to be set to the throttled frequency. On the next iteration of polling, the throttled frequency is above or equal to the newly requested frequency, so the polling is stopped. With cpufreq limiting the max frequency, the hardware no longer report a throttling state and no further updates to thermal pressure or qos state are made. The result of this is that scaling_max_frequency can only go down, and the system becomes slower and slower every time a thermal throttling event is reported by the hardware. Even if the logic could be improved, there is no reason for software to limit the max freqency in response to the hardware limiting the max frequency. At best software will follow the reported hardware state, but typically it will cause slower backoff of the throttling. This reverts commit c4c0efb06f17fa4a37ad99e7752b18a5405c76dc. Fixes: c4c0efb06f17 ("cpufreq: qcom-cpufreq-hw: Add cpufreq qos for LMh") Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11cpufreq: mediatek: Raise proc and sram max voltage for MT7622/7623AngeloGioacchino Del Regno1-2/+11
[ Upstream commit 0883426fd07e39355362e3f2eb9aee1a154dcaf6 ] During the addition of SRAM voltage tracking for CCI scaling, this driver got some voltage limits set for the vtrack algorithm: these were moved to platform data first, then enforced in a later commit 6a17b3876bc8 ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()") using these as max values for the regulator_set_voltage() calls. In this case, the vsram/vproc constraints for MT7622 and MT7623 were supposed to be the same as MT2701 (and a number of other SoCs), but that turned out to be a mistake because the aforementioned two SoCs' maximum voltage for both VPROC and VPROC_SRAM is 1.36V. Fix that by adding new platform data for MT7622/7623 declaring the right {proc,sram}_max_volt parameter. Fixes: ead858bd128d ("cpufreq: mediatek: Move voltage limits to platform data") Fixes: 6a17b3876bc8 ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11cpufreq: mediatek: raise proc/sram max voltage for MT8516Jia-Wei Chang1-2/+11
[ Upstream commit d3296bb4cafd4bad4a5cf2eeab9d19cc94f9e30e ] Since the upper boundary of proc/sram voltage of MT8516 is 1300 mV, which is greater than the value of MT2701 1150 mV, we fix it by adding the corresponding platform data and specify proc/sram_max_volt to support MT8516. Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Fixes: ead858bd128d ("cpufreq: mediatek: Move voltage limits to platform data") Fixes: 6a17b3876bc8 ("cpufreq: mediatek: Refine mtk_cpufreq_voltage_tracking()") Reported-by: Nick Hainke <vincent@systemli.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11cpufreq: mediatek: fix KP caused by handler usage after regulator_put/clk_putJia-Wei Chang1-32/+30
[ Upstream commit d51e106240bc755cbe59634b70d567c192b045b2 ] Any kind of failure in mtk_cpu_dvfs_info_init() will lead to calling regulator_put() or clk_put() and the KP will occur since the regulator/clk handlers are used after released in mtk_cpu_dvfs_info_release(). To prevent the usage after regulator_put()/clk_put(), the regulator/clk handlers are addressed in a way of "Free the Last Thing Style". Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Fixes: 4b9ceb757bbb ("cpufreq: mediatek: Enable clocks and regulators") Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Suggested-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-05-11cpufreq: mediatek: fix passing zero to 'PTR_ERR'Jia-Wei Chang1-5/+5
[ Upstream commit d51c63230994f167126d9d8381011b4cb2b0ad22 ] In order to prevent passing zero to 'PTR_ERR' in mtk_cpu_dvfs_info_init(), we fix the return value of of_get_cci() using error pointer by explicitly casting error number. Signed-off-by: Jia-Wei Chang <jia-wei.chang@mediatek.com> Fixes: 0daa47325bae ("cpufreq: mediatek: Link CCI device to CPU") Reported-by: Dan Carpenter <error27@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10cpufreq: davinci: Fix clk use after freeUwe Kleine-König1-1/+3
[ Upstream commit 5d8f384a9b4fc50f6a18405f1c08e5a87a77b5b3 ] The remove function first frees the clks and only then calls cpufreq_unregister_driver(). If one of the cpufreq callbacks is called just before cpufreq_unregister_driver() is run, the freed clks might be used. Fixes: 6601b8030de3 ("davinci: add generic CPUFreq driver for DaVinci") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-14cpufreq: qcom-hw: Fix cpufreq_driver->get() for non-LMH systemsDouglas Anderson1-11/+13
[ Upstream commit 51be2fffd65d9f9cb427030ab0ee85d791b4437d ] On a sc7180-based Chromebook, when I go to /sys/devices/system/cpu/cpu0/cpufreq I can see: cpuinfo_cur_freq:2995200 cpuinfo_max_freq:1804800 scaling_available_frequencies:300000 576000 ... 1708800 1804800 scaling_cur_freq:1804800 scaling_max_freq:1804800 As you can see the `cpuinfo_cur_freq` is bogus. It turns out that this bogus info started showing up as of commit c72cf0cb1d77 ("cpufreq: qcom-hw: Fix the frequency returned by cpufreq_driver->get()"). That commit seems to assume that everyone is on the LMH bandwagon, but sc7180 isn't. Let's go back to the old code in the case where LMH isn't used. Fixes: c72cf0cb1d77 ("cpufreq: qcom-hw: Fix the frequency returned by cpufreq_driver->get()") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> [ Viresh: Fixed the 'fixes' tag ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-01cpufreq: armada-37xx: stop using 0 as NULL pointerMiles Chen1-1/+1
[ Upstream commit 08f0adb193c008de640fde34a2e00a666c01d77c ] Use NULL for NULL pointer to fix the following sparse warning: drivers/cpufreq/armada-37xx-cpufreq.c:448:32: sparse: warning: Using plain integer as NULL pointer Signed-off-by: Miles Chen <miles.chen@mediatek.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-01cpufreq: Add SM6375 to cpufreq-dt-platdev blocklistKonrad Dybcio1-0/+1
[ Upstream commit faf28e240dd118d9521c68aeb9388b9b8f02d9d0 ] The Qualcomm SM6375 platform uses the qcom-cpufreq-hw driver, so add it to the cpufreq-dt-platdev driver's blocklist. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-01cpufreq: Add Tegra234 to cpufreq-dt-platdev blocklistSumit Gupta1-0/+1
[ Upstream commit 01c5bb0cc2a39fbc56ff9a5ef28b79447f0c2351 ] Tegra234 platform uses the tegra194-cpufreq driver, so add it to the blocklist in cpufreq-dt-platdev driver to avoid the cpufreq driver registration from there. Signed-off-by: Sumit Gupta <sumitg@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-01cpufreq: CPPC: Add u64 casts to avoid overflowingPierre Gondois1-5/+6
[ Upstream commit f5f94b9c8b805d87ff185caf9779c3a4d07819e3 ] The fields of the _CPC object are unsigned 32-bits values. To avoid overflows while using _CPC's values, add 'u64' casts. Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-01-18cpufreq: amd-pstate: fix kernel hang issue while amd-pstate unregisteringPerry Yuan1-0/+1
commit 4f3085f87b51a551a0647f218d4f324796ecb703 upstream. In the amd_pstate_adjust_perf(), there is one cpufreq_cpu_get() call to increase increments the kobject reference count of policy and make it as busy. Therefore, a corresponding call to cpufreq_cpu_put() is needed to decrement the kobject reference count back, it will resolve the kernel hang issue when unregistering the amd-pstate driver and register the `amd_pstate_epp` driver instance. Fixes: 1d215f0319 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State") Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Tested-by: Wyes Karny <wyes.karny@amd.com> Signed-off-by: Perry Yuan <perry.yuan@amd.com> Cc: 5.17+ <stable@vger.kernel.org> # 5.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-01-07cpufreq: Init completion before kobject_init_and_add()Yongqiang Liu1-1/+1
commit 5c51054896bcce1d33d39fead2af73fec24f40b6 upstream. In cpufreq_policy_alloc(), it will call uninitialed completion in cpufreq_sysfs_release() when kobject_init_and_add() fails. And that will cause a crash such as the following page fault in complete: BUG: unable to handle page fault for address: fffffffffffffff8 [..] RIP: 0010:complete+0x98/0x1f0 [..] Call Trace: kobject_put+0x1be/0x4c0 cpufreq_online.cold+0xee/0x1fd cpufreq_add_dev+0x183/0x1e0 subsys_interface_register+0x3f5/0x4e0 cpufreq_register_driver+0x3b7/0x670 acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq] do_one_initcall+0x13d/0x780 do_init_module+0x1c3/0x630 load_module+0x6e67/0x73b0 __do_sys_finit_module+0x181/0x240 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: 4ebe36c94aed ("cpufreq: Fix kobject memleak") Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 5.2+ <stable@vger.kernel.org> # 5.2+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-12-31cpufreq: amd_freq_sensitivity: Add missing pci_dev_put()Xiongfeng Wang1-0/+2
[ Upstream commit 91fda1f88c0968f1491ab150bb01690525af150a ] pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count after using pci_get_device(). Let's add it. Fixes: 59a3b3a8db16 ("cpufreq: AMD: Ignore the check for ProcFeedback in ST/CZ") Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31cpufreq: qcom-hw: Fix the frequency returned by cpufreq_driver->get()Manivannan Sadhasivam1-13/+29
[ Upstream commit c72cf0cb1d77f6b1b58c334dcc3d09fa13111c4c ] The cpufreq_driver->get() callback is supposed to return the current frequency of the CPU and not the one requested by the CPUFreq core. Fix it by returning the frequency that gets supplied to the CPU after the DCVS operation of EPSS/OSM. Fixes: 2849dd8bc72b ("cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver") Reported-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31cpufreq: qcom-hw: Fix memory leak in qcom_cpufreq_hw_read_lut()Chen Hui1-0/+1
[ Upstream commit 9901c21bcaf2f01fe5078f750d624f4ddfa8f81b ] If "cpu_dev" fails to get opp table in qcom_cpufreq_hw_read_lut(), the program will return, resulting in "table" resource is not released. Fixes: 51c843cf77bb ("cpufreq: qcom: Update the bandwidth levels on frequency change") Signed-off-by: Chen Hui <judy.chenhui@huawei.com> Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-11-22cpufreq: amd-pstate: add amd-pstate driver parameter for mode selectionPerry Yuan1-9/+27
When the amd_pstate driver is built-in users still need a method to be able enable or disable it depending upon their circumstance. Add support for an early parameter to do this. There is some performance degradation on a number of ASICs in the passive mode. This performance issue was originally discovered in shared memory systems but it has been proven that certain workloads on MSR systems also suffer performance issues. Set the amd-pstate driver as disabled by default to temporarily mitigate the performance problem. 1) with `amd_pstate=disable`, pstate driver will be disabled to load at kernel booting. 2) with `amd_pstate=passive`, pstate driver will be enabled and loaded as non-autonomous working mode supported in the low-level power management firmware. 3) If neither parameter is specified, the driver will be disabled by default to avoid triggering performance regressions in certain ASICs Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Tested-by: Wyes Karny <wyes.karny@amd.com> Signed-off-by: Perry Yuan <Perry.Yuan@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-11-22cpufreq: amd-pstate: change amd-pstate driver to be built-in typePerry Yuan2-11/+2
Currently when the amd-pstate and acpi_cpufreq are both built into kernel as module driver, amd-pstate will not be loaded by default in this case. Change amd-pstate driver as built-in type, it will resolve the loading sequence problem to allow user to make amd-pstate driver as the default cpufreq scaling driver. Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Tested-by: Wyes Karny <wyes.karny@amd.com> Signed-off-by: Perry Yuan <Perry.Yuan@amd.com> Fixes: ec437d71db77 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-11-22cpufreq: amd-pstate: cpufreq: amd-pstate: reset MSR_AMD_PERF_CTL register at ↵Wyes Karny1-0/+10
init MSR_AMD_PERF_CTL is guaranteed to be 0 on a cold boot. However, on a kexec boot, for instance, it may have a non-zero value (if the cpu was in a non-P0 Pstate). In such cases, the cores with non-P0 Pstates at boot will never be pushed to P0, let alone boost frequencies. Kexec is a common workflow for reboot on Linux and this creates a regression in performance. Fix it by explicitly setting the MSR_AMD_PERF_CTL to 0 during amd_pstate driver init. Cc: All applicable <stable@vger.kernel.org> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Tested-by: Wyes Karny <wyes.karny@amd.com> Signed-off-by: Wyes Karny <wyes.karny@amd.com> Signed-off-by: Perry Yuan <Perry.Yuan@amd.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-25cpufreq: intel_pstate: hybrid: Use known scaling factor for P-coresRafael J. Wysocki1-54/+15
Commit 46573fd6369f ("cpufreq: intel_pstate: hybrid: Rework HWP calibration") attempted to use the information from CPPC (the nominal performance in particular) to obtain the scaling factor allowing the frequency to be computed if the HWP performance level of the given CPU is known or vice versa. However, it turns out that on some platforms this doesn't work, because the CPPC information on them does not align with the contents of the MSR_HWP_CAPABILITIES registers. This basically means that the only way to make intel_pstate work on all of the hybrid platforms to date is to use the observation that on all of them the scaling factor between the HWP performance levels and frequency for P-cores is 78741 (approximately 100000/1.27). For E-cores it is 100000, which is the same as for all of the non-hybrid "core" platforms and does not require any changes. Accordingly, make intel_pstate use 78741 as the scaling factor between HWP performance levels and frequency for P-cores on all hybrid platforms and drop the dependency of the HWP calibration code on CPPC. Fixes: 46573fd6369f ("cpufreq: intel_pstate: hybrid: Rework HWP calibration") Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: 5.15+ <stable@vger.kernel.org> # 5.15+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-25cpufreq: intel_pstate: Read all MSRs on the target CPURafael J. Wysocki1-33/+33
Some of the MSR accesses in intel_pstate are carried out on the CPU that is running the code, but the values coming from them are used for the performance scaling of the other CPUs. This is problematic, for example, on hybrid platforms where MSR_TURBO_RATIO_LIMIT for P-cores and E-cores is different, so the values read from it on a P-core are generally not applicable to E-cores and the other way around. For this reason, make the driver access all MSRs on the target CPU on platforms using the "core" pstate_funcs callbacks which is the case for all of the hybrid platforms released to date. For this purpose, pass a CPU argument to the ->get_max(), ->get_max_physical(), ->get_min() and ->get_turbo() pstate_funcs callbacks and from there pass it to rdmsrl_on_cpu() or rdmsrl_safe_on_cpu() to access the MSR on the target CPU. Fixes: 46573fd6369f ("cpufreq: intel_pstate: hybrid: Rework HWP calibration") Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: 5.15+ <stable@vger.kernel.org> # 5.15+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-18cpufreq: sun50i: Switch to use dev_err_probe() helperYang Yingliang1-6/+3
In the probe path, convert pr_err() to dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. It's more simple in error path. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-10-18cpufreq: qcom-nvmem: Switch to use dev_err_probe() helperYang Yingliang1-5/+2
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. It's more simple in error path. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-10-18cpufreq: imx6q: Switch to use dev_err_probe() helperYang Yingliang1-3/+1
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. It's more simple in error path. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-10-18cpufreq: dt: Switch to use dev_err_probe() helperYang Yingliang1-4/+2
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. It's more simple in error path. Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-10-18cpufreq: qcom: remove unused parameter in function definitionFabien Parent1-4/+4
The speedbin_nvmem parameter is not used for get_krait_bin_format_{a,b}. Let's remove the parameter to make the code cleaner. Signed-off-by: Fabien Parent <fabien.parent@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-10-18cpufreq: qcom: fix writes in read-only memory regionFabien Parent1-1/+2
This commit fixes a kernel oops because of a write in some read-only memory: [ 9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8 ..snip.. [ 9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP ..snip.. [ 9.269161] Call trace: [ 9.276271] __memcpy+0x5c/0x230 [ 9.278531] snprintf+0x58/0x80 [ 9.282002] qcom_cpufreq_msm8939_name_version+0xb4/0x190 [ 9.284869] qcom_cpufreq_probe+0xc8/0x39c ..snip.. The following line defines a pointer that point to a char buffer stored in read-only memory: char *pvs_name = "speedXX-pvsXX-vXX"; This pointer is meant to hold a template "speedXX-pvsXX-vXX" where the XX values get overridden by the qcom_cpufreq_krait_name_version function. Since the template is actually stored in read-only memory, when the function executes the following call we get an oops: snprintf(*pvs_name, sizeof("speedXX-pvsXX-vXX"), "speed%d-pvs%d-v%d", speed, pvs, pvs_ver); To fix this issue, we instead store the template name onto the stack by using the following syntax: char pvs_name_buffer[] = "speedXX-pvsXX-vXX"; Because the `pvs_name` needs to be able to be assigned to NULL, the template buffer is stored in the pvs_name_buffer and not under the pvs_name variable. Cc: v5.7+ <stable@vger.kernel.org> # v5.7+ Fixes: a8811ec764f9 ("cpufreq: qcom: Add support for krait based socs") Signed-off-by: Fabien Parent <fabien.parent@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-10-18cpufreq: qcom: fix memory leak in error pathFabien Parent1-2/+5
If for some reason the speedbin length is incorrect, then there is a memory leak in the error path because we never free the speedbin buffer. This commit fixes the error path to always free the speedbin buffer. Cc: v5.7+ <stable@vger.kernel.org> # v5.7+ Fixes: a8811ec764f9 ("cpufreq: qcom: Add support for krait based socs") Signed-off-by: Fabien Parent <fabien.parent@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-10-18cpufreq: tegra194: Fix module loadingJon Hunter1-0/+1
When the Tegra194 CPUFREQ driver is built as a module it is not automatically loaded as expected on Tegra194 devices. Populate the MODULE_DEVICE_TABLE to fix this. Cc: v5.9+ <stable@vger.kernel.org> # v5.9+ Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-10-08Merge tag 'char-misc-6.1-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc and other driver updates from Greg KH: "Here is the large set of char/misc and other small driver subsystem changes for 6.1-rc1. Loads of different things in here: - IIO driver updates, additions, and changes. Probably the largest part of the diffstat - habanalabs driver update with support for new hardware and features, the second largest part of the diff. - fpga subsystem driver updates and additions - mhi subsystem updates - Coresight driver updates - gnss subsystem updates - extcon driver updates - icc subsystem updates - fsi subsystem updates - nvmem subsystem and driver updates - misc driver updates - speakup driver additions for new features - lots of tiny driver updates and cleanups All of these have been in the linux-next tree for a while with no reported issues" * tag 'char-misc-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (411 commits) w1: Split memcpy() of struct cn_msg flexible array spmi: pmic-arb: increase SPMI transaction timeout delay spmi: pmic-arb: block access for invalid PMIC arbiter v5 SPMI writes spmi: pmic-arb: correct duplicate APID to PPID mapping logic spmi: pmic-arb: add support to dispatch interrupt based on IRQ status spmi: pmic-arb: check apid against limits before calling irq handler spmi: pmic-arb: do not ack and clear peripheral interrupts in cleanup_irq spmi: pmic-arb: handle spurious interrupt spmi: pmic-arb: add a print in cleanup_irq drivers: spmi: Directly use ida_alloc()/free() MAINTAINERS: add TI ECAP driver info counter: ti-ecap-capture: capture driver support for ECAP Documentation: ABI: sysfs-bus-counter: add frequency & num_overflows items dt-bindings: counter: add ti,am62-ecap-capture.yaml counter: Introduce the COUNTER_COMP_ARRAY component type counter: Consolidate Counter extension sysfs attribute creation counter: Introduce the Count capture component counter: 104-quad-8: Add Signal polarity component counter: Introduce the Signal polarity component counter: interrupt-cnt: Implement watch_validate callback ...
2022-10-06Merge tag 'linux-kselftest-next-6.1-rc1' of ↵Linus Torvalds4-59/+310
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull Kselftest updates from Shuah Khan: "Fixes and new tests: - Add an amd-pstate-ut test module, used by kselftest to unit test amd-pstate functionality - Fixes and cleanups to to cpu-hotplug to delete the fault injection test code - Improvements to vm test to use top_srcdir for builds" * tag 'linux-kselftest-next-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: docs:kselftest: fix kselftest_module.h path of example module cpufreq: amd-pstate: Add explanation for X86_AMD_PSTATE_UT selftests/cpu-hotplug: Add log info when test success selftests/cpu-hotplug: Reserve one cpu online at least selftests/cpu-hotplug: Delete fault injection related code selftests/cpu-hotplug: Use return instead of exit selftests/cpu-hotplug: Correct log info cpufreq: amd-pstate: modify type in argument 2 for filp_open Documentation: amd-pstate: Add unit test introduction selftests: amd-pstate: Add test trigger for amd-pstate driver cpufreq: amd-pstate: Add test module for amd-pstate driver cpufreq: amd-pstate: Expose struct amd_cpudata selftests/vm: use top_srcdir instead of recomputing relative paths
2022-10-05cpufreq: amd-pstate: Add explanation for X86_AMD_PSTATE_UTMeng Li1-0/+8
This kernel module is used for testing. It's safe to say M here. It can also be built-in without X86_AMD_PSTATE enabled. Currently, only tests for amd-pstate are supported. If X86_AMD_PSTATE is set disabled, it can tell the users test can only run on amd-pstate driver, please set X86_AMD_PSTATE enabled. In the future, comparison tests will be added. It can set amd-pstate disabled and set acpi-cpufreq enabled to run test cases, then compare the test results. Suggested-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Meng Li <li.meng@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-10-05cpufreq: amd-pstate: modify type in argument 2 for filp_openMeng Li1-1/+1
Modify restricted FMODE_PREAD to experted int O_RDONLY to fix the sparse warnings below: sparse warnings: (new ones prefixed by >>) >> drivers/cpufreq/amd-pstate-ut.c:74:40: sparse: sparse: incorrect type >> in argument 2 (different base types) @@ expected int @@ got >> restricted fmode_t [usertype] @@ drivers/cpufreq/amd-pstate-ut.c:74:40: sparse: expected int drivers/cpufreq/amd-pstate-ut.c:74:40: sparse: got restricted fmode_t [usertype] Signed-off-by: Meng Li <li.meng@amd.com> Reported-by: kernel test robot <lkp@intel.com> Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-10-05cpufreq: amd-pstate: Add test module for amd-pstate driverMeng Li3-0/+301
Add amd-pstate-ut test module, this module is used by kselftest to unit test amd-pstate functionality. This module will be expected by some of selftests to be present and loaded. Signed-off-by: Meng Li <li.meng@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-10-05cpufreq: amd-pstate: Expose struct amd_cpudataMeng Li1-59/+1
Expose struct amd_cpudata to AMD P-State unit test module. This data struct will be used on the following AMD P-State unit test (amd-pstate-ut) module. The amd-pstate-ut module can get some AMD infomations by this data struct. For example: highest perf, nominal perf, boost supported etc. Signed-off-by: Meng Li <li.meng@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Acked-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2022-10-03Merge tag 'pm-6.1-rc1' of ↵Linus Torvalds9-47/+69
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management updates from Rafael Wysocki: "These add support for some new hardware, extend the existing hardware support, fix some issues and clean up code Specifics: - Add isupport for Tiger Lake in no-HWP mode to intel_pstate (Doug Smythies) - Update the AMD P-state driver (Perry Yuan): - Fix wrong lowest perf fetch - Map desired perf into pstate scope for powersave governor - Update pstate frequency transition delay time - Fix initial highest_perf value - Clean up - Move max CPU capacity to sugov_policy in the schedutil cpufreq governor (Lukasz Luba) - Add SM6115 to cpufreq-dt blocklist (Adam Skladowski) - Add support for Tegra239 and minor cleanups (Sumit Gupta, ye xingchen, and Yang Yingliang) - Add freq qos for qcom cpufreq driver and minor cleanups (Xuewen Yan, and Viresh Kumar) - Minor cleanups around functions called at module_init() (Xiu Jianfeng) - Use module_init and add module_exit for bmips driver (Zhang Jianhua) - Add AlderLake-N support to intel_idle (Zhang Rui) - Replace strlcpy() with unused retval with strscpy() in intel_idle (Wolfram Sang) - Remove redundant check from cpuidle_switch_governor() (Yu Liao) - Replace strlcpy() with unused retval with strscpy() in the powernv cpuidle driver (Wolfram Sang) - Drop duplicate word from a comment in the coupled cpuidle driver (Jason Wang) - Make rpm_resume() return -EINPROGRESS if RPM_NOWAIT is passed to it in the flags and the device is about to resume (Rafael Wysocki) - Add extra debugging statement for multiple active IRQs to system wakeup handling code (Mario Limonciello) - Replace strlcpy() with unused retval with strscpy() in the core system suspend support code (Wolfram Sang) - Update the intel_rapl power capping driver: - Use standard Energy Unit for SPR Dram RAPL domain (Zhang Rui). - Add support for RAPTORLAKE_S (Zhang Rui). - Fix UBSAN shift-out-of-bounds issue (Chao Qin) - Handle -EPROBE_DEFER when regulator is not probed on mtk-ci-devfreq.c (AngeloGioacchino Del Regno) - Fix message typo and use dev_err_probe() in rockchip-dfi.c (Christophe JAILLET)" * tag 'pm-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (29 commits) cpufreq: qcom-cpufreq-hw: Add cpufreq qos for LMh cpufreq: Add __init annotation to module init funcs cpufreq: tegra194: change tegra239_cpufreq_soc to static PM / devfreq: rockchip-dfi: Fix an error message PM / devfreq: mtk-cci: Handle sram regulator probe deferral powercap: intel_rapl: Use standard Energy Unit for SPR Dram RAPL domain PM: runtime: Return -EINPROGRESS from rpm_resume() in the RPM_NOWAIT case intel_idle: Add AlderLake-N support powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue cpufreq: tegra194: Add support for Tegra239 cpufreq: qcom-cpufreq-hw: Fix uninitialized throttled_freq warning cpufreq: intel_pstate: Add Tigerlake support in no-HWP mode powercap: intel_rapl: Add support for RAPTORLAKE_S cpufreq: amd-pstate: Fix initial highest_perf value cpuidle: Remove redundant check in cpuidle_switch_governor() PM: wakeup: Add extra debugging statement for multiple active IRQs cpufreq: tegra194: Remove the unneeded result variable PM: suspend: move from strlcpy() with unused retval to strscpy() intel_idle: move from strlcpy() with unused retval to strscpy() cpuidle: powernv: move from strlcpy() with unused retval to strscpy() ...
2022-10-03Merge branches 'acpi-cppc', 'acpi-pcc', 'acpi-apei' and 'acpi-osi'Rafael J. Wysocki2-6/+23
Merge new material related to CPPC, PCC, APEI and OSI strings handling for 6.1-rc1: - Disable frequency invariance in the CPPC library if registers used by cppc_get_perf_ctrs() are accessed via PCC (Jeremy Linton). - Add ACPI disabled check to acpi_cpc_valid() (Perry Yuan). - Fix Tx acknowledge in the PCC address space handler (Huisong Li). - Use wait_for_completion_timeout() for PCC mailbox operations (Huisong Li). - Release resources on PCC address space setup failure path (Rafael Mendonca). - Remove unneeded result variables from APEI code (ye xingchen). - Print total number of records found during BERT log parsing (Dmitry Monakhov). - Drop support for 3 _OSI strings that should not be necessary any more and update documentation on custom _OSI strings so that adding new ones is not encouraged any more (Mario Limonciello). * acpi-cppc: ACPI: CPPC: Disable FIE if registers in PCC regions ACPI: CPPC: Add ACPI disabled check to acpi_cpc_valid() * acpi-pcc: ACPI: PCC: Fix Tx acknowledge in the PCC address space handler ACPI: PCC: replace wait_for_completion() ACPI: PCC: Release resources on address space setup failure path * acpi-apei: ACPI: APEI: Remove unneeded result variables ACPI: APEI: Add BERT error log footer * acpi-osi: ACPI: OSI: Update Documentation on custom _OSI strings ACPI: OSI: Remove Linux-HPI-Hybrid-Graphics _OSI string ACPI: OSI: Remove Linux-Lenovo-NV-HDMI-Audio _OSI string ACPI: OSI: Remove Linux-Dell-Video _OSI string
2022-09-28Merge tag 'cpufreq-arm-updates-6.1' of ↵Rafael J. Wysocki7-29/+47
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm Pull cpufreq/arm updates for 6.1-rc1 from Viresh Kumar: "- Add SM6115 to cpufreq-dt blocklist (Adam Skladowski). - Add support for Tegra239 and minor cleanups (Sumit Gupta, ye xingchen, and Yang Yingliang). - Add freq qos for qcom cpufreq driver and minor cleanups (Xuewen Yan, and Viresh Kumar). - Minor cleanups around functions called at module_init() (Xiu Jianfeng). - Use module_init and add module_exit for bmips driver (Zhang Jianhua)." * tag 'cpufreq-arm-updates-6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm: cpufreq: qcom-cpufreq-hw: Add cpufreq qos for LMh cpufreq: Add __init annotation to module init funcs cpufreq: tegra194: change tegra239_cpufreq_soc to static cpufreq: tegra194: Add support for Tegra239 cpufreq: qcom-cpufreq-hw: Fix uninitialized throttled_freq warning cpufreq: tegra194: Remove the unneeded result variable cpufreq: bmips-cpufreq: Use module_init and add module_exit cpufreq: Add SM6115 to cpufreq-dt-platdev blocklist
2022-09-26cpufreq: qcom-cpufreq-hw: Add cpufreq qos for LMhXuewen Yan1-0/+14
Before update thermal pressure, the max cpufreq should be limited. Add QOS control for Lmh throttle cpufreq. Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-09-26cpufreq: Add __init annotation to module init funcsXiu Jianfeng3-3/+3
Add missing __init annotation to module init funcs. Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-09-26cpufreq: tegra194: change tegra239_cpufreq_soc to staticYang Yingliang1-1/+1
tegra239_cpufreq_soc is only used in tegra194-cpufreq.c now, change it to static. Fixes: 676886010707 ("cpufreq: tegra194: Add support for Tegra239") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2022-09-24ACPI: CPPC: Disable FIE if registers in PCC regionsJeremy Linton1-4/+21
PCC regions utilize a mailbox to set/retrieve register values used by the CPPC code. This is fine as long as the operations are infrequent. With the FIE code enabled though the overhead can range from 2-11% of system CPU overhead (ex: as measured by top) on Arm based machines. So, before enabling FIE assure none of the registers used by cppc_get_perf_ctrs() are in the PCC region. Finally, add a module parameter which can override the PCC region detection at boot or module reload. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-24nvmem: prefix all symbols with NVMEM_Rafał Miłecki1-1/+1
This unifies all NVMEM symbols. They follow one style now. Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220916122100.170016-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-13 00:59:27 +0300