Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
Hi! > > > > That said, you may need to use uWh and uAh instead of mAh and mWh, > > > > though. > > > > > > Not sure. Is there any existing chip that can report uAh/uWh? That is > > > great precision. > > > > The way things are going, it should be feasible for small embedded systems > > quite soon. Refer to the previous thread. > > I see... is it also applicable to currents and voltages? I.e. should we > use uA and uV from the start? AFAICT, mobile phone in standby can eat less than 1000 uW... so uA/uV would indeed be nice. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
Hi! That said, you may need to use uWh and uAh instead of mAh and mWh, though. Not sure. Is there any existing chip that can report uAh/uWh? That is great precision. The way things are going, it should be feasible for small embedded systems quite soon. Refer to the previous thread. I see... is it also applicable to currents and voltages? I.e. should we use uA and uV from the start? AFAICT, mobile phone in standby can eat less than 1000 uW... so uA/uV would indeed be nice. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Mon, 2007-04-16 at 07:12 +0400, Anton Vorontsov wrote: > Why? With current battery class we can do whatever everyone needs. No > need for wrappers. > Because of your original design, simple batteries are stay simple, and > no noticing that there is some "complicated" attributes exists at all. > That's indeed great characteristic of that *universal* battery class. Indeed. Im just trying to make sure we dont bloat an otherwise very simple class. A word of caution only. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Mon, 2007-04-16 at 07:12 +0400, Anton Vorontsov wrote: Why? With current battery class we can do whatever everyone needs. No need for wrappers. cut Because of your original design, simple batteries are stay simple, and no noticing that there is some complicated attributes exists at all. That's indeed great characteristic of that *universal* battery class. Indeed. Im just trying to make sure we dont bloat an otherwise very simple class. A word of caution only. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Mon, Apr 16, 2007 at 03:32:54AM +0100, ian wrote: > On Sun, 2007-04-15 at 21:57 -0300, Henrique de Moraes Holschuh wrote: > > > > No, that won't help much. IMO, we want the sanest set of standard > > attributes we can get, and weird as it might be, average reporting are > > common properties of battery control firmware on laptops (maybe > > because of SBS, but still...). > > We need to think very carefully here. > > charge, current, capacity, etc. are properties all batteries have, and > the current values can all be sampled instantaneously. > > funky values processed by 'black box' firmware are not universal > properties of all batteries. > > IOW, battery class should be for 'simple' battery types only. > > perhaps rename it to simple battery class to make it distinct? > > Userspace is the place to put the complications, in any case, and I see > nothing wrong with having both a simple battery class AND other > proprietary battery class an SBS battery class. (or a > toshiba_proprietary_bios battery class or whatever). > > Perhaps we need a 'libbattery.so' so that userspace can have a nice > consistent interface? Why? With current battery class we can do whatever everyone needs. No need for wrappers. Adding new properties is cheap and easy. Simple batteries using only "simple" properties/attributes, and complicated batteries using complicated attributes. Because of your original design, simple batteries are stay simple, and no noticing that there is some "complicated" attributes exists at all. That's indeed great characteristic of that *universal* battery class. For example, ds2760 is not really "simple" monitoring chip. ADC battery is (it's in -hh tree so far). So, ds2760 is somewhere in between SBS design, and dumb ADC batteries. So, my another purposal, which I very like now: Let's do self-documented properties. current_now, current_avg, e.t.c. No more just "current", lets remove any ambiguousness! -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Sun, 2007-04-15 at 21:57 -0300, Henrique de Moraes Holschuh wrote: > > No, that won't help much. IMO, we want the sanest set of standard > attributes we can get, and weird as it might be, average reporting are > common properties of battery control firmware on laptops (maybe > because of SBS, but still...). We need to think very carefully here. charge, current, capacity, etc. are properties all batteries have, and the current values can all be sampled instantaneously. funky values processed by 'black box' firmware are not universal properties of all batteries. IOW, battery class should be for 'simple' battery types only. perhaps rename it to simple battery class to make it distinct? Userspace is the place to put the complications, in any case, and I see nothing wrong with having both a simple battery class AND other proprietary battery class an SBS battery class. (or a toshiba_proprietary_bios battery class or whatever). Perhaps we need a 'libbattery.so' so that userspace can have a nice consistent interface? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
Hello Pavel, On Sun, Apr 15, 2007 at 07:56:56PM +, Pavel Machek wrote: > Hi! > > > * It insists on reusing its predefined attributes *and* their units. > > So, userspace getting expected values for any battery. > > > > Also common units is required for APM/ACPI emulation. > > > > Though our battery class insisting on re-usage, but not forces it. If some > > battery driver can't convert its own raw values (can't imagine why), then > > driver is free to implement its own attributes *and* additional _units > > attribute. Though, this scheme is discouraged. > > > > * LEDs support. Each battery register its trigger, and gadgets with LEDs > > can quickly bind to battery-charging / battery-full triggers. > > > > Here how it looks like from user space: > > > > # ls /sys/class/battery/main-battery/ > > capacity max_capacity max_voltage min_current power subsystem uevent > > current max_current min_capacity min_voltage status temp > > voltage > > # cat /sys/class/battery/main-battery/status > > Full > > # cat /sys/class/leds/h5400\:green-right/trigger > > none h5400-radio timer hwtimer main-battery-charging [main-battery-full] > > # cat /sys/class/leds/h5400\:green-right/brightness > > 255 > > Can we get few lines in Documentation? Yes, sure. > I guess min_capacity is > shutdown capacity at current temperature, but its surely non-obvious. > > Will min_capacity increase as batery gets old? Or will max_capacity > decrease? min_capacity and max_capacity depend on temperature. But some drivers can/want to interpolate, others can't/don't want. It's driver's matter. ds2760_battery just remembers last capacity when current was < 10 mA (i.e. battery charged full at given temperature) as max_capacity, and takes this as reference for calculations. > (Should we introduce design_capacity for ACPI systems that > know the difference?) Yup, I've introduced it in [take2] (it's in this thread, thus it's hard to find). Will resend it as separate thread soon, along with few other changes. > What is min_current? Granularity of amper meter? > > And min_voltage is shutdown voltage? Yes, should be. But, for example, ds2760 battery can't remember this value in its eeprom (iirc), thus this value passed by platform code, i.e. in our case (iPaqs) it's machine dependent value. Probably we should not even export this attribute in ds2760_battery driver, as it does not take any part in calculations. Plus this attribute highly depend on battery chemistry and temperature. Thus it's hardly anyhow useful, except if hardware itself reports it (not ds2760 case). > Otherwise it looks good to me. Something like this is really needed. Thanks! > > + * All voltages, currents, capacities and temperatures in mV, mA, mAh and > > + * tenths of a degree unless otherwise stated. It's driver's job to convert > > tenths of degree Celsius? Yup, fixed in [take2]. > > +#define BATTERY_STATUS_UNKNOWN 0 > > +#define BATTERY_STATUS_CHARGING 1 > > +#define BATTERY_STATUS_DISCHARGING 2 > > +#define BATTERY_STATUS_NOT_CHARGING 3 > > +#define BATTERY_STATUS_FULL 4 > > Perhaps we need STATUS_ERROR? At least on some machines it is > different from STATUS_NOT_CHARGING. I'm unsure about this. BATTERY_STATUS_* is mostly about charging process status (should I rename it to more verbose BATTERY_CHARGING_STATUS_, or just mention it in Documentation?). For errors things it might be better to create "health" attribute. > > + /* private */ > > + struct power_supplicant pst; > > + > > + #ifdef CONFIG_LEDS_TRIGGERS > > + struct led_trigger *charging_trig; > > + char *charging_trig_name; > > + struct led_trigger *full_trig; > > + char *full_trig_name; > > + #endif > > +}; > > #ifdefs need to be at column 0? Yup, fixed in [take2]. > > +/* > > + * This is recommended structure to specify static battery parameters. > > + * Generic one, parametrizable for different batteries. Battery device > > + * itself does bot use it, but that's what implementing most drivers, > > 'does not'? Thanks, will fix! > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Sun, 2007-04-15 at 21:57 -0300, Henrique de Moraes Holschuh wrote: No, that won't help much. IMO, we want the sanest set of standard attributes we can get, and weird as it might be, average reporting are common properties of battery control firmware on laptops (maybe because of SBS, but still...). We need to think very carefully here. charge, current, capacity, etc. are properties all batteries have, and the current values can all be sampled instantaneously. funky values processed by 'black box' firmware are not universal properties of all batteries. IOW, battery class should be for 'simple' battery types only. perhaps rename it to simple battery class to make it distinct? Userspace is the place to put the complications, in any case, and I see nothing wrong with having both a simple battery class AND other proprietary battery class an SBS battery class. (or a toshiba_proprietary_bios battery class or whatever). Perhaps we need a 'libbattery.so' so that userspace can have a nice consistent interface? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Mon, Apr 16, 2007 at 03:32:54AM +0100, ian wrote: On Sun, 2007-04-15 at 21:57 -0300, Henrique de Moraes Holschuh wrote: No, that won't help much. IMO, we want the sanest set of standard attributes we can get, and weird as it might be, average reporting are common properties of battery control firmware on laptops (maybe because of SBS, but still...). We need to think very carefully here. charge, current, capacity, etc. are properties all batteries have, and the current values can all be sampled instantaneously. funky values processed by 'black box' firmware are not universal properties of all batteries. IOW, battery class should be for 'simple' battery types only. perhaps rename it to simple battery class to make it distinct? Userspace is the place to put the complications, in any case, and I see nothing wrong with having both a simple battery class AND other proprietary battery class an SBS battery class. (or a toshiba_proprietary_bios battery class or whatever). Perhaps we need a 'libbattery.so' so that userspace can have a nice consistent interface? Why? With current battery class we can do whatever everyone needs. No need for wrappers. Adding new properties is cheap and easy. Simple batteries using only simple properties/attributes, and complicated batteries using complicated attributes. Because of your original design, simple batteries are stay simple, and no noticing that there is some complicated attributes exists at all. That's indeed great characteristic of that *universal* battery class. For example, ds2760 is not really simple monitoring chip. ADC battery is (it's in -hh tree so far). So, ds2760 is somewhere in between SBS design, and dumb ADC batteries. So, my another purposal, which I very like now: Let's do self-documented properties. current_now, current_avg, e.t.c. No more just current, lets remove any ambiguousness! -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
Hello Pavel, On Sun, Apr 15, 2007 at 07:56:56PM +, Pavel Machek wrote: Hi! * It insists on reusing its predefined attributes *and* their units. So, userspace getting expected values for any battery. Also common units is required for APM/ACPI emulation. Though our battery class insisting on re-usage, but not forces it. If some battery driver can't convert its own raw values (can't imagine why), then driver is free to implement its own attributes *and* additional _units attribute. Though, this scheme is discouraged. * LEDs support. Each battery register its trigger, and gadgets with LEDs can quickly bind to battery-charging / battery-full triggers. Here how it looks like from user space: # ls /sys/class/battery/main-battery/ capacity max_capacity max_voltage min_current power subsystem uevent current max_current min_capacity min_voltage status temp voltage # cat /sys/class/battery/main-battery/status Full # cat /sys/class/leds/h5400\:green-right/trigger none h5400-radio timer hwtimer main-battery-charging [main-battery-full] # cat /sys/class/leds/h5400\:green-right/brightness 255 Can we get few lines in Documentation? Yes, sure. I guess min_capacity is shutdown capacity at current temperature, but its surely non-obvious. Will min_capacity increase as batery gets old? Or will max_capacity decrease? min_capacity and max_capacity depend on temperature. But some drivers can/want to interpolate, others can't/don't want. It's driver's matter. ds2760_battery just remembers last capacity when current was 10 mA (i.e. battery charged full at given temperature) as max_capacity, and takes this as reference for calculations. (Should we introduce design_capacity for ACPI systems that know the difference?) Yup, I've introduced it in [take2] (it's in this thread, thus it's hard to find). Will resend it as separate thread soon, along with few other changes. What is min_current? Granularity of amper meter? And min_voltage is shutdown voltage? Yes, should be. But, for example, ds2760 battery can't remember this value in its eeprom (iirc), thus this value passed by platform code, i.e. in our case (iPaqs) it's machine dependent value. Probably we should not even export this attribute in ds2760_battery driver, as it does not take any part in calculations. Plus this attribute highly depend on battery chemistry and temperature. Thus it's hardly anyhow useful, except if hardware itself reports it (not ds2760 case). Otherwise it looks good to me. Something like this is really needed. Thanks! + * All voltages, currents, capacities and temperatures in mV, mA, mAh and + * tenths of a degree unless otherwise stated. It's driver's job to convert tenths of degree Celsius? Yup, fixed in [take2]. +#define BATTERY_STATUS_UNKNOWN 0 +#define BATTERY_STATUS_CHARGING 1 +#define BATTERY_STATUS_DISCHARGING 2 +#define BATTERY_STATUS_NOT_CHARGING 3 +#define BATTERY_STATUS_FULL 4 Perhaps we need STATUS_ERROR? At least on some machines it is different from STATUS_NOT_CHARGING. I'm unsure about this. BATTERY_STATUS_* is mostly about charging process status (should I rename it to more verbose BATTERY_CHARGING_STATUS_, or just mention it in Documentation?). For errors things it might be better to create health attribute. + /* private */ + struct power_supplicant pst; + + #ifdef CONFIG_LEDS_TRIGGERS + struct led_trigger *charging_trig; + char *charging_trig_name; + struct led_trigger *full_trig; + char *full_trig_name; + #endif +}; #ifdefs need to be at column 0? Yup, fixed in [take2]. +/* + * This is recommended structure to specify static battery parameters. + * Generic one, parametrizable for different batteries. Battery device + * itself does bot use it, but that's what implementing most drivers, 'does not'? Thanks, will fix! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Fri, 13 Apr 2007, Anton Vorontsov wrote: > > With fixed-units files, having *_energy and *_capacity isn't too clear > > either... Nor is it consistent with SBS, since SBS uses "capacity" to > > refer to either energy or charge, depending on a units attribute. > > > > As a compromise, how about using "energy" and "charge" for quantities, > > and "charging" (i.e., a verb) when referring to the operation? > > It would be great compromise! Please please please! I can live with it, although I'd rather just use the units (zero margin of error or confusion). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Fri, 13 Apr 2007, Anton Vorontsov wrote: With fixed-units files, having *_energy and *_capacity isn't too clear either... Nor is it consistent with SBS, since SBS uses capacity to refer to either energy or charge, depending on a units attribute. As a compromise, how about using energy and charge for quantities, and charging (i.e., a verb) when referring to the operation? It would be great compromise! Please please please! I can live with it, although I'd rather just use the units (zero margin of error or confusion). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Thu, Apr 12, 2007 at 10:34:06PM -0400, Shem Multinymous wrote: > Hi, > > On 4/12/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > >On Fri, 13 Apr 2007, Anton Vorontsov wrote: > >> * Yup, I've read last discussion regarding batteries, and I've seen > >> objections against "charge" term, quoting Shem Multinymous: > >> > >> "And, for the reasons I explained earlier, I strongly suggest not using > >> the term "charge" except when referring to the action of charging. > >> Hence: > >> s/charge_rate/rate/; s/charge/capacity/" > >> > >> But lets think about it once again? We'll make things much cleaner > >> if we'll drop "capacity" at all. > > > >I stand with Shem on this one. The people behind the SBS specification > >seems to agree... that specification is aimed at *engineers* and still > >avoids the obvious trap of using "charge" due to its high potential for > >confusion. > > > >I don't even want to know how much of a mess the people writing applets > >woudl make of it... > > With fixed-units files, having *_energy and *_capacity isn't too clear > either... Nor is it consistent with SBS, since SBS uses "capacity" to > refer to either energy or charge, depending on a units attribute. > > As a compromise, how about using "energy" and "charge" for quantities, > and "charging" (i.e., a verb) when referring to the operation? It would be great compromise! Please please please! -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
Hi, On 4/12/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: On Fri, 13 Apr 2007, Anton Vorontsov wrote: > * Yup, I've read last discussion regarding batteries, and I've seen > objections against "charge" term, quoting Shem Multinymous: > > "And, for the reasons I explained earlier, I strongly suggest not using > the term "charge" except when referring to the action of charging. > Hence: > s/charge_rate/rate/; s/charge/capacity/" > > But lets think about it once again? We'll make things much cleaner > if we'll drop "capacity" at all. I stand with Shem on this one. The people behind the SBS specification seems to agree... that specification is aimed at *engineers* and still avoids the obvious trap of using "charge" due to its high potential for confusion. I don't even want to know how much of a mess the people writing applets woudl make of it... With fixed-units files, having *_energy and *_capacity isn't too clear either... Nor is it consistent with SBS, since SBS uses "capacity" to refer to either energy or charge, depending on a units attribute. As a compromise, how about using "energy" and "charge" for quantities, and "charging" (i.e., a verb) when referring to the operation? BTW, tp_smapi uses "charge" and "charging" interchangeably; that was a mistake. Shem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Thu, Apr 12, 2007 at 09:51:12PM -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 13 Apr 2007, Anton Vorontsov wrote:
> > Let's name attributes with mWh units as {min_,max_,design_,}energy,
> > and attributes with mAh units as {min_,max_,design_,}charge.
>
> [...]
>
> > * Yup, I've read last discussion regarding batteries, and I've seen
> > objections against "charge" term, quoting Shem Multinymous:
> >
> > "And, for the reasons I explained earlier, I strongly suggest not using
> > the term "charge" except when referring to the action of charging.
> > Hence:
> > s/charge_rate/rate/; s/charge/capacity/"
> >
> > But lets think about it once again? We'll make things much cleaner
> > if we'll drop "capacity" at all.
>
> I stand with Shem on this one. The people behind the SBS specification
> seems to agree... that specification is aimed at *engineers* and still
> avoids the obvious trap of using "charge" due to its high potential for
> confusion.
>
> I don't even want to know how much of a mess the people writing applets
> woudl make of it...
:-(
Okay, term "charge" is out of scope, I guess. But can we use "capacity"
for xAh, and "energy" for xWh? I just trying to separate these terms
somehow, and avoid "_units" stuff.
>
> > > That said, you may need to use uWh and uAh instead of mAh and mWh, though.
> >
> > Not sure. Is there any existing chip that can report uAh/uWh? That is
> > great precision.
>
> The way things are going, it should be feasible for small embedded systems
> quite soon. Refer to the previous thread.
I see... is it also applicable to currents and voltages? I.e. should we
use uA and uV from the start?
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.org/bd2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Fri, 13 Apr 2007, Anton Vorontsov wrote:
> Let's name attributes with mWh units as {min_,max_,design_,}energy,
> and attributes with mAh units as {min_,max_,design_,}charge.
[...]
> * Yup, I've read last discussion regarding batteries, and I've seen
> objections against "charge" term, quoting Shem Multinymous:
>
> "And, for the reasons I explained earlier, I strongly suggest not using
> the term "charge" except when referring to the action of charging.
> Hence:
> s/charge_rate/rate/; s/charge/capacity/"
>
> But lets think about it once again? We'll make things much cleaner
> if we'll drop "capacity" at all.
I stand with Shem on this one. The people behind the SBS specification
seems to agree... that specification is aimed at *engineers* and still
avoids the obvious trap of using "charge" due to its high potential for
confusion.
I don't even want to know how much of a mess the people writing applets
woudl make of it...
> > That said, you may need to use uWh and uAh instead of mAh and mWh, though.
>
> Not sure. Is there any existing chip that can report uAh/uWh? That is
> great precision.
The way things are going, it should be feasible for small embedded systems
quite soon. Refer to the previous thread.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Thu, Apr 12, 2007 at 03:56:30PM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 12 Apr 2007, Paul Sokolovsky wrote:
> > Yes, that's apparently the way to go. We just should consider
> > if mAh and mWh are enough, or we go wider and allow whole collection of
> > units. Btw, original handhelds.org code used Joules ;-).
>
> FWIW, SBS only mentions mAh and mWh. AFAIK, all other (meaningful) units
> should be able to be converted to either Ah or Wh, assuming enough precision
> on the math. I never heard of any other way to fuel-gauge batteries than
> these two main modes (current-based or capacity-based), but I don't work on
> the battery field.
Okay, I have an idea:
Let's name attributes with mWh units as {min_,max_,design_,}energy,
and attributes with mAh units as {min_,max_,design_,}charge.
Because both energy and charge represents ""capacity"" in some meanings,
and that's why we bothering with _units attribute. So, lets drop
"capacity"* and use more specific terms? I really don't want string
attributes by default (except status).
If we export attributes with predefined units, userspace developers
could just look into include/linux/battery.h and conclude: "Ah, great,
if battery reporting energy, then it's in mWh, and if battery reporting
charge it's always in mAh".
* Yup, I've read last discussion regarding batteries, and I've seen
objections against "charge" term, quoting Shem Multinymous:
"And, for the reasons I explained earlier, I strongly suggest not using
the term "charge" except when referring to the action of charging.
Hence:
s/charge_rate/rate/; s/charge/capacity/"
But lets think about it once again? We'll make things much cleaner
if we'll drop "capacity" at all.
> That said, you may need to use uWh and uAh instead of mAh and mWh, though.
Not sure. Is there any existing chip that can report uAh/uWh? That is
great precision.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.org/bd2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Thu, 12 Apr 2007, Paul Sokolovsky wrote: > Yes, that's apparently the way to go. We just should consider > if mAh and mWh are enough, or we go wider and allow whole collection of > units. Btw, original handhelds.org code used Joules ;-). FWIW, SBS only mentions mAh and mWh. AFAIK, all other (meaningful) units should be able to be converted to either Ah or Wh, assuming enough precision on the math. I never heard of any other way to fuel-gauge batteries than these two main modes (current-based or capacity-based), but I don't work on the battery field. That said, you may need to use uWh and uAh instead of mAh and mWh, though. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
Hello Matthew, Thursday, April 12, 2007, 5:24:30 PM, you wrote: > On Thu, Apr 12, 2007 at 06:15:05PM +0400, Anton Vorontsov wrote: >> On Thu, Apr 12, 2007 at 02:08:18PM +0100, Matthew Garrett wrote: >> > ACPI batteries can report capacity and rate in either mA or mW. Given >> >> You sure, capacity in mA? Then I don't know. But you can safely >> fallback and create your own attribute (just as in David's battery class, >> where every battery required to create its own attributes), plus create >> capacity_units attribute. So, user space will know your driver's specific >> units. > Well, mAh, but yes. Clearly it's possible to add extra attributes, but > speccing standard attributes that don't entirely cover the most common > non-embedded battery class seems less than ideal. Why not just require > capacity_units and rate_units attributes? Yes, that's apparently the way to go. We just should consider if mAh and mWh are enough, or we go wider and allow whole collection of units. Btw, original handhelds.org code used Joules ;-). -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
Hello Matthew, Thursday, April 12, 2007, 5:24:30 PM, you wrote: On Thu, Apr 12, 2007 at 06:15:05PM +0400, Anton Vorontsov wrote: On Thu, Apr 12, 2007 at 02:08:18PM +0100, Matthew Garrett wrote: ACPI batteries can report capacity and rate in either mA or mW. Given You sure, capacity in mA? Then I don't know. But you can safely fallback and create your own attribute (just as in David's battery class, where every battery required to create its own attributes), plus create capacity_units attribute. So, user space will know your driver's specific units. Well, mAh, but yes. Clearly it's possible to add extra attributes, but speccing standard attributes that don't entirely cover the most common non-embedded battery class seems less than ideal. Why not just require capacity_units and rate_units attributes? Yes, that's apparently the way to go. We just should consider if mAh and mWh are enough, or we go wider and allow whole collection of units. Btw, original handhelds.org code used Joules ;-). -- Best regards, Paulmailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Thu, 12 Apr 2007, Paul Sokolovsky wrote: Yes, that's apparently the way to go. We just should consider if mAh and mWh are enough, or we go wider and allow whole collection of units. Btw, original handhelds.org code used Joules ;-). FWIW, SBS only mentions mAh and mWh. AFAIK, all other (meaningful) units should be able to be converted to either Ah or Wh, assuming enough precision on the math. I never heard of any other way to fuel-gauge batteries than these two main modes (current-based or capacity-based), but I don't work on the battery field. That said, you may need to use uWh and uAh instead of mAh and mWh, though. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Thu, Apr 12, 2007 at 03:56:30PM -0300, Henrique de Moraes Holschuh wrote:
On Thu, 12 Apr 2007, Paul Sokolovsky wrote:
Yes, that's apparently the way to go. We just should consider
if mAh and mWh are enough, or we go wider and allow whole collection of
units. Btw, original handhelds.org code used Joules ;-).
FWIW, SBS only mentions mAh and mWh. AFAIK, all other (meaningful) units
should be able to be converted to either Ah or Wh, assuming enough precision
on the math. I never heard of any other way to fuel-gauge batteries than
these two main modes (current-based or capacity-based), but I don't work on
the battery field.
Okay, I have an idea:
Let's name attributes with mWh units as {min_,max_,design_,}energy,
and attributes with mAh units as {min_,max_,design_,}charge.
Because both energy and charge represents capacity in some meanings,
and that's why we bothering with _units attribute. So, lets drop
capacity* and use more specific terms? I really don't want string
attributes by default (except status).
If we export attributes with predefined units, userspace developers
could just look into include/linux/battery.h and conclude: Ah, great,
if battery reporting energy, then it's in mWh, and if battery reporting
charge it's always in mAh.
* Yup, I've read last discussion regarding batteries, and I've seen
objections against charge term, quoting Shem Multinymous:
And, for the reasons I explained earlier, I strongly suggest not using
the term charge except when referring to the action of charging.
Hence:
s/charge_rate/rate/; s/charge/capacity/
But lets think about it once again? We'll make things much cleaner
if we'll drop capacity at all.
That said, you may need to use uWh and uAh instead of mAh and mWh, though.
Not sure. Is there any existing chip that can report uAh/uWh? That is
great precision.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.org/bd2
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Fri, 13 Apr 2007, Anton Vorontsov wrote:
Let's name attributes with mWh units as {min_,max_,design_,}energy,
and attributes with mAh units as {min_,max_,design_,}charge.
[...]
* Yup, I've read last discussion regarding batteries, and I've seen
objections against charge term, quoting Shem Multinymous:
And, for the reasons I explained earlier, I strongly suggest not using
the term charge except when referring to the action of charging.
Hence:
s/charge_rate/rate/; s/charge/capacity/
But lets think about it once again? We'll make things much cleaner
if we'll drop capacity at all.
I stand with Shem on this one. The people behind the SBS specification
seems to agree... that specification is aimed at *engineers* and still
avoids the obvious trap of using charge due to its high potential for
confusion.
I don't even want to know how much of a mess the people writing applets
woudl make of it...
That said, you may need to use uWh and uAh instead of mAh and mWh, though.
Not sure. Is there any existing chip that can report uAh/uWh? That is
great precision.
The way things are going, it should be feasible for small embedded systems
quite soon. Refer to the previous thread.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Thu, Apr 12, 2007 at 09:51:12PM -0300, Henrique de Moraes Holschuh wrote:
On Fri, 13 Apr 2007, Anton Vorontsov wrote:
Let's name attributes with mWh units as {min_,max_,design_,}energy,
and attributes with mAh units as {min_,max_,design_,}charge.
[...]
* Yup, I've read last discussion regarding batteries, and I've seen
objections against charge term, quoting Shem Multinymous:
And, for the reasons I explained earlier, I strongly suggest not using
the term charge except when referring to the action of charging.
Hence:
s/charge_rate/rate/; s/charge/capacity/
But lets think about it once again? We'll make things much cleaner
if we'll drop capacity at all.
I stand with Shem on this one. The people behind the SBS specification
seems to agree... that specification is aimed at *engineers* and still
avoids the obvious trap of using charge due to its high potential for
confusion.
I don't even want to know how much of a mess the people writing applets
woudl make of it...
:-(
Okay, term charge is out of scope, I guess. But can we use capacity
for xAh, and energy for xWh? I just trying to separate these terms
somehow, and avoid _units stuff.
That said, you may need to use uWh and uAh instead of mAh and mWh, though.
Not sure. Is there any existing chip that can report uAh/uWh? That is
great precision.
The way things are going, it should be feasible for small embedded systems
quite soon. Refer to the previous thread.
I see... is it also applicable to currents and voltages? I.e. should we
use uA and uV from the start?
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.org/bd2
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
Hi, On 4/12/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Fri, 13 Apr 2007, Anton Vorontsov wrote: * Yup, I've read last discussion regarding batteries, and I've seen objections against charge term, quoting Shem Multinymous: And, for the reasons I explained earlier, I strongly suggest not using the term charge except when referring to the action of charging. Hence: s/charge_rate/rate/; s/charge/capacity/ But lets think about it once again? We'll make things much cleaner if we'll drop capacity at all. I stand with Shem on this one. The people behind the SBS specification seems to agree... that specification is aimed at *engineers* and still avoids the obvious trap of using charge due to its high potential for confusion. I don't even want to know how much of a mess the people writing applets woudl make of it... With fixed-units files, having *_energy and *_capacity isn't too clear either... Nor is it consistent with SBS, since SBS uses capacity to refer to either energy or charge, depending on a units attribute. As a compromise, how about using energy and charge for quantities, and charging (i.e., a verb) when referring to the operation? BTW, tp_smapi uses charge and charging interchangeably; that was a mistake. Shem - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/7] [RFC] Battery monitoring class
On Thu, Apr 12, 2007 at 10:34:06PM -0400, Shem Multinymous wrote: Hi, On 4/12/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Fri, 13 Apr 2007, Anton Vorontsov wrote: * Yup, I've read last discussion regarding batteries, and I've seen objections against charge term, quoting Shem Multinymous: And, for the reasons I explained earlier, I strongly suggest not using the term charge except when referring to the action of charging. Hence: s/charge_rate/rate/; s/charge/capacity/ But lets think about it once again? We'll make things much cleaner if we'll drop capacity at all. I stand with Shem on this one. The people behind the SBS specification seems to agree... that specification is aimed at *engineers* and still avoids the obvious trap of using charge due to its high potential for confusion. I don't even want to know how much of a mess the people writing applets woudl make of it... With fixed-units files, having *_energy and *_capacity isn't too clear either... Nor is it consistent with SBS, since SBS uses capacity to refer to either energy or charge, depending on a units attribute. As a compromise, how about using energy and charge for quantities, and charging (i.e., a verb) when referring to the operation? It would be great compromise! Please please please! -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.org/bd2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
