Bug 88471 - Bogus battery information on Teclast X98 Air 3G (Baytrail-T)
Summary: Bogus battery information on Teclast X98 Air 3G (Baytrail-T)
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: drivers_other
URL:
Keywords:
: 100411 101161 109741 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-11-18 21:06 UTC by Fabian Zaremba
Modified: 2017-04-01 08:53 UTC (History)
31 users (show)

See Also:
Kernel Version: 3.18-rc5
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg from 3.18rc5 on Teclast X98 Air 3G (60.16 KB, text/plain)
2014-11-18 21:06 UTC, Fabian Zaremba
Details
Used kernel configuration (159.43 KB, text/plain)
2014-11-18 21:07 UTC, Fabian Zaremba
Details
cat /sys/class/power_supply/BMBT/uevent (304 bytes, text/plain)
2014-11-18 21:14 UTC, Fabian Zaremba
Details
Output of `acpidump > acpidump.out` (381.73 KB, application/octet-stream)
2014-11-18 21:27 UTC, Fabian Zaremba
Details
dmesg from 3.19-rc2 on Teclast X98 Air 3G (45.06 KB, text/plain)
2015-01-05 14:28 UTC, Fabian Zaremba
Details
dmesg from patched 3.19-rc2 on Teclast X98 Air 3G (43.10 KB, text/plain)
2015-01-05 14:28 UTC, Fabian Zaremba
Details
dmesg of kernel 4.1.0 (60.49 KB, text/plain)
2015-06-27 16:24 UTC, Laszlo Fiat
Details
config of kernel 4.1.0 (163.30 KB, application/octet-stream)
2015-06-27 16:26 UTC, Laszlo Fiat
Details
attachment-1893-0.html (4.81 KB, text/html)
2016-05-12 08:34 UTC, Dmitriy Beykun
Details
Patch AXP288 (2.53 KB, patch)
2016-11-18 15:10 UTC, sfumato1977
Details | Diff
make volatile axp20x_fg_res patch (335 bytes, patch)
2016-11-20 16:26 UTC, RussianNeuroMancer
Details | Diff
AXP288 fixes (15.56 KB, patch)
2016-11-22 16:48 UTC, Laszlo Fiat
Details | Diff
BMOP opregion driver - PoC - do NOT use (16.13 KB, patch)
2016-12-16 16:13 UTC, Sergei Trusov
Details | Diff
DEXP Z110 *patched* DSDT (587.07 KB, text/plain)
2016-12-16 16:25 UTC, Sergei Trusov
Details
dmesg after running Hans de Goede's branch on a Z8300 laptop (55.55 KB, text/plain)
2016-12-23 20:55 UTC, Taha
Details
attachment-11392-0.html (1.23 KB, text/html)
2017-01-18 11:43 UTC, Icenowy Zheng
Details
attachment-11870-0.html (1.01 KB, text/html)
2017-03-07 15:48 UTC, Icenowy Zheng
Details
Patch hide_phantom_batteries (1.34 KB, patch)
2017-03-08 14:29 UTC, alan
Details | Diff
dual os Android (652.51 KB, image/png)
2017-03-11 12:28 UTC, youling257
Details
4.11 kernel lineage os (113.57 KB, image/png)
2017-03-11 12:39 UTC, youling257
Details

Description Fabian Zaremba 2014-11-18 21:06:33 UTC
Created attachment 158041 [details]
dmesg from 3.18rc5 on Teclast X98 Air 3G

The tablet is based on Bay Trail-T Z3736F - power regulator and similar hardware is reported by BIOS/EFI menu as "XPowers integrated" (without model information).

I do get readings quite similar to the one from a real battery/AC from /sys/class/power_supply/BMBT/uevent, but they lack proper informations on actual charge level (reporting 100% and no actual numbers until the battery dies).

You can find my DSDT attached as binary here: https://bugzilla.kernel.org/attachment.cgi?id=157121
I uploaded `iasl -d DSDT.dat` decompiled output to clbin: https://clbin.com/MiZug

My dmesg log, my used kernel config & the reading from /sys are attached to this bug report.

I also tried to apply patch from bug #69011 (since the hardware is similar) and activated CONFIG_I2C_ACPI_OPREGION in kernel config, but nothing helped.
Hardware of this tablet is also similar to the tablet in bug #83941, but I do not get any hard ACPI errors.
Comment 1 Fabian Zaremba 2014-11-18 21:07:59 UTC
Created attachment 158051 [details]
Used kernel configuration
Comment 2 Fabian Zaremba 2014-11-18 21:14:54 UTC
Created attachment 158061 [details]
cat /sys/class/power_supply/BMBT/uevent
Comment 3 Fabian Zaremba 2014-11-18 21:27:21 UTC
Created attachment 158071 [details]
Output of `acpidump > acpidump.out`
Comment 4 Aaron Lu 2014-12-23 05:39:16 UTC
commit 40e7fcb19293cbdff02c74cb0668413480f82ea1
Author: Lan Tianyu <tianyu.lan@intel.com>
Date:   Sun Nov 23 21:22:54 2014 +0800

    ACPI: Add _DEP support to fix battery issue on Asus T100TA

This commit may matter, can you please try v3.19-rc1?
Comment 5 Lan Tianyu 2014-12-23 06:06:34 UTC
Could you try the following patch?

diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c
index b14c045..c7b84dd 100644
--- a/drivers/gpio/gpiolib-acpi.c
+++ b/drivers/gpio/gpiolib-acpi.c
@@ -546,6 +546,8 @@ static void acpi_gpiochip_request_regions(struct acpi_gpio_chip *achip)
 						    NULL, achip);
 	if (ACPI_FAILURE(status))
 		dev_err(chip->dev, "Failed to install GPIO OpRegion handler\n");
+
+	acpi_walk_dep_device_list(handle);
 }
 
 static void acpi_gpiochip_free_regions(struct acpi_gpio_chip *achip)
