Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 30 5月, 2014 2 次提交
  3. 27 5月, 2014 2 次提交
  5. 26 5月, 2014 2 次提交
  7. 25 5月, 2014 3 次提交
  9. 20 5月, 2014 2 次提交
  11. 17 5月, 2014 2 次提交
  13. 16 5月, 2014 5 次提交
    • T
      ACPI / processor: Fix STARTING/DYING action in acpi_cpu_soft_notify() · 8da83734
      由 Toshi Kani 提交于 
      During CPU online/offline testing on a large system, one of the
processors got stuck after the message "bad: scheduling from the
idle thread!".  The problem is that acpi_cpu_soft_notify() calls
acpi_bus_get_device() for all action types.  CPU_STARTING and
CPU_DYING do not allow the notify handlers to sleep.  However,
acpi_bus_get_device() can sleep in acpi_ut_acquire_mutex().

Change acpi_cpu_soft_notify() to return immediately for CPU_STARTING
and CPU_DYING as they have no action in this handler.
Signed-off-by: NToshi Kani <toshi.kani@hp.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8da83734
    • L
      ACPI / battery: Accelerate battery resume callback · 9e50bc14
      由 Lan Tianyu 提交于 
      Most time of battery resume callback is spent on executing AML code
_BTP, _BIF and _BIF to get battery info, status and set alarm. These
AML methods may access EC operation regions several times and consumes
time.

These operations are not necessary during devices resume and can run
during POST_SUSPEND/HIBERNATION event when all processes are thawed.

This also can avoid removing and adding battery sysfs nodes every system
resume even if the battery unit is not actually changed. The original code
updates sysfs nodes without check and this seems not reasonable.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9e50bc14
    • H
      ACPI / platform: add IDs for Broadcom Bluetooth and GPS chips · a3cffce4
      由 Heikki Krogerus 提交于 
      These IDs are used on Baytrail boards such as Lenovo Miix 2
and Asus Transformer Book T100TA. On lenovo Miix 2 8",
BCM4752 is called LNV4752. All the rest of the IDs are for
Broadcom BCM43241 module with the ID referring to different
revision number.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a3cffce4
    • B
      ACPI / processor: Check if LAPIC is present during initialization · c401eb8e
      由 Baoquan He 提交于 
      In acpi_processor_get_info(), ACPI processor info is initialized including
ID, namely CPU index. Currently, on a UP system running an SMP kerenl with
no LAPIC in the MADT, cpu0_initialized is checked to decide whether or not
the CPU has been initialized.

However, this check may not be sufficient for kdump kernels. Most of time
only 1 CPU is supported because of known problems in kdump kernels. So say
the multiple CPUs are present in the boot kernel and a crash happens on
one specific CPU, say CPU2. Then it jumps into the kdump kernel with
"nr_cpus=1" in the command line. In this situation, the kdump kernel
will reuse the ACPI resources from the crashed kernel directly. That
means all LAPIC instances are enabled in the MADT while only one CPU is
in use.  In the kdump kernel, x86_cpu_to_apicid contains the correct APIC
ID and it's related to the CPU ID. If cpu0_initialized is checked only, 0
will be used as the CPU index instead of that APIC ID, which is not
correct.

In addition to checking cpu0_initialized, check acpi_lapic. If acpi_lapic
is 0, then no LAPIC is available from the MADT and the system should be
treated as a UP one without a LAPIC (that is, assign 0 to the CPU index).
Otherwise, use the original (valid) CPU index.
Signed-off-by: NBaoquan He <bhe@redhat.com>
[rjw: Subject and changelog]
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c401eb8e
    • R
      ACPI / PM: Hold ACPI scan lock over the "freeze" sleep state · 1f0b6386
      由 Rafael J. Wysocki 提交于 
      The "freeze" sleep state suffers from the same issue that was
addressed by commit ad07277e (ACPI / PM: Hold acpi_scan_lock over
system PM transitions) for ACPI sleep states, that is, things break
if ->remove() is called for devices whose system resume callbacks
haven't been executed yet.

