The maximum supported voltage for ldo_io# is 3.3V, but on cold
boot the selector comes up at 0x1f, which maps to 3.8V.

This causes _regulator_get_voltage() to fail with -EINVAL which
causes regulator registration to fail when constrains are used:

[    1.467788] vcc-touchscreen: failed to get the current voltage(-22)
[    1.474209] axp20x-regulator axp20x-regulator: Failed to register ldo_io1
[    1.483363] axp20x-regulator: probe of axp20x-regulator failed with error -22

This commits makes the axp20x regulator driver accept the 0x1f register
value, fixing this.

The datasheet does not guarantee reliable operation above 3.3V, so on
boards where this regulator is used the regulator-max-microvolt setting
must be 3.3V or less.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The minium voltage of 1800mV is a copy and paste error from the axp20x
regulator info. The correct minimum voltage for the ldo_io regulators
on the axp22x is 700mV.

Fixes: 1b82b4e4 ("regulator: axp20x: Add support for AXP22X regulators")
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The current linear voltage range for the LDO4 regulator found in the APX20X
PMICs assumes that the voltage is linear between 2.5 and 3.1V.

However, the PMIC can output up to 3.3V on that regulator by skipping the
2.6V and 2.9V steps.

Fix the ranges to read and set the proper voltages.

Fixes: 13d57e64 ("regulator: axp20x: Use linear voltage ranges for AXP20X LDO4")
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Originally the helper macros used uppercase regulator names, which
are primarily used to expand to the regulator ID enum, as the default
names. This is aestheticly unpleasent.

Since the of_match bits are the same, just lowercase, use that as the
default names instead.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

AXP20X datasheet lists the possible voltage settings for LDO4, so
it was implemented using a voltage table. Upon closer examination,
the valid voltages can be mapped into 3 linear ranges.

Move AXP20X LDO4 to use linear ranges. The supporting code can be
reused with later AXP8xx PMICs, which have a number of regulators
that have 2 linear ranges.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Switch-type regulators, such as DC1SW on AXP22X, are a secondary output
from DCDC1. They are just an on/off switch, and the driver should not
try to read its voltage directly from the DCDC1 control registers.

Instead, the core will pass down the voltage from the regulator supply
chain.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The enable/disable values for GPIO LDOs are reversed. It seems no one
noticed as AXP22x support was introduced recently, and no one was using
the GPIO LDOs, either because no designs actually use them or board
support hasn't caught up.

Fixes: 1b82b4e4 ("regulator: axp20x: Add support for AXP22X regulators")
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

The DC1SW and DC5LDO regulators in the AXP22X are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property.

Since they are internally connected, the relationship should not be
represented in the device tree, but handled internally by the driver.

This patch has the driver remember the regulator names for the parent
DCDC1/DCDC5, and use them as supply names for DC1SW/DC5LDO.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

The enable bit indexes for DCDC4 and DCDC5 regulators are off by 1.

We haven't run into any problems with this since either the regulators
aren't defined in the DT and aren't used, or all the DCDC regulators
have the "always-on" property set, as they are almost always used
for system critical loads.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

This allows the module to be autoloaded.

Together with 07949bf9 ("cpufreq: dt: allow driver to boot
automatically") this is sufficient to allow a modular kernel (such
as Debian's) to enable cpufreq on a Cubietruck.
Signed-off-by: NIan Campbell <ijc@hellion.org.uk>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add AXP22X regulator definitions and variant id associations.
This introduces a new "switch" type output for one of the regulators.
It is a switchable secondary output of one regulator, with the same
voltage level as the primary output.
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
[wens@csie.org: Moved variant choosing to multi family support patch]
[wens@csie.org: Add dc-dc work frequency range]
[wens@csie.org: Add "switch" type output regulator DC1SW]
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

Rework the AXP20X_ macros and probe function to support the several chip
families, so that each family can define it's own set of regulators.
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
[wens@csie.org: Support different DC-DC work frequency ranges]
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Reviewed-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

A common simplified DT parsing code for regulators was introduced in
commit a0c7b164 ("regulator: of: Provide simplified DT parsing
method"). This is very similar to our own code, so get rid of ours
and use the common code.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch fills the DT related fields in the regulator descriptors,
which can then be used by the regulator core's simplified DT code.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
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>

The current device used for the regulator configuration is the child device
created by the MFD driver. This means that it doesn't have any of_node pointing
to it, and whenever we register the regulators, it will not look into the
regulator supply in the DT, hence requiring to provide regulator aliases in the
MFD driver.

We can easily fix that by using the parent device in our configuration, which
has a DT node associated to it, and will allow a DT lookup. Eventually, we will
be able to remove the aliases in the MFD driver.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The voltages in axp20x_ldo4_data table are in ascendant order, so use
regulator_map_voltage_ascend.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

The of_find_node_by_name function will search for a DT node named
"regulators" after the provided np node, but will not ensure that this node
is a child of np.
This might result in retrieving a "regulators" node that is not related to
the axp20x PMIC.
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Acked-by: NCarlo Caione <carlo@caione.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

AXP202 and AXP209 come with two synchronous step-down DC-DCs and five
LDOs. This patch introduces basic support for those regulators.
Signed-off-by: NCarlo Caione <carlo@caione.org>
Signed-off-by: NMark Brown <broonie@linaro.org>