Re: [PATCH v3] soc: samsung: Add simple voltage coupler for Exynos5800

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 09, 2020 at 12:42:21PM +0200, Marek Szyprowski wrote:
> Add a simple custom voltage regulator coupler for Exynos5800 SoCs, which
> require coupling between "vdd_arm" and "vdd_int" regulators. This coupler
> ensures that the voltage values don't go below the bootloader-selected
> operation point during the boot process until a the clients sets their
> constraints. It is achieved by assuming minimal voltage value equal to
> the current value if no constraints are set. This also ensures proper
> voltage balancing if any of the client driver is missing.
> 
> The balancing code comes from regulator core.c with the 

You cut the sentence.

> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
> ---
> This patch is yet another attempt to fix the regulator coupling on
> Exynos5800/5422 SoCs. Here are links to the previous attempts and
> discussions:
> 
> https://lore.kernel.org/linux-samsung-soc/20191008101709.qVNy8eijBi0LynOteWFMnTg4GUwKG599n6OyYoX1Abs@z/
> https://lore.kernel.org/lkml/20191017102758.8104-1-m.szyprowski@xxxxxxxxxxx/
> https://lore.kernel.org/linux-pm/cover.1589528491.git.viresh.kumar@xxxxxxxxxx/
> https://lore.kernel.org/linux-pm/20200528131130.17984-1-m.szyprowski@xxxxxxxxxxx/
> https://lore.kernel.org/linux-samsung-soc/57cf3a15-5d9b-7636-4c69-60742e8cfae6@xxxxxxxxxxx/
> https://lore.kernel.org/lkml/20200605063724.9030-1-m.szyprowski@xxxxxxxxxxx/
> 
> The problem is with "vdd_int" regulator coupled with "vdd_arm" on Odroid
> XU3/XU4 boards family. "vdd_arm" is handled by CPUfreq. "vdd_int" is
> handled by devfreq. CPUfreq initialized quite early during boot and it
> starts changing OPPs and "vdd_arm" value. Sometimes CPU activity during
> boot goes down and some low-frequency OPPs are selected, what in turn
> causes lowering "vdd_arm". This happens before devfreq applies its
> requirements on "vdd_int". Regulator balancing code reduces "vdd_arm"
> voltage value, what in turn causes lowering "vdd_int" value to the lowest
> possible value. This is much below the operation point of the wcore bus,
> which still runs at the highest frequency.
> 
> The issue was hard to notice because in the most cases the board managed
> to boot properly, even when the regulator was set to lowest value allowed
> by the regulator constraints. However, it caused some random issues,
> which can be observed as "Unhandled prefetch abort" or low USB stability.
> 
> Handling this case in the generic code has been rejected, so the only way
> to ensure the desired behavior on Exynos5800-based SoCs is to make a
> custom regulator coupler driver. I've tried hard to extract some common
> code to simplify the exynos-regulator-coupler driver as much as possible,
> but the difference between it and the generic code is so deep that this
> approach failed, so indead I simply copied and modified the balancing
> code.
> 
> Best regards
> Marek Szyprowski
> ---
>  arch/arm/mach-exynos/Kconfig                  |   1 +
>  drivers/soc/samsung/Kconfig                   |   3 +
>  drivers/soc/samsung/Makefile                  |   1 +
>  .../soc/samsung/exynos-regulator-coupler.c    | 221 ++++++++++++++++++
>  4 files changed, 226 insertions(+)
>  create mode 100644 drivers/soc/samsung/exynos-regulator-coupler.c
> 
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 76838255b5fa..f185cd3d4c62 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -118,6 +118,7 @@ config SOC_EXYNOS5800
>  	bool "Samsung EXYNOS5800"
>  	default y
>  	depends on SOC_EXYNOS5420
> +	select EXYNOS_REGULATOR_COUPLER
>  
>  config EXYNOS_MCPM
>  	bool
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index 19c4d3f1437b..5d7819b52eed 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -43,4 +43,7 @@ config EXYNOS_PM_DOMAINS
>  	bool "Exynos PM domains" if COMPILE_TEST
>  	depends on PM_GENERIC_DOMAINS || COMPILE_TEST
>  
> +config EXYNOS_REGULATOR_COUPLER
> +	bool "Exynos SoC Regulator Coupler" if COMPILE_TEST
> +	depends on ARCH_EXYNOS || COMPILE_TEST
>  endif
> diff --git a/drivers/soc/samsung/Makefile b/drivers/soc/samsung/Makefile
> index 31db65cb7aa3..93285faec416 100644
> --- a/drivers/soc/samsung/Makefile
> +++ b/drivers/soc/samsung/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_EXYNOS_PMU_ARM_DRIVERS)	+= exynos3250-pmu.o exynos4-pmu.o \
>  					exynos5250-pmu.o exynos5420-pmu.o
>  obj-$(CONFIG_EXYNOS_PMU_ARM64_DRIVERS)	+= exynos-pm.o exynos5433-pmu.o
>  obj-$(CONFIG_EXYNOS_PM_DOMAINS) += pm_domains.o
> +obj-$(CONFIG_EXYNOS_REGULATOR_COUPLER) += exynos-regulator-coupler.o
> diff --git a/drivers/soc/samsung/exynos-regulator-coupler.c b/drivers/soc/samsung/exynos-regulator-coupler.c
> new file mode 100644
> index 000000000000..3cafc1738eb6
> --- /dev/null
> +++ b/drivers/soc/samsung/exynos-regulator-coupler.c
> @@ -0,0 +1,221 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Samsung Electronics Co., Ltd.
> + *	      http://www.samsung.com/
> + * Author: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
> + *
> + * Simplified generic volatage coupler from regulator core.c
> + * The main difference is that it keeps current regulator voltage
> + * if consumers didn't apply their contraints yet.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/regulator/coupler.h>
> +#include <linux/regulator/driver.h>
> +#include <linux/regulator/machine.h>
> +
> +static int regulator_get_optimal_voltage(struct regulator_dev *rdev,
> +					 int *current_uV,
> +					 int *min_uV, int *max_uV,
> +					 suspend_state_t state)
> +{
> +	struct coupling_desc *c_desc = &rdev->coupling_desc;
> +	struct regulator_dev **c_rdevs = c_desc->coupled_rdevs;
> +	struct regulation_constraints *constraints = rdev->constraints;
> +	int desired_min_uV = 0, desired_max_uV = INT_MAX;
> +	int max_current_uV = 0, min_current_uV = INT_MAX;
> +	int highest_min_uV = 0, target_uV, possible_uV;
> +	int i, ret, max_spread, n_coupled = c_desc->n_coupled;
> +	bool done;
> +
> +	*current_uV = -1;
> +
> +	/* Find highest min desired voltage */
> +	for (i = 0; i < n_coupled; i++) {
> +		int tmp_min = 0;
> +		int tmp_max = INT_MAX;
> +
> +		lockdep_assert_held_once(&c_rdevs[i]->mutex.base);
> +
> +		ret = regulator_check_consumers(c_rdevs[i],
> +						&tmp_min,
> +						&tmp_max, state);
> +		if (ret < 0)
> +			return ret;
> +
> +		if (tmp_min == 0) {
> +			ret = regulator_get_voltage_rdev(c_rdevs[i]);
> +			if (ret < 0)
> +				return ret;
> +			tmp_min = ret;
> +		}
> +
> +		/* apply constraints */
> +		ret = regulator_check_voltage(c_rdevs[i], &tmp_min, &tmp_max);
> +		if (ret < 0)
> +			return ret;
> +
> +		highest_min_uV = max(highest_min_uV, tmp_min);
> +
> +		if (i == 0) {
> +			desired_min_uV = tmp_min;
> +			desired_max_uV = tmp_max;
> +		}
> +	}
> +
> +	max_spread = constraints->max_spread[0];
> +
> +	/*
> +	 * Let target_uV be equal to the desired one if possible.
> +	 * If not, set it to minimum voltage, allowed by other coupled
> +	 * regulators.
> +	 */
> +	target_uV = max(desired_min_uV, highest_min_uV - max_spread);
> +
> +	/*
> +	 * Find min and max voltages, which currently aren't violating
> +	 * max_spread.
> +	 */
> +	for (i = 1; i < n_coupled; i++) {
> +		int tmp_act;
> +
> +		tmp_act = regulator_get_voltage_rdev(c_rdevs[i]);
> +		if (tmp_act < 0)
> +			return tmp_act;
> +
> +		min_current_uV = min(tmp_act, min_current_uV);
> +		max_current_uV = max(tmp_act, max_current_uV);
> +	}
> +
> +	/*
> +	 * Correct target voltage, so as it currently isn't
> +	 * violating max_spread
> +	 */
> +	possible_uV = max(target_uV, max_current_uV - max_spread);
> +	possible_uV = min(possible_uV, min_current_uV + max_spread);
> +
> +	if (possible_uV > desired_max_uV)
> +		return -EINVAL;
> +
> +	done = (possible_uV == target_uV);
> +	desired_min_uV = possible_uV;
> +
> +	/* Set current_uV if wasn't done earlier in the code and if necessary */
> +	if (*current_uV == -1) {
> +		ret = regulator_get_voltage_rdev(rdev);
> +		if (ret < 0)
> +			return ret;
> +		*current_uV = ret;
> +	}
> +
> +	*min_uV = desired_min_uV;
> +	*max_uV = desired_max_uV;
> +
> +	return done;
> +}
> +
> +static int exynos_coupler_balance_voltage(struct regulator_coupler *coupler,
> +					  struct regulator_dev *rdev,
> +					  suspend_state_t state)
> +{
> +	struct regulator_dev **c_rdevs;
> +	struct regulator_dev *best_rdev;
> +	struct coupling_desc *c_desc = &rdev->coupling_desc;
> +	int i, ret, n_coupled, best_min_uV, best_max_uV, best_c_rdev;
> +	unsigned int delta, best_delta;
> +	unsigned long c_rdev_done = 0;
> +	bool best_c_rdev_done;
> +
> +	c_rdevs = c_desc->coupled_rdevs;
> +	n_coupled = c_desc->n_coupled;
> +
> +	/*
> +	 * Find the best possible voltage change on each loop. Leave the loop
> +	 * if there isn't any possible change.
> +	 */
> +	do {
> +		best_c_rdev_done = false;
> +		best_delta = 0;
> +		best_min_uV = 0;
> +		best_max_uV = 0;
> +		best_c_rdev = 0;
> +		best_rdev = NULL;
> +
> +		/*
> +		 * Find highest difference between optimal voltage
> +		 * and current voltage.
> +		 */
> +		for (i = 0; i < n_coupled; i++) {
> +			/*
> +			 * optimal_uV is the best voltage that can be set for
> +			 * i-th regulator at the moment without violating
> +			 * max_spread constraint in order to balance
> +			 * the coupled voltages.
> +			 */
> +			int optimal_uV = 0, optimal_max_uV = 0, current_uV = 0;
> +
> +			if (test_bit(i, &c_rdev_done))

Add a sanity check at beginning that you have enough of bits for this...
or use bitmap.

Best regards,
Krzysztof




[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux for Synopsys ARC Processors]    
  • [Linux on Unisoc (RDA Micro) SoCs]     [Linux Actions SoC]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  •   Powered by Linux