Ken Xue | 18 Nov 06:58 2014
Picon

[PATCH] acpi:apd:add AMD ACPI2Platform device support for x86 system.

This new feature is to interpret AMD specific ACPI device to platform device
such as I2C, UART found on AMD CZ and later chipsets. It is based on example
INTEL LPSS. Now, it can support AMD I2C & UART.

Signed-off-by: Ken Xue <Ken.Xue <at> amd.com>
Signed-off-by: Jeff Wu <Jeff.Wu <at> amd.com>
---
 arch/x86/Kconfig        |  11 +++
 drivers/acpi/Makefile   |   1 +
 drivers/acpi/acpi_apd.c | 245 ++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/acpi/internal.h |   6 ++
 drivers/acpi/scan.c     |   1 +
 5 files changed, 264 insertions(+)
 create mode 100644 drivers/acpi/acpi_apd.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ded8a67..6402c79f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
 <at>  <at>  -495,6 +495,17  <at>  <at>  config X86_INTEL_LPSS
 	  things like clock tree (common clock framework) and pincontrol
 	  which are needed by the LPSS peripheral drivers.

+config X86_AMD_PLATFORM_DEVICE
+	bool "AMD ACPI2Platform devices support"
+	depends on ACPI
+	select COMMON_CLK
+	select PINCTRL
+	---help---
+	  Select to interpret AMD specific ACPI device to platform device
(Continue reading)

wlaeosyv | 17 Nov 17:58 2014
Picon

Здpавствуйтe! Bас интepeсуют kлиeнтсkиe базы данных?

Здравcтвуйтe! Ваc интeрecyют kлиeнтckиe базы данныx?
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Andrey Skvortsov | 16 Nov 13:10 2014
Picon

[PATCH] ACPI / WAKEUP : enable wakeup power for physical child devices

commit f2b56bc808addb908a5bf435d9b942c02af9a7c4
("ACPI / PM: Use device wakeup flags for handling ACPI wakeup devices")
broke wake-on-lan for Broadcom BCM4401 Ethernet card (b44) on Dell Vostro 1500 laptop.
device_may_wakeup for main ACPI device (PCIE) returns false, because it has
can_wakeup = 0. Therefore any physical devices connected to this parent
were not prepared for wakeup/suspend. But physical device is capable to
wakeup the system.

To fix this issue device_may_wakeup was replaced with acpi_device_may_wakeup.
acpi_device_may_wakeup was written based on function
acpi_system_wakeup_device_seq_show

Signed-off-by: Andrey Skvortsov <Andrej.Skvortzov <at> gmail.com>
---
 drivers/acpi/wakeup.c |   45 +++++++++++++++++++++++++++++++++++++--------
 1 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/drivers/acpi/wakeup.c b/drivers/acpi/wakeup.c
index 1638401..0da7e70 100644
--- a/drivers/acpi/wakeup.c
+++ b/drivers/acpi/wakeup.c
 <at>  <at>  -19,6 +19,34  <at>  <at> 
 #define _COMPONENT		ACPI_SYSTEM_COMPONENT
 ACPI_MODULE_NAME("wakeup_devices")

