Created attachment 1652287 [details] Output of some diagnostic tools 1. Machine: The PC is a HP Pavilion x2 (detachable) Distribution and kernel updated at the latest revision as a potential way to solve the issue below. 2. OS: Dual boot Windows 10 + Fedora 31 (kernel 5.4.8-200.fc31.x86_64 x86_64) 3. The issue I cannot charge the battery when Fedora is running. The led status of the battery works as expected: steady white when on battery (greater than a certain treshold), and steady orange when in charge. When the AC cable is inserted the led switch from white to orange. 4. Facts and evidences When the PC is off the battery charges normally. Same when using Windows 10. The issue can be reproduced turning the PC on and booting in Fedora. The PC doesn't charge the battery when the OS is running. - NOTE - This issue is quite similar to the #1610545 raised by Dario Balboni on a EZBOOK2 and assigned to Hans De Goede. The resolution in that case was to disable the battery temperature sensor pin. I guess that the register dump is different for the HP Pavilion, and the same instructions cannot apply. Some journal output, and the very same steps used to analyse the above mentioned issue are in the attachment as well.
I believe I have the same hp x2 model as you do, if you undock the tablet part from the keyboard, then at the bottom of the tablet part (where the dock connector is) there is some small text written. Fully to the right, at the top row of the text for my X2 it says: M/M 10-n000nd what does your model say? Also I guess your model uses a Type-C connector for charging like my model does? The problem is that the AXP288 PMIC can only do USB-2 charger-type detection using the BC1.2 spec charger type detection and HP has added some custom glue to do Type-C charger type detection through the Cc pins. So if you take a USB-A to Type-C cable, combined with an 2A charger with an USB-A receptacle, then the "cat /sys/class/extcon/extcon*/state" should look like this: # cat /sys/class/extcon/extcon*/state SDP=0 CDP=0 DCP=1 USB=0 And the device will charge at 2A, but because of the custom glue Linux does not recognize the actual Type-C charger which comes with the device and you end up with the safe default of 500 mA which is not even enough to keep the device from discharging while it is on. You can verify the configured charging current by doing: cat /sys/class/power_supply/axp288_charger/input_current_limit And you can manually fix it after plugging in the charger by doing: sudo sh -c "echo 3000000 > /sys/class/power_supply/axp288_charger/input_current_limit" Assuming you are using a Type-C charger which can deliver up to 3A. When I initially got my HP x2 10-n000nd I spend some time trying to come up with a proper fix, but I've not had any luck with this, sorry.
> Fully to the right, at the top row of the text for my X2 it says: M/M 10-n000nd > what does your model say? UGh, that should be "Fully to the left" ...
Right, fully to the left, the model is M/M 10-n010nl Input power: 5.25V:::3A, using a USB-C or Type-C connector. I read the configured value for the charging current: # cat /sys/class/power_supply/axp288_charger/input_current_limit 500000 and updated via # sh -c "echo 3000000 > /sys/class/power_supply/axp288_charger/input_current_limit" I charged the battery during the night (PC fully off) and now Fedora reports "Fully charged". I used the PC for some time to discharge a bit, so to engage the recharging state (there should be a threshold around 94%,to avoid too frequent recharges). I rebooted too, and used Windows 10 to assess the battery status there. Battery fully charged, and the OS acknowledges the AC when cable inserted. Rebooted to Fedora, battery shows a 84%. Surprise, plugging the AC cable the battery states "0:39 to charge (84%)". << It works !! >> Let's see if lasts over time or if it's just a stroke of luck :-) Thank you so much, appreciated --------------------------------------- I don't have a solid electric/electronic background, then I'm unsure of the meaning of extcon' state, as an example. Acronyms don't mean much to me (SDP,CDP,DCP; maybe USB...) Where can I find information of that, to deepen my knowledge? And is there a register dump, to better understand the meaning the output of, say, "i2cdump -y -f # 0x34" ? E.g. where is the temperature dump setting? etc... Thanks
(In reply to Roberto from comment #3) > Right, fully to the left, the model is M/M 10-n010nl > > Input power: 5.25V:::3A, using a USB-C or Type-C connector. Ok, slightly different model number, but that may just mean a different wifi chip or some such is used, over all it seems to be mostly the same device as my 10-n000nd > Let's see if lasts over time or if it's just a stroke of luck :-) The input_current_limit should change back to 500000 if you unplug and replug the charger (unless you are using a different charger now), the fix of echoing a new value to input_current_limit is only temporary. In the mean time I've taken another shot at debugging / fixing this yesterday evening and I think I may have a solution. I will get back to you on this in a couple of days. > I don't have a solid electric/electronic background, then I'm unsure of the > meaning of extcon' state, as an example. > Acronyms don't mean much to me (SDP,CDP,DCP; maybe USB...) SDP: Standard Downstream Port, a normal USB port on a PC (with USB data capabilities), which can deliver max 500mA current. CDP: Charging Downstream Port, a "charging" USB port on a PC (with USB data capabilities), which can deliver max 1500mA current. DCP: Dedicated Charing Port, a USB port on a charger, with no USB data capabilities (typically the data lines are shorted together), which can deliver max 2000mA current. USB, only there for legacy / backward compat reasons, synonymous with SDP. > Where can I find information of that, to deepen my knowledge? > And is there a register dump, to better understand the meaning the output > of, say, "i2cdump -y -f # 0x34" ? > E.g. where is the temperature dump setting? etc... If you want to learn more about the AXP288, search the web for AXP288_ver1.07.pdf
Ok, so fixing this took a bit longer then I estimated, mostly because there also were a bunch of issues with: 1. Spurious wakeups from suspend 2. Not waking up (and not starting to charge) when the charger gets plugged in while suspended 3. The lid switch getting stuck in "closed" position after the first open / close of the lid I've fixed all of these and started a scratch-build of the latest Fedora kernel with my fixes added: https://koji.fedoraproject.org/koji/taskinfo?taskID=40933593 Note this is still building atm, it should be finished in a couple of hours. See here for instructions on installing a kernel directly from koji: https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
(In reply to Hans de Goede from comment #5) > Ok, so fixing this took a bit longer then I estimated, mostly because there > also were a bunch of issues with: > > 1. Spurious wakeups from suspend > 2. Not waking up (and not starting to charge) when the charger gets plugged > in while suspended > 3. The lid switch getting stuck in "closed" position after the first open / > close of the lid > > I've fixed all of these and started a scratch-build of the latest Fedora > kernel with my fixes added: > https://koji.fedoraproject.org/koji/taskinfo?taskID=40933593 > > Note this is still building atm, it should be finished in a couple of hours. > > See here for instructions on installing a kernel directly from koji: > https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt •._.••´¯``•.¸¸.•` Definitely it works •._.••´¯``•.¸¸.•` The new kernel solved the issue, the AC power charges the battery. I've tested some situations like closing the lid and connecting the cable, suspending and recharging, all these are ok. --- Many Thanks --- Here below some reports if they might be of any help: $ cat /sys/class/power_supply/axp288_charger/* POWER_SUPPLY_NAME=axp288_charger POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_ONLINE=1 POWER_SUPPLY_TYPE=USB POWER_SUPPLY_HEALTH=Good POWER_SUPPLY_CONSTANT_CHARGE_CURRENT=2800000 POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=2800000 POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE=4350000 POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=4350000 POWER_SUPPLY_INPUT_CURRENT_LIMIT=3000000 $ cat /sys/class/power_supply/axp288_fuel_gauge/* POWER_SUPPLY_NAME=axp288_fuel_gauge POWER_SUPPLY_STATUS=Charging POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_HEALTH=Good POWER_SUPPLY_VOLTAGE_MAX_DESIGN=4350000 POWER_SUPPLY_VOLTAGE_NOW=4100000 POWER_SUPPLY_VOLTAGE_OCV=3889000 POWER_SUPPLY_CURRENT_NOW=1856000 POWER_SUPPLY_CAPACITY=25 POWER_SUPPLY_CAPACITY_ALERT_MIN=0 POWER_SUPPLY_TECHNOLOGY=Li-ion POWER_SUPPLY_CHARGE_FULL=4938752 POWER_SUPPLY_CHARGE_NOW=1218672 $ sudo tlp-stat -b --- TLP 1.2.2 -------------------------------------------- +++ Battery Features: Charge Thresholds and Recalibrate natacpi = inactive (no kernel support) tpacpi-bat = inactive (laptop not supported) tp-smapi = inactive (laptop not supported) +++ Battery Status: axp288_fuel_gauge /sys/class/power_supply/axp288_fuel_gauge/manufacturer = (not available) /sys/class/power_supply/axp288_fuel_gauge/model_name = (not available) /sys/class/power_supply/axp288_fuel_gauge/cycle_count = (not supported) /sys/class/power_supply/axp288_fuel_gauge/charge_full_design = (not available) /sys/class/power_supply/axp288_fuel_gauge/charge_full = 4938752 [mAh] /sys/class/power_supply/axp288_fuel_gauge/charge_now = 1167712 [mAh] /sys/class/power_supply/axp288_fuel_gauge/current_now = 1616 [mA] /sys/class/power_supply/axp288_fuel_gauge/status = Charging
I'm happy to hear that the patches work for you. In the mean time I've got a report by email from a user with a HP x2 10 with a Cherry Trail SoC in combination with an AXP288, this seems to be the same mainboard design with just a different SoC. I'm waiting for testing feedback from that user. Once I have (positive) feedback for that other model then I will submit the patches upstream and then eventually they should find their way to the Fedora kernels. Until the patches are added to the Fedora kernels, I suggest that you stick with the test kernel which I build for you.
Yup, curious to hear about, you mean same charging (not charging) issue? I appreciate the hard work you did, overcoming several hindrances to the patch. And you bet I'll use the test kernel :-) Thanks again, great job indeed.
(In reply to Roberto from comment #8) > Yup, curious to hear about, you mean same charging (not charging) issue? Yes, Cherry Trail is a die shrink of Bay Trail and it seems the mainboard of the HP x2 10 with Cherry Trail SoC and AXP288 PMIC seems to be mostly unchanged from the one on your model, so same issues with charging, spurious wakeup, lid switch stuck in closed position, etc.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 31 kernel bugs. Fedora 31 has now been rebased to 5.5.7-200.fc31. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 32, and are still experiencing this issue, please change the version to Fedora 32. If you experience different issues, please open a new bug report for those.
The patches fixing this have been submitted upstream, but they are not in 5.5.7, so this is not fixed yet.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to Hans de Goede from comment #11) > The patches fixing this have been submitted upstream, but they are not in > 5.5.7, so this is not fixed yet. In the mean time the patches fixing this have landed quite a while ago, closing.