Comment 6 Fabian Zaremba 2015-01-05 14:26:00 UTC
(In reply to Lan Tianyu from comment #5)
> Could you try the following patch?

I just tried v3.19-rc2 without additional patching and with your patch.

Without your patch, nothing seemed to have changed (bogus battery information stays the same).
With your patch some additional errors regarding ACPI/AC-Adapter appeared in dmesg, but the SDIO RTL8723 WiFi card stopped working (driver does not seem to recognize the card anymore). Unfortunately, nothing changed regarding the battery information.

Please note that I am using a patch by Jon Pry to make the SDHCI card work - I adapted it to work on 3.19: https://clbin.com/WNPPV

I will attach the new dmesg (with and without your patch applied) here.
Comment 7 Fabian Zaremba 2015-01-05 14:28:04 UTC
Created attachment 162511 [details]
dmesg from 3.19-rc2 on Teclast X98 Air 3G

Without the patch proposed in comment #5
Comment 8 Fabian Zaremba 2015-01-05 14:28:59 UTC
Created attachment 162521 [details]
dmesg from patched 3.19-rc2 on Teclast X98 Air 3G

Including patch from comment #5
Comment 9 Aaron Lu 2015-06-17 07:58:09 UTC
I have a Teclast X98 air II, but I can't boot the USB based Linux since the USB hub somehow doesn't work during Linux boot phase(it does work during BIOS phase or I can't load Linux kernel from the USB drive).

Can you please check if you have CONFIG_AXP288_FUEL_GAUGE set in your kernel config?
Comment 10 Laszlo Fiat 2015-06-27 16:22:03 UTC
I have tried on a Teclast X80h with vanilla 4.1.0 kernel (no patches) with CONFIG_AXP288_FUEL_GAUGE set to Y, but the result is the same:

cat /sys/class/power_supply/BMBT/uevent 
POWER_SUPPLY_NAME=BMBT
POWER_SUPPLY_STATUS=Unknown
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_CAPACITY=100
POWER_SUPPLY_CAPACITY_LEVEL=Low
POWER_SUPPLY_MODEL_NAME=SR Real Battery
POWER_SUPPLY_MANUFACTURER=SR 1
POWER_SUPPLY_SERIAL_NUMBER=Intel 

I attach a dmesg, and a kernel config I used. I can try again with any patches.
Comment 11 Laszlo Fiat 2015-06-27 16:24:37 UTC
Created attachment 181081 [details]
dmesg of kernel 4.1.0
Comment 12 Laszlo Fiat 2015-06-27 16:26:30 UTC
Created attachment 181091 [details]
config of kernel 4.1.0
Comment 13 Aaron Lu 2015-07-06 02:54:52 UTC
*** Bug 100411 has been marked as a duplicate of this bug. ***
Comment 14 Kevin 2015-07-06 06:25:27 UTC
(In reply to Aaron Lu from comment #13)
> *** Bug 100411 has been marked as a duplicate of this bug. ***

Since my bug report has been marked as duplicate of this bug, is there anything I should/can do here? Should/Can I post logs here on the latest kernels? How can I help? :)
Comment 15 Aaron Lu 2015-07-06 08:14:13 UTC
Thanks Kevin, but no logs are needed at this moment.
We know what the problem is: the ACPI based battery doesn't work because there is a customized BMOP operation region that Linux doesn't support yet; for the native fuel gauge driver, its probe function will fail due to lacking platform data and it's not clear how the platform data should be provided and by who.
Comment 16 Herbert 2015-07-31 11:51:26 UTC
Hi at all.

Any updates in this case?

Thank you in advance.

Regards,
Herbert
Comment 17 Aaron Lu 2015-08-11 18:48:48 UTC
Cc David.
Comment 18 Aaron Lu 2015-08-24 08:08:45 UTC
*** Bug 101161 has been marked as a duplicate of this bug. ***
Comment 19 beta992 2015-08-24 10:03:10 UTC
(In reply to Aaron Lu from comment #15)
> Thanks Kevin, but no logs are needed at this moment.
> We know what the problem is: the ACPI based battery doesn't work because
> there is a customized BMOP operation region that Linux doesn't support yet;
> for the native fuel gauge driver, its probe function will fail due to
> lacking platform data and it's not clear how the platform data should be
> provided and by who.

Thanks for the information. :)

Are there no workarounds? Like injecting a custom DSDT with the correct tables/data?
Comment 20 Aaron Lu 2015-08-25 01:25:10 UTC
(In reply to beta992 from comment #19)
> Are there no workarounds? Like injecting a custom DSDT with the correct
> tables/data?

No workaround available yet, sorry.
Comment 21 Kevin 2015-09-08 17:45:05 UTC
In 4.2 kernel, I'm getting :

....
[    3.223313] i2c_designware 80860F41:04: I2C bus managed by PUNIT
[    3.231650] axp20x i2c-INT33F4:00: AXP20x variant AXP288 found
[    3.430691] axp288_extcon axp288_extcon: failed to get platform data
[    3.434509] axp288_charger axp288_charger: failed to get platform data
[    3.438744] axp20x i2c-INT33F4:00: AXP20X driver loaded
[    3.441318] ACPI: Battery Slot [BMBT] (battery present)
[    3.441477] [Firmware Bug]: No valid trip found
....


Since the axp288 seems to be related to power and charging, is this related to this bug? Or should I create a new bug report in Power-Others ?
Comment 22 Aaron Lu 2015-09-09 01:12:33 UTC
Yes, it is related. The axp288_charger and axp288_fuel_gauge driver are supposed to provide information for AC and battery if I'm not mistaken and as you can see, the platform_data field is missing so the drivers don't work. Looks like it is the same thing for other axp288_*(e.g. axp288_extcon) drivers too.
Comment 23 beta992 2015-09-09 08:14:25 UTC
@Aaron Lu: sorry for asking, but does Android have support for BMOP?
I have tried searching on it, but couldn't find any information.
If so, maybe it could be ported to Linux. :)
Comment 24 Aaron Lu 2015-09-09 08:50:04 UTC
AFAIK, android doesn't make use of ACPI to get battery information, instead, they use driver to directly poke the hardware as axp288_xxx driver does. I think the only difference is that in Android's tree, the platform_data is initialized and set somehow.
Comment 25 Dmitriy Beykun 2015-09-26 13:56:27 UTC
Aaron,

> it's not clear how the platform data should be provided and by who.
> is that in Android's tree, the platform_data is initialized and set somehow.

like this?
https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.10/tree/arch/x86/platform/byt/byt-board.c?h=valleyisland-io-4.0

we even have same for Medfield/Merrifield in mainline: arch/x86/platform/intel-mid


Could you, please, contact Intel yocto developers and ask them about mainlining proper ACPI support for Baytrail?

BR,
Dmitriy Beykun
Comment 26 sfumato1977 2015-09-26 16:14:51 UTC
I temporarily "resolved" 

load module test_power.ko


i2cget -f -y 4        0x34        0xB9

                   (axp288) (percentage reg)

and a script every 10 seconds
He writes

echo (percentage_reg-128) >/sys/module/test_power/parameters/battery_capacity


I'm not good with kernel modules .
someone more skilled could create something less barbaric?

thank you. sorry for my English
Comment 27 sfumato1977 2015-09-26 16:41:21 UTC
I forgot and maybe a new firmware for Intel Atom Z3735F audio codec on ​​SPI1
Thank you
Umberto I.
Comment 28 Aaron Lu 2015-09-28 01:26:26 UTC
(In reply to Dmitriy Beykun from comment #25)
> Aaron,
> 
> > it's not clear how the platform data should be provided and by who.
> > is that in Android's tree, the platform_data is initialized and set
> somehow.
> 
> like this?
> https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.10/tree/arch/x86/
> platform/byt/byt-board.c?h=valleyisland-io-4.0

That doesn't seem help as the above code did somethong for SPI while the driver here is about a cell device from the AXP288 PMIC.
Comment 29 Dmitriy Beykun 2015-09-28 09:29:26 UTC
> That doesn't seem help as the above code did somethong for SPI while the
> driver here is about a cell device from the AXP288 PMIC.

Yes, but bug here is about missing battery data on Baytrail-T platforms. Doesn't matter how are we going to get the data.

Is declaring another x86 platform for Baytrail-T an option? I honestly don't remember if this is allowed at x86 right now, if allowed at all.

I was thinking that because BMOP region support needs linux-acpi approval and time to implement, but there are actual users of Baytrail-T hardware, we could make axp288_adc/fuel_gague work for them directly without proper ACPI driver, since we have the IIO drivers.

Correct me if I'm wrong.

BR,
Dmitriy Beykun
Comment 30 Aaron Lu 2015-09-29 02:33:54 UTC
(In reply to Dmitriy Beykun from comment #29)
> > That doesn't seem help as the above code did somethong for SPI while the
> driver here is about a cell device from the AXP288 PMIC.
> 
> Yes, but bug here is about missing battery data on Baytrail-T platforms.
> Doesn't matter how are we going to get the data.

Agreed.

> 
> Is declaring another x86 platform for Baytrail-T an option? I honestly don't
> remember if this is allowed at x86 right now, if allowed at all.

I don't quite understand the above words.

The platform_data I memtioned in comment #15 is the companion data of the fuel_gauge cell device, which contains information about how to convert the raw readings of the sensor to temperature. Such information is supposed to be:
1 provided by firmware;
2 hard coded in driver.
Our current axp288/fuel_gauge driver expects 1 while the firmware doesn't provide that information...

> 
> I was thinking that because BMOP region support needs linux-acpi approval
> and time to implement, but there are actual users of Baytrail-T hardware, we
> could make axp288_adc/fuel_gague work for them directly without proper ACPI
> driver, since we have the IIO drivers.

We can get the raw readings, but we don't know how to convert that into temperatures(see temp_to_adc/adc_to_temp in drivers/power/axp288_fuel_gauge.c). And the fuel_gauge's platform_data seems to be also required for some other purposes in that driver.
Comment 31 Icenowy Zheng 2015-10-23 13:05:22 UTC
(In reply to Aaron Lu from comment #9)
> I have a Teclast X98 air II, but I can't boot the USB based Linux since the
> USB hub somehow doesn't work during Linux boot phase(it does work during
> BIOS phase or I can't load Linux kernel from the USB drive).
> 
> Can you please check if you have CONFIG_AXP288_FUEL_GAUGE set in your kernel
> config?

P.S. Maybe you are using the Android UEFI, which needs the patch usb-make-xhci-platform-driver-use-64-bit-or-32-bit-D.patch ( can be retrieve on AOSC kernel patches, https://github.com/AOSC-Dev/aosc-os-abbs/raw/staging/extra-kernel/linux-kernel-aosc-main/autobuild/patches/0008-usb-make-xhci-platform-driver-use-64-bit-or-32-bit-D.patch)
or You can just flash in the UEFI for Windows(I choose the latter on my X989 Air 3G)
Comment 32 Icenowy Zheng 2015-10-23 13:05:45 UTC
(In reply to Icenowy Zheng from comment #31)
> (In reply to Aaron Lu from comment #9)
> > I have a Teclast X98 air II, but I can't boot the USB based Linux since the
> > USB hub somehow doesn't work during Linux boot phase(it does work during
> > BIOS phase or I can't load Linux kernel from the USB drive).
> > 
> > Can you please check if you have CONFIG_AXP288_FUEL_GAUGE set in your
> kernel
> > config?
> 
> P.S. Maybe you are using the Android UEFI, which needs the patch
> usb-make-xhci-platform-driver-use-64-bit-or-32-bit-D.patch ( can be retrieve
> on AOSC kernel patches,
> https://github.com/AOSC-Dev/aosc-os-abbs/raw/staging/extra-kernel/linux-
> kernel-aosc-main/autobuild/patches/0008-usb-make-xhci-platform-driver-use-64-
> bit-or-32-bit-D.patch)
> or You can just flash in the UEFI for Windows(I choose the latter on my X989
> Air 3G)

Sorry for the extra 9, it's X98 Air 3G
Comment 33 Aaron Lu 2015-12-22 05:26:06 UTC
*** Bug 109741 has been marked as a duplicate of this bug. ***
Comment 34 Kevin 2016-02-24 04:44:38 UTC
Hi,
Is there any progress regarding this bug? Should I compile the new kernel and check?

Thanks

Kevin
Comment 35 RussianNeuroMancer 2016-03-20 19:49:14 UTC
Seems like same issue with DEXP Ursus 7W tablet (and probably other DEXP Ursus BayTrail-based tablets/laptops).
Comment 36 sfumato1977 2016-03-20 20:46:03 UTC
For The Moment , a "solution " is to run this script found here axpd.sh https://github.com/Icenowy/axpd

I tried , to contact the authors , the axp288_fuel_gauge.c driver . But I have not yet had a response .
in between I tried alone to create a " Frankestain " driver , 
joining two  driver axp20x.c and test_power.c
I was able to reveal the chip "axp288" to set the percentage of power and etc .. 
but I'm not a professional programmer and do not know how to make him repeat continuously.
As soon as I try to create a loop routine my driver would send crach the kernel .
Comment 37 Louan du Toit 2016-03-23 11:27:17 UTC
Hi, correct me if I'm wrong, but the main issue seems to be with the "platform data". Is that not supplied via your PC's DSDT file? If so, then it's got nothing to do with the kernel, but with the PC manufacturer and the information they supply via the BIOS/EFI?
Comment 38 RussianNeuroMancer 2016-03-23 14:12:15 UTC
Louan du Toit, check comment #15.
Comment 39 MCassaniti 2016-05-12 07:12:42 UTC
I'm also finding it difficult to get my BayTrail tablet to work correctly when it comes to charging. For the record I have a HP Stream7 and a Pendo 10.1 Windows tablet. The Stream will give correct battery capacity via ACPI, but no AC adapter (it's USB charge only). The Pendo gives 100% charge always, but lists an AC adapter. I didn't see the AC adapter state changing when connecting the AC adapter.

AFAIK the X-Powers AXP288 chip was specifically designed for the BayTrail SoC, so it may be a requirement to only support the AXP288 on a BayTrail SoC and not other platforms.

Reading through the 4.5 code shows that following information is expected to be provided by firmware:

 - [axp288_charger]: The maximum current and voltage used, and the default current and voltage used (fallback if maximum is missing)
 - [extcon_axp288]: The GPIO pin used to switch USB D+/D- lines between the PMIC and the SoC
 - [axp288_fuel_gauge]: The minimum and maximum voltages, minimum and maximum temperatures, two capacity values, an ocv curve, a thermistor curve and a parameter for the thermistor curve

I believe that the platform may be able to provide a method to switch the USB lines when the axp288_pmic driver is in use.

The layout of drivers is somewhat along the following lines:

 - The axp288_charger driver registers a USB power supply and will correctly report an online/off-line status, apart from other details
 - The axp288_fuel_gauge driver registers a battery power supply and will correctly return a battery status by querying the PMIC driver, apart from other details
 - The extcon_axp288 driver is (from what I understand) designed to get an interrupt when the OTG USB port is externally powered (device mode) and change the USB lines
 - The intel_pmic_xpower driver leverages an ACPI operation region to (from what I understand) query select values
 - The axp288_adc driver seems to be what the PMIC is actually querying to get a lot of its values

If I understand it all correctly, the intel_pmic_xpower driver should be able to successfully query the platform for the values required. The intel_pmic_xpower driver does not however fill the data structures that other drivers need filled.

Can I propose that the charger driver defaults values be filled when the structure is declared, which would enable part of the USB charging functionality. This still means the GPIO pin details are unknown, but getting that information populated through the PMIC driver should allow USB charging.

It may make more sense to statically set almost all values for a BayTrail SoC platform except the GPIO pin, but I honestly don't know. I do intend to contact the driver developers again soon and see what I can find out.
Comment 40 Dmitriy Beykun 2016-05-12 08:34:02 UTC
Created attachment 216051 [details]
attachment-1893-0.html

2016-05-12 10:12 GMT+03:00 <bugzilla-daemon@bugzilla.kernel.org>:

> https://bugzilla.kernel.org/show_bug.cgi?id=88471
>
> michael@cassaniti.id.au changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |michael@cassaniti.id.au
>
> --- Comment #39 from michael@cassaniti.id.au ---
> I'm also finding it difficult to get my BayTrail tablet to work correctly
> when
> it comes to charging. For the record I have a HP Stream7 and a Pendo 10.1
> Windows tablet. The Stream will give correct battery capacity via ACPI,
> but no
> AC adapter (it's USB charge only). The Pendo gives 100% charge always, but
> lists an AC adapter. I didn't see the AC adapter state changing when
> connecting
> the AC adapter.
>
> AFAIK the X-Powers AXP288 chip was specifically designed for the BayTrail
> SoC,
> so it may be a requirement to only support the AXP288 on a BayTrail SoC
> and not
> other platforms.
>

AXP288 is indeed designed for Baytrail, but it is a fairly standard AXP
chip very similar to many other AXP chips used in Allwinner tablets for
years.
We have gpio/regulators support for AXP2xx in drivers/.

Intel failed to provide manpower to wire that properly and instead created
a set of external drivers you list below.


>
> Reading through the 4.5 code shows that following information is expected
> to be
> provided by firmware:
>
>  - [axp288_charger]: The maximum current and voltage used, and the default
> current and voltage used (fallback if maximum is missing)
>  - [extcon_axp288]: The GPIO pin used to switch USB D+/D- lines between the
> PMIC and the SoC
>  - [axp288_fuel_gauge]: The minimum and maximum voltages, minimum and
> maximum
> temperatures, two capacity values, an ocv curve, a thermistor curve and a
> parameter for the thermistor curve
>
> I believe that the platform may be able to provide a method to switch the
> USB
> lines when the axp288_pmic driver is in use.
>
> Can I propose that the charger driver defaults values be filled when the
> structure is declared, which would enable part of the USB charging
> functionality. This still means the GPIO pin details are unknown, but
> getting
> that information populated through the PMIC driver should allow USB
> charging.
>


You may propose anything, but Aaron (the author of axp288 support for
Baytrail) unassigned himself from this issue.
And now we sort of know why
http://www.pcworld.com/article/3063508/components/intel-is-on-the-verge-of-exiting-the-smartphone-and-tablet-markets-after-cutting-atom-chips.html


>
> It may make more sense to statically set almost all values for a BayTrail
> SoC
> platform except the GPIO pin, but I honestly don't know. I do intend to
> contact
> the driver developers again soon and see what I can find out.
>

Please contact maintainers of
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/mfd/axp20x.c?id=refs/tags/v4.5.4


>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
Comment 41 MCassaniti 2016-05-13 03:04:15 UTC
Thanks for the quick reply. I've just added the current maintainer's email address to this bug. I will email him directly and request he reviews, and ask his comments to be added to the bug here.

I can't conclude whether it makes sense to fix the AXP288 drivers, or if it makes sense to extend the AXP20x drivers to support both ACPI and OF, picking up support for the AXP288 at the same time.
Comment 42 Pietro Di Costanzo 2016-06-21 12:16:42 UTC
Hi, i confirm this bug for my Cherry View tablet, Cube iWORK 10, with an atom X5-8300

(tested with kernels ranging from 4.5.x to 4.7rc2)

Just one note:
the gmin-kernel tree (The kernel tree patched and mantained by Intel for its Android on Atom distribution, based on 3.14.x version), correctly recognizes the Power Gauge (Note that from the Intel point of view this controller is called Dollar Cove, so you'll have to search for it).

Maybe we can look in the patches to see if something is different. this is the link to the kernel and the patches published by Intel:
https://github.com/android-ia/device_intel_gmin-kernel

With some tweaks it works in a standard Linux distro (Except for the DRM, i need to use nomodeset to run it), so it should be a viable way...
Comment 43 Pietro Di Costanzo 2016-06-21 12:29:50 UTC
Just to point out how it works on the gmin kernel, here is the dollar_cove driver: http://pastebin.com/8GZcz1Mw

It is the corrispective of our axp288_x drivers. If you take a look at the intel_soc_pmic_set_pdata, this is where the pdata is realy initialized.

Maybe we just need a way to replicate this on the linux Drivers, right?
Comment 44 Oleg K 2016-11-13 16:41:21 UTC
Acer One 10 (S1002), Kali Linux Live 2016.2
Don't battery information.
Comment 45 RussianNeuroMancer 2016-11-14 11:29:20 UTC
I noticed that currently axp288_fuel_gauge doesn't enable charging LED when tablet is charging.
Comment 46 MCassaniti 2016-11-16 01:59:40 UTC
So Carlo Caione was contacted and informed on the status, particularly that there's no PIN MUX information. He contacted Chen-Yu Tsai (wens@csie.org) and said he'd be best to work on it.
Since then I can she that Chen-Yu has updated some other AXP2xx drivers, but not the AXP288 driver. That isn't to discredit his work, but it would seem there's other priorities over this driver.
I haven't followed up anything regarding the driver since then. Been too lazy I guess. Comment #42 does look quite interesting though.
Comment 47 RussianNeuroMancer 2016-11-18 03:46:04 UTC
> Since then I can she that Chen-Yu has updated some other AXP2xx drivers, but
> not the AXP288 driver. 
Chen-Yu Tsai answered "I do work on the AXP family for Allwinner SoCs. I do not have any Bay Trail devices that use the AXP288."
Comment 48 Laszlo Fiat 2016-11-18 08:23:49 UTC
The AXP288 is an "intelligent" chip, it provides us all the basic data we need readable on i2c: battery percentage, is it charging, discharging, if we receive power via the microusb connector. The example was shown in Comment 26.

Creating such a "basic driver", that just reads out these data via i2c, and presents it to linux is not such a big deal. I've started working on it several months ago, but stopped due to lack of time.

The trouble is that such a basic driver most likely cannot be mainlined, as there is a much more advanced driver already mainlined , which just doesn't do anything, due to the lack of routine that would read out and provide the platform data that this advanced driver needs for operation. 

We could "steal" code from here: https://github.com/01org/ProductionKernelQuilts

This repository contains all the patches for baytrail and cherrytrail that intel created for android for kernel 3.14.x, including the AXP288 drivers called DollarCove in these drivers. This we also know from Comment 42. These patches most likely contain the code that reads the platform data.

So we have two options: 

1. Writing a basic driver that just reads out data from the AXP288 chip via i2c.
2. Finding the platform data code in the android patches, and try to make the already mainlined kernel drivers work.
Comment 49 sfumato1977 2016-11-18 15:10:07 UTC
Created attachment 245031 [details]
Patch AXP288

tested on kernel 4.8 for Android-x86
Comment 50 sfumato1977 2016-11-18 15:13:02 UTC
here I am with another "temporary" solution. can someone explain to me what I did? because I do not know but it works.

do not forget to load all of the modules for axp288


insmod drivers/extcon/extcon-core.ko
insmod drivers/extcon/extcon-axp288.ko
insmod drivers/iio/adc/axp288_adc.ko
insmod drivers/power/axp20x_usb_power.ko
insmod drivers/power/axp288_charger.ko
insmod drivers/regulator/axp20x-regulator.ko
insmod drivers/power/axp288_fuel_gauge.ko
Comment 51 youling257 2016-11-18 17:17:54 UTC
(In reply to sfumato1977 from comment #50)
> here I am with another "temporary" solution. can someone explain to me what
> I did? because I do not know but it works.
> 
> do not forget to load all of the modules for axp288
> 
> 
> insmod drivers/extcon/extcon-core.ko
> insmod drivers/extcon/extcon-axp288.ko
> insmod drivers/iio/adc/axp288_adc.ko
> insmod drivers/power/axp20x_usb_power.ko
> insmod drivers/power/axp288_charger.ko
> insmod drivers/regulator/axp20x-regulator.ko
> insmod drivers/power/axp288_fuel_gauge.ko

u0_a25@x86:/ $ su
root@x86:/ # dmesg | grep axp
[    4.542515] axp20x-i2c i2c-INT33F4:00: AXP20x variant AXP288 found
[    4.598958] axp288_extcon axp288_extcon: failed to get otg transceiver
[    4.676771] input: axp20x-pek as /devices/platform/80860F41:04/i2c-4/i2c-INT33F4:00/axp20x-pek/input/input0
[    4.693137] axp20x-i2c i2c-INT33F4:00: AXP20X driver loaded
[    8.936915] axp20x: exports duplicate symbol axp20x_device_probe (owned by kernel)
[    8.958814] ueventd: failed to load axp20x-i2c for modalias acpi:INT33F4:INT33F4:
[    9.003143] Error: Driver 'axp20x-pek' is already registered, aborting...
[    9.020804] ueventd: failed to load axp20x-pek for modalias platform:axp20x-pek
[    9.177499] Modules linked in: soc_button_array(+) int3403_thermal int340x_thermal_zone efi_pstore efivars battery axp288_adc industrialio int3400_thermal acpi_thermal_rel 8250_dw lpc_ich joydev ax88179_178a usbnet mii mac_hid i915 drm_kms_helper fb_sys_fops syscopyarea sysfillrect sysimgblt drm i2c_algo_bit hid_apple atkbd
[   11.963847] axp20x: exports duplicate symbol axp20x_device_probe (owned by kernel)
[   11.984055] ueventd: failed to load axp20x-i2c for modalias acpi:INT33F4:INT33F4:
[   15.407594] axp288_fuel_gauge axp288_fuel_gauge: FG data is already initialized
[   15.448176] axp288_fuel_gauge axp288_fuel_gauge: HW IRQ 16 -> VIRQ 278
[   15.501097] axp288_fuel_gauge axp288_fuel_gauge: HW IRQ 17 -> VIRQ 279
[   15.549154] axp288_fuel_gauge axp288_fuel_gauge: HW IRQ 18 -> VIRQ 280
[   15.603610] axp288_fuel_gauge axp288_fuel_gauge: HW IRQ 19 -> VIRQ 281
[   15.656341] axp288_fuel_gauge axp288_fuel_gauge: HW IRQ 24 -> VIRQ 286
[   15.709085] axp288_fuel_gauge axp288_fuel_gauge: HW IRQ 25 -> VIRQ 287
root@x86:/ #
Comment 52 Laszlo Fiat 2016-11-18 17:36:29 UTC
(In reply to sfumato1977 from comment #50)
> here I am with another "temporary" solution. can someone explain to me what
> I did? because I do not know but it works.
> 

Don't say you don't know what you did. You created the missing platform data structure for the drivers so that they don't bail out at their beginning due to the missing platform data. 

It doesn't work correctly that way, because you did not fill in the platform data structure with the right values, so it is there, but it is empty.
Comment 53 sfumato1977 2016-11-18 18:21:30 UTC
someone kindly can replicate the experiment using this kernel

https://github.com/sfumato77/Kernel-4.8_Android-x86_BayTrail

and use this config_BayTrail

P.S.
excuse me, I am an amateur programmer.
I may have made a "blunder".
for this I ask of you.

If I compile the kernel, I have indicated more above.
in /sys/class/power_supply/
I find axp288_fuel_gauge

with all the information on the battery.
because, this, happens, for me it is inexplicable
Comment 54 RussianNeuroMancer 2016-11-19 03:41:32 UTC
1. /etc/modules-load.d/axp288.conf
extcon-core
extcon-axp288
axp288_adc
axp20x_usb_power
axp288_charger
axp20x-regulator
axp288_fuel_gauge
2. battery in /etc/modprobe.d/blacklist.conf

Battery level is displayed for me. However, /sys/class/power_supply/axp288_fuel_gauge and acpi output:
> Battery 0: Discharging, 66%, discharging at zero rate - will never fully
> discharge.
looks like a lot of information still missing.
Comment 55 RussianNeuroMancer 2016-11-20 16:26:21 UTC
Created attachment 245211 [details]
make volatile axp20x_fg_res patch

Turns out instead of blacklisting battery (which is doesn't help actually) this diffs above should be applied: https://github.com/sfumato77/Kernel-4.8_Android-x86_BayTrail/commit/e8e70e9722bb7a83d6ee29bc660c393885f47bd1

Also battery level doesn't get updated on charging/discharging (at least of my tablet). To get it updated properly additional change is required - patch attached. Source of this patch: http://4pda.ru/forum/index.php?showtopic=650808&view=findpost&p=55252765
Comment 56 sfumato1977 2016-11-20 20:22:06 UTC
Comment on attachment 245031 [details]
Patch AXP288

>diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
>index fd55c2f..40c4b1a 100644
>--- a/drivers/extcon/extcon-axp288.c
>+++ b/drivers/extcon/extcon-axp288.c
>@@ -270,6 +270,7 @@ static void axp288_extcon_enable_irq(struct
>axp288_extcon_info *info)
> static int axp288_extcon_probe(struct platform_device *pdev)
> {
>       struct axp288_extcon_info *info;
>+      struct axp288_extcon_pdata *pdata;
>       struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
>       int ret, i, pirq, gpio;
> 
>@@ -280,7 +281,8 @@ static int axp288_extcon_probe(struct platform_device
>*pdev)
>       info->dev = &pdev->dev;
>       info->regmap = axp20x->regmap;
>       info->regmap_irqc = axp20x->regmap_irqc;
>-      info->pdata = pdev->dev.platform_data;
>+      pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
>+      info->pdata = pdata;
> 
>       if (!info->pdata) {
>               /* Try ACPI provided pdata via device properties */
>diff --git a/drivers/power/axp288_charger.c b/drivers/power/axp288_charger.c
>index 4030eeb..aa1552a 100644
>--- a/drivers/power/axp288_charger.c
>+++ b/drivers/power/axp288_charger.c
>@@ -812,6 +812,7 @@ static int axp288_charger_probe(struct platform_device
>*pdev)
> {
>       int ret, i, pirq;
>       struct axp288_chrg_info *info;
>+      struct axp20x_chrg_pdata *pdata;
>       struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
>       struct power_supply_config charger_cfg = {};
> 
>@@ -822,7 +823,9 @@ static int axp288_charger_probe(struct platform_device
>*pdev)
>       info->pdev = pdev;
>       info->regmap = axp20x->regmap;
>       info->regmap_irqc = axp20x->regmap_irqc;
>-      info->pdata = pdev->dev.platform_data;
>+      pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
>+      info->pdata = pdata;
>+
> 
>       if (!info->pdata) {
>               /* Try ACPI provided pdata via device properties */
>diff --git a/drivers/power/axp288_fuel_gauge.c
>b/drivers/power/axp288_fuel_gauge.c
>index 50c0110..01fa9ce 100644
>--- a/drivers/power/axp288_fuel_gauge.c
>+++ b/drivers/power/axp288_fuel_gauge.c
>@@ -1080,6 +1080,7 @@ static int axp288_fuel_gauge_probe(struct
>platform_device *pdev)
> {
>       int ret = 0;
>       struct axp288_fg_info *info;
>+      struct axp20x_fg_pdata *pdata;
>       struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
>       struct power_supply_config psy_cfg = {};
> 
>@@ -1091,7 +1092,8 @@ static int axp288_fuel_gauge_probe(struct
>platform_device *pdev)
>       info->regmap = axp20x->regmap;
>       info->regmap_irqc = axp20x->regmap_irqc;
>       info->status = POWER_SUPPLY_STATUS_UNKNOWN;
>-      info->pdata = pdev->dev.platform_data;
>+      pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
>+      info->pdata=pdata;
>       if (!info->pdata)
>               return -ENODEV;
> 
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index fd80b09..436b509 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -117,6 +117,7 @@ static const struct regmap_range axp288_writeable_ranges[] = {
 
 static const struct regmap_range axp288_volatile_ranges[] = {
        regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IPSOUT_V_HIGH_L),
+       regmap_reg_range(AXP20X_FG_RES, AXP20X_FG_RES),
 };
 
 static const struct regmap_access_table axp288_writeable_table = {
Comment 57 Laszlo Fiat 2016-11-22 16:48:58 UTC
Created attachment 245691 [details]
AXP288 fixes

I've tried to port the original android-ia platform data handling code from here: https://github.com/01org/ProductionKernelQuilts, mainly from intel_soc_pmic_dc.c

It turned out to be difficult. The android code reads battery data from an ACPI table called OEM0, using the battery id framework [1], which never hit mainline. If there is a problem, the android code uses default values, so that's what I did, too.

A second set of battery data should come from an ACPI table called BCFG, which I have on the Teclast X80h, but the driver expects a data structure with the name XPOWER-0, which I do not have. Again, we use default values.

I've "fixed" the extcon-axp288 driver, so that it actually loads, and doesn't make the axp288_charger driver hang on load. 

I added module parameters, so that the drivers autoload, the idea is from here: [2]

It works for me. The patch is for vanilla kernel 4.8.9.

And I haven't yet looked at the AXP288 Opregion code in mainline, which is a bit tricky to compile in.

Since this patch uses default values, it may brick your device: 

USE AT YOUR OWN RISK.

Again, this is not a correct fix for the problem, it is just a cludge to make it work.

[1]: https://lwn.net/Articles/603928/
[2]: https://goo.gl/bvwpxq  (git.kernel.org)
Comment 58 RussianNeuroMancer 2016-11-22 17:06:16 UTC
Laszlo Fiat, how to find you right numbers for fg_bat_curve?

There is example for Chuwi Vi10 Plus:
https://github.com/JideTechnology/remixos-kernel/commit/8442ffc0ffecd596f99360f9ce87aca6d7f8494c
Comment 59 Laszlo Fiat 2016-11-22 17:18:49 UTC
(In reply to RussianNeuroMancer from comment #58)
> Laszlo Fiat, how to find you right numbers for fg_bat_curve?
> 
> There is example for Chuwi Vi10 Plus:
> https://github.com/JideTechnology/remixos-kernel/commit/
> 8442ffc0ffecd596f99360f9ce87aca6d7f8494c

First, I try to read from ACPI BCFG table, but if it is incorrect (mine is), then we go with the default. I took the default fg_bat_curve (along with most code in the patch) from intel_soc_pmic_dc.c.
Comment 60 sfumato1977 2016-11-22 21:00:03 UTC
OK works.


[    7.252855] axp20x-i2c i2c-INT33F4:00: AXP20x variant AXP288 found
[    7.252940] axp20x-i2c i2c-INT33F4:00: Failed to get gpio for extcon pdata
[    7.252948] axp288_get_acpi_cdata:BCFG table not found!!
[    7.252952] axp288_get_fg_config_data: Loading default fg config.
[    7.319541] axp20x-i2c i2c-INT33F4:00: added platform data for axp288_extcon
[    7.319546] axp20x-i2c i2c-INT33F4:00: added platform data for axp288_charger
[    7.319550] axp20x-i2c i2c-INT33F4:00: added platform data for axp288_fuel_gauge
[    7.490705] axp288_charger axp288_charger: failed to register otg notifier
[    7.930131] axp288_fuel_gauge axp288_fuel_gauge: FG data is already initialized
[    7.986431] axp288_fuel_gauge axp288_fuel_gauge: HW IRQ 16 -> VIRQ 279
[    8.023371] axp288_fuel_gauge axp288_fuel_gauge: HW IRQ 17 -> VIRQ 280
[    8.053397] axp288_fuel_gauge axp288_fuel_gauge: HW IRQ 18 -> VIRQ 281
[    8.106387] axp288_fuel_gauge axp288_fuel_gauge: HW IRQ 19 -> VIRQ 282
[    8.146368] axp288_fuel_gauge axp288_fuel_gauge: HW IRQ 24 -> VIRQ 287
[    8.175093] axp288_fuel_gauge axp288_fuel_gauge: HW IRQ 25 -> VIRQ 288
[    8.380568] input: axp20x-pek as /devices/platform/80860F41:04/i2c-12/i2c-INT33F4:00/axp20x-pek/input/input4
[    8.381274] axp20x-i2c i2c-INT33F4:00: AXP20X driver loaded


although I had to make a small correction. because I had too many of these:

[   24.376769] axp288_extcon axp288_extcon: disconnect or unknown or ID event
[   24.379574] axp288_extcon axp288_extcon: disconnect or unknown or ID event
[   24.812456] axp288_extcon axp288_extcon: disconnect or unknown or ID event
[  103.408870] axp288_extcon axp288_extcon: disconnect or unknown or ID event
[  103.411397] axp288_extcon axp288_extcon: disconnect or unknown or ID event
[  103.846426] axp288_extcon axp288_extcon: disconnect or unknown or ID event
[  105.371829] axp288_extcon axp288_extcon: disconnect or unknown or ID event
[  105.374402] axp288_extcon axp288_extcon: disconnect or unknown or ID event
[  105.808454] axp288_extcon axp288_extcon: disconnect or unknown or ID event



   chrg_type = (stat & DET_STAT_MASK) >> DET_STAT_SHIFT;

        switch (chrg_type) {
+       case 0 :
        case DET_STAT_SDP:
                dev_dbg(info->dev, "sdp cable is connecetd\n");
                notify_otg = true;
                notify_charger = true;
                cable = EXTCON_CHG_USB_SDP;
Comment 61 RussianNeuroMancer 2016-11-25 16:38:51 UTC
> It works for me. The patch is for vanilla kernel 4.8.9.
Tested with 4.8.10, works for me too.
Comment 62 RussianNeuroMancer 2016-11-25 17:00:24 UTC
Well, it works, but turns out it works worse - proper battery curve seems like really required instead of default one, at least on my tablet (DEXP Ursus 7W / ONE-01 / Ployer MOMO7W).

Discharging looks like this: 98% 97% 90% 97% 94%, 88% 90%, 82%, etc. (it jumping back and forth).

I back to Comment 49 + Comment 55 combination for now.
Comment 63 Sergei Trusov 2016-12-01 07:23:01 UTC
Hallo,

I have preliminary researched the Windows driver (namely IntelBatteryManagement) and found the following:

1. It is for ACPI hardware ID INT33FE. This belongs to the 'Xpower Battery Device' (discussed here) and some 'TI PMIC Battery Device' on BayTrail CR and CherryTrail CR platforms. The PMIC type is determined by the 'PTYP' ACPI method. 
Code flows for both BYT CR (0x85) and CHT CR (0x05) are then the same. (Actually driver supports two more hardware combinations those are not interested).

2. The driver inits PMIC by writing to registers: 0x30 [AXP20X_VBUS_IPSOUT_MGMT], 0x33 [AXP20X_CHRG_CTRL1], 0x2c (not defined by axp20x.h), 0x34 [AXP20X_CHRG_CTRL2], 0x32 [AXP20X_OFF_CTRL].
I see no access to stuff like 'OCV curve' nor 'thermistor curve' registers.

3. It calls BMDR._DSM method to get: reg, mask, DCP, SDP, CDP, interface type.
These are used to detect charger source at run-time.

4. It installs BMOP (0x9e) operation region handler. The handler itself is relatively simple and could be represented with the pseudo-code given below. Another callback reads PMIC registers and fills up the related data structure.

/* comments are for corresponding data accessors */
enum bmop_address {
	SOC,	/* FG battery capacity percentage = Reg [AXP20X_FG_RES] */
	FCCP,	/* FG full charge capacity = 1.456mAh * [AXP288_FG_DES_CAP1_REG] */
	CHST,	/* FG charging status: 2 charging; 1 discharging; 8 full */
	RMCP,	/* FG remaining capacity = soc * FCCP / 100 */
	VOLT,	/* FG voltage = 1.1 * [AXP20X_BATT_V] */
	BATP,	/* FG battery present = 1 */
	SRP0,	/* Charger present = STYP. DCP, SDP or CDP */
	STYP,	/* Charger type. Get Reg to read from (0) and Mask (E0) by BMDR._DSM */
	CHGC,	/* Charging [AXP20X_BATT_CHRG_I] or discharging [AXP20X_BATT_DISCHRG_I] current */
	STPC,	/* Charger stop RSN  = 0 */
	GADC,	/* Charger ADC raw   = 0 */
	TTEM,	/* FG time to empty  = 0 */
	TTCH,	/* FG time to charge = 0 */
	CYCL,	/* FG cycle count. EFI var */
	BTP,	/* FG BTP. ACPI_WRITE by BMDR.SBTP method? */
	DCPU,	/* FG DPTF current. ACPI writable. Charger then pokes this to [AXP20X_CHRG_CTRL] */
	DSCP,	/* FG design capacity. Hardcoded 5100!? */
	TVOL,	/* not handled by the generic BMOP as TI PMIC lacks it */
	ILIM,	/* the same as above. The current limit is controlled but not reported here */
};

static struct bmop_field {
	unsigned addr[ILIM+1];
} bmop_field;

static acpi_status intel_xpower_pmic_battery_handler(u32 function,
		acpi_physical_address address, u32 bits, u64 *value64,
		void *handler_context, void *region_context)
{
	if (function == ACPI_READ)
		*value64 = bmop_field.addr[address];
	else if (address == BTP || address == DCPU)
		bmop_field.addr[address] = *value64;
	return AE_OK;
}

Since I am new to Linux and its driver architecture, I do not know how (from what driver) this handler should be correctly installed. (also I am not sure about acpi_physical_address granularity, perhaps address should be divided by four).
Comment 64 Sergei Trusov 2016-12-16 16:13:32 UTC
Created attachment 247861 [details]
BMOP opregion driver - PoC - do NOT use

Well, here is hacky 'proof-of-concept' BMOP implementation.
It is tested on DEXP Ursus Z110 (I'll attach DSDT as a reference).

To make it run on top of vanila 4.9 [*1], I had to do two additional things:

1. Patch DSDT. The `BMDR` device (HID INT33FE) is connected to the same I2C as `PMI1` (HID INT33F4) one. Physically they are whole chip and shown this way by the Windows Device Manager.

@@ -16545,7 +16545,7 @@
             Name (RBUF, ResourceTemplate ()
             {
                 I2cSerialBusV2 (0x0068, ControllerInitiated, 0x000186A0,
-                    AddressingMode7Bit, "\\_SB.I2C1",
+                    AddressingMode7Bit, "\\_SB.I2C5",
                     0x00, ResourceConsumer, , Exclusive,
                     )
                 GpioInt (Level, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,

2. Hack gpio-axp209 to support axp288 and attach it as a cell to the MFD.

So BMOP driver is autoloaded and probed by kernel. And, that is more important, installed address space handler works as expected.

The standard battery driver must be loaded after `xpower_battery` one to provide correct information:

cat /sys/class/power_supply/BMBT/uevent
POWER_SUPPLY_NAME=BMBT
POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=3825
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=3800000
POWER_SUPPLY_VOLTAGE_NOW=3678000
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_CHARGE_FULL_DESIGN=9000000
POWER_SUPPLY_CHARGE_FULL=8999000
POWER_SUPPLY_CHARGE_NOW=4319000
POWER_SUPPLY_CAPACITY=47
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_MODEL_NAME=GPC3358154
POWER_SUPPLY_MANUFACTURER=GRAND
POWER_SUPPLY_SERIAL_NUMBER=3358154

Note CHARGE_FULL_DESIGN that is taken from DSDT.
No need in some unknown variables of axp288_fuel_gauge.c
---

At the moment BMOP is incomplete. There is no IRQ handling implemented in the xpower_battery driver (as it duplicates extcon_axp288 functionality).

Taking into account broken DSDT, I think to find a way to install BMOP somehow from axp288_fuel_gauge or so. In that case gpio-axp209 seems to be redundant (and that is why I published such low quality code).

---
[1] I had to disable gpio-keys or apply this 
https://patchwork.kernel.org/patch/6118791/ 
because of IRQ conflict with rtc_cmos
Comment 65 RussianNeuroMancer 2016-12-16 16:16:03 UTC
By they way, there is many axp2xx-related patches by Hans de Goede in linux-i2c right now: https://www.spinics.net/lists/linux-i2c/
Comment 66 Sergei Trusov 2016-12-16 16:25:04 UTC
Created attachment 247891 [details]
DEXP Z110 *patched* DSDT

(In reply to Laszlo Fiat from comment #57)

> I've "fixed" the extcon-axp288 driver

As far as I understand, this patchset is related:  

[PATCH v10 0/7] usb: add support for Intel dual role port mux
http://www.spinics.net/lists/linux-usb/msg141872.html

However I have not tested it yet.
Comment 67 youling257 2016-12-16 19:53:27 UTC
4.8 kernel no gpio axp 209,only add this patch https://patchwork.kernel.org/patch/8545381/ ?
Comment 68 Sergei Trusov 2016-12-17 03:47:08 UTC
(In reply to youling257 from comment #67)
> 4.8 kernel no gpio axp 209,only add this patch
> https://patchwork.kernel.org/patch/8545381/ ?

Perhaps, but I have not tested it on 4.8.

Please note that BMOP driver needs proper DSDT to load
and is provided not for production use.
Comment 69 youling257 2016-12-17 06:43:09 UTC
others thing,modify dsdt for pwm backlight,https://plus.google.com/116937366969544577777/posts/fc7y2oAirh5 

https://patchwork.kernel.org/patch/6118791/ ,this patch also for volume key .
Comment 70 youling257 2016-12-17 10:30:45 UTC
x86:/ $ dmesg | grep battery
[   13.433407] xpower_battery i2c-INT33FE:00: irq 322
[   13.607472] ueventd: blacklisted module battery: 1
[   13.767992] Modules linked in: soc_button_array(+) int3403_thermal int340x_thermal_zone efi_pstore efivars axp20x_pek axp288_adc industrialio gpio_axp209 xpower_battery axp20x_i2c axp20x int3400_thermal acpi_thermal_rel 8250_dw lpc_ich joydev ax88179_178a usbnet mii mac_hid i915 drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect sysimgblt i2c_algo_bit hid_apple atkbd
[   19.238831] BMOP: write [BTP] FG battery trip point => 502
[   19.244865] ACPI: Battery Slot [BMBT] (battery present)
[   72.855182] healthd: battery l=98 v=4100 t=0.0 h=1 st=2 c=0 fc=4999000 cc=3825 chg=
x86:/ $ dmesg | grep BMOP
[   19.238059] BMOP: read [FCCP] FG full chagre capacity => 4999
[   19.238154] BMOP: read [CYCL] FG cycle count => 3825
[   19.238831] BMOP: write [BTP] FG battery trip point => 502
[   19.244045] BMOP: read [CHGC] (Dis)Charging current => 0
[   19.244123] BMOP: read [FCCP] FG full chagre capacity => 4999
[   19.244277] BMOP: read [VOLT] FG voltage => 4030
[   19.244365] BMOP: write [DCPU] FG DPTF current => 198
[   19.244402] BMOP: write [TVOL] => 2
[   19.244438] BMOP: write [ILIM] => 4
[   72.850134] BMOP: read [CHGC] (Dis)Charging current => 0
[   72.850182] BMOP: read [FCCP] FG full chagre capacity => 4999
[   72.850264] BMOP: read [VOLT] FG voltage => 4100
[   72.850312] BMOP: write [DCPU] FG DPTF current => 198
[   72.850337] BMOP: write [TVOL] => 2
[   72.850359] BMOP: write [ILIM] => 4
x86:/ $ dmesg | grep health
[   34.401492] init: Starting service 'healthd'...
[   34.430153] type=1400 audit(1481969863.144:120): avc: denied { entrypoint } for pid=2458 comm="init" path="/sbin/healthd" dev="mmcblk1p3" ino=17353 scontext=u:r:healthd:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[   34.430898] type=1400 audit(1481969863.145:121): avc: denied { read execute } for pid=2458 comm="healthd" path="/sbin/healthd" dev="mmcblk1p3" ino=17353 scontext=u:r:healthd:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[   35.436126] healthd: BatteryHealthPath not found
[   35.456906] healthd: BatteryTemperaturePath not found
[   72.842487] type=1400 audit(1481969901.556:185): avc: denied { dac_override } for pid=2458 comm="healthd" capability=1 scontext=u:r:healthd:s0 tcontext=u:r:healthd:s0 tclass=capability permissive=1
[   72.855182] healthd: battery l=98 v=4100 t=0.0 h=1 st=2 c=0 fc=4999000 cc=3825 chg=
[   72.855585] type=1400 audit(1481969901.569:186): avc: denied { wake_alarm } for pid=2458 comm="healthd" capability=35 scontext=u:r:healthd:s0 tcontext=u:r:healthd:s0 tclass=capability2 permissive=1
[  149.041180] healthd: battery l=98 v=4100 t=0.0 h=1 st=2 c=0 fc=4999000 cc=3825 chg=
x86:/ $ dmesg | grep healthd
[   34.401492] init: Starting service 'healthd'...
[   34.430153] type=1400 audit(1481969863.144:120): avc: denied { entrypoint } for pid=2458 comm="init" path="/sbin/healthd" dev="mmcblk1p3" ino=17353 scontext=u:r:healthd:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[   34.430898] type=1400 audit(1481969863.145:121): avc: denied { read execute } for pid=2458 comm="healthd" path="/sbin/healthd" dev="mmcblk1p3" ino=17353 scontext=u:r:healthd:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
[   35.436126] healthd: BatteryHealthPath not found
[   35.456906] healthd: BatteryTemperaturePath not found
[   72.842487] type=1400 audit(1481969901.556:185): avc: denied { dac_override } for pid=2458 comm="healthd" capability=1 scontext=u:r:healthd:s0 tcontext=u:r:healthd:s0 tclass=capability permissive=1
[   72.855182] healthd: battery l=98 v=4100 t=0.0 h=1 st=2 c=0 fc=4999000 cc=3825 chg=
[   72.855585] type=1400 audit(1481969901.569:186): avc: denied { wake_alarm } for pid=2458 comm="healthd" capability=35 scontext=u:r:healthd:s0 tcontext=u:r:healthd:s0 tclass=capability2 permissive=1
[  149.041180] healthd: battery l=98 v=4100 t=0.0 h=1 st=2 c=0 fc=4999000 cc=3825 chg=
x86:/ $

x86:/ $ su
x86:/ # cat /sys/class/power_supply/BMBT/uevent
POWER_SUPPLY_NAME=BMBT
POWER_SUPPLY_STATUS=
POWER_SUPPLY_PRESENT=
POWER_SUPPLY_TECHNOLOGY=
POWER_SUPPLY_CYCLE_COUNT=
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=
POWER_SUPPLY_VOLTAGE_NOW=
POWER_SUPPLY_CURRENT_NOW=
POWER_SUPPLY_CHARGE_FULL_DESIGN=
POWER_SUPPLY_CHARGE_FULL=
POWER_SUPPLY_CHARGE_NOW=
POWER_SUPPLY_CAPACITY=
POWER_SUPPLY_CAPACITY_LEVEL=
POWER_SUPPLY_MODEL_NAME=
POWER_SUPPLY_MANUFACTURER=
POWER_SUPPLY_SERIAL_NUMBER=
x86:/ #

98,Incorrect
Comment 71 youling257 2016-12-17 10:33:48 UTC
i don't want to say more about android,first,blacklist battery ;then on post-fs,run script,modprobe battery
Comment 72 Sergei Trusov 2016-12-18 09:37:44 UTC
(In reply to youling257 from comment #70)

> [   72.855182] healthd: battery l=98 v=4100 t=0.0 h=1 st=2 c=0 fc=4999000
> cc=3825 chg=

Ok, it shows the following values:

> [   19.238059] BMOP: read [FCCP] FG full chagre capacity => 4999
> [   19.238154] BMOP: read [CYCL] FG cycle count => 3825
> [   72.850264] BMOP: read [VOLT] FG voltage => 4100

At least this is a good news.

cat /sys/class/power_supply/BMBT/uevent is weird.
It contains more fields but less data than without BMOP driver (see comment #10 for example).

Will there be any changes if manually re-load the battery module?
Comment 73 youling257 2016-12-18 10:04:44 UTC
(In reply to Sergei Trusov from comment #72)
> (In reply to youling257 from comment #70)
> 
> > [   72.855182] healthd: battery l=98 v=4100 t=0.0 h=1 st=2 c=0 fc=4999000
> > cc=3825 chg=
> 
> Ok, it shows the following values:
> 
> > [   19.238059] BMOP: read [FCCP] FG full chagre capacity => 4999
> > [   19.238154] BMOP: read [CYCL] FG cycle count => 3825
> > [   72.850264] BMOP: read [VOLT] FG voltage => 4100
> 
> At least this is a good news.
> 
> cat /sys/class/power_supply/BMBT/uevent is weird.
> It contains more fields but less data than without BMOP driver (see comment
> #10 for example).
> 
> Will there be any changes if manually re-load the battery module?

it must before healthd to load battery,[34.401492] init: Starting service 'healthd'... 

i tried methods from comment 49 to 64,no better than this script https://github.com/zhaofengli/iwork8/blob/master/scripts/battery.sh ,on post-fs or post-fs-data run script,of course blacklist battery . i know what android needs,it isn't only show battery level.
Comment 74 Sergei Trusov 2016-12-18 11:05:44 UTC
(In reply to youling257 from comment #73)
 
> > Will there be any changes if manually re-load the battery module?
> 
> it must before healthd to load battery,[34.401492] init: Starting service
> 'healthd'... 

I think both *battery drivers do not need this daemon to provide
/sys/class/power_supply/BMBT/uevent
At least my test system (mentioned in comment #64) has no healthd at all.

> i tried methods from comment 49 to 64,no better than this script
> https://github.com/zhaofengli/iwork8/blob/master/scripts/battery.sh ,on

You are lucky https://github.com/Icenowy/axpd/issues/3
Comment 75 Hans de Goede 2016-12-22 11:57:30 UTC
I've a series of patches (designware-i2c + axp288 + extcon) which together give full support for battery and charger monitoring on the axp288 and work well for me on a cube iwork8 air tablet. I've send these upstream, some of them have already been merged and I expect the others to get merged too.

This series should resolve this bug, at least for all tablets with an axp288 pmic. If you're interested in this work, it is probably easiest (for now) to build your own kernel from my WIP branch:

https://git.linuxtv.org/hgoede/gspca.git/log/?h=drm-intel-next-queued

Note I often rebase / do forced pushes to this branch, it is not a good branch to base another branch on.
Comment 76 youling257 2016-12-22 12:29:30 UTC
(In reply to Hans de Goede from comment #75)
> I've a series of patches (designware-i2c + axp288 + extcon) which together
> give full support for battery and charger monitoring on the axp288 and work
> well for me on a cube iwork8 air tablet. I've send these upstream, some of
> them have already been merged and I expect the others to get merged too.
> 
> This series should resolve this bug, at least for all tablets with an axp288
> pmic. If you're interested in this work, it is probably easiest (for now) to
> build your own kernel from my WIP branch:
> 
> https://git.linuxtv.org/hgoede/gspca.git/log/?h=drm-intel-next-queued
> 
> Note I often rebase / do forced pushes to this branch, it is not a good
> branch to base another branch on.

how to use it ?
Comment 77 Taha 2016-12-22 22:30:33 UTC
(In reply to Hans de Goede from comment #75)
> I've a series of patches (designware-i2c + axp288 + extcon) which together
> give full support for battery and charger monitoring on the axp288 and work
> well for me on a cube iwork8 air tablet. I've send these upstream, some of
> them have already been merged and I expect the others to get merged too.
> 
> This series should resolve this bug, at least for all tablets with an axp288
> pmic. If you're interested in this work, it is probably easiest (for now) to
> build your own kernel from my WIP branch:
> 
> https://git.linuxtv.org/hgoede/gspca.git/log/?h=drm-intel-next-queued
> 
> Note I often rebase / do forced pushes to this branch, it is not a good
> branch to base another branch on.

I've compiled this kernel on my cherry trail z3800 laptop and the battery percentage still doesn't seem to be displayed. There is nothing inside /sys/class/power_supply/. I used the i2c script to get the battery percentage and that worked.

I was going to attach the dmesg output but I just realized what the issue was as I was typing. It's not enough to git clone git://linuxtv.org/hgoede/gspca.git - you have to checkout the branch drm-intel-next-queued.
Comment 78 youling257 2016-12-22 22:51:11 UTC
4.9 kernel

[ 10.889503] silead_ts i2c-MSSL1680:00: Silead chip ID: 0x80360000
[ 10.890766] silead_ts i2c-MSSL1680:00: Registers clear error -11
[ 10.904226] silead_ts: probe of i2c-MSSL1680:00 failed with error -11

i must use 4.8 kernel,how to use drm-intel-next-queued with 4.8 kernel ? 
this 4.8 kernel,https://github.com/maurossi/linux/tree/kernel-4.8
Comment 79 Hans de Goede 2016-12-23 18:55:35 UTC
(In reply to youling257 from comment #78)
> 4.9 kernel
> 
> [ 10.889503] silead_ts i2c-MSSL1680:00: Silead chip ID: 0x80360000
> [ 10.890766] silead_ts i2c-MSSL1680:00: Registers clear error -11
> [ 10.904226] silead_ts: probe of i2c-MSSL1680:00 failed with error -11
> 
> i must use 4.8 kernel,how to use drm-intel-next-queued with 4.8 kernel ? 
> this 4.8 kernel,https://github.com/maurossi/linux/tree/kernel-4.8

Hmm, that sounds like a glitch, does it happen every boot ? What happens if you do:

rmmod silead
modprobe silead

?
Comment 80 youling257 2016-12-23 19:12:24 UTC
(In reply to Hans de Goede from comment #79)
> (In reply to youling257 from comment #78)
> > 4.9 kernel
> > 
> > [ 10.889503] silead_ts i2c-MSSL1680:00: Silead chip ID: 0x80360000
> > [ 10.890766] silead_ts i2c-MSSL1680:00: Registers clear error -11
> > [ 10.904226] silead_ts: probe of i2c-MSSL1680:00 failed with error -11
> > 
> > i must use 4.8 kernel,how to use drm-intel-next-queued with 4.8 kernel ? 
> > this 4.8 kernel,https://github.com/maurossi/linux/tree/kernel-4.8
> 
> Hmm, that sounds like a glitch, does it happen every boot ? What happens if
> you do:
> 
> rmmod silead
> modprobe silead
> 
> ?

blacklist silead,on post-fs,modprobe silead max_x=1625 max_y=1135 invert_y=yes ,http://4pda.ru/forum/index.php?showtopic=650808&view=findpost&p=55476620

i care android x86 nougat ,i don't care others linux .

if you can make your cube iwork8 air work well with 4.9 kernel on others linux,you are lucky,just for you, not work for my tablet . if you want solve others chinese bay trail/Cherry trail tablet ,you need buy them ! 

my bay trail tablet onda v891w ,i use android x86 nougat 4.8 kernel reply with you now .
i suggest you go to solve your tablet cube iWork8 air on android x86 nougat problem,sound、backlight、battery......
Comment 81 Taha 2016-12-23 20:54:14 UTC
> I've a series of patches (designware-i2c + axp288 + extcon) which together
> give full support for battery and charger monitoring on the axp288 and work
> well for me on a cube iwork8 air tablet. I've send these upstream, some of
> them have already been merged and I expect the others to get merged too.
> 
> This series should resolve this bug, at least for all tablets with an axp288
> pmic. If you're interested in this work, it is probably easiest (for now) to
> build your own kernel from my WIP branch:
> 
> https://git.linuxtv.org/hgoede/gspca.git/log/?h=drm-intel-next-queued
> 
> Note I often rebase / do forced pushes to this branch, it is not a good
> branch to base another branch on.

Okay, I gave this another shot today and amazingly, it worked! I git cloned git://linuxtv.org/hgoede/gspca.git, checked out the drm-intel-next-queued branch and then checked out commit b37beb3f7567b55089fb7de941e182cc5f82b493 (because the latest commit was giving me a compile error), enabled the axp modules and disabled I2C_DESIGNWARE_BAYTRAIL, compiled the kernel and now when I boot into XFCE, I can see the battery percentage in the bottom right corner.

I'm running a Z8300 laptop (specifically the Jumper EZBook 2 which was previously running Windows 10).

After some further testing, the kernel seems to freeze after a minute or two but it is likely unrelated as the version I compiled was 4.9-rc8. I've attached the dmesg.
Comment 82 Taha 2016-12-23 20:55:28 UTC
Created attachment 248451 [details]
dmesg after running Hans de Goede's branch on a Z8300 laptop
Comment 83 Hans de Goede 2016-12-23 21:20:27 UTC
(In reply to Taha from comment #81)
> Okay, I gave this another shot today and amazingly, it worked!

Well not that amazingly really (I would like to think I know what I'm doing), but still good news, thank you for testing this. The axp288_fuel_gauge patches have mostly been accepted upstream so with 4.11 everything should just work (they were send to late for 4.10).

(In reply to youling257 from comment #80)
> blacklist silead,on post-fs,modprobe silead max_x=1625 max_y=1135
> invert_y=yes
> ,http://4pda.ru/forum/index.php?showtopic=650808&view=findpost&p=55476620

If you've a silead touchscreen it would be great if you could take a look at the silead patches in my branch, specifically this one:

https://git.linuxtv.org/hgoede/gspca.git/commit/?h=drm-intel-next-queued&id=56ebbc3541034635c3a1a620dd7b54fa9ec1c4be

And send a patch on top which adds the necessary silead_ts_dmi_table entry for your tablet to automatically make it do the right thing. Please also submit your silead ts firmware (with a
unique name, as done for the iwork8 air) to: https://github.com/onitake/gsl-firmware/tree/master/firmware/linux/silead

So that people can just copy the contents of the silead dir there to /lib/firmware and have things just work (no blacklisting + modprobe options needed).

Note I'm the upstream maintainer of the silead driver. But I still need to get the dmi stuff accepted by the input subsys maintainer (he has not reviewed the patches yet).

> if you can make your cube iwork8 air work well with 4.9 kernel on others
> linux,you are lucky,just for you, not work for my tablet . if you want solve
> others chinese bay trail/Cherry trail tablet ,you need buy them ! 

I agree that it would be good to have more then one model, actually the last 2 days I've been working on getting the jumper ezpad mini3 which I've bought to work (not much luck there its firmware seems very broken). But it is impossible for me to buy all possible models, so I need your help with testing on your own tablet.
Comment 84 youling257 2016-12-23 21:30:12 UTC
(In reply to Hans de Goede from comment #83)
> (In reply to Taha from comment #81)
> > Okay, I gave this another shot today and amazingly, it worked!
> 
> Well not that amazingly really (I would like to think I know what I'm
> doing), but still good news, thank you for testing this. The
> axp288_fuel_gauge patches have mostly been accepted upstream so with 4.11
> everything should just work (they were send to late for 4.10).
> 
> (In reply to youling257 from comment #80)
> > blacklist silead,on post-fs,modprobe silead max_x=1625 max_y=1135
> > invert_y=yes
> > ,http://4pda.ru/forum/index.php?showtopic=650808&view=findpost&p=55476620
> 
> If you've a silead touchscreen it would be great if you could take a look at
> the silead patches in my branch, specifically this one:
> 
> https://git.linuxtv.org/hgoede/gspca.git/commit/?h=drm-intel-next-
> queued&id=56ebbc3541034635c3a1a620dd7b54fa9ec1c4be
> 
> And send a patch on top which adds the necessary silead_ts_dmi_table entry
> for your tablet to automatically make it do the right thing. Please also
> submit your silead ts firmware (with a
> unique name, as done for the iwork8 air) to:
> https://github.com/onitake/gsl-firmware/tree/master/firmware/linux/silead
> 
> So that people can just copy the contents of the silead dir there to
> /lib/firmware and have things just work (no blacklisting + modprobe options
> needed).
> 
> Note I'm the upstream maintainer of the silead driver. But I still need to
> get the dmi stuff accepted by the input subsys maintainer (he has not
> reviewed the patches yet).
> 
> > if you can make your cube iwork8 air work well with 4.9 kernel on others
> > linux,you are lucky,just for you, not work for my tablet . if you want
> solve
> > others chinese bay trail/Cherry trail tablet ,you need buy them ! 
> 
> I agree that it would be good to have more then one model, actually the last
> 2 days I've been working on getting the jumper ezpad mini3 which I've bought
> to work (not much luck there its firmware seems very broken). But it is
> impossible for me to buy all possible models, so I need your help with
> testing on your own tablet.

28 days ago,https://github.com/onitake/gsl-firmware/issues/25#issuecomment-263049301
Comment 85 MCassaniti 2017-01-18 11:32:24 UTC
Quentin Schulz from Free Electrons has posted a patch (link: https://lwn.net/Articles/710492/) that adequately describes what OCV curves are and why they are important. The takeaway is that they will be specific to the battery used in the device, and therefore need to be read from the firmware, not programmed into the driver. Unfortunately I still don't know enough about ACPI to know how to retrieve this data satisfactorily.

A very ugly fallback could be to program a linear curve (i.e. straight line rather than a curve), but that would give false battery status.
Comment 86 Icenowy Zheng 2017-01-18 11:43:39 UTC
Created attachment 252331 [details]
attachment-11392-0.html

2017年1月18日 下午7:32于 bugzilla-daemon@bugzilla.kernel.org写道:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=88471
>
> --- Comment #85 from MCassaniti <michael@cassaniti.id.au> ---
> Quentin Schulz from Free Electrons has posted a patch (link:
> https://lwn.net/Articles/710492/) that adequately describes what OCV curves
> are
> and why they are important. The takeaway is that they will be specific to the
> battery used in the device, and therefore need to be read from the firmware,
> not programmed into the driver. Unfortunately I still don't know enough about
> ACPI to know how to retrieve this data satisfactorily.
>
> A very ugly fallback could be to program a linear curve (i.e. straight line
> rather than a curve), but that would give false battery status.

I think AXP has a integrated curve at leadt better than a linear curve.

>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 87 Icenowy Zheng 2017-01-30 21:49:49 UTC
(In reply to Hans de Goede from comment #79)
> (In reply to youling257 from comment #78)
> > 4.9 kernel
> > 
> > [ 10.889503] silead_ts i2c-MSSL1680:00: Silead chip ID: 0x80360000
> > [ 10.890766] silead_ts i2c-MSSL1680:00: Registers clear error -11
> > [ 10.904226] silead_ts: probe of i2c-MSSL1680:00 failed with error -11
> > 
> > i must use 4.8 kernel,how to use drm-intel-next-queued with 4.8 kernel ? 
> > this 4.8 kernel,https://github.com/maurossi/linux/tree/kernel-4.8
> 
> Hmm, that sounds like a glitch, does it happen every boot ? What happens if
> you do:
> 
> rmmod silead
> modprobe silead
> 
> ?

I got the same error, and everytime I rmmod it and modprobe it I got it again.

My device now is a EZpad mini2s (The X98 Air 3G I used to make this bug report now runs its stock Android firmware ;-) )

Should I issue another bug for it?
Comment 88 Hans de Goede 2017-01-31 15:26:47 UTC
(In reply to Icenowy Zheng from comment #87)
> I got the same error, and everytime I rmmod it and modprobe it I got it
> again.
> 
> My device now is a EZpad mini2s (The X98 Air 3G I used to make this bug
> report now runs its stock Android firmware ;-) )
> 
> Should I issue another bug for it?

Yes, please file a silead driver bug for this.
Comment 89 alan 2017-03-03 14:21:04 UTC
Can someone here can tell me if axp20 and axp288 patches are always necessary to support battery on 4.10.x kernel ?

I loaded axp20 and axp288 as modules in /etc/modules-load.d/axp288.conf:

extcon-core
extcon-axp288
axp288_adc
axp20x_usb_power
axp288_charger
axp20x-regulator
axp288_fuel_gauge

Note: Except CONFIG_EXTCON=y, by default, all others options for axp20 and axp288 are defined by "m" in the kernel options of the 4.10.x kernel.

and here is the dmesg error messages I received:

[    7.163603] axp288_extcon axp288_extcon: failed to get platform data
[    7.163707] axp288_charger axp288_charger: failed to get platform data

Thanks.
Comment 90 Hans de Goede 2017-03-03 14:30:08 UTC
(In reply to alan from comment #89)
> Can someone here can tell me if axp20 and axp288 patches are always
> necessary to support battery on 4.10.x kernel ?
> 
> I loaded axp20 and axp288 as modules in /etc/modules-load.d/axp288.conf:
> 
> extcon-core
> extcon-axp288
> axp288_adc
> axp20x_usb_power
> axp288_charger
> axp20x-regulator
> axp288_fuel_gauge
> 
> Note: Except CONFIG_EXTCON=y, by default, all others options for axp20 and
> axp288 are defined by "m" in the kernel options of the 4.10.x kernel.
> 
> and here is the dmesg error messages I received:
> 
> [    7.163603] axp288_extcon axp288_extcon: failed to get platform data
> [    7.163707] axp288_charger axp288_charger: failed to get platform data
> 
> Thanks.

Alan, 

I've already told you twice through private email that not all patches necessary for this are in place yet and that there are quire a few different patches needed for everything to just work. Either just use my test branch which has everything integrated: https://github.com/jwrdegoede/linux-sunxi/commits/drm-intel-next-queued-cht or just wait patiently. 4.11-rc1 will have most patches, but depending on your hw configuration that version may or may not work.

Regards,

Hans
Comment 91 alan 2017-03-06 12:40:42 UTC
@Hans de Goede: Well, I waited for the 4.11-rc1 kernel and now it is out. I will test it with my hardware.

Sorry for my impatience but it's been more than a year since I expect my hardware to be fully functional. I hope that you understand.

I guess that more of your patches will be included in the next 4.11-rc versions and that we could have full support for battery when the 4.11 stable kernel will be released. 

Thanks to you and to the kernel community.
Comment 92 alan 2017-03-06 12:42:21 UTC
(In reply to Hans de Goede from comment #90)
> @Hans de Goede: Well, I waited for the 4.11-rc1 kernel and now it is out. I
> will test it with my hardware.
> 
> Sorry for my impatience but it's been more than a year since I expect my
> hardware to be fully functional. I hope that you understand.
> 
> I guess that more of your patches will be included in the next 4.11-rc
> versions and that we could have full support for battery when the 4.11
> stable kernel will be released. 
> 
> Thanks to you and to the kernel community.
Comment 93 Hans de Goede 2017-03-06 13:11:33 UTC
Hi,

(In reply to alan from comment #91)
> @Hans de Goede: Well, I waited for the 4.11-rc1 kernel and now it is out. I
> will test it with my hardware.
> 
> Sorry for my impatience but it's been more than a year since I expect my
> hardware to be fully functional. I hope that you understand.
> 
> I guess that more of your patches will be included in the next 4.11-rc
> versions and that we could have full support for battery when the 4.11
> stable kernel will be released. 

I'm sorry, but that is not how the kernel development process works. After rc1 only bugfixes for regressions (so things which used to work in 4.10 and are broken in 4.11) are fixed, since my work is new (*) hardware enablement anything which was not in -next when the merge window opened and thus is not in 4.11-rc1 will not get merged till 4.12-rc1.

*) New as in not yet supported

Regards,

Hans
Comment 94 alan 2017-03-07 13:39:08 UTC
Hi Hans,

(In reply to Hans de Goede from comment #93)
> Hi,
> 
> (In reply to alan from comment #91)
> > @Hans de Goede: Well, I waited for the 4.11-rc1 kernel and now it is out. I
> > will test it with my hardware.
> > 
> > Sorry for my impatience but it's been more than a year since I expect my
> > hardware to be fully functional. I hope that you understand.
> > 
> > I guess that more of your patches will be included in the next 4.11-rc
> > versions and that we could have full support for battery when the 4.11
> > stable kernel will be released. 
> 
> I'm sorry, but that is not how the kernel development process works. After
> rc1 only bugfixes for regressions (so things which used to work in 4.10 and
> are broken in 4.11) are fixed, since my work is new (*) hardware enablement
> anything which was not in -next when the merge window opened and thus is not
> in 4.11-rc1 will not get merged till 4.12-rc1.
> 
> *) New as in not yet supported
> 
> Regards,
> 
> Hans

I well understand. I only want to say to you that I tested the 4.11-rc1 kernel and the support for the battery seems to be better. I don't know if it is full supported but the initialization for the battery seems to work by default. This was not the case with the 4.10.x kernel. I only met a little 'problem', the power applet on my desktop (Cinnamon) for the battery displays 2 batteries rather than one (Intel SR 1 SR real battery 100% and secondary battery). The first one doesn't work, it is the secondary who works. I think it is only a little bug.

Thanks for your work. 

Regards.

Alan.
Comment 95 RussianNeuroMancer 2017-03-07 15:08:05 UTC
I tested 4.11rc1 on DEXP Ursus 7W and now battery is detected without additional patches and adjustments via /etc/modules-load.d/axp288.conf

Big thank to you, Hans and to everyone who help with getting this working!

p.s. Alongside real battery there is always second battery that always at 100% - as I understand I should fill separate bugreport about this issue?
Comment 96 Hans de Goede 2017-03-07 15:37:27 UTC
(In reply to RussianNeuroMancer from comment #95)
> p.s. Alongside real battery there is always second battery that always at
> 100% - as I understand I should fill separate bugreport about this issue?

Yes please, I'm not seeing this on my tablets, but if you can out me in the Cc if the new bug we can debug it there.
Comment 97 Icenowy Zheng 2017-03-07 15:48:32 UTC
Created attachment 255115 [details]
attachment-11870-0.html

2017年3月7日 23:37于 bugzilla-daemon@bugzilla.kernel.org写道:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=88471
>
> --- Comment #96 from Hans de Goede (jwrdegoede@fedoraproject.org) ---
> (In reply to RussianNeuroMancer from comment #95)
> > p.s. Alongside real battery there is always second battery that always at
> > 100% - as I understand I should fill separate bugreport about this issue?

It's the fake ACPI battery.

I think we should prevent ACPI battery from being probed if axp288 is present.

>
> Yes please, I'm not seeing this on my tablets, but if you can out me in the
> Cc
> if the new bug we can debug it there.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 98 RussianNeuroMancer 2017-03-07 15:50:27 UTC
Bugreport: https://bugzilla.kernel.org/show_bug.cgi?id=194811

I wasn't able to add you into CC List.
Comment 99 Sergei Trusov 2017-03-07 16:04:37 UTC
(In reply to Icenowy Zheng from comment #97)

> > > p.s. Alongside real battery there is always second battery that always at
> > > 100% - as I understand I should fill separate bugreport about this issue?
> 
> It's the fake ACPI battery.

Actually this works with the BMOP driver (see comment #64).

The problem is, I don not know how to start the BMOP opregion handler on the hardware with broken DSDTs (like one I own).

By the way, the DSDT contains the code that assumes the interaction between BMOP and DPTF.
Comment 100 alan 2017-03-08 14:29:00 UTC
Created attachment 255135 [details]
Patch hide_phantom_batteries
Comment 101 alan 2017-03-08 14:32:13 UTC
Hi, 

there is a workaround for 'phantom' battery. The workaround is to hide the 'phantom' battery.  I put a patch in attachment to this topic. The patch was made for 4.9-rc5 kernel but I think it can be adapted for 4.11-rcx kernel. The patch come from jharrison022. The name of the patch is : hide_phantom_batteries
Comment 102 Sergei Trusov 2017-03-09 07:15:42 UTC
There is another simple workaround (to blacklist the 'battery' module) in comment #54
Comment 103 RussianNeuroMancer 2017-03-09 10:57:45 UTC
Sergei, battery blacklisting doesn't help me with 4.11rc1.
Comment 104 Sergei Trusov 2017-03-10 14:40:41 UTC
(In reply to RussianNeuroMancer from comment #103)
> Sergei, battery blacklisting doesn't help me with 4.11rc1.

Oh, this is weird. Anyway it can be disabled with CONFIG_ACPI_BATTERY=N 
or deleted /lib/modules/*/kernel/drivers/acpi/battery.ko*
Comment 105 Sergei Trusov 2017-03-10 14:45:43 UTC
More interesting, why this module does not load on some tablets? (as Hans said in comment #96)
I guess the hardware has no PNP0C0A in DSDT
Comment 106 Hans de Goede 2017-03-11 09:55:13 UTC
(In reply to Sergei Trusov from comment #105)
> More interesting, why this module does not load on some tablets? (as Hans
> said in comment #96)
> I guess the hardware has no PNP0C0A in DSDT

In my case, there are not 1 but 2 PNP0C0A devices in the DSDT, but they both have _STA methods which returns 0 for my tablet (which has BDID set to One):

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (BDID == One)
                {
                    Return (Zero)
                }
                ...
            }

And:

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (BDID != 0x08)
                {
                    Return (Zero)
                }
                ...
            }

So the answer is it depends on the DSDT I guess.

I'm working on a fix for this, but lets discuss this further in bug 194811 which is about the issue with there being 2 batteries on some devices. I believe the original issue (no charge information) has been resolved now, so lets close this bug.
Comment 107 youling257 2017-03-11 12:25:37 UTC
(In reply to Hans de Goede from comment #106)
> (In reply to Sergei Trusov from comment #105)
> > More interesting, why this module does not load on some tablets? (as Hans
> > said in comment #96)
> > I guess the hardware has no PNP0C0A in DSDT
> 
> In my case, there are not 1 but 2 PNP0C0A devices in the DSDT, but they both
> have _STA methods which returns 0 for my tablet (which has BDID set to One):
> 
>             Method (_STA, 0, NotSerialized)  // _STA: Status
>             {
>                 If (BDID == One)
>                 {
>                     Return (Zero)
>                 }
>                 ...
>             }
> 
> And:
> 
>             Method (_STA, 0, NotSerialized)  // _STA: Status
>             {
>                 If (BDID != 0x08)
>                 {
>                     Return (Zero)
>                 }
>                 ...
>             }
> 
> So the answer is it depends on the DSDT I guess.
> 
> I'm working on a fix for this, but lets discuss this further in bug 194811
> which is about the issue with there being 2 batteries on some devices. I
> believe the original issue (no charge information) has been resolved now, so
> lets close this bug.

The current output is reversed .  3.10.20 kernel dual os Android 4.4 ,4.11 kernel Android x86 7.1.1 lineage os,Linux version 4.11.0-rc1-android-x86 (root@localhost) (gcc version 6.3.0 20170221 (Ubuntu 6.3.0-8ubuntu1) ) #3 SMP PREEMPT Sat Mar 11 18:42:24 CST 2017 ,3c toolbox apk .
Comment 108 youling257 2017-03-11 12:28:43 UTC
Created attachment 255185 [details]
dual os Android
Comment 109 youling257 2017-03-11 12:39:28 UTC
Created attachment 255187 [details]
4.11 kernel lineage os
Comment 110 Hans de Goede 2017-03-11 14:09:08 UTC
Hi,

(In reply to youling257 from comment #107)
> (In reply to Hans de Goede from comment #106)
> > (In reply to Sergei Trusov from comment #105)
> > > More interesting, why this module does not load on some tablets? (as Hans
> > > said in comment #96)
> > > I guess the hardware has no PNP0C0A in DSDT
> > 
> > In my case, there are not 1 but 2 PNP0C0A devices in the DSDT, but they
> both
> > have _STA methods which returns 0 for my tablet (which has BDID set to
> One):
> > 
> >             Method (_STA, 0, NotSerialized)  // _STA: Status
> >             {
> >                 If (BDID == One)
> >                 {
> >                     Return (Zero)
> >                 }
> >                 ...
> >             }
> > 
> > And:
> > 
> >             Method (_STA, 0, NotSerialized)  // _STA: Status
> >             {
> >                 If (BDID != 0x08)
> >                 {
> >                     Return (Zero)
> >                 }
> >                 ...
> >             }
> > 
> > So the answer is it depends on the DSDT I guess.
> > 
> > I'm working on a fix for this, but lets discuss this further in bug 194811
> > which is about the issue with there being 2 batteries on some devices. I
> > believe the original issue (no charge information) has been resolved now,
> so
> > lets close this bug.
> 
> The current output is reversed .

 I don't think so I think that android is getting confused by current_now reading negative when discharging, as on some devices current_now is always reported positive and the actual current direction needs to be determined from the state sysfs attribute. I believe that when charging the current will be correct under android and that android is unconditionally multiplying the current by -1 when discharging even if the reported current_now is already negative making it positive again.

From a terminal do:

cat /sys/class/power_supply/axp288_fuel_gauge/status

And:

cat /sys/class/power_supply/axp288_fuel_gauge/current_now

When unplugged and thus discharging these should read e.g.

[root@localhost ~]# cat /sys/class/power_supply/axp288_fuel_gauge/status 
Discharging
[root@localhost ~]# cat /sys/class/power_supply/axp288_fuel_gauge/current_now 
-720000

If you get something similar (negative current_now when discharging) then this is a bug in how android interprets current_now.

Regards,

Hans
Comment 111 youling257 2017-03-11 14:57:03 UTC
(In reply to Hans de Goede from comment #110)
> Hi,
> 
> (In reply to youling257 from comment #107)
> > (In reply to Hans de Goede from comment #106)
> > > (In reply to Sergei Trusov from comment #105)
> > > > More interesting, why this module does not load on some tablets? (as
> Hans
> > > > said in comment #96)
> > > > I guess the hardware has no PNP0C0A in DSDT
> > > 
> > > In my case, there are not 1 but 2 PNP0C0A devices in the DSDT, but they
> > both
> > > have _STA methods which returns 0 for my tablet (which has BDID set to
> > One):
> > > 
> > >             Method (_STA, 0, NotSerialized)  // _STA: Status
> > >             {
> > >                 If (BDID == One)
> > >                 {
> > >                     Return (Zero)
> > >                 }
> > >                 ...
> > >             }
> > > 
> > > And:
> > > 
> > >             Method (_STA, 0, NotSerialized)  // _STA: Status
> > >             {
> > >                 If (BDID != 0x08)
> > >                 {
> > >                     Return (Zero)
> > >                 }
> > >                 ...
> > >             }
> > > 
> > > So the answer is it depends on the DSDT I guess.
> > > 
> > > I'm working on a fix for this, but lets discuss this further in bug
> 194811
> > > which is about the issue with there being 2 batteries on some devices. I
> > > believe the original issue (no charge information) has been resolved now,
> > so
> > > lets close this bug.
> > 
> > The current output is reversed .
> 
>  I don't think so I think that android is getting confused by current_now
> reading negative when discharging, as on some devices current_now is always
> reported positive and the actual current direction needs to be determined
> from the state sysfs attribute. I believe that when charging the current
> will be correct under android and that android is unconditionally
> multiplying the current by -1 when discharging even if the reported
> current_now is already negative making it positive again.
> 
> From a terminal do:
> 
> cat /sys/class/power_supply/axp288_fuel_gauge/status
> 
> And:
> 
> cat /sys/class/power_supply/axp288_fuel_gauge/current_now
> 
> When unplugged and thus discharging these should read e.g.
> 
> [root@localhost ~]# cat /sys/class/power_supply/axp288_fuel_gauge/status 
> Discharging
> [root@localhost ~]# cat
> /sys/class/power_supply/axp288_fuel_gauge/current_now 
> -720000
> 
> If you get something similar (negative current_now when discharging) then
> this is a bug in how android interprets current_now.
> 
> Regards,
> 
> Hans

no ,this is Android x86,use mainline kernel,just add drm: disable permission check ;usbnet: [TEMP HACK] force the interface name to ethX ; mwifiex: change interface name to wlanX ;android: support 32-bit binder in 64-bit kernel; x86/vdso: fix a build break on CONFIG_FUNCTION_TRACER=y ; shmem: enable user xattr for tmpfs ;SSSE3 emulation for invalid opcode ,Android x86 can use anyone kernel . it isn't you known oem Android .
Comment 112 youling257 2017-03-11 15:39:57 UTC
android_x86:/ $ su
android_x86:/ # cat /sys/class/power_supply/axp288_fuel_gauge/current_now
-1088000
android_x86:/ # cat /sys/class/power_supply/axp288_fuel_gauge/status
Discharging
android_x86:/ # cat /sys/class/power_supply/axp288_fuel_gauge/current_now
-688000
android_x86:/ # cat /sys/class/power_supply/axp288_fuel_gauge/status
Discharging
android_x86:/ #

OK,kernel no problem,Android os problem.
Comment 113 paul 2017-03-14 10:30:39 UTC
I've been testing these patches on 4.11-rc1 (along with the ones pending for 4.12 on the mailing list) and the battery works fine. Kudos!

However I notice that my touchscreen (i2c, goodix driver) becomes buggy, some touch events are reported, some are not. Since this patch series touch a lot the i2c code, it might be related (or not). Can somebody reproduce this?
Comment 114 Sergei Trusov 2017-04-01 08:53:43 UTC
Hallo All, 

Thanks to Hans de Goede the AXP288 driverset is getting additional features (not upstreamed yet).

One might want to check out https://github.com/jwrdegoede/linux-sunxi/tree/master
(at the moment applied to Linux 4.11-rc4).

Note You need to log in before you can comment on or make changes to this bug.