Date: Mon, 08 Feb 2010 10:22:17 -0800 From: Nate Lawson <nate@root.org> To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-acpi@FreeBSD.org, John Baldwin <jhb@FreeBSD.org> Subject: Re: acpi_ec_ecdt_probe => acpi_ec_identify Message-ID: <4B705659.4030604@root.org> In-Reply-To: <4B703E5B.205@icyb.net.ua> References: <4B6B4A3C.5090308@icyb.net.ua> <4B6BB263.4040604@root.org> <4B6BB7AF.3040205@icyb.net.ua> <4B6BB8E2.6080204@root.org> <4B703E5B.205@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Andriy Gapon wrote: > on 05/02/2010 08:21 Nate Lawson said the following: >> Andriy Gapon wrote: >>> on 05/02/2010 07:53 Nate Lawson said the following: >>>> I agree in concept. The ECDT-based probe method was intended to get it >>>> active as early as possible, and Linux has a quirk to create a fake ECDT >>>> to get an early EC on some systems that require it but don't have an ECDT. >>>> >>>> However, I thought jhb@'s multi-pass probe work would be a better way to >>>> support this than moving it into device_identify(). Is that code ready >>>> to use yet? >>> I agree with this. But, unfortunately, the code doesn't seem to be as ready as >>> everyone would love it to be. >> Ok, then identify() is fine too. > > I've been trying to understand why and if we need to handle ECDT table at all. > It seems that we need it for reasons that don't allow acpi_ec_ecdt_probe => > acpi_ec_identify conversion. It seems that Nate had a very good reason to put a > call to acpi_ec_ecdt_probe where it is now. > While no OS code uses EC early during boot, _INI methods of Devices may access EC > address space and that seems to be one of the reasons to have ECDT. > _INI methods are called quite early from AcpiInitializeObjects. > This is before we do any walk of ACPI namespace and, thus, before enumeration of > ACPI devices. Yes, that is the reason for the early nature of the ECDT probe. However, some AML needs this early probe method but does not have an ECDT. This was mostly an issue with older Compaq laptops, IIRC. In this case, Linux would assume it knows something about the EC (since it is always at the same IO ports: 0x64, 0x66) and create a fake ECDT for its own probe to consume. This would be enabled manually by a boot flag. I'm assuming Windows used a different probe method. It may be possible to "ping" the EC and if it answers, probe it. I'm not sure this is safe but might be worth investigating. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B705659.4030604>