drivers/regulator/pwm-regulator.c:
  In function ‘pwm_regulator_init_table’:
drivers/regulator/pwm-regulator.c:171:14:
  warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

drivers/regulator/pwm-regulator.c:
  In function 'pwm_regulator_init_table':
drivers/regulator/pwm-regulator.c:172:14:
  warning: 'length' is used uninitialized in this function [-Wuninitialized]
    if ((length < sizeof(*duty_cycle_table)) ||
              ^
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

drivers/regulator/pwm-regulator.c:
  In function 'pwm_regulator_init_continuous':
drivers/regulator/pwm-regulator.c:202:22:
  warning: unused variable 'np' [-Wunused-variable]
     struct device_node *np = pdev->dev.of_node;
              ^
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Remove over-bracketing, use framework API to fetch PWM period and
be more forthcoming that pwm_voltage_to_duty_cycle() actually returns
duty cycle as a percentage, rather than a register value.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

In "[3d7ef30] regulator: pwm-regulator: Simplify voltage to duty-cycle
call" we stopped using max_duty_cycle, so we can retire it from device
data and DT.

There is no need to deprecate this property, as it hasn't hit Mainline
yet.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Perhaps this is just personal preference, but ...

This patch introduces a new local variable to receive and test regulator
initialisation data.  It simplifies and cleans up the code making it
that little bit easier to read and maintain.  The local value is assigned
to the structure attribute when all the others are.  This is the way we
usually do things.

Prevents this kind of nonsense:

	this->is->just.silly = fetch_silly_value(&pointer);
	if (!this->is->just.silly) {
		printk("Silly value failed: %d\n", this->is->just.silly);
		return this->is->just.silly;
	}
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

If we reverse some of the logic and change the formula used,
we can simplify the function greatly.

It is intentional that this function is supplied and then re-worked
within the same patch-set.  The submission in the previous patch is
the tried and tested (i.e. in real releases) method written by ST.
This patch contains a simplification provided later.  It looks and
performs better, but doesn't have the same time-under-test that the
original method does.  The idea is that we keep some history in
order to provide an easy way back i.e. revert.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The current version of PWM regulator only supports a static table
approach, where pre-calculated values are supplied by the vendor and
obtained via DT.  The continuous-voltage method takes min_uV and
max_uV, and divides the difference between them up into a number of
slices.  The number of slices depend on how large the duty cycle
register is.  This information is provided by a DT property.

As the name alludes, this provides values for a continuous voltage
range between min_uV and max_uV, which has obvious benefits over
either limited voltage possibilities, or the requirement to provide
a large voltage-table.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Take this out of the main .probe() routine in order to facilitate the
introduction of different ways to obtain 'duty cycle' information.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The core framework already takes care of this.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The Regulator Device keeps a full copy of it's own, which can be easily accessed.
Signed-off-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The of_get_regulator_init_data() function is used to extract the regulator
init_data but information on how to extract certain data is defined in the
static regulator descriptor (e.g: how to map the hardware operating modes).

Add a const struct regulator_desc * parameter to the function signature so
the parsing logic could use the information in the struct regulator_desc.

of_get_regulator_init_data() relies on of_get_regulation_constraints() to
actually extract the init_data so it has to pass the struct regulator_desc
but that is modified on a later patch.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NMark Brown <broonie@kernel.org>

A platform_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

rename st-pwm to pwm-regulator. And support getting voltage & duty table from
device tree, other platforms can also use this driver without any modify.
Signed-off-by: NChris Zhong <zyw@rock-chips.com>
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Tested-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>