summaryrefslogtreecommitdiff
path: root/drivers/power/supply/cpcap-battery.c
AgeCommit message (Collapse)Author
2019-04-15power: supply: cpcap-battery: Fix pointless EPROBE_DEFER warningsTony Lindgren
With loadable modules we may get the following during init: could not initialize VBUS or ID IIO: -517 Let's not print any pointless error messages for deferred probe. Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-04-15power: supply: cpcap-battery: Use accumulator for current and power averageTony Lindgren
We should not use measured current value for average since we have proper coulomb counter values available. Using measured current value should be only used when the value is queried at a higher rate than the 250 ms rate the coulomb counter is configured to run at. Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-04-15power: supply: cpcap-battery: Fix coulomb counter calibration register useTony Lindgren
The coulomb counter calibration is not CCO, it's CCM. And the CCM is nine bits wide signed register, so let's use sign_extend32() for it. Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-04-15power: supply: cpcap-battery: Fix signed counter sample registerTony Lindgren
The accumulator sample register is signed 32-bits wide register on droid 4. And only the earlier version of cpcap has a signed 24-bits wide register. We're currently passing it around as unsigned, so let's fix that and use sign_extend32() for the earlier revision. Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-04-15power: supply: cpcap-battery: Fix low battery checkTony Lindgren
We need to check current instead of the charge counter to see if a charger is connected. The charge counter shows the cumulated value instead of the current charge current and can be negative or positive. Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-04-10power: supply: cpcap-battery: Fix division by zeroTony Lindgren
If called fast enough so samples do not increment, we can get division by zero in kernel: __div0 cpcap_battery_cc_raw_div cpcap_battery_get_property power_supply_get_property.part.1 power_supply_get_property power_supply_show_property power_supply_uevent Fixes: 874b2adbed12 ("power: supply: cpcap-battery: Add a battery driver") Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2018-12-05power: supply: cpcap-battery: make array cpcap_battery_irqs static, shrinks ↵Colin Ian King
object size Don't populate the array cpcap_battery_irqs on the stack but instead make it static. Makes the object code smaller by 99 bytes: Before: text data bss dec hex filename 13673 2448 0 16121 3ef9 cpcap-battery.o After: text data bss dec hex filename 13510 2512 0 16022 3e96 cpcap-battery.o (gcc version 8.2.0 x86_64) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2017-12-01power: supply: cpcap-battery: Fix platform_get_irq_byname's error checkingArvind Yadav
The platform_get_irq_byname() function returns -1 if an error occurs. zero or positive number on success. platform_get_irq_byname() error checking for zero is not correct. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2017-06-08power: supply: cpcap-battery: Add a battery driverTony Lindgren
On the CPCAP PMIC we can use the ADCs for monitoring the battery, and there is also a coulomb counter. So let's add basic support for the battery driver. I did not add any capacity prediction as that should probably be done in the user space. Or at least user space should tell the kernel some battery statistics and then the kernel driver could display the capacity based on that. Cc: devicetree@vger.kernel.org Cc: Marcel Partap <mpartap@gmx.net> Cc: Michael Scott <michael.scott@linaro.org> Cc: Rob Herring <robh@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>