WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: 'Kamala Narasimhan' <Kamala.Narasimhan@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [xen-devel][PATCH] Battery Management
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Tue, 14 Oct 2008 23:25:44 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Tue, 14 Oct 2008 08:27:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0519110A9448BC429B231AD118D7270805A2FF5A@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <0519110A9448BC429B231AD118D7270805A2FE20@xxxxxxxxxxxxxxxxxxxxxx><D8078B8B3B09934AA9F8F2D5FB3F28CE08A3CEFD0A@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <D8078B8B3B09934AA9F8F2D5FB3F28CE08A3CEFD16@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <0519110A9448BC429B231AD118D7270805A2FF5A@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcktnWeVAB6gk6+1Q5i+o6SjyoeAKgAFm+HgAAmWLRAAC9XWoAAA1rVw
Thread-topic: [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 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