linux-stable.git/drivers/base/power/opp, branch v4.6

PM / OPP: Remove useless check

2016-05-04T23:42:19+00:00

Regulators are optional for devices using OPPs and the OPP core
shouldn't be printing any errors for such missing regulators.

It was fine before the commit 0c717d0f9cb4, but that failed to update
this part of the code to remove an 'always true' check and an extra
unwanted print message.

Fix that now.

Fixes: 0c717d0f9cb4 (PM / OPP: Initialize regulator pointer to an error value)
Reported-by: Marc Gonzalez 
Signed-off-by: Viresh Kumar 
Reviewed-by: Stephen Boyd 
Signed-off-by: Rafael J. Wysocki

PM / OPP: Rename structures for clarity

2016-02-21T13:24:35+00:00

Stephen pointed out recently, that few structures always confuse him as
they aren't named properly. And this patch tries to address that:

Names are updated as:
- device_opp or dev_opp -> opp_table
- dev_opp_list -> opp_tables
- dev_opp_list_lock -> opp_table_lock
- device_list_opp -> opp_device (it was never a list, but a structure)
- list_dev -> opp_dev
- And similar changes in comments and function names as well.

This also fixes checkpatch warnings that were generated with this patch.

No functional changes.

Suggested-by: Stephen Boyd 
Signed-off-by: Viresh Kumar 
Reviewed-by: Stephen Boyd 
Signed-off-by: Rafael J. Wysocki

PM / OPP: Fix incorrect comments

2016-02-21T13:24:04+00:00

Some comments were just copy/pasted from other sections and don't match
to the routines they were added for. Fix them.

Signed-off-by: Viresh Kumar 
Reviewed-by: Stephen Boyd 
Signed-off-by: Rafael J. Wysocki

PM / OPP: Initialize regulator pointer to an error value

2016-02-16T12:12:41+00:00

We are currently required to do two checks for regulator pointer:
IS_ERR() and IS_NULL().

And multiple instances are reported, about both of these not being used
consistently and so resulting in crashes.

Fix that by initializing regulator pointer with an error value and
checking it only against an error.

This makes code more consistent and more efficient.

Fixes: 7d34d56ef334 (PM / OPP: Disable OPPs that aren't supported by the regulator)
Reported-and-tested-by: Jon Hunter 
Reported-and-tested-by: Tony Lindgren 
Reported-and-tested-by: Guenter Roeck 
Signed-off-by: Viresh Kumar 
[ rjw: Initialize to -ENXIO ]
Signed-off-by: Rafael J. Wysocki

PM / OPP: Initialize u_volt_min/max to a valid value

2016-02-15T21:55:35+00:00

We kept u_volt_min/max initialized to 0, when only the target voltage is
present in DT, instead of the target/min/max triplet.

This didn't go well with the regulator framework, as on few calls the
min voltage was set to target and max was set to 0 and so resulted in a
kernel crash like below:

kernel BUG at ../drivers/regulator/core.c:216!

[] (regulator_check_voltage) from [] (regulator_set_voltage_unlocked+0x58/0x230)
[] (regulator_set_voltage_unlocked) from [] (regulator_set_voltage+0x28/0x54)
[] (regulator_set_voltage) from [] (_set_opp_voltage+0x30/0x98)
[] (_set_opp_voltage) from [] (dev_pm_opp_set_rate+0xf0/0x28c)
[] (dev_pm_opp_set_rate) from [] (__cpufreq_driver_target+0x184/0x2b4)
[] (__cpufreq_driver_target) from [] (dbs_check_cpu+0x1b0/0x1f4)
[] (dbs_check_cpu) from [] (cpufreq_governor_dbs+0x324/0x5c4)
[] (cpufreq_governor_dbs) from [] (__cpufreq_governor+0xe4/0x1ec)
[] (__cpufreq_governor) from [] (cpufreq_init_policy+0x64/0x8c)
[] (cpufreq_init_policy) from [] (cpufreq_online+0x2fc/0x708)
[] (cpufreq_online) from [] (subsys_interface_register+0x94/0xd8)
[] (subsys_interface_register) from [] (cpufreq_register_driver+0x14c/0x19c)
[] (cpufreq_register_driver) from [] (dt_cpufreq_probe+0x70/0xec)
[] (dt_cpufreq_probe) from [] (platform_drv_probe+0x4c/0xb0)
[] (platform_drv_probe) from [] (driver_probe_device+0x214/0x2c0)
[] (driver_probe_device) from [] (__driver_attach+0x8c/0x90)
[] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c)
[] (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218)
[] (bus_add_driver) from [] (driver_register+0x78/0xf8)
[] (driver_register) from [] (do_one_initcall+0x90/0x1d8)
[] (do_one_initcall) from [] (kernel_init_freeable+0x15c/0x1fc)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xf0)
[] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
Code: e1550004 baffffeb e3a00000 e8bd8070 (e7f001f2)

