Gillian Bayford | 25 Oct 22:06 2014
Picon

ATTN

You have been sanction a donation. Reply for info.
--
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

Rafael J. Wysocki | 24 Oct 14:38 2014

[GIT PULL] ACPI and power management updates for 3.18-rc1

Hi Linus,

Please pull from

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm+acpi-3.18-rc2

to receive ACPI and power management updates for v3.18-rc2 with
top-most commit a91e99e27a683608d221fb18b70d7de9d801de4a

 Merge branches 'pm-cpuidle' and 'pm-cpufreq'

on top of commit f114040e3ea6e07372334ade75d1ee0775c355e1

 Linux 3.18-rc1

This is material that didn't make it to my 3.18-rc1 pull request
for various reasons, mostly related to timing and travel
(LinuxCon EU / LPC) plus a couple of fixes for recent bugs.
The only really new thing here is the PM QoS class for memory
bandwidth, but it is simple enough and users of it will be added
in the next cycle.  One major change in behavior is that platform
devices enumerated by ACPI will use 32-bit DMA mask by default.
Also included is an ACPICA update to a new upstream release,
but that's mostly cleanups, changes in tools and similar.  The
rest is fixes and cleanups mostly.

Specifics:

 - Fix for a recent PCI power management change that overlooked
(Continue reading)

Jarkko Nikula | 24 Oct 12:08 2014
Picon

Re: [PATCH] ACPI: Use ACPI companion to match only the first physical device

On 10/24/2014 12:12 PM, Mika Westerberg wrote:
> Commit 6ab3430129e2 ("mfd: Add ACPI support") made the MFD subdevices to
> share the parent MFD ACPI companion device if no _HID/_CID is specified for
> the subdevice in mfd_cell description. However, since all the subdevices
> share the ACPI companion, the match and modalias generation logic started
> to use the ACPI companion as well resulting this:
>
>    # cat /sys/bus/platform/devices/HID-SENSOR-200041.6.auto/modalias
>    acpi:INT33D1:PNP0C50:
>
> instead of the expected one
>
>    # cat /sys/bus/platform/devices/HID-SENSOR-200041.6.auto/modalias
>    platform:HID-SENSOR-200041
>
> In other words the subdevice modalias is overwritten by the one taken from
> ACPI companion. This causes udev not to load the driver anymore.
>
> It is useful to be able to share the ACPI companion so that MFD subdevices
> (and possibly other devices as well) can access the ACPI resources even if
> they do not have ACPI representation in the namespace themselves.
>
> An example where this is used is Minnowboard LPC driver that creates GPIO
> as a subdevice among other things. Without the ACPI companion gpiolib is
> not is not able to lookup the corresponding GPIO controller from ACPI
> GpioIo resource.
>
> To fix this we restrict the match and modalias logic to be limited to the
> first physical device. The secondary devices will still be able to access
> the ACPI companion but they will be matched using traditional way.
(Continue reading)

Zhang Rui | 23 Oct 14:25 2014
Picon

[PATCH] ACPI: invoke acpi_device_wakeup() with correct parameters

From f0d75284074478790a50655bf3cc1096f5f943fa Mon Sep 17 00:00:00 2001
From: Zhang Rui <rui.zhang <at> intel.com>
Date: Thu, 23 Oct 2014 20:20:00 +0800
Subject: [PATCH] ACPI: invoke acpi_device_wakeup() with correct parameters

Fix a bug that invokes acpi_device_wakeup() with wrong parameters.

Signed-off-by: Zhang Rui <rui.zhang <at> intel.com>
---
 drivers/acpi/device_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index 9177547..b4743d4 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
 <at>  <at>  -711,7 +711,7  <at>  <at>  int acpi_pm_device_run_wake(struct device *phys_dev, bool enable)
 		return -ENODEV;
 	}

-	return acpi_device_wakeup(adev, enable, ACPI_STATE_S0);
+	return acpi_device_wakeup(adev, ACPI_STATE_S0, enable);
 }
 EXPORT_SYMBOL(acpi_pm_device_run_wake);
 #endif /* CONFIG_PM_RUNTIME */
--

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
(Continue reading)

Lv Zheng | 23 Oct 04:11 2014
Picon

[PATCH 0/6] ACPI/OSL: Rework of ACPICA memory OSLs to improve performance.

It is reported that there is a performance issue in the ACPICA OSL
implementation around memory mappings.

