Re: Re: Smart Battery System driver

François Valenduc
2005-01-16T10:48:01Z

Hello,

Thanks for your driver. With this new version, the AC adapter status is
available, which is better. There are even two ac_adapter directory in
/proc/acpi. However, I don't find anymore battery information. I have
seen that directory structure has changed and that now,
/proc/acpi/battery is empty. I have tried the cat command on the new sbs
sub-directory but I didn't find usual battery info. Also with the first
version you sended, I noticed that the remaining battery time was too
low. For example, with a battery fully loaded, I am supposed to have
only around 40 minutes of autonomy, which is a bit short !

Thanks for your help,
Sincerely yours,
François Valenduc

Rich Townsend a écrit :

> Johan Vromans wrote:
>
>> Johannes Kuhlmann <jkuhlmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>
>>
>>> I had to put
>>> EXPORT_SYMBOL(acpi_ec_write); and EXPORT_SYMBOL(acpi_ec_read); after
>>> the functions in drivers/acpi/ec.c.
>>
>>
>>
>> This is one of the issues Bruno's patch addressed...
>>
>
> Yeah, I'd completely forgotten about the patch, until I went back and
> checked the instructions in Bruno's smartbatt package. D'oh!
>
> I've modified the README file accordingly, and placed a copy of the
> patch in my acpi-sbs package. This is on top of a number of changes &
> additions to the code, which include:
>
> *) Fixed scaling bug when capacity is reported in mWh
> *) Added a new module parameter, capacity_info, to alter whether
> capacities are reported in mAh (charge) or mWh (power)
> *) Fixed a number of bugs in the formatting of info/state output
> *) Added support for Smart Battery System Manager (SBSM), Smart
> Battery Selector (SBSEL) and Smart Battery Charge (SBC) subsystems.
> With the code for these in place, the module correctly (I think)
> enumerates how many batteries the system can support, which ones are
> present, etc.
> *) Added a new legacy interface for the AC adapter, in
> /proc/acpi/ac_adapter/*/state (where * is typically SBS0).
> *) Put in semaphores, so the code *might* now be SMP safe. Of course,
> this may be a purely academic excercise; I've never met the lucky ****
> who has an SMP laptop :)
>
> The latest copy of the code can be obtained from:
>
> http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050116.tar.gz
>
> To move forward from here, I'd appreciate some advice from others on
> this list. In particular
>
> *) I'd like some feedback on the directory structure I've chosen. At
> the moment, the root directory of the Smart Battery System is 'sbs',
> but would something more verbose like 'smart_battery_system' be
> appropriate? Also, should various subdirectories, representing
> subsystems, have more descriptive names -- e.g., 'battery_A' instead
> of 'SB0' (the SBS spec. refers to the batteries as 'A', 'B' etc),
> 'selector' instead of 'SBSL', and so on?
>
> *) I'd appreciate feedback from people with systems *other* than Acer
> TravelMater 4x00 laptops, to help check parts of the code that are not
> accessed on these machines (e.g., the Smart Battery System Manager
> code; my TM4502 laptop has an older Smart Battery Selector)
>
> *) The code to update the Smart Battery System state from the SMBus is
> terribly slow, presumably because SMBus itself is a slow protocol.
> Unfortunately, this has the effect of freezing the system (including
> loss of keystrokes and/or mouse movements) whenever an update occurs.
> Typically, these freezes will arise every few seconds, as monitoring
> tools (e.g., gkrellm, wmacpi) poll the /proc/acpi interfaces. The
> jerkiness that results is unacceptable to many, including myself. How
> might I go about fixing this? I've tried putting a schedule() call
> after every individual SMBus access, but that appears to have little
> effect on the system responsiveness.
>
> *) I'm not sure how to go about implmeneting Alarm functionality, not
> only to deal with low-power scenarios, but also to detect asynchronous
> events such as AC on-line/off-line and battery change, without the
> need for polling. Certainly, interrupts *are* being generated
> somewhere, as evidenced by the incrementing value of the acpi field in
> /proc/interrupts. Furthermore, with ACPI debugging enabled, I can see
> the embedded controller handling the events; for instance, an AC
> off-line event produces the following debug output:
>
> Execute Method: [\_SB_.PCI0.LPC0.EC0_._Q20] (Node dded7de8)
> acpi_ec-0180 [5125] acpi_ec_read : Read [c0] from address [19]
> acpi_ec-0180 [5125] acpi_ec_read : Read [14] from address [3d]
> acpi_ec-0180 [5125] acpi_ec_read : Read [c0] from address [19]
> acpi_ec-0232 [5126] acpi_ec_write : Wrote [80] to address [19]
>
> The corresponding DSL code for function _Q20 of my DSDT is:
>
> Method (_Q20, 0, NotSerialized)
> {
> If (And (SMST, 0x40))
> {
> Store (SMAA, Local0)
> If (LEqual (Local0, 0x14))
> {
> And (SMST, 0xBF, SMST)
> }
> }
> }
>
> ...which unfortunately doesn't mean a whole lot to me. How can I
> install some form of a handler, so that when the EC detects a Smart
> Battery event (and -- as per the ACPI spec -- sets the EC Alarm
> Address and Data registers), and then fires off a General Purpose
> Event, a chunk of *my* code gets run?
>
> Any pointers for the above questions will be very welcome -- and
> thanks to everyone who has responded with bug reports so far.
>
> cheers,
>
> Rich
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
>

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt