Smart Battery System driver

Hi all --

Recently, Bruno Ducrot posted a driver that allows access to smart batteries, through the /dev/i2c interface. This came at just the right time for me, since I'd recently purchased an Acer TravelMate 4502, and had no way to monitor the status of the smart battery.

However, this driver is primarily to allow access to the SMBus inside the embedded controller that communicates with the Smart Battery System (SBS); other tools are required to read the battery status. Bruno provided a userspace tool, but there is still a requirement for some form of /proc/acpi interface that current battery-monitoring tools can read.

Accordingly, I've written a first shot at an SBS ACPI driver. This driver, which can be downloaded from

http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20040114.tar.gz

...provides access to the SBS via a new /proc/acpi/sbs interface, and
also provides a "legacy" /proc/acpi/battery interface that current
battery-monitoring tools can access. This driver depends on Bruno's i2c-acpi-ec driver, which I have included with my source code since a couple of bug fixes were necessary.

Instructions for compilation and installation, plus some anticipated FAQs, can all be found in the accompanying README file. This is my first ever shot at kernel programming (and in fact my first real program in C!), so please expect there to be a number of goofs; but it seems to work OK on my system (2.6.10-gentoo-r4, with battery monitoring using wmacpi-1.99). Let me know what you find!

On a final note, DON'T use the SBS driver if you have the ACPI battery driver enabled in the kernel (either built-in, or as a module) -- the two will clash over their use of /proc/acpi/battery, and things will get Ugly(tm).

cheers,

Rich Townsend

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

Hi Rich ;),

To Bruno and you: Thanks. Really really tkanks :). It works like a charm ;). For the record, i'm testing it on a Travelmate 4001LMi with kernel 2.6.10. Both interfaces, legacy and the new sbs one are working ok. Same for acpi userspace tools.

Hope all the quaint things you do are like this ;)

Thanks again.

David Gómez                                      Jabber ID: [email protected]


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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rich Townsend wrote:

| Hi all --
|
| Recently, Bruno Ducrot posted a driver that allows access to smart
| batteries, through the /dev/i2c interface. This came at just the right
| time for me, since I'd recently purchased an Acer TravelMate 4502, and
| had no way to monitor the status of the smart battery.

hi rich,

Bruno also said a working driver was about to be released...

anyway I've tested your driver and have some results to show you:

this is what I get from a modified version of bruno ducrot's smartbattery userspace program

- ----------------------------------------------------------- archon smartbatt-head # ./smartbattery 5 -a

smart battery manufacturer information

manufacturer name:              SMP-SONY
device name:                    04ZL
manufacture date (yyyy/mm/dd):  2004/8/17
serial number:                  1

smart battery device specs

device chemistry:               LION
design voltage:                 14800 mV
design charge capacity:         4400 mAh

smart battery device state

charger:                        charging (almost full)
relative charge:                99%
full charge capacity:           3687 mAh
remain:                         3667 mAh
current input:                  0 mA
average time to empty:          n/a
average time to full:           n/a
temperature:                    20.8 C
voltage:                        16752 mV
remaining_capacity_alarm:       disabled
charge cycle count:             22

archon smartbatt-head #
- ------------------------------------------------------------

assuming the values are right, let's see:

archon BAT0 # pwd
/proc/acpi/battery/BAT0
archon BAT0 # cat info

present:                 yes
design capacity:         80 mAh
last full capacity:      10 mAh
battery technology:      rechargeable
design voltage:          0 mV

model number:
serial number: 250
battery type:
OEM info:
archon BAT0 #

weird values... maybe something's missing here... or is this something else other than battery read values?

archon BAT0 # cat state

present:                 yes
capacity state:          ok
charging state:          charged
present rate:            0 mA
remaining capacity:      3667 mAh
present voltage:         16753 mV

archon BAT0 #

this makes sense. It's ok.

archon SBS0 # pwd
/proc/acpi/sbs/SBS0
archon SBS0 # cat info

design voltage:          0 mV
design capacity:         80 mAh
full charge capacity:    10 mAh
remain capacity alarm:   5 mAh
remain time alarm:       0 mAh
charging current:        0 mA
charging voltage:        18 mV
charge reporting error:  0%
specification info:      Smart Battery v4.4
manufacturer name:
manufacture date:        1980- 0- 0
serial number:           250

device name:
device chemistry:
archon SBS0 #

again, none of the values seem to be correct...

archon SBS0 # cat state

charging state:          charged
current:                 0 mA
average current          0 mA
voltage:                 16753 mV
temperature:             21.5 C
relative charge:         99%
absolute charge:         83%
remaining capacity:      3667 mAh
run time to empty:       not discharging
average time to empty:   not discharging
average time to full:    not charging

archon SBS0 #

this is also ok.

I haven't had the time to read the code, but it seems that something's missing in the info files. could you check on that?

also, it's misbehaving when there is no battery present:

archon SBS0 # pwd
/proc/acpi/sbs/SBS0
archon SBS0 # cat state
cat: state: Operation not permitted
archon SBS0 #

archon BAT0 # pwd
/proc/acpi/battery/BAT0
archon BAT0 # cat info

present:                 yes
design capacity:         80 mAh
last full capacity:      10 mAh
battery technology:      rechargeable
design voltage:          0 mV

model number:
serial number: 250
battery type:
OEM info:
archon BAT0 #

archon BAT0 # cat state
cat: state: Operation not permitted
archon BAT0 #

Thanks for the work with the driver. It's damn good work!

Also, the other driver from Bruno Ducrot should be out soon, so I predict we'll have some work with both. maybe some kind of merge would be possible, best parts of one and best parts of the other... just a comment.

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: [email protected]
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB6F/feRy7HWZxjWERAjJFAJ9vQ3jaaE1L30YSjcZPRmA5jK+EzACePq5h kHp9LlMv5oChkpY52jUWSGI=
=HCrZ
-----END PGP SIGNATURE-----

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

One thing I've been meaning to ask - several Thinkpads have an interesting design issue, whereby reading certain smbus addresses can render the machine unbootable without a motherboard replacement. As a result, i2c-piix refuses to load on Thinkpads. Does something similar need to be done for i2c-acpi-ec, or does it only provide i2c access to devices connected to the embedded controller?

Matthew Garrett | [email protected]



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

Hi,

I just tried to use this with a pure kernel (2.6.10-gentoo-r2), that means I didn't apply Bruno's patch before, and had some problems with 'acpi_ec_read' and 'acpi_ec_write' being unknown symbols. The problem was, that those symbols were not exported. I had to put EXPORT_SYMBOL(acpi_ec_write); and EXPORT_SYMBOL(acpi_ec_read); after the functions in drivers/acpi/ec.c.

Regards,
Johannes

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

This is one of the issues Bruno's patch addressed...

-- Johan

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

I thought it wouldn't be necessary to apply the patch because Rich didn't mention it in his README file.

Regards,
Johannes

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

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

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

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

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

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

Thus wrote Rich Townsend:

The best way to do this would be to insert a Notify statement in the code. Here's a snippet from the appropriate method on my machine:

Notify (\_SB.ACAD, 0x80)

Of course, since you have a smart battery it is unlikely that you have an AC adapter device present in the DSDT, so you'd have to hack up a device in your tables and acpi_install_notify_handler() against it to have it reported.
Best regards,

Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/[email protected]


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

...

...

Look http://marc.theaimsgroup.com/?l=acpi4linux&m=109760298204539&w=2
More, the acpi-i2c-ec need to be event driven, which is not the case yet.

This have to be done in i2c-acpi-ec which will overwrite that one and must not be run if we do it correctly.
I guess this method is for OS which do not implement that one, as its the case for now..

