On Mon, 30 Oct 2017 09:26:33 +0100 Peter Rosin <peda@xxxxxxxxxx> wrote: > Hi! > > We have a device with a series of rechargeable batteries. > > The chargers are bq24725 and the batteries have a thermistor > for temperature monitoring. This thermistor is connected to > a standard adc component (ads1015). Immediate thought is that we need to represent this device explicitly. So for this we have the existing drivers/hwmon/ntc_thermistor driver. > This means that the value > the kernel knows for the temperature is in volts (from the > iio driver). We can also monitor the charging current and the > battery voltage for each battery/charger (also with that very > same adc). A gpio pin indicates if external AC power is present. A little nasty but not really in IIO scope. I presume there are other devices with AC connection monitoring as a gpio that is polled? Would probably expect that to be a extcon driver perhaps? > This gpio pin has to be polled, i.e. it is not possible to hook > up interrupts for it. > > We currently have this "working" without the concept of neither > battery nor charger manager in the kernel. It is all handled > from user space by writing to > > /sys/class/power_supply/bq24735@<i2c-bus-and-addr>/status > > to en-/disable charging and by monitoring the adc voltages > and doing the unit conversion to degrees Celsius in user space. > > IIUC, ideally there should be in-kernel charger-managers and > battery objects for each charger/battery. Potentially a generic charger manager might work well. > > I wonder if there is any existing way to do the non-linear > conversion from the iio-adc volt-reading of the thermistor to > the desired unit of degrees-celsius, or if I need to write > something myself? Table and interpolation based in the above mentioned driver. > > I do see the generic-adc-battery driver, which sounds about > right, but it has no DT binding and it also has its > cal_charge() callback which is presumably difficult to handle > from DT? We have no way to get at the battery charge level, > short of inaccurate guesses based on the battery voltage. The > driver also appears to have no concept of battery temperature, > but I suppose it could be extended with that? Not sure if it's > even applicable, I'm fumbling... Potentially you could probably make it work. There will need to be some sort of platform specific glue driver to pull it all together That glue driver could then register an instance of generic adc battery and provide the necessary platform data. How that connects everything together could be handled via dt bindings. > > I may have completely misunderstood how this is supposed to be > hooked up in an ideal world. Nope, just at tricky problem to solve neatly ;) Jonathan > > Cheers, > Peter > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" > in the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
