[Lenovo Yoga Book Questions & Answers] jimnarey:
Help Needed - Battery Gauge/Charger

The issue

The following can be seen by running 'dmesg' after boot using the ISO in my first post, which uses a 4.18 kernel customised for the hardware in the Yoga Book.

The kernel attempts to load the driver for the TI bq24190 battery charger IC. I'm not yet able to post links so search for 'bq24190_charger.c' in the Linux kernel Github repo. The driver throws an error on boot when it hits this code at line 1640. It's expecting a 6 and it gets a 4, the value of BQ24190_REG_VPRS_PN_24190.

bq24190_charger.c

if (v != BQ24190_REG_VPRS_PN_24190 &&
v != BQ24190_REG_VPRS_PN_24192I) {
dev_err(bdi->dev, "Error unknown model: 0x%02x\n", v);
return -ENODEV;
}

If I remove this check altogether and re-compile the module then the driver proceeds to load but reports zeroes for all status values. It's not clear whether it is, in fact, the right chip and isn't talking to the rest of the hardware or it's simply the wrong driver.

However, at least removing this check allows the Whiskey Cove ACPI IC driver to get a bit further along. Search for 'intel_cht_int33fe.c' in the kernel source. Comments in this file (line 124) confirm that this IC is expected to be paired with a bq24190.

By adding in dmesg warnings and re-compiling the int33fe module I could see that when an unmodified bq24190 driver is used, i.e. the check above takes place and is failed, the int33fe driver fails its own check at line 138:

intel_cht_int33fe.c

regulator = regulator_get_optional(dev, "cht_wc_usb_typec_vbus");
if (IS_ERR(regulator)) {
ret = PTR_ERR(regulator);
return (ret == -ENODEV) ? -EPROBE_DEFER : ret;
}
regulator_put(regulator);

When I remove the check, it fails at the next check starting at line 145:

/* The FUSB302 uses the irq at index 1 and is the only irq user */
fusb302_irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 1);
if (fusb302_irq < 0) {
if (fusb302_irq != -EPROBE_DEFER)
dev_err(dev, "Error getting FUSB302 irq\n");
return fusb302_irq;
}

I have tried various combinations of including the FUSB driver and dependencies as modules/built in but the result is the same. I also tried moving the FUSB check to after the code which tries to link up with the max17047 battery gauge IC, but this fails also.

Some owners of the Android version of the Yoga Book have posted files/screenshots on Telegram which indicate that a different charger, the bq25892 is used. As far as I know i2c devices are simply identified by the fact that they occupy a certain address on the bus. You can see in the datasheet for the bq24190 (sorry, no links!) on page 3 that it uses i2c address 6BH. The datasheet for the bq25890/2 shows on page 5 that the bq25892 also uses 6BH.

I don't know enough about i2c to know whether this is the issue, or how to point Linux to a different driver in the way that you might using a VID:PID for a USB or PCI device? It would be really helpful if anybody could definitively confirm which chip we are dealing with.

Some final ACPI errors crop up towards the end of the dmesg output (I've cleared all the others) and I suspect that sorting this will clear them, as well as making the Yoga Book with Mint usable in Tablet mode.

Other things which need fixing:

- There are sound errors in the dmesg output but it also shows that the drivers and codec are loading properly. I can see all the devices which should be visible in amixer from the command line. Because getting the config wrong can blow speakers I've resisted tackling this until I've done further research but if anyone has a solution please let me know.

- Halo Keyboard. This needs either a kernel module to be written or a software layer which runs at least under X. I don't expect this to be hugely difficult - Linux can see the Halo as a wacom graphics pad and take input, albeit not deal with it properly yet. There's also a mystery, generic HID device which by process of elimination must be the button/backlight. However, the generic HID driver loads so it shouldn't be too hard to work out how to talk to it.

- I re-built the ISO using Cubic. When I have tried to make ISOs which use my custom kernel to boot the ISO itself, they don't work. I get garbled graphics and the boot stalls. This is why the touchscreen doesn't work when you live boot (which uses 4.10) but does when you install (because it uses 4.18). This ought not to be insurmountable but I haven't cracked it yet. I've tried doing it manually and using the Debian live-boot commands for both Debian/Ubuntu. Still no luck.

- Until I can get a custom ISO to boot from a custom kernel it won't be possible to install on the SD Card. Otherwise, there's no reason this shouldn't be possible.

- It should be possible to install to another USB device now, but I haven't tried yet. Make sure to use the disable MMC script on the desktop if you don't want to install Grub EFI on the eMMC. Ubuntu and derivatives ignore whatever you choose for this and just use the fist EFI partition they find. Amazingly this bug has been there since 2014!

- It ought to be possible to map the hardware buttons (volume, power) to specific keys in Grub, possibly using a locale. This would allow selections to be made without a keyboard.