+
+bool acpi_device_may_wakeup(struct acpi_device *dev)
+{
+	struct acpi_device_physical_node *entry;
+	bool may_wakeup = false;
(Continue reading)

Rafael J. Wysocki | 15 Nov 02:30 2014
Picon

[PATCH] ACPI / sleep: Drain outstanding events after disabling multiple GPEs

From: Rafael J. Wysocki <rafael.j.wysocki <at> intel.com>

After multiple GPEs have been disabled at the low level in one go,
like when acpi_disable_all_gpes() is called, we should always drain
all of the outstanding events from them, or the ACPICA's GPE handling
code may re-enable one of them as a result of a race condition.

For this reason, call acpi_os_wait_events_complete() after
acpi_enable_all_wakeup_gpes() and acpi_disable_all_gpes() in
acpi_freeze_prepare() and acpi_power_off_prepare(), respectively.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki <at> intel.com>
---
 drivers/acpi/sleep.c |    2 ++
 1 file changed, 2 insertions(+)

Index: linux-pm/drivers/acpi/sleep.c
===================================================================
--- linux-pm.orig/drivers/acpi/sleep.c
+++ linux-pm/drivers/acpi/sleep.c
 <at>  <at>  -630,6 +630,7  <at>  <at>  static int acpi_freeze_begin(void)
 static int acpi_freeze_prepare(void)
 {
 	acpi_enable_all_wakeup_gpes();
+	acpi_os_wait_events_complete();
 	enable_irq_wake(acpi_gbl_FADT.sci_interrupt);
 	return 0;
 }
 <at>  <at>  -825,6 +826,7  <at>  <at>  static void acpi_power_off_prepare(void)
 	/* Prepare to power off the system */
(Continue reading)

Hanjun Guo | 14 Nov 10:44 2014

[PATCH] ACPI / Kconfig: Remove redundant depends on ACPI

Since config ACPI_REDUCED_HARDWARE_ONLY is already depended
on ACPI (inside if ACPI / endif), so depdens on ACPI is redundant,
remove it and fix the minor syntax problem also.

Signed-off-by: Hanjun Guo <hanjun.guo <at> linaro.com>
---
 drivers/acpi/Kconfig | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index b23fe37..79078b8 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
 <at>  <at>  -360,15 +360,14  <at>  <at>  config ACPI_BGRT
 config ACPI_REDUCED_HARDWARE_ONLY
 	bool "Hardware-reduced ACPI support only" if EXPERT
 	def_bool n
-	depends on ACPI
 	help
-	This config item changes the way the ACPI code is built.  When this
-	option is selected, the kernel will use a specialized version of
-	ACPICA that ONLY supports the ACPI "reduced hardware" mode.  The
-	resulting kernel will be smaller but it will also be restricted to
-	running in ACPI reduced hardware mode ONLY.
+	  This config item changes the way the ACPI code is built.  When this
+	  option is selected, the kernel will use a specialized version of
+	  ACPICA that ONLY supports the ACPI "reduced hardware" mode.  The
+	  resulting kernel will be smaller but it will also be restricted to
+	  running in ACPI reduced hardware mode ONLY.

(Continue reading)

Ashwin Chaugule | 13 Nov 01:59 2014

[PATCH v11 0/1] PCC: Platform Communication Channel

Changes since V10:
- Replace array with dynamic allocation.
- Rename index to subspace_id to avoid confusion.
- Use latency instead of min turnaround time.

Changes since V9:
- Default to PCC subspace headers as defined in ACPI v5.1

Changes since V8:
- Removed unncessary header files.
- Added kerneldoc comments.
- Added intro about PCC in pcc.c

Changes since V7:
- Added timeout to tx method in case the remote dies.
- Restructured usage of acpi_status. Had inverted logic previously.

Changes since V6:
- Cosmetic changes based on Lv's suggestions

Changes since V5:
- Optimize loop that matches channel request.
- Use platform_create_bundle.
- Replace ioread/writes.
- Remove redundant code and headers.
- Restructure common mailbox macros.
- Reformat PCC cmd parsing.

Changes since V4:
- Folded PCC Mailbox helpers into pcc.c
(Continue reading)

Travis James | 10 Nov 22:28 2014
Picon

Asus wmi backlight key troubleshooting


Hello,
I was told to forward this information on to this list, I feel like I have come up with some useful
characterization of the Asus backlight keys not working on many of the newer laptops. Since making these
posts, I found an old freedesktop bug report ( https://bugs.freedesktop.org/show_bug.cgi?id=45452 )
that seems to have the same characteristics that I have seen when calling the
\_SB_.PCI0.LPCB.EC0.{_Q0E,_Q0F} methods: while other methods generate notify events, _Q0E and _Q0F
seem to only return 1 when executed using acpiexec.

( This is largely a copy of my posts to the following bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1111977 ,
https://bugzilla.redhat.com/show_bug.cgi?id=1144866 ,
https://bugs.freedesktop.org/show_bug.cgi?id=81762 )

First Post:
--------------------------------------------------------------------------------
Hello, 
I currently own an Asus Q302la, which seems to have an identical setup to the other Asus laptops that I have
seen reported on various redhat,kernel,and freedesktop bugzilla bugs. its Fn+F5 and Fn+F6 keys are not
registering events when viewed through input-tools or evemu-record despite various other asus-wmi
key-keycombos showing up and do not seem to be affected by any permutation of the boot options:
video.use_native_backlight=1, acpi_backlight=vendor, acpi_osi="!Windows 2012", and
acpi_osi="!Windows 2009". no scan codes come up with "echo 1> /sys/modules/i8042/parameters/debug" either.

other bugs on this laptop that make me feel as though this is the same hardware configuration are that it has
the Focaltech touchpad (FLT0102) that is still being worked on for multitouch support and is stubbornly
registering in PS/2 emulation mode, its intel 7270 wireless ac card was on an unkown pci id (recently
patched in linux-stable), its "G-sensor" isn't registering, and the ambient light sensor isn't being
detected (though its showing up as an ASL device with an HID of ACPI0008, which doesn't seem to be
recognized by the kernel yet), which seems to match up with most of the other recent asus laptop bugs.
(Continue reading)

Dave Jones | 10 Nov 22:21 2014
Picon

systemd, fpdt and /dev/mem

I just noticed systemd has started doing this:

[ 3228.978745] Program systemd tried to access /dev/mem between 30a48000->30a48008.

After some investigation, it seems that it's reading
/sys/firmware/acpi/tables/FPDT to get a pointer, and then trying to read
that address using /dev/mem.  Asides from the grossness of grovelling around in
memory, given it's too late to stop exporting pointers in sysfs objects,
should there perhaps be a better way to export the data the FPDT is
pointing at ?

Or should some part of acpi be reserving the memory range it points to,
so that the /dev/mem driver doesn't freak out ?

Curiously, the address it points to is in this range..
  302b5000-3129dfff : Kernel bss

Which makes me wonder what exactly it's reading.

	Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jiang Liu | 9 Nov 16:10 2014
Picon

[RFC Part4 v1 00/17] Refine support of non-PCI-compliant Message

Some interrupt controllers, such as DMAR/HPET/HT_IRQ, work almost in
the same as PCI MSI interrupt controller. And there some devices make
use of PCI MSI mechanism for non-PCI devices on ARm/ARM64 platforms.

So this patches tries to split PCI MSI code into PCI dependent part
and PCI independent part. The PCI independent part will be used to
support other PCI MSI like interrupt controllers.

Patch 1-9 are clean ups for previous hierarchy irqdomain patchset
and preparation for coming PCI MSI code reorganization.
Patch 10-15 split PCI MSI code and implement common mechanism to support
other MSI alike interrupt contollers.
Patch 16-17 converts HT_IRQ to use the common MSI support mechanism.

This patch set only solves the issue to manage interrupt controller,
but we still need another patch set to provide pci_enable_msix_range()
alike interfaces to support non-PCI devices. To achieve that, we will:
1) Move msi_list from struct pci_dev into struct device
2) Abstract common code from drivers/pci/msi.c into kernel/irq/msi.c
3) Implement msi_enable_range()/msi_disable() alike interfaces.

