- 11 Jul, 2021 1 commit
-
-
Axel Lin authored
Since config.dev = pdev->dev.parent in current code, so dev_get_drvdata(rdev->dev.parent) call in hi6421_regulator_enable returns the drvdata of the mfd device rather than the regulator. Fix it. This was broken while converting to use simplified DT parsing because the config.dev changed from pdev->dev to pdev->dev.parent for parsing the parent's of_node. Fixes: 29dc269a ("regulator: hi6421: Convert to use simplified DT parsing") Signed-off-by:
Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210630095959.2411543-1-axel.lin@ingics.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
- 07 Jul, 2021 2 commits
-
-
Axel Lin authored
If use dev->parent, the regulator_unregister will not be called when this driver is unloaded. Fix it by using dev instead. Signed-off-by:
-
Ulf Hansson authored
A power domain should not be modelled as a regulator, not even for the simplest case as recent discussions have concluded around the existing regulator-fixed-domain DT binding. Fortunately, there is only one user of the binding that was recently added. Therefore, let's mark the binding as deprecated to prevent it from being further used. Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20210705133441.11344-1-ulf.hansson@linaro.orgSigned-off-by:
-
- 01 Jul, 2021 1 commit
-
-
Axel Lin authored
Fix trivial copy-paste typo. Signed-off-by:
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/20210623153443.623856-1-axel.lin@ingics.comSigned-off-by:
-
- 30 Jun, 2021 1 commit
-
-
Axel Lin authored
Since config.dev = pdev->dev.parent in current code, so dev_get_drvdata(rdev->dev.parent) actually returns the drvdata of the mfd device rather than the regulator. Fix it. Fixes: 9bc146ac ("regulator: hi6421v600: Fix setting wrong driver_data") Reported-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
- 28 Jun, 2021 2 commits
-
-
Axel Lin authored
For linear regulators, the n_voltages should be (max - min) / step + 1. Buck voltage from 1v to 3V, per step 100mV, and vout mask is 0x1f. If value is from 20 to 31, the voltage will all be fixed to 3V. And LDO also, just vout range is different from 1.2v to 3v, step is the same. If value is from 18 to 31, the voltage will also be fixed to 3v. Signed-off-by:
ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/20210627080418.1718127-1-axel.lin@ingics.comSigned-off-by:
-
ChiYuan Huang authored
Fix wrong mask for strobe-polarity-high. Signed-off-by:
-
- 23 Jun, 2021 3 commits
-
-
Colin Ian King authored
The boolean variable may_have_irqs is not ininitialized and is only being set to true in the case where chip is ROHM_CHIP_TYPE_BD9576. Fix this by ininitialized may_have_irqs to false. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: e7bf1fa5 ("regulator: bd9576: Support error reporting") Signed-off-by:Colin Ian King <colin.king@canonical.com> Acked-by:
-
Axel Lin authored
Fix build error if REGMAP_I2C is not set. Signed-off-by:
-
Axel Lin authored
Use DIV_ROUND_UP to prevent truncation by integer division issue. This ensures we return enough delay time. Also fix returning negative value when new_sel < old_sel. Signed-off-by:
-
- 22 Jun, 2021 1 commit
-
-
Axel Lin authored
Current code set "config.driver_data = sreg" but sreg only init the mutex, the othere fields are just zero. Fix it by pass *info to config.driver_data so each regulator can get corresponding data by rdev_get_drvdata(). Separate enable_mutex from struct hi6421_spmi_reg_info since only need one mutex for the driver. Fixes: d2dfd50a ("staging: hikey9xx: hi6421v600-regulator: move LDO config from DT") Signed-off-by:
-
- 21 Jun, 2021 22 commits
-
-
Mark Brown authored
Merge series "regulator: qcom,rpmh-regulator: Add support for pmic available on SA8155p-adp board" from Bhupesh Sharma <bhupesh.sharma@linaro.org>: Changes since v2: ----------------- - v2 series can be found here: https://lore.kernel.org/linux-arm-msm/20210615074543.26700-1-bhupesh.sharma@linaro.org/T/#m8303d27d561b30133992da88198abb78ea833e21 - Addressed review comments from Bjorn and Mark. - As per suggestion from Bjorn, seperated the patches in different patchsets (specific to each subsystem) to ease review and patch application. Changes since v1: ----------------- - v1 series can be found here: https://lore.kernel.org/linux-arm-msm/20210607113840.15435-1-bhupesh.sharma@linaro.org/T/#mc524fe82798d4c4fb75dd0333318955e0406ad18 - Addressed review comments from Bjorn and Vinod received on the v1 series. This series adds the regulator support code for SA8155p-adp board which is based on Qualcomm snapdragon sa8155p SoC which in turn is simiar to the sm8150 SoC. This board supports a new PMIC PMM8155AU. While at it, also make some cosmetic changes to the regulator driver and dt-bindings to make sure the compatibles are alphabetical and also fix issues with extra comma(s) at the end of terminator line(s). Cc: Mark Brown <broonie@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Bhupesh Sharma (5): dt-bindings: regulator: qcom,rpmh-regulator: Arrange compatibles alphabetically dt-bindings: regulator: qcom,rpmh-regulator: Add compatible for SA8155p-adp board pmic regulator: qcom-rpmh: Cleanup terminator line commas regulator: qcom-rpmh: Add terminator at the end of pm7325x_vreg_data[] array regulator: qcom-rpmh: Add new regulator found on SA8155p adp board .../regulator/qcom,rpmh-regulator.yaml | 17 ++--- drivers/regulator/qcom-rpmh-regulator.c | 62 +++++++++++++++---- 2 files changed, 59 insertions(+), 20 deletions(-) -- 2.31.1
-
Mark Brown authored
Merge series "Extend regulator notification support" from Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>: Extend regulator notification support This series extends the regulator notification and error flag support. Initial discussion on the topic can be found here: https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.camel@fi.rohmeurope.com/ In a nutshell - the series adds: 1. WARNING level events/error flags. (Patch 3) Current regulator 'ERROR' event notifications for over/under voltage, over current and over temperature are used to indicate condition where monitored entity is so badly "off" that it actually indicates a hardware error which can not be recovered. The most typical hanling for that is believed to be a (graceful) system-shutdown. Here we add set of 'WARNING' level flags to allow sending notifications to consumers before things are 'that badly off' so that consumer drivers can implement recovery-actions. 2. Device-tree properties for specifying limit values. (Patches 1, 5) Add limits for above mentioned 'ERROR' and 'WARNING' levels (which send notifications to consumers) and also for a 'PROTECTION' level (which will be used to immediately shut-down the regulator(s) W/O informing consumer drivers. Typically implemented by hardware). Property parsing is implemented in regulator core which then calls callback operations for limit setting from the IC drivers. A warning is emitted if protection is requested by device tree but the underlying IC does not support configuring requested protection. 3. Helpers which can be registered by IC. (Patch 4) Target is to avoid implementing IRQ handling and IRQ storm protection in each IC driver. (Many of the ICs implementin these IRQs do not allow masking or acking the IRQ but keep the IRQ asserted for the whole duration of problem keeping the processor in IRQ handling loop). 4. Emergency poweroff function (refactored out of the thermal_core to kernel/reboot.c) which is called if IC fires error IRQs but IC reading fails and given retry-count is exceeded. (Patches 2, 4) Please note that the mutex in the emergency shutdown was replaced by a simple atomic in order to allow call from any context. The helper was attempted to be done so it could be used to implement roughly same logic as is used in qcom-labibb regulator. This means amongst other things a safety shut-down if IC registers are not readable. Using these shut-down retry counters are optional. The idea is that the helper could be also used by simpler ICs which do not provide status register(s) which can be used to check if error is still active. ICs which do not have such status register can simply omit the 'renable' callback (and retry-counts etc) - and helper assumes the situation is Ok and re-enables IRQ after given time period. If problem persists the handler is ran again and another notification is sent - but at least the delay allows processor to avoid IRQ loop. Patch 7 takes this notification support in use at BD9576MUF. Patch 8 is related to MFD change which is not really related to the RFC here. It was added to this series in order to avoid potential conflicts. Patch 9 adds a maintainers entry. Changelog v10-RESEND: - rebased on v5.13-rc4 Changelog v10: - rebased on v5.13-rc2 - Move rdev_*() print macros to the internal.h and use rdev_dbg() from irq_helpers.c - Export rdev_get_name() and move it from coupler.h to driver.h for others to use. (It was already in coupler.h but not exported - usage was limited and coupler.h does not sound like optimal place as rdev_name is not only used by coupled regulators) - Send all regulator notifications from irq_helpers.c at one OR'd event for the sake of simplicity. For BD9576 this does not matter as it has own IRQ for each event case. Header defining events says they may be OR'd. - Change WARN() at protection shutdown to pr_emerg as suggested by Petr. Changelog v9: - rebases on v5.13-rc1 - Update thermal documentation - Fix regulator notification event number Changelog v8: - split shutdown API adding and thermal core taking it in use to own patches. - replace the spinlock with atomic when ensuring the emergency shutdown is only called once. Changelog v7: general: - rebased on v5.12-rc7 - new patch for refactoring the hw-failure reboot logic out of thermal_core.c for others to use. notification helpers: - fix regulator error_flags query - grammar/typos - do not BUG() but attempt to shut-down the system - use BITS_PER_TYPE() Changelog v6: Add MAINTAINERS entry Changes to IRQ notifiers - move devm functions to drivers/regulator/devres.c - drop irq validity check - use devm_add_action_or_reset() - fix styling issues - fix kerneldocs Changelog v5: - Fix the badly formatted pr_emerg() call. Changelog v4: - rebased on v5.12-rc6 - dropped RFC - fix external FET DT-binding. - improve prints for cases when expecting HW failure. - styling and typos Changelog v3: Regulator core: - Fix dangling pointer access at regulator_irq_helper() stpmic1_regulator: - fix function prototype (compile error) bd9576-regulator: - Update over current limits to what was given in new data-sheet (REV00K) - Allow over-current monitoring without external FET. Set limits to values given in data-sheet (REV00K). Changelog v2: Generic: - rebase on v5.12-rc2 + BD9576 series - Split devm variant of delayed wq to own series Regulator framework: - Provide non devm variant of IRQ notification helpers - shorten dt-property names as suggested by Rob - unconditionally call map_event in IRQ handling and require it to be populated BD9576 regulators: - change the FET resistance property to micro-ohms - fix voltage computation in OC limit setting
-
Matti Vaittinen authored
Add a reviewer entry for the regulator irq_helpers. Signed-off-by:
-
Matti Vaittinen authored
Driver name was changed in MFD cell: https://lore.kernel.org/lkml/560b9748094392493ebf7af11b6cc558776c4fd5.1613031055.git.matti.vaittinen@fi.rohmeurope.com/ Fix the ID table to match this. Fixes: b1b3ced3 ("mfd: Support ROHM BD9576MUF and BD9573MUF") Signed-off-by:
-
Matti Vaittinen authored
BD9573 and BD9576 support set of "protection" interrupts for "fatal" issues. Those lead to SOC reset as PMIC shuts the power outputs. Thus there is no relevant IRQ handling for them. Few "detection" interrupts were added to the BD9576 with the idea that SOC could take some recovery-action before error gets unrecoverable. Add support for over and under voltage detection for Vout1 ... Vout4 and VoutL1. Add over-current detection for VoutS1 and finally a thermal warning (common for all regulators) which alerts 30 C before temperature reaches the thermal shutdown point. This way consumer drivers can build error-recovery mechanisms. Unfortunately the BD9576 interrupt logic was not re-evaluated. IRQs are not designed to be properly acknowleged - and IRQ line is kept active for whole duration of error condition (in comparison to informing only about state change). Signed-off-by:
-
Matti Vaittinen authored
BD9576MUF provides over-current protection and detection. Current is measured as voltage loss over external FET. Allow specifying FET's on resistance so current monitoring limits can be converted to voltages. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/e5feb160d7e09f33fff5b88f1928c66a15c6680f.1622628334.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by:
-
Matti Vaittinen authored
Add DT property parsing code and setting callback for regulator over/under voltage, over-current and temperature error limits. Signed-off-by:
-
Matti Vaittinen authored
Provide helper function for IC's implementing regulator notifications when an IRQ fires. The helper also works for IRQs which can not be acked. Helper can be set to disable the IRQ at handler and then re-enabling it on delayed work later. The helper also adds regulator_get_error_flags() errors in cache for the duration of IRQ disabling. Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/ebdf86d8c22b924667ec2385330e30fcbfac0119.1622628334.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by:
-
Matti Vaittinen authored
The rdev print helpers are a nice way to print messages related to a specific regulator device. Move them from core.c to internal.h As the rdev print helpers use rdev_get_name() export it from core.c. Also move the declaration from coupler.h to driver.h because the rdev name is not just a coupled regulator property. I guess the main audience for rdev_get_name() will be the regulator core and drivers. Signed-off-by:
-
Matti Vaittinen authored
Add 'warning' level events and error flags to regulator core. Current regulator core notifications are used to inform consumers about errors where HW is misbehaving in such way it is assumed to be broken/unrecoverable. There are PMICs which are designed for system(s) that may have use for regulator indications sent before HW is damaged so that some board/consumer specific recovery-event can be performed while continuing most of the normal operations. Add new WARNING level events and notifications to be used for that purpose. Signed-off-by:
-
Matti Vaittinen authored
The hardware shutdown function was exported from kernel/reboot for other subsystems to use. Logic is copied from the thermal_core. The protection mutex is replaced by an atomic_t to allow calls also from an IRQ context. Also the WARN() was replaced by pr_emerg() based on discussions here: https://lore.kernel.org/lkml/YJuPwAZroVZ%2Fw633@alley/ and here: https://lore.kernel.org/linux-iommu/20210331093104.383705-4-geert+renesas@glider.be/ Use the exported API instead of implementing own just for the thermal_core. Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/5531e89d9e710f5d10e7cdce3ee58957335b9e03.1622628333.git.matti.vaittinen@fi.rohmeurope.comSigned-off-by:
-
Matti Vaittinen authored
There can be few cases when we need to shut-down the system in order to protect the hardware. Currently this is done at least by the thermal core when temperature raises over certain limit. Some PMICs can also generate interrupts for example for over-current or over-voltage, voltage drops, short-circuit, ... etc. On some systems these are a sign of hardware failure and only thing to do is try to protect the rest of the hardware by shutting down the system. Add shut-down logic which can be used by all subsystems instead of implementing the shutdown in each subsystem. The logic is stolen from thermal_core with difference of using atomic_t instead of a mutex in order to allow calls directly from IRQ context and changing the WARN() to pr_emerg() as discussed here: https://lore.kernel.org/lkml/YJuPwAZroVZ%2Fw633@alley/ and here: https://lore.kernel.org/linux-iommu/20210331093104.383705-4-geert+renesas@glider.be/Signed-off-by:
-
Matti Vaittinen authored
Support specifying protection/error/warning limits for regulator over current, over temperature and over/under voltage. Most of the PMICs support only "protection" feature but few setups do also support error/warning level indications. On many ICs most of the protection limits can't actually be set. But for example the ampere limit for over-current protection on ROHM BD9576 can be configured - or feature can be completely disabled. Provide limit setting for all protections/errors for the sake of the completeness and do that using own properties for all so that not all users would need to set all levels when only one or few are supported. Signed-off-by:
-
Axel Lin authored
commit db27f829 changed eco_mode << (ffs(sreg->eco_mode_mask) - 1) to sreg->eco_mode_mask << (ffs(sreg->eco_mode_mask) - 1) which is wrong. Fix it by simply set val = sreg->eco_mode_mask. In additional, sreg->eco_mode_mask can be 0 (LDO3, LDO33, LDO34). Return -EINVAL if idle mode is not supported when sreg->eco_mode_mask is 0. While at it, also use unsigned int for reg_val/val which is the expected type for regmap_read and regmap_update_bits. Fixes: db27f829 ("staging: regulator: hi6421v600-regulator: use shorter names for OF properties") Signed-off-by:
-
Sergey Larin authored
Add Maxim MAX8893 PMIC device tree bindings. The example is also provided. Signed-off-by:
Sergey Larin <cerg2010cerg2010@mail.ru> Link: https://lore.kernel.org/r/20210618141607.884-2-cerg2010cerg2010@mail.ruSigned-off-by:
-
Sergey Larin authored
MAX8893 is a simple regulator which can be found on some of Sasmsung phones. Signed-off-by:
-
Axel Lin authored
Use unsigned int instead of u32 for regmap_read/regmap_update_bits val argument. Signed-off-by:
-
Bhupesh Sharma authored
Add compatible string for pmm8155au pmic found on the SA8155p-adp board. Cc: Mark Brown <broonie@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Bhupesh Sharma <bhupesh.sharma@linaro.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210617051712.345372-3-bhupesh.sharma@linaro.orgSigned-off-by:
-
Bhupesh Sharma authored
Arrange the compatibles inside qcom-rpmh regulator device tree bindings alphabetically. Cc: Mark Brown <broonie@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Bhupesh Sharma authored
SA8155p-adp board supports a new regulator - pmm8155au. The output power management circuits in this regulator include: - FTS510 smps, - HFS510 smps, and - LDO510 linear regulators Add support for the same. Cc: Mark Brown <broonie@kernel.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Bhupesh Sharma authored
Add missing terminator(s) at the end of pm7325x_vreg_data[] array instances. Fixes: c4e5aa3d ("regulator: qcom-rpmh: Add PM7325/PMR735A regulator support") Cc: Mark Brown <broonie@kernel.org> Reviewed-by:
-
Bhupesh Sharma authored
Cleanup the qcom-rpmh regulator driver to remove comma(s) at the end of the terminator line(s). Cc: Mark Brown <broonie@kernel.org> Reviewed-by:
-
- 16 Jun, 2021 5 commits
-
-
Rouven Czerwinski authored
Instead of returning the the PTR_ERR directly, use dev_err_probe which will also correctly set the deferred probe reason in /sys/kernel/debug/deferred_devices, making it easier to debug missing devices on the system. Signed-off-by:
Rouven Czerwinski <r.czerwinski@pengutronix.de> Link: https://lore.kernel.org/r/20210616125331.153414-1-r.czerwinski@pengutronix.deSigned-off-by:
-
Axel Lin authored
At the context with *rdev, use rdev_get_drvdata() is more intuitive. Signed-off-by:
Alistair Francis <alistair@alistair23.me> Link: https://lore.kernel.org/r/20210616034458.3499522-3-axel.lin@ingics.comSigned-off-by:
-
Axel Lin authored
It's only used in this file and never changed, make it static const. Signed-off-by:
-
Axel Lin authored
The platform_device_id table is supposed to be zero-terminated. Signed-off-by:
-
Axel Lin authored
The vsel active level is for the normal voltage, the opposite level is the suspend voltage. Signed-off-by:
-
- 15 Jun, 2021 2 commits
-
-
Axel Lin authored
devm_regmap_init_spmi_ext() returns ERR_PTR() on error. Signed-off-by:
-
Alistair Francis authored
Initial support for the Silergy SY7636A-regulator Power Management chip. Signed-off-by:
-
