1. 08 7月, 2014 1 次提交
  2. 17 6月, 2014 1 次提交
    • L
      ACPICA: Restore error table definitions to reduce code differences between... · 0a00fd5e
      Lv Zheng 提交于
      ACPICA: Restore error table definitions to reduce code differences between Linux and ACPICA upstream.
      
      The following commit has changed ACPICA table header definitions:
      
       Commit: 88f074f4
       Subject: ACPI, CPER: Update cper info
      
      While such definitions are currently maintained in ACPICA. As the
      modifications applying to the table definitions affect other OSPMs'
      drivers, it is very difficult for ACPICA to initiate a process to
      complete the merge. Thus this commit finally only leaves us divergences.
      
      Revert such naming modifications to reduce the source code differecnes
      between Linux and ACPICA upstream. No functional changes.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Cc: Bob Moore <robert.moore@intel.com>
      Cc: Chen, Gong <gong.chen@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0a00fd5e
  3. 03 6月, 2014 1 次提交
  4. 01 6月, 2014 1 次提交
    • L
      ACPICA: Tables: Add mechanism to control early table checksum verification. · 47d68c7f
      Lv Zheng 提交于
      It is reported that Linux x86 kernel cannot map large tables. The following
      large SSDT table on such platform fails to pass checksum verification and
      cannot be installed:
       ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL  S2600CP  00004000 INTL 20100331)
      
      It sounds strange that in the 64-bit virtual memory address space, we
      cannot map a single ACPI table to do checksum verification. The root cause
      is:
       1. ACPICA doesn't split IO memory mapping and table mapping;
       2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map
          mechanism during early boot stage, which is more suitable for only IO
          mappings.
      
      ACPICA originally only mapped table header for signature validation, and
      this header mapping is required by OSL override mechanism. There was no
      checksum verification because we could not map the whole table using this
      OSL. While the following ACPICA commit enforces checksum verification by
      mapping the whole table during Linux boot stage and it finally triggers
      this issue on some platforms:
       Commit: 86dfc6f3
       Subject: ACPICA: Tables: Fix table checksums verification before installation.
      
      Before doing further cleanups for the OSL table mapping and override
      implementation, this patch introduces an option for such OSPMs to
      temporarily discard the checksum verification feature. It then can be
      re-enabled easily when the ACPICA and the underlying OSL is ready.
      
      This patch also deletes a comment around the limitation of mappings because
      it is not correct. The limitation is not how many times we can map in the
      early stage, but the OSL mapping facility may not be suitable for mapping
      the ACPI tables and thus may complain us the size limitation.
      
      The acpi_tb_verify_table() is renamed to acpi_tb_verify_temp_table() due to the
      work around added, it now only applies to the table descriptor that hasn't
      been installed and cannot be used in other cases. Lv Zheng.
      Tested-by: NYuanhan Liu <yuanhan.liu@linux.intel.com>
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      47d68c7f
  5. 30 5月, 2014 2 次提交
  6. 28 5月, 2014 5 次提交
    • L
      ACPI: Clean up acpi_os_map/unmap_memory() to eliminate __iomem. · a238317c
      Lv Zheng 提交于
      ACPICA doesn't include protections around address space checking, Linux
      build tests always complain increased sparse warnings around ACPICA
      internal acpi_os_map/unmap_memory() invocations.  This patch tries to fix
      this issue permanently.
      
      There are 2 choices left for us to solve this issue:
       1. Add __iomem address space awareness into ACPICA.
       2. Remove sparse checker of __iomem from ACPICA source code.
      
      This patch chooses solution 2, because:
       1.  Most of the acpi_os_map/unmap_memory() invocations are used for ACPICA.
           table mappings, which in fact are not IO addresses.
       2.  The only IO addresses usage is for "system memory space" mapping code in:
            drivers/acpi/acpica/exregion.c
            drivers/acpi/acpica/evrgnini.c
            drivers/acpi/acpica/exregion.c
          The mapped address is accessed in the handler of "system memory space"
          - acpi_ex_system_memory_space_handler().  This function in fact can be
          changed to invoke acpi_os_read/write_memory() so that __iomem can
          always be type-casted in the OSL layer.
      
      According to the above investigation, we drew the following conclusion:
      It is not a good idea to introduce __iomem address space awareness into
      ACPICA mostly in order to protect non-IO addresses.
      
      We can simply remove __iomem for acpi_os_map/unmap_memory() to remove
      __iomem checker for ACPICA code. Then we need to enforce external usages
      to invoke other APIs that are aware of __iomem address space.
      The external usages are:
       drivers/acpi/apei/einj.c
       drivers/acpi/acpi_extlog.c
       drivers/char/tpm/tpm_acpi.c
       drivers/acpi/nvs.c
      
      This patch thus performs cleanups in this way:
       1. Add acpi_os_map/unmap_iomem() to be invoked by non-ACPICA code.
       2. Remove __iomem from acpi_os_map/unmap_memory().
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a238317c
    • L
      ACPICA: Clean up redudant definitions already defined elsewhere · 92985ef1
      Lv Zheng 提交于
      Since mis-order issues have been solved, we can cleanup redundant
      definitions that already have defaults in <acpi/platform/acenv.h>.
      
      This patch removes redudant environments for __KERNEL__ surrounded code.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      92985ef1
    • L
      ACPICA: Linux headers: Add <asm/acenv.h> to remove mis-ordered inclusion of <asm/acpi.h> · 07d83914
      Lv Zheng 提交于
      There is a mis-order inclusion for <asm/acpi.h>.
      
      As we will enforce including <linux/acpi.h> for all Linux ACPI users, we
      can find the inclusion order is as follows:
      
      <linux/acpi.h>
        <acpi/acpi.h>
         <acpi/platform/acenv.h>
          (acenv.h before including aclinux.h)
          <acpi/platform/aclinux.h>
      ...........................................................................
           (aclinux.h before including asm/acpi.h)
           <asm/acpi.h>                             @Redundant@
            (ACPICA specific stuff)
      ...........................................................................
      ...........................................................................
            (Linux ACPI specific stuff) ? - - - - - - - - - - - - +
           (aclinux.h after including asm/acpi.h)   @Invisible@   |
          (acenv.h after including aclinux.h)       @Invisible@   |
         other ACPICA headers                       @Invisible@   |
      ............................................................|..............
        <acpi/acpi_bus.h>                                         |
        <acpi/acpi_drivers.h>                                     |
        <asm/acpi.h> (Excluded)                                   |
         (Linux ACPI specific stuff) ! <- - - - - - - - - - - - - +
      
      NOTE that, in ACPICA, <acpi/platform/acenv.h> is more like Kconfig
      generated <generated/autoconf.h> for Linux, it is meant to be included
      before including any ACPICA code.
      
      In the above figure, there is a question mark for "Linux ACPI specific
      stuff" in <asm/acpi.h> which should be included after including all other
      ACPICA header files.  Thus they really need to be moved to the position
      marked with exclaimation mark or the definitions in the blocks marked with
      "@Invisible@" will be invisible to such architecture specific "Linux ACPI
      specific stuff" header blocks.  This leaves 2 issues:
      1. All environmental definitions in these blocks should have a copy in the
         area marked with "@Redundant@" if they are required by the "Linux ACPI
         specific stuff".
      2. We cannot use any ACPICA defined types in <asm/acpi.h>.
      
      This patch splits architecture specific ACPICA stuff from <asm/acpi.h> to
      fix this issue.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      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: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      07d83914
    • L
      ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h> · d13bd5a6
      Lv Zheng 提交于
      From ACPICA's perspective, <acpi/actypes.h> should be included after
      inclusion of <acpi/platform/acenv.h>.  But currently in Linux,
      <acpi/platform/aclinux.h> included by <acpi/platform/acenv.h> has
      included <acpi/actypes.h> to find ACPICA types for inline functions.
      
      This causes the following problem:
      1. Redundant code in <asm/acpi.h> and <acpi/platform/aclinux.h>:
         Linux must be careful to keep conditions for <acpi/actypes.h> inclusion
         consistent with the conditions for <acpi/platform/aclinux.h> inclusion.
         Which finally leads to the issue that we have to keep many useless macro
         definitions in <acpi/platform/aclinux.h> or <asm/acpi.h>.
         Such conditions include:
           COMPILER_DEPENDENT_UINT64
           COMPILER_DEPENDENT_INT64
           ACPI_INLINE
           ACPI_SYSTEM_XFACE
           ACPI_EXTERNAL_XFACE
           ACPI_INTERNAL_XFACE
           ACPI_INTERNAL_VAR_XFACE
           ACPI_MUTEX_TYPE
           DEBUGGER_THREADING
           ACPI_ACQUIRE_GLOBAL_LOCK
           ACPI_RELEASE_GLOBAL_LOCK
           ACPI_FLUSH_CPU_CACHE
         They have default implementations in <include/acpi/platform/acenv.h>
         while Linux need to keep a copy in <asm/acpi.h> to avoid build errors.
      
      This patch introduces <acpi/platform/aclinuxex.h> to fix this issue by
      splitting conditions and declarations (most of them are inline functions)
      into 2 header files so that the wrong inclusion of <acpi/actypes.h> can be
      removed from <acpi/platform/aclinux.h>.
      
      This patch also removes old ACPI_NATIVE_INTERFACE_HEADER mechanism which is
      not preferred by Linux and adds the platform/acenvex.h to be the solution
      to solve this issue.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d13bd5a6
    • L
      ACPICA: Linux headers: Remove ACPI_PREEMPTION_POINT() due to no usages. · 636fcfef
      Lv Zheng 提交于
      This patch deletes deprecated ACPI_PREEMPTION_POINT(), there is no user
      for it in Linux kernel now.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      636fcfef
  7. 27 5月, 2014 1 次提交
  8. 20 5月, 2014 2 次提交
    • H
      ACPI / video: Add an acpi_video_unregister_backlight function · 1b7f37e1
      Hans de Goede 提交于
      Add an acpi_video_unregister_backlight function, which only unregisters
      the backlight device, and leaves the acpi_notifier in place. Some acpi_vendor
      driver need this as they don't want the acpi_video# backlight device, but do
      need the acpi-video driver for hotkey handling.
      
      Chances are that this new acpi_video_unregister_backlight() is actually
      what existing acpi_vendor drivers have wanted all along. Currently acpi_vendor
      drivers which want to disable the acpi_video# backlight device, make 2 calls:
      
      acpi_video_dmi_promote_vendor();
      acpi_video_unregister();
      
      The intention here is to make things independent of when acpi_video_register()
      gets called. As acpi_video_register() will get called on acpi-video load time
      on non intel gfx machines, while it gets called on i915 load time on intel
      gfx machines.
      
      This leads to the following 2 interesting scenarios:
      
       a) intel gfx:
        1) acpi-video module gets loaded (as it is a dependency of acpi_vendor
           and i915)
        2) acpi-video does NOT call acpi_video_register()
        3) acpi_vendor loads (lets assume it loads before i915), calls
           acpi_video_dmi_promote_vendor(); which sets
           ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
        4) calls acpi_video_unregister -> not registered, nop
        5) i915 loads, calls acpi_video_register
        6) acpi_video_register registers the acpi_notifier for the hotkeys,
           does NOT register a backlight device because of
           ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
      
       b) non intel gfx
        1) acpi-video module gets loaded (as it is a dependency acpi_vendor)
        2) acpi-video calls acpi_video_register()
        3) acpi_video_register registers the acpi_notifier for the hotkeys,
           and a backlight device
        4) acpi_vendor loads, calls acpi_video_dmi_promote_vendor()
        5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier
           for the hotkeys AND the backlight device
      
      So here we have possibly the same acpi_vendor module, making the same calls,
      but with different results, in one cases acpi-video does handle hotkeys,
      in the other it does not.
      
      Note that the a) scenario turns into b) if we assume the i915 module loads
      before the vendor_acpi module, so we also have different behavior depending
      on module loading order!
      
      So as said I believe that quite a few existing acpi_vendor modules really
      always want the behavior of a), hence this patch adds a new
      acpi_video_unregister_backlight() which gives the behavior of a) independent
      of module loading order.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1b7f37e1
    • R
      ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend · f25c0ae2
      Rafael J. Wysocki 提交于
      Rework the ACPI PM domain's PM callbacks to avoid resuming devices
      during system suspend (in order to modify their wakeup settings etc.)
      if that isn't necessary.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f25c0ae2
  9. 07 5月, 2014 15 次提交
  10. 21 4月, 2014 8 次提交
  11. 26 3月, 2014 2 次提交
  12. 20 3月, 2014 1 次提交