UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/drivers/soc/samsung/exynos-asv.c

161 lines
3.5 KiB
C
Raw Normal View History

soc: samsung: Add Exynos Adaptive Supply Voltage driver The Adaptive Supply Voltage (ASV) driver adjusts CPU cluster operating points depending on exact revision of an SoC retrieved from the CHIPID block or the OTP memory. This allows for some power saving as for some CPU clock frequencies we can lower CPU cluster's supply voltage comparing to safe values common to all the SoC revisions. This patch adds support for Exynos5422/5800 SoC, it is partially based on code from https://github.com/hardkernel/linux repository, branch odroidxu4-4.14.y, files: arch/arm/mach-exynos/exynos5422-asv.[ch]. Tested on Odroid XU3, XU4, XU3 Lite. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-28 23:15:33 +08:00
// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (c) 2019 Samsung Electronics Co., Ltd.
* http://www.samsung.com/
soc: samsung: exynos-chipid: convert to driver and merge exynos-asv The Exynos Chip ID driver on Exynos SoCs has so far only informational purpose - to expose the SoC device in sysfs. No other drivers depend on it so there is really no benefit of initializing it early. The code would be the most flexible if converted to a regular driver. However there is already another driver - Exynos ASV (Adaptive Supply Voltage) - which binds to the device node of Chip ID. The solution is to convert the Exynos Chip ID to a built in driver and merge the Exynos ASV into it. This has several benefits: 1. Although the Exynos ASV driver binds to a device node present in all Exynos DTS (generic compatible), it fails to probe except on the supported ones (only Exynos5422). This means that the regular boot process has a planned/normal device probe failure. Merging the ASV into Chip ID will remove this probe failure because the final driver will always bind, just with disabled ASV features. 2. Allows to use dev_info() as the SoC bus is present (since core_initcall). 3. Could speed things up because of execution of Chip ID code in a SMP environment (after bringing up secondary CPUs, unlike early_initcall), This reduces the amount of work to be done early, when the kernel has to bring up critical devices. 5. Makes the Chip ID code defer-probe friendly, Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
2020-12-08 02:54:57 +08:00
* Copyright (c) 2020 Krzysztof Kozlowski <krzk@kernel.org>
soc: samsung: Add Exynos Adaptive Supply Voltage driver The Adaptive Supply Voltage (ASV) driver adjusts CPU cluster operating points depending on exact revision of an SoC retrieved from the CHIPID block or the OTP memory. This allows for some power saving as for some CPU clock frequencies we can lower CPU cluster's supply voltage comparing to safe values common to all the SoC revisions. This patch adds support for Exynos5422/5800 SoC, it is partially based on code from https://github.com/hardkernel/linux repository, branch odroidxu4-4.14.y, files: arch/arm/mach-exynos/exynos5422-asv.[ch]. Tested on Odroid XU3, XU4, XU3 Lite. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-28 23:15:33 +08:00
* Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
soc: samsung: exynos-chipid: convert to driver and merge exynos-asv The Exynos Chip ID driver on Exynos SoCs has so far only informational purpose - to expose the SoC device in sysfs. No other drivers depend on it so there is really no benefit of initializing it early. The code would be the most flexible if converted to a regular driver. However there is already another driver - Exynos ASV (Adaptive Supply Voltage) - which binds to the device node of Chip ID. The solution is to convert the Exynos Chip ID to a built in driver and merge the Exynos ASV into it. This has several benefits: 1. Although the Exynos ASV driver binds to a device node present in all Exynos DTS (generic compatible), it fails to probe except on the supported ones (only Exynos5422). This means that the regular boot process has a planned/normal device probe failure. Merging the ASV into Chip ID will remove this probe failure because the final driver will always bind, just with disabled ASV features. 2. Allows to use dev_info() as the SoC bus is present (since core_initcall). 3. Could speed things up because of execution of Chip ID code in a SMP environment (after bringing up secondary CPUs, unlike early_initcall), This reduces the amount of work to be done early, when the kernel has to bring up critical devices. 5. Makes the Chip ID code defer-probe friendly, Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
2020-12-08 02:54:57 +08:00
* Author: Krzysztof Kozlowski <krzk@kernel.org>
soc: samsung: Add Exynos Adaptive Supply Voltage driver The Adaptive Supply Voltage (ASV) driver adjusts CPU cluster operating points depending on exact revision of an SoC retrieved from the CHIPID block or the OTP memory. This allows for some power saving as for some CPU clock frequencies we can lower CPU cluster's supply voltage comparing to safe values common to all the SoC revisions. This patch adds support for Exynos5422/5800 SoC, it is partially based on code from https://github.com/hardkernel/linux repository, branch odroidxu4-4.14.y, files: arch/arm/mach-exynos/exynos5422-asv.[ch]. Tested on Odroid XU3, XU4, XU3 Lite. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-28 23:15:33 +08:00
*
* Samsung Exynos SoC Adaptive Supply Voltage support
*/
#include <linux/cpu.h>
#include <linux/device.h>
#include <linux/errno.h>
#include <linux/of.h>
#include <linux/pm_opp.h>
#include <linux/regmap.h>
#include <linux/soc/samsung/exynos-chipid.h>
#include "exynos-asv.h"
#include "exynos5422-asv.h"
#define MHZ 1000000U
static int exynos_asv_update_cpu_opps(struct exynos_asv *asv,
struct device *cpu)
{
struct exynos_asv_subsys *subsys = NULL;
struct dev_pm_opp *opp;
unsigned int opp_freq;
int i;
for (i = 0; i < ARRAY_SIZE(asv->subsys); i++) {
if (of_device_is_compatible(cpu->of_node,
asv->subsys[i].cpu_dt_compat)) {
subsys = &asv->subsys[i];
break;
}
}
if (!subsys)
return -EINVAL;
for (i = 0; i < subsys->table.num_rows; i++) {
unsigned int new_volt, volt;
int ret;
opp_freq = exynos_asv_opp_get_frequency(subsys, i);
opp = dev_pm_opp_find_freq_exact(cpu, opp_freq * MHZ, true);
if (IS_ERR(opp)) {
dev_info(asv->dev, "cpu%d opp%d, freq: %u missing\n",
cpu->id, i, opp_freq);
continue;
}
volt = dev_pm_opp_get_voltage(opp);
new_volt = asv->opp_get_voltage(subsys, i, volt);
dev_pm_opp_put(opp);
if (new_volt == volt)
continue;
ret = dev_pm_opp_adjust_voltage(cpu, opp_freq * MHZ,
new_volt, new_volt, new_volt);
if (ret < 0)
dev_err(asv->dev,
"Failed to adjust OPP %u Hz/%u uV for cpu%d\n",
opp_freq, new_volt, cpu->id);
else
dev_dbg(asv->dev,
"Adjusted OPP %u Hz/%u -> %u uV, cpu%d\n",
opp_freq, volt, new_volt, cpu->id);
}
return 0;
}
static int exynos_asv_update_opps(struct exynos_asv *asv)
{
struct opp_table *last_opp_table = NULL;
struct device *cpu;
int ret, cpuid;
for_each_possible_cpu(cpuid) {
struct opp_table *opp_table;
cpu = get_cpu_device(cpuid);
if (!cpu)
continue;
opp_table = dev_pm_opp_get_opp_table(cpu);
opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER The OPP core manages various resources, e.g. clocks or interconnect paths. These resources are looked up when the OPP table is allocated once dev_pm_opp_get_opp_table() is called the first time (either directly or indirectly through one of the many helper functions). At this point, the resources may not be available yet, i.e. looking them up will result in -EPROBE_DEFER. Unfortunately, dev_pm_opp_get_opp_table() is currently unable to propagate this error code since it only returns the allocated OPP table or NULL. This means that all consumers of the OPP core are required to make sure that all necessary resources are available. Usually this happens by requesting them, checking the result and releasing them immediately after. For example, we have added "dev_pm_opp_of_find_icc_paths(dev, NULL)" to several drivers now just to make sure the interconnect providers are ready before the OPP table is allocated. If this call is missing, the OPP core will only warn about this and then attempt to continue without interconnect. This will eventually fail horribly, e.g.: cpu cpu0: _allocate_opp_table: Error finding interconnect paths: -517 ... later ... of: _read_bw: Mismatch between opp-peak-kBps and paths (1 0) cpu cpu0: _opp_add_static_v2: opp key field not found cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22 This example happens when trying to use interconnects for a CPU OPP table together with qcom-cpufreq-nvmem.c. qcom-cpufreq-nvmem calls dev_pm_opp_set_supported_hw(), which ends up allocating the OPP table early. To fix the problem with the current approach we would need to add yet another call to dev_pm_opp_of_find_icc_paths(dev, NULL). But actually qcom-cpufreq-nvmem.c has nothing to do with interconnects... This commit attempts to make this more robust by allowing dev_pm_opp_get_opp_table() to return an error pointer. Fixing all the usages is trivial because the function is usually used indirectly through another helper (e.g. dev_pm_opp_set_supported_hw() above). These other helpers already return an error pointer. The example above then works correctly because set_supported_hw() will return -EPROBE_DEFER, and qcom-cpufreq-nvmem.c already propagates that error. It should also be possible to remove the remaining usages of "dev_pm_opp_of_find_icc_paths(dev, NULL)" from other drivers as well. Note that this commit currently only handles -EPROBE_DEFER for the clock/interconnects within _allocate_opp_table(). Other errors are just ignored as before. Eventually those should be propagated as well. Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> [ Viresh: skip checking return value of dev_pm_opp_get_opp_table() for EPROBE_DEFER in domain.c, fix NULL return value and reorder code a bit in core.c, and update exynos-asv.c ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-07-27 17:30:46 +08:00
if (IS_ERR(opp_table))
soc: samsung: Add Exynos Adaptive Supply Voltage driver The Adaptive Supply Voltage (ASV) driver adjusts CPU cluster operating points depending on exact revision of an SoC retrieved from the CHIPID block or the OTP memory. This allows for some power saving as for some CPU clock frequencies we can lower CPU cluster's supply voltage comparing to safe values common to all the SoC revisions. This patch adds support for Exynos5422/5800 SoC, it is partially based on code from https://github.com/hardkernel/linux repository, branch odroidxu4-4.14.y, files: arch/arm/mach-exynos/exynos5422-asv.[ch]. Tested on Odroid XU3, XU4, XU3 Lite. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-28 23:15:33 +08:00
continue;
if (!last_opp_table || opp_table != last_opp_table) {
last_opp_table = opp_table;
ret = exynos_asv_update_cpu_opps(asv, cpu);
if (ret < 0)
dev_err(asv->dev, "Couldn't udate OPPs for cpu%d\n",
cpuid);
}
dev_pm_opp_put_opp_table(opp_table);
}
return 0;
}
soc: samsung: exynos-chipid: convert to driver and merge exynos-asv The Exynos Chip ID driver on Exynos SoCs has so far only informational purpose - to expose the SoC device in sysfs. No other drivers depend on it so there is really no benefit of initializing it early. The code would be the most flexible if converted to a regular driver. However there is already another driver - Exynos ASV (Adaptive Supply Voltage) - which binds to the device node of Chip ID. The solution is to convert the Exynos Chip ID to a built in driver and merge the Exynos ASV into it. This has several benefits: 1. Although the Exynos ASV driver binds to a device node present in all Exynos DTS (generic compatible), it fails to probe except on the supported ones (only Exynos5422). This means that the regular boot process has a planned/normal device probe failure. Merging the ASV into Chip ID will remove this probe failure because the final driver will always bind, just with disabled ASV features. 2. Allows to use dev_info() as the SoC bus is present (since core_initcall). 3. Could speed things up because of execution of Chip ID code in a SMP environment (after bringing up secondary CPUs, unlike early_initcall), This reduces the amount of work to be done early, when the kernel has to bring up critical devices. 5. Makes the Chip ID code defer-probe friendly, Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
2020-12-08 02:54:57 +08:00
int exynos_asv_init(struct device *dev, struct regmap *regmap)
soc: samsung: Add Exynos Adaptive Supply Voltage driver The Adaptive Supply Voltage (ASV) driver adjusts CPU cluster operating points depending on exact revision of an SoC retrieved from the CHIPID block or the OTP memory. This allows for some power saving as for some CPU clock frequencies we can lower CPU cluster's supply voltage comparing to safe values common to all the SoC revisions. This patch adds support for Exynos5422/5800 SoC, it is partially based on code from https://github.com/hardkernel/linux repository, branch odroidxu4-4.14.y, files: arch/arm/mach-exynos/exynos5422-asv.[ch]. Tested on Odroid XU3, XU4, XU3 Lite. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-28 23:15:33 +08:00
{
int (*probe_func)(struct exynos_asv *asv);
struct exynos_asv *asv;
struct device *cpu_dev;
u32 product_id = 0;
int ret, i;
soc: samsung: exynos-chipid: convert to driver and merge exynos-asv The Exynos Chip ID driver on Exynos SoCs has so far only informational purpose - to expose the SoC device in sysfs. No other drivers depend on it so there is really no benefit of initializing it early. The code would be the most flexible if converted to a regular driver. However there is already another driver - Exynos ASV (Adaptive Supply Voltage) - which binds to the device node of Chip ID. The solution is to convert the Exynos Chip ID to a built in driver and merge the Exynos ASV into it. This has several benefits: 1. Although the Exynos ASV driver binds to a device node present in all Exynos DTS (generic compatible), it fails to probe except on the supported ones (only Exynos5422). This means that the regular boot process has a planned/normal device probe failure. Merging the ASV into Chip ID will remove this probe failure because the final driver will always bind, just with disabled ASV features. 2. Allows to use dev_info() as the SoC bus is present (since core_initcall). 3. Could speed things up because of execution of Chip ID code in a SMP environment (after bringing up secondary CPUs, unlike early_initcall), This reduces the amount of work to be done early, when the kernel has to bring up critical devices. 5. Makes the Chip ID code defer-probe friendly, Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
2020-12-08 02:54:57 +08:00
asv = devm_kzalloc(dev, sizeof(*asv), GFP_KERNEL);
soc: samsung: Add Exynos Adaptive Supply Voltage driver The Adaptive Supply Voltage (ASV) driver adjusts CPU cluster operating points depending on exact revision of an SoC retrieved from the CHIPID block or the OTP memory. This allows for some power saving as for some CPU clock frequencies we can lower CPU cluster's supply voltage comparing to safe values common to all the SoC revisions. This patch adds support for Exynos5422/5800 SoC, it is partially based on code from https://github.com/hardkernel/linux repository, branch odroidxu4-4.14.y, files: arch/arm/mach-exynos/exynos5422-asv.[ch]. Tested on Odroid XU3, XU4, XU3 Lite. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-28 23:15:33 +08:00
if (!asv)
return -ENOMEM;
soc: samsung: exynos-chipid: convert to driver and merge exynos-asv The Exynos Chip ID driver on Exynos SoCs has so far only informational purpose - to expose the SoC device in sysfs. No other drivers depend on it so there is really no benefit of initializing it early. The code would be the most flexible if converted to a regular driver. However there is already another driver - Exynos ASV (Adaptive Supply Voltage) - which binds to the device node of Chip ID. The solution is to convert the Exynos Chip ID to a built in driver and merge the Exynos ASV into it. This has several benefits: 1. Although the Exynos ASV driver binds to a device node present in all Exynos DTS (generic compatible), it fails to probe except on the supported ones (only Exynos5422). This means that the regular boot process has a planned/normal device probe failure. Merging the ASV into Chip ID will remove this probe failure because the final driver will always bind, just with disabled ASV features. 2. Allows to use dev_info() as the SoC bus is present (since core_initcall). 3. Could speed things up because of execution of Chip ID code in a SMP environment (after bringing up secondary CPUs, unlike early_initcall), This reduces the amount of work to be done early, when the kernel has to bring up critical devices. 5. Makes the Chip ID code defer-probe friendly, Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
2020-12-08 02:54:57 +08:00
asv->chipid_regmap = regmap;
asv->dev = dev;
soc: samsung: exynos-asv: handle reading revision register error If regmap_read() fails, the product_id local variable will contain random value from the stack. Do not try to parse such value and fail the ASV driver probe. Fixes: 5ea428595cc5 ("soc: samsung: Add Exynos Adaptive Supply Voltage driver") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com> Link: https://lore.kernel.org/r/20201207190517.262051-3-krzk@kernel.org
2020-12-08 03:05:15 +08:00
ret = regmap_read(asv->chipid_regmap, EXYNOS_CHIPID_REG_PRO_ID,
&product_id);
if (ret < 0) {
soc: samsung: exynos-chipid: convert to driver and merge exynos-asv The Exynos Chip ID driver on Exynos SoCs has so far only informational purpose - to expose the SoC device in sysfs. No other drivers depend on it so there is really no benefit of initializing it early. The code would be the most flexible if converted to a regular driver. However there is already another driver - Exynos ASV (Adaptive Supply Voltage) - which binds to the device node of Chip ID. The solution is to convert the Exynos Chip ID to a built in driver and merge the Exynos ASV into it. This has several benefits: 1. Although the Exynos ASV driver binds to a device node present in all Exynos DTS (generic compatible), it fails to probe except on the supported ones (only Exynos5422). This means that the regular boot process has a planned/normal device probe failure. Merging the ASV into Chip ID will remove this probe failure because the final driver will always bind, just with disabled ASV features. 2. Allows to use dev_info() as the SoC bus is present (since core_initcall). 3. Could speed things up because of execution of Chip ID code in a SMP environment (after bringing up secondary CPUs, unlike early_initcall), This reduces the amount of work to be done early, when the kernel has to bring up critical devices. 5. Makes the Chip ID code defer-probe friendly, Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
2020-12-08 02:54:57 +08:00
dev_err(dev, "Cannot read revision from ChipID: %d\n", ret);
soc: samsung: exynos-asv: handle reading revision register error If regmap_read() fails, the product_id local variable will contain random value from the stack. Do not try to parse such value and fail the ASV driver probe. Fixes: 5ea428595cc5 ("soc: samsung: Add Exynos Adaptive Supply Voltage driver") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com> Link: https://lore.kernel.org/r/20201207190517.262051-3-krzk@kernel.org
2020-12-08 03:05:15 +08:00
return -ENODEV;
}
soc: samsung: Add Exynos Adaptive Supply Voltage driver The Adaptive Supply Voltage (ASV) driver adjusts CPU cluster operating points depending on exact revision of an SoC retrieved from the CHIPID block or the OTP memory. This allows for some power saving as for some CPU clock frequencies we can lower CPU cluster's supply voltage comparing to safe values common to all the SoC revisions. This patch adds support for Exynos5422/5800 SoC, it is partially based on code from https://github.com/hardkernel/linux repository, branch odroidxu4-4.14.y, files: arch/arm/mach-exynos/exynos5422-asv.[ch]. Tested on Odroid XU3, XU4, XU3 Lite. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-28 23:15:33 +08:00
switch (product_id & EXYNOS_MASK) {
case 0xE5422000:
probe_func = exynos5422_asv_init;
break;
default:
soc: samsung: exynos-chipid: convert to driver and merge exynos-asv The Exynos Chip ID driver on Exynos SoCs has so far only informational purpose - to expose the SoC device in sysfs. No other drivers depend on it so there is really no benefit of initializing it early. The code would be the most flexible if converted to a regular driver. However there is already another driver - Exynos ASV (Adaptive Supply Voltage) - which binds to the device node of Chip ID. The solution is to convert the Exynos Chip ID to a built in driver and merge the Exynos ASV into it. This has several benefits: 1. Although the Exynos ASV driver binds to a device node present in all Exynos DTS (generic compatible), it fails to probe except on the supported ones (only Exynos5422). This means that the regular boot process has a planned/normal device probe failure. Merging the ASV into Chip ID will remove this probe failure because the final driver will always bind, just with disabled ASV features. 2. Allows to use dev_info() as the SoC bus is present (since core_initcall). 3. Could speed things up because of execution of Chip ID code in a SMP environment (after bringing up secondary CPUs, unlike early_initcall), This reduces the amount of work to be done early, when the kernel has to bring up critical devices. 5. Makes the Chip ID code defer-probe friendly, Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
2020-12-08 02:54:57 +08:00
dev_dbg(dev, "No ASV support for this SoC\n");
devm_kfree(dev, asv);
return 0;
soc: samsung: Add Exynos Adaptive Supply Voltage driver The Adaptive Supply Voltage (ASV) driver adjusts CPU cluster operating points depending on exact revision of an SoC retrieved from the CHIPID block or the OTP memory. This allows for some power saving as for some CPU clock frequencies we can lower CPU cluster's supply voltage comparing to safe values common to all the SoC revisions. This patch adds support for Exynos5422/5800 SoC, it is partially based on code from https://github.com/hardkernel/linux repository, branch odroidxu4-4.14.y, files: arch/arm/mach-exynos/exynos5422-asv.[ch]. Tested on Odroid XU3, XU4, XU3 Lite. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-28 23:15:33 +08:00
}
soc: samsung: exynos-asv: don't defer early on not-supported SoCs Check if the SoC is really supported before gathering the needed resources. This fixes endless deferred probe on some SoCs other than Exynos5422 (like Exynos5410). Fixes: 5ea428595cc5 ("soc: samsung: Add Exynos Adaptive Supply Voltage driver") Cc: <stable@vger.kernel.org> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com> Link: https://lore.kernel.org/r/20201207190517.262051-2-krzk@kernel.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2020-12-08 03:05:14 +08:00
cpu_dev = get_cpu_device(0);
ret = dev_pm_opp_get_opp_count(cpu_dev);
if (ret < 0)
return -EPROBE_DEFER;
soc: samsung: exynos-chipid: convert to driver and merge exynos-asv The Exynos Chip ID driver on Exynos SoCs has so far only informational purpose - to expose the SoC device in sysfs. No other drivers depend on it so there is really no benefit of initializing it early. The code would be the most flexible if converted to a regular driver. However there is already another driver - Exynos ASV (Adaptive Supply Voltage) - which binds to the device node of Chip ID. The solution is to convert the Exynos Chip ID to a built in driver and merge the Exynos ASV into it. This has several benefits: 1. Although the Exynos ASV driver binds to a device node present in all Exynos DTS (generic compatible), it fails to probe except on the supported ones (only Exynos5422). This means that the regular boot process has a planned/normal device probe failure. Merging the ASV into Chip ID will remove this probe failure because the final driver will always bind, just with disabled ASV features. 2. Allows to use dev_info() as the SoC bus is present (since core_initcall). 3. Could speed things up because of execution of Chip ID code in a SMP environment (after bringing up secondary CPUs, unlike early_initcall), This reduces the amount of work to be done early, when the kernel has to bring up critical devices. 5. Makes the Chip ID code defer-probe friendly, Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201207190517.262051-5-krzk@kernel.org Reviewed-by: Pankaj Dubey <pankaj.dubey@samsung.com>
2020-12-08 02:54:57 +08:00
ret = of_property_read_u32(dev->of_node, "samsung,asv-bin",
soc: samsung: Add Exynos Adaptive Supply Voltage driver The Adaptive Supply Voltage (ASV) driver adjusts CPU cluster operating points depending on exact revision of an SoC retrieved from the CHIPID block or the OTP memory. This allows for some power saving as for some CPU clock frequencies we can lower CPU cluster's supply voltage comparing to safe values common to all the SoC revisions. This patch adds support for Exynos5422/5800 SoC, it is partially based on code from https://github.com/hardkernel/linux repository, branch odroidxu4-4.14.y, files: arch/arm/mach-exynos/exynos5422-asv.[ch]. Tested on Odroid XU3, XU4, XU3 Lite. Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-10-28 23:15:33 +08:00
&asv->of_bin);
if (ret < 0)
asv->of_bin = -EINVAL;
for (i = 0; i < ARRAY_SIZE(asv->subsys); i++)
asv->subsys[i].asv = asv;
ret = probe_func(asv);
if (ret < 0)
return ret;
return exynos_asv_update_opps(asv);
}