Bug 196701

Summary: no battery info on thinkpad tablet 10
Product: Drivers Reporter: Stefan Assmann (sassmann)
Component: I2CAssignee: Zhang Rui (rui.zhang)
Status: CLOSED INSUFFICIENT_DATA    
Severity: normal CC: andy.shevchenko, lv.zheng, rui.zhang, youling257
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 4.13.0-0.rc5 Subsystem:
Regression: No Bisected commit-id:
Attachments: dmesg.txt
acpidata.dat
output of grep -H 15 /sys/bus/acpi/devices/*/status
dmesg from Lenovo Miix2 8
dsdt.dsl from Lenovo Miix2 8
output of grep -H 15 /sys/bus/acpi/devices/*/status from Lenovo Miix2 8
ThinkPad 8 z3795
dmesg from Lenovo Miix2 8

Description Stefan Assmann 2017-08-18 11:40:19 UTC
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.
Comment 1 Stefan Assmann 2017-08-18 11:41:55 UTC
Created attachment 258011 [details]
acpidata.dat
Comment 2 Stefan Assmann 2017-11-29 11:33:13 UTC
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?
Comment 3 Zhang Rui 2017-12-18 02:35:11 UTC
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?
Comment 4 Zhang Rui 2017-12-18 02:35:46 UTC
BTW, I should ask this question first, does the problem still exist in the latest upstream kernel?
Comment 5 Stefan Assmann 2018-01-02 14:44:11 UTC
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.
Comment 6 Andy Shevchenko 2018-01-03 19:32:37 UTC
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.
Comment 7 Stefan Assmann 2018-01-04 07:40:35 UTC
Created attachment 273395 [details]
output of grep -H 15 /sys/bus/acpi/devices/*/status
Comment 8 RussianNeuroMancer 2018-03-08 15:52:34 UTC
Created attachment 274623 [details]
dmesg from Lenovo Miix2 8

Exactly same issue on Lenovo Miix2 8, dmesg from Linux 4.16rc4 is attached.
Comment 9 RussianNeuroMancer 2018-03-08 15:53:05 UTC
Created attachment 274625 [details]
dsdt.dsl from Lenovo Miix2 8
Comment 10 RussianNeuroMancer 2018-03-08 15:54:56 UTC
Created attachment 274627 [details]
output of grep -H 15 /sys/bus/acpi/devices/*/status from Lenovo Miix2 8
Comment 11 youling257 2018-03-18 06:46:06 UTC
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
Comment 12 youling257 2018-03-18 06:48:22 UTC
Created attachment 274799 [details]
ThinkPad 8 z3795
Comment 13 RussianNeuroMancer 2018-04-07 09:07:41 UTC
Andy, is there anything we could provide to help find root cause of the issue?
Comment 14 RussianNeuroMancer 2018-07-31 12:07:25 UTC
Created attachment 277627 [details]
dmesg from Lenovo Miix2 8

Still reproducible with Linux 4.18rc7, new dmesg attached.
Comment 15 Andy Shevchenko 2018-08-01 18:34:55 UTC
(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.
Comment 16 RussianNeuroMancer 2018-08-10 16:47:49 UTC
youling257, please check https://github.com/jwrdegoede/linux-sunxi/commit/58643cc9aa27b792eb910327dc19f83ba80569f1
Comment 17 youling257 2018-08-10 18:17:09 UTC
(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.
Comment 18 RussianNeuroMancer 2018-08-14 16:13:07 UTC
> 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.
Comment 19 Andy Shevchenko 2019-05-13 17:42:47 UTC
That commit is no more exist. Did it make upstream? Does vanilla work now flawlessly in the sense of the subject?
Comment 20 Andy Shevchenko 2020-10-12 14:30:22 UTC
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.