Skip to content

L
linux
An error occurred fetching the project authors.
Switch branch/tag
  1. 22 Jun, 2020 1 commit
  3. 13 Feb, 2020 1 commit
  5. 07 Nov, 2019 1 commit
  7. 25 Oct, 2019 2 commits
    • Hans de Goede's avatar
      ACPI / PMIC: Add Cherry Trail Crystal Cove PMIC OpRegion driver · cefe6aac
      Hans de Goede authored 
      We have no docs for the CHT Crystal Cove PMIC. The Asus Zenfone-2 kernel
code has 2 Crystal Cove regulator drivers, one calls the PMIC a "Crystal
Cove Plus" PMIC and talks about Cherry Trail, so presuambly that one
could be used to get register info for the regulators if we need to
implement regulator support in the future.

For now the sole purpose of this driver is to make
intel_soc_pmic_exec_mipi_pmic_seq_element work on devices with a
CHT Crystal Cove PMIC.

Specifically this fixes the following MIPI PMIC sequence related errors
on e.g. an Asus T100HA:

[  178.211801] intel_soc_pmic_exec_mipi_pmic_seq_element: No PMIC registered
[  178.211897] [drm:intel_dsi_dcs_init_backlight_funcs [i915]] *ERROR* mipi_exec_pmic failed, error: -6
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cefe6aac
    • Hans de Goede's avatar
      ACPI / PMIC: Add byt prefix to Crystal Cove PMIC OpRegion driver · ed852cde
      Hans de Goede authored 
      Our current Crystal Cove OpRegion driver is only valid for the
Crystal Cove PMIC variant found on Bay Trail (BYT) boards,
Cherry Trail (CHT) based boards use another variant.

At least the regulator registers are different on CHT and these registers
are one of the things controlled by the custom PMIC OpRegion.

