set/get_bypass ops were missing for ldo1/ldo2 on tps65917 and
ldo9 on palmas/tps659038 which support bypass mode.
Adding the bypass ops helps consumers configure these ldos in
bypass mode or remove bypass mode if need be.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Reported-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Palmas driver is used to cater to even TPS659038 but TPS659038 does not have
REGEN3 resource. Adding another field in the driver data to check on that.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The register offset for REGEN2_CTRL in different for TPS659038 chip as when
compared with other Palmas family PMICs. In the case of TPS659038 the wrong
offset pointed to PLLEN_CTRL and was causing a hang. Correcting the same.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

of_device_id is always used as const.
(See driver.of_match_table and open firmware functions)
Signed-off-by: NFabian Frederick <fabf@skynet.be>
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>

These of_node_get() were added to balance refcount decrements inside of
of_find_node_by_name().
See: commit c92f5dd2 ("regulator: Add missing of_node_put()")

However of_find_node_by_name() was then replaced by of_get_child_by_name(),
which doesn't call of_node_put() against its input parameter.

So, need to remove these unnecessary of_node_get() calls.
Signed-off-by: NGuodong Xu <guodong.xu@linaro.org>
Reviewed-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

We use regmap regulator ops to enable/disable and check if regulator
is enabled for various SMPS. However, these depend on valid
enable_reg, enable_mask and enable_value in regulator descriptor.

So, similar to fix we did in commit 318dbb02
("regulator: palmas: Fix SMPS enable/disable/is_enabled"), populate the
same for TPS65917 SMPS registration. LDO definitions are already in
place.

Fixes: d6f83370 ("regulator: palmas: Add tps65917 PMIC support")
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Palmas regulator needs to full up the regulator_desc based on PMIC and
type of regulator. However, we dont need to do desc[id] every time. we
can simplify by using a pointer to desc[id] and filling up the
parameters.
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

With commit d6f83370 (regulator: palmas:
Add tps65917 PMIC support) palmas_regs_info naming is confusing as it is
a driver data parameter and a local variable. To prevent mistaken
updates, rename the local variable to palmas_generic_regs_info.
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Palmas register information is part of the ddata pointer which is used
through out the code by indexing off the driver data array. Instead,
just do the indexing once and use the pointer to further reference
structure fields.

This simplifies code and prevents errors by accessing wrong variables.
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

reg_info is a generic term which might cause conflict at a later point
in time. To prevent such a thing from occuring in future, rename to
palmas_reg_info.
Signed-off-by: NNishanth Menon <nm@ti.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Tested-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

convert to static variables to squelch the following sparse warnings:
drivers/regulator/palmas-regulator.c:325:36: warning: symbol 'palma_sleep_req_info' was not declared. Should it be static?
drivers/regulator/palmas-regulator.c:1414:32: warning: symbol 'palmas_ddata' was not declared. Should it be static?
drivers/regulator/palmas-regulator.c:1427:32: warning: symbol 'tps65917_ddata' was not declared. Should it be static?
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

When setting up .enable_reg for an SMPS regulator, presumably we should
call PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE, ...) rather than using
LDO_BASE. This change makes the LCD panel and HDMI work again on the
NVIDIA Dalmore board anyway.

Fixes: 318dbb02 ("regulator: palmas: Fix SMPS enable/disable/is_enabled")
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NNishanth Menon <nm@ti.com>
Tested-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Add tps65917 PMIC support.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

add driver data and modularize the probe.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Shift the reg_info structure definition to the header file.
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

We use regmap regulator ops to enable/disable and check if regulator
is enabled for various SMPS. However, these depend on valid
enable_reg, enable_mask and enable_value in regulator descriptor.

Currently we do not populate these for SMPS other than SMPS10, this
results in spurious results as regmap assumes that the values are
valid and ends up reading register 0x0 RTC:SECONDS_REG on Palmas
variants that do have RTC! To fix this, we update proper parameters
for the descriptor fields.

