https://bugzilla.kernel.org/show_bug.cgi?id=14824
Zhang Rui <rui.zh...@intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |elio.v...@gmail.com
Bjorn Helgaas <bjorn.helg...@hp.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bjorn.helg...@hp.com
--- Comment #6 from Zhang Rui <rui.zh...@intel.com> 2010-05-10 06:45:20 ---
*** Bug 15801 has been marked as a duplicate of this bug. ***
--- Comment #7 from Bjorn Helgaas <bjorn.helg...@hp.com> 2010-09-13 20:51:29
---
I know this is fixed and closed already, but I don't like the fact that
we had to add special-case code to evaluate processor _PDC methods in
acpi_bus_init().
I doubt that Windows has a _PDC special case. It would have to have
been there for a long time, because I'm sure there was no Windows update
just for this laptop, and I don't see anything in the spec that would
suggest such special treatment. It'd be interesting to use qemu to
figure out whether Windows really does something special here.
I don't have time to really do anything with this now, so these are just
idle thoughts in case I can come back to this later. If I understand
correctly, the original problem is this:
1) The \_SB_.PCI0.LPCB.EC0_._REG method references \_PR_.CPU0._PPC
2) The \_PR_.CPU0._PPC definition is in an SSDT loaded by the CPU0 _PDC
method
3) Linux executes the _REG method before the _PDC method, so _PPC is
undefined
The ACPI 4.0 spec, section 6.5.4 (_REG) on p. 276 does say:
OSPM must make Embedded Controller operation regions, accessed via the
Embedded Controllers described in ECDT, available before executing any
control method.
So we clearly have to do *some* EC initialization early. But I wonder if
we're doing more than is required. We currently call acpi_boot_ec_enable(),
which uses ec_install_handlers() -> acpi_install_address_space_handler() ->
acpi_ev_execute_reg_methods() to evaluate _REG(1). But the surrounding
text from the spec suggests that _REG(1) is *not* required at this point:
Except for the cases shown below, control methods must assume all
operation regions inaccessible until the _REG(RegionSpace, 1) method
is executed. ...
The exceptions for this rule are:
1. [PCI config, I/O, and memory opregions]
2. [Embedded Controller opregions via the ECDT controller]
Maybe Windows merely happens to bind the \_PR_.CPU0 driver (and run
its _PDC method) before it binds the \_SB_.PCI0.LPCB.EC0_ driver (and
run its _REG method). It still seems wrong to me for the BIOS to rely
on that sort of ordering, but it doesn't rely on anything special in
Windows to explain why it works.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