It also can be addressed in the same way, by holding the ACPI scan
lock over the "freeze" sleep state and PM transitions to and from
that state, but ->begin() and ->end() platform operations for the
"freeze" sleep state are needed for this purpose.

This change has been tested on Acer Aspire S5 with Thunderbolt.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1f0b6386
  15. 13 5月, 2014 2 次提交
  17. 10 5月, 2014 2 次提交
  19. 08 5月, 2014 4 次提交
  21. 07 5月, 2014 1 次提交
  23. 06 5月, 2014 4 次提交
  25. 01 5月, 2014 1 次提交
  27. 30 4月, 2014 1 次提交
  29. 28 4月, 2014 2 次提交
    • T
      ACPI / PAD: call schedule() when need_resched() is true · 5b59c69e
      由 Tony Camuso 提交于 
      The purpose of the acpi_pad driver is to implement the "processor power
aggregator" device as described in the ACPI 4.0 spec section 8.5. It
takes requests from the BIOS (via ACPI) to put a specified number of
CPUs into idle, in order to save power, until further notice.

It does this by creating high-priority threads that try to keep the CPUs
in a high C-state (using the monitor/mwait CPU instructions). The
mwait() call is in a loop that checks periodically if the thread should
end and a few other things.

It was discovered through testing that the power_saving threads were
causing the system to consume more power than the system was consuming
before the threads were created. A counter in the main loop of
power_saving_thread() revealed that it was spinning. The mwait()
instruction was not keeping the CPU in a high C state very much if at
all.

Here is a simplification of the loop in function power_saving_thread() in
drivers/acpi/acpi_pad.c

    while (!kthread_should_stop()) {
         :
        try_to_freeze()
         :
        while (!need_resched()) {
             :
            if (!need_resched())
                __mwait(power_saving_mwait_eax, 1);
             :
            if (jiffies > expire_time) {
                do_sleep = 1;
                break;
            }
        }
    }

If need_resched() returns true, then mwait() is not called. It was
returning true because of things like timer interrupts, as in the
following sequence.

hrtimer_interrupt->__run_hrtimer->tick_sched_timer-> update_process_times->
rcu_check_callbacks->rcu_pending->__rcu_pending->set_need_resched

Kernels 3.5.0-rc2+ do not exhibit this problem, because a patch to
try_to_freeze() in include/linux/freezer.h introduces a call to
might_sleep(), which ultimately calls schedule() to clear the reschedule
flag and allows the the loop to execute the call to mwait().

However, the changes to try_to_freeze are unrelated to acpi_pad, and it
does not seem like a good idea to rely on an unrelated patch in a
function that could later be changed and reintroduce this bug.

Therefore, it seems better to make an explicit call to schedule() in the
outer loop when the need_resched flag is set.
Reported-and-tested-by: NStuart Hayes <stuart_hayes@dell.com>
Signed-off-by: NTony Camuso <tcamuso@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5b59c69e
    • A
      ACPI / scan: do not scan fixed hardware on HW-reduced platform · 2650ef42
      由 Aaron Lu 提交于 
      Fixed hardware does not exist on HW-reduced ACPI platforms since the
programming interface for them is not implemented on them, so no need
to scan that hardware on them.

This patch avoids creating the fixed power button ACPI device and
eliminates a probe error message from ACPI button driver on ASUS T100.
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2650ef42
  31. 25 4月, 2014 1 次提交
  33. 22 4月, 2014 1 次提交
  35. 09 4月, 2014 1 次提交
    • H
      ACPI: Update the ACPI spec information in Kconfig · c7f5220d
      由 Hanjun Guo 提交于 
      The UEFI Forum included the ACPI spec in its portfolio in October 2013
and will host future spec iterations, following the ACPI v5.0a release.

A UEFI Forum working group named ACPI Specification Working Group (ASWG)
has been established to handle future ACPI developments, any UEFI member
can join the group and contribute to ACPI specification.

So update the ownership and developers for ACPI in Kconfig accordingly,
and add another website link to ACPI specification too.
Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c7f5220d
  37. 07 4月, 2014 2 次提交