- 22 Feb, 2022 2 commits
-
-
Adam Ward authored
Update DA9141/2 max voltage to match spec change Signed-off-by:
Adam Ward <Adam.Ward.opensource@diasemi.com> Link: https://lore.kernel.org/r/9d1ec5b6db70d27f56d05b8a0139fc0840f03e20.1645489455.git.Adam.Ward.opensource@diasemi.comSigned-off-by:
Mark Brown <broonie@kernel.org>
-
Adam Ward authored
Update DA9141/2 ranges to correct errors Signed-off-by:
-
- 08 Feb, 2022 1 commit
-
-
Oliver Barta authored
The check done by regulator_late_cleanup() to detect whether a regulator is on was inconsistent with the check done by _regulator_is_enabled(). While _regulator_is_enabled() takes the enable GPIO into account, regulator_late_cleanup() was not doing that. This resulted in a false positive, e.g. when a GPIO-controlled fixed regulator was used, which was not enabled at boot time, e.g. reg_disp_1v2: reg_disp_1v2 { compatible = "regulator-fixed"; regulator-name = "display_1v2"; regulator-min-microvolt = <1200000>; regulator-max-microvolt = <1200000>; gpio = <&tlmm 148 0>; enable-active-high; }; Such regulator doesn't have an is_enabled() operation. Nevertheless it's state can be determined based on the enable GPIO. The check in regulator_late_cleanup() wrongly assumed that the regulator is on and tried to disable it. Signed-off-by:Oliver Barta <oliver.barta@aptiv.com> Link: https://lore.kernel.org/r/20220208084645.8686-1-oliver.barta@aptiv.comSigned-off-by:
-
- 19 Jan, 2022 1 commit
-
-
Randy Dunlap authored
max20086-regulator.c needs <linux/gpio/consumer.h> for an enum, some macros, and a function prototype. (seen on ARCH=m68k) Adding this header file fixes multiple build errors: ../drivers/regulator/max20086-regulator.c: In function 'max20086_i2c_probe': ../drivers/regulator/max20086-regulator.c:217:26: error: storage size of 'flags' isn't known 217 | enum gpiod_flags flags; ../drivers/regulator/max20086-regulator.c:261:27: error: 'GPIOD_OUT_HIGH' undeclared (first use in this function); did you mean 'GPIOF_INIT_HIGH'? 261 | flags = boot_on ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW; | ^~~~~~~~~~~~~~ ../drivers/regulator/max20086-regulator.c:261:44: error: 'GPIOD_OUT_LOW' undeclared (first use in this function); did you mean 'GPIOF_INIT_LOW'? 261 | flags = boot_on ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW; ../drivers/regulator/max20086-regulator.c:262:27: error: implicit declaration of function 'devm_gpiod_get'; did you mean 'devm_gpio_free'? [-Werror=implicit-function-declaration] 262 | chip->ena_gpiod = devm_gpiod_get(chip->dev, "enable", flags); ../drivers/regulator/max20086-regulator.c:217:26: warning: unused variable 'flags' [-Wunused-variable] 217 | enum gpiod_flags flags; Fixes: bfff546a ("regulator: Add MAX20086-MAX20089 driver") Signed-off-by:Randy Dunlap <rdunlap@infradead.org> Reported-by:
kernel test robot <lkp@intel.com> Cc: Watson Chow <watson.chow@avnet.com> Cc: Mark Brown <broonie@kernel.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20220115033603.24473-1-rdunlap@infradead.orgSigned-off-by:
-
- 11 Jan, 2022 1 commit
-
-
Dan Carpenter authored
This code accidentally returns PTR_ERR(NULL) which is success. It should return a negative error code. Fixes: bfff546a ("regulator: Add MAX20086-MAX20089 driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
- 07 Jan, 2022 2 commits
-
-
Watson Chow authored
The MAX20086-MAX20089 are dual/quad power protectors for cameras. Add a driver that supports controlling the outputs individually. Additional features, such as overcurrent detection, may be added later if needed. Signed-off-by:
Watson Chow <watson.chow@avnet.com> Signed-off-by:
-
Laurent Pinchart authored
The MAX20086-MAX20089 are dual/quad power protectors for cameras. Add corresponding DT bindings. Signed-off-by:
-
- 06 Jan, 2022 1 commit
-
-
Konrad Dybcio authored
The RPMh regulator driver is much newer and gets more attention, which in consequence makes it do a few things better. Update qcom_smd-regulator's probe function to mimic what rpmh-regulator does to address a couple of issues: - Probe defer now works correctly, before it used to, well, kinda just die.. This fixes reliable probing on (at least) PM8994, because Linux apparently cannot deal with supply map dependencies yet.. - Regulator data is now matched more sanely: regulator data is matched against each individual regulator node name and throwing an -EINVAL if data is missing, instead of just assuming everything is fine and iterating over all subsequent array members. - status = "disabled" will now work for disabling individual regulators in DT. Previously it didn't seem to do much if anything at all. Signed-off-by:
Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20211230023442.1123424-1-konrad.dybcio@somainline.orgSigned-off-by:
-
- 04 Jan, 2022 1 commit
-
-
Minghao Chi authored
Return value from regmap_update_bits() directly instead of taking this in another redundant variable. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by:
CGEL ZTE <cgel.zte@gmail.com> Link: https://lore.kernel.org/r/20220104104139.601031-1-chi.minghao@zte.com.cnSigned-off-by:
-
- 24 Dec, 2021 1 commit
-
-
Marijn Suijten authored
Receiving the Over-Current Protection interrupt while the regulator is disabled does not count as unhandled/failure (IRQ_NONE, or 0 as it were) but a "fake event", usually due to inrush as the is regulator about to be enabled. Fixes: 390af53e ("regulator: qcom-labibb: Implement short-circuit and over-current IRQs") Signed-off-by:
Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Link: https://lore.kernel.org/r/20211224113450.107958-1-marijn.suijten@somainline.orgSigned-off-by:
-
- 21 Dec, 2021 1 commit
-
-
Rob Herring authored
There's no need for a fixed string like 'BUCK9' to be under 'patternProperties', so move it under 'properties' instead. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211221120744.1118518-1-robh@kernel.orgSigned-off-by:
-
- 15 Dec, 2021 2 commits
-
-
Hans de Goede authored
The TPS68470 PMIC provides Clocks, GPIOs and Regulators. At present in the kernel the Regulators and Clocks are controlled by an OpRegion driver designed to work with power control methods defined in ACPI, but some platforms lack those methods, meaning drivers need to be able to consume the resources of these chips through the usual frameworks. This commit adds a driver for the regulators provided by the tps68470, and is designed to bind to the platform_device registered by the intel_skl_int3472 module. This is based on this out of tree driver written by Intel: https://github.com/intel/linux-intel-lts/blob/4.14/base/drivers/regulator/tps68470-regulator.c with various cleanups added. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-6-hdegoede@redhat.comSigned-off-by:
-
Mark Brown authored
Merge tag 'platform-drivers-x86-int3472-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 into regulator-5.17 Signed tag for the immutable platform-drivers-x86-int3472 branch This branch contains 5.16-rc1 + the pending ACPI/i2c, tps68570 platform_data and INT3472 driver patches required so that the tps68570 regulator driver can be applied.
-
- 13 Dec, 2021 10 commits
-
-
Minghao Chi authored
Return value from twlreg_write() directly instead of taking this in another redundant variable. Reported-by:
-
Hans de Goede authored
The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around this info missing from the ACPI tables on devices where the int3472 driver is used, the int3472 MFD-cell drivers attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. All the sensor ACPI fw-nodes have a _DEP dependency on the INT3472 ACPI fw-node, so to work around these probe ordering issues the ACPI core / i2c-code does not instantiate the I2C-clients for any ACPI devices which have a _DEP dependency on an INT3472 ACPI device until all _DEP-s are met. This relies on acpi_dev_clear_dependencies() getting called by the driver for the _DEP-s when they are ready, add a acpi_dev_clear_dependencies() call to the discrete.c probe code. In the tps68470 case calling acpi_dev_clear_dependencies() is already done by the acpi_gpiochip_add() call done by the driver for the GPIO MFD cell (The GPIO cell is deliberately the last cell created to make sure the clk + regulator cells are already instantiated when this happens). However for proper probe ordering, the clk/regulator cells must not just be instantiated the must be fully ready (the clks + regulators must be registered with their subsystems). Add MODULE_SOFTDEP dependencies for the clk and regulator drivers for the instantiated MFD-cells so that these are loaded before us and so that they bind immediately when the platform-devs are instantiated. Reviewed-by:
-
Hans de Goede authored
Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell, specifying the voltages of the various regulators and tying the regulators to the sensor supplies so that sensors which use the TPS68470 can find their regulators. Since the voltages and supply connections are board-specific, this introduces a DMI matches int3472_tps68470_board_data struct which contains the necessary per-board info. This per-board info also includes GPIO lookup information for the sensor IO lines which may be connected to the tps68470 GPIOs. Reviewed-by:
-
Hans de Goede authored
Pass tps68470_clk_platform_data to the tps68470-clk MFD-cell, so that sensors which use the TPS68470 can find their clock. Reviewed-by:
-
Hans de Goede authored
The discrete.c code is not the only code which needs to lookup the acpi_device and device-name for the sensor for which the INT3472 ACPI-device is a GPIO/clk/regulator provider. The tps68470.c code also needs this functionality, so factor this out into a new get_sensor_adev_and_name() helper. Reviewed-by:
-
Hans de Goede authored
The intel_skl_int3472.ko module contains 2 separate drivers, the int3472_discrete platform driver and the int3472_tps68470 I2C-driver. These 2 drivers contain very little shared code, only skl_int3472_get_acpi_buffer() and skl_int3472_fill_cldb() are shared. Split the module into 2 drivers, linking the little shared code directly into both. This will allow us to add soft-module dependencies for the tps68470 clk, gpio and regulator drivers to the new intel_skl_int3472_tps68470.ko to help with probe ordering issues without causing these modules to get loaded on boards which only use the int3472_discrete platform driver. While at it also rename the .c and .h files to remove the cumbersome intel_skl_int3472_ prefix. Reviewed-by:
-
Hans de Goede authored
The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the provider-device during probe/registration of the provider device. The TI TPS68470 PMIC is used x86/ACPI devices with the consumer-info missing from the ACPI tables. Thus the tps68470-clk and tps68470-regulator drivers must provide the consumer-info at probe time. Define tps68470_clk_platform_data and tps68470_regulator_platform_data structs to allow the x86 platform code to pass the necessary consumer info to these drivers. Reviewed-by:
-
Hans de Goede authored
Change i2c_acpi_new_device() into i2c_acpi_new_device_by_fwnode() and add a static inline wrapper providing the old i2c_acpi_new_device() behavior. This is necessary because in some cases we may only have access to the fwnode / acpi_device and not to the matching physical-node struct device *. Suggested-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Hans de Goede authored
The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. To ensure the correct probe-ordering the ACPI core has code to defer the enumeration of consumers affected by this until the providers are ready. Call the new acpi_dev_ready_for_enumeration() helper to avoid enumerating / instantiating i2c-clients too early. Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
-
Hans de Goede authored
The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. One case where we hit this issue is camera sensors such as e.g. the OV8865 sensor found on the Microsoft Surface Go. The sensor uses clks, regulators and GPIOs provided by a TPS68470 PMIC which is described in an INT3472 ACPI device. There is special platform code handling this and setting platform_data with the necessary consumer info on the MFD cells instantiated for the PMIC under: drivers/platform/x86/intel/int3472. For this to work properly the ov8865 driver must not bind to the I2C-client for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and clk MFD cells have all been fully setup. The OV8865 on the Microsoft Surface Go is just one example, all X86 devices using the Intel IPU3 camera block found on recent Intel SoCs have similar issues where there is an INT3472 HID ACPI-device, which describes the clks and regulators, and the driver for this INT3472 device must be fully initialized before the sensor driver (any sensor driver) binds for things to work properly. On these devices the ACPI nodes describing the sensors all have a _DEP dependency on the matching INT3472 ACPI device (there is one per sensor). This allows solving the probe-ordering problem by delaying the enumeration (instantiation of the I2C-client in the ov8865 example) of ACPI-devices which have a _DEP dependency on an INT3472 device. The new acpi_dev_ready_for_enumeration() helper used for this is also exported because for devices, which have the enumeration_by_parent flag set, the parent-driver will do its own scan of child ACPI devices and it will try to enumerate those during its probe(). Code doing this such as e.g. the i2c-core-acpi.c code must call this new helper to ensure that it too delays the enumeration until all the _DEP dependencies are met on devices which have the new honor_deps flag set. Acked-by:
-
- 07 Dec, 2021 3 commits
-
-
Yanteng Si authored
Since 89a6a5e5("regulator: add property parsing and callbacks to set protection limits") which introduced a warning: Documentation/driver-api/regulator:166: ./include/linux/regulator/driver.h:96: WARNING: Unexpected indentation. Documentation/driver-api/regulator:166: ./include/linux/regulator/driver.h:98: WARNING: Block quote ends without a blank line; unexpected unindent. Let's fix them. Signed-off-by:
Yanteng Si <siyanteng@loongson.cn> Link: https://lore.kernel.org/r/20211207123230.2262047-1-siyanteng@loongson.cnSigned-off-by:
-
Thierry Reding authored
According to the description and the various uses of this property it is meant to be an array of unsigned 32-bit values, so fixup the type to match that. Signed-off-by:
Thierry Reding <treding@nvidia.com> Acked-by:
-
Thierry Reding authored
One of the examples in the bindings has an interrupts property and the Linux kernel driver has support for requesting an interrupt as well. It looks like the absence from the bindings was just an oversight. Add the property to make sure the examples can be validated. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20211206153432.226963-1-thierry.reding@gmail.comSigned-off-by:
-
- 01 Dec, 2021 2 commits
-
-
Vinod Koul authored
Add the rpmh regulators found in PM8450 PMIC Signed-off-by:
Vinod Koul <vkoul@kernel.org> Tested-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20211201072515.3968843-3-vkoul@kernel.orgSigned-off-by:
-
Vinod Koul authored
Add compatible string for PM8450 used in SM8450 boards. Signed-off-by:
-
- 30 Nov, 2021 4 commits
-
-
Adam Ward authored
Add the configuration for the DA9141 and DA9142 regulators. Also tidy the table, cleaning away superfluous information. Signed-off-by:
-
Adam Ward authored
Clean away information from a test that was included accidentally Signed-off-by:
-
Adam Ward authored
Add the DA9141 and DA9142 regulators device recognition data and operational parameters. Signed-off-by:
-
Adam Ward authored
Prevent changing current limit when enabled as a precaution against possibile instability due to tight integration with switching cycle Signed-off-by:
-
- 29 Nov, 2021 2 commits
-
-
Satya Priya authored
Add support for PMG1110 regulators. Signed-off-by:
Satya Priya <quic_c_skakit@quicinc.com> Link: https://lore.kernel.org/r/1637668167-31325-3-git-send-email-quic_c_skakit@quicinc.comSigned-off-by:
-
Satya Priya authored
Add compatible string for pmg1110 pmic. Signed-off-by:
-
- 26 Nov, 2021 2 commits
-
-
Dominik Kobinski authored
The PM8226 PMIC is very often seen on MSM8x26 boards. Suggested-by:
Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com> Signed-off-by:
Dominik Kobinski <dominikkobinski314@gmail.com> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211123181119.2897-1-dominikkobinski314@gmail.comSigned-off-by:
-
Dominik Kobinski authored
Suggested-by:
-
- 24 Nov, 2021 4 commits
-
-
Matti Vaittinen authored
Function rohm_regulator_set_voltage_sel_restricted() and rohm_regulator_set_dvs_levels() had inlined dummy implementations for cases when the real implementation was not configured in. All of the drivers who issue the call to these functions do SELECT the real implementation from the Kconfig. There should be no cases where the real implementation was not selected by the drivers using these functions - such a situation is likely to be an error which deserves to be noticed at compile-time. These dummies could in theory be used for compile-testing the drivers only (without the generic rohm regulator pieces). However, for such compile testing we should manually drop the selection from KConfig - and I guess that if it does not work out-of-the-box, then it is not going to happen. Especially when there should be no reason to omit compile-testing the generic rohm_regulator part. Crash test dummies. Signed-off-by:
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/YZ3UXXrk/Efe7Scj@fedoraSigned-off-by:
-
Matti Vaittinen authored
Provide a generic map_event helper for regulators which have a notification IRQ with single, well defined purpose. Eg, IRQ always indicates exactly one event for exactly one regulator device. For such IRQs the mapping is trivial. Signed-off-by:
-
Matti Vaittinen authored
Help drivers avoid storing both supported notification and supported error flags by supporting conversion from regulator error to notification. This may help saving some bytes. Add helper for finding the regulator notification corresponding to a regulator error. Signed-off-by:
-
Matti Vaittinen authored
The irq_flags from the regulator IRQ helper description struct was never used. The IRQ flags are passed as parameters to helper registration instead. Remove the unnecessary struct field. Fixes: 7111c6d1 ("regulator: IRQ based event/error notification helpers") Signed-off-by:
-
