Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 29 8月, 2013 1 次提交
  3. 04 8月, 2013 3 次提交
  5. 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
  7. 09 7月, 2013 1 次提交
  9. 08 7月, 2013 1 次提交
  11. 02 7月, 2013 2 次提交
  13. 28 6月, 2013 1 次提交
  15. 25 6月, 2013 1 次提交
  17. 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
  19. 18 6月, 2013 1 次提交
  21. 12 6月, 2013 1 次提交
  23. 10 6月, 2013 4 次提交
  25. 06 6月, 2013 1 次提交
  27. 05 6月, 2013 2 次提交
  29. 04 6月, 2013 1 次提交
  31. 03 6月, 2013 3 次提交
  33. 29 5月, 2013 2 次提交
  35. 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
  37. 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
  39. 18 4月, 2013 2 次提交
    • R
      xen-blkback: implement LRU mechanism for persistent grants · 3f3aad5e
      由 Roger Pau Monne 提交于 
      This mechanism allows blkback to change the number of grants
persistently mapped at run time.

The algorithm uses a simple LRU mechanism that removes (if needed) the
persistent grants that have not been used since the last LRU run, or
if all grants have been used it removes the first grants in the list
(that are not in use).

The algorithm allows the user to change the maximum number of
persistent grants, by changing max_persistent_grants in sysfs.

Since we are storing the persistent grants used inside the request
struct (to be able to mark them as "unused" when unmapping), we no
longer need the bitmap (unmap_seg).
Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xen.org
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      3f3aad5e
    • R
      xen-blkback: use balloon pages for all mappings · c6cc142d
      由 Roger Pau Monne 提交于 
      Using balloon pages for all granted pages allows us to simplify the
logic in blkback, especially in the xen_blkbk_map function, since now
we can decide if we want to map a grant persistently or not after we
have actually mapped it. This could not be done before because
persistent grants used ballooned pages, whereas non-persistent grants
used pages from the kernel.

This patch also introduces several changes, the first one is that the
list of free pages is no longer global, now each blkback instance has
it's own list of free pages that can be used to map grants. Also, a
run time parameter (max_buffer_pages) has been added in order to tune
the maximum number of free pages each blkback instance will keep in
it's buffer.
Signed-off-by: NRoger Pau Monné <roger.pau@citrix.com>
Cc: xen-devel@lists.xen.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      c6cc142d
  41. 12 4月, 2013 1 次提交
  43. 05 4月, 2013 1 次提交
  45. 30 3月, 2013 1 次提交
  47. 29 3月, 2013 2 次提交
  49. 24 3月, 2013 1 次提交
  51. 22 3月, 2013 1 次提交
    • R
      ACPI / LPSS: Add support for exposing LTR registers to user space · 2e0f8822
      由 Rafael J. Wysocki 提交于 
      Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have
registers providing access to LTR (Latency Tolerance Reporting)
functionality that allows software to monitor and possibly influence
the aggressiveness of the platform's active-state power management.

For each LPSS device, there are two modes of operation related to LTR,
the auto mode and the software mode.  In the auto mode the LTR is
set up by the platform firmware and managed by hardware.  Software
can only read the LTR register values to monitor the platform's
behavior.  In the software mode it is possible to use LTR to control
the extent to which the platform will use its built-in power
management features.

This changeset adds support for reading the LPSS devices' LTR
registers and exposing their values to user space for monitoring and
diagnostics purposes.  It re-uses the MMIO mappings created to access
the LPSS devices' clock registers for reading the values of the LTR
registers and exposes them to user space through sysfs device
attributes.  Namely, a new atrribute group, lpss_ltr, is created for
each LPSS device.  It contains three new attributes: ltr_mode,
auto_ltr, sw_ltr.  The value of the ltr_mode attribute reflects the
LTR mode being used at the moment (software vs auto) and the other
two contain the actual register values (raw) whose meaning depends
on the LTR mode.  All of these attributes are read-only.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2e0f8822