• State Resolved
  • Locked Locked
  • Replies 50 replies
  • Answers 4 answers
  • Subscribers 100 subscribers
  • Views 15842 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/BQ27421-G1: Installing and using the driver on Debian

Brian Wrenn
Intellectual 430 points
Part Number: BQ27421-G1
Other Parts Discussed in Thread: BQ27500, BQ27000, BQ27200, BQ27210, BQ27010, BQ27510, BQ27541

Tool/software: Linux

Hi, I have been trying to use the driver for this power monitor on a Debian system, Linaro 4.4.9 to be specific.  I'm working on the DART SD410 devkit from Variscite.  I have issued some direct i2c calls from with a bash shell to get information from the BQ27421-G1 and verified the data reported as accurate.  So I know I have the device connected properly.

However, after following the steps to build the driver into the kernel, I haven't identified any way to make use of the driver.  I followed the instructions to build the driver into my kernel by way of menuconfig as shown here.

Symbol: BATTERY_BQ27XXX [=y]
Type  : tristate
Prompt: BQ27xxx battery driver
  Location:
    -> Device Drivers
      -> Power supply class support (POWER_SUPPLY [=y])
  Defined at drivers/power/supply/Kconfig:167
  Depends on: POWER_SUPPLY [=y]


Symbol: BATTERY_BQ27XXX_I2C [=y]
Type  : tristate
Prompt: BQ27xxx I2C support
  Location:
    -> Device Drivers
      -> Power supply class support (POWER_SUPPLY [=y])
        -> BQ27xxx battery driver (BATTERY_BQ27XXX [=y])
  Defined at drivers/power/supply/Kconfig:172
  Depends on: POWER_SUPPLY [=y] && BATTERY_BQ27XXX [=y] && I2C [=y]

After flashing the boot image of the SOM, I would expect something like a file structure to exist where cat'ing the contents of a file reports things like temperature, battery level, etc.  But I've found no such things.  Also, the .ko file for the module is nowhere to be found on the file system.  I would expect that it resides somewhere under /lib/modules/<linux version>/.  I had to find the .ko in the source tree, scp it to the SOM, and manually insert it with insmod.  But even after that, I didn't see any way to get information polled from the device.

I've read the both the quick start guide and the technical reference for this device, but it doesn't seem to have this information, so I'm trying to answer the following questions.

(1) How to I build the kernel such that it includes the driver and loads it upon boot?  A kernel rebuild after making the kernel config changes does not result this.  What further steps do I need to do?
(2) How do I tell the driver on which i2c I have the BQ27421-G2 connected?
(3) How do I extract information from the BQ27421-G2 from the driver?
(4) The technical reference makes mention of what looks like some API calls, e.g. Temperature(), Voltage().  Is there a library (.so or .a) against which a program can link to access information provided by the driver? Or perhaps does some header file exist that a program could include at compile time?