Apparently, we need much more time to discuss the proposal for next
patch set.

Hi Thomas and Bjorn,
	Could you please to review patch 10,13 and give your thoughts?
Those are the main changes. This patch set only passes compilation and
boot tests.

Regards!
(Continue reading)

Jassi Brar | 9 Nov 14:18 2014

[PATCH] mailbox: enable non-DT/ACPI clients to use the api

The Mailbox API so far discounted controllers and clients that
may not have a DT based channel mapping capability, as in ACPI.

Allow such mailbox clients to ask for a mailbox channel by simply
specifying a token. The token would be globally unique
among channels provided by such controllers... which shouldn't
be a problem because practically non-DT means ACPI and ACPI
specifies just one controller instance called the Platform
Communications Channel (PCC) that could have max 256 subspaces
(channels or mailboxes). So this is simply going to be the value
from 'Signature' field (first 4bytes) of the SharedMemory Region
corresponding to the subspace/channel the client is interested in.

Signed-off-by: Jassi Brar <jaswinder.singh <at> linaro.org>
---
 drivers/mailbox/mailbox.c          | 50 +++++++++++++++++++++-----------------
 include/linux/mailbox_controller.h |  7 ++++++
 2 files changed, 35 insertions(+), 22 deletions(-)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index afcb430..8260451 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
 <at>  <at>  -296,36 +296,42  <at>  <at>  struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index)
 {
 	struct device *dev = cl->dev;
 	struct mbox_controller *mbox;
-	struct of_phandle_args spec;
-	struct mbox_chan *chan;
+	struct mbox_chan *chan = NULL;
(Continue reading)

Jiang Liu | 8 Nov 19:13 2014
Picon

[Patch Part3 v3 00/38] Enable hierarchy irqdomian on x86 platforms

This is the last part to enable support of hierarchy domain on x86
platforms.

It first converts IOAPIC to support hierarchy irqdomain, then cleans
up all unused code and interfaces. It also introduces a kernel boot
parameter to configure CPU vector allocation policies.

It's based on my previous patch set at:
https://www.mail-archive.com/linux-kernel <at> vger.kernel.org/msg760868.html
And you may access it at:
https://github.com/jiangliu/linux.git irqdomain/p3v3

It has been tested on Intel 64-bit server and 32-bit laptop. It also
passes Fengguang's 0day tests. Helps are welcomed for testing:
1) Intel MID platform
2) Intel CE or OLPC platforms

Patch 1-3 kills pre_init_apic_IRQ0().
Patch 4-9 convert IOAPIC to use hierarch irqdomain
Patch 10-36 clean up code, unused interfaces etc.
Patch 37-38 introduces a mechanism to configure CPU vector allocation
	policies.

Jiang Liu (37):
  x86, intel-mid, trivial: Refine code syntax for sfi_parse_mtmr()
  x86, irq: Kill unused pre_init_apic_IRQ0()
  x86, irq: Prepare IOAPIC interfaces to support hierarchy irqdomain
  x86, irq: Implement callbacks to enable hierarchy irqdomain on
    IOAPICs
  x86, irq: Refine the way to allocate irq_cfg for legacy IRQs
(Continue reading)


Gmane