New Smart Battery release (incl. updated embedded controller patches)

I'm pleased to announce that, after quite a long period of inactivity, I've finally managed to grab enough spare time from the real world to bring the SBS-CM (Smart Battery System/Control Method) project up to date.

Those relying on this project to check their battery status (primarily on Acer laptops) can now grab the sbs-cm-20051112 release of SBS-CM from the Sourceforge download page:

https://sourceforge.net/project/showfiles.php?group_id=129330

In this new release, I haven't made any changes to the DSDT stuff. However, I've included new patches for replacing the spinlock mutexing in the embedded controller (EC) driver with semaphore mutexing. In addition to the kernel 2.6.10 and 2.6.11 patches included in previous releases, I now provide patches for 2.6.12. 2.6.13 and 2.6.14 kernels. I intend to offer a 2.6.15 patch once this kernel version becomes the current version.

Why are these patches still necessary? Yuming Lu has done some great work getting EC burst mode working under Linux; I believe all kernels since 2.6.13 contain the burst mode code by default. Unfortunately, however, burst mode does not fix the problems that the spinlock patches were designed to fix.

To be specific: I have fixed my kernel (2.6.13) with Yuming's most recent patch that prevents the boot process from stalling when the EC driver is loaded. Booting with burst mode enabled (boot parameter ec_burst=1) gets into immediate trouble if I have the thermal zone ACPI driver loaded, since my computer thinks the cpu is at 250C. This is indicative that the EC is not working properly.

Then, after disabling the thermal zone stuff, my computer boots up OK but still shows all the symptoms of lost interrupts. Furthermore, after 10 minutes of uptime, I notice that the kacpid task has expended nearly 3 seconds of CPU time. This expenditure is wholly due to the EC access, and indicates that for 3 seconds out of 10 minutes, the EC burst code is not interruptible -- hence the lost interrupts.

While I will certainly agree that my own patches are not nearly as elegant as the burst mode solution, I must point out that they do not lead to any lost interrupts at all -- I don't lose any keypresses, and the kacpid task doesn't use up any CPU time.

I would really appreciate it if those involved in maintaining the EC code --- both Yuming and perhaps Len Brown --- could get in touch with me and help sort out a way to get EC burst mode working without lost interrupts. When that's done, I'll feel much more comfortable about focusing on porting my SBS stuff to the HAL, which is where it belongs.

Best wishes,

Rich T

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Nice to see update on smart battery.
I'm curious if you plan to have a smart battery driver without hacking DSDT.

I'm wondering why. Because, my patch has two parts. One part is to remove spin_lock_irqsave like what your patch did. Another part is employing pure-interrupt based ec handling with burst-mode enabled for ec_read and ec_write. So, my assumption is if your spinlock patch works, my patch should work too.

I'd like to find out the root cause . For your information, I do hear some thermal related issues which is not root caused as ec issues.

If I remember clealy, my latest ec code has removed spin_lock_irqave for code patch of ec_burst=1.

I want to root cause this problem.
Would you like to open a tracker on bugzilla.kernel.org?

Thanks,
Luming

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Hi!

I think that such support existed some time ago. IIRC resolution was that the support should really be in DSDT.

Pavel

Thanks, Sharp!


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Why? The spec explicitly allows smart batteries without the DSDT providing a control method interface.

Matthew Garrett | [email protected]


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Hi!

Then it was probably mistake :-(.
Pavel

Thanks, Sharp!


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Unfortunately I don't have any hardware here which uses smart batteries, but Gnome (at least) has switched over to using Hal for displaying battery information. It would be pretty straight forward to add support for parsing the information from a smart battery driver.

Matthew Garrett | [email protected]


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Exactly. That's what I intend to do, once the remaining EC issues are resolved (there will have to be a small kernel patch to expose the EC SMBus to userspace, but that's no big deal)

cheers,

Rich

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php

Hi!

