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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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 hands
>on to better answer your question.  However, given the current battery
>firmware implementation trend, the pass-through mode is likely to work
>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 along
>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 different.
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel