RE: ACPI/ECDT on gateway 200x notebook

* RE: ACPI/ECDT on gateway 200x notebook
@ 2004-01-14  2:23 Yu, Luming
       [not found] ` <3ACA40606221794F80A5670F0AF15F8401720CCA-SRlDPOYGfgogGBtAFL8yw7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
  0 siblings, 1 reply; 17+ messages in thread
From: Yu, Luming @ 2004-01-14  2:23 UTC (permalink / raw)
  To: Greg Sarjeant, Ducrot Bruno
  Cc: Li, Shaohua, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

Greg,

Thanks for your information. I think It's important to append your
conclusion to 
bug 1744.  To any new issue, you can just file a new one, But it should
be
Linux ACPI bug.

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 
> Greg Sarjeant
> Sent: Tuesday, January 13, 2004 11:27 PM
> To: Ducrot Bruno
> Cc: Li, Shaohua; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: [ACPI] ACPI/ECDT on gateway 200x notebook
> 
> 
> Hi,
> 
>    I just wanted to send along an update on this, rather than 
> continue to clutter bug 1744 with potentially unrelated issues.
> 
>    First off, the AE_BAD_PARAMETER issue is defiintely caused 
> by the DWordAcc in the _GPE method. Using the bit_width patch 
> from bug 1744 masks this error. Overriding the DSDT with the 
> new Gateway 200X DSDT on acpi.sourceforge.net fixes it. Both 
> of these options restore fan, thermal and button 
> functionality. The lid is not fully supported with the 
> bit_width patch, but the fixed DSDT restores the lid fully. 
> The adapter and battery are still missing after applying 
> either solution. This is apparently because of the missing ECDT.
> 
>    To fix the ECDT problem, I have now tried both this patch 
> and the fake_ecdt patch that can be found somewhere in this 
> thread: http://sourceforge.net/mailarchive/message.php?msg_id=6514510
> 
>    I have used them with kernel 2.4.23 and 2.4.24. As far as 
> I know, neither will apply to 2.6.x. Both patches restore the 
> ac adapter and the battery, which is terrific. The parameter 
> to pass to the kernel for the fake_ecdt patch is:
> 
>    ecdt_fake=0x66:0x62:0x1c:0x01:\_SB_.PCI0.LPCB.H_EC
> 
>    There are two differences between the approaches. The 
> fake_ecdt patch yields a single H_EC subdirectory under 
> /proc/acpi/embedded_controller, while the bugzilla patch 
> gives me two. However, using the fake_ecdt patch gives me an 
> error in dmesg which is not present with the other patch. The 
> relevant section is:
> 
> ACPI: Faking ECDT
> schedule_task(): keventd has not started
> evregion-0249 [21] ev_address_space_dispa: no handler for 
> region(df6d0188) [SystemMemory]
>  exfldio-0282 [20] ex_access_region      : Region 
> SystemMemory(0) has no handler
>  psparse-1120: *** Error: Method execution failed 
> [\_SB_.PCI0.LPCB.H_EC._REG] (Node c15dfae8), AE_NOT_EXIST
> ACPI: Could not use ECDT
> 
> 
>    Note that it says that it couldn't use the ECDT, but I do 
> have my battery and adapter info, so I think it is. I'm not 
> exactly sure what this error means, or if it is anything to 
> be concerned about, since I dont see it with the other patch. 
> Any ideas?
> 
>    Also, please let me know if I should append this to bug 
> 1744. I think that we already have two unrelated problems 
> being covered there (buggy DSDT and missing ECDT), and I 
> didn't want to introduce a third ;)
> 
>    Thanks,
>     Greg
> 
> 
> 
> On Wed, 7 Jan 2004 11:54:24 +0100
> Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> 
> > On Wed, Jan 07, 2004 at 09:04:25AM +0800, Li, Shaohua wrote:
> > > Yes, the patch may resolve some problems, but it is just 
> a workaround. I guess a possible solution is if ECDT is 
> lacked, scan namespace to get EC device's info, such as GPE, 
> IO ports, then use these info to automatically make a fake 
> ECDT. Because getting info doesn't involve any operating on 
> EC device, it's feasible. A problem is if a system has more 
> than 1 EC, how do we?
> > > 
> > 
> > Yes, exactly.  Anyway, io ports 0x62, 0x66 are the legacy access
> > for the "main" EC.  Perhaps checking those ports and initilializing
> > that one only may be OK?
> > 
> > -- 
> > Ducrot Bruno
> > 
> > --  Which is worse:  ignorance or apathy?
> > --  Don't know.  Don't care.

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

^ permalink raw reply	[flat|nested] 17+ messages in thread