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

["Kamala Narasimhan" <Kamala.Narasimhan@xxxxxxxxxx>]

Kevin,

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
implementor.

Thanks,
Kamala

> -----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
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