Hi Phil

Am Freitag, den 06.05.2016, 15:27 +0800 schrieb Phil Reid:

G'day Karl
On 29/04/2016 03:15, Karl-Heinz Schneider wrote:

quoted

I have written an Kernel driver for the LTC1760 which is basically an
charger which can handle 2 batteries. Datasheet can be found at
http://www.linear.com/product/LTC1760

They're nice chips.

quoted

However, the device has one speciality: Hence it handles two smart
batteries, which are expected to sit on I2C address 0x0b, it implements
an i2c mux. As the device does so, my driver does also (using
i2c_add_mux_adapter() call).
Further more, Linux already ships with an driver capable to talk to
these smart battery chips, namely "sbs-battery".

I currently using device tree to bind the LTC1760 to the smbus it sits
on and further to define the i2c-lines it implements as well as the
batteries sitting on the two muxed lines.

Would you say this approach is technically right? The LTC expects SBS
compliant batteries connected to it, which implies a standard minimal
interface. But binding the batteries via device tree gives the user the
freedom to specify a more specialized driver.
On the other hand one could argue that if the LTC is present, also
batteries are (potentially) present and the LTC driver is responsible to
read the related registers and provide proper PM attributes. Personally
I don't like to rewrite or copy code wich works just fine...

I've been writing a driver for the same chip :).
My system has 2 ltc1760 for a total of 4 batteries.
Haven't completed it as yet so hadn't posted, but got it talking to the batteries.
I implemented an I2c mux in the driver and just attached two sbs-battery's to it in the device tree.
I think the mux is the way to go, simple and reuses existing code.

Think so too.
My version doesn't do very much. It presents the "online" property and
charging state, which is also changeable to fast mode. It has some more
interesting information in it's registers, but don't know how to put
them into standard power_supply properties.

The sbs-battery driver needs a couple of gpio pins to indicate battery presence,
so I was thinking of implementing these in the ltc1760 as gpio pins.
Not sure what the bext approach is here.

Would say that's not necessary. Using the GPIO for the sbs-battery
driver to detect the presence of the battery is purely optional. Indeed
it requests the GPIO as input and tries to make it an interrupt line. If
either step fails, handling the GPIO and interrupt is skipped.

FYI, if you didn't find it there is an acpi only driver for the ltc1760 in the kernel.
But I could see a way to make it work with device trees. It enumerates it's own
batteries.

Indeed I failed to find it. Looked through drivers to find something
similar. How is it named?

I have found the ltc1760 doesn't work to well with some i2c masters.
Currently using the bit bang i2c bus driver as that was the most reliable.
The designware controller kept locking up.

Did guess that could happen. The ltc1760 acts by itself as an I2C master
on it's muxed lines, and if it communicates to the currently selected
battery the masters clock line is held low during this time, preventing
the master from communicating at all. This may lead to time outs on
masters side.

I'm using an IMX6 on an SECO Q7 board, where the ltc is soldered on it's
smbus line. Did you try to reduce I2C speed? Mine is running fine at
100kHz. I don't know if there is a way to adjust time out values of I2C
masters?