Thanks.
  • 0
    Guru 13630 points
    (1) How to I build the kernel such that it includes the driver and loads it upon boot? A kernel rebuild after making the kernel config changes does not result this. What further steps do I need to do?
    Ans: Change in defconfig and make it as =Y. Also resolve the dependency(better would be to do from menuconfig). Check the dmesg for the driver is loaded.
    (2) How do I tell the driver on which i2c I have the BQ27421-G2 connected?
    Ans: You need to set this as I2C Board info in device tree. Explore the device tree option.
    (3) How do I extract information from the BQ27421-G2 from the driver?
    Ans: Once step 1 and step 2 are in place, you can access through sysfs entry: /sys/class/power_supply/battery
    (4) The technical reference makes mention of what looks like some API calls, e.g. Temperature(), Voltage(). Is there a library (.so or .a) against which a program can link to access information provided by the driver? Or perhaps does some header file exist that a program could include at compile time?
    Ans: I am not sure of it. You can explore the uevents Netlink messages or use sysfs etntry as mentioned in point 3.
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points

    I have done (1), but not (2), so that is probablky what I am missing. Would you post a link to an sample device tree file if you readily have one?

  • 0 in reply to Brian Wrenn
    Guru 13630 points

    Hi,

    Please refer in kernel source, Documentation/i2c/instantiating-devices

    e.g. for reference and need tof ind for your bus and i2c slave

    &i2c3 {
    clock-frequency = <100000>;

    bq27500@55 {
    compatible = "ti,bq27500";
    reg = <0x55>;
    };

    };

  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points

    Hi, thank you for proving some more clues.  I have looked through the driver source on my version of Linux (Debian/Linaro 4.4.9), and the driver source there doesn't seem to provide any of the of_device_id information required, which would include the compatibility string.  I also found a kernel tree commit that seems to add that information which the driver source of my Linux tree lacks.

    www.spinics.net/.../msg115434.html

    By chance is this driver not capable of running on my system in its current version?  I don't know if I can upgrade from 4.4.9 due to other considerations.  The driver version #define'ed in the driver source code file is 1.2.0.

    Just for good measure, I attempted a kernel build after modifying the device tree as guided, but the driver is not loaded nor running on the system.

    Thanks,

    Brian

  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Hi,

    The worrying part is driver not getting loaded. Atleast the module_init of the driver should be run, if not the probe. Have you added enough logs to say the driver is not loaded ? I would suggest you to make the driver as module so that you can insert at any time and check the corresponding dmesg.
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points
    My kernel config includes these:
    CONFIG_W1_SLAVE_BQ27000=y
    CONFIG_BATTERY_BQ27XXX=y
    CONFIG_BATTERY_BQ27XXX_I2C=y
    CONFIG_BATTERY_BQ27XXX_PLATFORM=y

    I've used menuconfig to check all the related dependencies, and they are 'y'. I've done a clean build of my boot image with that config, both with and without the first W1 config item since the instructions make no mention of it. But it does not produce a .ko file as I would expect, and of course a dmesg doesn't contain any information about the driver after booting.
  • 0 in reply to Brian Wrenn
    Guru 13630 points

    Hi Brian,

    You need to make them as =m

    e.g.

    CONFIG_W1_SLAVE_BQ27000=m
    CONFIG_BATTERY_BQ27XXX=m
    CONFIG_BATTERY_BQ27XXX_I2C=m
    CONFIG_BATTERY_BQ27XXX_PLATFORM=m

    Then "make modules" and also install the modules. To make them as .ko

  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points
    Hi Dwarakesh,

    thank you for your patience with me. I thought 'y' would build the .ko files just the same. I attempted to manually load the .ko file after rebuilding the kernel with 'm' set to those values. That did indeed build the .ko files, but it did not make them part of the boot image, so I manually transferred bq27xxx_battery.ko from my development machine to the target platform and ran an insmod with that. However, that produced a kernel abort. See the first few lines of that output:

    root@linaro-alip:~# insmod bq27xxx_battery.ko ^M
    [ 112.345321] Unable to handle kernel NULL pointer dereference at virtual address 000000c8^M
    [ 112.345380] pgd = ffffffc0235a8000^M
    [ 112.352561] [000000c8] *pgd=0000000000000000, *pud=0000000000000000^M
    [ 112.359838] ^M
    [ 112.362572] Internal error: Oops: 96000005 [#1] PREEMPT SMP^M
    [ 112.362584] power_supply bq27500-0: POWER_SUPPLY_NAME=bq27500-0^M
    [ 112.362614] Modules linked in: bq27xxx_battery(+)^M
    [ 112.362638] CPU: 2 PID: 2475 Comm: insmod Not tainted 4.4.9-linaro-lt-qcom #1^M
    [ 112.362646] Hardware name: Variscite VAR-SD410CustomBoard (DT)^M
    [ 112.362663] task: ffffffc025952700 ti: ffffffc0258a0000 task.ti: ffffffc0258a0000^M
    [ 112.362691] PC is at dev_driver_string+0x8/0x28^M
    [ 112.362713] LR is at __dynamic_dev_dbg+0x74/0xcc^M
    [ 112.362727] pc : [<ffffffc000479c58>] lr : [<ffffffc00035696c>] pstate: 80000145^M
    [ 112.362734] sp : ffffffc0258a3620^M
  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Hi Brian,

    Can you share the dts changes you did regarding i2c ?
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points

    Hi Dwarakesh,

    I've attached two .dtsi files.  This is the last state in which I've had them.  I don't remember the exact modification since between the previous state in which I had them, but whatever change I've made has stopped the kernel abort from happening.  But the driver still never seems to load.  I think the modifications could happen in either of these files.

    -Brian5811.dtsi_files.zip

  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Hi Brian,

    What did you see in dmesg after the crash stopped ?
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points

    The kernel abort dump seemed to be in an infinite loop, so I power cycled.  If/when I produce the abort again, I'll let it run longer to see it if actually completes or minimally keep more of it in the log to send you some snippet.  Here's what I had in the console capture prior to power cycling in the attached file.6153.screenlog.0_bqcrash.txt

  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Hi Brian,

    When you meant "but whatever change I've made has stopped the kernel abort from happening." I thought you have fixed this abort dump. Ok let me check the reason for this crash.
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points
    Yes, I did say that, but I guess our messages are coming a little out of synch, since I saw your message asking for the abort dump after I mentioned that. Presumably, you had not yet seen the message about not having the abort any longer prior to asking for a log of the dump. If you think it's helpful to look through the logs, sure thing, but if you want to put that on hold, that's just as good for me.

    The problem I think I'm having is that the platform driver doesn't seem to have any association with the device tree entry, so when I load the .ko file, it's probe function doesn't get invoked or gets invoked without any device info. Since there is no compatibility specified within the driver source, I don't now how the device tree creates that association. In drivers I've seen before, they use a '.compatible' field to establish that association. Looking at other device tree files that have references to bq27***, it looks like there's some other way that association gets created. That's just my best guess.
  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Hi,

    If there is no .compatible=ti,bq27*** inside the drivers/power/ folder, then you might need to consider adding it the older way. Please refer to the first method shared in kernel documentation by writing in Board file and to use I2C_BOARD_INFO
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points
    Hi Dwarakesh,

    I've read a little more into i2c, and apparently the kernel should attempt to match compatibility with the contents of the i2c_device_id table. See below from bq27xxx_battery.c.

    <snippet>
    static const struct i2c_device_id bq27xxx_id[] = {
    { "bq27200", BQ27000 },
    { "bq27210", BQ27010 },
    { "bq27500", BQ27500 },
    { "bq27510", BQ27500 },
    { "bq27520", BQ27500 },
    { "bq27530", BQ27530 },
    { "bq27531", BQ27530 },
    { "bq27541", BQ27541 },
    { "bq27542", BQ27541 },
    { "bq27546", BQ27541 },
    { "bq27742", BQ27541 },
    { "bq27545", BQ27545 },
    { "bq27421", BQ27421 }, // <============== SEE HERE
    { "bq27425", BQ27421 },
    { "bq27441", BQ27421 },
    { "bq27621", BQ27421 },
    {},
    };
    </snippet>

    Because my .dtsi file contains a compatibility string that matches one of those, supposedly the kernel will pass the device of that device tree element to the driver's probe function.

    i2c@78ba000 {
    clock-frequency = <100000>;

    bq27421@55 {
    compatible = "ti,bq27421"; // <============ SEE HERE
    reg = <0x55>;
    };
    };
    But so far as I can tell, it doesn't. I've added some debug statements to print into dmesg within the driver, but none of them appear within dmesg upon loading the driver's .ko file.
  • 0 in reply to Brian Wrenn
    Guru 13630 points

    Hi Brian,

    Can you try patching this to drivers/power/bq27xxx_battery.c ?

    +#ifdef CONFIG_OF
    +static const struct of_device_id bq27xxx_battery_i2c_of_match_table[] = {
    + { .compatible = "ti,bq27200" },
    + { .compatible = "ti,bq27210" },
    + { .compatible = "ti,bq27500" },
    + { .compatible = "ti,bq27510" },
    + { .compatible = "ti,bq27520" },
    + { .compatible = "ti,bq27530" },
    + { .compatible = "ti,bq27531" },
    + { .compatible = "ti,bq27541" },
    + { .compatible = "ti,bq27542" },
    + { .compatible = "ti,bq27546" },
    + { .compatible = "ti,bq27742" },
    + { .compatible = "ti,bq27545" },
    + { .compatible = "ti,bq27421" },
    + { .compatible = "ti,bq27425" },
    + { .compatible = "ti,bq27441" },
    + { .compatible = "ti,bq27621" },
    + {},
    +};
    +MODULE_DEVICE_TABLE(of, bq27xxx_battery_i2c_of_match_table);
    +#endif
    static const struct i2c_device_id bq27xxx_id[] = {
    { "bq27200", BQ27000 },
    { "bq27210", BQ27010 },
    @@ -1198,6 +1219,7 @@ MODULE_DEVICE_TABLE(i2c, bq27xxx_id);
    static struct i2c_driver bq27xxx_battery_i2c_driver = {
    .driver = {
    .name = "bq27xxx-battery",
    + .of_match_table = of_match_ptr(bq27xxx_battery_i2c_of_match_table),
    },
    .probe = bq27xxx_battery_i2c_probe,
    .remove = bq27xxx_battery_i2c_remove,

    And check this.

  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points

    0181.archive2.zipHi Dwarakesh,

    I applied the patch, rebuilt the kernel, and re-imaged the SD 410, but the behavior didn't change: no related messages in dmsg and no content in /sys/class/power_supply/.  I've attached the patched file for you to confirm that I applied it correctly.  I've also included the .dtsi modification in the most recent state.  It comes from 4.4.9 under kernel/arch/arm64/boot/dts/qcom.  All other .dts/.dtsi files in that directory have their original form.  At one point, I had applied changes to msm8916.dtsi, but I've backed those out before modifying apq8016-var-sd410.dtsi.

    Thanks,

    Brian

  • 0 in reply to Brian Wrenn
    Guru 13630 points

    Hi Brian,

    How did you confirm on this : i2c@78ba000

    bq27xxx_battery_platform_probe : Does this get called ?

    I strongly suspect the Device Tree to be the issue now. please check how any other i2c client is being configured in the specific device's device tree and follow the same.

  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points

    Hi Dwarakesh,



    How did you confirm on this : i2c@78ba000

    3704.archive3.zipI'm not sure I could say I've confirmed that I've done this device tree node correctly or not.  I just followed the convention of the other device tree nodes.  78ba000 is the address for the i2c connected to the bq27421-g1.  Another file, msm8916.dtsi, defines the i2c fully, the node I added in apq8016-var-sd410.dtsi I expect would append to that i2c config.  

    Just before posting this message, I moved the added device tree node from apq8016-var-sd410.dtsi to msm8916.dtsi and got the same outcome.  See attached.

    bq27xxx_battery_platform_probe : Does this get called ?

    The probe function immediately prints to dmesg upon invocation, and I this printk doesn't show up there.  Given that, I think the probe function isn't getting called.

    static int bq27xxx_battery_platform_probe(struct platform_device *pdev)
    {
    struct bq27xxx_device_info *di;
    struct bq27xxx_platform_data *pdata = pdev->dev.platform_data;
    const char *name;

    printk("@@@ here-1.1\n");

    ...

  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Hi Brian,

    Can you try making the drivers back as built in. =y option and check if it is giving the same logs as modules. Let me check the attached files.
  • 0 in reply to Dwarakesh Radhakrishnan
    Guru 13630 points
    Can you align the bq27xxx as done for ov5645 sensor connected to the same i2c6 bus
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points
    I just did, and I got this:

    [ 4.324730] i2c i2c-1: of_i2c: modalias failure on /soc/i2c@78ba000/bq27421@55

    So this seems like a good clue. This was with the .dtsi files I sent you in archive3.zip a couple messages above.
  • 0 in reply to Brian Wrenn
    Intellectual 430 points
    FYI, this message just sent was in response to changing the configs back to 'y'.

    I'm looking into your question about ov5645 and i2c6 right now.
  • 0 in reply to Brian Wrenn
    Intellectual 430 points

    0550.archive4.zipI got the same dmesg output:

    [    4.331626] i2c i2c-1: of_i2c: modalias failure on /soc/i2c@78ba000/bq27421@55

    I attached the .dtsi.

  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Just this much, just my try:

    bq27421@55 {
    compatible = "ti,bq27421";
    reg = <0x55>;
    };
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points

    6153.kernel_abort.txtThis time, I think the match worked.  But I did get a kernel abort.   Here's some of the dmesg output.

    [    4.561208] qcom-camss 1b0ac00.camss: Fail to init vfe sub-device^M

    [    4.586278] msm_cci_init_gpio_params:1371 gpio count 0^M

    [    4.599364] Driver for 1-wire Dallas network protocol.^M

    [    4.606146] @@@ here-2.1^M

    [    4.606348] @@@ here-2.2^M

    [    4.608098] @@@ here-2.3^M

    [    4.610334] @@@ here-2.4^M

    [    4.630561] Unable to handle kernel NULL pointer dereference at virtual address 000000c8^M

    [    4.561208] qcom-camss 1b0ac00.camss: Fail to init vfe sub-device^M

    [    4.586278] msm_cci_init_gpio_params:1371 gpio count 0^M

    2 things to note:

    (1) I added the "@@@ here-..." messages to bq27xxx_battery.c

    (2) Here's the source snippet from that file where I think the abort may have happened.

    printk("@@@ here-2.4\n");

    retval = bq27xxx_powersupply_init(di, name);

    if (retval)

    goto batt_failed;

    /* Schedule a polling after about 1 min */

    schedule_delayed_work(&di->work, 60 * HZ);

    printk("@@@ here-2.5\n");

    Notice that "here-2.5" never gets written to dmesg.

    I'm doing a clean build of the whole kernel just to make sure I've covered all my bases, and I'm adding more print messages between "here-2.4" and "here-2.5".  I'm also attaching the entire kernel abort dump.

  • 0 in reply to Brian Wrenn
    Intellectual 430 points
    Do you think removing the "clock-frequency = <100000>;" element has anything to do with the abort?
  • 0 in reply to Brian Wrenn
    Guru 13630 points
    yeah, you can add it back, but with the same alignment as I have mentioned above and check.
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points

    I added the clock frequency element back to the .dtsi, but the kernel abort still happens.  I've included three things in this archive.

    (1) source code of bq27xxx_batter.c that includes my print statements

    (2) kernel abort console dump

    (3) .dtsi file I used

    This resulted from a clean build of the boot image.  The problem seems to happen somewhere within the function bq27xxx_powersupply_init().  If you correlate the "@@@" messages in the abort dump with the attached source, I think you will see what I mean.7563.archive5.zip

  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Hi,

    They have given some patches and have discussed similar issue online

    marc.info/

    patchwork.kernel.org/.../
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points

    4670.archive6.zipHi Dwarakesh,

    I manually applied those patches, and they did make a difference.  The kernel abort no longer happens, but there is another problem.  Something is writing to the console (dmesg) at such a high rate that /dev/kmsg experiences a high amount of overruns and hence messages lost.  That warning makes the console so busy that I can't explore whether the driver is working or not, i.e. populating /sys/class/power_supply/ with information or not.  I removed the debugging printk calls I had added, so it's not those.  I've attached two files in an archive: one has the console output that did make it to dmesg, and the other has the patched driver source.  I double checked the patched source, and I don't think I missed anything.

    I found a couple more patches, but I haven't tried these yet.  I probably won't get to that until tomorrow.

    [v4,5/8] power: bq27xxx_battery: add BQ27425 chip id - Patchwork

    [v3,4/7] power: bq27xxx_battery: add BQ27425 chip id - Patchwork 

    [1/3] power: bq27xxx_battery: fix platform probe - Patchwork

    [v12.3,10/10] power: bq27xxx_battery: Remove duplicate ... - Patchwork

  • 0 in reply to Brian Wrenn
    Guru 13630 points
    I am not sure if these patches will help.

    Just to narrow down, I would suggest if you are fine, to make them as mosules =m and check which .ko is causing and what is the message coming.
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points

    I just tried after setting the driver as a module.  The SOM boots fine, and the rapid, repeating occurrence of the error message begins instantly after running 'insmod bq27xxx_battery.ko'.

    [  144.049378] systemd-journald[1489]: /dev/kmsg buffer overrun, some messages lost.

    I can't tell what causes this message since the syslog has no other messages coming from it.  This message consumes the entirety of the console, so much that I can't enter any command.  I have to hard reset the SOM.

  • 0 in reply to Brian Wrenn
    Intellectual 430 points

    2148.console.txtQuick follow-up: I managed to rmmod after insmod the .ko, and then I ran a dmesg.  Immediately after the rmmod, the systemd-jould messages stopped.  I've attached that console output.

  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Hi Brian,

    One try would be to immediately rmmod bq27xxx_battery.ko

    like
    #insmod bq27xxx_battery.ko && rmmod bq27xxx_battery.ko, if this is giving some clue of what log is getting filled. Also increase if possible the dmesg size
  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Ok thanks, exactly what I wanted to try. Looks like it is filling the buffer with uevent message. Some kind of update sent to the sysfs entry, including temperature, battery level etc. But why this frequently need to be looked into. Let me check it.
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points
    Okay, thanks. BTW, I really appreciate how you've diligently engaged this.
  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Looks like,

    bq27xxx_battery_irq_handler_thread() - interrupt is occurring continuously

    which calls bq27xxx_battery_update() -> power_supply_changed() calls this uevent

    Can you check if this is the observation by adding logs ? Also check this condition, how it is not same: di->cache.capacity != cache.capacity
  • 0 in reply to Brian Wrenn
    Intellectual 430 points

    And another note, the driver seems to be working even though it's flooding dmesg. At least I can see that it creates a file structure under /sys/class/power_supply and populates those files with values related to battery status.  To do this, I connected the SOM to Wi-Fi and ssh'ed into it since the console is not usable after loading the module.  I had to set the poll_interval module parameter to "1", probably just because I just didn't want to wait until 360 seconds for what I'm guessing would be the first update.

  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Hi Brian,

    Thanks. The drive for me is to get the hardware working.

    Yeah it is updating the battery values way too often. May be the fuel gauge and battery needs some kind of calibration(which I am not sure about).
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points
    So if I understand you correctly, you believe the dmesg flooding is a result of a hardware calibration issue? Is this something you think TI can fix in a couple of day, or do you think it will take substantially longer?
  • 0 in reply to Brian Wrenn
    Guru 13630 points
    I am taking guess. But there is a flow in code to tell if battery is calibrated or not.
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points

    Hi Dwarakesh,

    can we expect a fix for this flaw forthcoming from TI?

  • 0 in reply to Brian Wrenn
    Guru 13630 points

    Hi Brian,

    You can post this query to battery management forum of e2e regarding it. You will get help.

  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Hi Brian,

    If you have made progress in Linux driver,please close this issue and open regarding the continuous interrupt or uevent in battery management forum.
  • 0 in reply to Dwarakesh Radhakrishnan
    Intellectual 430 points

    The TI support reps in that forum only provided this answer:

    Calibration won't affect interrupts to the extent that the gauge will issue interrupts continuously. You can check the gauge configuration and your hardware for correct interrupt signaling.

  • 0 in reply to Brian Wrenn
    Intellectual 430 points
    I have found the answer to the syslog overflow problem. Apparently, kernel config items can cause this with the presence of an I2C or power supply device, the bq27421-g1 being both of those.

    CONFIG_POWER_SUPPLY_DEBUG
    CONFIG_I2C_DEBUG_CORE

    bugs.freedesktop.org/show_bug.cgi

    This URL indicates that to avoid this disable one of those two config items. I only had CONFIG_POWER_SUPPLY_DEBUG enabled, and the problem existed. I had to disable it while already having CONFIG_I2C_DEBUG_CORE disabled to get rid of the problem.

    I still have to determine how to configure this driver for the battery we will use in our system, so I'm not done with this issue yet, but getting closer.
  • 0 in reply to Brian Wrenn
    Intellectual 430 points

    I'm posting this a summary of my findings in getting this driver to work.

    Platform

    Variscite SD410 running Debian/Linaro 4.4.9 w/ PREEMPT-RT patch 17

    Item 1: device tree modifications.

    Within the i2c node on which the BQ27421-G1 resides, add the following

    <your i2c node> {

    ...

    clock-frequency = <100000>; /* !!!tng6-add */

    ...

    bq27421@55 {

    compatible = "ti,bq27421";

    reg = <0x55>;

    };

    ...

    };

    Item 2: First patch to apply to bq27xxx_battery.c

    Add the following lines

    #ifdef CONFIG_OF

    static const struct of_device_id bq27xxx_battery_i2c_of_match_table[] = {

    { .compatible = "ti,bq27200" },

    { .compatible = "ti,bq27210" },

    { .compatible = "ti,bq27500" },

    { .compatible = "ti,bq27510" },

    { .compatible = "ti,bq27520" },

    { .compatible = "ti,bq27530" },

    { .compatible = "ti,bq27531" },

    { .compatible = "ti,bq27541" },

    { .compatible = "ti,bq27542" },

    { .compatible = "ti,bq27546" },

    { .compatible = "ti,bq27742" },

    { .compatible = "ti,bq27545" },

    { .compatible = "ti,bq27421" },

    { .compatible = "ti,bq27425" },

    { .compatible = "ti,bq27441" },

    { .compatible = "ti,bq27621" },

    {},

    };

    MODULE_DEVICE_TABLE(of, bq27xxx_battery_i2c_of_match_table);

    #endif

    Add the line with the comment notation.

    static struct i2c_driver bq27xxx_battery_i2c_driver = {
    .driver = {
    .name = "bq27xxx-battery",
    .of_match_table = of_match_ptr(bq27xxx_battery_i2c_of_match_table), // ADD THIS LINE FOR THE PATCH
    },
    .probe = bq27xxx_battery_i2c_probe,
    .remove = bq27xxx_battery_i2c_remove,
    .id_table = bq27xxx_id,
    };

    Item 3: Second patch to apply to bq27xxx_battery.c

    See link: marc.info/

    Note that if you apply the previous patch before this one, your line numbers will differ, but you can probably figure out where to put the mods just by inspecting the source.  That's what I did.

    Item 4: Third patch to apply to bq27xxx_battery.c

    See link: patchwork.kernel.org/.../

    Again, note that if you apply the previous patch before this one, your line numbers will differ.

    Item 5: Disable power supply and i2c debugging kernel options

    See link: bugs.freedesktop.org/show_bug.cgi

    This will avert a bug that causes the syslog to overflow.

  • 0 in reply to Brian Wrenn
    Guru 13630 points
    Hi Brian,

    Thanks for sharing detailed reply explaining how you got it working. Can you close the issue, with your above post as the answer.