- 03 Oct, 2020 9 commits
-
-
Krzysztof Kozlowski authored
Since ACPI_PTR() is used to NULLify the value when !CONFIG_ACPI, the struct acpi_device_id becomes unused: drivers/power/supply/bq24257_charger.c:1155:36: warning: 'bq24257_acpi_match' defined but not used [-Wunused-const-variable=] Signed-off-by:Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com>
-
Iskren Chernev authored
max17048 and max17049 support SOC alerts (interrupts when battery capacity changes by +/- 1%). At the moment the driver polls for changes every second. Using the alerts removes the need for polling. Signed-off-by:
Iskren Chernev <iskren.chernev@gmail.com> Tested-by:
Jonathan Bakker <xc-racer2@live.ca> Signed-off-by:
-
Iskren Chernev authored
The Maxim ModelGauge family supports fine-tuning by setting a compensation value (named rcomp in the docs). The value is affected by battery chemistry and ambient temperature. Add support for reading maxim,rcomp from DT and configuring the device with the supplied value. Temperature adjustment is not implemented at the moment, because there is no provision for receiving the ambient temperature at the moment. Signed-off-by:
-
Iskren Chernev authored
To compensate for the battery chemistry and operating conditions the chips support a compensation value. Specify one or two byte compensation via the maxim,rcomp byte array. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Iskren Chernev authored
The max17040 fuel gauge is part of a family of 8 chips that have very similar mode of operations and registers. This change adds: - compatible strings for all supported devices and handling for the minor differences between them; - handling for devices reporting double capacity via maxim,double-soc; The datasheets of the supported devices are linked [0] [1] [2] [3]. [0] https://datasheets.maximintegrated.com/en/ds/MAX17040-MAX17041.pdf [1] https://datasheets.maximintegrated.com/en/ds/MAX17043-MAX17044.pdf [2] https://datasheets.maximintegrated.com/en/ds/MAX17048-MAX17049.pdf [3] https://datasheets.maximintegrated.com/en/ds/MAX17058-MAX17059.pdfSigned-off-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Iskren Chernev authored
Maxim max17040 is a fuel gauge from a larger family utilising the Model Gauge technology. Document all different compatible strings that the max17040 driver recognizes. Some devices in the wild report double the capacity. The maxim,double-soc (from State-Of-Charge) property fixes that. Examples: https://lore.kernel.org/patchwork/patch/1263411/#1468420Signed-off-by:
-
Iskren Chernev authored
Rewrite i2c operations from i2c client read/write to regmap i2c. As a result, most private functions now accept the private driver data instead of an i2c client pointer. Signed-off-by:
-
Iskren Chernev authored
Two actions were performed during remove - power supply dereg and delayed work cleanup. Power supply dereg can be handled by using the devm_ version of the registration function. Work cleanup can be added as a devm_action. If probe fails after psy registration it will now be cleaned up properly. Signed-off-by:
-
Sebastian Reichel authored
Currently the sign for CURRENT_NOW and CURRENT_AVG is a bit of a mess. There are basically 3 different ways battery fuel gauges report the current: 1. uses negative values for discharging and positive values for charging 2. uses positive values for discharging and negative values for discharging (opposit of 1) 3. only uses positive values As a result userspace currently cannot use the sign at all in a generic way. Let's solve the issue by documenting a canonical way for reporting the data and ensure new drivers follow this way. Then existing drivers can be fixed on a case-by-case basis. The 'negative value = battery discharging' has been choosen, since there are only very few drivers doing it the other way around. Signed-off-by:
-
- 01 Oct, 2020 6 commits
-
-
Krzysztof Kozlowski authored
Add support for new device: the TI bq34z100-G1, a Wide Range Fuel Gauge for Li-Ion, PbA, NiMH, and NiCd batteries. The device shares a lot with other models, although it has its own differences requiring new quirks. This patch was tested on a system equipped with NiMH batteries. Signed-off-by:
-
Krzysztof Kozlowski authored
bq27000, bq27010 and upcoming bq34z100 have a Capacity Inaccurate flag. However except this similarity, bq34z100 is quite different than bq27000/bq27010, so flag BQ27XXX_O_ZERO cannot be reused here. Add a new bit flag describing this capability. No functional change for bq27000 and bq27010. Signed-off-by:
-
Krzysztof Kozlowski authored
bq27000, bq27010 and upcoming bq34z100 have a single byte SoC register. However except this similarity, bq34z100 is quite different than bq27000/bq27010, so flag BQ27XXX_O_ZERO cannot be reused here. Add a new bit flag describing that SoC is a single byte register. No functional change for bq27000 and bq27010. Signed-off-by:
-
Krzysztof Kozlowski authored
BIT() is a preferred way to toggle bit-like flags: no problems with 32/64 bit systems, less chances for mistakes. Remove also unneeded whitespace. Signed-off-by:
-
Krzysztof Kozlowski authored
Commit 6f24ff97 ("power: supply: bq27xxx_battery: Add the BQ27Z561 Battery monitor") and commit d74534c2 ("power: bq27xxx_battery: Add support for additional bq27xxx family devices") added support for new device types by copying most of the code and adding necessary quirks. However they did not copy the code in bq27xxx_battery_status() responsible for returning POWER_SUPPLY_STATUS_NOT_CHARGING. Unify the bq27xxx_battery_status() so for all types when charger is supplied, it will return "not charging" status. Signed-off-by:
-
Krzysztof Kozlowski authored
Add compatible for bq34z100 charger. Signed-off-by:
-
- 30 Sep, 2020 1 commit
-
-
Lucas Stach authored
Some fault events like the over-current condition will get resolved by the hardware, by e.g. disabling the port. As the status in the interrupt status register is cleared on read when the fault is resolved, the sysfs health property will only contain the correct health status for the first time it is read after such an event, even if the actual fault condition (like a VBUS short) still persists. To reflect this properly in the property we cache the last health status and only update the cache when a actual change happens, i.e. the ERR bit in the status register flips, as this one properly reflects a continued fault condition. The ALERT pin however, is not driven by the ERR status, but by the actual fault status, so the pin will change back to it's default state when the hardware has automatically resolved the fault by cutting the power. Thus we never get an IRQ when the actual fault condition has been resolved and the ERR status bit has been cleared in auto-recovery mode. To get this information we need to poll the interrupt status register after some time to see if the fault is gone and update our cache in that case. To avoid any additional locking, we handle both paths (IRQ firing and delayed polling) through the same single-threaded delayed work. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
- 29 Sep, 2020 7 commits
-
-
Dan Murphy authored
Andrews TI email is no longer valid and he indicated that it is OK to remove him from the MAINTAINERS file for the DMA HEAPS FRAMEWORK. For the BQ27xxx list I replaced Andrews email with mine. Signed-off-by:
Dan Murphy <dmurphy@ti.com> Acked-by:
-
Wang Qing authored
Modify the comment typo: "compliment" -> "complement". Signed-off-by:
Wang Qing <wangqing@vivo.com> Signed-off-by:
-
Michał Mirosław authored
Document new properties for IBAT compensation feature. Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Reviewed-by:
-
Michał Mirosław authored
Add configuration for compensation of IBAT measuring resistor in series with the battery. Signed-off-by:
-
Wang Qing authored
Modify the comment typo: "compliment" -> "complement". Signed-off-by:
-
Artur Rojek authored
This binding can support Ingenic JZ4725B and JZ4770 SoCs, as they are compatible with Ingenic JZ4740 battery. Introduce the following compatible property combinations: compatible = "ingenic,jz4725b-battery", "ingenic,jz4740-battery", compatible = "ingenic,jz4770-battery", "ingenic,jz4740-battery" Signed-off-by:
Artur Rojek <contact@artur-rojek.eu> Reviewed-by:
-
Artur Rojek authored
Convert the textual documentation of Device Tree bindings for the Ingenic JZ47xx SoCs battery to YAML. Signed-off-by:
-
- 28 Aug, 2020 14 commits
-
-
Jonathan Bakker authored
The bindings for charger-manager were very unclear and didn't specify allowable values in many cases. Clean these up to show what each value does and make sure all properties are documented here rather than using wildcards. Signed-off-by:
-
Jonathan Bakker authored
Rather than having a cm-chargers and a separate cm-num-chargers property, simply count the entries in cm-chargers. Signed-off-by:
-
Jonathan Bakker authored
In commit 830ae442 ("extcon: Remove the deprecated extcon functions") the function extcon_register_interest became a no-op returning an error, leading to non-functional behaviour in charger-manager. Additionally, a translation table is needed between the text representation of the extcon cable names and their IDs is needed. In order to retain DT compatibility, TA and CHARGE-DOWNSTREAM are added as they were present up until commit 11eecf91 ("extcon: Modify the id and name of external connector") Signed-off-by:
-
Jonghwa Lee authored
Prevents direct charging control in cable notification and only set the input current limit according to cable type. Leave the enabling of charing to cm_monitor() where charging management proceeds. We may lose a few ms to enable charging compared to before, but it's more important that charging is enabled always in safe context. Signed-off-by:
Jonghwa Lee <jonghwa3.lee@samsung.com> Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
-
Jonghwa Lee authored
cm_monitor(), where charging management starts, checks various charging condition sequentially to decide next charging operation. However, as it follows sequential process, cascaded if statements, it does some jobs which have already done in the previous stage. This results in a delay in decision making. Moreover, starting point of charging is spread all around which makes maintain code and debugging difficult. Both of the problems mentioned above become clean if it manages battery charging focusing on battery status not following sequential condition checking. Now, cm_monitor() moves battery state diagram and does the optimal operation for current state. As a result, it reduces whole monitoring time almost in half. Signed-off-by:
-
Jonghwa Lee authored
Current charger-manager calls power_supply_changed() whenever charging status is changed. Remove the separated power_supply_changed() calls and let it be called at end of try_charger_enable() function which is called to set charging/discharging. Signed-off-by:
-
Jonghwa Lee authored
The POWER_SUPPLY_CHARGE_NOW/FULL property reflects battery's charges in uAh unit, but charger-manager has been used it wrongly as a status field. Signed-off-by:
-
Jonathan Bakker authored
We were using POWER_SUPPLY_PROP_TEMP if the temperature was coming via the fuel gauge and POWER_SUPPLY_PROP_TEMP_AMBIENT if it was coming via the thermal framework. Since they're mutually exclusive in the driver and we don't know if the thermal framework is ambient or not, unify them both to use POWER_SUPPLY_PROP_TEMP. Signed-off-by:
-
Jonghwa Lee authored
cm_notify_event() was introduced to get an event associated with the battery status externally (ie in board files), but no one ever used it. Moreover it makes charger manager driver more complicated. Drop the function and all data related to it to simplify the driver. Signed-off-by:
-
Jonghwa Lee authored
Whenever the battery status is changed, charger manager triggers a uevent through a private interface. Modify it to use power_supply_changed() since it belongs to the power supply subsystem. Signed-off-by:
-
Andreas Kemnade authored
Both chips have charger and a fuel gauge. This adds basic support for displaying the state of the battery and the input power, settings are not modified. There are some defaults set via OTP. Charging also starts after plugging USB. Known issues of the fuel gauge: There are drivers in the wild which disable the fuel gauge at shutdown. If a kernel is booted without fuel gauge support, after such a driver has been used, the fuel gauge will stay off and decalibrate. If this driver is used after that, it might display wrong values for charge level. Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Signed-off-by:
-
Ikjoon Jang authored
Current sbs-battery considers all smbus errors as disconnection events when battery-detect pin isn't supplied, and restored to present state back when any successful transaction is made. This can lead to unwanted state changes between present and !present when there's one i2c error and other following commands were successful. This patch provides a unified way of checking presence by calling sbs_get_battery_presence_and_health() when detect pin is not used. Signed-off-by:
Ikjoon Jang <ikjn@chromium.org> Signed-off-by:
-
Sebastian Reichel authored
Simplify the driver and remove the DT specific code by using the generic device property framework. Reviewed-by:
Dmitry Osipenko <digetx@gmail.com> Tested-by:
-
Sebastian Reichel authored
There are no platforms using the pdata support, so let's drop it to simplify the driver. Reviewed-by:
-
- 27 Aug, 2020 3 commits
-
-
Dan Murphy authored
Update the license to the SPDX licensing format. Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a dev_dbg message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Ikjoon Jang authored
This patch enables calling sbs_get_battery_presence_and_health() without checking its chip type. No functional changes. Signed-off-by:
-