Ugh... is there any reason why smart battery driver could not present information in same (or very similar?) way to /proc/acpi/battery/*/*?

Pavel

Thanks, Sharp!


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

It take less time if the EC is programmed to pool the batteries and expose them via the EC regions, than direct access to batteries from the EC smbus.

Bruno Ducrot

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


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

Hi Pavel,

But that means that you need to use a patched DSDT, and in consequence use initrd to get Smart Battery support, isn't it? In that case it'd be good to have support for smart batteries in the kernel without forcing to use initrd.

regards,

David Gómez                                      Jabber ID: [email protected]


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

Actually, that doesn't appear to be so:

morgaine acpi # pwd
/usr/src/linux-2.6.15-gentoo-r1/drivers/acpi
morgaine acpi # grep -n irqsave ec.c

331:    spin_lock_irqsave(&ec->polling.lock, flags);
376:    spin_lock_irqsave(&ec->polling.lock, flags);
586:    spin_lock_irqsave(&ec->polling.lock, flags);
688:    spin_lock_irqsave(&ec->polling.lock, flags);

I couldn't find any tickets on bugzilla, so I thought I'd bring it up again. Perhaps Yuming's patch has been lost in submission somehow?

Regards,

Roderick

I've just build linux-2.6.14 with SBS-CM, acpi-dsdt-initrd patch and suspend2 for my Acer Extensa 3002WLMi.
I'm not shure wether the ec_burst parameter is still necessary or not. But in both cases there is an improvement compared to the situation I had before. There are still keyboard events missing, but now it's one out of 15 to 20 and not 2 to 4 out of 10.

There might be some issues with BIOS and the DSDT connected to the problem. I've compared the data from my Acer with some informations, Olaf Jansen-Olliges gave me. His system does not suffer from the 'missing key syndrome'.
Olaf's Acer has BIOS version 3A08. Mine came (6 months ago) with BIOS version 3A10, which is still not available on the Acer website. And there are some minor diffs for the DSDT too. I don't know if it's a good idea, but I will try to modify the memory size information in the DSDT I got from Olaf, so I can test it with my system.

Regards,

Berthold

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

You don't mention whether you've applied the acpi-ec-nospinlock patch. This patch is designed to remove lost interrupts completely. I know that Olaf has used this patch -- perhaps that is what you are missing.

As well as checking on this patch, could you send me the DSDT (undisassembled) so I can check it out.

cheers,

Rich

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

Hello Rich, hello Berthold,

I've used the spinlock Patch for a long time together with kernel 2.6.11 (gentoo) on my ACER extensa 3002 WLMi. After that i've switched to 2.6.12 where I've tried the ec_burst patches from Luming. With the kernel parameter ec_burst=1 i was able to use the system without problems. Later the patch from Luming found the way into the kernel and i thought fine for me no patching related to the interrupt issue needed any more. But on Bertholds machine it seems to be different from the situation here. For example he is able to suspend his machine (when he has success typing the needed commands :-) On my machine it is no problem typing the commands but in most cases (>90%) this is the last thing I do. We have tried to compare our machines and in fact we only found two differences Berthold has 1G and BIOS 3A10 while on my machine there are ony 512Mb with BIOS revision 3A08.

Now I've tested the new sbs-cm spinlock patch with kernel 2.6.13 (gentoo) and my machine continued to work without missing keys.

Regards
Olaf

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

There is no magic involved. Just keep pressing Fn+F4 long enough. ;-)

But you're right. I can suspend my machine without problems to disk. Even with (the latest) fglrx. And I can resume from suspend. Only those missing keys ...

Regards,

Berthold

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

Sorry! It was late in the evening.

I'm sure that I've applied the patch. but I will double check this evening. Which DSDT do you need? The unpatched original or the patched DSDT?

Thanks in advance

Berthold

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click

Hello Rich,

I've examined the kernel source tree I used to build the kernel. I've applied the acpi-ec-nospinlock patch, so this is not the reason for the missing events.

I've attached the original DSDT and the one I got after fixing the initial compiler errors and after I applied acer-tm4xxx-sbs-cm.diff.

Best regards

Berthold