Bug 88471
| Summary: | Bogus battery information on Teclast X98 Air 3G (Baytrail-T) | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Fabian Zaremba (fabian) |
| Component: | Other | Assignee: | drivers_other |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | aaron.lu, alan90000, beta992, billypon, bugzilla, carlo, david.e.box, hf, icenowy, icenowy, joel, jwrdegoede, kernel.bugzilla, kernelbugs, kevinjf, kovalevoe, laszlo.fiat, littlesmartguy, louan, luke-jr+linuxbugs, michael, paul, pxpert, rc.alternative1, russianneuromancer, rzk333, sassmann, sergei.a.trusov, sfumato1977, tianyu.lan, youling257 |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 3.18-rc5 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg from 3.18rc5 on Teclast X98 Air 3G
Used kernel configuration cat /sys/class/power_supply/BMBT/uevent Output of `acpidump > acpidump.out` dmesg from 3.19-rc2 on Teclast X98 Air 3G dmesg from patched 3.19-rc2 on Teclast X98 Air 3G dmesg of kernel 4.1.0 config of kernel 4.1.0 attachment-1893-0.html Patch AXP288 make volatile axp20x_fg_res patch AXP288 fixes BMOP opregion driver - PoC - do NOT use DEXP Z110 *patched* DSDT dmesg after running Hans de Goede's branch on a Z8300 laptop attachment-11392-0.html attachment-11870-0.html Patch hide_phantom_batteries dual os Android 4.11 kernel lineage os |
||
|
Description
Fabian Zaremba
2014-11-18 21:06:33 UTC
Created attachment 158051 [details]
Used kernel configuration
Created attachment 158061 [details]
cat /sys/class/power_supply/BMBT/uevent
Created attachment 158071 [details]
Output of `acpidump > acpidump.out`
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? 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) (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. Created attachment 162511 [details] dmesg from 3.19-rc2 on Teclast X98 Air 3G Without the patch proposed in comment #5 Created attachment 162521 [details] dmesg from patched 3.19-rc2 on Teclast X98 Air 3G Including patch from comment #5 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? 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. Created attachment 181081 [details]
dmesg of kernel 4.1.0
Created attachment 181091 [details]
config of kernel 4.1.0
*** Bug 100411 has been marked as a duplicate of this bug. *** (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? :) 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. Hi at all. Any updates in this case? Thank you in advance. Regards, Herbert Cc David. *** Bug 101161 has been marked as a duplicate of this bug. *** (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? (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. 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 ? 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. @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. :) 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. 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 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
I forgot and maybe a new firmware for Intel Atom Z3735F audio codec on SPI1 Thank you Umberto I. (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. > 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
(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. (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) (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 *** Bug 109741 has been marked as a duplicate of this bug. *** Hi, Is there any progress regarding this bug? Should I compile the new kernel and check? Thanks Kevin Seems like same issue with DEXP Ursus 7W tablet (and probably other DEXP Ursus BayTrail-based tablets/laptops). 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 . 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? Louan du Toit, check comment #15. 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. 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. > 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. 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... 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? Acer One 10 (S1002), Kali Linux Live 2016.2 Don't battery information. I noticed that currently axp288_fuel_gauge doesn't enable charging LED when tablet is charging. 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. > 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."
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. Created attachment 245031 [details]
Patch AXP288
tested on kernel 4.8 for Android-x86
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 (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:/ # (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. 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 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.
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 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 = { 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) 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 (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.
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;
> It works for me. The patch is for vanilla kernel 4.8.9.
Tested with 4.8.10, works for me too.
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. 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).
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 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/ 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. 4.8 kernel no gpio axp 209，only add this patch https://patchwork.kernel.org/patch/8545381/ ? (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. 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 . 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
i don't want to say more about android，first，blacklist battery ；then on post-fs，run script，modprobe battery (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? (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. (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 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. (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 ? (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. 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 (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 ? (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...... > 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.
Created attachment 248451 [details]
dmesg after running Hans de Goede's branch on a Z8300 laptop
(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. (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 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. 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. (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? (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. 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. (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 @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. (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. 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 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. 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? (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. 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. Bugreport: https://bugzilla.kernel.org/show_bug.cgi?id=194811 I wasn't able to add you into CC List. (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. Created attachment 255135 [details]
Patch hide_phantom_batteries
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 There is another simple workaround (to blacklist the 'battery' module) in comment #54 Sergei, battery blacklisting doesn't help me with 4.11rc1. (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* 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 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. (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 . Created attachment 255185 [details]
dual os Android
Created attachment 255187 [details]
4.11 kernel lineage os
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 (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 . 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. 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? 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). |