On the reported platforms, there is a debugging facility implemented in the
ACPI namespace using circular logging buffer:
        Name (DPTR, 0x3AFEB000)
        Name (EPTR, 0x3AFFB000)
        Name (CPTR, 0x3AFEB010)
        Mutex (MMUT, 0x00)
        Method (MDBG, 1, Serialized)
        {
            Store (Acquire (MMUT, 0x03E8), Local0)
            If (Local0 == Zero)
            {
                OperationRegion (ABLK, SystemMemory, CPTR, 0x10)
                Field (ABLK, ByteAcc, NoLock, Preserve)
                {
                    AAAA,   128
                }
                Store (Arg0, AAAA) /* \MDBG.AAAA */
                CPTR = (CPTR + 0x10) /* \CPTR */
                If (CPTR >= EPTR)
                {
                    CPTR = (DPTR + 0x10) /* \CPTR */
                }
                Release (MMUT)
            }
            Return (Local0)
        }
This function is heavily invoked by other ACPI control methods.
(Continue reading)

Darren Hart | 21 Oct 23:50 2014

Re: [PATCH v4 00/13] Add ACPI _DSD and unified device properties? support

On Sat, Oct 18, 2014 at 10:35:49AM +0200, Grant Likely wrote:
> On Wed, 15 Oct 2014 17:43:01 +0200
> , Darren Hart <dvhart <at> linux.intel.com>
>  wrote:
> > 
> > 
> > On 10/15/14 17:17, Mark Rutland wrote:
> > > On Wed, Oct 15, 2014 at 03:46:39PM +0100, Darren Hart wrote:
> > 
> > >> Mark, what would you propose we do differently to enable this driver to
> > >> be firmware-type agnostic?
> > > 
> > > For this particular driver, all I'm asking for is that the
> > > "used-by-rtas" property is not moved over from of_find_property to
> > > device_get_property. It is irrelevant for all ACPI systems. Evidently my
> > > comment was unclear; I apologise for that.
> > 
> > So my objection here is that by keeping the of_* terms in the driver we
> > are required to include of, although it does safely convert to returning
> > NULL if !CONFIG_OF I suppose.
> 
> This shouldn't be that controversial. There will be things that only make
> sense for DT or only ACPI. Allowing the property to be processed when
> the other interface is being used may tempt firmware authors to use the
> property because it just happens to have a side effect that looks right
> to them.
> 
> I don't see any problem with factoring out those bits into a function
> that is only called (or built) when the associated firmware interface is
> used. In these situations, the driver isn't 100% generic, so having
(Continue reading)

Alexandre Courbot | 21 Oct 07:14 2014
Picon

GPIO bindings guidelines (Was: Re: [PATCH v5 10/12] gpio: Support for unified device properties interface)

On Mon, Oct 20, 2014 at 11:26 PM, Arnd Bergmann <arnd <at> arndb.de> wrote:
> On Monday 20 October 2014 15:12:50 Alexandre Courbot wrote:
>> On Sat, Oct 18, 2014 at 6:47 PM, Arnd Bergmann <arnd <at> arndb.de> wrote:
>> > On Friday 17 October 2014 20:09:51 Arnd Bergmann wrote:
>> >> On October 17, 2014 2:16:00 PM CEST, "Rafael J. Wysocki" <rjw <at> rjwysocki.net> wrote:
>> >> >From: Mika Westerberg <mika.westerberg <at> linux.intel.com>
>> >> >
>> >> >Some drivers need to deal with only firmware representation of its
>> >> >GPIOs. An example would be a GPIO button array driver where each button
>> >> >is described as a separate firmware node in device tree. Typically
>> >> >these
>> >> >child nodes do not have physical representation in the Linux device
>> >> >model.
>> >> >
>> >> >In order to help device drivers to handle such firmware child nodes we
>> >> >add dev[m]_get_named_gpiod_from_child() that takes a child firmware
>> >> >node pointer as its second argument (the first one is the parent device
>> >> >itself), finds the GPIO using whatever is the underlying firmware
>> >> >method, and requests the GPIO properly.
>> >>
>> >> Could we also have a wrapper around this function without a "name" argument,
>> >> using just the index?
>> >
>> > Expanding on this thought: I think we should mandate for new bindings
>> > that they use either a name and no index, or an index but not name,
>>
>> I'm afraid this could forbid some useful use-cases, namely the ones
>> where several GPIOs serve the same function (and are typically set
>> together). We had a few patch proposals to handle such GPIO groups,
>> and even though one was in pretty good shape the submitter did not
(Continue reading)

Williams Scott | 21 Oct 04:22 2014
Picon

Financial Aid at 2% Interest Rate


Business and personal finance assistance (loan) Available at Two percent(2%) Interest Rate, *No Credit
Check * Presentation of Collateral are not important, if interested, Kindly contacts us for detail as you
click reply. You can also call us via: +1 623 239 1600. Thank You
--
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 | 20 Oct 16:45 2014
Picon

