Created attachment 258009 [details] dmesg.txt There's no battery info on thinkpad tablet 10, this is a baytrail tablet. Dmesg shows multiple [ 0.403022] i2c i2c-0: i2c read failed Tracing that back to the source we end up in acpi_gsb_i2c_read_bytes() I assume this might be related to the missing battery info. ACPI battery is somewhat detected [ 3.182363] ACPI: Battery Slot [BAT0] (battery absent) The battery is present indeed. Attaching full dmesg, let me know what else you need.
Created attachment 258011 [details] acpidata.dat
Battery is still reported as absent in 4.15-rc1. Looking at the dsdt. \_SB.I2C1.BAT0._STA Method (_STA, 0, NotSerialized) // _STA: Status { If (AVBL) { Acquire (CFMZ, 0xFFFF) ECNR (0xF0) Local0 = (ECR0 & One) If (Local0) { Release (CFMZ) Return (0x1F) } Else { Sleep (0x0A) ECNR (0xF0) Local0 = (ECR0 & One) If (Local0) { Release (CFMZ) Return (0x1F) } Else { Release (CFMZ) Return (0x0F) } } } Return (0x1F) } the only case where the battery is returned as not present (0x0f) is when Local0 is 0, which depends on ECR0. The init of ECR0 happens in \_SB.I2C1.BAT0.EC00 Method (EC00, 0, NotSerialized) { [...] ECR0 = Zero [...] } which is called by ECNR in _STA. Listing ECNR Method (ECNR, 1, NotSerialized) { Acquire (CFMX, 0xFFFF) EC00 () ECD0 = 0x80 ECD1 = Arg0 ECWR = I2CW = ECWR /* \_SB_.I2C1.BAT0.ECWR */ If ((ECST == Zero)) { ECRD = I2CR /* \_SB_.I2C1.I2CR */ } Release (CFMX) Sleep (0x02) } This looks like a I2C bus read is issued which probably updates ECR0. Question is how can I figure out where things go astray. How can I debug these ACPI methods and figure out what's read from the I2C bus?
First of all, there are two ACPI battery devices according to the acpidump. 1. \_SB.I2C1.BATC 2. \_SB.I2C1.BAT0 For BAT0, OperationRegion (ERAM, GenericSerialBus, Zero, 0x0100) Field (ERAM, BufferAcc, NoLock, Preserve) { Connection (ENE3), Offset (0x01), AccessAs (BufferAcc, AttribBytes (0x06)), I2CR, 8, AccessAs (BufferAcc, AttribBytes (0x05)), I2CW, 8 } it writes to I2CW and get status from I2CR. For BATC, OperationRegion (DVUM, GenericSerialBus, Zero, 0x0100) Field (DVUM, BufferAcc, NoLock, Preserve) { Connection (UMPC), AccessAs (BufferAcc, AttribBytes (0x39)), FGC0, 8 } it reads from FGC0 to get the battery status. I don't know which ACPI Battery device should work, but to me [ 0.403022] i2c i2c-0: i2c read failed [ 0.442121] i2c i2c-0: i2c read failed [ 0.465911] i2c i2c-0: i2c read failed [ 0.502087] i2c i2c-0: i2c read failed [ 0.525812] i2c i2c-0: i2c read failed [ 0.561081] i2c i2c-0: i2c read failed [ 0.584776] i2c i2c-0: i2c read failed [ 0.621078] i2c i2c-0: i2c read failed [ 0.644644] i2c i2c-0: i2c read failed [ 0.680079] i2c i2c-0: i2c read failed [ 0.703609] i2c i2c-0: i2c read failed [ 0.739076] i2c i2c-0: i2c read failed [ 0.762547] i2c i2c-0: i2c read failed these are probably the battery status read failure. I'd suggest we get the I2C failure resolved first and see if the battery is back. Andy, could you take a look at the I2C issues first?
BTW, I should ask this question first, does the problem still exist in the latest upstream kernel?
Thanks for taking a look! According to https://forums.lenovo.com/t5/Linux-Discussion/Linux-on-Thinkpad-Tablet-10/td-p/3396025 the BATC is just a leftover from the reference implementation and should be ignored. BAT0 is the real deal. There's also a link to a userspace tool that talks to BAT0 via i2c. http://www.id3p.de/gitweb/?p=tpt10-bat.git;a=summary Last kernel I tested was 4.15-rc1, I did a quick test on 4.15.0-rc6 and that behaves exactly the same.
Can you attach output of % grep -H 15 /sys/bus/acpi/devices/*/status ? It would be interesting to see if they both have status 15. WRT i2c failures I would think that it's related to wrong battery choice.
Created attachment 273395 [details] output of grep -H 15 /sys/bus/acpi/devices/*/status
Created attachment 274623 [details] dmesg from Lenovo Miix2 8 Exactly same issue on Lenovo Miix2 8, dmesg from Linux 4.16rc4 is attached.
Created attachment 274625 [details] dsdt.dsl from Lenovo Miix2 8
Created attachment 274627 [details] output of grep -H 15 /sys/bus/acpi/devices/*/status from Lenovo Miix2 8
ThinkPad 8 z3795，build kernel with tpt10 battery driver，/sys/class/power_supply/BAT0，battery state normal，but can't charging. https://www.dpin.de/downloads/tpt10/patches/lk4.15-nf-acpi.diff
Created attachment 274799 [details] ThinkPad 8 z3795
Andy, is there anything we could provide to help find root cause of the issue?
Created attachment 277627 [details] dmesg from Lenovo Miix2 8 Still reproducible with Linux 4.18rc7, new dmesg attached.
(In reply to RussianNeuroMancer from comment #14) > Created attachment 277627 [details] > dmesg from Lenovo Miix2 8 > > Still reproducible with Linux 4.18rc7, new dmesg attached. I don't see any I2C issues, so, back to Rui.
youling257, please check https://github.com/jwrdegoede/linux-sunxi/commit/58643cc9aa27b792eb910327dc19f83ba80569f1
(In reply to RussianNeuroMancer from comment #16) > youling257, please check > https://github.com/jwrdegoede/linux-sunxi/commit/ > 58643cc9aa27b792eb910327dc19f83ba80569f1 That is i want to you check it for your miix2 8. Hans bought ThinkPad 8 for develop. i have never has ThinkPad 8，i found phoenixstudio chinese forum PhoenixOS users has ThinkPad 8.
> That is i want to you check it for your miix2 8. With this patch battery is detected and report level properly on Lenovo Miix2 8.
That commit is no more exist. Did it make upstream? Does vanilla work now flawlessly in the sense of the subject?
I'm about to close this bug since nobody appear to test and confirm the state. So I leave it in need info state for a while (day or two) and then close.