summaryrefslogtreecommitdiff
path: root/drivers/power/supply/axp288_charger.c
AgeCommit message (Collapse)Author
2020-04-29power: supply: axp288_charger: Omit superfluous error messageTang Bin
In the axp288_charger_probe(), when get irq failed, the function platform_get_irq() logs an error message, so remove redundant message here. Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com> Signed-off-by: Shengju Zhang <zhangshengju@cmss.chinamobile.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2020-03-08power: supply: axp288_charger: Add special handling for HP Pavilion x2 10Hans de Goede
Some HP Pavilion x2 10 models use an AXP288 for charging and fuel-gauge. We use a native power_supply / PMIC driver in this case, because on most models with an AXP288 the ACPI AC / Battery code is either completely missing or relies on custom / proprietary ACPI OpRegions which Linux does not implement. The native drivers mostly work fine, but there are 2 problems: 1. These model uses a Type-C connector for charging which the AXP288 does not support. As long as a Type-A charger (which uses the USB data pins for charger type detection) is used everything is fine. But if a Type-C charger is used (such as the charger shipped with the device) then the charger is not recognized. So we end up slowly discharging the device even though a charger is connected, because we are limiting the current from the charger to 500mA. To make things worse this happens with the device's official charger. Looking at the ACPI tables HP has "solved" the problem of the AXP288 not being able to recognize Type-C chargers by simply always programming the input-current-limit at 3000mA and relying on a Vhold setting of 4.7V (normally 4.4V) to limit the current intake if the charger cannot handle this. 2. If no charger is connected when the machine boots then it boots with the vbus-path disabled. On other devices this is done when a 5V boost converter is active to avoid the PMIC trying to charge from the 5V boost output. This is done when an OTG host cable is inserted and the ID pin on the micro-B receptacle is pulled low, the ID pin has an ACPI event handler associated with it which re-enables the vbus-path when the ID pin is pulled high when the OTG cable is removed. The Type-C connector has no ID pin, there is no ID pin handler and there appears to be no 5V boost converter, so we end up not charging because the vbus-path is disabled, until we unplug the charger which automatically clears the vbus-path disable bit and then on the second plug-in of the adapter we start charging. The HP Pavilion x2 10 models with an AXP288 do have mostly working ACPI AC / Battery code which does not rely on custom / proprietary ACPI OpRegions. So one possible solution would be to blacklist the AXP288 native power_supply drivers and add the HP Pavilion x2 10 with AXP288 DMI ids to the list of devices which should use the ACPI AC / Battery code even though they have an AXP288 PMIC. This would require changes to 4 files: drivers/acpi/ac.c, drivers/power/supply/axp288_charger.c, drivers/acpi/battery.c and drivers/power/supply/axp288_fuel_gauge.c. Beside needing adding the same DMI matches to 4 different files, this approach also triggers problem 2. from above, but then when suspended, during suspend the machine will not wakeup because the vbus path is disabled by the AML code when not charging, so the Vbus low-to-high IRQ is not triggered, the CPU never wakes up and the device does not charge even though the user likely things it is charging, esp. since the charge status LED is directly coupled to an adapter being plugged in and does not reflect actual charging. This could be worked by enabling vbus-path explicitly from say the axp288_charger driver's suspend handler. So neither situation is ideal, in both cased we need to explicitly enable the vbus-path to work around different variants of problem 2 above, this requires a quirk in the axp288_charger code. If we go the route of using the ACPI AC / Battery drivers then we need modifications to 3 other drivers; and we need to partially disable the axp288_charger code, while at the same time keeping it around to enable vbus-path on suspend. OTOH we can copy the hardcoding of 3A input-current-limit (we never touch Vhold, so that would stay at 4.7V) to the axp288_charger code, which needs changes regardless, then we concentrate all special handling of this interesting device model in the axp288_charger code. That is what this commit does. Cc: stable@vger.kernel.org BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1791098 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174Thomas Gleixner
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 655 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-05power: supply: axp288_charger: Fix unchecked return valueGustavo A. R. Silva
Currently there is no check on platform_get_irq() return value in case it fails, hence never actually reporting any errors and causing unexpected behavior when using such value as argument for function regmap_irq_get_virq(). Fix this by adding a proper check, a message reporting any errors and returning *pirq* Addresses-Coverity-ID: 1443940 ("Improper use of negative value") Fixes: 843735b788a4 ("power: axp288_charger: axp288 charger driver") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2018-12-05power: supply: axp288: use the BIT() macroOlliver Schinagl
Make use of the recommended BIT() macro for bit defines. Signed-off-by: Olliver Schinagl <oliver@schinagl.nl> Signed-off-by: Priit Laes <plaes@plaes.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2018-07-06power: supply: axp288_charger: Fix initial constant_charge_current valueHans de Goede
We should look at val which contains the value read from the register, not ret which is always 0 on a successful read. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Fixes: eac53b3664f59 ("power: supply: axp288_charger: Drop platform_data dependency") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-04-26power: supply: axp288_charger: Do not bind when the charge function is not usedHans de Goede
Some devices with an AXP288 PMIC do not have a battery at all, or use external charger and fuelgauge ICs instead of the AXP288 builtin functionality. On such devices we should not bind to the charge function to avoid exporting a non working power_supply class device. Cc: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-04-26power: supply: axp288_charger: Support 3500 and 4000 mA input current limitHans de Goede
The AXP288 supports an input-current-limit of up to 4000 mA, this commit adds support for the 3500 and 4000 mA settings which were missing until now. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-01-08power: supply: axp288_charger: Properly stop work on probe-error / removeHans de Goede
Properly stop any work we may have queued on probe-errors / remove. Rather then adding a remove driver callback for this, and goto style error handling to probe, use a devm_action for this. The devm_action gets registered before we register any of the extcon notifiers which may queue the work, devm does cleanup in reverse order, so this ensures that the notifiers are removed before we cancel the work. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-01-08power: supply: axp288_charger: Simplify extcon cable handlingHans de Goede
Simplify extcon cable handling using the new devm_extcon_register_notifier_all function to listen to all cables in one go. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-01-08power: supply: axp288_charger: Use the right property for the input current ↵Hans de Goede
limit Use the right property for the input current limit and make it writable. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-01-08power: supply: axp288_charger: Pick lower input current limit not higherHans de Goede
The code before this commit would pick 900 mA when asking for an input current limit of 600mA, rather then 500 mA, not good. While touching almost all code using the silly xxxMA defines anyways, also get rid of these simply typing out the numbers and switch the unit to uA as that is the psy class standard unit for currents. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-01-08power: supply: axp288_charger: Do not cache input current limit valueHans de Goede
The hardware may change this underneath us. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-01-08power: supply: axp288_charger: Remove no longer needed lockingHans de Goede
Now that we use regmap to do read-modify-write ops everywhere, we can rely on the regmap lock and no longer need our own lock. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-01-08power: supply: axp288_charger: Use regmap_update_bits to set the input limitsHans de Goede
Use regmap_update_bits in axp288_charger_set_vbus_inlmt, instead of DIY code. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-01-08power: supply: axp288_charger: Cleanup some double empty linesHans de Goede
While we are doing cleanups, also remove some double blank lines. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-01-08power: supply: axp288_charger: Remove charger-enabled state trackingHans de Goede
The extcon code is the only one to trigger our worker (outside of the initial run) and we can rely on it to only call us if things have changed, so there is no need to track the charger-enabled state. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-01-08power: supply: axp288_charger: Add missing newlines to some messagesHans de Goede
Add missing (terminating) "\n"-s to some dev_dbg messages. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2018-01-08power: supply: axp288_charger: Do not stop + restart charging at bootHans de Goede
Before this commit we were relying solely on the extcon interface for cable detection, including to determine if a cable providing vbus is connected at all. This caused us to turn off charging at boot, because when we run the initial state processing the axp288-extcon driver is still running charger-type detection most of the time, so all charger cable types read as disconnected when we run the initial state processing. This commit reworks the axp288_charger_extcon_evt_worker flow to use the VBUS_VALID bit from the PWR_INPUT_STATUS register to determine if we should turn charging on/off. Note this is the same bit as we use for the online property. If VBUS_VALID is set, but the extcon code has not completed the charger type detection yet, we now simply bail leaving things as configured by the BIOS (we will get a notifier call when the extcon code is done and reschedule the axp288_charger_extcon_evt_worker). The extcon code is the only one to trigger the worker (outside of the initial run) and we can rely on it to only call us if things have changed, so while we are completely refactoring axp288_charger_extcon_evt_worker, also remove the code to check if the state has changed. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2017-04-19power: supply: axp288_charger: Only wait for INT3496 device if presentHans de Goede
On some devices with an axp288 pmic setting vbus path based on the id-pin is handled by an ACPI _AIE interrupt on the gpio and the INT3496 device is disabled. Instead of returning -EPROBE_DEFER on these devices waiting for the never to show up INT3496 device, check for its presence and only request and monitor the matching extcon if the device is there, otherwise let the firmware handle the vbus path control. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-01-04power: supply: axp288_charger: Use one notifier_block per extcon cableHans de Goede
Prior to this commit the code was using 1 notifier_block for all types of charger cable, this is incorrect as the notifier_block becomes part of a linked-list and now the same notifier_block is part of 3 linked lists. This commit fixes this by using a separate nb per extcon cable. Note this happened to work fine sofar because axp288_charger was the only listener, so when added to each of the 3 notifier chains, the next pointer in the nb would be set to 0, so we've 3 heads pointing to the same nb, with its next pointing to NULL. But as soon as we mix in a second extcon consumer things will go boom. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-01-04power: supply: axp288_charger: Fix the module not auto-loadingHans de Goede
Add a MODULE_DEVICE_TABLE to fix the module not auto-loading. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-01-04power: supply: axp288_charger: Remove unnecessary irq?_en register writesHans de Goede
Setting the irq_enable bits is taken care of by the irq chip when we request the irqs and the driver should not be meddling with the irq?_en registers itself. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-01-04power: supply: axp288_charger: Fix wrong regmap_update_bitsHans de Goede
To set a bit to 1 one needs to pass the mask for the bit to set as second argument into regmap_update_bits, not "1". Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-01-04power: supply: axp288_charger: Get and process initial hardware-stateHans de Goede
Do not wait for an extcon notification before processing the cable states, instead queue the otg / cable work on probe to make sure we immediately process the initial hardware state. Note this also requiree moving the getting of the USB_HOST cable state from the extcon notifier to the workqueue function. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-01-04power: supply: axp288_charger: Some minor cleanupsHans de Goede
Remove info->health, info->present and info->online caching, as no code is reading the cached values. Remove if (changed) check before calling power_supply_changed(), we return early from axp288_charger_extcon_evt_worker if nothing has changed, so the check is not needed. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-01-04power: supply: axp288_charger: Handle charger type changing without disconnectHans de Goede
Deal with the charger type changing without a vbus-disconnect being reported in between the 2 charger type states: -Do not return from axp288_charger_extcon_evt_worker early in this case (track old_chg_type) -Make calling axp288_charger_enable_charger with the same value as before a nop, to avoid the need for the caller to check this -Do no do a dev_err when axp288_charger_enable_charger returns an error, axp288_charger_enable_charger already returns an error itself -Disable the charger before changing the charge-current setting (nop if vbus was seen as disconnected before the change) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-01-04power: supply: axp288_charger: Actually get and use the USB_HOST extcon deviceHans de Goede
Nothing was setting info->otg.cable, so the extcon_get_cable_state_ calls on it would always return -EINVAL. This commit fixes this by actually setting info->otg.cable using the new extcon_get_extcon_dev_by_cable_id function. This commit also makes failing to register the extcon notifier for the USB_HOST cable an error rather then a warning, because we MUST have this notfier to properly disable the VBUS path when in host mode so that we're not drawing current from the 5V boost converter which is supplying power to the otg port when in host mode. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-01-04power: supply: axp288_charger: Move init_hw_regs call before supply registrationHans de Goede
Move the charger_init_hw_regs() above the power_supply_register call, the axp288_charger_usb_set_property() uses axp288_chrg_info.max_cv and .max_cc which get set by charger_init_hw_regs(). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-01-04power: supply: axp288_charger: Register extcon notifers after power_supplyHans de Goede
The extcon notifier work calls power_supply_changed on the power_supply we register, so the extcon notifiers should be registered after we register the power_supply. While touching this code anyways, refactor the code for the 3 cable types into a loop to avoid code repetition. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-01-04power: supply: axp288_charger: Use devm_power_supply_registerHans de Goede
Use devm_power_supply_register instead of power_supply_register, this avoids the need to do manual cleanup and results in quite a nice code cleanup. Note it may seem excessive to add a "struct device *dev" helper local variable for the 1 time it is used in this patch, but future patches in this series also use it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-01-04Merge branch 'psy-mfd-axp288-immutable' into psy-nextSebastian Reichel
2017-01-04power: supply: axp288_charger: Replace the extcon APIChanwoo Choi
This patch uses the resource-managed extcon API for extcon_register_notifier() and replaces the deprecated extcon API as following: - extcon_get_cable_state_() -> extcon_get_state() Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-01-04power: supply: axp288_charger: Drop platform_data dependencyHans de Goede
When the axp288_charger driver was originally merged, it was merged with a dependency on some other driver providing platform data for it. However the battery-data-framework which should provide that data never got merged, so the axp288_charger as merged upstream has never worked, its probe method simply always returns -ENODEV. This commit removes the dependency on the platform_data instead reading back the charging current and charging voltage that the firmware has set and using those values as the maximum values the user may set. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2017-01-04power: supply: axp288_charger: Make charger_init_hw_regs propagate i2c errorsHans de Goede
Make charger_init_hw_regs propagate i2c errors, instead of only warning about them and then ignoring them. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2016-08-16power: axp288_charger: remove duplicated include from axp288_charger.cWei Yongjun
Remove duplicated include. Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2016-08-11power: move power supply drivers to power/supplySebastian Reichel
This moves all power supply drivers from drivers/power/ to drivers/power/supply/. The intention is a cleaner source tree, since drivers/power/ also contains frameworks unrelated to power supply, like adaptive voltage scaling. Signed-off-by: Sebastian Reichel <sre@kernel.org>