Remember, we have that:

                    Device (SMBC)
                    {
                        Name (_HID, "ACPI0001")
                        Name (_EC, 0x1820)
                                       ^^
				   which will correspond to
				   this _Q20 that we have to
				   overwrite.



                        Device (SBS0)
                        {
                            Name (_HID, "ACPI0002")
                            Name (_SBS, 0x02)
                        }
                    }

Many thanks again for your work,

Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rich Townsend wrote:

| Johan Vromans wrote:
|
|> Johannes Kuhlmann <[email protected]> writes:
|>
|>
|>> I had to put
|>> EXPORT_SYMBOL(acpi_ec_write); and EXPORT_SYMBOL(acpi_ec_read); after
|>> the functions in drivers/acpi/ec.c.

Any chance of permanently fixing the ACPI ec driver with this patch? I'm sure it'll continue to be needed and such change would spare us from patching every kernel every day... just a thought... After all, all it does is exporting some symbols... care to comment?

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

hi rich,

I haven't been very busy, so no time to comment or test your driver.

| *) 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.

nice! :-)

| *) Added a new legacy interface for the AC adapter, in | /proc/acpi/ac_adapter/*/state (where * is typically SBS0).

that'd be nice.

| *) 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 :)

true. me neither.

|
| The latest copy of the code can be obtained from:
|
| http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050116.tar.gz

got it. any newer code?

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

my honest not privileged and not acpi/kernel experienced oppinion is:
/proc/acpi/sbs seems sane. also SB?, SBSEL, SBC, etc seems very close to the ACPI standard, which justifies those names.

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

I've tried your newer driver. reports are on the bottom of the e-mail.

| *) The code to update the Smart Battery System state from the SMBus is | terribly slow,

| *) 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.

can't help you on any of these questions. lack of knowledge/experience. sorry.

The report:

I've tried to load the module and it still has the mutual-exclusion problem with the acpi AC and battery drivers. How can that be fixed?

With AC built-in the kernel, the module segfaults on insmod...

After removing the AC driver, it loads fine and reports good results. Appearently looks nice. Tried with and without battery. Both SBSEL, SBC and SB0 values make sense.

Don't know if it's still relevant, but here's a link for my version of the smartbattery.c userspace program. just "make" and test it. needs the i2c-dev and i2c-acpi-ec drivers.

http://arrakis.dhis.org/linux/smartbattery/smartbattery-20050117.tar.gz

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: [email protected]
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB6+dpeRy7HWZxjWERAjZ9AKDuRZ3bHn1pQNLsFFhvjXnH7KlSEgCg5nhi Vq5ovAO0EWiMFWEfg9hHLzI=
=GCxy
-----END PGP SIGNATURE-----

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

Not surprised, there's probably all manner of crap that happens when one tries to mkdir /proc/acpi/ac_adapter more than once.

But I'm not sure why this is happening with the revised version of the code (20050116); this version contains #ifndef directives to prevent the legacy interfaces being compiled in if they are already in the kernel. Are you sure your kernel configuration matches your currently-running kernel?

Excellent!

Thanks for the pointer, I'll try this out!

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

a) Not have to rewrite every acpi battery applet to use the sbs interface directly, and
b) Not have to have a database of hardware that has a smart battery

Is there any way to provide the legacy interface even if standard battery support is built in, or alternatively some way of probing the system to determine which battery module should be loaded?

Thanks,

Matthew Garrett | [email protected]



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

As I have wrote earlier the klaptopdaemon (kde applet) can take info from exsting files under /proc/acpi created by the acpi_sbs module. At least under 2.6.10 kernel ;-/

z.a.kaleta (sanskryt), registered Linux User #279350


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

I want to add that kaptopdemon just generated the sount signal and print extra window in which has informed me that to the end of battery is only 15 minutes and later the info that only 5 minutes left.
The smartbattery program show the same info.
This was impossble before.

z.a.kaleta (sanskryt), registered Linux User #279350


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

We can't have the legacy interface (/proc/acpi/battery) if standard battery support is built in, since standard battery support *defines* the legacy interface! The legacy interfaces in acpi-sbs only exist to fake the existence of a standard (i.e., control method, CM) battery.

Regarding auto-loading of the correct module, it is likely that at some point in the future there may be some sort of merge between the SBS work done by myself and Bruno Ducrot, and the standard battery code battery.c. This will involve quite a bit of design effort, since the ACPI spec considers SBS and CM batteries to be totally different beasts (I don't know why they didn't define a unified interface for batteries).

But at the moment we're still at the phase of getting the SBS system working properly.

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

Hi all --

I've just uploaded a new version of the Smart Battery driver:

http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050117.tar.gz

Changes include

*) A slightly more-methodical use of mutexes (probably still broken, though)
*) An 'alarm' interface file in each SB? Smart Battery subdirectory (see the README file for usage instructions) *) An 'alarm' interface file in each BAT? legacy battery subdirectory

The alarm functionality is read-write, so you can change the capacity & time-left levels at which the Smart Battery begins to generate alarm events.

HOWEVER, here's the rub: I haven't yet found a way of detecting when these alarm events are issued. Reading through chapter 12.12 of the ACPI spec, it appears that all Alarm Notify messages from EC-based SMBus should trigger a query method (_QXX), with the query value XX being set by the _EC named object.

For instance, on my system (TM4502):

                    Device (SMBC)
                    {
                        Name (_HID, "ACPI0001")
                        Name (_EC, 0x1820)
                        Device (SBS0)
                        {
                            Name (_HID, "ACPI0002")
                            Name (_SBS, 0x02)
                        }
                     }

...means that the SMBus has a base address of 0x18 within embedded controller space, and all SMBus events are handled by query method _Q20.

Looking at the definition of _Q20 on my system, we have:

                    Method (_Q20, 0, NotSerialized)
                    {
                        If (And (SMST, 0x40))
                        {
                            Store (SMAA, Local0)
                            If (LEqual (Local0, 0x14))
                            {
                                And (SMST, 0xBF, SMST)
                            }
                        }
                    }

This I think I can understand: if the SMBus Alarm Notify bit is set (bit 14 of the SMST register), and the alarm was triggered by the device with shifted address 0x14, then reset the alarm bit.

Now what corresponds to shifted address 0x14? Well, shift it one bit to the right to get the 'true' SMBus slave address, and we find the value 0x0a -- which corresponds (see sec. 10 of the ACPI spec.) to a Smart Battery System Manager (SBSM) or Smart Battery Selector (SBSEL, which I've got on my system). So, the _Q20 method listens for alarms coming from the SBSM/SBSEL, but takes no specific action when it receives one, beyond resetting it.

Spurred on by a post by a very helpful post by Karol Kozimor, I tried adding code to the _Q20 method, to fire off a notifcation to the driver (well, in fact I just used a Store(XXXXX, debug) to get some output). With this code in place, I found that my SBSEL was generating alarms when the AC power cord was plugged in and removed. Likewise, events were generated when the battery was removed and re-inserted.

Hurrah, I thought -- we can get the 'backend' for alarms to work (although we'll need to do some DSDT hacking). But here now is the problem: using the new driver, I set the alarm trigger levels to crazy-high values, to get the Smart Battery to fire off alarm events. But these events seem to be getting lost somewhere, or they're not being generated in the first place, because I don't get a peep from my hacked _Q20 method.

I don't know why this is the case, but its worth noting that section 10.1.1 of the spec states "The Smart Battery System Manager, the Smart Battery Selector, and the Smart Battery Charger each have an optional mechanism for notifying the system that the battery configuration or AC status has changed. ACPI requires that this interrupt mechanism be through the SMBus Alarm Notify mechanism." Important note: no mention whatsoever of alarms generated by the Smart Battery itself!

But where, then, do the Smart Battery alarms end up? Reading sec. 5.6.2.2.2 of the spec. gave me hope: "Similarly, for an SMBus driver, if no driver registers for SMBus alarms, the SMBus driver will queue control methods to handle these. Methods must be placed under the SMBus device with the name _QXX, where XX is the hex format of the SMBus address of the device sending the alarm". So I went added _QXX methods for SMBus slave address 0x0b (Smart Battery) and its shifted equivalent 0x16. Unfortunately, again not a peep from the battery.

What could be going wrong? Some thoughts:
*) maybe there is already a driver registered for SMBus alarms, that prevents them from getting through?
*) I'm assuming its already there, but maybe the functionality described in 5.6.2.2.2 actually needs to be implemented in the i2c-acpi-ec code? *) perhaps the battery simply isn't generating the alarms?
*) maybe I just don't know enough about what I'm doing?

Well, that's enough rambling for me -- I just wanted to share how far I'd got in working out what is what. I'd really like to get the alarm issue resolved, since it is the most important feature to me, but at the moment I need to do some Real Work to keep my boss happy. It would be great if eveyone interested in Smart Battery support could have a shot at playing around like I have -- seriously, you don't need to know a whole lot!

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

...and there's an even more-recent version at

http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050118.tar.gz

This contains nothing particularly new, but there is a small tweak to the alarm writing code (to enable values up to 65535 to be written), plus an important modification to the battery selection code. This modification fixes situations where, on systems with a Smart Battery Selector, any read from a battery caused the charging of that battery temporarily to stop.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rich Townsend wrote:

| Rich Townsend wrote:
|
|> Hi all --
|>
|> I've just uploaded a new version of the Smart Battery driver:
|>
|>
|>
|
| ...and there's an even more-recent version at
|
| http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050118.tar.gz
|
| This contains nothing particularly new, but there is a small tweak to
| the alarm writing code (to enable values up to 65535 to be written),
| plus an important modification to the battery selection code. This
| modification fixes situations where, on systems with a Smart Battery
| Selector, any read from a battery caused the charging of that battery
| temporarily to stop.

I'm sorry to mention... but it segfaults everytime when I insmod it with the battery plugged.

what kind of debug information do you need to sort this out? Or is it already known?

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: [email protected]
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB7QiLeRy7HWZxjWERApwWAKC85v+B6urVcd8nyr7C7duFTbNJ2wCfa4Gd n9ad3nRo8e5ynB+uBMBlrLc=
=EX4F
-----END PGP SIGNATURE-----

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

OK, it seems like I've drifted toward doing a nightly build of the SBS driver -- and tonight is no different! The latest version of the code,

http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050119.tar.gz

contains some important changes, including:

*) fixed a segmentation fault on module load, experienced by some users (thanks to Pedro Venda & Olaf Jansen-Olliges for their "interactive debugging")
*) modified the i2c-acpi-ec module, to insert msleeps() after each read/write to the embedded controller - this leads to HUGE improvements in the responsiveness of the system when the /proc/acpi/* stuff is accessed *) fixed some typos in the /proc/acpi/* output -- most importantly, the battery/BAT0/state file doesn't now report that a battery is discharging when it is in fact charging
*) fixed the allowed length of alarm values written into /proc/acpi/SBS/SB?/alarm, so that for instance "10000,10000" is now valid

Keep the bug reports coming!

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

Good work! Seems to function properly on my TravelMate 4001WLMi.

The Gnome Battery applet does not detect when the AC state changes. Is that part of the required but still to be implemented event interface?

-- Johan

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

Yes -- in the sense that a notify event should be issued on AC state change, but the code to do that isn't yet there.

However, I'm surprised that the GB applet doesn't get the AC state from polling /proc/acpi/adapter/AC0/state. I use wmacpi, and that shows up the AC state fine...

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

An updated version of my battstat.pl progran can be found on my TravelMate web pages: http://www.squirrel.nl/people/jvromans/
Articles -> TravelMate 4000 -> ACPI Hacking -> Battery.

I will automatically select the new SBS API, fall back to the legacy battery API, or fall back to call the smartbattery2 program.

-- Johan

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

I've tried the above driver on my Acer TM4001WLMi and it sort of doesn't work. The problem is that after modprobing i2c_acpi_ec and acpi_sbs I've got two battery and two ac_adapter directories in /proc (very weird if you ask me).

So before modprobing:
ls -l /proc/acpi
gives
total 0
dr-xr-xr-x 10 root root 0 2005-01-19 19:36 .
dr-xr-xr-x 103 root root 0 2005-01-19 20:36 ..

dr-xr-xr-x    2 root root 0 2005-01-19 19:44 ac_adapter
-rw-r--r--    1 root root 0 2005-01-19 19:44 alarm
dr-xr-xr-x    2 root root 0 2005-01-19 19:37 battery
dr-xr-xr-x    5 root root 0 2005-01-19 19:44 button
-rw-r--r--    1 root root 0 2005-01-19 19:44 debug_layer
-rw-r--r--    1 root root 0 2005-01-19 19:44 debug_level
-r--------    1 root root 0 2005-01-19 19:44 dsdt
dr-xr-xr-x    3 root root 0 2005-01-19 19:44 embedded_controller
-r--------    1 root root 0 2005-01-19 19:36 event
-r--------    1 root root 0 2005-01-19 19:44 fadt
dr-xr-xr-x    4 root root 0 2005-01-19 19:44 fan
-r--r--r--    1 root root 0 2005-01-19 19:44 info
dr-xr-xr-x    4 root root 0 2005-01-19 19:44 power_resource
dr-xr-xr-x    3 root root 0 2005-01-19 19:44 processor
-rw-r--r--    1 root root 0 2005-01-19 19:44 sleep
dr-xr-xr-x    3 root root 0 2005-01-19 19:44 thermal_zone
-rw-r--r--    1 root root 0 2005-01-19 19:44 wakeup

Then, after modprobing the modules
total 0
dr-xr-xr-x 10 root root 0 2005-01-19 19:36 .
dr-xr-xr-x 103 root root 0 2005-01-19 20:36 ..

dr-xr-xr-x    3 root root 0 2005-01-19 19:45 ac_adapter
dr-xr-xr-x    3 root root 0 2005-01-19 19:45 ac_adapter
-rw-r--r--    1 root root 0 2005-01-19 19:45 alarm
dr-xr-xr-x    2 root root 0 2005-01-19 19:37 battery
dr-xr-xr-x    2 root root 0 2005-01-19 19:37 battery
dr-xr-xr-x    5 root root 0 2005-01-19 19:45 button
-rw-r--r--    1 root root 0 2005-01-19 19:45 debug_layer
-rw-r--r--    1 root root 0 2005-01-19 19:45 debug_level
-r--------    1 root root 0 2005-01-19 19:45 dsdt
dr-xr-xr-x    3 root root 0 2005-01-19 19:45 embedded_controller
-r--------    1 root root 0 2005-01-19 19:36 event
-r--------    1 root root 0 2005-01-19 19:45 fadt
dr-xr-xr-x    4 root root 0 2005-01-19 19:45 fan
-r--r--r--    1 root root 0 2005-01-19 19:45 info
dr-xr-xr-x    4 root root 0 2005-01-19 19:45 power_resource
dr-xr-xr-x    3 root root 0 2005-01-19 19:45 processor
dr-xr-xr-x    3 root root 0 2005-01-19 19:45 sbs
-rw-r--r--    1 root root 0 2005-01-19 19:45 sleep
dr-xr-xr-x    3 root root 0 2005-01-19 19:45 thermal_zone
-rw-r--r--    1 root root 0 2005-01-19 19:45 wakeup

Something works:
cat ac_adapter/AC0/state
gives
state: off-line

However,
ls battery
gives nothing (empty dir).

There is an sbs dir, that has all the correct info. The only thing that seems to give problems is the battery directory. Also it would be nice if there was only one battery and ac_adapter dir.

best,
Jeroen

Kile - a LaTeX Environment for KDE
http://kile.sourceforge.net


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Hi Joeren,

you should not have ac_adapter or battery before "modprobing" have you diabled the ac_adapter and battery section in your kernel configuration? (as mentioned in the README)

Good luck
Olaf

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

This is (in) my rc.local:

# Experimental: drivers for smartbattery reading. modprobe i2c-dev
modprobe i2c-acpi-ec
modprobe -r ac
modprobe -r battery
modprobe acpi-sbs

-- Johan

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Note that i2c-dev isn't needed by i2c-acpi-ec or acpi-sbs. Also, you can get acpi-sbs to automatically load i2c-acpi-ec by adding the line

below acpi-sbs i2c-acpi-ec

...to /etc/modules.conf. With this line in place, your rc.local would look like

modprobe -r ac
modprobe -r battery
modprobe acpi-sbs

cheers,

Rich

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Hi Johan,

i've tested it again on my machine. I only get values for my battery when i disable

- CONFIG_ACPI_AC and
- CONFIG_ACPI_BATTERY

in my kernel configuration. Even when they are marked to be build as modules i get no values! Perhaps you should try to compile a new kernel with this variables set to no.

greetings
Olaf

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Sorry for the confusion -- with these settings in my rc.local I _DO_ get correct values, so there should be no need to recompile the kernel if ac and battery are modules. Just make sure they're unloaded before you load acpi-sbs.

-- Johan

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

This was enabled, so I will have to recompile the kernel I guess.

best,
Jeroen

P.S.: Next time I will read the README before asking a question ;-)

Kile - KDE Integrated LaTeX Editor
http://kile.sourceforge.net


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Tonight's build:

http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050120.tar.gz

...only has one modification (apart from fixing a typo in my name, thanks to Olaf Jansen-OIlliges!). The 'present rate' field in the legacy-interface /proc/acpi/battery/*/state file is supposed to show the present discharge/charge rate in either mA or mW, depending on the capacity_mode used. However, I've just been using the current (in mA) returned by the Smart Battery System, which is clearly incorrect when capacity_mode=2 (mW) is selected.

I've fixed this in a rather cunning way. The SBS is more sophisticated than normal control-method batteries, in that individual batteries can report their time to empty or full (applications reporting on CM batteries have to calculate these times from the last full capacity and discharge/charge rates). What I've done in the latest release is to calculate what value of the 'present rate' field will produce the correct time to empty or full when combined with the last full capacity. The upshot is, not only does the 'present rate' field now give sensible values when capacity_mode=2, but also the times reported by applications using the legacy interface will be direct reflections of the proper SBS times.

The SBS driver seems to be working reasonably well now -- there are no outstanding bugs. My next task is to work out how best to aim for kernel integration, and to figure out how to set up event handling. Don't expect the pace of development to be as fast as the past few days -- I need sleep like the rest of you!

cheers,

Rich

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rich Townsend wrote:

| Tonight's build:
|
| http://shayol.bartol.udel.edu/~rhdt/download/acpi_sbs-20050120.tar.gz
|
| ...only has one modification (apart from fixing a typo in my name,
| thanks to Olaf Jansen-OIlliges!). The 'present rate' field in the
| legacy-interface /proc/acpi/battery/*/state file is supposed to show the
| present discharge/charge rate in either mA or mW, depending on the
| capacity_mode used. However, I've just been using the current (in mA)
| returned by the Smart Battery System, which is clearly incorrect when
| capacity_mode=2 (mW) is selected.
|
| I've fixed this in a rather cunning way. The SBS is more sophisticated
| than normal control-method batteries, in that individual batteries can
| report their time to empty or full (applications reporting on CM
| batteries have to calculate these times from the last full capacity and
| discharge/charge rates). What I've done in the latest release is to
| calculate what value of the 'present rate' field will produce the
| correct time to empty or full when combined with the last full capacity.
| The upshot is, not only does the 'present rate' field now give sensible
| values when capacity_mode=2, but also the times reported by applications
| using the legacy interface will be direct reflections of the proper SBS
| times.
|
| The SBS driver seems to be working reasonably well now -- there are no
| outstanding bugs. My next task is to work out how best to aim for kernel
| integration, and to figure out how to set up event handling. Don't
| expect the pace of development to be as fast as the past few days -- I
| need sleep like the rest of you!

yes, you definately deserve it. :-) very good work. again many thanks for your time and dedication.

I think we should try to solve the issues with the current battery and ac ACPI drivers. that is something that's giving some problems to most people trying the driver.

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: [email protected]
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB78pZeRy7HWZxjWERAsdDAKCRuMdt7ZGU1/jWmtrmQdsTVwwp8wCeL6lq nfYvCiNBUUkA5T0E29VZVN0=
=mQIp
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Well, I could make it so that the driver would refuse to compile if either of these were enabled in the kernel. That's something I originally considered doing, before I moved to the current behaviour of silently not compiling the legacy interfaces if ac or battery were enabled. It seems that such behaviour is confusing.

The best solution would be to perform a run-time check. I'll see if I can add code to dynamically detect if the ac_adapter and battery directories are empy on module insertion, and only add the legacy interfaces if they are.

cheers,

Rich

PS Last night, I got a proof-of-concept for event notifications working. I still haven't got battery alarms working, but we should now be able to do event-driven AC and battery present/charging/discharging statuses.

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

not "empty" but "do not exist". We will probably find machines that have working CM Battery but can also be used with SBS.
Or maybe it is possible from kernelspace to check if a module is loaded to lock each other out => if battery or ac is loaded, sbs will refuse to load and the other way round.

It would be pretty cool to throw an event on every change of battery charge level (some HP notebooks do this even with CM battery), so there is no need to poll for battery charge level.

Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Seyfried wrote:

| On Thu, Jan 20, 2005 at 11:04:02AM -0500, Rich Townsend wrote:
|
|
|>The best solution would be to perform a run-time check. I'll see if I
|>can add code to dynamically detect if the ac_adapter and battery
|>directories are empy on module insertion, and only add the legacy
|>interfaces if they are.
|
|
| not "empty" but "do not exist". We will probably find machines that have
| working CM Battery but can also be used with SBS.
| Or maybe it is possible from kernelspace to check if a module is loaded
| to lock each other out => if battery or ac is loaded, sbs will refuse
| to load and the other way round.

I think the only way to do this is to integrate the sbs code into the battery and ac_adapter drivers. that way at load time, the kernel code can check which type of driver to use or both if possible/useful. that could be hard, I'm aware of that.

|
|
|>PS Last night, I got a proof-of-concept for event notifications working.
|>I still haven't got battery alarms working, but we should now be able to
|>do event-driven AC and battery present/charging/discharging statuses.
|
|
| It would be pretty cool to throw an event on every change of battery charge
| level (some HP notebooks do this even with CM battery), so there is no need
| to poll for battery charge level.

wasn't there a not-so-recent-but-almost discussion about this issue in the acpi-devel mailing list? I think people argued that acpi would NOT generate events! that could mean that the acpi layer wouldn't generate events at all or that it wouldn't generate events on behalf of hardware unable to generate events.

care to comment?

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: [email protected]
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB8QCceRy7HWZxjWERArT0AJ9Kxk1il9RjoV1/Ow4+Dl63L0yR4wCgz4+B cf9OpRuKZaKnKHzZe02Csd8=
=KSIG
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

i have no idea ;-) I know that hp nx5000's continuously notify me via /proc/acpi/event if the charge level changes, so i only have to poll battery after an notification and that is very handy IMO :-)

Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

2005/1/20, Rich Townsend :

I'm sorry for reply an old mail.
But, it's the last release of acpi_sbs kernel module?

I know about sbs-linux project in sourceforge, but I get a big delay (about ~20 seconds) with my Acer TM 4001 when I try to read battery status.

There are any way to fix it?

Thanks!!

(Sorry my English, I'm not an English speaker)

$ sh ~/.bash_history

Antoni Villalonga i Noceras
#Web# ~> http://friki.org
#Bloc# ~> http://bloc.balearweb.net/friki
#Jabber# ~> friki-STYuutOhSz/[email protected]


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Hi Antoni,

i think yes.

perhaps you have the same problem which is discussed in this thread:

https://sourceforge.net/tracker/index.php?func=detail&aid=1191536&group_id=129330&atid=714494

I've an ACER Extensa 3002WLMI which is said to be the same machine. With the information given there i have no problems on my machine :-) Perhaps we should integrate this information in a new Version/Patchfile and send it to Rich.

If you need more Information (or if ir works for you) please let me know.

same problem here :-)

Regards
Olaf

BTW: have you got suspend to disk / ram working on your machine?

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Please try if this works too
http://bugzilla.kernel.org/show_bug.cgi?id=3851#c73

Thanks,
Luming

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Hi Luming,

I'd like to try the given patch...

but
--->

The requested
URL /pub/linux/kernel/people/lenb/acpi/patches/release/2.6.12/acpi-20050729-2.6.12.patch.gz was not found on this server.
<---

can you please give me a hint where i am wrong.

Regards
Olaf

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Hmm, I don't know. But you can find the ec patch here:
http://bugzilla.kernel.org/attachment.cgi?id=5574&action=view

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Hi Luming,

got it :-)
Thanks a lot. I'll give it a try and let you know if this works for me.

Olaf

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Hi Luming,

with this patch ( i applied it to a fresh 2.6.13 vanilla kernel ) a older problem reoccured on my machine. When i type (fast) sometimes keystrokes are missed. But the time for reading the battery state is OK. Can i give you more information or help in debugging?

With ec_burst=1 it seems to be slightly better but i'm afraid some keys are lost then too.

Thanks a lot
Olaf

BTW.: if this is only a problem on my (rotten) ACER. The patch from Rich Townsend works here really sufficient for me. But I am really willing to help you - if you want me to do so

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Thanks for testing. Without ec_burst=1, the driver still use spin lock. If ec_burst=1 doesn't work for you, I will be a little supprised.

So, please report any issue with ec_burst=1.

Thanks,
Luming

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Hi Luming,

since I'm not able to get my ati-card or my ipw2200 up and running with this Kernel. I will have to solve this problems first. But afterwards i'll test again and let you know.

Thanks a lot for your assistance
Olaf

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Hello Luming,

now i've got everything up and running with kernel 2.6.13-git6. And yes you are right. With your patch my machine is lucky again :-) Readout of battery is fast and with ec_burst=1 there seems to be no problem with missing keys.

Thanks again
Olaf

P.S.: If i should do some special testing or you please let me know.

System:
Acer Extensa 3002 WLMI
gentoo linux with kernel-2.6.13-git6
ipw2200-1.0.6 (WPA with wpa_supplicant)
ATI fglrx 8.14.13

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Please try this patch:
http://bugzilla.kernel.org/show_bug.cgi?id=3851#c73

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

2005/9/6, Antoni Villalonga:

Thanks to Olaf and Yu!

It doesn't work for me, I don't have more time today at weekend I'll retry. :-)

THANKS!!

$ sh ~/.bash_history

Antoni Villalonga i Noceras
#Web# ~> http://friki.org
#Bloc# ~> http://bloc.balearweb.net/friki
#Jabber# ~> friki-STYuutOhSz/[email protected]


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

See the bug report here: https://sourceforge.net/tracker/index.php?func=detail&aid=1191536&group_id=129330&atid=714494
I have exactely the same laptop than you and I manage to read battery state without problem using a modified DSDT table. If you use kernels 2.6.11 or 2.6.12, you can use the attached patch which includes the changes suggested in the bug report. If you use kernel 2.6.13, this patch doesn't apply cleanly. However, without extra patch, it works correctly for me.

François Valenduc

diff -urN linux-2.6.11.5-original/drivers/acpi/ec.c linux-2.6.11.5/drivers/acpi/ec.c
@@ -31,6 +31,7 @@
 #include <linux/delay.h>
 #include <linux/proc_fs.h>
 #include <linux/seq_file.h>
+#include <asm/semaphore.h>
 #include <asm/io.h>
 #include <acpi/acpi_bus.h>
 #include <acpi/acpi_drivers.h>

@@ -54,8 +55,8 @@
 #define ACPI_EC_EVENT_OBF	0x01	/* Output buffer full */
 #define ACPI_EC_EVENT_IBE	0x02	/* Input buffer empty */
 
-#define ACPI_EC_UDELAY		100	/* Poll @ 100us increments */
-#define ACPI_EC_UDELAY_COUNT	1000	/* Wait 10ms max. during EC ops */
+#define ACPI_EC_MSLEEP		1	/* Sleep 1ms between polling */
+#define ACPI_EC_MSLEEP_COUNT	10	/* Wait 10ms max. during EC ops */
 #define ACPI_EC_UDELAY_GLK	1000	/* Wait 1ms max. to get global lock */
 
 #define ACPI_EC_COMMAND_READ	0x80

@@ -87,7 +88,7 @@
 	struct acpi_generic_address	command_addr;
 	struct acpi_generic_address	data_addr;
 	unsigned long			global_lock;
-	spinlock_t			lock;
+	struct semaphore		sem;
 };
 
 /* If we find an EC via the ECDT, we need to keep a ptr to its context */

@@ -106,7 +107,7 @@
 	u8			event)
 {
 	u32			acpi_ec_status = 0;
-	u32			i = ACPI_EC_UDELAY_COUNT;
+	u32			i = ACPI_EC_MSLEEP_COUNT;
 
 	if (!ec)
 		return -EINVAL;

@@ -118,7 +119,7 @@
 			acpi_hw_low_level_read(8, &acpi_ec_status, &ec->status_addr);
 			if (acpi_ec_status & ACPI_EC_FLAG_OBF)
 				return 0;
-			udelay(ACPI_EC_UDELAY);
+			msleep(ACPI_EC_MSLEEP);
 		} while (--i>0);
 		break;
 	case ACPI_EC_EVENT_IBE:

@@ -126,7 +127,7 @@
 			acpi_hw_low_level_read(8, &acpi_ec_status, &ec->status_addr);
 			if (!(acpi_ec_status & ACPI_EC_FLAG_IBF))
 				return 0;
-			udelay(ACPI_EC_UDELAY);
+			msleep(ACPI_EC_MSLEEP);
 		} while (--i>0);
 		break;
 	default:

@@ -137,7 +138,7 @@
 }
 
 
-static int
+int
 acpi_ec_read (
 	struct acpi_ec		*ec,
 	u8			address,

@@ -145,7 +146,6 @@
 {
 	acpi_status		status = AE_OK;
 	int			result = 0;
-	unsigned long		flags = 0;
 	u32			glk = 0;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_read");

@@ -161,7 +161,10 @@
 			return_VALUE(-ENODEV);
 	}
 	
-	spin_lock_irqsave(&ec->lock, flags);
+	if (down_interruptible (&ec->sem)) {
+		result = -ERESTARTSYS;
+		goto end_nosem;
+	}
 
 	acpi_hw_low_level_write(8, ACPI_EC_COMMAND_READ, &ec->command_addr);
 	result = acpi_ec_wait(ec, ACPI_EC_EVENT_IBE);

@@ -180,7 +183,8 @@
 		*data, address));
 
 end:
-	spin_unlock_irqrestore(&ec->lock, flags);
+	up (&ec->sem);
+end_nosem:
 
 	if (ec->global_lock)
 		acpi_release_global_lock(glk);

@@ -189,7 +193,7 @@
 }
 
 
-static int
+int
 acpi_ec_write (
 	struct acpi_ec		*ec,
 	u8			address,

@@ -197,7 +201,6 @@
 {
 	int			result = 0;
 	acpi_status		status = AE_OK;
-	unsigned long		flags = 0;
 	u32			glk = 0;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_write");

@@ -211,7 +214,10 @@
 			return_VALUE(-ENODEV);
 	}
 
-	spin_lock_irqsave(&ec->lock, flags);
+	if (down_interruptible (&ec->sem)) {
+		result = -ERESTARTSYS;
+		goto end_nosem;
+	}
 
 	acpi_hw_low_level_write(8, ACPI_EC_COMMAND_WRITE, &ec->command_addr);
 	result = acpi_ec_wait(ec, ACPI_EC_EVENT_IBE);

@@ -232,7 +238,8 @@
 		data, address));
 
 end:
-	spin_unlock_irqrestore(&ec->lock, flags);
+	up (&ec->sem);
+end_nosem:
 
 	if (ec->global_lock)
 		acpi_release_global_lock(glk);

@@ -284,14 +291,13 @@
 EXPORT_SYMBOL(ec_write);
 
 
-static int
+int
 acpi_ec_query (
 	struct acpi_ec		*ec,
 	u32			*data)
 {
 	int			result = 0;
 	acpi_status		status = AE_OK;
-	unsigned long		flags = 0;
 	u32			glk = 0;
 
 	ACPI_FUNCTION_TRACE("acpi_ec_query");

@@ -312,7 +318,10 @@
 	 * Note that successful completion of the query causes the ACPI_EC_SCI
 	 * bit to be cleared (and thus clearing the interrupt source).
 	 */
-	spin_lock_irqsave(&ec->lock, flags);
+	if (down_interruptible (&ec->sem)) {
+		result = -ERESTARTSYS;
+		goto end_nosem;
+	}
 
 	acpi_hw_low_level_write(8, ACPI_EC_COMMAND_QUERY, &ec->command_addr);
 	result = acpi_ec_wait(ec, ACPI_EC_EVENT_OBF);

@@ -324,7 +333,8 @@
 		result = -ENODATA;
 
 end:
-	spin_unlock_irqrestore(&ec->lock, flags);
+	up (&ec->sem);
+end_nosem:
 
 	if (ec->global_lock)
 		acpi_release_global_lock(glk);

@@ -348,7 +358,6 @@
 {
 	struct acpi_ec		*ec = (struct acpi_ec *) ec_cxt;
 	u32			value = 0;
-	unsigned long		flags = 0;
 	static char		object_name[5] = {'_','Q','0','0','\0'};
 	const char		hex[] = {'0','1','2','3','4','5','6','7',
 				         '8','9','A','B','C','D','E','F'};

@@ -358,9 +367,11 @@
 	if (!ec_cxt)
 		goto end;	
 
-	spin_lock_irqsave(&ec->lock, flags);
+	if (down_interruptible (&ec->sem)) {
+		return_VOID;
+	}
 	acpi_hw_low_level_read(8, &value, &ec->command_addr);
-	spin_unlock_irqrestore(&ec->lock, flags);
+	up(&ec->sem);
 
 	/* TBD: Implement asynch events!
 	 * NOTE: All we care about are EC-SCI's.  Other EC events are

@@ -623,7 +634,7 @@
 
 	ec->handle = device->handle;
 	ec->uid = -1;
-	spin_lock_init(&ec->lock);
+	sema_init(&ec->sem, 1);
 	strcpy(acpi_device_name(device), ACPI_EC_DEVICE_NAME);
 	strcpy(acpi_device_class(device), ACPI_EC_CLASS);
 	acpi_driver_data(device) = ec;

@@ -832,7 +843,7 @@
 	status = acpi_evaluate_integer(handle, "_GPE", NULL, &ec_ecdt->gpe_bit);
 	if (ACPI_FAILURE(status))
 		return status;
-	spin_lock_init(&ec_ecdt->lock);
+	sema_init(&ec_ecdt->sem, 1);
 	ec_ecdt->global_lock = TRUE;
 	ec_ecdt->handle = handle;
 

@@ -909,7 +920,7 @@
 	ec_ecdt->status_addr = ecdt_ptr->ec_control;
 	ec_ecdt->data_addr = ecdt_ptr->ec_data;
 	ec_ecdt->gpe_bit = ecdt_ptr->gpe_bit;
-	spin_lock_init(&ec_ecdt->lock);
+	sema_init(&ec_ecdt->sem, 1);
 	/* use the GL just to be safe */
 	ec_ecdt->global_lock = TRUE;
 	ec_ecdt->uid = ecdt_ptr->uid;

2005/9/6, Antoni Villalonga:

It works now.

The delay of cat /proc/acpi/battery/BAT0/state its nearly 0.170 seconds.

Read form this file block my pc while it is reading.I advise it if i'm moving the mouse or typing, it stop for a moment.

$ while true; cat /proc/acpi/battery/BAT0/state > /dev/null; done
It block totally the computer <:D

Thanks to all!

PS: I use linux-2.6.13

$ sh ~/.bash_history

Antoni Villalonga i Noceras
#Web# ~> http://friki.org
#Bloc# ~> http://bloc.balearweb.net/friki
#Jabber# ~> friki-STYuutOhSz/[email protected]


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Hi Antoni ;)

It seems so. By the way, it doesn't compile against 2.6.13...

David Gómez                                      Jabber ID: [email protected]


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

It seems you install the modules in /lib/modules/XXX/i2c etc. instead of /lib/modules/XXX/kernel/driver/i2c etc. Is that intentional?

I got bitten by this since I previously installed the i2c-acpi-ec driver in /lib/modules/XXX/kernel/driver/i2c, which apparently took precedence over the one installed in /lib/modules/XXX/i2c.

-- Johan

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

I do this because everything in /lib/modules/XXX/kernel/* gets clobbered when you do a make modules_install from the kernel source tree; any module not part of the source tree is deleted. That's why external modules really don't belong in the /lib/modules/XXX/kernel/* tree -- IMHO.

Of course, this will eventaully be moot, when/if the SBS stuff actually gets put into the kernel. I have recently realized that the whole SBS functionality can be implemented in terms of control methods in the DSDT, without the need for any kernel drivers. It may be interesting to have a shot at implementing the SBS this way, and then making some sort of autopatch script which adds the SBS code to a supplied DSDT.

cheers,

Rich

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

I see.

Nice. This would require a kernel recompile/reboot for each DSDT modification...

-- Johan

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

http://gaugusch.at/kernel.shtml has a patch to allow you to include your DSDT in an initrd to save you having to recompile the kernel.

Bernard.

 Bernard Blackham <bernard at blackham dot com dot au>


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johan Vromans wrote:

| Rich Townsend <[email protected]> writes:
|
|
|>I do this because everything in /lib/modules/XXX/kernel/* gets
|>clobbered when you do a make modules_install from the kernel source
|>tree;
|
|
| I see.
|
|
|>I have recently realized that the whole SBS functionality can be
|>implemented in terms of control methods in the DSDT, without the
|>need for any kernel drivers.
|
|
| Nice. This would require a kernel recompile/reboot  for each DSDT
| modification...

not nice, I guess. 99.9% of the interested (me included) wouldn't be able to patch their DSDT and with generated ASL (is it ASL or AML or... ACPI language) code for their specific case.

but academically interesting :-)

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: [email protected]
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB8QGAeRy7HWZxjWERAiBTAKChHU1ZOOuJLe1QmG/seChXZO2v1wCgulDn MSYoH67MOpPTB27v0ad467c=
=dJMG
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

[Quoting Pedro Venda, on January 21 2005, 13:20, in "Re: [ACPI] Re: Smart"]

I found it almost trivial to correct the DSDT and customize the kernel to use it. No hard or mysterious tricks involved...

-- Johan

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johan Vromans wrote:

| [Quoting Pedro Venda, on January 21 2005, 13:20, in "Re: [ACPI] Re: Smart"]
|
|>99.9% of the interested (me included) wouldn't be able to patch
|>their DSDT and with generated ASL (is it ASL or AML or... ACPI
|>language) code for their specific case.
|
|
| I found it almost trivial to correct the DSDT and customize the kernel
| to use it. No hard or mysterious tricks involved...

ok, but it'd take a tree of hacked DSDT for all sorts of laptops to make the patching automatic. I guess for me or you it'd be simple to patch, but talk about a linux user that uses suse linux or mandrake to make it easier to use/administrate...

not flaming distros here! I'm just saying those try to do things automatically on behalf of people (which is not bad in many cases) and it'd be hard to do such automatic patching.

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: [email protected]
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB8QTneRy7HWZxjWERArduAJ9qAaDlzbF2BD6gzjdpcbH4HSkdVACfdokt fACjOib484Y7LlqxKQ+PR0A=
=KTsH
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

What if you just had to run a perl script, and then add an "initrd=" line to your kernel boot parameters? Because the code would be *so* much cleaner if a lot of the tasks were moved to the DSDT; in particular, we could get rid of i2c_acpi_sbs, and thus remove the dependency of ACPI on I2C.

cheers,

Rich

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rich Townsend wrote:

| Pedro Venda wrote:
|
|> Johan Vromans wrote:
|> | Rich Townsend <[email protected]> writes:
|> |
|> |
|> |>I do this because everything in /lib/modules/XXX/kernel/* gets
|> |>clobbered when you do a make modules_install from the kernel source
|> |>tree;
|> |
|> |
|> | I see.
|> |
|> |
|> |>I have recently realized that the whole SBS functionality can be
|> |>implemented in terms of control methods in the DSDT, without the
|> |>need for any kernel drivers.
|> |
|> |
|> | Nice. This would require a kernel recompile/reboot  for each DSDT
|> | modification...
|>
|> not nice, I guess. 99.9% of the interested (me included) wouldn't be
|> able to
|> patch their DSDT and with generated ASL (is it ASL or AML or... ACPI
|> language)
|> code for their specific case.
|
|
| What if you just had to run a perl script, and then add an "initrd="
| line to your kernel boot parameters? Because the code would be *so* much
| cleaner if a lot of the tasks were moved to the DSDT; in particular, we
| could get rid of i2c_acpi_sbs, and thus remove the dependency of ACPI on
| I2C.

I'd agree that the i2c-acpi dependency is not pretty.

on the other hand... I'm still not liking the CM (dump, limited) interface to control SBS (smart, sophisticated) batteries. yes, CM gets the information from the SBS hardware but I can't stop feeling loosing capabilities.

any way, I'm willing to cooperate with you on either decision, although I seriously dislike the DSDT thing.

regards,
pedro venda.

|
| cheers,
|
| Rich
|
|
| -------------------------------------------------------
| This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
| Tool for open source databases. Create drag-&-drop reports. Save time
| by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
| Download a FREE copy at http://www.intelliview.com/go/osdn_nl
| _______________________________________________
| Acpi-devel mailing list
| [email protected]
| https://lists.sourceforge.net/lists/listinfo/acpi-devel

- --

Pedro João Lopes Venda
email: [email protected]
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB8QbJeRy7HWZxjWERAtVTAKDE8wO1QtEOSXAt+blvQka7KDGC0ACgtTLO ANWFnIdDuWs8CRQv1hkpTe8=
=cSaT
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Ah, but there doesn't have to be any loss of capabilities. There are two separate issues here:

1) Implementing the SMBus access through control methods, as described by the API in the SMBus-CM specification (which I'll be trying out very soon)

2) Implementing a control-method wrapper for SBS, so that it can be accessed using the API described in Sec. 10.2 of the ACPI specification.

Issue (1) basically removes the need for the i2c_acpi_ec module, and indeed the need to have any i2c or smbus support in the kernel; everything is done through the embedded controller. This is highly desirable.

Issue (2) would allow SBS batteries to appear to the kernel as CM batteries, meaning that the stock battery.ko module can be used. This, however, is obviously a backward-compatibility step, and not the way forward; however, it may be a 'clean' interim solution to implementing SBS, in lieu of a yet-to-be-designed library for accessing SBS and CM batteries through a standard interface.

cheers,

Rich

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rich Townsend wrote:

| Pedro Venda wrote:
|
|> Rich Townsend wrote:
|> | Pedro Venda wrote:
|> |
|> |> Johan Vromans wrote:
|> |> | Rich Townsend <[email protected]> writes:
|> |> |
|> |> |
|> |> |>I do this because everything in /lib/modules/XXX/kernel/* gets
|> |> |>clobbered when you do a make modules_install from the kernel source
|> |> |>tree;
|> |> |
|> |> |
|> |> | I see.
|> |> |
|> |> |
|> |> |>I have recently realized that the whole SBS functionality can be
|> |> |>implemented in terms of control methods in the DSDT, without the
|> |> |>need for any kernel drivers.
|> |> |
|> |> |
|> |> | Nice. This would require a kernel recompile/reboot  for each DSDT
|> |> | modification...
|> |>
|> |> not nice, I guess. 99.9% of the interested (me included) wouldn't be
|> |> able to
|> |> patch their DSDT and with generated ASL (is it ASL or AML or... ACPI
|> |> language)
|> |> code for their specific case.
|> |
|> |
|> | What if you just had to run a perl script, and then add an "initrd="
|> | line to your kernel boot parameters? Because the code would be *so*
|> much
|> | cleaner if a lot of the tasks were moved to the DSDT; in particular, we
|> | could get rid of i2c_acpi_sbs, and thus remove the dependency of
|> ACPI on
|> | I2C.
|>
|> I'd agree that the i2c-acpi dependency is not pretty.
|>
|> on the other hand... I'm still not liking the CM (dump, limited)
|> interface to
|> control SBS (smart, sophisticated) batteries. yes, CM gets the
|> information from
|> the SBS hardware but I can't stop feeling loosing capabilities.
|
|
| Ah, but there doesn't have to be any loss of capabilities. There are two
| separate issues here:
|
| 1) Implementing the SMBus access through control methods, as described
| by the API in the SMBus-CM specification (which I'll be trying out very
| soon)
|
| 2) Implementing a control-method wrapper for SBS, so that it can be
| accessed using the API described in Sec. 10.2 of the ACPI specification.
|
| Issue (1) basically removes the need for the i2c_acpi_ec module, and
| indeed the need to have any i2c or smbus support in the kernel;
| everything is done through the embedded controller. This is highly
| desirable.
|
| Issue (2) would allow SBS batteries to appear to the kernel as CM
| batteries, meaning that the stock battery.ko module can be used. This,
| however, is obviously a backward-compatibility step, and not the way
| forward; however, it may be a 'clean' interim solution to implementing
| SBS, in lieu of a yet-to-be-designed library for accessing SBS and CM
| batteries through a standard interface.

ahhh, there's a nice explanation. thanks :-)

so, just to clear things up, solution (1) doesn't need DSDT patching?? that'd be excelent "value-for-money". it'd provide access to SBS information without ugly acpi-i2c dependencies.

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: [email protected]
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB8WMceRy7HWZxjWERAhKuAJ9uxEDnia3IOkTJBXWI30jYgCaNHwCeNvJ5 HWHutp6t9GOKO3IHvnHEtqs=
=g4zf
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Pedro Venda wrote:

<snip>

No, both require DSDT patching -- unless there is a way to add objects into the ACPI namespace dynamically (anyone got any ideas on this?).

This of course is a big barrier to adoption. But having said that, patching a DSDT is no more difficult than patching a kernel. You just tweak the source code, compile it, and then add an initrd= argument to the kernel boot parameters.

However, maybe someone could do some work on making it even easier? Any thoughts?

cheers,

Rich

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Acpi-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-devel

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

What about people who didn't use initrd in their kernel?

z.a.kaleta (sanskryt), registered Linux User #279350


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Hi!

Well, we could just ask Acer to include that SBS code into their DSDTs....
Pavel

People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pavel Machek wrote:

| Hi!
|
|
|>|>I do this because everything in /lib/modules/XXX/kernel/* gets
|>|>clobbered when you do a make modules_install from the kernel source
|>|>tree;
|>|
|>|
|>| I see.
|>|
|>|
|>|>I have recently realized that the whole SBS functionality can be
|>|>implemented in terms of control methods in the DSDT, without the
|>|>need for any kernel drivers.
|>|
|>|
|>| Nice. This would require a kernel recompile/reboot  for each DSDT
|>| modification...
|>
|>not nice, I guess. 99.9% of the interested (me included) wouldn't be able to
|>patch their DSDT and with generated ASL (is it ASL or AML or... ACPI
|>language)
|>code for their specific case.
|>
|>but academically interesting :-)
|
|
| Well, we could just ask Acer to include that SBS code into their
| DSDTs....
| 								Pavel

which apparently is a waste of time. from some e-mails I've seen around, they are very reluctant to support anything linux-related.

regards,
pedro venda.
- --

Pedro João Lopes Venda
email: [email protected]
http://arrakis.dhis.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB8+CVeRy7HWZxjWERAtWDAKChdQD+2XgjEo2WXkxM2syyZzwnegCfXOew 49zml3i6YKUDBy1LsaPMmRU=
=ymwH
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

That's not exactly true. Although they tell this to every end-user (funny sice they are buying the stuff), some people at acer seem to be willing to cooperate with Linux distributors. Of course, it depends on the phase of the moon and what that people had to lunch today and for sure the right hand at acer does not know what the left hand is doing (and the other way round). But not everything is lost, there may still be some hope (and i will of course not buy acer until this is fixed).

Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl

this works fine (no more interrupting the charge).
at every boot, with ac ever plugged i lost 1% of the charge, the led in front of the laptop is green ( full charge ) but the driver says 97%

thx again for your great work!

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

That's because the battery won't switch the charger on until the charge level drops below a certain value. Also, once the battery is fully charged, it begins slowly to discharge again. This is because the battery's internal circuitry requires a small amount of power.

cheers,

Rich

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Exactly. This must be implemented in i2c-acpi-ec, and a event notifier sohuld be done in order to pass this to the children. Also I have to modify i2c-acpi-ec in order to make this driver event driven (we write to the PCRTL, then wait for an event (query number will be 0x20 in this perticular case) from the EC before processing further), and in the handler, if the alarm bit is set, then notify the child.
That what I meant in a previous mail with 'overriden the _Q20', by the fact that I think its only a dummy alarm ack in order to be sure the smbus is still functionnal even if the OS do not provide a driver for accessing the smbus. I never meant to do this in DSDT. I'm sorry for the confusion.

This may be another trouble.

Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


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

OK, thanks for the clarification. Out of interest, how do I install event handlers for the EC? A quick look through ec.c doesn't show any obvious way to do it.

Yeah, I think that may be the real problem. Even without proper alarm handling in i2c-acpi-ec, the alarms sent by the battery should still show up in the _Q20 method I hacked into my DSDT. Is it possible to fake an SMBus alarm, to track whether it is getting through the EC driver code properly

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

Simple. Need to add this into ec.c ;)

I don't know.

Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


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

My gut instinct would be that the i2c-acpi-ec SBMus host in the embedded controller is distinct from the i2c-piix SMBus host in the southbridge. But I really am very new to all of this, and gut instinct won't bring a dead Thinkpad back to life. I would sit tight until someone with deeper knowledge says "yay or nay".

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

The latter. But its possible that devices connected may be faulty. I'm not aware of a thinkpad with such i2c access (though its possible there is one than can be legacy).

Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi.

i don't know if this is a bug, but when the battery is charging and some program is polling the smartbattery through the /proc interface, the charging stopped for one oder two seconds. this happens only, if i get the information through the /proc interface.
if i'm using the "standalone" smartbattery program, the charging process doesn't stop.
my laptop is an acer travelmate 4002mli.

Hendrik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFB68n7gL2kQgmW9pgRArf4AJ9DopXCEIZnRhiHnRHRwPsHfcSJPgCeLlhX LhTiH2UsCyxhi9na0tX83w8=
=3DE2
-----END PGP SIGNATURE-----

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

That's fine! Many thanks.

Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


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

This is realy great.
I have:
1. patched the 2.6.10 kernel with Bruno patch
2. compiled the kernel without ac and battery modules in acpi tree;
3. compiled and instaled the i2c_acpi_ec and acpi_sbs moudules;
4. instaled acpid package from debian;
and now I have the klaptopdaemon in Kde window manager showing when the laptop is on ac or on battery with the info.
Congratulations and thanks for all persons involvd in this project.

z.a.kaleta (sanskryt), registered Linux User #279350


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

Some more info - the laptop is Acer Travelmate 4001 VLMIwith Pentium (R) M processor 1.50Ghz stepping 06.
Except info abourt source of power after all moves described above the klaptopdaemon applet permit me to change the position throttling in /proc/acpi/procesor/CPU0.
With this way I can put the throttling for 00%, 12%, 25%, 37%, 50%, 62%, 75% and 87% which corespondent to T0 to T7 state.
Of course I can't be sure that anything is realy done for processor but I can inform that using mechnism from Klaptopdaemon applet I can change the info show in the file /proc/acpi/processor/CPU0/throttling.
This mechanism didn't change the info in /proc/acpi/processor/CPU0/performance file.
May be this can help You. If any other info is neccesary I can try to deliver it if You inform me what to do.

z.a.kaleta (sanskryt), registered Linux User #279350


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

thx for your drivers, i tryed the first release and they works fine (without ac), then i tryed your last one 20050116
here both battery and ac works BUT while recharging the battery the orange led in front of my laptop, turn on and off continuosly, so continuosly stop recharging.

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