Bug 196701

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.