| Message ID | 1423088075-10025-4-git-send-email-marek@goldelico.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
Hi, On Wed, Feb 04, 2015 at 11:14:32PM +0100, Marek Belisko wrote: > + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values > + for charging calibration (see example) > + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values > + for discharging calibration (see example) Please prefix these properties with "ti," -- Sebastian
On Wed 2015-02-04 23:14:32, Marek Belisko wrote: > Signed-off-by: Marek Belisko <marek@goldelico.com> > --- > .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++ > 1 file changed, 43 insertions(+) > create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt > > diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt > new file mode 100644 > index 0000000..bb3580c > --- /dev/null > +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt > @@ -0,0 +1,43 @@ > +twl4030_madc_battery > + > +Required properties: > + - compatible : "ti,twl4030-madc-battery" > + - capacity-uah : battery capacity in uAh Could we make it capacity-uAh ? > + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values > + for charging calibration (see example) > + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values > + for discharging calibration (see example) Would "mV-to-capacity..." be more accurate? Also, would it make sense to introduce coefficients for temperature and discharge rate? Thanks, Pavel
On Mon, Mar 16, 2015 at 10:05 PM, Pavel Machek <pavel@ucw.cz> wrote: > On Wed 2015-02-04 23:14:32, Marek Belisko wrote: >> Signed-off-by: Marek Belisko <marek@goldelico.com> >> --- >> .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++ >> 1 file changed, 43 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt >> >> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt >> new file mode 100644 >> index 0000000..bb3580c >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt >> @@ -0,0 +1,43 @@ >> +twl4030_madc_battery >> + >> +Required properties: >> + - compatible : "ti,twl4030-madc-battery" >> + - capacity-uah : battery capacity in uAh > > Could we make it capacity-uAh ? This name was suggested by Mark Rutland [1] and naming convention should be all lowercase. There exists already bindings without uppercase (e.g. ti,bb-uamp) so I would keep it consistent. > >> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values >> + for charging calibration (see example) >> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values >> + for discharging calibration (see example) > > Would "mV-to-capacity..." be more accurate? Also, would it make sense Again maybe mv but it can be added also later. > to introduce coefficients for temperature and discharge rate? What do you mean? Nothing like that is used in current driver why do we need to add it? > > Thanks, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [1] - http://lists.openwall.net/linux-kernel/2014/10/09/104 BR, marek
Am 16.03.2015 um 22:20 schrieb Belisko Marek <marek.belisko@gmail.com>: > On Mon, Mar 16, 2015 at 10:05 PM, Pavel Machek <pavel@ucw.cz> wrote: >> On Wed 2015-02-04 23:14:32, Marek Belisko wrote: >>> Signed-off-by: Marek Belisko <marek@goldelico.com> >>> --- >>> .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++ >>> 1 file changed, 43 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt >>> >>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt >>> new file mode 100644 >>> index 0000000..bb3580c >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt >>> @@ -0,0 +1,43 @@ >>> +twl4030_madc_battery >>> + >>> +Required properties: >>> + - compatible : "ti,twl4030-madc-battery" >>> + - capacity-uah : battery capacity in uAh >> >> Could we make it capacity-uAh ? > This name was suggested by Mark Rutland [1] and naming convention > should be all lowercase. There exists already bindings > without uppercase (e.g. ti,bb-uamp) so I would keep it consistent. >> >>> + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values >>> + for charging calibration (see example) >>> + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values >>> + for discharging calibration (see example) >> >> Would "mV-to-capacity..." be more accurate? Also, would it make sense > Again maybe mv but it can be added also later. >> to introduce coefficients for temperature and discharge rate? > What do you mean? Nothing like that is used in current driver why do > we need to add it? Temperature calibration should have already been done in the underlaying twl4030 iio driver. Discharge rate is the real current flow reported in uA. Also reported by iio. >> >> Thanks, >> Pavel >> -- >> (english) http://www.livejournal.com/~pavelmachek >> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > [1] - http://lists.openwall.net/linux-kernel/2014/10/09/104 > > BR, > > marek > BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Temperature calibration should have already been done in the underlaying twl4030 iio driver. > > Discharge rate is the real current flow reported in uA. Also > reported by iio. Ack, but there's rather severe temperature dependency of the lithium battery, which you should take into account if you want to compute "percentage charged". Pavel
Hi, Am 17.03.2015 um 09:47 schrieb Pavel Machek <pavel@ucw.cz>: > Hi! > >>>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt >>>> new file mode 100644 >>>> index 0000000..bb3580c >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt >>>> @@ -0,0 +1,43 @@ >>>> +twl4030_madc_battery >>>> + >>>> +Required properties: >>>> + - compatible : "ti,twl4030-madc-battery" >>>> + - capacity-uah : battery capacity in uAh >>> >>> Could we make it capacity-uAh ? >> This name was suggested by Mark Rutland [1] and naming convention >> should be all lowercase. There exists already bindings >> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent. > > Messing up SI units due to "convention" is _stupid_. Don't do it. > >>> to introduce coefficients for temperature and discharge rate? >> What do you mean? Nothing like that is used in current driver why do >> we need to add it? > > Well, conversion between Li-ion's voltage and state of charge at 0 > current is well known: We can’t measure at 0 current since the OMAP is driven from battery and charger and may also draw some mA… > > def percent(m, v): > u = 0.0387-(1.4523*(3.7835-v)) > if u < 0: > return 0 > return (0.1966+math.sqrt(u))*100 > > And there's not much to calibrate there, and it should become library > helper function; there's no need to write it to every single dts. > > The charge/discharge difference is due to internal battery resistance, > and Ohm's law. (Then, you should not need different values for > charging/discharging case.) Yes, and that also depends on the board and battery type. So you always need to specify some battery specific coefficient for that in the DT. We simply did choose a table, because calculating the right coefficients is more complex and getting the table values can easily be done from running one full charge-discharge-charge cycle. > > With your aproach, you'll get lower percentage when phone is under > load vs. idle. Taking internal resistance into account would give you > more precise readings. (Attached, old patch for zaurus shows the > needed computation). This is why we have a charging and a discharging table to compensate for this effect. > > And if you wanted even more precise readings... internal resistance > depends on temperature. We don’t necessarily know the real battery temperature. > > I guess this should go into library somewhere, because many machines > need similar code. Is a library easier to maintain and handle than just a set of table values? Anyways it ends up in a representation of a mapping function with two input parameters (voltage and charge/discharge indication). My proposal: keep it simple for everybody. And I can’t imagine something easier than a mapping table. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 17.03.2015 um 09:48 schrieb Pavel Machek <pavel@ucw.cz>: >> >> Temperature calibration should have already been done in the underlaying twl4030 iio driver. >> >> Discharge rate is the real current flow reported in uA. Also >> reported by iio. > > Ack, but there's rather severe temperature dependency of the lithium > battery, which you should take into account if you want to compute > “percentage charged". We just want to estimate it as good as possible. 5-10% is sufficient and better than no value at all (which is what you get without this driver). And, we just convert the (existing) driver from non-DT to DT and to use iio, so we do not want to change the inner logic what it does and how it works. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 17.03.2015 um 09:47 schrieb Pavel Machek <pavel@ucw.cz>: > Hi! > >>>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt >>>> new file mode 100644 >>>> index 0000000..bb3580c >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt >>>> @@ -0,0 +1,43 @@ >>>> +twl4030_madc_battery >>>> + >>>> +Required properties: >>>> + - compatible : "ti,twl4030-madc-battery" >>>> + - capacity-uah : battery capacity in uAh >>> >>> Could we make it capacity-uAh ? >> This name was suggested by Mark Rutland [1] and naming convention >> should be all lowercase. There exists already bindings >> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent. > > Messing up SI units due to "convention" is _stupid_. Don't do it. > >>> to introduce coefficients for temperature and discharge rate? >> What do you mean? Nothing like that is used in current driver why do >> we need to add it? > > Well, conversion between Li-ion's voltage and state of charge at 0 > current is well known: > > def percent(m, v): > u = 0.0387-(1.4523*(3.7835-v)) > if u < 0: > return 0 > return (0.1966+math.sqrt(u))*100 I forgot to ask: does the kernel have a sqrt() function? > > And there's not much to calibrate there, and it should become library > helper function; there's no need to write it to every single dts. > > The charge/discharge difference is due to internal battery resistance, > and Ohm's law. (Then, you should not need different values for > charging/discharging case.) > > With your aproach, you'll get lower percentage when phone is under > load vs. idle. Taking internal resistance into account would give you > more precise readings. (Attached, old patch for zaurus shows the > needed computation). > > And if you wanted even more precise readings... internal resistance > depends on temperature. > > I guess this should go into library somewhere, because many machines > need similar code. > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > <zbattery.10.diff> -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue 2015-03-17 10:07:12, Dr. H. Nikolaus Schaller wrote: > > Am 17.03.2015 um 09:47 schrieb Pavel Machek <pavel@ucw.cz>: > > > Hi! > > > >>>> diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt > >>>> new file mode 100644 > >>>> index 0000000..bb3580c > >>>> --- /dev/null > >>>> +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt > >>>> @@ -0,0 +1,43 @@ > >>>> +twl4030_madc_battery > >>>> + > >>>> +Required properties: > >>>> + - compatible : "ti,twl4030-madc-battery" > >>>> + - capacity-uah : battery capacity in uAh > >>> > >>> Could we make it capacity-uAh ? > >> This name was suggested by Mark Rutland [1] and naming convention > >> should be all lowercase. There exists already bindings > >> without uppercase (e.g. ti,bb-uamp) so I would keep it consistent. > > > > Messing up SI units due to "convention" is _stupid_. Don't do it. > > > >>> to introduce coefficients for temperature and discharge rate? > >> What do you mean? Nothing like that is used in current driver why do > >> we need to add it? > > > > Well, conversion between Li-ion's voltage and state of charge at 0 > > current is well known: > > > > def percent(m, v): > > u = 0.0387-(1.4523*(3.7835-v)) > > if u < 0: > > return 0 > > return (0.1966+math.sqrt(u))*100 > > I forgot to ask: does the kernel have a sqrt() function? This could be good enough. https://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0/2.6.0-mm1/broken-out/fix-sqrt.patch Pavel
Hi! > >>> to introduce coefficients for temperature and discharge rate? > >> What do you mean? Nothing like that is used in current driver why do > >> we need to add it? > > > > Well, conversion between Li-ion's voltage and state of charge at 0 > > current is well known: > > We can’t measure at 0 current since the OMAP is driven from battery > and charger and may also draw some mA… Yes, but you know how many mA you are taking just now. So if you knew the internal resistance, you could compute the voltage at 0 current. (And it should also work during charging, as long as you know how much current is going in.) > > def percent(m, v): > > u = 0.0387-(1.4523*(3.7835-v)) > > if u < 0: > > return 0 > > return (0.1966+math.sqrt(u))*100 > > > > And there's not much to calibrate there, and it should become library > > helper function; there's no need to write it to every single dts. > > > > The charge/discharge difference is due to internal battery resistance, > > and Ohm's law. (Then, you should not need different values for > > charging/discharging case.) > > Yes, and that also depends on the board and battery type. So you always > need to specify some battery specific coefficient for that in the DT. Yes, and that coefficient should be internal battery resistance ;-). > We simply did choose a table, because calculating the right coefficients > is more complex and getting the table values can easily be done from > running one full charge-discharge-charge cycle. Well.. One set of coefficients would be kind of ok. But you are doing two, because it really depends on current, not charge/discharge. So why not do it right, for all currents...? > > With your aproach, you'll get lower percentage when phone is under > > load vs. idle. Taking internal resistance into account would give you > > more precise readings. (Attached, old patch for zaurus shows the > > needed computation). > > This is why we have a charging and a discharging table to compensate > for this effect. Yes, but there's very different current during "idle" phone and during call (for example). So yes, you are compensating for different current during charge and discharge, but it is possible to do better. > > I guess this should go into library somewhere, because many machines > > need similar code. > > Is a library easier to maintain and handle than just a set of table > values? I think so, yes, because otherwise you need a set of tables for each machine. Pavel
Hi Pavel, Am 17.03.2015 um 11:37 schrieb Pavel Machek <pavel@ucw.cz>: > Hi! > >>>>> to introduce coefficients for temperature and discharge rate? >>>> What do you mean? Nothing like that is used in current driver why do >>>> we need to add it? >>> >>> Well, conversion between Li-ion's voltage and state of charge at 0 >>> current is well known: >> >> We can’t measure at 0 current since the OMAP is driven from battery >> and charger and may also draw some mA… > > Yes, but you know how many mA you are taking just now. So if you knew > the internal resistance, you could compute the voltage at 0 > current. (And it should also work during charging, as long as you know > how much current is going in.) As far as I understand the twl4030 charger and MADC it is not possible to separate these values. It is only reporting the inflow from charger to battery + system. So you don’t know how many mA are supplying the system and how many mA are left over for charging. You can only assume how much the system is drawing while running (something between 50 and 600 mA but this depends on system activities, power state of peripherald and e.g. backlight being switched on). I think your basic assumption that we know any time how many mA the system is taking is not given. > >>> def percent(m, v): >>> u = 0.0387-(1.4523*(3.7835-v)) >>> if u < 0: >>> return 0 >>> return (0.1966+math.sqrt(u))*100 >>> >>> And there's not much to calibrate there, and it should become library >>> helper function; there's no need to write it to every single dts. >>> >>> The charge/discharge difference is due to internal battery resistance, >>> and Ohm's law. (Then, you should not need different values for >>> charging/discharging case.) >> >> Yes, and that also depends on the board and battery type. So you always >> need to specify some battery specific coefficient for that in the DT. > > Yes, and that coefficient should be internal battery resistance ;-). But where do you know this value from to write it into a DT file? Usually you can’t measure it easily and for some batteries you don’t have a data sheet. Contrary, the calibration curves can easily be measured on the device (assuming that the charge level decreases/increases linearly over time between Full and Empty). I tend to make software easy to use for the user (developer of a board support package) of a driver, not theoretically correct or mathematically elegant. > >> We simply did choose a table, because calculating the right coefficients >> is more complex and getting the table values can easily be done from >> running one full charge-discharge-charge cycle. > > Well.. One set of coefficients would be kind of ok. But you are doing > two, because it really depends on current, not charge/discharge. So > why not do it right, for all currents…? Because the right solution for all these issues is to use a fuel gauge chip (bq27xxx). This driver is just for systems where the hardware designer did forget (or did not want to spend money) for such a chip, but user space expects some /sys/class/power_supply indication (e.g. Android/Replicant). The missing optimal precision is something we can live with. > >>> With your aproach, you'll get lower percentage when phone is under >>> load vs. idle. Taking internal resistance into account would give you >>> more precise readings. (Attached, old patch for zaurus shows the >>> needed computation). >> >> This is why we have a charging and a discharging table to compensate >> for this effect. > > Yes, but there's very different current during "idle" phone and during > call (for example). So yes, you are compensating for different current > during charge and discharge, but it is possible to do better. I am not convinced that it can be really done better, considering the limitations of the twl4030 circuits, and I doubt that it is worth the efforts of doing it better. > >>> I guess this should go into library somewhere, because many machines >>> need similar code. >> >> Is a library easier to maintain and handle than just a set of table >> values? > > I think so, yes, because otherwise you need a set of tables for each > machine. Yes, but what is the problem? We have different device trees for each machine anyways. And as soon as they differ in battery characteristics the coefficients for your calculation have to be defined for each machine. So someone has to write in some DT values (difficult to understand and derive coefficients or two simple mapping tables). To me it looks as if you want to make it a 100% solution while I am happy with the 80% solution, which already exists as a platform data driver and just want to get it back into DT based boards. So I would suggest that Mareks patches to make the platform data driver DT compatible are applied first, and you are invited to submit a technically better solution for testing on real hardware. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi! > >>>>> to introduce coefficients for temperature and discharge rate? > >>>> What do you mean? Nothing like that is used in current driver why do > >>>> we need to add it? > >>> > >>> Well, conversion between Li-ion's voltage and state of charge at 0 > >>> current is well known: > >> > >> We can’t measure at 0 current since the OMAP is driven from battery > >> and charger and may also draw some mA… > > > > Yes, but you know how many mA you are taking just now. So if you knew > > the internal resistance, you could compute the voltage at 0 > > current. (And it should also work during charging, as long as you know > > how much current is going in.) > > As far as I understand the twl4030 charger and MADC it is not possible to > separate these values. It is only reporting the inflow from charger to > battery + system. So you don’t know how many mA are supplying the system > and how many mA are left over for charging. > > You can only assume how much the system is drawing while running (something > between 50 and 600 mA but this depends on system activities, power state > of peripherald and e.g. backlight being switched on). > > I think your basic assumption that we know any time how many mA the system > is taking is not given. So.. you won't be able to get exact value while charging, but you get one while discharging, which is what really matters...? > > Yes, and that coefficient should be internal battery resistance ;-). > > But where do you know this value from to write it into a DT file? > Usually you can’t measure it easily and for some batteries you don’t have > a data sheet. > > Contrary, the calibration curves can easily be measured on the device > (assuming that the charge level decreases/increases linearly over time > between Full and Empty). If you can copy it from the data sheet, that's the easiest option. If not, you should be able to easily compute it from the charge/discharge curves or from measured voltage at different loads. Pavel
Hi Pavel, Am 17.03.2015 um 14:59 schrieb Pavel Machek <pavel@ucw.cz>: > Hi! > >>>>>>> to introduce coefficients for temperature and discharge rate? >>>>>> What do you mean? Nothing like that is used in current driver why do >>>>>> we need to add it? >>>>> >>>>> Well, conversion between Li-ion's voltage and state of charge at 0 >>>>> current is well known: >>>> >>>> We can’t measure at 0 current since the OMAP is driven from battery >>>> and charger and may also draw some mA… >>> >>> Yes, but you know how many mA you are taking just now. So if you knew >>> the internal resistance, you could compute the voltage at 0 >>> current. (And it should also work during charging, as long as you know >>> how much current is going in.) >> >> As far as I understand the twl4030 charger and MADC it is not possible to >> separate these values. It is only reporting the inflow from charger to >> battery + system. So you don’t know how many mA are supplying the system >> and how many mA are left over for charging. >> >> You can only assume how much the system is drawing while running (something >> between 50 and 600 mA but this depends on system activities, power state >> of peripherald and e.g. backlight being switched on). >> >> I think your basic assumption that we know any time how many mA the system >> is taking is not given. > > So.. you won't be able to get exact value while charging, but you > get one while discharging, which is what really matters…? Is it the same during charging? And, as we already discussed it depends on the situation. In addition, GSM power consumption runs in bursts and I don’t know if the sample rate of the MADC is good enough to track that correctly. > >>> Yes, and that coefficient should be internal battery resistance ;-). >> >> But where do you know this value from to write it into a DT file? >> Usually you can’t measure it easily and for some batteries you don’t have >> a data sheet. >> >> Contrary, the calibration curves can easily be measured on the device >> (assuming that the charge level decreases/increases linearly over time >> between Full and Empty). > > If you can copy it from the data sheet, that's the easiest option. If > not, you should be able to easily compute it from the charge/discharge > curves or from measured voltage at different loads. Well, this again assumes that you can generate/control different loads easily (e.g. turn on/off this and that peripheral) to check the voltage drop. Sounds good in theory, but I don’t want to do it in practice to derive this parameter. And, don’t forget that the MADC signals are nosiy and don’t have the best precision. So it is likely that you get wrong values. As said, I think it is not worth the effort around the imperfect twl4030/MADC charging system. If someone wants precise data, that is what fuel gauge chips are good for. And we already have drivers for them. BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt new file mode 100644 index 0000000..bb3580c --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt @@ -0,0 +1,43 @@ +twl4030_madc_battery + +Required properties: + - compatible : "ti,twl4030-madc-battery" + - capacity-uah : battery capacity in uAh + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values + for charging calibration (see example) + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values + for discharging calibration (see example) + - io-channels: Should contain IIO channel specifiers + for each element in io-channel-names. +- io-channel-names: Should contain the following values: + * "temp" - The ADC channel for temperature reading + * "ichg" - The ADC channel for battery charging status + * "vbat" - The ADC channel to measure the battery voltage + +Example: + madc-battery { + compatible = "ti,twl4030-madc-battery"; + capacity-uah = <1200000>; + volt-to-capacity-charging-map = <4200 100>, + <4100 75>, + <4000 55>, + <3900 25>, + <3800 5>, + <3700 2>, + <3600 1>, + <3300 0>; + + volt-to-capacity-discharging-map = <4200 100> + <4100 95>, + <4000 70>, + <3800 50>, + <3700 10>, + <3600 5>, + <3300 0>; + io-channels = <&twl_madc 1>, + <&twl_madc 10>, + <&twl_madc 12>; + io-channel-names = "temp", + "ichg", + "vbat"; + };
Signed-off-by: Marek Belisko <marek@goldelico.com> --- .../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt