Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 08 3月, 2010 17 次提交
  3. 07 3月, 2010 1 次提交
    • R
      PM: Provide generic subsystem-level callbacks · d690b2cd
      由 Rafael J. Wysocki 提交于 
      There are subsystems whose power management callbacks only need to
invoke the callbacks provided by device drivers.  Still, their system
sleep PM callbacks should play well with the runtime PM callbacks,
so that devices suspended at run time can be left in that state for
a system sleep transition.

Provide a set of generic PM callbacks for such subsystems and
define convenience macros for populating dev_pm_ops structures.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      d690b2cd
  5. 27 2月, 2010 7 次提交
    • R
      PM: Allow device drivers to use dpm_wait() · f8824cee
      由 Rafael J. Wysocki 提交于 
      There are some dependencies between devices (in particular, between
EHCI USB controllers and their OHCI/UHCI siblings) which are not
reflected by the structure of the device tree.  With synchronous
suspend and resume these dependencies are taken into accout
automatically, because the devices in question are always registered
in the right order, but to meet these constraints with asynchronous
suspend and resume the drivers of these devices will need to use
dpm_wait() in their suspend/resume routines, so introduce a helper
function allowing them to do that.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      f8824cee
    • R
      PM: Start asynchronous resume threads upfront · 97df8c12
      由 Rafael J. Wysocki 提交于 
      It has been shown by testing that total device resume time can be
reduced significantly (by as much as 50% or more) if the async
threads executing some devices' resume routines are all started
before the main resume thread starts to handle the "synchronous"
devices.

This is a consequence of the fact that the slowest devices tend to be
located at the end of dpm_list, so their resume routines are started
very late.  Consequently, they have to wait for all the preceding
"synchronous" devices before their resume routines can be started
by the main resume thread, even if they are "asynchronous".  By
starting their async threads upfront we effectively move those
devices towards the beginning of dpm_list, without breaking their
ordering with respect to their parents and children.  As a result,
their resume routines are started much earlier and we are able to
save much more device resume time this way.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      97df8c12
    • R
      PM: Add facility for advanced testing of async suspend/resume · 5a2eb858
      由 Rafael J. Wysocki 提交于 
      Add configuration switch CONFIG_PM_ADVANCED_DEBUG for compiling in
extra PM debugging/testing code allowing one to access some
PM-related attributes of devices from the user space via sysfs.

If CONFIG_PM_ADVANCED_DEBUG is set, add sysfs attribute power/async
for every device allowing the user space to access the device's
power.async_suspend flag and modify it, if desired.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      5a2eb858
    • R
      PM: Add a switch for disabling/enabling asynchronous suspend/resume · 0e06b4a8
      由 Rafael J. Wysocki 提交于 
      Add sysfs attribute /sys/power/pm_async allowing the user space to
disable/enable asynchronous suspend/resume of devices.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      0e06b4a8
    • R
      PM: Asynchronous suspend and resume of devices · 5af84b82
      由 Rafael J. Wysocki 提交于 
      Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other.  However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself.  Analogously, we're not allowed to resume a device before
resuming its parent.

The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.

For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices).  For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.

The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
    for the device or, in the case of devices with the
    power.async_suspend flags unset, before executing the device's
    suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
    and device class suspend callbacks for the device, the PM core
    waits for the completions of all the device's children to be
    completed.
(4) During resume, right before running the bus type, device type and
    device class resume callbacks for the device, the PM core waits
    for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
    after the bus type, device type and device class suspend (or
    resume) callbacks executed for the device have returned.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      5af84b82
    • R
      PM: Add parent information to timing messages · 8cc6b39f
      由 Rafael J. Wysocki 提交于 
      Add parent information to the messages printed by the suspend/resume
core when initcall_debug is set.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      8cc6b39f
    • R
      PM / Runtime: Add sysfs switch for disabling device run-time PM · 53823639
      由 Rafael J. Wysocki 提交于 
      Add new device sysfs attribute, power/control, allowing the user
space to block the run-time power management of the devices.  If this
attribute is set to "on", the driver of the device won't be able to power
manage it at run time (without breaking the rules) and the device will
always be in the full power state (except when the entire system goes
into a sleep state).
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      53823639
  7. 17 2月, 2010 1 次提交
  9. 21 1月, 2010 2 次提交
    • G
      Revert "sysdev: fix prototype for memory_sysdev_class show/store functions" · bd796671
      由 Greg Kroah-Hartman 提交于 
      This reverts commit 8ff410da

It should not have been sent to Linus's tree yet, as it depends
on changes that are queued up in my driver-core for the .34 kernel
merge.

Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: "Zheng, Shaohui" <shaohui.zheng@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bd796671
    • H
      driver-core: fix devtmpfs crash on s390 · f776c5ec
      由 Heiko Carstens 提交于 
      On Mon, Jan 18, 2010 at 05:26:20PM +0530, Sachin Sant wrote:
> Hello Heiko,
>
> Today while trying to boot next-20100118 i came across
> the following Oops :
>
> Brought up 4 CPUs
> Unable to handle kernel pointer dereference at virtual kernel address 0000000000
> 543000
> Oops: 0004 #1 SMP
> Modules linked in:
> CPU: 0 Not tainted 2.6.33-rc4-autotest-next-20100118-5-default #1
> Process swapper (pid: 1, task: 00000000fd792038, ksp: 00000000fd797a30)
> Krnl PSW : 0704200180000000 00000000001eb0b8 (shmem_parse_options+0xc0/0x328)
>           R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:2 PM:0 EA:3
> Krnl GPRS: 000000000054388a 000000000000003d 0000000000543836 000000000000003d
>           0000000000000000 0000000000483f28 0000000000536112 00000000fd797d00
>           00000000fd4ba100 0000000000000100 0000000000483978 0000000000543832
>           0000000000000000 0000000000465958 00000000001eb0b0 00000000fd797c58
> Krnl Code: 00000000001eb0aa: c0e5000994f1       brasl   %r14,31da8c
>           00000000001eb0b0: b9020022           ltgr    %r2,%r2
>           00000000001eb0b4: a784010b           brc     8,1eb2ca
>          >00000000001eb0b8: 92002000           mvi     0(%r2),0
>           00000000001eb0bc: a7080000           lhi     %r0,0
>           00000000001eb0c0: 41902001           la      %r9,1(%r2)
>           00000000001eb0c4: b9040016           lgr     %r1,%r6
>           00000000001eb0c8: b904002b           lgr     %r2,%r11
> Call Trace:
> (<00000000fd797c50> 0xfd797c50)
> <00000000001eb5da> shmem_fill_super+0x13a/0x25c
> <0000000000228cfa> get_sb_single+0xbe/0xdc
> <000000000034ffc0> dev_get_sb+0x2c/0x38
> <000000000066c602> devtmpfs_init+0x46/0xc0
> <000000000066c53e> driver_init+0x22/0x60
> <000000000064d40a> kernel_init+0x24e/0x3d0
> <000000000010a7ea> kernel_thread_starter+0x6/0xc
> <000000000010a7e4> kernel_thread_starter+0x0/0xc
>
> I never tried to boot a kernel with DEVTMPFS enabled on a s390 box.
> So am wondering if this is supported or not ? If you think this
> is supported i will send a mail to community on this.

There is nothing arch specific to devtmpfs. This part crashes because the
kernel tries to modify the data read-only section which is write protected
on s390.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f776c5ec
  11. 17 1月, 2010 2 次提交
  13. 12 1月, 2010 1 次提交
  15. 24 12月, 2009 8 次提交
  17. 23 12月, 2009 1 次提交
    • R
      PM / Runtime: Use device type and device class callbacks · a6ab7aa9
      由 Rafael J. Wysocki 提交于 
      The power management of some devices is handled through device types
and device classes rather than through bus types.  Since these
devices may also benefit from using the run-time power management
core, extend it so that the device type and device class run-time PM
callbacks can be taken into consideration by it if the bus type
callback is not defined.

Update the run-time PM core documentation to reflect this change.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      a6ab7aa9