Linux/BQ25898D: BQ25898D

We do not have bq25898D driver. The closest drive is that of bq25898. The key differences between the two devices are bq25898D use D+/D- for input limit detection while bq25898 use PSEL. The drivers are located at https://github.com/tibms?tab=repositories. Hope the information helps. Thanks!

Hi Ning,

have you tried to compile this driver against the Linux 4.4.9 kernel?  If not, which kernel did you use?  My attempt against 4.4.9 to build this driver failed.  See attachment.  It has the Makefile I used and the compilation errors.

Thanks,

Brian

ning-archive1.zip

Hi Brian,

I just now checked till 4.0, struct power_supply was the structure. Later they have split it into struct power_supply_desc and moved them into it

Can you try whichever variable is not in power_supply, change them as
e.g. bq->usb.num_properties into

struct power_supply ps = bq->usb

ps.desc.num_properties= ARRAY_SIZE(bq2589x_charger_props);

I have not tested. Just a way to see if it is working.

Hi Dwarakesh,

I attempted to run with a modified version of the bq25890_charger.c, since it resides within mainline.  I only needed to make some minor modifications to successfully build.  However, when I attempt load the .ko I get this error message.

[10726.835113] bq25890-charger 1-006a: Could not probe irq pin.

[10726.840166] bq25890-charger 1-006a: No irq resource found.

[10726.846329] bq25890-charger: probe of 1-006a failed with error -2

The function call to devm_gpiod_get_index() fails, and I'm not sure why.

FWIW, here's a snippet of my device tree config.

blsp_i2c6: i2c@78ba000 {

...

bq25890@6a {

compatible = "ti,bq25890";
reg = <0x6a>;
ti,battery-regulation-voltage = <4200000>;
ti,charge-current = <1000000>;
ti,termination-current = <50000>;
ti,precharge-current = <128000>;
ti,minimum-sys-voltage = <3600000>;
ti,boost-voltage = <5000000>;
ti,boost-max-current = <1000000>;
ti,use-ilim-pin;
ti,thermal-regulation-threshold = <120>;
};

};

Do you think it's better to pursue to the bq25890 driver route or the bq25898 route.  The latter seems like a lot more work if this GPIO error is easily resolved.

Yes, as well as Documentation/devicetree/bindings/interrupt-controller/interrupts.txt, but I don't see anything that associates an IRQ label with a particular GPIO interrupt pin, at least not in a syntax compliant sample.

Does TI have some working example of a device tree config for its BQ25898 driver?

Hi, in the kernel trace in my previous post, the probe method had printk calls added to it, the very first of which executed as the first instruction of the function.  That's why I suspect a problem within the device tree file.

-Brian

Hi Dwarakesh,

(1)

first, I stumbled across something that I think I should explicitly state just to make sure we're on the same page.  I cloned this repo for the driver.

I have also found this driver.

They both look about the same in terms of age, and each one's sample device tree has an example for the BQ25898D.  Does TI recommend one of these over the other?

(2)

I found out why the syslog did not include any of my printk messages.  I had initially created an out-of-tree build before making an in-tree build of this driver, and I had mistakenly modified the out-of-tree source while building the in-tree source.  I now have that resolved and found the cause of the NULL pointer exception in the stack trace previously posted.  However, after done some more debugging, I have another one.

[    4.697776] bq2589x-1 1-006a: bq2589x_charger1_probe:irq = 95

[    4.706432] Unable to handle kernel NULL pointer dereference at virtual address 00000002

...

[    4.803500] PC is at i2c_smbus_read_byte_data+0x10/0x3c

[    4.803569] LR is at bq2589x_read_byte.isra.4+0x44/0xa0

...

[    5.652932] [<ffffffc000085428>] el1_da+0x18/0x70

[    5.652990] [<ffffffc0005e073c>] bq2589x_read_byte.isra.4+0x50/0xac

[    5.653034] [<ffffffc0005e0cd0>] bq2589x_get_vbus_type+0x1c/0x3c

[    5.653037] [<ffffffc0005e0df8>] bq2589x_usb_get_property+0x20/0xa8

[    5.653056] [<ffffffc0005dc3f8>] power_supply_get_property+0x20/0x30

[    5.653087] [<ffffffc0005dda48>] power_supply_update_leds+0x2c/0x190

[    5.653109] [<ffffffc0005dcaa4>] power_supply_changed_work+0x6c/0xdc

[    5.653159] [<ffffffc0000cea44>] process_one_work+0x138/0x304

[    5.653194] [<ffffffc0000ced70>] worker_thread+0x160/0x440

[    5.653205] [<ffffffc0000d42ac>] kthread+0xe0/0xf4

[    5.653235] [<ffffffc000085c50>] ret_from_fork+0x10/0x40

The bq->client member data points to NULL at this location in the source.

static int bq2589x_read_byte(struct bq2589x *bq, u8 *data, u8 reg)
{
int ret;

mutex_lock(&bq2589x_i2c_lock);
ret = i2c_smbus_read_byte_data(bq->client, reg);

So the i2c_set_clientdata(client, bq) call in bq2589x_charger1_probe() does not seem to actually set that data member.

static int bq2589x_charger1_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{

...

bq->dev = &client->dev;

bq->client = client;
i2c_set_clientdata(client, bq);

That's where I am at this point.  But before pursuing #2 any further, I thought I should check in on #1 first.

Thanks,

Brian

I've ported the bq25898_dual driver to Linaro 4.4.9.  It successfully loads, but unfortunately it consumes the console with syslog messages such that it makes the console unusable. E.g.

** 9 printk messages dropped ** [   30.236967] systemd-journald[1493]: /dev/kmsg buffer overrun, some messages lost.

I have observed similar behavior with the BQ27421-D after patching its drivers to make it function on Linaro 4.4.9.  For reference, I have two open cases for that chip.

However, in the case of the BQ25898D, I haven't confirmed that it is performing its core duties  Since this module depends on an external symbol that the kernel build process only exports when built in-tree, I can't build this as a .ko and insert it after initiating a wireless connection.  I don't have wired network support.  I've tried adding a script to /etc/init.d to initiate the wireless connection, but to no avail.  I also tried blacklisting the driver at boot time so that I could make ssh available before loading the driver, but that hasn't worked thus far either.

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 bq25898d being both of those.

CONFIG_POWER_SUPPLY_DEBUG
CONFIG_I2C_DEBUG_CORE

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.

The driver I ported, bq25898_dual.c aborts upon system shutdown, i.e. when the system unregisters the driver, so I still haven't resolved this issue entirely.