The print in probe is done using pr_info. Correct print call would be dev_dbg because: - Severity should really be dbg - The dev pointer is given as first argument Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/c4f55add237455555df0597c72052022f7a669f6.1601885841.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
The PM8953 is commonly used on board with MSM8953 SoCs or its variants: APQ8053, SDM(SDA)450 and SDM(SDA)632. It provides 7 SMPS and 23 LDO regulators. Signed-off-by: Vladimir Lypak <junak.pub@gmail.com> Link: https://lore.kernel.org/r/20201004083413.324351-1-junak.pub@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
If debugging is disabled, print_constraints() does not print the actual constraints, but still performs some processing and string formatting, only to throw away the result later. Fix this by moving all constraint debug processing to a separate function, and replacing it by a dummy when debugging is disabled. This reduces kernel size by almost 800 bytes (on arm/arm64). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20201005131546.22448-1-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
AngeloGioacchino Del Regno <kholk11@gmail.com>: From: AngeloGioacchino Del Regno <kholk11@gmail.com> This patch series enables support for the regulators as found in the PM660 and PM660L PMICs. While at it, and to make them work, along with other regulators for other qcom PMICs, enlarge the maximum property name length in the regulator core, so that we're able to correctly parse the supply parents, which have got very long names (details in patch 1/5). This patch series has been tested against the following devices: - Sony Xperia XA2 Ultra (SDM630 Nile Discovery) - Sony Xperia 10 (SDM630 Ganges Kirin) - Sony Xperia 10 Plus (SDM636 Ganges Mermaid) AngeloGioacchino Del Regno (7): regulator: core: Enlarge max OF property name length to 64 chars regulator: qcom_spmi: Add support for new regulator types regulator: qcom_spmi: Add PM660/PM660L regulators regulator: dt-bindings: Document the PM660/660L SPMI PMIC entries regulator: qcom_smd: Add PM660/PM660L regulator support mfd: qcom-spmi-pmic: Add support for PM660/PM660L regulator: dt-bindings: Document the PM660/PM660L PMICs entries .../regulator/qcom,smd-rpm-regulator.yaml | 7 ++ .../regulator/qcom,spmi-regulator.txt | 31 +++++ drivers/mfd/qcom-spmi-pmic.c | 4 + drivers/regulator/core.c | 4 +- drivers/regulator/qcom_smd-regulator.c | 113 ++++++++++++++++++ drivers/regulator/qcom_spmi-regulator.c | 107 +++++++++++++++++ include/linux/soc/qcom/smd-rpm.h | 4 + 7 files changed, 268 insertions(+), 2 deletions(-) -- 2.28.0
The only usage of qcom_labibb_ops is to assign it to the ops field in the regulator_desc struct, which is a const pointer. The only usage of pmi8998_lab_desc and pmi8998_ibb_desc is to assign their address to the desc field in the labibb_regulator_data struct which can be made const, since it is only copied into the desc field in the labbibb_regulator_data struct. This struct is modified, but that's a copy of the static one. Make them const to allow the compiler to put them in read-only memory. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20200930162602.18583-1-rikard.falkeborn@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
The PM660 and PM660L are a very very common PMIC combo, found on boards using the SDM630, SDM636, SDM660 (and SDA variants) SoC. PM660 provides 6 SMPS and 19 LDOs (of which one is unaccesible), while PM660L provides 5 SMPS (of which S3 and S4 are combined), 10 LDOs and a Buck-or-Boost (BoB) regulator. The PM660L IC also provides other regulators that are very specialized (for example, for the display) and will be managed in the other appropriate drivers (for example, labibb). Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-6-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
The PM660 PMIC is very often paired with the PM660L option on SDM630/663/660 (and SDA variants) boards. The PM660 has 11 "660" LDOs (2 NMOS, 9 PMOS) and 7 HT LDOs (4 NMOS, 3 PMOS) and a quirk: the L4 regulator is unaccessible or does not exist on the PMIC. The PM660L has 8 "660" LDOs (1 NMOS, 7 PMOS) and 2 HT NMOS LDOs. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-4-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
This commit adds the support for some regulator types that are missing in this driver, such as the ht nmos-ldo, ht-lv nmos-ldo and new gen n/pmos-ldo, all belonging to the FTSMPS426 register layout. This is done in preparation for adding support for the PM660 and PM660L PMICs. Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com> Link: https://lore.kernel.org/r/20200926125549.13191-3-kholk11@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Some regulator drivers may be defining very long names: this is the
case with the qcom_smd and qcom_spmi regulators, where we need to
parse the regulator parents from DT.
For clarity, this is an example:
{ "l13a", QCOM_SMD_RPM_LDOA, 13, &pm660_ht_lvpldo,
"vdd_l8_l9_l10_l11_l12_l13_l14" },
pm660-regulators {
...
vdd_l8_l9_l10_l11_l12_l13_l14-supply = <&vreg_s4a_2p04>
...
};
Now, with a 32 characters limit, the function is trying to parse,
exactly, "vdd_l8_l9_l10_l11_l12_l13_l14-s" (32 chars) instead of
the right one, which is 37 chars long in this specific case.
... And this is not only the case with PM660/PM660L, but also with
PMA8084, PM8916, PM8950 and others that are not implemented yet.
The length of 64 chars was chosen based on the longest parsed property
name that I could find, which is in PM8916, and would be 53 characters
long.
At that point, rounding that to 64 looked like being the best idea.
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
Link: https://lore.kernel.org/r/20200926125549.13191-2-kholk11@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>