Fix that by initializing u_volt_min/max to the target voltage in such cases.

Reported-and-tested-by: Krzysztof Kozlowski 
Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings)
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

PM / OPP: Fix NULL pointer dereference crash when disabling OPPs

2016-02-11T21:05:38+00:00

Commit 7d34d56ef334 (PM / OPP: Disable OPPs that aren't supported by
the regulator) causes a crash to happen on Tegra124 Jetson TK1 when
using the DFLL clock source for the CPU.  The DFLL manages the voltage
itself and so there is no regulator specified for the OPPs and so we
get a crash when we try to dereference the regulator pointer.  Fix
this by checking to see if the regulator IS_ERR_OR_NULL before
dereferencing it.

Fixes: 7d34d56ef334 (PM / OPP: Disable OPPs that aren't supported by the regulator)
Signed-off-by: Jon Hunter 
Reported-by: Bartlomiej Zolnierkiewicz 
Acked-by: Viresh Kumar 
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki

PM / OPP: Add dev_pm_opp_set_rate()

2016-02-10T00:11:54+00:00

This adds a routine, dev_pm_opp_set_rate(), responsible for configuring
power-supply and clock source for an OPP.

The OPP is found by matching against the target_freq passed to the
routine. This shall replace similar code present in most of the OPP
users and help simplify them a lot.

Signed-off-by: Viresh Kumar 
Reviewed-by: Stephen Boyd 
Signed-off-by: Rafael J. Wysocki

PM / OPP: Manage device clk

2016-02-10T00:11:54+00:00

OPP core has got almost everything now to manage device's OPP
transitions, the only thing left is device's clk. Get that as well.

Signed-off-by: Viresh Kumar 
Reviewed-by: Stephen Boyd 
Signed-off-by: Rafael J. Wysocki

PM / OPP: Parse clock-latency and voltage-tolerance for v1 bindings

2016-02-10T00:11:54+00:00

V2 bindings have better support for clock-latency and voltage-tolerance
and doesn't need special care. To use callbacks, like
dev_pm_opp_get_max_{transition|volt}_latency(), irrespective of the
bindings, the core needs to know clock-latency/voltage-tolerance for the
earlier bindings.

This patch reads clock-latency/voltage-tolerance from the device node,
irrespective of the bindings (to keep it simple) and use them only for
V1 bindings.

Signed-off-by: Viresh Kumar 
Reviewed-by: Stephen Boyd 
Signed-off-by: Rafael J. Wysocki

PM / OPP: Introduce dev_pm_opp_get_max_transition_latency()

2016-02-10T00:11:53+00:00

In few use cases (like: cpufreq), it is desired to get the maximum
latency for changing OPPs. Add support for that.

Signed-off-by: Viresh Kumar 
Reviewed-by: Stephen Boyd 
Signed-off-by: Rafael J. Wysocki