[Patch] ACPI, irq: fix regression casued by 6b9fb7082409

When IOAPIC is disabled, acpi_gsi_to_irq() should return gsi directly
instead of calling mp_map_gsi_to_irq() to translate gsi to IRQ by IOAPIC.
It fixes https://bugzilla.kernel.org/show_bug.cgi?id=84381.

Reported-and-Tested-by: Thomas Richter <thor <at> math.tu-berlin.de>
Signed-off-by: Jiang Liu <jiang.liu <at> linux.intel.com>
Cc: Thomas Richter <thor <at> math.tu-berlin.de>
Cc: rui.zhang <at> intel.com
Cc: <stable <at> vger.kernel.org> # 3.17
---
 arch/x86/kernel/acpi/boot.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index b436fc735aa4..eceba9d9e116 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
 <at>  <at>  -604,14 +604,19  <at>  <at>  void __init acpi_pic_sci_set_trigger(unsigned int irq, u16 trigger)

 int acpi_gsi_to_irq(u32 gsi, unsigned int *irqp)
 {
-	int irq = mp_map_gsi_to_irq(gsi, IOAPIC_MAP_ALLOC | IOAPIC_MAP_CHECK);
+	int irq;

-	if (irq >= 0) {
+	if (acpi_irq_model == ACPI_IRQ_MODEL_PIC) {
+		*irqp = gsi;
+	} else {
+		irq = mp_map_gsi_to_irq(gsi,
+					IOAPIC_MAP_ALLOC | IOAPIC_MAP_CHECK);
(Continue reading)

Rafael J. Wysocki | 20 Oct 01:32 2014
Picon

Re: [PATCH v5 00/12] Add ACPI _DSD and unified device properties support

On Saturday, October 18, 2014 10:49:59 AM Grant Likely wrote:
> On Sat, 18 Oct 2014 00:50 +0200
> , "Rafael J. Wysocki" <rjw <at> rjwysocki.net>
>  wrote:
> > On Friday, October 17, 2014 08:04:52 PM Arnd Bergmann wrote:
> > > 
> > > On October 17, 2014 2:01:33 PM CEST, "Rafael J. Wysocki" <rjw <at> rjwysocki.net> wrote:
> > > >Hi Everyone,
> > > >
> > > >Hving had a couple of chats with Grant and Arnd during LinuxCon EU/LPC,
> > > >we
> > > >now have version 5 taking all feedback into account (hopefully).
> > > 
> > > Awesome, that was really fast. I'm currently on my way his me in
> > > the train, replying from my phone, but it looks good now. I'll have a more
> > > detailed look next week but I'm definitely happy to see this go in (to next
> > > and 3.19) now, any details we still find can be fixed on top.
> > > 
> > > > In
> > > >short, if
> > > >we are passed a struct fwnode_handle pointer, we can get from it to the
> > > >appropriate device node pointer (either struct acpi_device or struct
> > > >device_node)
> > > >using container_of() after we've checked the type.  This is needed for
> > > >the code
> > > >that needs to access child nodes of a device in case when they don't
> > > >have
> > > >struct device representations (whatever the reason).  This has been
> > > >suggested
> > > >by Grant and pretty much everyone involved agrees that it's better that
(Continue reading)

Hanjun Guo | 17 Oct 15:36 2014

[PATCH v5 00/18] Introduce ACPI for ARM64 based on ACPI 5.1

ACPI 5.1 has some major changes for ARM platform and the following
tables which are essential for ARM platforms:
1) MADT table updates for GIC v2/v3.
2) FADT updates for PSCI
3) GTDT for arch timer

This patch set is the ARM64 ACPI core patches covered MADT, FADT
and GTDT, platform board specific drivers are not covered by this
patch set.

We first introduce acpi.c and its related head file which are needed
by ACPI core, and then get RSDP to extract all the ACPI boot-time tables.
When all the boot-time tables (FADT, MADT, GTDT) are ready, then
parse them to init the sytem when booted. Specifically,
a) we use FADT to init PSCI and use PSCI to boot SMP;
b) Use MADT for GIC init and SMP init;
c) GTDT for arch timer init.

This patch set is based on 3.17-rc4 and was tested by Graeme on Juno
and FVP base model boot with ACPI only OK, if you want to test them,
you can pull from acpi-5.1-v5 branch in leg/acpi repo:
git://git.linaro.org/leg/acpi/acpi.git

Updates since v4:
 - ACPI uasge doc for ARM64 was updated a lot by Al
 - Collect some ACKs from Grant, Olof, Mark
 - address some comments from Olof and Catalin since last version

Updates since v3:
 - Compile out sleep.c on ARM64 when ACPI enabled
(Continue reading)


Gmane