- 17 Aug, 2021 1 commit
-
-
Sebastian Krzyszkowiak authored
This register is same as in MAX17047 and MAX17050, so there's no need for custom casing it. Signed-off-by:
Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com>
-
- 16 Aug, 2021 9 commits
-
-
Dmitry Osipenko authored
SMB347 can supply power to USB VBUS, implement the USB VBUS regulator. USB VBUS needs to be powered for switching OTG-cable USB port into host mode. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
-
Dmitry Osipenko authored
Pin control needs to be activated by setting the enable bit, otherwise hardware rejects all pin changes. Previously this stayed unnoticed on Nexus 7 because pin control was enabled by default after rebooting from downstream kernel, which uses driver that enables the bit and charger registers are non-volatile until power supply (battery) is disconnected. Configure the pin control enable bit. This fixes the potentially never-enabled charging on devices that use pin control. Signed-off-by:
-
Dmitry Osipenko authored
Utilize generic regmap caching in order to avoid unnecessary slow I2C accesses to all constant registers each time the supply status updated and remove local caching of charger state to make code cleaner. Signed-off-by:
-
Dmitry Osipenko authored
The smb347_set_writable() is used by interrupt handler and outside of it. The interrupt should be disabled when the function is used outside of interrupt handler in order to prevent racing with the interrupt context. Add new parameter to smb347_set_writable() that allows to disable IRQ. Signed-off-by:
-
Dmitry Osipenko authored
SMB347 can supply power to USB VBUS, which is required by OTG-cable devices that want to switch USB port into the host mode. Add USB VBUS regulator properties. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Emil Renner Berthing authored
The only way to reset the BeagleV Starlight v0.9 board[1] properly is to tell the PMIC to reset itself which will then assert the external reset lines of the SoC, USB hub and ethernet phy. This adds a driver to register a reset handler to do just that. [1] https://github.com/beagleboard/beaglev-starlightSigned-off-by:
Emil Renner Berthing <kernel@esmil.dk> Signed-off-by:
-
Krzysztof Kozlowski authored
The Maxim 17042-family of fuel gauges are often embedded in other Maxim chips, e.g. in Maxim 77693 which is a companion power management IC. In such designs there might be actually two interrupts: - INTB signaling change from charger, flash or MUIC, - ALERT signaling change from fuel gauge. Describe the interrupt in bindings to make it clear it is about the fuel gauge ALERT interrupt, not the INT. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Krzysztof Kozlowski authored
All bits of STATUS register are already defined (see STATUS_SMN_BIT and further) so there is no need to define status SoC threshold min/max values one more time. Signed-off-by:
-
Krzysztof Kozlowski authored
Reading status register can fail in the interrupt handler. In such case, the regmap_read() will not store anything useful under passed 'val' variable and random stack value will be used to determine type of interrupt. Handle the regmap_read() failure to avoid handling interrupt type and triggering changed power supply event based on random stack value. Fixes: 39e7213e ("max17042_battery: Support regmap to access device's registers") Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 14 Aug, 2021 2 commits
-
-
Linus Walleij authored
This extends the struct power_supply_battery_info with a "technology" field makes the core DT parser optionally obtain this from the device tree. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Linus Walleij authored
This adds a battery-chemistry property and bindings for the different "technologies" that are used in Linux. More types can be added. This is needed to convert the custom ST-Ericsson AB8500 battery properties over to the generic battery bindings. Cc: devicetree@vger.kernel.org Signed-off-by:
-
- 13 Aug, 2021 11 commits
-
-
Pawel Dembicki authored
This commit introduces support for NETGEAR ReadyNAS Duo v2. This device use bit 4 of LED[2:0] Polarity Control Register to indicate AC Power loss. For more details about AC loss detection in NETGEAR ReadyNAS Duo v2, please look at the file: RND_5.3.13_WW.src/u-boot/board/mv_feroceon/mv_hal/usibootup/usibootup.c from Netgear GPL sources. Signed-off-by:
Pawel Dembicki <paweldembicki@gmail.com> Signed-off-by:
-
Pawel Dembicki authored
This commit prepare driver for another device support. New power_off_cfg structure describes two most important things: name of mdio bus and pointer to register setting function. It allow to add new device with different mdio bus node and other phy register config. Signed-off-by:
-
Sebastian Reichel authored
Immutable branch between regulator and power-supply for for 5.15 This immutable branch introduces the MT6360 charger driver, which requires a new linear range helper. Signed-off-by:Sebastian Reichel <sre@kernel.org>
-
Bruno Meneguele authored
Rename ChargeOption macros to match the others for ChargeCurrent and ChargeVoltage and also separate the command & masks macros from the bits of interest macros for each command. This macro doesn't introduce any functional change, only code re-org. Signed-off-by:
Bruno Meneguele <bruno.meneguele@smartgreen.net> Signed-off-by:
-
Andreas Kemnade authored
Read voltage_now via IIO and provide the property. Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Reported-by: kernel test robot <lkp@intel.com> # missing depends on IIO Acked-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Andreas Kemnade authored
Add iio map to allow power driver to read out values as a consumer. This approach does not block later addition of devicetree support which would be helpful if there is an in-kernel consumer for AIN0/1. Signed-off-by:
-
Gene Chen authored
Add basic support for the battery charger for MT6360 PMIC Signed-off-by:
Gene Chen <gene_chen@richtek.com> Reviewed-by:
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by:
-
Gene Chen authored
Add bindings document for Charger support on MT6360 PMIC Signed-off-by:
-
Gene Chen authored
Add linear range get selector within for choose closest selector between minimum and maximum selector. Signed-off-by:
-
Colin Ian King authored
Clean up a handful of checkpatch warnings: - static const char * array should probably be static const char * const - function arguments should have identifier names - else should follow close brace '}' - suspect code indent for conditional statements - unnecessary parentheses in an if condition - avoid multiple line dereference - remove debug showing function execution, ftrace can trace these better - prefer 'long' over 'long int' as the int is unnecessary Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Tang Bin authored
Use the defined variable "dev" to make the code cleaner. Co-developed-by:
Zhang Shengju <zhangshengju@cmss.chinamobile.com> Signed-off-by:
Tang Bin <tangbin@cmss.chinamobile.com> Reviewed-by:
-
- 06 Aug, 2021 7 commits
-
-
Matthias Schiffer authored
As defined by the Smart Battery Data Specification. An _AVG suffix is added to the enum values REG_TIME_TO_EMPTY and REG_TIME_TO_FULL to make the distinction clear. Signed-off-by:
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by:
-
Matthias Schiffer authored
The Smart Battery Data Specification allows for values 0..65535 mV, there is no reason to limit the value to 20000. Signed-off-by:
-
Tang Bin authored
In the probe function, when get irq failed, the function platform_get_irq_byname() logs an error message, so remove redundant message here. Co-developed-by:
-
Maxime Ripard authored
The AXP209 compatible was used in Device Trees and the driver, but it was never documented. Cc: Chen-Yu Tsai <wens@csie.org> Cc: linux-pm@vger.kernel.org Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
-
Maxime Ripard authored
The AXP803 compatible was introduced recently with a fallback to the AXP813, but it was never documented. Cc: Chen-Yu Tsai <wens@csie.org> Cc: linux-pm@vger.kernel.org Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
Nikita Travkin authored
MAX77849 is a combined fuel-gauge, charger and MUIC IC. Notably, fuel-gauge has dedicated i2c lines and seems to be fully compatible with max17047. Add new compatible for it reusing max17047 code paths. Signed-off-by:
Nikita Travkin <nikita@trvn.ru> Signed-off-by:
-
Nikita Travkin authored
max77849 is a combined fuel-gauge, charger and MUIC device. Add it to the bindings documentation. Signed-off-by:
-
- 05 Aug, 2021 10 commits
-
-
Hans de Goede authored
The I2C-bus to the XPower AXP288 is shared between the Linux kernel and the SoCs P-Unit. The P-Unit has a semaphore which the kernel must "lock" before it may use the bus. If not explicitly taken by the I2C-driver, then this semaphore is automatically taken by the I2C-bus-driver for each I2C-transfer and this is a quite expensive operation. Explicitly take the semaphore in probe() around the register-accesses done during probe, so that this only needs to be done once, rather then once per register-access. Signed-off-by:
-
Hans de Goede authored
The I2C-bus to the XPower AXP288 is shared between the Linux kernel and the SoCs P-Unit. The P-Unit has a semaphore which the kernel must "lock" before it may use the bus. If not explicitly taken by the I2C-driver, then this semaphore is automatically taken by the I2C-bus-driver for each I2C-transfer. Move the AXP20X_CC_CTRL check done in probe() together with the other register-accesses done in probe, so that we can take the semaphore once for the entire set of register-accesses. Signed-off-by:
-
Andrejus Basovas authored
The I2C-bus to the XPower AXP288 is shared between the Linux kernel and the SoCs P-Unit. The P-Unit has a semaphore which the kernel must "lock" before it may use the bus and while the kernel holds the semaphore the CPU and GPU power-states must not be changed otherwise the system will freeze. This is a complex process, which is quite expensive. This is all done by iosf_mbi_block_punit_i2c_access(). To ensure that no unguarded I2C-bus accesses happen, iosf_mbi_block_punit_i2c_access() gets called by the I2C-bus-driver for every I2C transfer. Because this is so expensive it is allowed to call iosf_mbi_block_punit_i2c_access() in a nested fashion, so that higher-level code which does multiple I2C-transfers can call it once for a group of transfers, turning the calls done by the I2C-bus-driver into no-ops. Userspace power-supply API users typically will read all provided properties in one go, refreshing the last read values when power_supply_changed() is called by the driver and/or periodically (e.g. every 2 minutes). The reading of all properties in one go causes the P-Unit semaphore to quickly be taken and released multiple times in a row. Certain PMIC registers like AXP20X_FG_RES are even used in multiple properties so they get read multiple times, leading to a P-Unit take + release each time the register is read. As already mentioned the taking of the P-Unit semaphore is a quite expensive operation and it has also been reported that the "hammering" of the P-Unit semaphore done by the axp288_fuel_gauge driver can even cause stability issues with the system as a whole. Switch over to a scheme where the axp288_fuel_gauge driver keeps a local copy of all the registers which it uses for properties and make it only refresh its copy of the registers if the values are older then 1 minute; or when a fuel-gauge interrupt has triggered since the last read. This not only reduces the amount of reads, it also makes the code do all the reads in one go, rather then reading specific registers based on which property is being queried. This allows calling iosf_mbi_block_punit_i2c_access() once before doing all the reads, so that we now only take the P-Unit semaphore once per update. Tested-by:
Andrejus Basovas <cpp@gcc.lt> Signed-off-by:
-
Hans de Goede authored
Accessing registers on the AXP288 is quite expensive, so we should avoid doing unnecessary accesses. The FG_LOW_CAP_REG never changes underneath us, so we only need to read it once. Devices with an AXP288 do not have user-replace (let alone hot-swappable) batteries and the only bit we care about in the PWR_OP_MODE register is the CHRG_STAT_BAT_PRESENT bit, so we can get away with only reading the PWR_OP_MODE register once too. Note that the FG_LOW_CAP_REG is not marked volatile in the regmap, so we were effectively already reading it once. This change makes this explicit, this is done as preparation of a further patch which moves all remaining register accesses in fuel_gauge_get_property() out of that function. Signed-off-by:
-
Hans de Goede authored
Directly store the struct device pointer in axp288_fg_info, rather then storing a pointer to the struct platform_device there and then using "&info->pdev->dev" everywhere. Signed-off-by:
-
Hans de Goede authored
The I2C-bus to the XPower AXP288 is shared between the Linux kernel and the SoCs P-Unit. The P-Unit has a semaphore which the kernel must "lock" before it may use the bus. This semaphore is automatically taken by the I2C-bus-driver. The retry on -EBUSY logic in fuel_gauge_reg_readb() likely was added to deal with the I2C-bus-drive returning -EBUSY when it failed to take the semaphore, but this really should never happen. The semaphore code even has a WARN_ON(ret) to log a kernel backtrace if this does somehow happen, when this happens something is seriously wrong and the system typically freezes soon afterwards. TL;DR: the regmap_read() should never fail with -EBUSY so the retries are unnecessary. Signed-off-by:
-
Hans de Goede authored
When fuel_gauge_reg_readb()/_writeb() fails, report which register we were trying to read / write when the error happened. Also reword the message a bit: - Drop the axp288 prefix, dev_err() already prints this - Switch from telegram / abbreviated style to a normal sentence, aligning the message with those from fuel_gauge_read_*bit_word() Signed-off-by:
-
Hans de Goede authored
Drop the IRQ mapping messages, because they are really not interesting at all. Signed-off-by:
-
Hans de Goede authored
The debugfs code is simply just dumping a bunch of registers, the same information can also easily be gotten through the regmap debugfs interface or through the i2cdump utility. I've not used the debugfs interface once in all these years that I've been working on the axp288_fuel_gauge driver, so lets just remove it. Note this also removes the temperature-channels from the list of IIO ADC channels used by the driver, since these were only used in the debugfs interface. Signed-off-by:
-
Hans de Goede authored
The values of various defines used in the driver are not aligned properly when tabsize is set to 8 (I guess they were created with a different tabsize). Properly align the defines to make the code easier to read. Signed-off-by:
-
