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

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

[Rich Townsend]

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

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

[Yu, Luming]

On Sunday 13 November 2005 12:14, Rich Townsend wrote:
> 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.

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

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

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.

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

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.

>
>  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.
If I remember clealy, my latest ec code has removed spin_lock_irqave for code 
patch of ec_burst=1.

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

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

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

[Pavel Machek]

Hi!

> > 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.
> 
> Nice to see update on smart battery.
> I'm curious if you plan to have a smart battery driver without
> hacking DSDT.

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

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

[Matthew Garrett]

On Mon, Nov 14, 2005 at 01:15:12PM +0100, Pavel Machek wrote:

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

Why? The spec explicitly allows smart batteries without the DSDT 
providing a control method interface.
-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org


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

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

[Pavel Machek]

Hi!

> > I think that such support existed some time ago. IIRC resolution was
> > that the support should really be in DSDT.
> 
> Why? The spec explicitly allows smart batteries without the DSDT 
> providing a control method interface.

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

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

[Matthew Garrett]

On Mon, Nov 14, 2005 at 05:05:25PM +0100, Pavel Machek wrote:
> > Why? The spec explicitly allows smart batteries without the DSDT 
> > providing a control method interface.
> 
> Then it was probably mistake :-(.

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 | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org


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

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

[Rich Townsend]

Matthew Garrett wrote:
> On Mon, Nov 14, 2005 at 05:05:25PM +0100, Pavel Machek wrote:
> 
>>>Why? The spec explicitly allows smart batteries without the DSDT 
>>>providing a control method interface.
>>
>>Then it was probably mistake :-(.
> 
> 
> 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.
> 

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

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

[Pavel Machek]

Hi!

> > > Why? The spec explicitly allows smart batteries without the DSDT 
> > > providing a control method interface.
> > 
> > Then it was probably mistake :-(.
> 
> 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.

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

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

[Bruno Ducrot]

On Mon, Nov 14, 2005 at 04:09:02PM +0000, Matthew Garrett wrote:
> On Mon, Nov 14, 2005 at 05:05:25PM +0100, Pavel Machek wrote:
> > > Why? The spec explicitly allows smart batteries without the DSDT 
> > > providing a control method interface.
> > 
> > Then it was probably mistake :-(.
> 
> 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.
> 

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

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

[David Gómez]

Hi Pavel,

On Nov 14 at 01:15:12, Pavel Machek wrote:
> > Nice to see update on smart battery.
> > I'm curious if you plan to have a smart battery driver without
> > hacking DSDT.
> 
> I think that such support existed some time ago. IIRC resolution was
> that the support should really be in DSDT.

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: davidge@jabber.org


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

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

[Roderick van Domburg]

Yu, Luming <luming.yu@...> writes:

> > 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.
> 
> 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.
> 
> [snip]
>
> If I remember clealy, my latest ec code has removed spin_lock_irqave for code 
> patch of ec_burst=1.

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

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

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

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

[Berthold Cogel]

Rich Townsend wrote:
> 
> 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.
> 

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

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

[Rich Townsend]

Berthold Cogel wrote:
> Rich Townsend wrote:
> 
>>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.
>>
> 
> 
> 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.
> 

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

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

[Olaf Jansen-Olliges]

Hello Rich, hello Berthold, 

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

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

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

[Berthold Cogel]

Olaf Jansen-Olliges wrote:
> Hello Rich, hello Berthold, 
> 
> 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 

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

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

[Berthold Cogel]

Rich Townsend wrote:
> 
> 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.
> 

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

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

[Berthold Cogel]

[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

Rich Townsend wrote:
> 
> 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.
> 

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

[-- Attachment #2: dsdt.aml.bz2 --]
[-- Type: application/x-bzip, Size: 9719 bytes --]

[-- Attachment #3: DSDT.aml.patched.bz2 --]
[-- Type: application/x-bzip, Size: 11129 bytes --]

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

[Lebedev, Vladimir P]

[-- Attachment #1: Type: text/plain, Size: 4350 bytes --]

Hi Rich,

I am attaching patch for kernel 2.6.14 with SBS drivers based on drivers
which were written by you and Bruno Ducrot.

Also this patch contains your latest updates of embedded controller
(ec.c file)

Differences to your version include some cleanup, handling of battery
removal/insertion, and non-conflicting operation with ACPI battery and
ac modules. 

All work pretty good on Acer TravelMate 2303LCi.

If you are interested, apply the patch, set ACPI_SBS configuration
variable (Smart Battery System - bottom of menu) to 'y' or 'm'(modprobe
acpi_sbs will be required in case 'm'), etc. Module acpi_sbs depends on
ACPI_AC, ACPI_BATTERY and I2C.

Vladimir.



 

 

 

 


-----Original Message-----
From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Rich
Townsend
Sent: Sunday, November 13, 2005 7:14 AM
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: [ACPI] 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
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel

[-- Attachment #2: diff.txt.bz2 --]
[-- Type: application/octet-stream, Size: 12726 bytes --]

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

[Yu, Luming]

 I just replace spin_lock_irq_xx with mutex for poll code path of ec driver.
It is at http://bugzilla.kernel.org/show_bug.cgi?id=5764 .

For issues observerd on Smart Battery driver with ec_intr=1 (aka "ec_burst=1")
 , we need to follow up.  

Please try to kill acpi daemon to see if your problem get resolved?

Thanks,
Luming


>-----Original Message-----
>From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
>[mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
>Lebedev, Vladimir P
>Sent: 2005年11月16日 1:39
>To: Rich Townsend; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Cc: Brown, Len; Starikovskiy, Alexey Y
>Subject: RE: [ACPI] New Smart Battery release (incl. updated 
>embedded controller patches)
>
>Hi Rich,
>
>I am attaching patch for kernel 2.6.14 with SBS drivers based 
>on drivers
>which were written by you and Bruno Ducrot.
>
>Also this patch contains your latest updates of embedded controller
>(ec.c file)
>
>Differences to your version include some cleanup, handling of battery
>removal/insertion, and non-conflicting operation with ACPI battery and
>ac modules. 
>
>All work pretty good on Acer TravelMate 2303LCi.
>
>If you are interested, apply the patch, set ACPI_SBS configuration
>variable (Smart Battery System - bottom of menu) to 'y' or 'm'(modprobe
>acpi_sbs will be required in case 'm'), etc. Module acpi_sbs depends on
>ACPI_AC, ACPI_BATTERY and I2C.
>
>Vladimir.
>
>
>
> 
>
> 
>
> 
>
> 
>
>
>-----Original Message-----
>From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>[mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Rich
>Townsend
>Sent: Sunday, November 13, 2005 7:14 AM
>To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>Subject: [ACPI] 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
>_______________________________________________
>Acpi-devel mailing list
>Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>https://lists.sourceforge.net/lists/listinfo/acpi-devel
>


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click