Hi!
> > I'll convert mXh to uXh a bit later, if there will no further objections
> > against uXh. Also I'd like to hear if there any objections on
> > mA/mV -> uA/uV conversion. I think we'd better keep all units at the
> > same order/precision.
>
> Okay, would it make sense to use "long" instead
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 so
> > > Also, if you your battery can collect and report its approximated values
> > > in additional to momentary values, you're free to add _AVG attributes
> > > to standard ones and use them.
> >
> > No, that won't help much. IMO, we want the sanest set of standard
> > attributes we can get, and
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
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 o
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,
On Sun, Apr 15, 2007 at 09:57:22PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 16 Apr 2007, Anton Vorontsov wrote:
> > Current battery class assumes values are not averaged. I.e. momentary
> > values. In general, it's userspace' job to collect statistics. Though,
> > if hardware can report
On Mon, 16 Apr 2007, Anton Vorontsov wrote:
> Current battery class assumes values are not averaged. I.e. momentary
> values. In general, it's userspace' job to collect statistics. Though,
> if hardware can report only average values, it's just okay to use
> usual attributes.
What about SBS-style
Hi,
On Mon, Apr 16, 2007 at 12:08:54AM +0200, Ondrej Zajicek wrote:
> On Thu, Apr 12, 2007 at 03:25:03AM +0400, Anton Vorontsov wrote:
> > Here is battery monitor class. According to first copyright string, we're
> > maintaining it since 2003. I've took few days and cleaned it up to be
> > more su
On Thu, Apr 12, 2007 at 03:25:03AM +0400, Anton Vorontsov wrote:
> Here is battery monitor class. According to first copyright string, we're
> maintaining it since 2003. I've took few days and cleaned it up to be
> more suitable for mainline inclusion.
Just some ideas:
- what about using exponent
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.
> >
> >
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 drive
On Fri, Apr 13, 2007 at 05:49:39PM +0400, Anton Vorontsov wrote:
> I'll convert mXh to uXh a bit later, if there will no further objections
> against uXh. Also I'd like to hear if there any objections on
> mA/mV -> uA/uV conversion. I think we'd better keep all units at the
> same order/precision.
On Thu, Apr 12, 2007 at 03:25:03AM +0400, Anton Vorontsov wrote:
> Here is battery monitor class. According to first copyright string, we're
> maintaining it since 2003. I've took few days and cleaned it up to be
> more suitable for mainline inclusion.
>
> It differs from battery class at git://gi
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
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"
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
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
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, quotin
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 handhel
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
Hi Anton,
On 4/12/07, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
On Thu, Apr 12, 2007 at 11:00:07AM -0400, Shem Multinymous wrote:
> I suggest adding "remaining operating time" and "remaining charging
> time". You can try deducing these from the above attributes, but in
> practice this gives ver
Hello Randy,
On Wed, Apr 11, 2007 at 07:53:59PM -0700, Randy Dunlap wrote:
> On Thu, 12 Apr 2007 03:25:03 +0400 Anton Vorontsov wrote:
> > +void battery_status_changed(struct battery *bat)
> > +{
> > + pr_debug("%s\n", __FUNCTION__);
> > + #ifdef CONFIG_LEDS_TRIGGERS
>
> Please don't indent p
Hello Shem,
On Thu, Apr 12, 2007 at 11:00:07AM -0400, Shem Multinymous wrote:
> Hi Anton,
>
> A few comments on the ever-contentious choice of battery attributes:
>
> On 4/11/07, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> >+ * All voltages, currents, capacities and temperatures in mV, mA, mAh
Hi Anton,
A few comments on the ever-contentious choice of battery attributes:
On 4/11/07, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
+ * 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
+ * its r
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, capaci
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 yo
On Thu, Apr 12, 2007 at 02:08:18PM +0100, Matthew Garrett wrote:
> On Thu, Apr 12, 2007 at 03:25:03AM +0400, Anton Vorontsov wrote:
> > + * 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
> > + *
Hello Greg,
On Wed, Apr 11, 2007 at 08:43:23PM -0700, Greg KH wrote:
> On Thu, Apr 12, 2007 at 03:25:03AM +0400, Anton Vorontsov wrote:
> > Here is battery monitor class. According to first copyright string, we're
> > maintaining it since 2003. I've took few days and cleaned it up to be
> > more s
On Thu, Apr 12, 2007 at 03:25:03AM +0400, Anton Vorontsov wrote:
> + * 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
> + * its raw values to which this class operates. If for some reason driver
>
On Wed, 11 Apr 2007, Greg KH wrote:
> Ok, yes, you want a conditional type of attribute group, like the
> new firewire code does. I have no problem adding that if you like.
Please do. I want that for ibm-acpi/thinkpad-acpi as well. Right now I
need to use multiple attribute groups because of th
On Thu, Apr 12, 2007 at 03:25:03AM +0400, Anton Vorontsov wrote:
> Here is battery monitor class. According to first copyright string, we're
> maintaining it since 2003. I've took few days and cleaned it up to be
> more suitable for mainline inclusion.
>
> It differs from battery class at git://gi
On Thu, 12 Apr 2007 03:25:03 +0400 Anton Vorontsov wrote:
> Here is battery monitor class. According to first copyright string, we're
> maintaining it since 2003. I've took few days and cleaned it up to be
> more suitable for mainline inclusion.
>
> ---
> drivers/Kconfig |2 +
> dr
Here is battery monitor class. According to first copyright string, we're
maintaining it since 2003. I've took few days and cleaned it up to be
more suitable for mainline inclusion.
It differs from battery class at git://git.infradead.org/battery-2.6.git:
* It's using external power kernel interf
34 matches
Mail list logo
