Re: Re: Smart Battery System driver

François Valenduc
2005-01-16T14:36:51Z

Hello again,

In fact, I now have battery and ac adapter info. I just had to remove AC
adapter support in the ACPI support in kernel configuration.
Neverthelss, I still get strange values for the remaining time. Now,
when battery is full loaded, I am suposed to have an autonomy of 54
hours ! That would be wonderful but I don't think it's realstic !

Would you haveAny ideas to solve the problem. Thanks in advance

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