diff options
| author | Daniel Drake <dsd@laptop.org> | 2012-03-27 17:07:40 +0200 |
|---|---|---|
| committer | Ingo Molnar <mingo@kernel.org> | 2012-03-27 20:54:52 +0200 |
| commit | a3c8121b8724c3d496dc00201ab40e8313edcf0d (patch) | |
| tree | 4e6974368cd9f09a7a881c0f3ece3ccf7b8f5451 /Documentation | |
| parent | x86: Merge the x86_32 and x86_64 cpu_idle() functions (diff) | |
| download | linux-a3c8121b8724c3d496dc00201ab40e8313edcf0d.tar.xz linux-a3c8121b8724c3d496dc00201ab40e8313edcf0d.zip | |
x86/olpc: Add debugfs interface for EC commands
Add a debugfs interface for sending commands to the OLPC
Embedded Controller (EC) and reading the responses. The EC
provides functionality for machine identification, battery and
AC control, wakeup control, etc.
Having a debugfs interface available is useful for EC
development and debugging.
Based on code by Paul Fox (who also approves of the end result).
Signed-off-by: Daniel Drake <dsd@laptop.org>
Acked-by: Paul Fox <pgf@laptop.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andres Salomon <dilinger@queued.net>
Link: http://lkml.kernel.org/r/20120327150740.667D09D401E@zog.reactivated.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/ABI/testing/debugfs-olpc | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/Documentation/ABI/testing/debugfs-olpc b/Documentation/ABI/testing/debugfs-olpc new file mode 100644 index 000000000000..bd76cc6d55f9 --- /dev/null +++ b/Documentation/ABI/testing/debugfs-olpc @@ -0,0 +1,16 @@ +What: /sys/kernel/debug/olpc-ec/cmd +Date: Dec 2011 +KernelVersion: 3.4 +Contact: devel@lists.laptop.org +Description: + +A generic interface for executing OLPC Embedded Controller commands and +reading their responses. + +To execute a command, write data with the format: CC:N A A A A +CC is the (hex) command, N is the count of expected reply bytes, and A A A A +are optional (hex) arguments. + +To read the response (if any), read from the generic node after executing +a command. Hex reply bytes will be returned, *whether or not* they came from +the immediately previous command. |