summaryrefslogtreecommitdiff
path: root/drivers/power/supply/cpcap-charger.c
AgeCommit message (Collapse)AuthorFilesLines
2019-10-21power: supply: cpcap-charger: cpcap_charger_voltage_to_regval() can be statickbuild test robot1-1/+1
Add 'static' keyword to internal function as reported by sparse using the following configuration: make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' Fixes: d4ee021c410f ("power: supply: cpcap-charger: Limit voltage to 4.2V for battery") Signed-off-by: kbuild test robot <lkp@intel.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-10-20power: supply: cpcap-charger: Allow changing constant charge voltageTony Lindgren1-0/+83
Let's allow reconfiguring the cpcap-charger max charge voltage and default to 4.2V that should be safe for the known users. This allows the users to use 4.35V for the extra capacity if really needed at a cost of probably shorter battery life. We check the constant charge voltage limit set by the battery. Some pieces of the property setting code is based on an earlier patch from Pavel Machek <pavel@ucw.cz> but limited to configuring the charge voltage for now. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-10-20power: supply: cpcap-charger: Improve battery detectionTony Lindgren1-3/+4
We are currently using a wrong ADC range for the battery detection. The ADC returns the battery temperature if connected. Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-10-20power: supply: cpcap-charger: Limit voltage to 4.2V for batteryTony Lindgren1-2/+130
There have been some cases of droid4 battery bulging that seem to be related to being left connected to the charger for several weeks. It is suspected that the 4.35V charge voltage configured for the battery is too much in the long run, so lets limit the charge voltage to 4.2V. It could also be that the batteries are just getting old. We don't really want to just change the charge voltage to 4.2V as Android may have charged the battery to 4.35V as pointed out by Pavel Machek. To add checks for battery voltage, the driver needs to understand the voltage it's charging at, and also needs to better understand it's charger state. Right now it only understands connect and disconnect, while now we need to know also a connected state but not charging. So let's add better charger state handling with help of chrgcurr2 interrupt for detecting charge full and retry, and add a check for battery voltage before we start charging. And then we finally can lower the charge voltage to 4.2V. Note that we've been using the same register values as the Android distros on droid4, so it is suspected that the same problem also exists in Android. Cc: Pavel Machek <pavel@ucw.cz> Cc: Rob Herring <robh+dt@kernel.org> Reported-by: Merlijn Wajer <merlijn@wizzup.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-09-03power: supply: cpcap-charger: Enable vbus boost voltageTony Lindgren1-3/+20
We are currently not enabling VBUS boost for cpcap when in host mode. This means the VBUS is fed at the battery voltage level, which can cause flakeyness enumerating devices. Looks like the boost control for VBUS is CPCAP_BIT_VBUS_SWITCH that we must enable in the charger for nice 4.92 V VBUS output. And looks like we must not use the STBY pin enabling but must instead use manual VBUS control in phy-cpcap-usb. We want to do this in cpcap_charger_vbus_work() and also set a flag for feeding_vbus to avoid races between USB detection and charger detection, and disable charging if feeding_vbus is set. Cc: Jacopo Mondi <jacopo@jmondi.org> Cc: Kishon Vijay Abraham I <kishon@ti.com> Cc: Marcel Partap <mpartap@gmx.net> Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Michael Scott <hashcode0f@gmail.com> Cc: NeKit <nekit1000@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174Thomas Gleixner1-9/+1
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-15power: supply: cpcap-charger: Fix pointless EPROBE_DEFER warningsTony Lindgren1-2/+3
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-01-21cpcap-charger: generate events for userspacePavel Machek1-0/+1
The driver doesn't generate uevents on charger connect/disconnect. This leads to UPower not detecting when AC is on or off... and that is bad. Reported by Arthur D. on github ( https://github.com/maemo-leste/bugtracker/issues/206 ), thanks to Merlijn Wajer for suggesting a fix. Cc: stable@kernel.org Signed-off-by: Pavel Machek <pavel@ucw.cz> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2018-12-05power: supply: cpcap-charger: clean an indentation issue, remove tabColin Ian King1-1/+1
Trivial fix to clean up indentation issue, remove an extraneous tab Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2017-11-13power: supply: cpcap-charger: fix incorrect return value checkPan Bian1-1/+1
Function platform_get_irq_byname() returns a negative error code on failure, and a zero or positive number on success. However, in function cpcap_usb_init_irq(), positive IRQ numbers are also taken as error cases. Use "if (irq < 0)" instead of "if (!irq)" to validate the return value of platform_get_irq_byname(). Signed-off-by: Pan Bian <bianpan2016@163.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
2017-06-15power: supply: cpcap-charger: Add missing power_supply_configTony Lindgren1-1/+5
Otherwise cpcap-battery won't probe properly with the power-supplies property configured but will fail with "Not all required supplies found, defer probe". 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>
2017-05-14power: supply: cpcap-charger: Fix charger voltages based on ADC valuesTony Lindgren1-10/+14
With the ADC driver working, we can now fix the voltage table based on the values read from the ADC. Note that unlike the ICHRG registers, the VCHRG register bits don't match the MC13783UG.pdf. 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 <sre@kernel.org>
2017-05-14power: supply: cpcap-charger: Update charge current table and add commentsTony Lindgren1-24/+35
Turns out a similar battery charger hardware is documented for NXP MC13783 PMIC in "MC13783 Power Management and Audio Circuit Users's Guide" named MC13783UG.pdf. Looks like the CPCAP charge current table matches that, so let's start using the nominal values from it. While at it, let's also add comments to some of the mystery CPCAP charger registers based on the MC13783UG.pdf documentation. Note that this patch does not contain any functional changes, the register values being used stay the same. 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 <sre@kernel.org>
2017-05-04power: supply: cpcap-charger: Keep trickle charger bits disabledTony Lindgren1-2/+1
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: 0c9888e3c192 ("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>
2017-05-04power: supply: cpcap-charger: Fix enable for 3.8V charge settingTony Lindgren1-1/+1
Zero is a valid register value for for 3.8V charging. Fixes: 0c9888e3c192 ("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>
2017-05-04power: supply: cpcap-charger: Fix charge voltage configurationTony Lindgren1-2/+2
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: 0c9888e3c192 ("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>
2017-05-04power: supply: cpcap-charger: Fix charger nameTony Lindgren1-1/+1
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: 0c9888e3c192 ("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>
2017-04-14power: supply: cpcap-charger: Add minimal CPCAP PMIC battery chargerTony Lindgren1-0/+681
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>