Further, we want to ensure the behavior consistent with logic
prior to commit dbabd624, where, once you do a set_mode,
enable/disable ensure the logic remains consistent and configures
Palmas to the configuration that we set with set_mode (since the
configuration register is common). To do this, we can rely on the
regulator core's regulator_register behavior where the regulator
descriptor pointer provided by the regulator driver is stored. (no
reallocation and copy is done). This lets us update the enable_value
post registration, to remain consistent with the mode we configure as
part of set_mode.

Fixes: dbabd624 ("regulator: palmas: Reemove open coded functions with helper functions")
Reported-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Tested-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

get_voltage_sel reads from SMPS register - if the read selector value
is 0, the SMPS is actually disabled - So, this is in addition to the
ctrl_register that may also be used to enable/disable the SMPS.

The original logic(prior to commit dbabd624) used to be:
static int palmas_map_voltage_smps(struct regulator_dev *rdev,
               int min_uV, int max_uV)
<snip>
       if (min_uV == 0)
               return 0;

To handle this scenario, with the transition to regulator_list
implementation, we seem to have missed the data necessary to mark as
one of the valid entries as "0" 'disabled regulator' which results in
0 volts - So, stick with pre-existing logic.

Without this added to the list, palmas regulator driver,
on probe, attempts to setup constraints and in the case of
OMAP5uEVM, SMPS9 (which is mapped for 2v1 audio supply) fails in
regulator_list_voltage_linear_range mapping of '0', and as a fall back
of constraints not being applied, the entire regulator list is not
enumerated due to assumption that something system wide has gone bad
on with the PMIC.

Fixes: dbabd624 ("regulator: palmas: Reemove open coded functions with helper functions")
Reported-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Reemove open coded functions with helper functions.
Signed-off-by: NKeerthy <j-keerthy@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Make of_device_id array const, because all OF functions
handle it as const.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

The device tree binding of Palmas regulator driver says as:

palmas_pmis {
	compatible = "ti,palmas-pmic";
	...
	regulators {
		...
	}
};

In this "regulators" subnode is expected to be part of parent node, not
the outside of parent node. Hence to get the regulator node, the correct
call is of_get_child_by_name() rather than of_find_node_by_name() which
actually searches the "regulators" node from the parent node to end of DTS
file.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Current equation on the comment is wrong.
For linear mapping starting from 0, the equation is (maxV-minV)/stepV + 1.
Since the linear mapping for PALMAS is not all starting from 0, the equation
on the comment is not useful and misleading. Thus remove it.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

As per datasheet (Referred TPS65913), the on-time for LDO is
500micro second. If LDO6 is in vibrator mode then the on-time
is 2000us.

Set the enable_time on regulator descriptor accordingly.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Palmas rails like LDOs, SMPSs, REGENs, SYSENs can be enable and disable
by register programming through I2C communication as well as it can be
enable/disable with the external control input ENABLE1, ENABLE2 and NSLEEP.

Add support for configuring these rails to be controlled by external control
inputs. This is require to configure the rail's control register as well as
configuration of resource register.

Provide the external input names through parameter "roof-floor". Updated the
DT binding document to details different value of the roof-floor.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Commmit af40a94aba "regulator: palmas: Use devm_regulator_register" missed
removing a regulator_unregister() call if palmas_extreg_init falis. Fix it.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

devm_* simplifies the code.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

As per datasheet (Referred TPS65913), the on-time for LDO is
500micro second. If LDO6 is in vibrator mode then the on-time
is 2000us.

Set the enable_time on regulator descriptor accordingly.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

With the following change
---------
commit ad02e846
Author: Axel Lin <axel.lin@ingics.com>

    regulator: palmas: Return raw register values as the selectors in [get|set]_voltage_sel

    Don't adjust the selector in [get|set]_voltage_sel, fix it in list_voltage() instead.

    For smps*(except smps10), the vsel reg-value and voltage mapping as below:
----------
The list_voltage() takes the true value of selector which is
programmed in the register.  As per smsp voltage table
    reg-value       volt (uV) ( Assume RANGE is x1 )
    0               0
    1               500000
    2               500000
    3               500000
    4               500000
    5               500000
    6               500000 (0.49V + 1 * 0.01V) * RANGE
    7               510000 (0.49V + 2 * 0.01V) * RANGE
    8               520000 (0.49V + 3 * 0.01V) * RANGE
    9               530000 (0.49V + 4 * 0.01V) * RANGE
    ....
    121            1650000 (0.49V + 116 * 0.1) * RANGE