Commit 4d9ed62a ("mfd: intel_soc_pmic: Export separate mfd-cell
configs for BYT and CHT") has disabled the intel_pmic_crc.c code for CHT
devices by removing the "crystal_cove_pmic" MFD cell on CHT devices.

This commit renames the intel_pmic_crc.c driver and the cell to be
prefixed with "byt" to indicate that this code is for BYT devices only.

This is a preparation patch for adding a separate PMIC OpRegion
driver for the CHT variant of the Crystal Cove PMIC (sometimes called
Crystal Cove Plus in Android kernel sources).
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ed852cde
  9. 14 Oct, 2019 1 commit
  11. 04 Apr, 2019 1 commit
  13. 15 Jan, 2019 1 commit
  15. 20 Dec, 2018 1 commit
  17. 16 Oct, 2018 1 commit
  19. 17 May, 2018 1 commit
  21. 20 Mar, 2018 1 commit
    • Rafael J. Wysocki's avatar
      ACPI: Add Time and Alarm Device (TAD) driver · 95c513ec
      Rafael J. Wysocki authored 
      Introduce a driver for the ACPI Time and Alarm Device (TAD) based on
Section 9.18 of ACPI 6.2.

This driver only supports the system wakeup capabilities of the TAD
which are mandatory.  Support for the RTC capabilities of the TAD
will be added to it in the future.

This driver is entirely sysfs-based.  It provides attributes (under
the TAD platform device) to allow user space to manage the AC and DC
wakeup timers of the TAD: set and read their values, set and check
their expire timer wake policies, check and clear their status and
check the capabilities of the TAD reported by AML.  The DC timer
attributes are only present if the TAD supports a separate DC alarm
timer.

The wakeup events handling and power management of the TAD is
expected to be taken care of by the ACPI PM domain attached to its
platform device.
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      95c513ec
  23. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored 
      Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier.  The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
 - file had no licensing information it it.
 - file was a */uapi/* one with no licensing information in it,
 - file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne.  Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed.  Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
 - Files considered eligible had to be source code files.
 - Make and config files were included as candidates if they contained >5
   lines of source
 - File already had some variant of a license header in it (even if <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  25. 13 Oct, 2017 1 commit
  27. 11 Oct, 2017 1 commit
    • Srinivas Pandruvada's avatar
      ACPI / LPIT: Add Low Power Idle Table (LPIT) support · eeb2d80d
      Srinivas Pandruvada authored 
      Add functionality to read LPIT table, which provides:

 - Sysfs interface to read residency counters via
   /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
   /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us

Here the count "low_power_idle_cpu_residency_us" shows the time spent
by CPU package in low power state.  This is read via MSR interface,
which points to MSR for PKG C10.

Here the count "low_power_idle_system_residency_us" show the count the
system was in low power state. This is read via MMIO interface. This
is mapped to SLP_S0 residency on modern Intel systems. This residency
is achieved only when CPU is in PKG C10 and all functional blocks are
in low power state.

It is possible that none of the above counters present or anyone of the
counter present or all counters present.

For example: On my Kabylake system both of the above counters present.
After suspend to idle these counts updated and prints:

 6916179
 6998564

This counter can be read by tools like turbostat to display. Or it can
be used to debug, if modern systems are reaching desired low power state.

 - Provides an interface to read residency counter memory address

   This address can be used to get the base address of PMC memory
   mapped IO.  This is utilized by intel_pmc_core driver to print
   more debug information.

In addition, to avoid code duplication to read iomem, removed the read of
iomem from acpi_os_read_memory() in osl.c and made a common function
acpi_os_read_iomem(). This new function is used for reading iomem in
in both osl.c and acpi_lpit.c.

Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdfSigned-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      eeb2d80d
  29. 03 Oct, 2017 1 commit
    • Rajmohan Mani's avatar
      ACPI / PMIC: Add TI PMIC TPS68470 operation region driver · e13452ac
      Rajmohan Mani authored 
      The Kabylake platform coreboot (Chrome OS equivalent of
BIOS) has defined 4 operation regions for the TI TPS68470 PMIC.
These operation regions are to enable/disable voltage
regulators, configure voltage regulators, enable/disable
clocks and to configure clocks.

This config adds ACPI operation region support for TI TPS68470 PMIC.
TPS68470 device is an advanced power management unit that powers
a Compact Camera Module (CCM), generates clocks for image sensors,
drives a dual LED for flash and incorporates two LED drivers for
general purpose indicators.

This driver enables ACPI operation region support to control voltage
regulators and clocks for the TPS68470 PMIC.
Signed-off-by: default avatarRajmohan Mani <rajmohan.mani@intel.com>
Acked-by: default avatarSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e13452ac
  31. 03 Aug, 2017 1 commit
    • Lukas Wunner's avatar
      ACPI / property: Support Apple _DSM properties · 899596e0
      Lukas Wunner authored 
      While the rest of the world has standardized on _DSD as the way to store
device properties in AML (introduced with ACPI 5.1 in 2014), Apple has
been using a custom _DSM to achieve the same for much longer (ever since
they switched from DeviceTree-based PowerPC to Intel in 2005, verified
with MacOS X 10.4.11).

The theory of operation on macOS is as follows:  AppleACPIPlatform.kext
invokes mergeEFIproperties() and mergeDSMproperties() for each device to
merge properties conveyed by EFI drivers as well as properties stored in
AML into the I/O Kit registry from which they can be retrieved by
drivers.  We've been supporting EFI properties since commit 58c5475a
("x86/efi: Retrieve and assign Apple device properties").  The present
commit adds support for _DSM properties, thereby completing our support
for Apple device properties.  The _DSM properties are made available
under the primary fwnode, the EFI properties under the secondary fwnode.
So for devices which possess both property types, they can all be
elegantly accessed with the uniform API in <linux/property.h>.

Until recently we had no need to support _DSM properties, they contained
only uninteresting garbage.  The situation has changed with MacBooks and
MacBook Pros introduced since 2015:  Their keyboard is attached with SPI
instead of USB and the _CRS data which is necessary to initialize the
spi driver only contains valid information if OSPM responds "false" to
_OSI("Darwin").  If OSPM responds "true", _CRS is empty and the spi
driver fails to initialize.  The rationale is very simple, Apple only
cares about macOS and Windows:  On Windows, _CRS contains valid data,
whereas on macOS it is empty.  Instead, macOS gleans the necessary data
from the _DSM properties.

Since Linux deliberately defaults to responding "true" to _OSI("Darwin"),
we need to emulate macOS' behaviour by initializing the spi driver with
data returned by the _DSM.

An out-of-tree driver for the SPI keyboard exists which currently binds
to the ACPI device, invokes the _DSM, parses the returned package and
instantiates an SPI device with the data gleaned from the _DSM:
https://github.com/cb22/macbook12-spi-driver/commit/9a416d699ef4
https://github.com/cb22/macbook12-spi-driver/commit/0c34936ed9a1

By adding support for Apple's _DSM properties in generic ACPI code, the
out-of-tree driver will be able to register as a regular SPI driver,
significantly reducing its amount of code and improving its chances to
be mainlined.

The SPI keyboard will not be the only user of this commit:  E.g. on the
MacBook8,1, the UART-attached Bluetooth device likewise returns empty
_CRS data if OSPM returns "true" to _OSI("Darwin").

The _DSM returns a Package whose format unfortunately deviates slightly
from the _DSD spec:  The properties are marshalled up in a single Package
as alternating key/value elements, unlike _DSD which stores them as a
Package of 2-element Packages.  The present commit therefore converts
the Package to _DSD format and the ACPI core can then treat the data as
if Apple would follow the standard.

Well, except for one small annoyance:  The properties returned by the
_DSM only ever have one of two types, Integer or Buffer.  The former is
retrievable as usual with device_property_read_u64(), but the latter is
not part of the _DSD spec and it is not possible to retrieve Buffer
properties with the device_property_read_*() functions due to the type
checking performed in drivers/acpi/property.c.  It is however possible
to retrieve them with acpi_dev_get_property().  Apple is using the
Buffer type somewhat sloppily to store null-terminated strings but also
integers.  The real data type is not distinguishable by the ACPI core
and the onus is on the caller to use the contents of the Buffer in an
appropriate way.

In case Apple moves to _DSD in the future, this commit first checks for
_DSD and falls back to _DSM only if _DSD is not found.
Tested-by: default avatarRonald Tschalär <ronald@innovation.ch>
Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      899596e0
  33. 26 Apr, 2017 1 commit
    • Hans de Goede's avatar
      ACPI / bus: Introduce a list of ids for "always present" devices · b7ecf663
      Hans de Goede authored 
      Several Bay / Cherry Trail devices (all of which ship with Windows 10) hide
the LPSS PWM controller in ACPI, typically the _STA method looks like this:

    Method (_STA, 0, NotSerialized)  // _STA: Status
    {
        If (OSID == One)
        {
            Return (Zero)
        }

        Return (0x0F)
    }

Where OSID is some dark magic seen in all Cherry Trail ACPI tables making
the machine behave differently depending on which OS it *thinks* it is
booting, this gets set in a number of ways which we cannot control, on
some newer machines it simple hardcoded to "One" aka win10.

This causes the PWM controller to get hidden, which means Linux cannot
control the backlight level on cht based tablets / laptops.

Since loading the driver for this does no harm (the only in kernel user
of it is the i915 driver, which will only uses it when it needs it), this
commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
for the LPSS PWM device, fixing the lack of backlight control.
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
[ rjw: Rename the new file to utils.c ]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b7ecf663
  35. 20 Apr, 2017 1 commit
  37. 28 Mar, 2017 1 commit
    • Josh Poimboeuf's avatar
      ACPI: Fix incompatibility with mcount-based function graph tracing · 61b79e16
      Josh Poimboeuf authored 
      Paul Menzel reported a warning:

  WARNING: CPU: 0 PID: 774 at /build/linux-ROBWaj/linux-4.9.13/kernel/trace/trace_functions_graph.c:233 ftrace_return_to_handler+0x1aa/0x1e0
  Bad frame pointer: expected f6919d98, received f6919db0
    from func acpi_pm_device_sleep_wake return to c43b6f9d

The warning means that function graph tracing is broken for the
acpi_pm_device_sleep_wake() function.  That's because the ACPI Makefile
unconditionally sets the '-Os' gcc flag to optimize for size.  That's an
issue because mcount-based function graph tracing is incompatible with
'-Os' on x86, thanks to the following gcc bug:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42109

I have another patch pending which will ensure that mcount-based
function graph tracing is never used with CONFIG_CC_OPTIMIZE_FOR_SIZE on
x86.

But this patch is needed in addition to that one because the ACPI
Makefile overrides that config option for no apparent reason.  It has
had this flag since the beginning of git history, and there's no related
comment, so I don't know why it's there.  As far as I can tell, there's
no reason for it to be there.  The appropriate behavior is for it to
honor CONFIG_CC_OPTIMIZE_FOR_{SIZE,PERFORMANCE} like the rest of the
kernel.
Reported-by: default avatarPaul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
Acked-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: All applicable <stable@vger.kernel.org>
      61b79e16
  39. 03 Feb, 2017 1 commit
  41. 28 Sep, 2016 1 commit
  43. 24 Sep, 2016 1 commit
    • Mika Westerberg's avatar
      ACPI / watchdog: Add support for WDAT hardware watchdog · 058dfc76
      Mika Westerberg authored 
      Starting from Intel Skylake the iTCO watchdog timer registers were moved to
reside in the same register space with SMBus host controller.  Not all
needed registers are available though and we need to unhide P2SB (Primary
to Sideband) device briefly to be able to read status of required NO_REBOOT
bit. The i2c-i801.c SMBus driver used to handle this and creation of the
iTCO watchdog platform device.

Windows, on the other hand, does not use the iTCO watchdog hardware
directly even if it is available. Instead it relies on ACPI Watchdog Action
Table (WDAT) table to describe the watchdog hardware to the OS. This table
contains necessary information about the the hardware and also set of
actions which are executed by a driver as needed.

This patch implements a new watchdog driver that takes advantage of the
ACPI WDAT table. We split the functionality into two parts: first part
enumerates the WDAT table and if found, populates resources and creates
platform device for the actual driver. The second part is the driver
itself.

The reason for the split is that this way we can make the driver itself to
be a module and loaded automatically if the WDAT table is found. Otherwise
the module is not loaded.
Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      058dfc76
  45. 12 Sep, 2016 1 commit
  47. 24 Jul, 2016 1 commit
  49. 21 Jul, 2016 2 commits
    • Srinivas Pandruvada's avatar
      ACPI / DPTF: move int340x_thermal.c to the DPTF folder · c11dd70f
      Srinivas Pandruvada authored 
      Since DPTF has its own folder under ACPI, move this file also there.
Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c11dd70f
    • Srinivas Pandruvada's avatar
      ACPI / DPTF: Add DPTF power participant driver · 6256ebd5
      Srinivas Pandruvada authored 
      This driver adds support for Dynamic Platform and Thermal Framework
(DPTF) Platform Power Participant device (INT3407) support.

This participant is responsible for exposing platform telemetry such as:
    max_platform_power
    platform_power_source
    adapter_rating
    battery_steady_power
    charger_type

These attributes are presented via sysfs interface under the INT3407
platform device:
$ls /sys/bus/platform/devices/INT3407\:00/dptf_power/
    adapter_rating_mw
    battery_steady_power_mw
    charger_type
    max_platform_power_mw
    platform_power_source
    `
ACPI methods description used in this driver:
    PMAX: Maximum platform power that can be supported by the battery in
          mW.
    PSRC: System charge source,
            0x00 = DC
            0x01 = AC
            0x02 = USB
            0x03 = Wireless Charger
    ARTG: Adapter rating in mW (Maximum Adapter power) Must be 0 if no
          AC adapter is plugged in.
    CTYP: Charger Type,
            Traditional : 0x01
            Hybrid: 0x02
            NVDC: 0x03
    PBSS: Returns max sustained power for battery in milliWatts.

The INT3407 also contains _BTS and _BIX objects, which are compliant to
ACPI 5.0, specification. Those objects are already used by ACPI battery
(PNP0C0A) driver and information about them is exported via Linux power
supply class registration.
Signed-off-by: default avatarSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6256ebd5
  51. 11 Jul, 2016 1 commit
    • Mika Westerberg's avatar
      ACPI: Rename configfs.c to acpi_configfs.c to prevent link error · fafe5306
      Mika Westerberg authored 
      If we compile ACPI configfs.c as module it will confuse the linker as it
hides symbols from the actual configfs:

Kernel: arch/x86/boot/bzImage is ready  (#1236)
  MODPOST 5739 modules
ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "configfs_register_subsystem" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "config_group_init" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "config_item_init_type_name" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "config_group_init_type_name" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "configfs_undepend_item" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] undefined!
...

Prevent these by renaming the file to acpi_configfs.c instead.
Reported-by: default avatarScott Lawson <scott.lawson@intel.com>
Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fafe5306
  53. 08 Jul, 2016 1 commit
  55. 24 Jun, 2016 1 commit
  57. 10 Jun, 2016 1 commit
  59. 04 May, 2016 1 commit
    • Lv Zheng's avatar
      ACPI / osi: Collect _OSI handling into one single file · e5f660eb
      Lv Zheng authored 
      _OSI handling code grows giant and it's time to move them into one file.

This patch collects all _OSI handling code into one single file.
So that we only have the following functions to be used externally:

 early_acpi_osi_init(): Used by DMI detections;
 acpi_osi_init(): Used to initialize OSI command line settings and install
                  Linux specific _OSI handler;
 acpi_osi_setup(): The API that should be used by the external quirks.
 acpi_osi_is_win8(): The API is used by the external drivers to determine
                     if BIOS supports Win8.

CONFIG_DMI is not useful as stub dmi_check_system() can make everything
stub because of strip.

No functional changes.
Tested-by: default avatarLukas Wunner <lukas@wunner.de>
Tested-by: default avatarChen Yu <yu.c.chen@intel.com>
Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e5f660eb
  61. 09 Apr, 2016 1 commit
    • Sinan Kaya's avatar
      ACPI: implement Generic Event Device · 3db80c23
      Sinan Kaya authored 
      Generic Event Device described in ACPI 6.1 allows platforms to handle
platform interrupts in ACPI ASL statements. It borrows constructs like
_EVT from GPIO events. All interrupts are listed in _CRS and the handler
is written in _EVT method. Here is an example.

Device (GED0)
{

	Name (_HID, "ACPI0013")
	Name (_UID, 0)
	Name(_CRS, ResourceTemplate ()
	{
		Interrupt(ResourceConsumer, Edge, ActiveHigh, Shared, , , )
		 {123}
	})

	Method (_EVT, 1) {
		if (Lequal(123, Arg0))
		{
		}
	}
}

Wake capability has not been implemented yet.
Signed-off-by: default avatarSinan Kaya <okaya@codeaurora.org>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3db80c23
  63. 16 Feb, 2016 1 commit
  65. 14 Dec, 2015 2 commits
  67. 09 Dec, 2015 1 commit
    • Javier Martinez Canillas's avatar
      ACPI: Fix build errors due objects compiled unconditionally · 08dc7c7e
      Javier Martinez Canillas authored 
      If the CONFIG_ACPI Kconfig symbol is not enabled and a partial build is
attempted, compile errors will happen due missing types and identifiers.

This can be easily reproduced with the following commands:

$ export CROSS_COMPILE="arm-linux-gnueabihf-" ARCH=arm
$ make allmodconfig
$ make M=drivers/acpi/
  CC      drivers/acpi//tables.o
drivers/acpi//tables.c:235:3: warning: 'struct acpi_subtable_proc' declared inside parameter list
   unsigned int max_entries)
   ^
drivers/acpi//tables.c:235:3: warning: its scope is only this definition or declaration, which is probably not what you want
drivers/acpi//tables.c: In function 'acpi_parse_entries_array':
drivers/acpi//tables.c:269:4: error: invalid use of undefined type 'struct acpi_subtable_proc'
...
scripts/Makefile.build:258: recipe for target 'drivers/acpi//tables.o' failed
make[1]: *** [drivers/acpi//tables.o] Error 1
Makefile:1401: recipe for target '_module_drivers/acpi/' failed
make: *** [_module_drivers/acpi/] Error 2

This is because objects are tried to be built unconditionally even when
CONFIG_ACPI is not enabled. This is usually not a problem since arches'
Kconfig sources drivers/acpi/Kconfig directly and also selects ACPI but
the Makefile should conditionally build the objects as well to prevent
these build errors.
Signed-off-by: default avatarJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      08dc7c7e
  69. 12 Oct, 2015 1 commit
    • Ashwin Chaugule's avatar
      ACPI: Introduce CPU performance controls using CPPC · 337aadff
      Ashwin Chaugule authored 
      CPPC stands for Collaborative Processor Performance Controls
and is defined in the ACPI v5.0+ spec. It describes CPU
performance controls on an abstract and continuous scale
allowing the platform (e.g. remote power processor) to flexibly
optimize CPU performance with its knowledge of power budgets
and other architecture specific knowledge.

This patch adds a shim which exports commonly used functions
to get and set CPPC specific controls for each CPU. This enables
CPUFreq drivers to gather per CPU performance data and use
with exisiting governors or even allows for customized governors
which are implemented inside CPUFreq drivers.
Signed-off-by: default avatarAshwin Chaugule <ashwin.chaugule@linaro.org>
Reviewed-by: default avatarAl Stone <al.stone@linaro.org>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      337aadff
  71. 25 Aug, 2015 2 commits
    • Ashwin Chaugule's avatar
      ACPI: Decouple ACPI idle and ACPI processor drivers · 5f05586c
      Ashwin Chaugule authored 
      This patch introduces a new Kconfig symbol, ACPI_PROCESSOR_IDLE,
which is auto selected by architectures which support the ACPI
based C states for CPU Idle management.

The processor_idle driver in its present form contains declarations
specific to X86 and IA64. Since there are no reasonable defaults
for other architectures e.g. ARM64, the driver is selected only for
X86 or IA64.

This helps in decoupling the ACPI processor_driver from the ACPI
processor_idle driver which is useful for the upcoming alternative
patchwork for controlling CPU Performance (CPPC) and CPU Idle (LPI).
Signed-off-by: default avatarAshwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5f05586c
    • Ashwin Chaugule's avatar
      ACPI: Split out ACPI PSS from ACPI Processor driver · 239708a3
      Ashwin Chaugule authored 
      The ACPI processor driver is currently tied too closely
to the ACPI P-states (PSS) and other related constructs
for controlling CPU performance.

The newer ACPI specification (v5.1 onwards) introduces
alternative methods to PSS. These new mechanisms are
described within each ACPI Processor object and so they
need to be scanned whenever a new Processor object is detected.
This patch introduces a new Kconfig symbol to allow for
finer configurability among the two options for controlling
performance states. There is no change in functionality and
the option is auto-selected by the architectures which support it.

A future commit will introduce support for CPPC: A newer method of
controlling CPU performance. The OS is not expected to support
CPPC and PSS at the same time, so the Kconfig option lets us make
the two mutually exclusive at compile time.
Signed-off-by: default avatarAshwin Chaugule <ashwin.chaugule@linaro.org>
[ rjw: Changelog ]
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      239708a3
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7