924607 - Investigate and implement code to disable USB charging circuit via Linux Kernel

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect, P2)

Description

[Dave Huseby [:huseby]]

The Linux Kernel has drivers for controlling power regulators and the power chips.  This bugs encapsulates the investigation of the hamachi and keon devices to see if they support shutting off the USB charging circuit and then adding to the test driver scripts to shut off USB charging so the power consumption data gathering can work.

Comment 1

[Dave Huseby [:huseby]]

There is an msm_charger kernel module available that looks to be able to disable the charging circuit but it doesn't expose that control to user space.  I'm in the process of writing a small kernel module that does that.

Comment 2

[Dave Huseby [:huseby]]

I'm trying to build a custom kernel for the Hamachi device.  I found the kernel config file and customized it to my liking but I'm struggling to figure out the trick to get ./build.sh to build the kernel from source rather than use the one pulled from qualcomm.

Do you have any suggestions?

Comment 3

[Michael Wu [:mwu]]

I believe Jed has successfully built a kernel for hamachi before. We'll want to switch to a proper hamachi kernel build now that we have the source, but things aren't currently configured to easily build hamachi kernels.

Comment 4

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

There was some discussion on IRC the other day.  Our current hamachi manifest pulls CodeAurora's kernel/msm, which I haven't actually tried but I assume it won't work as-is on the device itself.

I have an altered manifest, currently at https://github.com/jld/b2g-manifest/tree/master/hamachi.xml, which will build a boot image and matching WiFi drivers from Alcatel's souce release (+ our seccomp-bpf patch).  Notes on installation are in https://gist.github.com/jld/7270024 (extra complication there because the WiFi drivers created by the build will be overwritten by the ones from backup-hamachi in the system.img staging tree).

WARNING: Some builds seem to have a locked bootloader which won't load an image created this way, in which case the device will be bricked until an acceptable boot.img is flashed (but fastboot will still work for that).

Comment 5

[Dave Huseby [:huseby]]

I'm limiting the scope of this bug to be just getting charging under software control on my GP Keon.  There will be follow on bugs to track the work of getting the Hamachi kernel source build up to date and patched.

Comment 6

[Dave Huseby [:huseby]]

According to qualcomm, the charging circuit isn't under software control from the application processor.  Only the baseband processor can control it.  That means the Keon and Hamachi are unable to disable charging from the b2g side.  I am now switching to investigating making a source build of the kernel for the Nexus S and Nexus 4 hardware.  Maybe they will support this feature.

Comment 7

[Dave Huseby [:huseby]]

I should not that this is really only needed for us to do automated regression testing for power usage.  We are still able to manually execute tests on devices with the ammeter attached and still gather reasonably good data.

Comment 8

[Dave Huseby [:huseby]]

I have shifted gears to working on the Nexus S platform.  It uses the max8998_charger kernel module to manage charging of the battery.  I'm currently getting the Nexus S kernel to build from source so that I can make modifications.

Comment 9

[Dave Huseby [:huseby]]

Attachment: Charging.png

Screenshot showing dmesg on the Nexus S with "USB charging enabled" messages and the resulting measurements on the ammeter.  Notice that the line on the ammeter is red.  That indicates that current is flowing from the charging circuit INTO the battery (i.e. the battery is charging).

Comment 10

[Dave Huseby [:huseby]]

Attachment: No_Charging.png

This is a screenshot of the same kernel as before but with a modified battery driver that disables charging and refuses to enable it when the USB cable is connected.  Notice in the dmesg output it says "REFUSING TO ENABLE CHARGING".  There is also the ammeter output that shows that current is flowing from the battery into the device (i.e. the battery is discharging) even though the USB cable is attached.

Comment 11

[Dave Huseby [:huseby]]

My investigation is complete.  Moving on to implementation.  See Bug 942387 and Bug 942386.