Created attachment 300797 [details] acpidump My issue seems remarkably similar to this issue filed here. But with a different tablet computer, the Nuvision Solo 10 Draw. https://bugzilla.redhat.com/show_bug.cgi?id=1610545 Running the following commands as root from that page modprobe i2c-dev i2cset -y -f 6 0x34 0x82 0xf0 i2cset -y -f 6 0x34 0x84 0xf0 seems to solve the issue allowing the battery to charge and stopping the red light indicator from blinking. Operating System: Arch Linux Kernel: 5.17.4-arch1-1 Attached some information about the battery and system.
Created attachment 300798 [details] tlp-stat
Thank you for your bug report. It seems that this is actually caused by the fix for: https://bugzilla.redhat.com/show_bug.cgi?id=1610545 Based on: https://wiki.archlinux.org/title/Nuvision_Solo_10_Draw which says that this was introduced in July 23, 2019, I suspect that the fix for rhbz#1610545 : https://github.com/torvalds/linux/commit/9bcf15f75cac3c6a00d8f8083a635de9c8537799 actually causes this issue, or at least exposed a pre-existing problem with the device's firmware which was hidden before. I guess this really actually is the same as bug 203829, which is about a similar bug on a Lenovo Ideapd 100S exposed by the kernel now honoring the battery-temperature-sensor-bias-current configured by the BIOS (honoring as in leaving it as is), rather then hardcoding 80 ųA for this. Can you disable the workaround and then read the value of both registers ? : modprobe i2c-dev i2cget -y -f 6 0x34 0x82 i2cget -y -f 6 0x34 0x84 And let me know the value of both registers? Then please try the following instead as workaround: i2cset -y -f 6 0x34 0x84 0xf3 Unlike the workaround which you have been using this does actually leave the temperature sensor input to the charger enabled, but switches the bias current to 80 ųA as Linux used to do in kernels older then kernel 5.0.
I actually wrote most of that ArchWiki page on the Nivision Okay the output I get is sudo i2cget -y -f 6 0x34 0x82 0xf0 sudo i2cget -y -f 6 0x34 0x84 0xe0 The workaround seems to work to enable charging.
Hmm, ok this is a bit weird. Can you try blacklisting the "axp288_adc" kernel module and then turning off the tablet and after it powering back on again without the "axp288_adc" module loaded do: i2cget -y -f 6 0x34 0x82 i2cget -y -f 6 0x34 0x84 Again? Also can you try using: i2cset -y -f 6 0x34 0x84 0xe3 as workaround ? I have the feeling that the problem is that the axp288_adc driver ends up disabling the bias current all together on this device, changing 0x84 from 0xe0 to 0xe3 will enable the bias current without changing the amount of bias current.
Okay so here is the output with 'axp288_adc' blacklisted and no cables plugged in, it's the same as before. But I know it's not active because I lose the battery status. sudo i2cget -y -f 6 0x34 0x82 0xf0 sudo i2cget -y -f 6 0x34 0x84 0xe0 Should I use 'i2cset -y -f 6 0x34 0x84 0xe3' as a workaround when the 'axp288_adc' module isn't blacklisted and currently loaded?
I tried charging anyways without using the workarounds and with 'axp288_adc' blacklisted. The red battery light came on as if it were charging.
So I enabled the module again and it seem to be charging now without any workarounds. I had one thought, I noticed the blinking starts to occur after some time using the tablet and watching videos in Firefox. Is it possible that things are working normally but the system at a low level is tripping on actual temperature measurements when the tablet gets hot? Maybe I have to adjust the temperature thresholds in the BIOS? What do you think?
(In reply to Lance G. from comment #6) > I tried charging anyways without using the workarounds and with 'axp288_adc' > blacklisted. The red battery light came on as if it were charging. Right, so I guess that some part of the: modprobe i2c-dev i2cset -y -f 6 0x34 0x82 0xf0 i2cset -y -f 6 0x34 0x84 0xf0 Workaround which you have been using somehow sticks around even after a power-cycle. These tablets often have a mode where they show an animation when charging while turned off. Can you try turning the tablet off without the charger connected and then plug in the charger and see if you get such an animation? If you do then after that boot with 'axp288_adc' still blacklisted and then dump the 2 registers again. If that does not make any change, then I wonder what happens if you do load the axp288_adc driver and then try to charge the tablet ? It sounds to me like that should just work. IOW it seems that your workaround maybe is no longer needed ? Another interesting data point would be if you can unplug the battery, or keep the tablet on till it powers off due to the battery being dead (check it does not power-up again without charging) and then after that boot with 'axp288_adc' still blacklisted and then dump the 2 registers again, so that we know we really have the firmware set values and not values previously set by the workaround sticking over a reboot. Talking about the workaround. I assume you have disabled any systemd units you have written to do this automatically?
Note my previous comment was written before seeing this: (In reply to Lance G. from comment #7) > So I enabled the module again and it seem to be charging now without any > workarounds. Yes I already kinda expected that. > I had one thought, I noticed the blinking starts to occur after some time > using the tablet and watching videos in Firefox. Is it possible that things > are working normally but the system at a low level is tripping on actual > temperature measurements when the tablet gets hot? Yes, that is the whole purpose of the TS (temperature-sense) pin we are dealing with here, to disable charging when things get too hot. > Maybe I have to adjust > the temperature thresholds in the BIOS? I would not mess with those. I think everything is working as it should, even though the tablet is not charging, it also should not really discharge either and when you stop watching videos in Firefox and things cool down a bit it should start charging again I think.
(In reply to Hans de Goede from comment #8) > (In reply to Lance G. from comment #6) > > I tried charging anyways without using the workarounds and with > 'axp288_adc' > > blacklisted. The red battery light came on as if it were charging. > > Right, so I guess that some part of the: > > modprobe i2c-dev > i2cset -y -f 6 0x34 0x82 0xf0 > i2cset -y -f 6 0x34 0x84 0xf0 > > Workaround which you have been using somehow sticks around even after a > power-cycle. > > These tablets often have a mode where they show an animation when charging > while turned off. > > Can you try turning the tablet off without the charger connected and then > plug in the charger and see if you get such an animation? If you do then > after that boot > with 'axp288_adc' still blacklisted and then dump the 2 registers again. > > If that does not make any change, then I wonder what happens if you do load > the axp288_adc driver and then try to charge the tablet ? It sounds to me > like that should just work. IOW it seems that your workaround maybe is no > longer needed ? I have 'S5 Charging Driver' and 'S5 LPM Settings' switched on in the BIOS. I noticed without those enabled the tablet would still light the red light as if charging but no animation would play. With those enabled I get a nice battery status animation when the tablet is fully powered off from the operating system but is plugged in and charging. I let my tablet power off and go through the animation. As soon as the animation came up I unplugged and started boot again. Those i2c registers still show the same values and 'axp288_adc' was blacklisted at the time. > Another interesting data point would be if you can unplug the battery, or > keep the tablet on till it powers off due to the battery being dead (check > it does not power-up again without charging) and then after that boot with > 'axp288_adc' still blacklisted and then dump the 2 registers again, so that > we know we really have the firmware set values and not values previously set > by the workaround sticking over a reboot. I can try this sometime later. > Talking about the workaround. I assume you have disabled any systemd units > you have > written to do this automatically? I know I don't have anything enabled regarding workarounds. I have been needing to manually 'sudo modprobe i2c-dev' just to be able to make use of the 'i2cget' and 'i2cset' commands
(In reply to Hans de Goede from comment #9) > I would not mess with those. I think everything is working as it should, > even though the tablet is not charging, it also should not really discharge > either and when you stop watching videos in Firefox and things cool down a > bit it should start charging again I think. Do you think it's actually working as intended? So I just misunderstood when it was not charging. It was just holding the battery where it is when plugged in but not trying to give it charge due to temperature. If that's true, then why do you suppose sometimes the tablet blinks red when the indicator shows plenty of battery life left? It's quite annoying and makes me think something is wrong or the tablet will shutdown unexpectedly.
I believe the red blinking is to indicate that the battery is not charging due to the tablet being too hot.
it blinks when not plugged in to charge yet continues running as normal.
I tried letting the tablet run out to where it wouldn't boot, showing a low battery symbol. But after a bit it booted again despite showing the low battery icon before. On boot the 'axp288_adc' is still blacklisted. In this weird boot I recorded the following output. During this the tablet red light was blinking the entire time. sudo i2cget -y -f 6 0x34 0x82 0xf1 sudo i2cget -y -f 6 0x34 0x84 0xe2
I got roughly another 25 minutes of runtime before the system died again.
(In reply to Lance G. from comment #14) > I tried letting the tablet run out to where it wouldn't boot, showing a low > battery symbol. But after a bit it booted again despite showing the low > battery icon before. On boot the 'axp288_adc' is still blacklisted. In this > weird boot I recorded the following output. During this the tablet red light > was blinking the entire time. > > sudo i2cget -y -f 6 0x34 0x82 > 0xf1 > > sudo i2cget -y -f 6 0x34 0x84 > 0xe2 Ah, that looks better, that looks more like what I would expect as settings from the firmware, so it seems you have succeeded in getting the settings reset to the firmware defaults. If you now do load the axp288_adc driver, I expect register 0x82 to stay as is and 0x84 to change to 0xe3 (which is fine). Can you confirm this? And can you try charging the tablet without manually changing the registers and see if charging works normally ? (with the axp288_adc driver loaded) If charging seems to work fine, it would be also be interesting to see what charging does when running firefox ?
Ok so after enabling 'axp288_adc' I have these. sudo i2cget -y -f 6 0x34 0x82 0xf1 sudo i2cget -y -f 6 0x34 0x84 0xe3 The issue is the tablet starts blinking with only Gnomme and terminal on screen. When I plug in to charge Gnome plays a sound as if something is connected but the battery status doesn't show any charging occurring.
It did eventually start charging after letting it sit, I don't know why or what is causing it to not charge sometimes or blink when not even plugged in.
(In reply to Lance G. from comment #18) > It did eventually start charging after letting it sit, I don't know why or > what is causing it to not charge sometimes or blink when not even plugged in. Could it be that the blinking has 2 functions: 1) low battery indication (when no charger plugged in) 2) not charging due to tablet to hot indication (when charger plugged in) IOW, maybe it only blinks without the charger when the battery is below a certain threshold ? Other then that I'm starting to think that maybe my initial hunch here was correct and that we need to set register 0x84 to 0xf3 (from 0xe3) to set the bias current to 80 ųA on your tablet. Can you try doing: i2cset -y -f 6 0x34 0x84 0xf3 and see if that makes things work better?
(In reply to Hans de Goede from comment #19) > Could it be that the blinking has 2 functions: > > 1) low battery indication (when no charger plugged in) > 2) not charging due to tablet to hot indication (when charger plugged in) > > IOW, maybe it only blinks without the charger when the battery is below a > certain threshold ? > I should note that the blinking occurs even when the tablet is near 100% battery but not actually plugged into anything. > Other then that I'm starting to think that maybe my initial hunch here was > correct and that we need to set register 0x84 to 0xf3 (from 0xe3) to set the > bias current to 80 ųA on your tablet. Can you try doing: > > i2cset -y -f 6 0x34 0x84 0xf3 > > and see if that makes things work better? Ok this helps it seems. Test case was unplugging after a full charge. A few minutes after logging into Gnome I started seeing the blinking red light, tablet reported 97% battery left. I also found the tablet would not bother charging when plugged in at this point. I had these from the two i2c registers. sudo i2cget -y -f 6 0x34 0x82 0xf1 sudo i2cget -y -f 6 0x34 0x84 0xe3 Immediately after setting the workaround 'sudo i2cset -y -f 6 0x34 0x84 0xf3' the tablet stopped blinking and when plugged in after this it also appeared to charge. Gnome's battery icon changing to a charging one. I think this workaround fixes my issue. For my particular tablet seems things work best when '0x82' is '0xf1' and '0x84' is '0xf3'.
An additional question, I have one of those angled micro-b USB OTG adapters that have a port for providing power. Seems like my tablet accepts power from this, but maybe not enough to really charge. It lights up when this is plugged in with power but I don't hear any chime or see the battery icon switch to a charging icon in Gnome. Do you think that's okay/safe if it gets power this way while OTG is active?
(In reply to Lance G. from comment #20) > Immediately after setting the workaround 'sudo i2cset -y -f 6 0x34 0x84 > 0xf3' the tablet stopped blinking and when plugged in after this it also > appeared to charge. Gnome's battery icon changing to a charging one. > > I think this workaround fixes my issue. For my particular tablet seems > things work best when '0x82' is '0xf1' and '0x84' is '0xf3'. Ok, so it seems that your tablet needs to be added to the quirk list for devices which need the temp-sensor bias-current overridden to 80ųA. In order to add your tablet to this list I need to know the DMI strings of the tablet. Please run: grep . /sys/class/dmi/id/* 2>/dev/null And copy and paste the output here.
(In reply to Lance G. from comment #21) > An additional question, I have one of those angled micro-b USB OTG adapters > that have a port for providing power. Seems like my tablet accepts power > from this, but maybe not enough to really charge. It lights up when this is > plugged in with power but I don't hear any chime or see the battery icon > switch to a charging icon in Gnome. Do you think that's okay/safe if it gets > power this way while OTG is active? Yes that should be safe.
(In reply to Hans de Goede from comment #22) > Please run: > > grep . /sys/class/dmi/id/* 2>/dev/null > > And copy and paste the output here. Here it is. /sys/class/dmi/id/bios_date:12/30/2016 /sys/class/dmi/id/bios_release:5.11 /sys/class/dmi/id/bios_version:JK-BI-10-HLK10CR100-C34A-101-I /sys/class/dmi/id/board_asset_tag:Default string /sys/class/dmi/id/board_name:Cherry Trail CR /sys/class/dmi/id/board_vendor:TMAX /sys/class/dmi/id/board_version:Default string /sys/class/dmi/id/chassis_asset_tag:Default string /sys/class/dmi/id/chassis_type:3 /sys/class/dmi/id/chassis_vendor:Default string /sys/class/dmi/id/chassis_version:Default string /sys/class/dmi/id/modalias:dmi:bvn:bvrJK-BI-10-HLK10CR100-C34A-101-I:bd12/30/2016:br5.11:svnTMAX:pnTM101W610L:pvrDefaultstring:rvnTMAX:rnCherryTrailCR:rvrDefaultstring:cvnDefaultstring:ct3:cvrDefaultstring:skuDefaultstring: /sys/class/dmi/id/product_family:Default string /sys/class/dmi/id/product_name:TM101W610L /sys/class/dmi/id/product_sku:Default string /sys/class/dmi/id/product_version:Default string /sys/class/dmi/id/sys_vendor:TMAX /sys/class/dmi/id/uevent:MODALIAS=dmi:bvn:bvrJK-BI-10-HLK10CR100-C34A-101-I:bd12/30/2016:br5.11:svnTMAX:pnTM101W610L:pvrDefaultstring:rvnTMAX:rnCherryTrailCR:rvrDefaultstring:cvnDefaultstring:ct3:cvrDefaultstring:skuDefaultstring:
Thanks, I've submitted a patch upstream which (once merged) will make the kernel automatically change register 0x84 from 0xe3 to 0xf3 : https://lore.kernel.org/linux-iio/20220506095040.21008-1-hdegoede@redhat.com/