Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 28 10月, 2013 1 次提交
  3. 09 10月, 2013 1 次提交
  5. 31 8月, 2013 2 次提交
  7. 29 8月, 2013 1 次提交
  9. 27 8月, 2013 1 次提交
  11. 15 8月, 2013 1 次提交
  13. 13 8月, 2013 1 次提交
  15. 06 8月, 2013 2 次提交
  17. 04 8月, 2013 3 次提交
  19. 11 7月, 2013 1 次提交
    • M
      Add support driver for Intel Rapid Start Technology · 34a956db
      由 Matthew Garrett 提交于 
      Intel Rapid Start Technology is a firmware-based suspend-to-disk
implementation. Once placed in S3, the device will wake once either a
timeout elapses or the battery reaches a critical level. It will then resume
to the firmware and copy the contents of RAM to a specialised partition, and
then power off the machine. If the user turns the machine back on the
firmware will copy the contents of the partition back to RAM and then resume
from S3 as normal.

This driver provides an interface for configuring the wakeup events and
timeout. It still requires firmware support and an appropriate suspend
partition.
Signed-off-by: NMatthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      34a956db
  21. 09 7月, 2013 1 次提交
  23. 08 7月, 2013 1 次提交
  25. 28 6月, 2013 1 次提交
  27. 25 6月, 2013 1 次提交
  29. 21 6月, 2013 2 次提交
    • H
      pwm: Add sysfs interface · 76abbdde
      由 H Hartley Sweeten 提交于 
      Add a simple sysfs interface to the generic PWM framework.

  /sys/class/pwm/
  `-- pwmchipN/           for each PWM chip
      |-- export          (w/o) ask the kernel to export a PWM channel
      |-- npwm            (r/o) number of PWM channels in this PWM chip
      |-- pwmX/           for each exported PWM channel
      |   |-- duty_cycle  (r/w) duty cycle (in nanoseconds)
      |   |-- enable      (r/w) enable/disable PWM
      |   |-- period      (r/w) period (in nanoseconds)
      |   `-- polarity    (r/w) polarity of PWM (normal/inversed)
      `-- unexport        (w/o) return a PWM channel to the kernel

Based on work by Lars Poeschel.
Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Lars Poeschel <poeschel@lemonage.de>
Cc: Ryan Mallon <rmallon@gmail.com>
Cc: Rob Landley <rob@landley.net>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>
      76abbdde
    • L
      ACPI: Add sysfs ABI documentation · 89ca78a0
      由 Lv Zheng 提交于 
      Add initial ABI documentation for ACPI devices' sysfs interfaces.
Contacts information fields are filled with current ACPI maintainer and the
relevant authors are carbon copied.

[rjw: Use my e-mail address that's likely to be valid longer.]
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      89ca78a0
  31. 18 6月, 2013 1 次提交
  33. 12 6月, 2013 1 次提交
  35. 10 6月, 2013 4 次提交
  37. 06 6月, 2013 1 次提交
  39. 05 6月, 2013 2 次提交
  41. 04 6月, 2013 1 次提交
  43. 03 6月, 2013 3 次提交
  45. 29 5月, 2013 2 次提交
  47. 12 5月, 2013 2 次提交
    • R
      ACPI / hotplug: Use device offline/online for graceful hot-removal · 683058e3
      由 Rafael J. Wysocki 提交于 
      Modify the generic ACPI hotplug code to be able to check if devices
scheduled for hot-removal may be gracefully removed from the system
using the device offline/online mechanism introduced previously.

Namely, make acpi_scan_hot_remove() handling device hot-removal call
device_offline() for all physical companions of the ACPI device nodes
involved in the operation and check the results.  If any of the
device_offline() calls fails, the function will not progress to the
removal phase (which cannot be aborted), unless its (new) force
argument is set (in case of a failing offline it will put the devices
offlined by it back online).

In support of 'forced' device hot-removal, add a new sysfs attribute
'force_remove' that will reside under /sys/firmware/acpi/hotplug/.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NToshi Kani <toshi.kani@hp.com>
      683058e3
    • R
      Driver core: Add offline/online device operations · 4f3549d7
      由 Rafael J. Wysocki 提交于 
      In some cases, graceful hot-removal of devices is not possible,
although in principle the devices in question support hotplug.
For example, that may happen for the last CPU in the system or
for memory modules holding kernel memory.

In those cases it is nice to be able to check if the given device
can be gracefully hot-removed before triggering a removal procedure
that cannot be aborted or reversed.  Unfortunately, however, the
kernel currently doesn't provide any support for that.

To address that deficiency, introduce support for offline and
online operations that can be performed on devices, respectively,
before a hot-removal and in case when it is necessary (or convenient)
to put a device back online after a successful offline (that has not
been followed by removal).  The idea is that the offline will fail
whenever the given device cannot be gracefully removed from the
system and it will not be allowed to use the device after a
successful offline (until a subsequent online) in analogy with the
existing CPU offline/online mechanism.

For now, the offline and online operations are introduced at the
bus type level, as that should be sufficient for the most urgent use
cases (CPUs and memory modules).  In the future, however, the
approach may be extended to cover some more complicated device
offline/online scenarios involving device drivers etc.

The lock_device_hotplug() and unlock_device_hotplug() functions are
introduced because subsequent patches need to put larger pieces of
code under device_hotplug_lock to prevent race conditions between
device offline and removal from happening.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NToshi Kani <toshi.kani@hp.com>
      4f3549d7
  49. 02 5月, 2013 1 次提交
    • A
      rbd: don't create sysfs entries for non-mapped snapshots · 3e83b65b
      由 Alex Elder 提交于 
      When an rbd image gets mapped a device entry gets created for it
under /sys/bus/rbd/devices/<id>/.  Inside that directory there are
sysfs files that contain information about the image: its size,
feature bits, major device number, and so on.

Additionally, if that image has any snapshots, a device entry gets
created for each of those as a "child" of the mapped device.  Each
of these is a subdirectory of the mapped device, and each directory
contains a few files with information about the snapshot (its
snapshot id, size, and feature mask).

There is no clear benefit to having those device entries for the
snapshots.  The information provided via sysfs of of little real
value--and all of it is available via rbd CLI commands.  If we
still wanted to see the kernel's view of this information it could
be done much more simply by including it in a single sysfs file for
the mapped image.

But there *is* a clear cost to supporting them.  Every time a snapshot
context changes, these entries need to be updated (deleted snapshots
removed, new snapshots created).  The rbd driver is notified of
changes to the snapshot context via callbacks from an osd, and care
must be taken to coordinate removal of snapshot data structures
with the possibility of one these notifications occurring.

Things would be considerably simpler if we just didn't have to
maintain device entries for the snapshots.

So get rid of them.

The ability to map a snapshot of an rbd image will remain; the only
thing lost will be the ability to query these sysfs directories for
information about snapshots of mapped images.

This resolves:
    http://tracker.ceph.com/issues/4796Signed-off-by: NAlex Elder <elder@inktank.com>
Reviewed-by: NJosh Durgin <josh.durgin@inktank.com>
      3e83b65b
  51. 12 4月, 2013 1 次提交
  53. 05 4月, 2013 1 次提交