* New battery driver for AXP20X and AXP22X PMICs
* Improve max17042_battery for usage on x86
* Misc small cleanups & fixes
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE72YNB0Y/i3JqeVQT2O7X88g7+poFAlkU2QYACgkQ2O7X88g7
+poudxAAjAzrD6WGMtH+++53j8sKTel1eyuKImsv/4TgkWjyBeXzeeEtHX4T8qCJ
HtfGf/JB7sYCWdSFXCxYmOy051r6InGd3VxC2mMvkuz6p8ya1YAR41oHwXEBdsa5
TcYhIe9GNHEhdENTLsKywXOA3gh1REjU9ljCUJJwAxUpqDfU6pRSoFqwB0SAu6zC
/FjGAcooyOyKT9tsZuJ68Xw01thtsowMLNKD6gkXSiMfH2wVhlEijoQ3OwJzW423
mvxukptrDaMiXWjjwY46/ExfEmoEmDo8le5vnB6m3OUOkTmsj2A7RI0GwYPjUM6S
ZCrGn4yNeq3c277rAixY8twhS9zLVM3vuFWOKeT9zSIleJ7eFu9er6U2jJZvA17C
BDoZg4RWFQrYv6YcMsADS8Wk4jYwhahdApNbG2RcUrC3qH+QTqGw6/7LCJ9X3dXs
tSWszwSw9pGIPNnzzhwI7nNREFTfy8W+0qRRyUw2LWEVTJBxzUYmF8L3hFnhr/94
JqFdDWqSCEZpi0sgjp3IxDAlZJ9p/lTFN7iA8UdK912kBA+1Mo4JQqd6piXxYvJM
yCjv4zDclpDa7QbV286y/FOLy/qnUrQ+8qIGvSgAJh5v32mJc8uJqP+4g8401D5T
6YfzboSUQ1s4hofFh1wIO+swq5iTcLJrhZyaCWC9qgKQVWx8tSw=
=lF9I
-----END PGP SIGNATURE-----
Merge tag 'for-v4.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply
Pull more power-supply updates from Sebastian Reichel:
"The power-supply subsystem has a few more changes for the v4.12 merge
window:
- New battery driver for AXP20X and AXP22X PMICs
- Improve max17042_battery for usage on x86
- Misc small cleanups & fixes"
* tag 'for-v4.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: (34 commits)
power: supply: cpcap-charger: Keep trickle charger bits disabled
power: supply: cpcap-charger: Fix enable for 3.8V charge setting
power: supply: cpcap-charger: Fix charge voltage configuration
power: supply: cpcap-charger: Fix charger name
power: supply: twl4030-charger: make twl4030_bci_property_is_writeable static
power: supply: sbs-battery: Add alert callback
mailmap: add Sebastian Reichel
power: supply: avoid unused twl4030-madc.h
power: supply: sbs-battery: Correct supply status with current draw
power: supply: sbs-battery: Don't ignore the first external power change
power: supply: pda_power: move from timer to delayed_work
power: supply: max17042_battery: Add support for the SCOPE property
power: supply: max17042_battery: Add support for the CHARGE_NOW property
power: supply: max17042_battery: Add support for the CHARGE_FULL_DESIGN property
power: supply: max17042_battery: mAh readings depend on r_sns value
power: supply: max17042_battery: Add support for the VOLT_MIN property
power: supply: max17042_battery: Add support for the TECHNOLOGY attribute
power: supply: max17042_battery: Add external_power_changed callback
power: supply: max17042_battery: Add support for the STATUS property
power: supply: max17042_battery: Add default platform_data fallback data
...
Android does not seem to set the trickle charger bits, and these
seem to be only used by the bootloader when bringing up a
completely discharged battery. So let's keep the trickle charging
bits disabled and avoid misconfiguring the hardware.
Fixes: 0c9888e3c1 ("power: supply: cpcap-charger: Add minimal
CPCAP PMIC battery charger")
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Zero is a valid register value for for 3.8V charging.
Fixes: 0c9888e3c1 ("power: supply: cpcap-charger: Add minimal
CPCAP PMIC battery charger")
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
We have the charge voltage wrong, it should be 4.35V instead of 4.2V.
This will cause the battery to never get fully charged.
I noticed this when looking at the Andoid kernel battery and charger
status for a fully charged battery:
POWER_SUPPLY_VOLTAGE_NOW=4351000
Also the battery on droid 4 says "4.35, 1735/1785mAh (min/typ),
6.6/6.8 Wh (min/typ)". Presumably the 4.35 on the battery is the
charge voltage.
And finally, on Android the CPCAP CRM register is set to 0x03b5 where
the b is the charge voltage.
Let's fix the charge voltage define and update the charge configuration
to use the 4.35V setting.
Fixes: 0c9888e3c1 ("power: supply: cpcap-charger: Add minimal
CPCAP PMIC battery charger")
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
I noticed we have a different name from what Android is using.
Let's not break the /sys/class/power user space interface here
and use the same naming as Android has.
On Android we have the following for droid 4:
$ ls /sys/class/power_supply/
ac battery usb
So let's use the usb naming here for charger too.
Fixes: 0c9888e3c1 ("power: supply: cpcap-charger: Add minimal
CPCAP PMIC battery charger")
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The function twl4030_bci_property_is_writeable can be made static
as it does not need to be in global scope.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Tested-by: "H. Nikolaus Schaller" <hns@goldelico.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
- Update the core device enumeration code to make it more internally
consistent and robust and drop the force_remove sysfs attribute
that could be used to tell it to ignore errors on device
hot-removal which was dangerous in general and no real and
still relevant use cases for it could be found (Rafael Wysocki,
Michal Hocko).
- Make the core device enumeration code use _PXM to associate
platform devices created by it with specific NUMA nodes (Shanker
Donthineni).
- Extend the CPPC library by adding more sysfs entries for
performance capabilities to it and making it use the lowest
nonlinear performance parameter (Prashanth Prakash).
- Make the CPU online more consistent with CPU initialization in
the ACPI processor driver (Prashanth Prakash).
- Update the AC and battery drivers to help them avoid attaching to
devices that cannot be handled by them and update the axp288_charger
power supply driver to work correctly on ACPI systems without the
INT3496 device (Hans de Goede).
- Add an ACPI operation region driver for the Intel CHT Whiskey Cove
PMIC and update the xpower operation region driver to work without
IIO which isn't really necessary for it to work (Hans de Goede).
- Add a new entry for Dell Inspiron 7537 to the _REV quirk blacklist
(Kai Heng Feng).
- Make the code in the ACPI video driver easier to follow by adding
symbols and comments to it (Dmitry Frank).
- Update ACPI documentation and drop a function that has no users
from the tables-handling code (Cao jin, Baoquan He).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJZB5h0AAoJEILEb/54YlRx8+EP/j468sN7PEBDXZLF1jsIJK6g
IozbOMAAVXBwDrfTOLYSVe3KOUJH0tVdax768tv6Gu94jbUT+nPeSNNDTaWbOpli
fi/f6ljSupWzh/TLjIBVAbNuEULcxB6AcMg0fxMRutIQUbr7ie6ioJ1R4UoMRrV8
HFdlsHiHa9uUMSDuwByzjzQX+TRAvseyBvkLxUlMMwJQ3+/+yH2FoGRmjzS0ZLAC
lTyzcAasznrGsqlDoFunNegoBFkgnJv5vJ7fVfujQb5irpX51iog6aNehLRt3GwX
opRlNjFIYk3XTSTR2QvV/utUrWuPYKJwkCulnlyACoWCmsYGbt115iEWY0YNVV71
tmHRK/TkbYHSg4H/Tgc4i1bMvWM4GOULq3NaltxfQA31O8s++02zL7HxblA763AP
4TmofNDTW3pF7GZ5DxtysXCCURdShj7y8ta4K+A0l4g6iCaTHLzFNlEJp2WSL6xo
LFg/VvAHFnF34OlDobKlm8hB53thHGd0UD0dnY4hwiwpsTwlc/e5pxgIpKEkw1/L
aO3VxIMtzVG93cno7JM7/6kWy2Qcnk2VqoPFiQPaB60QKfyKjBKCRYVeUVesrHrE
443MoJS3KmsenPSD7ACpW6yKmGP3p+3CKakdvE3C09XNToq98+3W0lsU5NP9ys94
m75frKXPSt9EAUqjsJ0Z
=IwcL
-----END PGP SIGNATURE-----
Merge tag 'acpi-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI updates from Rafael Wysocki:
"These are some device enumeration code changes, updates of the AC and
battery drivers to help them avoid attaching to devices that cannot be
handled by them, new operation region driver for the Intel CHT Whiskey
Cove PMIC, new sysfs entries for CPPC performance capabilities, a new
_REV quirk blacklist entry and a couple of assorted minor fixes and
cleanups.
Specifics:
- Update the core device enumeration code to make it more internally
consistent and robust and drop the force_remove sysfs attribute
that could be used to tell it to ignore errors on device
hot-removal which was dangerous in general and no real and still
relevant use cases for it could be found (Rafael Wysocki, Michal
Hocko).
- Make the core device enumeration code use _PXM to associate
platform devices created by it with specific NUMA nodes (Shanker
Donthineni).
- Extend the CPPC library by adding more sysfs entries for
performance capabilities to it and making it use the lowest
nonlinear performance parameter (Prashanth Prakash).
- Make the CPU online more consistent with CPU initialization in the
ACPI processor driver (Prashanth Prakash).
- Update the AC and battery drivers to help them avoid attaching to
devices that cannot be handled by them and update the
axp288_charger power supply driver to work correctly on ACPI
systems without the INT3496 device (Hans de Goede).
- Add an ACPI operation region driver for the Intel CHT Whiskey Cove
PMIC and update the xpower operation region driver to work without
IIO which isn't really necessary for it to work (Hans de Goede).
- Add a new entry for Dell Inspiron 7537 to the _REV quirk blacklist
(Kai Heng Feng).
- Make the code in the ACPI video driver easier to follow by adding
symbols and comments to it (Dmitry Frank).
- Update ACPI documentation and drop a function that has no users
from the tables-handling code (Cao jin, Baoquan He)"
* tag 'acpi-4.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / PMIC: Stop xpower OPRegion handler relying on IIO
ACPI / PMIC: Add opregion driver for Intel CHT Whiskey Cove PMIC
ACPI / scan: Avoid enumerating devices more than once
ACPI / scan: Apply default enumeration to devices with ACPI drivers
power: supply: axp288_charger: Only wait for INT3496 device if present
ACPI / AC: Add a blacklist with PMIC ACPI HIDs with a native charger driver
ACPI / battery: Add a blacklist with PMIC ACPI HIDs with a native battery driver
ACPI / battery: Fix acpi_battery_exit on acpi_battery_init_async errors
ACPI / utils: Add new acpi_dev_present helper
ACPI / video: add comments about subtle cases
ACPI / video: get rid of magic numbers and use enum instead
ACPI / doc: linuxized-acpica.txt: fix typos
ACPI / blacklist: add _REV quirk for Dell Inspiron 7537
ACPI / tables: Drop acpi_parse_entries() which is not used
ACPI / CPPC: add sysfs entries for CPPC perf capabilities
ACPI / CPPC: Read lowest nonlinear perf in cppc_get_perf_caps()
ACPI / platform: Update platform device NUMA node based on _PXM method
ACPI / Processor: Drop setup_max_cpus check from acpi_processor_add()
ACPI / scan: Drop support for force_remove
To simplify the sbs-manager code and notification of battery removal
use the i2c alert callback to notify the sbs-battery driver that an
event has occurred.
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Avoid inclusion of unused twl4030-madc.h. This
will allow twl4030-madc.h to be merged into the
iio driver.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The status reported directly by the battery controller is not always
reliable and should be corrected based on the current draw information.
This implements such a correction with a dedicated function, called
where the supply status is retrieved.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
A mechanism to ignore the first external power change notification was
put in place years ago to ignore the power_supply_register notification.
However, this doesn't apply to the current situation anymore, as the
first notification is always the result of a legitimate power change.
This removes this deprecated mechanism, which puts back the driver's
state machine to a sane state (an ignored first notification previously
caused a charging/discharging status inversion).
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Add support for the SCOPE property, always return SCOPE_SYSTEM,
as the max170xx is used for the main battery on all known systems
with a max170xx.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
At least upower prefers the more precise charge_now sysfs value over
capacity and the max17042 has the info, so lets export it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The info is there, lets export it as a property.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The PROP_CHARGE_FULL code was hardcoded for the default sense
resistor of 0.010 Ohm, make it use r_sns which contains the
actual sense resistor value in micro-Ohms instead.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The info is there, so lets export it, like we already do for VOLT_MAX.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The max17042 is intended for Li-Ion or Li-Po batteries, add a TECHNOLOGY
attribute to reflect this. Note this is hardcoded to Li-Ion as there is
no way to tell the difference, and Lithium-Ion Polymer batteries are
a sub-family of Lithium-Ion so Li-Ion technically is correct for both.
Using Li-Ion for both is already done by many drivers and is much
better then not providing any technology info at all.
Suggested-by: Wolfgang Wiedmeyer <wolfgit@wiedmeyer.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
If our supplier changes status, chances are we've changed status too,
let any listeners know about this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Userspace prefers the driver having a status property over having to guess
itself. Specifically this will properly make the GNOME3 UI (and likely
others) properly show discharging / charging / full status, instead
of always showing discharging as status.
Note that in the case there is no charger driver supplying the max17042,
then a status of unknown will get returned. At least upower treats
this the same as not having a status attribute, so in this case nothing
changes from a userspace pov.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Some x86 machines use a max17047 fuel-gauge and x86 might be missing
platform_data if not provided by SFI.
This commit adds default platform_data as fallback option so that the
driver can work on boards where no platform_data is provided.
Since not all boards have a thermistor hooked up, set temp_min to 0 and
change the health checks from temp <= temp_min to temp < temp_min to
not trigger on such boards (where temp reads 0).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The temp alert values are 8-bit 2's complement, so sign-extend them
before reporting them back to the caller.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Use sign_extend32 to sign-extend variables where necessary instead of
DIY code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
trivial fix to spelling mistake in dev_error message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
When CONFIG_IIO=m and the axp20x_usb_power driver is built-in, we get
a link time error:
drivers/power/built-in.o: In function `axp20x_usb_power_get_property':
undefined reference to `iio_read_channel_processed'
drivers/power/built-in.o: In function `axp20x_usb_power_probe':
undefined reference to `devm_iio_channel_get'
undefined reference to `devm_iio_channel_get'
This adds the same dependency that we already have for the AC power driver
to the USB power driver. For consistency, I'm also moving the two closer
together in the Kconfig file.
Fixes: 33863c938c ("power: supply: axp20x_usb_power: use IIO channels when available")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Function devm_kzalloc() will return a NULL pointer. However, in function
isp1704_charger_probe(), the return value of devm_kzalloc() is directly
used without validation. This may result in a bad memory access bug.
Fixes: 34a109610e ("isp1704_charger: Add DT support")
Signed-off-by: Pan Bian <bianpan2016@163.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Since we use the default primary handler for the irq, IRQF_ONESHOT must
be set. Otherwise the request fails and the following errors are
displayed:
genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 129
sbs-battery 0-000b: Failed to request irq: -22
Signed-off-by: Ryosuke Saito <raitosyo@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
This patch adds the battery power supply driver to get various data from
the PMIC, such as the battery status (charging, discharging, full,
dead), current max limit, current current, battery capacity (in
percentage), voltage max and min limits, current voltage and battery
capacity (in Ah).
This battery driver uses the AXP20X/AXP22X ADC driver as PMIC data
provider.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
The driver was registering two classes, bq24190-battery & -charger.
Because the power supply framework cannot surface features from multiple
drivers in a single class, a fuel gauge driver would create a third class,
which some power management utilities cannot see.
Deprecate the -battery class for future removal and replicate its features
in -charger. Set /sys/class...-charger/online = pg_stat && !batfet_disable.
If device_property "omit-battery-class" is set, don't register -battery.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
It is sensible to assume that the hardware actually always has a
way of charging the battery so when power_supply_am_i_supplied does not
find any suppliers, that does not mean that there are none, but simply
that no power_supply-drivers are registered / bound for any suppliers for
the supply calling power_supply_am_i_supplied.
At which point a fuel-gauge driver calling power_supply_am_i_supplied()
cannot determine whether the battery is being charged or not.
Allow a caller of power_supply_am_i_supplied to differentiate between
there not being any suppliers, vs no suppliers being online by returning
-ENODEV if there are no suppliers matching supplied_to / supplied_from,
which allows fuel-gauge drivers to return POWER_SUPPLY_STATUS_UNKNOWN
rather then POWER_SUPPLY_STATUS_DISCHARGING if there are no suppliers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
We can't assume that the battery is or stays present after probing
on devices with replaceable battery.
On some devices (e.g. GTA04 or OpenPanodra) it can be removed
and even be hot swapped by the user while device continues to operate
through external AC or USB power (as long as system power consumption
remains below ca. 500mA as provided by USB). Under certain conditions
it is possible to boot without battery.
So it makes no sense to check for this situation during probe and make
the charger driver (and its status reports) completely non-operational if
the battery can be inserted later.
Tested on: GTA04 and OpenPandora.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Currently, the twl4030 charger defines its own max_current by directly
creating sysfs nodes. It should use the input_current_limit property
which is e.g. used by the bq24257 driver.
This patch adds the input_current_property with the same semantics as
the max_current property. The code to manage the max_current property
is removed by a separate patch.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Allow platform-code to disable the reset on probe and suspend/resume
by setting a "disable-reset" boolean device property on the device.
There are several reasons why the platform-code may want to disable
the reset on probe and suspend/resume:
1) Resetting the charger should never be necessary it should always have
sane values programmed. If it is running with invalid values while we
are not running (system turned off or suspended) there is a big problem
as that may lead to overcharging the battery.
2) The reset in suspend() is meant to put the charger back into default
mode, but this is not necessary and not a good idea. If the charger has
been programmed with a higher max charge_current / charge_voltage then
putting it back in default-mode will reset those to the safe power-on
defaults, leading to slower charging, or charging to a lower voltage
(and thus not using the full capacity) while suspended which is
undesirable. Reprogramming the max charge_current / charge_voltage
after the reset will not help here as that will put the charger back
in host mode and start the i2c watchdog if the host then does not do
anything for 40s (iow if we're suspended for more then 40s) the watchdog
expires resetting the device to default-mode, including resetting all
the registers to there safe power-on defaults. So the only way to keep
using custom charge settings while suspending is to keep the charger in
its normal running state with the i2c watchdog disabled. This is fine
as the charger will still automatically switch from constant current
to constant voltage and stop charging when the battery is full.
3) Besides never being necessary resetting the charger also causes
problems on systems where the charge voltage limit is set higher then the
reset value, if this is the case and the charger is reset while charging
and the battery voltage is between the 2 voltages, then about half the
time the charger gets confused and claims to be charging (REG08 contains
0x64) but in reality the charger has decoupled itself from VBUS (Q1 off)
and is drawing 0A from VBUS, leaving the system running from the battery.
This last problem is happening on a GPD-win mini PC with a bq24292i
charger chip combined with a max17047 fuel-gauge and a LiHV battery.
I've checked and TI does not list any errata for the bq24292i which
could explain this (there are no errata at all).
Cc: Liam Breck <kernel@networkimprov.net>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Liam Breck <kernel@networkimprov.net>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
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>
When I submitted the extcon handling I had a patch pending for the
extcon sub-system for extcon_register_notifier to take -1 as cable id
for listening for all type cable events on an extcon with a single
notifier.
In the end it was decided to instead add a new
extcon_register_notifier_all function for this, switch to using this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Liam Breck <kernel@networkimprov.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
On chip reset, polling loop used udelay(10) which is too short
to be useful. Instead, use usleep_range(100, 200).
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
On pm_runtime_get() failure, always emit an error message.
Prevent unbalanced pm_runtime_get by calling:
pm_runtime_put_noidle() in irq handler
pm_runtime_put_sync() on any probe() failure
Rename probe() out labels instead of renumbering them.
Fixes: 13d6fa8447fa ("power: bq24190_charger: Use PM runtime autosuspend")
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Polishing and fixes for initial extcon patch.
Fixes: 4db249b6f3b4 ("power: supply: bq24190_charger: Use extcon to determine ilimit, 5v boost")
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
If the charger is unplugged before the battery is full we may
see an over/under voltage fault. Ignore this rather then emitting
a message or uevent.
This fixes messages like these getting logged on charger unplug + replug:
bq24190-charger 15-006b: Fault: boost 0, charge 1, battery 0, ntc 0
bq24190-charger 15-006b: Fault: boost 0, charge 0, battery 0, ntc 0
Cc: Tony Lindgren <tony@atomide.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Liam Breck <kernel@networkimprov.net>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
This adds a new driver for the LEGO MINDSTORMS EV3 battery. The EV3 is
an embedded ARM device that can use 6 AA batteries or a special rechargeable
Li-ion battery pack. The rechargeable battery pack presses a special key
switch in the battery compartment to indicate that it is present.
The EV3 is only capable of monitoring battery voltage and current. The
charging circuit is built into the rechargeable battery pack and there is
no way to communicate with is, so we can't provide any information about
charging status.
When not using the rechargeable battery pack, it is most common to use
alkaline batteries to power the device, but it is also common for people to
use rechargeable NiMH batteries. Since there is not a way to automatically
differentiate between these, the technology property is made writable.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Equivalent information can be nowadays obtained using function tracer.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:<device>.
But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Some trivial improvements on the returning value of the
functions:
- remove unnecessary goto labels that just return, return
immediately, instead.
- do not initialize when not needed.
- return the value from the calling function that fails instead
of politically choosing -EINVAL.
Signed-off-by: Andi Shyti <andi@etezian.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
val might become 7 in which case stime[7] (array of length 7) would be
accessed during the scnprintf call later and that will cause issues.
Obviously, string concatenation is not intended here so just a comma needs
to be added to fix the issue.
Fixes: 98a2766493 ("power_supply: Add new lp8788 charger driver")
Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@gmail.com>
Acked-by: Milo Kim <milo.kim@ti.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The custom CPCAP PMIC used on Motorola phones such as Droid 4 has a
USB battery charger. It can optionally also have a companion chip that
is used for wireless charging.
The charger on CPCAP also can feed VBUS for the USB host mode. This
can be handled by the existing kernel phy_companion interface.
Cc: devicetree@vger.kernel.org
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Add support for monitoring an extcon device with USB SDP/CDP/DCP and HOST
cables and adjust ilimit and enable/disable the 5V boost converter
accordingly. This is necessary on systems where the PSEL pin is hardwired
high and ILIM needs to be set by software based on the detected charger
type, as well as on systems where the 5V boost converter is used, as
that always needs to be enabled from software.
Cc: Liam Breck <kernel@networkimprov.net>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The bq24192 and bq24192i are mostly identical to the bq24190, TI even
published a single datasheet for all 3 of them. The difference
between the bq24190 and bq24192[i] is the way charger-type detection
is done, the bq24190 is to be directly connected to the USB a/b lines,
where as the the bq24192[i] has a gpio which should be driven high/low
externally depending on the type of charger connected, from a register
level access pov there is no difference.
The differences between the bq24192 and bq24192i are:
1) Lower default charge rate on the bq24192i
2) Pre-charge-current can be max 640 mA on the bq24192i
On x86/ACPI systems the code which instantiates the i2c client may not
know the exact variant being used, so instead of coding the model-id
in the i2c_id struct and bailing if it does not match, check the reported
model-id matches one of the supported variants.
This commit only adds support for the bq24192i as I don't
have a bq24192 to test with, adding support for the bq24192 should
be as simple as also accepting its model-id in the model-id test.
Cc: Liam Breck <kernel@networkimprov.net>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
The i2c-core already maps of irqs before calling the driver's probe
function and there are no in tree users of
bq24190_platform_data->gpio_int.
Remove the redundant custom irq-mapping code and just use client->irq.
Cc: Liam Breck <kernel@networkimprov.net>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Without CONFIG_PM, we get a harmless warning:
drivers/power/supply/bq24190_charger.c:1514:12: error: 'bq24190_runtime_resume' defined but not used [-Werror=unused-function]
drivers/power/supply/bq24190_charger.c:1501:12: error: 'bq24190_runtime_suspend' defined but not used [-Werror=unused-function]
To avoid the warning, we can mark all four PM functions as __maybe_unused,
which also lets us remove the incorrect #ifdef.
Fixes: 3d8090cba638 ("power: bq24190_charger: Check the interrupt status on resume")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Liam Breck <kernel@networkimprov.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
