- 04 May, 2017 4 commits
-
-
Tony Lindgren authored
Zero is a valid register value for for 3.8V charging. Fixes: 0c9888e3 ("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>
-
Tony Lindgren authored
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: 0c9888e3 ("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 authored
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: 0c9888e3 ("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:
-
Sebastian Reichel authored
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:
-
- 01 May, 2017 29 commits
-
-
Phil Reid authored
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 authored
Add two entries to map to my primary kernel address. Signed-off-by:Sebastian Reichel <sre@kernel.org>
-
Sebastian Reichel authored
Avoid inclusion of unused twl4030-madc.h. This will allow twl4030-madc.h to be merged into the iio driver. Signed-off-by: -
Paul Kocialkowski authored
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:
-
Paul Kocialkowski authored
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:
-
Michael Trimarchi authored
This changed is needed to avoid locking problem during boot as shown: <5>[ 8.824096] Registering SWP/SWPB emulation handler <6>[ 8.977294] clock: disabling unused clocks to save power <3>[ 9.108154] BUG: sleeping function called from invalid context at kernel_albert/kernel/mutex.c:269 <3>[ 9.122894] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0 <4>[ 9.130249] 3 locks held by swapper/0/1: <4>[ 9.134613] #0: (&__lockdep_no_validate__){......}, at: [<c0342430>] __driver_attach+0x58/0xa8 <4>[ 9.144500] #1: (&__lockdep_no_validate__){......}, at: [<c0342440>] __driver_attach+0x68/0xa8 <4>[ 9.154357] #2: (&polling_timer){......}, at: [<c0053770>] run_timer_softirq+0x108/0x3ec <4>[ 9.163726] Backtrace: <4>[ 9.166473] [<c001269c>] (dump_backtrace+0x0/0x114) from [<c067e5f0>] (dump_stack+0x20/0x24) <4>[ 9.175811] r6:00203230 r5:0000010d r4:d782e000 r3:60000113 <4>[ 9.182250] [<c067e5d0>] (dump_stack+0x0/0x24) from [<c007441c>] (__might_sleep+0x10c/0x128) <4>[ 9.191650] [<c0074310>] (__might_sleep+0x0/0x128) from [<c0688f60>] (mutex_lock_nested+0x34/0x36c) <4>[ 9.201660] r5:c02d5350 r4:d79a0c64 <4>[ 9.205688] [<c0688f2c>] (mutex_lock_nested+0x0/0x36c) from [<c02d5350>] (regulator_set_current_limit+0x30/0x118) <4>[ 9.217071] [<c02d5320>] (regulator_set_current_limit+0x0/0x118) from [<c0435ce0>] (update_charger+0x84/0xc4) <4>[ 9.228027] r7:d782fb20 r6:00000101 r5:c1767e94 r4:00000000 <4>[ 9.234436] [<c0435c5c>] (update_charger+0x0/0xc4) from [<c0435d40>] (psy_changed+0x20/0x48) <4>[ 9.243804] r5:d782e000 r4:c1767e94 <4>[ 9.247802] [<c0435d20>] (psy_changed+0x0/0x48) from [<c0435dec>] (polling_timer_func+0x84/0xb8) <4>[ 9.257537] r4:c1767e94 r3:00000002 <4>[ 9.261566] [<c0435d68>] (polling_timer_func+0x0/0xb8) from [<c00537e4>] (run_timer_softirq+0x17c/0x3ec) <4>[ 9.272033] r4:c1767eb0 r3:00000000 <4>[ 9.276062] [<c0053668>] (run_timer_softirq+0x0/0x3ec) from [<c004b000>] (__do_softirq+0xf0/0x298) <4>[ 9.286010] [<c004af10>] (__do_softirq+0x0/0x298) from [<c004b650>] (irq_exit+0x98/0xa0) <4>[ 9.295013] [<c004b5b8>] (irq_exit+0x0/0xa0) from [<c000edbc>] (handle_IRQ+0x60/0xc0) <4>[ 9.303680] r4:c1194e98 r3:c00bc778 <4>[ 9.307708] [<c000ed5c>] (handle_IRQ+0x0/0xc0) from [<c0008504>] (gic_handle_irq+0x34/0x68) <4>[ 9.316955] r8:000ac383 r7:d782fc3c r6:d782fc08 r5:c11936c4 r4:e0802100 <4>[ 9.324310] r3:c026ba48 <4>[ 9.327301] [<c00084d0>] (gic_handle_irq+0x0/0x68) from [<c068c2c0>] (__irq_svc+0x40/0x74) <4>[ 9.336456] Exception stack(0xd782fc08 to 0xd782fc50) <4>[ 9.342041] fc00: d6e30e6c ac383627 00000000 ac383417 ea19c000 ea200000 <4>[ 9.351104] fc20: beffffff 00000667 000ac383 d6e30670 d6e3066c d782fc94 d782fbe8 d782fc50 <4>[ 9.360168] fc40: c026ba48 c001d1f0 00000113 ffffffff Fixes: b2998049 ("[BATTERY] pda_power platform driver") Signed-off-by:Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by:
Anthony Brandon <anthony@amarulasolutions.com> Signed-off-by:
-
Hans de Goede authored
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:
-
Hans de Goede authored
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 authored
The info is there, lets export it as a property. Signed-off-by:
-
Hans de Goede authored
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 authored
The info is there, so lets export it, like we already do for VOLT_MAX. Signed-off-by:
-
Hans de Goede authored
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 authored
If our supplier changes status, chances are we've changed status too, let any listeners know about this. Signed-off-by:
-
Hans de Goede authored
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 authored
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 authored
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 authored
Use sign_extend32 to sign-extend variables where necessary instead of DIY code. Signed-off-by:
-
Colin Ian King authored
trivial fix to spelling mistake in dev_error message. Signed-off-by:
-
Arnd Bergmann authored
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: 33863c93 ("power: supply: axp20x_usb_power: use IIO channels when available") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Pan Bian authored
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: 34a10961 ("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:
-
Rahul Bedarkar authored
Replace ifdefs with SIMPLE_DEV_PM_OPS helper macro. Signed-off-by:
Rahul Bedarkar <rahulbedarkar89@gmail.com> Signed-off-by:
-
Ryosuke Saito authored
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:
-
Quentin Schulz authored
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:
-
Quentin Schulz authored
The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply. This patch adds the DT binding documentation for the battery power supply which gets 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). Signed-off-by:
Rob Herring <robh@kernel.org> Acked-by:
-
Liam Breck authored
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 authored
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:
-
H. Nikolaus Schaller authored
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 authored
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:
-
Hans de Goede authored
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:
-
- 13 Apr, 2017 7 commits
-
-
Hans de Goede authored
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:
-
Sebastian Reichel authored
-
Liam Breck authored
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 authored
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 authored
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 authored
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:
-
David Lechner authored
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:
-
