1. 26 8月, 2015 1 次提交
  2. 30 6月, 2015 1 次提交
  3. 19 6月, 2015 1 次提交
    • H
      acpi-video-detect: video: Make video_detect code part of the video module · 14ca7a47
      Hans de Goede 提交于
      This is a preparation patch for the backlight interface selection logic
      cleanup, there are 2 reasons to not always build the video_detect code
      into the kernel:
      
      1) In order for the video_detect.c to also deal with / select native
      backlight interfaces on win8 systems, instead of doing this in video.c
      where it does not belong, video_detect.c needs to call into the backlight
      class code. Which cannot be done if it is builtin and the blacklight class
      is not.
      
      2) Currently all the platform/x86 drivers which have quirks to prefer
      the vendor driver over acpi-video call acpi_video_unregister_backlight()
      to remove the acpi-video backlight interface, this logic really belongs
      in video_detect.c, which will cause video_detect.c to depend on symbols of
      video.c and video.c already depends on video_detect.c symbols, so they
      really need to be a single module.
      
      Note that this commits make 2 changes so as to maintain 100% kernel
      commandline compatibility:
      
      1) The __setup call for the acpi_backlight= handling is moved to
         acpi/util.c as __setup may only be used by code which is alwasy builtin
      2) video.c is renamed to acpi_video.c so that it can be combined with
         video_detect.c into video.ko
      
      This commit also makes changes to drivers/platform/x86/Kconfig to ensure
      that drivers which use acpi_video_backlight_support() from video_detect.c,
      will not be built-in when acpi_video is not built in. This also changes
      some "select" uses to "depends on" to avoid dependency loops.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      14ca7a47
  4. 11 6月, 2015 1 次提交
  5. 26 5月, 2015 1 次提交
  6. 07 5月, 2015 2 次提交
  7. 25 4月, 2015 1 次提交
  8. 19 2月, 2015 1 次提交
    • B
      x86/intel/quark: Add Isolated Memory Regions for Quark X1000 · 28a375df
      Bryan O'Donoghue 提交于
      Intel's Quark X1000 SoC contains a set of registers called
      Isolated Memory Regions. IMRs are accessed over the IOSF mailbox
      interface. IMRs are areas carved out of memory that define
      read/write access rights to the various system agents within the
      Quark system. For a given agent in the system it is possible to
      specify if that agent may read or write an area of memory
      defined by an IMR with a granularity of 1 KiB.
      
      Quark_SecureBootPRM_330234_001.pdf section 4.5 details the
      concept of IMRs quark-x1000-datasheet.pdf section 12.7.4 details
      the implementation of IMRs in silicon.
      
      eSRAM flush, CPU Snoop write-only, CPU SMM Mode, CPU non-SMM
      mode, RMU and PCIe Virtual Channels (VC0 and VC1) can have
      individual read/write access masks applied to them for a given
      memory region in Quark X1000. This enables IMRs to treat each
      memory transaction type listed above on an individual basis and
      to filter appropriately based on the IMR access mask for the
      memory region. Quark supports eight IMRs.
      
      Since all of the DMA capable SoC components in the X1000 are
      mapped to VC0 it is possible to define sections of memory as
      invalid for DMA write operations originating from Ethernet, USB,
      SD and any other DMA capable south-cluster component on VC0.
      Similarly it is possible to mark kernel memory as non-SMM mode
      read/write only or to mark BIOS runtime memory as SMM mode
      accessible only depending on the particular memory footprint on
      a given system.
      
      On an IMR violation Quark SoC X1000 systems are configured to
      reset the system, so ensuring that the IMR memory map is
      consistent with the EFI provided memory map is critical to
      ensure no IMR violations reset the system.
      
      The API for accessing IMRs is based on MTRR code but doesn't
      provide a /proc or /sys interface to manipulate IMRs. Defining
      the size and extent of IMRs is exclusively the domain of
      in-kernel code.
      
      Quark firmware sets up a series of locked IMRs around pieces of
      memory that firmware owns such as ACPI runtime data. During boot
      a series of unlocked IMRs are placed around items in memory to
      guarantee no DMA modification of those items can take place.
      Grub also places an unlocked IMR around the kernel boot params
      data structure and compressed kernel image. It is necessary for
      the kernel to tear down all unlocked IMRs in order to ensure
      that the kernel's view of memory passed via the EFI memory map
      is consistent with the IMR memory map. Without tearing down all
      unlocked IMRs on boot transitory IMRs such as those used to
      protect the compressed kernel image will cause IMR violations and system reboots.
      
      The IMR init code tears down all unlocked IMRs and sets a
      protective IMR around the kernel .text and .rodata as one
      contiguous block. This sanitizes the IMR memory map with respect
      to the EFI memory map and protects the read-only portions of the
      kernel from unwarranted DMA access.
      Tested-by: NOng, Boon Leong <boon.leong.ong@intel.com>
      Signed-off-by: NBryan O'Donoghue <pure.logic@nexus-software.ie>
      Reviewed-by: NAndy Shevchenko <andy.schevchenko@gmail.com>
      Reviewed-by: NDarren Hart <dvhart@linux.intel.com>
      Reviewed-by: NOng, Boon Leong <boon.leong.ong@intel.com>
      Cc: andy.shevchenko@gmail.com
      Cc: dvhart@infradead.org
      Link: http://lkml.kernel.org/r/1422635379-12476-2-git-send-email-pure.logic@nexus-software.ieSigned-off-by: NIngo Molnar <mingo@kernel.org>
      28a375df
  9. 16 12月, 2014 1 次提交
    • R
      platform/x86/acerhdf: Still depends on THERMAL · 200db647
      Randy Dunlap 提交于
      acerhdf uses thermal interfaces so it should depend on THERMAL.
      It also should not select a thermal driver without checking that
      THERMAL is enabled.
      
      This fixes the following build errors when THERMAL=m and
      ACERHDF=y.
      
      drivers/built-in.o: In function `acerhdf_set_mode':
      acerhdf.c:(.text+0x3e02e1): undefined reference to `thermal_zone_device_update'
      drivers/built-in.o: In function `acerhdf_unbind':
      acerhdf.c:(.text+0x3e052d): undefined reference to `thermal_zone_unbind_cooling_device'
      drivers/built-in.o: In function `acerhdf_bind':
      acerhdf.c:(.text+0x3e0593): undefined reference to `thermal_zone_bind_cooling_device'
      drivers/built-in.o: In function `acerhdf_init':
      acerhdf.c:(.init.text+0x1c2f5): undefined reference to `thermal_cooling_device_register'
      acerhdf.c:(.init.text+0x1c360): undefined reference to `thermal_zone_device_register'
      drivers/built-in.o: In function `acerhdf_unregister_thermal':
      acerhdf.c:(.text.unlikely+0x3c67): undefined reference to `thermal_cooling_device_unregister'
      acerhdf.c:(.text.unlikely+0x3c91): undefined reference to `thermal_zone_device_unregister'
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Acked-by: NPeter Feuerer <peter@piie.net>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      200db647
  10. 04 12月, 2014 2 次提交
  11. 11 11月, 2014 1 次提交
  12. 26 9月, 2014 1 次提交
  13. 16 8月, 2014 1 次提交
  14. 11 6月, 2014 3 次提交
  15. 07 4月, 2014 3 次提交
  16. 20 3月, 2014 1 次提交
  17. 21 1月, 2014 2 次提交
    • A
    • D
      X86 platform: New BayTrail IOSF-SB MBI driver · 997ab407
      David E. Box 提交于
      Current Intel SOC cores use a MailBox Interface (MBI) to provide access to unit
      devices connected to the system fabric. This driver implements access to this
      interface on BayTrail platforms. This is a requirement for drivers that need
      access to unit registers on the platform (e.g. accessing the PUNIT for power
      management features such as RAPL). Serialized access is handled by all exported
      routines with spinlocks.
      
      The API includes 3 functions for access to unit registers:
      
      int bt_mbi_read(u8 port, u8 opcode, u32 offset, u32 *mdr)
      int bt_mbi_write(u8 port, u8 opcode, u32 offset, u32 mdr)
      int bt_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask)
      
      port:	indicating the unit being accessed
      opcode:	the read or write port specific opcode
      offset:	the register offset within the port
      mdr:	the register data to be read, written, or modified
      mask:	bit locations in mdr to change
      
      Returns nonzero on error
      
      Note: GPU code handles access to the GFX unit. Therefore access to that unit
      with this driver is disallowed to avoid conflicts.
      Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      997ab407
  18. 21 11月, 2013 1 次提交
  19. 23 10月, 2013 1 次提交
  20. 05 9月, 2013 2 次提交
  21. 11 7月, 2013 3 次提交
    • S
      toshiba_acpi: Add dependency on SERIO_I8042 · 283672e4
      Seth Forshee 提交于
      Configuring this option as a module with ACPI_TOSHIBA built-in
      results in the following errors:
      
         drivers/built-in.o: In function `toshiba_acpi_remove':
      >> toshiba_acpi.c:(.text+0x314bb0): undefined reference to `i8042_remove_filter'
         drivers/built-in.o: In function `toshiba_acpi_add':
      >> toshiba_acpi.c:(.devinit.text+0xb822): undefined reference to `i8042_install_filter'
      >> toshiba_acpi.c:(.devinit.text+0xb98b): undefined reference to `i8042_remove_filter'
      
      Add a dependency to prevent ACPI_TOSHIBA from being built-in when
      SERIO_I8042=m.
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Cc: Azael Avalos <coproscefalo@gmail.com>
      Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      283672e4
    • M
      Add trivial driver to disable Intel Smart Connect · 5c7f80f7
      Matthew Garrett 提交于
      Intel Smart Connect is an Intel-specific ACPI interface for configuring
      devices to wake up at regular intervals so they can pull down mail or other
      internet updates, and then go to sleep again. If a user enables this in
      Windows and then reboots into Linux, the device may wake up if it's put to
      sleep. Since there's no Linux userland support for any of this, the machine
      will then remain awake until something else puts it back to sleep.
      
      I haven't figured out all that much about how this works (there's a bunch
      of different ACPI calls available on the device), but this seems to be
      enough to turn it off. We can add more features to this driver if anyone
      ever cares about figuring out what the rest of the calls do or writing some
      Linux userspace to implement the rest of it.
      Signed-off-by: NMatthew Garrett <mjg59@srcf.ucam.org>
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      5c7f80f7
    • M
      Add support driver for Intel Rapid Start Technology · 34a956db
      Matthew Garrett 提交于
      Intel Rapid Start Technology is a firmware-based suspend-to-disk
      implementation. Once placed in S3, the device will wake once either a
      timeout elapses or the battery reaches a critical level. It will then resume
      to the firmware and copy the contents of RAM to a specialised partition, and
      then power off the machine. If the user turns the machine back on the
      firmware will copy the contents of the partition back to RAM and then resume
      from S3 as normal.
      
      This driver provides an interface for configuring the wakeup events and
      timeout. It still requires firmware support and an appropriate suspend
      partition.
      Signed-off-by: NMatthew Garrett <mjg59@srcf.ucam.org>
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      34a956db
  22. 08 7月, 2013 1 次提交
  23. 09 5月, 2013 1 次提交
  24. 27 2月, 2013 2 次提交
  25. 25 2月, 2013 1 次提交
  26. 22 1月, 2013 1 次提交
  27. 21 8月, 2012 1 次提交
  28. 18 8月, 2012 1 次提交
  29. 27 3月, 2012 1 次提交
    • L
      acer-wmi: add quirk table for video backlight vendor mode · 86924de2
      Lee, Chun-Yi 提交于
      There have some acer laptop have broken _BCM implemenation, the AML
      code wrote value to EC register but firmware didn't change brighenss.
      
      Fortunately, the brightness control works on those machines with
      vendor mode. So, add quirk table for video backlight vendor mode
      and unregister acpi video interface on those machines.
      
      Tested on Acer TravelMate 4750
      
      Cc: Carlos Corbacho <carlos@strangeworlds.co.uk>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Dmitry Torokhov <dtor@mail.ru>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Thomas Renninger <trenn@suse.de>
      Signed-off-by: NLee, Chun-Yi <jlee@suse.com>
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      86924de2