Hence making n_voltages for smps to 122.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

SMPS10 has two outputs OUT1 and OUT2 and have one input IN1.
SMPS10-OUT2 is connected to SMPS10-IN1 and can be configured either
in BOOST mode or BYPASS mode. regulator_enable of SMPS10-OUT2 configures
it in BOOST mode. For BYPASS mode regulator_allow_bypass() API can be
used. SMPS10-OUT1 is connected to SMPS10-OUT2 and can be enabled using
regulator_enable().

[ axel.lin@ingics.com : Simplify regulator_desc setting for SMPS10_[OUT1|OUT2]
Signed-off-by: NJ Keerthy <j-keerthy@ti.com>
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Use the wrapper function for retrieving the platform data instead of
accessing dev->platform_data directly.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Add TPS659038 support.
Signed-off-by: NJ Keerthy <j-keerthy@ti.com>
Acked-by: NMark Brown <broonie@linaro.org>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

The SMPS10 regulator is not presesnt in all the variants
of the PALMAS PMIC family. Hence adding a feature to distingush
between them.
Signed-off-by: NJ Keerthy <j-keerthy@ti.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

regulator_enable_regmap() uses enable_reg to enable the regulator.
But enable_reg for smps10 points to SMPS10_STATUS which is a
read-only register. Fixed the same by having enable_reg
set to SMPS10_CTRL.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org

Since 'id' cannot take two values at the same time, the condition
should probably be an OR (||) instead of AND (&&).

Introduced by commit 28d1e8cd ("regulator: palma: add ramp delay
support through regulator constraints").
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Datasheet says:
Time Step (TSTEP) selection, when changing the output voltage, the new value is
reached through successive voltage steps (if not bypassed). The equivalent
programmable slew rate of the output voltage is:

TSTEP[1:0]: 00 Jump (no slope control)
TSTEP[1:0]: 01 10mV/us
TSTEP[1:0]: 10 5mV/us (default)
TSTEP[1:0]: 11 2.5mV/us
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The ctrl_addr setting for SMPS10 is missed, thus palmas_smps_init() read/write
wrong register for SMPS10 in current code. Fix it.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

SMPS3 and SMPS7 do not have tstep_addr setting, so current code actually
writes 0 to smps12_ctl (offset is 0) register when set_ramp_delay callback
is called for SMPS3 and SMPS7.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

When SMPS45 is set to off and LDO8 tracking is enabled, the output voltage can
be set from 0.45 to 1.65 V. Thus set min_uV to be 450000.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The Palma device like TPS65913 have the mode mask which is also
used for enable/disable the rails. The mode bits are defined as
	00: OFF
	01: AUTO
	10: ECO
	11: Forced PWM

and modes are set accordingly as
	REGULATOR_MODE_NORMAL: AUTO
	REGULATOR_MODE_IDLE: ECO
	REGULATOR_MODE_FAST: PWM

Two issue observed:
1. If client calls following sequence:
	regulator_enable(),
	regulator_set_mode(FAST),
	regulator_disable()

	and again the regulator_enable() then the mode is reset
	to NORMAL inplace of keeping the mode as FAST.

	Fixing this by storing the current mode configured by client
	and restoring modes when enable() is called after disable().

2. In following sequence, the regulator get enabled:
	regulator_disable()
	regulator_set_mode(FAST),

	Fixing this by updating new mode in register only if it is
	enabled.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Acked-by: NGraeme Gregory <gg@slimlogic.co.uk>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

Currently Palma regulator driver support the ramp delay
through rail specific platform data.

As regulator framework support the configuration of ramp
delay through regulator constraint, using the framework
method and removing the platform specific data approach.
Signed-off-by: NLaxman Dewangan <ldewangan@nvidia.com>
Acked-by: NGraeme Gregory <gg@slimlogic.co.uk>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>