[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [xen-devel][PATCH] Battery Management

  • To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Kamala Narasimhan" <Kamala.Narasimhan@xxxxxxxxxx>
  • Date: Tue, 14 Oct 2008 12:40:18 -0400
  • Cc:
  • Delivery-date: Tue, 14 Oct 2008 09:41:21 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcktnWeVAB6gk6+1Q5i+o6SjyoeAKgAFm+HgAAmWLRAAC9XWoAAA1rVwAANKGZA=
  • Thread-topic: [xen-devel][PATCH] Battery Management


I understand your concerns.  Pass-through battery management at its
current state does have a narrow scope at the moment because of the
nature of its implementation.  A subset of CMBattery firmware
implementation I studied does appear to use the command/data ports and
battery commands as mimicked in our vACPI layer.  But, if the trend
doesn't continue, while we fine tune our vACPI layer to work with a
broader range of laptops, we could use the non pass-through approach
which is a sure bet approach on all laptops.  I do expect non
pass-through approach to be more widely used in the beginning before
pass-through approach takes over.

To answer your question pertaining to using shared page, though I like
it, if feasible, we may be replacing one set of problem with another.
Also, to my knowledge, ACPI or other relevant specification does not
enforce any requirement on how/what shared pages or ports are used for
battery management and is left to the discretion of the firmware


> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@xxxxxxxxx]
> Sent: Tuesday, October 14, 2008 11:26 AM
> To: Kamala Narasimhan; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [xen-devel][PATCH] Battery Management
> >From: Kamala Narasimhan [mailto:Kamala.Narasimhan@xxxxxxxxxx]
> >Sent: Tuesday, October 14, 2008 10:49 PM
> >
> >There isn't a whole range of VT-x enabled laptops I could get my
> >on to better answer your question.  However, given the current
> >firmware implementation trend, the pass-through mode is likely to
> >on laptops that uses CMBattery interface.  The goal was to attempt to
> >put the base vACPI implementation that can be fine tuned as we go
> >to better support a whole range of VT-x enabled laptops shipped in
> >future.  That said, I have tested pass-through mode on the hardware I
> >could get hold of (that uses CMBattery interface) and seen it work.
> >
> >Thanks,
> >Kamala
> >
> Yes, I can understand your point. It's natural to first have a simple
> code to support basic functionality of most batteries, in pass-through
> mode, and then later extend to more functions like _BTP. However
> one point I'm not quite sure is about the port address. When _STA,
> _BIF and _BST are enough which should be common interfaces for
> all control method batteries, internal control interface may be
> For example:
> +// Battery command port - 0xb2
> +// Batter data port     - 0x86
> +// Battery commands (written to port 0xb2) -
> +// 0x7b - Battery operation init
> +// 0x7c - Type of battery operation
> +// 0x79 - Get battery data length
> +// 0x7d - Get battery data
> Above internal logic may be specific to battery implementation:
> - Port address may vary for different batteries, or
> - Even worse, different command type is defined, or even different
> interface (not a cmd/data pair) is developed
> For the first variation, maybe it's better to let Qemu pass actual
> port being used, by either a dumb port or shared page instead of
> hardcode. However I didn't see clean way for 2nd case. Per your
> knowledge, is 2nd case possible? Is there any formal spec defining
> such interface for all CMBatteries?
> Thanks,
> Kevin

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.