1. 21 1月, 2010 1 次提交
  2. 28 12月, 2009 1 次提交
  3. 24 12月, 2009 6 次提交
  4. 23 12月, 2009 16 次提交
  5. 22 12月, 2009 5 次提交
    • A
      ACPI: processor: remove _PDC object list from struct acpi_processor · e59897fe
      Alex Chiang 提交于
      When we call _PDC, we get a handle to the processor, allocate the
      object list buffer as needed, and free it immediately after calling
      _PDC.
      
      There's no need to drag around this object list with us everywhere
      else, so let's just get rid of it.
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      e59897fe
    • A
      ACPI: processor: change acpi_processor_set_pdc() interface · 43bab25c
      Alex Chiang 提交于
      When calling _PDC, we really only need the handle to the processor
      to call the method; we don't look at any other parts of the
      struct acpi_processor * given to us.
      
      In the early path, when we walk the namespace, we are given the
      handle directly, so just pass it through to acpi_processor_set_pdc()
      without stuffing it into a wasteful struct acpi_processor allocated
      on the stack each time
      
      This saves 2834 bytes of stack.
      
      Update the interface accordingly.
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      43bab25c
    • A
      ACPI: processor: unify arch_acpi_processor_cleanup_pdc · 47817254
      Alex Chiang 提交于
      The x86 and ia64 implementations of the function in $subject are
      exactly the same.
      
      Also, since the arch-specific implementations of setting _PDC have
      been completely hollowed out, remove the empty shells.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      47817254
    • A
      ACPI: processor: finish unifying arch_acpi_processor_init_pdc() · 6c5807d7
      Alex Chiang 提交于
      The only thing arch-specific about calling _PDC is what bits get
      set in the input obj_list buffer.
      
      There's no need for several levels of indirection to twiddle those
      bits. Additionally, since we're just messing around with a buffer,
      we can simplify the interface; no need to pass around the entire
      struct acpi_processor * just to get at the buffer.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      6c5807d7
    • A
      ACPI: processor: call _PDC early · 78f16996
      Alex Chiang 提交于
      We discovered that at least one machine (HP Envy), methods in the DSDT
      attempt to call external methods defined in a dynamically loaded SSDT.
      
      Unfortunately, the DSDT methods we are trying to call are part of the
      EC initialization, which happens very early, and the the dynamic SSDT
      is only loaded when a processor _PDC method runs much later.
      
      This results in namespace lookup errors for the (as of yet) undefined
      methods.
      
      Since Windows doesn't have any issues with this machine, we take it
      as a hint that they must be evaluating _PDC much earlier than we are.
      
      Thus, the proper thing for Linux to do should be to match the Windows
      implementation more closely.
      
      Provide a mechanism to call _PDC before we enable the EC. Doing so loads
      the dynamic tables, and allows the EC to be enabled correctly.
      
      The ACPI processor driver will still evaluate _PDC in its .add() method
      to cover the hotplug case.
      
      Resolves: http://bugzilla.kernel.org/show_bug.cgi?id=14824
      
      Cc: ming.m.lin@intel.com
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      78f16996
  6. 19 12月, 2009 1 次提交
  7. 18 12月, 2009 10 次提交