summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)Author
2021-03-15regulator: bd9571mwv: Convert device attribute to sysfs_emit()Geert Uytterhoeven
Convert the "backup_mode" device attribute from sprintf() to sysfs_emit(), as the latter is aware of the PAGE_SIZE buffer. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210312130242.3390038-4-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-15regulator: bd9571mwv: Fix regulator name printed on registration failureGeert Uytterhoeven
If a regulator fails to register, the driver prints an error message like: bd9571mwv-regulator bd9571mwv-regulator.6.auto: failed to register bd9571mwv-regulator regulator However, the platform device's name is already printed as part of dev_err(), and does not allow the user to distinguish among the various regulators that are part of the PMIC. Fix this by printing regulator_desc.name instead, to change the message like: bd9571mwv-regulator bd9571mwv-regulator.6.auto: failed to register DVFS regulator Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20210312130242.3390038-3-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-15regulator: bd9571mwv: Fix AVS and DVFS voltage rangeGeert Uytterhoeven
According to Table 30 ("DVFS_MoniVDAC [6:0] Setting Table") in the BD9571MWV-M Datasheet Rev. 002, the valid voltage range is 600..1100 mV (settings 0x3c..0x6e). While the lower limit is taken into account (by setting regulator_desc.linear_min_sel to 0x3c), the upper limit is not. Fix this by reducing regulator_desc.n_voltages from 0x80 to 0x6f. Fixes: e85c5a153fe237f2 ("regulator: Add ROHM BD9571MWV-M PMIC regulator driver") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210312130242.3390038-2-geert+renesas@glider.be Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-11regulator: mt6315: Fix off-by-one for .n_voltagesAxel Lin
The valid selector is 0 ~ 0xbf, so the .n_voltages should be 0xc0. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210311020558.579597-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10regulator: rt4831: Fix return value check in rt4831_regulator_probe()Wei Yongjun
In case of error, the function dev_get_regmap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: 9351ab8b0cb6 ("regulator: rt4831: Adds support for Richtek RT4831 DSV regulator") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20210305034930.3236099-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10regulator: pca9450: Clear PRESET_EN bit to fix BUCK1/2/3 voltage settingFrieder Schrempf
The driver uses the DVS registers PCA9450_REG_BUCKxOUT_DVS0 to set the voltage for the buck regulators 1, 2 and 3. This has no effect as the PRESET_EN bit is set by default and therefore the preset values are used instead, which are set to 850 mV. To fix this we clear the PRESET_EN bit at time of initialization. Fixes: 0935ff5f1f0a ("regulator: pca9450: add pca9450 pmic driver") Cc: <stable@vger.kernel.org> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Link: https://lore.kernel.org/r/20210222115229.166620-1-frieder.schrempf@kontron.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10regulator: qcom-rpmh: Use correct buck for S1C regulatorsatya priya
Use correct buck, that is, pmic5_hfsmps515 for S1C regulator of PM8350C PMIC. Signed-off-by: satya priya <skakit@codeaurora.org> Link: https://lore.kernel.org/r/1614155592-14060-7-git-send-email-skakit@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10regulator: qcom-rpmh: Correct the pmic5_hfsmps515 bucksatya priya
Correct the REGULATOR_LINEAR_RANGE and n_voltges for pmic5_hfsmps515 buck. Signed-off-by: satya priya <skakit@codeaurora.org> Link: https://lore.kernel.org/r/1614155592-14060-4-git-send-email-skakit@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10regulator: pca9450: Fix return value when failing to get sd-vsel GPIOFrieder Schrempf
This fixes the return value of pca9450_i2c_probe() to use the correct error code when getting the sd-vsel GPIO fails. Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Link: https://lore.kernel.org/r/20210222150809.208942-1-frieder.schrempf@kontron.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10regulator: mt6315: Return REGULATOR_MODE_INVALID for invalid modeAxel Lin
-EINVAL is not a valid return value for .of_map_mode, return REGULATOR_MODE_INVALID instead. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210215034813.45510-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-22Merge tag 'mfd-next-5.12' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "Core Frameworks: - Standardise MFD_CELL_* helpers New Drivers: - Add support for Acer Iconia Tab A500 Embedded Controller New Device Support: - Add support for ROHM BD9574MWF to BD9571MWV - Add support for Intel Alder Lake PCH-P PCI to LPSS - Add support for Intel Alder Lake PCH-S PCI to LPSS New Functionality: - Support ACPI enumeration; arizona Fix-ups: - Managed resources; bd9571mwv - DT additions/fix-ups; bd9571mwv, iqs62x, max8997, gateworks-gsc, ene-kb930 - Convert to SPDX; bd9571mw - Fix return values/error handling; sunxi - Provide SOFTDEP; arizona - Make use of DIV_ROUND_UP; mcp-sa11x0 - Use generic APIs; arizona - Add MAC address sysfs entries; intel-m10-bmc - Trivial: Coding-style fix-ups; iqs62x - Trivial: Remove superflouous code; iqs62x - Clear-up naming conventions; iqs62x Bug Fixes: - Fix 'pointer from integer' error; altera-sysmgr - Convert SGI_MFD_IOC3 from tristate to bool; Kconfig - Fix interrupt handling; gateworks-gsc - Extend required delay; iqs62x - Do not use I2C polling during calibration; iqs62x - Do no adjust clock frequency during calibration; iqs62x - Fix use-after-free; wm831x-auxad" * tag 'mfd-next-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (32 commits) mfd: wm831x-auxadc: Prevent use after free in wm831x_auxadc_read_irq() mfd: iqs62x: Do not change clock frequency during ATI mfd: iqs62x: Do not poll during ATI mfd: iqs62x: Increase interrupt handler return delay mfd: iqs62x: Rename regmap_config struct mfd: iqs62x: Remove unused bit mask mfd: iqs62x: Remove superfluous whitespace above fallthroughs mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs mfd: intel-m10-bmc: Expose MAC address and count mfd: Add driver for Embedded Controller found on Acer Iconia Tab A500 dt-bindings: mfd: Add ENE KB930 Embedded Controller binding dt-bindings: mfd: gateworks-gsc: Add fan-tach mode mfd: intel-lpss: Add Intel Alder Lake PCH-P PCI IDs mfd: gateworks-gsc: Fix interrupt type mfd: Standardise MFD_CELL_* helper names mfd: mcp-sa11x0: Use DIV_ROUND_UP to calculate rw_timeout mfd: max8997: Add of_compatible to Extcon and Charger mfd_cell dt-bindings: mfd: Correct the node name of the panel LED mfd: sgi-ioc3: Turn Kconfig option into a bool mfd: altera-sysmgr: Fix physical address storing more ...
2021-02-12Merge remote-tracking branch 'regulator/for-5.12' into regulator-nextMark Brown
2021-02-12regulator: bd718x7, bd71828, Fix dvs voltage levelsMatti Vaittinen
The ROHM BD718x7 and BD71828 drivers support setting HW state specific voltages from device-tree. This is used also by various in-tree DTS files. These drivers do incorrectly try to compose bit-map using enum values. By a chance this works for first two valid levels having values 1 and 2 - but setting values for the rest of the levels do indicate capability of setting values for first levels as well. Luckily the regulators which support setting values for SUSPEND/LPSR do usually also support setting values for RUN and IDLE too - thus this has not been such a fatal issue. Fix this by defining the old enum values as bits and fixing the parsing code. This allows keeping existing IC specific drivers intact and only slightly changing the rohm-regulator.c Fixes: 21b72156ede8b ("regulator: bd718x7: Split driver to common and bd718x7 specific parts") Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Acked-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20210212080023.GA880728@localhost.localdomain Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-11regulator: pca9450: Enable system reset on WDOG_B assertionFrieder Schrempf
By default the PCA9450 doesn't handle the assertion of the WDOG_B signal, but this is required to guarantee that things like software resets triggered by the watchdog work reliably. As we don't want to rely on the bootloader to enable this, we tell the PMIC to issue a cold reset in case the WDOG_B signal is asserted (WDOG_B_CFG = 10), just as the NXP U-Boot code does. Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Link: https://lore.kernel.org/r/20210211105534.38972-3-frieder.schrempf@kontron.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-11regulator: pca9450: Add SD_VSEL GPIO for LDO5Frieder Schrempf
LDO5 has two separate control registers. LDO5CTRL_L is used if the input signal SD_VSEL is low and LDO5CTRL_H if it is high. The current driver implementation only uses LDO5CTRL_H. To make this work on boards that have SD_VSEL connected to a GPIO, we add support for specifying an optional GPIO and setting it to high at probe time. In the future we might also want to add support for boards that have SD_VSEL set to a fixed low level. In this case we need to change the driver to be able to use the LDO5CTRL_L register. Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Link: https://lore.kernel.org/r/20210211105534.38972-1-frieder.schrempf@kontron.de Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-11regulator: qcom-rpmh: fix pm8009 ldo7Jonathan Marek
Use the correct name to avoid ldo7 commands being sent to ldo6's address. Fixes: 06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20210211034935.5622-1-jonathan@marek.ca Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-08regulator: mt6315: Add support for MT6315 regulatorHsin-Hsiung Wang
The MT6315 is a regulator found on boards based on MediaTek MT8192 and probably other SoCs. It connects as a slave to SoC using SPMI. Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> Link: https://lore.kernel.org/r/1612678457-11548-3-git-send-email-hsin-hsiung.wang@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-02regulator: qcom-labibb: Use disable_irq_nosync from isrMatti Vaittinen
Calling the disable_irq() from irq handler might be a bad idea as disable_irq() should wait for handlers to run. I don't see why this wouldn't deadlock in wait_event waiting for the threaded handler to complete. Use disable_irq_nosync() instead. Fixes: 390af53e04114 ("regulator: qcom-labibb: Implement short-circuit and over-current IRQs") Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Link: https://lore.kernel.org/r/f2c4c88d90bf7473e1b84b8a99b7b33d7a081764.1612249657.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-28regulator: pf8x00: Fix typo for PF8200 chip nameAxel Lin
Trivial typo fix. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Adrien Grassein <adrien.grassein@gmail.com> Link: https://lore.kernel.org/r/20210128120151.554411-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-25regulator: pf8x00: set ramp_delay for bucksChristoph Fritz
This patch sets ramp_delay for bucks to the max value given by the datasheet. Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> Reviewed-by: Adrien Grassein <adrien.grassein@gmail.com> Link: https://lore.kernel.org/r/60d8eb8feefd26380cc9c6503f835e569be90465.camel@googlemail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-25regulator: core: Avoid debugfs: Directory ... already present! errorHans de Goede
Sometimes regulator_get() gets called twice for the same supply on the same device. This may happen e.g. when a framework / library is used which uses the regulator; and the driver itself also needs to enable the regulator in some cases where the framework will not enable it. Commit ff268b56ce8c ("regulator: core: Don't spew backtraces on duplicate sysfs") already takes care of the backtrace which would trigger when creating a duplicate consumer symlink under /sys/class/regulator/regulator.%d in this scenario. Commit c33d442328f5 ("debugfs: make error message a bit more verbose") causes a new error to get logged in this scenario: [ 26.938425] debugfs: Directory 'wm5102-codec-MICVDD' with parent 'spi-WM510204:00-MICVDD' already present! There is no _nowarn variant of debugfs_create_dir(), but we can detect and avoid this problem by checking the return value of the earlier sysfs_create_link_nowarn() call. Add a check for the earlier sysfs_create_link_nowarn() failing with -EEXIST and skip the debugfs_create_dir() call in that case, avoiding this error getting logged. Fixes: c33d442328f5 ("debugfs: make error message a bit more verbose") Cc: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20210122183250.370571-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-25regulator: pf8x00: Add suspend supportChristoph Fritz
This patch adds suspend/resume support so that it is possible to configure the LDOs and BUCKs as on or off during suspend phase as well as to configure suspend specific voltages. Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> Link: https://lore.kernel.org/r/4c2e79d4fa96befdc9a6c59c3ff27b0a34f9fb56.camel@googlemail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-22regulator: Make regulator_sync_voltage() usable by coupled regulatorsDmitry Osipenko
Make regulator_sync_voltage() to re-balance voltage state of a coupled regulators instead of changing the voltage directly. Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30 Tested-by: Dmitry Osipenko <digetx@gmail.com> # A500 T20 and Nexus7 T30 Tested-by: Nicolas Chauvet <kwizart@gmail.com> # PAZ00 T20 Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20210122174311.28230-1-digetx@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-22regulator: Fix lockdep warning resolving suppliesMark Brown
With commit eaa7995c529b54 (regulator: core: avoid regulator_resolve_supply() race condition) we started holding the rdev lock while resolving supplies, an operation that requires holding the regulator_list_mutex. This results in lockdep warnings since in other places we take the list mutex then the mutex on an individual rdev. Since the goal is to make sure that we don't call set_supply() twice rather than a concern about the cost of resolution pull the rdev lock and check for duplicate resolution down to immediately before we do the set_supply() and drop it again once the allocation is done. Fixes: eaa7995c529b54 (regulator: core: avoid regulator_resolve_supply() race condition) Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20210122132042.10306-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-21regulator: s5m8767: Drop regulators OF node referenceKrzysztof Kozlowski
The device node reference obtained with of_get_child_by_name() should be dropped on error paths. Fixes: 26aec009f6b6 ("regulator: add device tree support for s5m8767") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20210121155914.48034-1-krzk@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-21regulator: qcom-rpmh: Add pmc8180 and pmc8180cBjorn Andersson
The regulators from PMC8180 and PMC8180C exposed by the RPMH in the Qualcomm SC8180X seems to be the same as PM8150 and PM8150L. Add compatibles for the two new PMICs and reuse the definition of the existing PMICs. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210120224901.1611232-2-bjorn.andersson@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-21regulator: s5m8767: Fix reference count leakPan Bian
Call of_node_put() to drop references of regulators_np and reg_np before returning error code. Fixes: 9ae5cc75ceaa ("regulator: s5m8767: Pass descriptor instead of GPIO number") Signed-off-by: Pan Bian <bianpan2016@163.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20210121032756.49501-1-bianpan2016@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-21regulator: remove ab3100 driverArnd Bergmann
The ST-Ericsson U300 platform is getting removed, so this driver is no longer needed. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210120151307.1726876-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-21Merge series "Really implement Qualcomm LAB/IBB regulators" from ↵Mark Brown
AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>: Okay, the title may be a little "aggressive"? However, the qcom-labibb driver wasn't really .. doing much. The current form of this driver is only taking care of enabling or disabling the regulators, which is pretty useless if they were not pre-set from the bootloader, which sets them only if continuous splash is enabled. Moreover, some bootloaders are setting a higher voltage and/or a higher current limit compared to what's actually required by the attached hardware (which is, in 99.9% of the cases, a display) and this produces a higher power consumption, higher heat output and a risk of actually burning the display if kept up for a very long time: for example, this is true on at least some Sony Xperia MSM8998 (Yoshino platform) and especially on some Sony Xperia SDM845 (Tama platform) smartphones. In any case, the main reason why this change was necessary for us is that, during the bringup of Sony Xperia MSM8998 phones, we had an issue with the bootloader not turning on the display and not setting the lab and ibb regulators before booting the kernel, making it impossible to powerup the display. With this said, this patchset enables setting voltage, current limiting, overcurrent and short-circuit protection.. and others, on the LAB/IBB regulators. Each commit in this patch series provides as many informations as possible about what's going on and testing methodology. Changes in v4: - Remove already applied commit - Add commit to switch to regulator_{list,map}_voltage_linear which in v3 got squashed in the commit that got removed in v4. Changes in v3: - Improved check for PBS disable and short-circuit condition: during the testing of short-circuit, coincidentally another register reading zero on the interesting bit was probed, which didn't trigger a malfunction of the SC logic, but was also wrong. After the change, the short-circuit test was re-done in the same way as described in the commit that is implementing it. - From Bjorn Andersson review: - Improved documentation about over-current and short-circuit protection in the driver - Improved maintainability of qcom_labibb_sc_recovery_worker() - Flipped around check for PBS vreg disabled in for loop of function labibb_sc_err_handler() - From Mark Brown (forgotten in v2): - Changed regulator_{list,map}_voltage_linear_range usages to regulator_{list,map}_voltage_linear (and fixed regulator descs to reflect the change). Changes in v2: - From Mark Brown review: - Replaced some if branches with switch statements - Moved irq get and request in probe function - Changed short conditionals to full ones - Removed useless check for ocp_irq_requested - Fixed issues with YAML documentation AngeloGioacchino Del Regno (7): regulator: qcom-labibb: Switch voltage ops from linear_range to linear regulator: qcom-labibb: Implement current limiting regulator: qcom-labibb: Implement pull-down, softstart, active discharge dt-bindings: regulator: qcom-labibb: Document soft start properties regulator: qcom-labibb: Implement short-circuit and over-current IRQs dt-bindings: regulator: qcom-labibb: Document SCP/OCP interrupts arm64: dts: pmi8998: Add the right interrupts for LAB/IBB SCP and OCP .../regulator/qcom-labibb-regulator.yaml | 30 +- arch/arm64/boot/dts/qcom/pmi8998.dtsi | 8 +- drivers/regulator/qcom-labibb-regulator.c | 720 +++++++++++++++++- 3 files changed, 735 insertions(+), 23 deletions(-) -- 2.30.0
2021-01-20regulator: axp20x: Fix reference cout leakPan Bian
Decrements the reference count of device node and its child node. Fixes: dfe7a1b058bb ("regulator: AXP20x: Add support for regulators subsystem") Signed-off-by: Pan Bian <bianpan2016@163.com> Link: https://lore.kernel.org/r/20210120123313.107640-1-bianpan2016@163.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-20regulator: qcom-labibb: Implement short-circuit and over-current IRQsAngeloGioacchino Del Regno
Short-Circuit Protection (SCP) and Over-Current Protection (OCP) are very important for regulators like LAB and IBB, which are designed to provide from very small to relatively big amounts of current to the device (normally, a display). Now that this regulator supports both voltage setting and current limiting in this driver, to me it looked like being somehow essential to provide support for SCP and OCP, for two reasons: 1. SCP is a drastic measure to prevent damaging "more" hardware in the worst situations, if any was damaged, preventing potentially drastic issues; 2. OCP is a great way to protect the hardware that we're powering through these regulators as if anything bad happens, the HW will draw more current than expected: in this case, the OCP interrupt will fire and the regulators will be immediately shut down, preventing hardware damage in many cases. Both interrupts were successfully tested in a "sort-of" controlled manner, with the following methodology: Short-Circuit Protection (SCP): 1. Set LAB/IBB to 4.6/-1.4V, current limit 200mA/50mA; 2. Connect a 10 KOhm resistor to LAB/IBB by poking the right traces on a FxTec Pro1 smartphone for a very brief time (in short words, "just a rapid touch with flying wires"); 3. The Short-Circuit protection trips: IRQ raises, regulators get cut. Recovery OK, test repeated without rebooting, OK. Over-Current Protection (OCP): 1. Set LAB/IBB to the expected voltage to power up the display of a Sony Xperia XZ Premium smartphone (Sharp LS055D1SX04), set current limit to LAB 200mA, IBB 50mA (the values that this display unit needs are 200/800mA); 2. Boot the kernel: OCP fires. Recovery never happens because the selected current limit is too low, but that's expected. Test OK. 3. Set LAB/IBB to the expected current limits for XZ Premium (LAB 200mA, IBB 800mA), but lower than expected voltage, specifically LAB 5.4V, IBB -5.6V (instead of 5.6, -5.8V); 4. Boot the kernel: OCP fires. Recovery never happens because the selected voltage (still in the working range limits) is producing a current draw of more than 200mA on LAB. Test OK. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Link: https://lore.kernel.org/r/20210119174421.226541-6-angelogioacchino.delregno@somainline.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-20regulator: qcom-labibb: Implement pull-down, softstart, active dischargeAngeloGioacchino Del Regno
Soft start is required to avoid inrush current during LAB ramp-up and IBB ramp-down, protecting connected hardware to which we supply voltage. Since soft start is configurable on both LAB and IBB regulators, it was necessary to add two DT properties, respectively "qcom,soft-start-us" to control LAB ramp-up and "qcom,discharge-resistor-kohms" to control the discharge resistor for IBB ramp-down, which obviously brought the need of implementing a of_parse callback for both regulators. Finally, also implement pull-down mode in order to avoid unpredictable behavior when the regulators are disabled (random voltage spikes etc). Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210119174421.226541-4-angelogioacchino.delregno@somainline.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-20regulator: qcom-labibb: Implement current limitingAngeloGioacchino Del Regno
LAB and IBB regulators can be current-limited by setting the appropriate registers, but this operation is granted only after sending an unlock code for secure access. Besides the secure access, it would be possible to use the regmap helper for get_current_limit, as there is no security blocking reads, but I chose not to as to avoid having a very big array containing current limits, especially for IBB. That said, these regulators support current limiting for: - LAB (pos): 200-1600mA, with 200mA per step (8 steps), - IBB (neg): 0-1550mA, with 50mA per step (32 steps). Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Link: https://lore.kernel.org/r/20210119174421.226541-3-angelogioacchino.delregno@somainline.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-20regulator: qcom-labibb: Switch voltage ops from linear_range to linearAngeloGioacchino Del Regno
The LAB and IBB regulator have just one range and it is useless to use linear_range ops, as these are used to express multiple linear ranges. Switch list_voltage and map_voltage callbacks to *_linear instead. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Link: https://lore.kernel.org/r/20210119174421.226541-2-angelogioacchino.delregno@somainline.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-15Merge series "Really implement Qualcomm LAB/IBB regulators" from ↵Mark Brown
AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>: Okay, the title may be a little "aggressive"? However, the qcom-labibb driver wasn't really .. doing much. The current form of this driver is only taking care of enabling or disabling the regulators, which is pretty useless if they were not pre-set from the bootloader, which sets them only if continuous splash is enabled. Moreover, some bootloaders are setting a higher voltage and/or a higher current limit compared to what's actually required by the attached hardware (which is, in 99.9% of the cases, a display) and this produces a higher power consumption, higher heat output and a risk of actually burning the display if kept up for a very long time: for example, this is true on at least some Sony Xperia MSM8998 (Yoshino platform) and especially on some Sony Xperia SDM845 (Tama platform) smartphones. In any case, the main reason why this change was necessary for us is that, during the bringup of Sony Xperia MSM8998 phones, we had an issue with the bootloader not turning on the display and not setting the lab and ibb regulators before booting the kernel, making it impossible to powerup the display. With this said, this patchset enables setting voltage, current limiting, overcurrent and short-circuit protection.. and others, on the LAB/IBB regulators. Each commit in this patch series provides as many informations as possible about what's going on and testing methodology. Changes in v2: - From Mark Brown review: - Replaced some if branches with switch statements - Moved irq get and request in probe function - Changed short conditionals to full ones - Removed useless check for ocp_irq_requested - Fixed issues with YAML documentation AngeloGioacchino Del Regno (7): regulator: qcom-labibb: Implement voltage selector ops regulator: qcom-labibb: Implement current limiting regulator: qcom-labibb: Implement pull-down, softstart, active discharge dt-bindings: regulator: qcom-labibb: Document soft start properties regulator: qcom-labibb: Implement short-circuit and over-current IRQs dt-bindings: regulator: qcom-labibb: Document SCP/OCP interrupts arm64: dts: pmi8998: Add the right interrupts for LAB/IBB SCP and OCP .../regulator/qcom-labibb-regulator.yaml | 30 +- arch/arm64/boot/dts/qcom/pmi8998.dtsi | 8 +- drivers/regulator/qcom-labibb-regulator.c | 661 +++++++++++++++++- 3 files changed, 686 insertions(+), 13 deletions(-) -- 2.29.2
2021-01-15regulator: qcom-labibb: Implement voltage selector opsAngeloGioacchino Del Regno
Implement {get,set}_voltage_sel, list_voltage, map_voltage with the useful regulator regmap helpers in order to be able to manage the voltage of LAB (positive) and IBB (negative) regulators. In particular, the supported ranges are the following: - LAB (pos): 4600mV to 6100mV with 100mV stepping, - IBB (neg): -7700mV to -1400mV with 100mV stepping. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210113194214.522238-2-angelogioacchino.delregno@somainline.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-15regulator: pf8x00: fix nxp,phase-shiftAdrien Grassein
Fix the ternary condition which is a bad coding style in the kernel I also remove the defering configuration of the nxp,phase-shift. The configuration is now done at parsing time. It save some memory and it's better for comprehension. I also use the OTP default configuration when the parameter is wrong or not specified. I think that it's better to use the default configuration from the chip than an arbitrary value. Signed-off-by: Adrien Grassein <adrien.grassein@gmail.com> Link: https://lore.kernel.org/r/20210114174714.122561-7-adrien.grassein@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-15regulator: pf8x00: use linear range for buck 1-6Adrien Grassein
Use a linear range to describe the voltages of the bucks 1-6 instead of listing it one by one (via a macro) Signed-off-by: Adrien Grassein <adrien.grassein@gmail.com> Link: https://lore.kernel.org/r/20210114174714.122561-6-adrien.grassein@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-15regulator: pf8x00: mark nxp,ilim-ma property as deprecatedAdrien Grassein
This property seems useless because we can use the regulator-max-microamp generic property to do the same and using generic code. As this property was already released in a kernel version, we can't remove it, just mark it as deprecated. Signed-off-by: Adrien Grassein <adrien.grassein@gmail.com> Link: https://lore.kernel.org/r/20210114174714.122561-5-adrien.grassein@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-15regulator: pf8x00: add a doc for the moduleAdrien Grassein
pf8x00 module build was not documented. Signed-off-by: Adrien Grassein <adrien.grassein@gmail.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> Link: https://lore.kernel.org/r/20210114174714.122561-2-adrien.grassein@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-14regulator: bd9571mwv: Add BD9574MWF supportYoshihiro Shimoda
Add support for BD9574MWF which is similar chip with BD9571MWV. Note that we don't support voltage rails VD{09,18,25,33} by this driver on BD9574. The VD09 voltage could be read from PMIC but that is not supported by this commit. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2021-01-14regulator: bd9571mwv: rid of using struct bd9571mwvYoshihiro Shimoda
To simplify this driver, use dev_get_regmap() and rid of using struct bd9571mwv. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Acked-by: Mark Brown <broonie@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2021-01-13regulator: ab8500: Decomission platform data headerLinus Walleij
The platform data header was only used to pass platform data from board files. We now populate the regulators exclusively from device tree, so the header contents can be moved into the regulator drivers. Cc: Lee Jones <lee.jones@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201205004057.1712753-2-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-13regulator: ab8500: Remove unused platform dataLinus Walleij
The struct ab8500_regulator_platform_data was a leftover since the days before we probed all regulators from the device tree. The ab8500-ext regulator was the only used, defining platform data and register intialization that was never used for anything, a copy of a boardfile no longer in use. Delete the ab8500_regulator_platform_data and make the ab8500-ext regulator reference the regulator init data in the local file directly. We are 100% device tree these days. Cc: Lee Jones <lee.jones@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20201205004057.1712753-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-08regulator: core: avoid regulator_resolve_supply() race conditionDavid Collins
The final step in regulator_register() is to call regulator_resolve_supply() for each registered regulator (including the one in the process of being registered). The regulator_resolve_supply() function first checks if rdev->supply is NULL, then it performs various steps to try to find the supply. If successful, rdev->supply is set inside of set_supply(). This procedure can encounter a race condition if two concurrent tasks call regulator_register() near to each other on separate CPUs and one of the regulators has rdev->supply_name specified. There is currently nothing guaranteeing atomicity between the rdev->supply check and set steps. Thus, both tasks can observe rdev->supply==NULL in their regulator_resolve_supply() calls. This then results in both creating a struct regulator for the supply. One ends up actually stored in rdev->supply and the other is lost (though still present in the supply's consumer_list). Here is a kernel log snippet showing the issue: [ 12.421768] gpu_cc_gx_gdsc: supplied by pm8350_s5_level [ 12.425854] gpu_cc_gx_gdsc: supplied by pm8350_s5_level [ 12.429064] debugfs: Directory 'regulator.4-SUPPLY' with parent '17a00000.rsc:rpmh-regulator-gfxlvl-pm8350_s5_level' already present! Avoid this race condition by holding the rdev->mutex lock inside of regulator_resolve_supply() while checking and setting rdev->supply. Signed-off-by: David Collins <collinsd@codeaurora.org> Link: https://lore.kernel.org/r/1610068562-4410-1-git-send-email-collinsd@codeaurora.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-07Merge series "regulator: mcp16502: make lpm pin optional" from Claudiu ↵Mark Brown
Beznea <claudiu.beznea@microchip.com>: Hi, This patch makes the LPM pin as optional as this may be controlled in the last phase of suspend procedure to decrease the power consumption while suspended. Along w/ this update the MAINTAINERS entry for this driver. Thank you, Claudiu Beznea Claudiu Beznea (3): dt-bindings: regulator: mcp16502: document lpm as optional regulator: mcp16502: lpm pin can be optional on some platforms MAINTAINERS: add myself as maintainer for mcp16502 Documentation/devicetree/bindings/regulator/mcp16502-regulator.txt | 3 ++- MAINTAINERS | 4 ++-- drivers/regulator/mcp16502.c | 2 +- 3 files changed, 5 insertions(+), 4 deletions(-) -- 2.7.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
2021-01-07regulator: bd718x7: Stop using parent dataMatti Vaittinen
The ROHM PMIC regulator drivers only need the regmap pointer from the parent device. Regmap can be obtained via dev_get_regmap() so do not require parent to populate driver data for that. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20210107122355.GA35080@localhost.localdomain Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-07regulator: mcp16502: lpm pin can be optional on some platformsClaudiu Beznea
On some platform (e.g. SAMA7G5) LPM pin should be optional as it can be controlled explicitly (via shutdown controller registers) in the platform specific power saving code to decrease the power consumption while suspended as this SoC pin may be connected to other devices that could take power saving actions based on its value. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/1610028927-9842-3-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-01-05Merge series "Add driver for dvfsrc, support for active state of scpsys" ↵Mark Brown
from Henry Chen <henryc.chen@mediatek.com>: This series is based on v5.10-rc1. The patchsets add support for MediaTek hardware module named DVFSRC (dynamic voltage and frequency scaling resource collector). The DVFSRC is a HW module which is used to collect all the requests from both software and hardware and turn into the decision of minimum operating voltage and minimum DRAM frequency to fulfill those requests. So, This series is to implement the dvfsrc driver to collect all the requests of operating voltage or DRAM bandwidth from other device drivers likes GPU/Camera through 3 frameworks basically: 1. interconnect framework: to aggregate the bandwidth requirements from different clients [1] https://patchwork.kernel.org/cover/10766329/ There has a hw module "DRAM scheduler", which used to control the throughput. The DVFSRC will collect forecast data of dram bandwidth from SW consumers(camera/gpu...), and according the forecast to change the DRAM frequency 2. Regualtor framework: to handle the operating voltage requirement from user or cosumer which not belong any power domain Changes in V6: * Remove the performace state support, because the request from consumer can be replaced by using interconnect and regulator framework. * Update the DT patches and convert them to DT schema. (Georgi) * Modify the comment format and coding style. (Mark) Changes in V5: * Support more platform mt6873/mt8192 * Drop the compatible and interconnect provider node and make the parent node an interconnect provider. (Rob/Georgi) * Make modification of interconnect driver from coding suggestion. (Georgi) * Move interconnect diagram into the commit text of patch. (Georgi) * Register the interconnect provider as a platform sub-device. (Georgi) Changes in V4: * Add acked TAG on dt-bindings patches. (Rob) * Declaration of emi_icc_aggregate since the prototype of aggregate function has changed meanwhile. (Georgi) * Used emi_icc_remove instead of icc_provider_del on probe. (Georgi) * Add dvfsrc regulator driver into series. * Bug fixed of mt8183_get_current_level. * Add mutex protection for pstate operation on dvfsrc_set_performance. Changes in V3: * Remove RFC from the subject prefix of the series * Combine dt-binding patch and move interconnect dt-binding document into dvfsrc. (Rob) * Remove unused header, add unit descirption to the bandwidth, rename compatible name on interconnect driver. (Georgi) * Fixed some coding style: check flow, naming, used readx_poll_timeout on dvfsrc driver. (Ryan) * Rename interconnect driver mt8183.c to mtk-emi.c * Rename interconnect header mtk,mt8183.h to mtk,emi.h * mtk-scpsys.c: Add opp table check first to avoid OF runtime parse failed Changes in RFC V2: * Remove the DT property dram_type. (Rob) * Used generic dts property 'opp-level' to get the performace state. (Stephen) * Remove unecessary dependency config on Kconfig. (Stephen) * Remove unused header file, fixed some coding style issue, typo, error handling on dvfsrc driver. (Nicolas/Stephen) * Remove irq handler on dvfsrc driver. (Stephen) * Remove init table on dvfsrc driver, combine hw init on trustzone. * Add interconnect support of mt8183 to aggregate the emi bandwidth. (Georgi) V5: https://patchwork.kernel.org/project/linux-mediatek/list/?series=348065 V4: https://lore.kernel.org/patchwork/cover/1209284/ V3: https://patchwork.kernel.org/cover/11118867/ RFC V2: https://lore.kernel.org/patchwork/patch/1068113/ RFC V1: https://lore.kernel.org/patchwork/cover/1028535/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
2021-01-05regulator: ROHM bd7xxxx: Do not depend on parent driver dataMatti Vaittinen
The ROHM PMIC regulator drivers only need the regmap pointer from the parent device. Regmap can be obtained via dev_get_regmap() so do not require parent to populate driver data for that. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20210105130221.GA3438042@localhost.localdomain Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit (git 2.34.1) at 2024-06-11 22:51:19 +0000