linux-toradex.git/drivers/acpi/Makefile, branch v5.5-rc7

Merge branch 'acpi-mm'

2019-11-26T09:31:02+00:00

* acpi-mm:
  ACPI: HMAT: use %u instead of %d to print u32 values
  ACPI: NUMA: HMAT: fix a section mismatch
  ACPI: HMAT: don't mix pxm and nid when setting memory target processor_pxm
  ACPI: NUMA: HMAT: Register "soft reserved" memory as an "hmem" device
  ACPI: NUMA: HMAT: Register HMAT at device_initcall level
  device-dax: Add a driver for "hmem" devices
  dax: Fix alloc_dax_region() compile warning
  lib: Uplevel the pmem "region" ida to a global allocator
  x86/efi: Add efi_fake_mem support for EFI_MEMORY_SP
  arm/efi: EFI soft reservation to memblock
  x86/efi: EFI soft reservation to E820 enumeration
  efi: Common enable/disable infrastructure for EFI soft reservation
  x86/efi: Push EFI_MEMMAP check into leaf routines
  efi: Enumerate EFI_MEMORY_SP
  ACPI: NUMA: Establish a new drivers/acpi/numa/ directory

Merge branches 'acpi-utils', 'acpi-platform', 'acpi-video' and 'acpi-doc'

2019-11-26T09:30:49+00:00

* acpi-utils:
  iommu/amd: Switch to use acpi_dev_hid_uid_match()
  mmc: sdhci-acpi: Switch to use acpi_dev_hid_uid_match()
  ACPI / LPSS: Switch to use acpi_dev_hid_uid_match()
  ACPI / utils: Introduce acpi_dev_hid_uid_match() helper
  ACPI / utils: Move acpi_dev_get_first_match_dev() under CONFIG_ACPI
  ACPI / utils: Describe function parameters in kernel-doc

* acpi-platform:
  ACPI: platform: Unregister stale platform devices
  ACPI: Always build evged in

* acpi-video:
  ACPI: video: update doc for acpi_video_bus_DOS()

* acpi-doc:
  ACPI: Documentation: Minor spelling fix in namespace.rst

ACPI: NUMA: Establish a new drivers/acpi/numa/ directory

2019-11-07T14:43:38+00:00

Currently hmat.c lives under an "hmat" directory which does not enhance
the description of the file. The initial motivation for giving hmat.c
its own directory was to delineate it as mm functionality in contrast to
ACPI device driver functionality.

As ACPI continues to play an increasing role in conveying
memory location and performance topology information to the OS take the
opportunity to co-locate these NUMA relevant tables in a combined
directory.

numa.c is renamed to srat.c and moved to drivers/acpi/numa/ along with
hmat.c.

Signed-off-by: Dan Williams 
Reviewed-by: Dave Hansen 
Acked-by: Thomas Gleixner 
Signed-off-by: Rafael J. Wysocki

ACPI / PMIC: Add Cherry Trail Crystal Cove PMIC OpRegion driver

2019-10-25T09:43:08+00:00

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: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki

ACPI / PMIC: Add byt prefix to Crystal Cove PMIC OpRegion driver

2019-10-25T09:43:08+00:00

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 4d9ed62ab142 ("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: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Rafael J. Wysocki

ACPI: Always build evged in

2019-10-14T08:59:57+00:00

Although the Generic Event Device is a Hardware-reduced
platfom device in principle, it should not be restricted to
ACPI_REDUCED_HARDWARE_ONLY.

Kernels supporting both fixed and hardware-reduced ACPI platforms
should be able to probe the GED when dynamically detecting that a
platform is hardware-reduced. For that, the driver must be
unconditionally built in.

Signed-off-by: Arjan van de Ven 
Signed-off-by: Samuel Ortiz 
Signed-off-by: Rafael J. Wysocki

acpi/hmat: Parse and report heterogeneous memory

2019-04-04T16:41:20+00:00

Systems may provide different memory types and export this information
in the ACPI Heterogeneous Memory Attribute Table (HMAT). Parse these
tables provided by the platform and report the memory access and caching
attributes to the kernel messages.

Reviewed-by: Rafael J. Wysocki 
Acked-by: Jonathan Cameron 
Tested-by: Jonathan Cameron 
Signed-off-by: Keith Busch 
Tested-by: Brice Goglin 
Signed-off-by: Greg Kroah-Hartman

ACPI / LPSS: Make PCI dependency explicit

2019-01-15T22:16:18+00:00

After commit 5d32a66541c4 (PCI/ACPI: Allow ACPI to be built without
CONFIG_PCI set), it is possible to build ACPI without any PCI support.

This code depends on PCI. Compile only when PCI is present.

Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set")
Signed-off-by: Sinan Kaya 
Signed-off-by: Rafael J. Wysocki

PCI/ACPI: Allow ACPI to be built without CONFIG_PCI set

2018-12-20T09:19:49+00:00

We are compiling PCI code today for systems with ACPI and no PCI
device present. Remove the useless code and reduce the tight
dependency.

Signed-off-by: Sinan Kaya 
Acked-by: Bjorn Helgaas  # PCI parts
Acked-by: Ingo Molnar 
Signed-off-by: Rafael J. Wysocki

ACPI/ADXL: Add address translation interface using an ACPI DSM

2018-10-16T08:03:00+00:00

Some new Intel servers provide an interface so that the OS can ask the
BIOS to translate a system physical address to a memory address (socket,
memory controller, channel, rank, dimm, etc.). This is useful for EDAC
drivers that want to take the address of an error reported in a machine
check bank and let the user know which DIMM may need to be replaced.

Specification for this interface is available at:

  https://cdrdv2.intel.com/v1/dl/getContent/603354

 [ Based on earlier code by Qiuxu Zhuo . ]

 [ bp: Make the first pr_info() in adxl_init() pr_debug() so that it
   doesn't pollute every dmesg. ]

Signed-off-by: Tony Luck 
Signed-off-by: Borislav Petkov 
Acked-by: Rafael J. Wysocki 
Tested-by: Qiuxu Zhuo 
CC: Len Brown 
CC: linux-acpi@vger.kernel.org
CC: linux-edac@vger.kernel.org
Link: http://lkml.kernel.org/r/20181015202620.23610-1-tony.luck@intel.com