You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'topic/workq-update' into topic/misc
This commit is contained in:
Takashi Iwai
@@ -0,0 +1,22 @@
|
||||
What: /proc/<pid>/oom_adj
|
||||
When: August 2012
|
||||
Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's
|
||||
badness heuristic used to determine which task to kill when the kernel
|
||||
is out of memory.
|
||||
|
||||
The badness heuristic has since been rewritten since the introduction of
|
||||
this tunable such that its meaning is deprecated. The value was
|
||||
implemented as a bitshift on a score generated by the badness()
|
||||
function that did not have any precise units of measure. With the
|
||||
rewrite, the score is given as a proportion of available memory to the
|
||||
task allocating pages, so using a bitshift which grows the score
|
||||
exponentially is, thus, impossible to tune with fine granularity.
|
||||
|
||||
A much more powerful interface, /proc/<pid>/oom_score_adj, was
|
||||
introduced with the oom killer rewrite that allows users to increase or
|
||||
decrease the badness() score linearly. This interface will replace
|
||||
/proc/<pid>/oom_adj.
|
||||
|
||||
A warning will be emitted to the kernel log if an application uses this
|
||||
deprecated interface. After it is printed once, future warnings will be
|
||||
suppressed until the kernel is rebooted.
|
||||
@@ -0,0 +1,83 @@
|
||||
What: /sys/bus/rbd/
|
||||
Date: November 2010
|
||||
Contact: Yehuda Sadeh <yehuda@hq.newdream.net>,
|
||||
Sage Weil <sage@newdream.net>
|
||||
Description:
|
||||
|
||||
Being used for adding and removing rbd block devices.
|
||||
|
||||
Usage: <mon ip addr> <options> <pool name> <rbd image name> [snap name]
|
||||
|
||||
$ echo "192.168.0.1 name=admin rbd foo" > /sys/bus/rbd/add
|
||||
|
||||
The snapshot name can be "-" or omitted to map the image read/write. A <dev-id>
|
||||
will be assigned for any registered block device. If snapshot is used, it will
|
||||
be mapped read-only.
|
||||
|
||||
Removal of a device:
|
||||
|
||||
$ echo <dev-id> > /sys/bus/rbd/remove
|
||||
|
||||
Entries under /sys/bus/rbd/devices/<dev-id>/
|
||||
--------------------------------------------
|
||||
|
||||
client_id
|
||||
|
||||
The ceph unique client id that was assigned for this specific session.
|
||||
|
||||
major
|
||||
|
||||
The block device major number.
|
||||
|
||||
name
|
||||
|
||||
The name of the rbd image.
|
||||
|
||||
pool
|
||||
|
||||
The pool where this rbd image resides. The pool-name pair is unique
|
||||
per rados system.
|
||||
|
||||
size
|
||||
|
||||
The size (in bytes) of the mapped block device.
|
||||
|
||||
refresh
|
||||
|
||||
Writing to this file will reread the image header data and set
|
||||
all relevant datastructures accordingly.
|
||||
|
||||
current_snap
|
||||
|
||||
The current snapshot for which the device is mapped.
|
||||
|
||||
create_snap
|
||||
|
||||
Create a snapshot:
|
||||
|
||||
$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_create
|
||||
|
||||
rollback_snap
|
||||
|
||||
Rolls back data to the specified snapshot. This goes over the entire
|
||||
list of rados blocks and sends a rollback command to each.
|
||||
|
||||
$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_rollback
|
||||
|
||||
snap_*
|
||||
|
||||
A directory per each snapshot
|
||||
|
||||
|
||||
Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
|
||||
-------------------------------------------------------------
|
||||
|
||||
id
|
||||
|
||||
The rados internal snapshot id assigned for this snapshot
|
||||
|
||||
size
|
||||
|
||||
The size of the image when this snapshot was taken.
|
||||
|
||||
|
||||
@@ -79,10 +79,6 @@
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter id="clk">
|
||||
<title>Clock Framework Extensions</title>
|
||||
!Iinclude/linux/sh_clk.h
|
||||
</chapter>
|
||||
<chapter id="mach">
|
||||
<title>Machine Specific Interfaces</title>
|
||||
<sect1 id="dreamcast">
|
||||
|
||||
@@ -16,7 +16,7 @@
|
||||
</orgname>
|
||||
|
||||
<address>
|
||||
<email>hjk@linutronix.de</email>
|
||||
<email>hjk@hansjkoch.de</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
@@ -114,7 +114,7 @@ GPL version 2.
|
||||
|
||||
<para>If you know of any translations for this document, or you are
|
||||
interested in translating it, please email me
|
||||
<email>hjk@linutronix.de</email>.
|
||||
<email>hjk@hansjkoch.de</email>.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
@@ -171,7 +171,7 @@ interested in translating it, please email me
|
||||
<title>Feedback</title>
|
||||
<para>Find something wrong with this document? (Or perhaps something
|
||||
right?) I would love to hear from you. Please email me at
|
||||
<email>hjk@linutronix.de</email>.</para>
|
||||
<email>hjk@hansjkoch.de</email>.</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
|
||||
@@ -255,9 +255,10 @@ framebuffer parameters.
|
||||
Kernel boot arguments
|
||||
---------------------
|
||||
|
||||
vram=<size>
|
||||
- Amount of total VRAM to preallocate. For example, "10M". omapfb
|
||||
allocates memory for framebuffers from VRAM.
|
||||
vram=<size>[,<physaddr>]
|
||||
- Amount of total VRAM to preallocate and optionally a physical start
|
||||
memory address. For example, "10M". omapfb allocates memory for
|
||||
framebuffers from VRAM.
|
||||
|
||||
omapfb.mode=<display>:<mode>[,...]
|
||||
- Default video mode for specified displays. For example,
|
||||
|
||||
@@ -16,7 +16,7 @@ you can do so by typing:
|
||||
As of the Linux 2.6.10 kernel, it is now possible to change the
|
||||
IO scheduler for a given block device on the fly (thus making it possible,
|
||||
for instance, to set the CFQ scheduler for the system default, but
|
||||
set a specific device to use the anticipatory or noop schedulers - which
|
||||
set a specific device to use the deadline or noop schedulers - which
|
||||
can improve that device's throughput).
|
||||
|
||||
To set a specific scheduler, simply do this:
|
||||
@@ -31,7 +31,7 @@ a "cat /sys/block/DEV/queue/scheduler" - the list of valid names
|
||||
will be displayed, with the currently selected scheduler in brackets:
|
||||
|
||||
# cat /sys/block/hda/queue/scheduler
|
||||
noop anticipatory deadline [cfq]
|
||||
# echo anticipatory > /sys/block/hda/queue/scheduler
|
||||
noop deadline [cfq]
|
||||
# echo deadline > /sys/block/hda/queue/scheduler
|
||||
# cat /sys/block/hda/queue/scheduler
|
||||
noop [anticipatory] deadline cfq
|
||||
noop [deadline] cfq
|
||||
|
||||
@@ -154,7 +154,7 @@ The stages that a patch goes through are, generally:
|
||||
inclusion, it should be accepted by a relevant subsystem maintainer -
|
||||
though this acceptance is not a guarantee that the patch will make it
|
||||
all the way to the mainline. The patch will show up in the maintainer's
|
||||
subsystem tree and into the staging trees (described below). When the
|
||||
subsystem tree and into the -next trees (described below). When the
|
||||
process works, this step leads to more extensive review of the patch and
|
||||
the discovery of any problems resulting from the integration of this
|
||||
patch with work being done by others.
|
||||
@@ -236,7 +236,7 @@ finding the right maintainer. Sending patches directly to Linus is not
|
||||
normally the right way to go.
|
||||
|
||||
|
||||
2.4: STAGING TREES
|
||||
2.4: NEXT TREES
|
||||
|
||||
The chain of subsystem trees guides the flow of patches into the kernel,
|
||||
but it also raises an interesting question: what if somebody wants to look
|
||||
@@ -250,7 +250,7 @@ changes land in the mainline kernel. One could pull changes from all of
|
||||
the interesting subsystem trees, but that would be a big and error-prone
|
||||
job.
|
||||
|
||||
The answer comes in the form of staging trees, where subsystem trees are
|
||||
The answer comes in the form of -next trees, where subsystem trees are
|
||||
collected for testing and review. The older of these trees, maintained by
|
||||
Andrew Morton, is called "-mm" (for memory management, which is how it got
|
||||
started). The -mm tree integrates patches from a long list of subsystem
|
||||
@@ -275,7 +275,7 @@ directory at:
|
||||
Use of the MMOTM tree is likely to be a frustrating experience, though;
|
||||
there is a definite chance that it will not even compile.
|
||||
|
||||
The other staging tree, started more recently, is linux-next, maintained by
|
||||
The other -next tree, started more recently, is linux-next, maintained by
|
||||
Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
|
||||
the mainline is expected to look like after the next merge window closes.
|
||||
Linux-next trees are announced on the linux-kernel and linux-next mailing
|
||||
@@ -303,12 +303,25 @@ volatility of linux-next tends to make it a difficult development target.
|
||||
See http://lwn.net/Articles/289013/ for more information on this topic, and
|
||||
stay tuned; much is still in flux where linux-next is involved.
|
||||
|
||||
Besides the mmotm and linux-next trees, the kernel source tree now contains
|
||||
the drivers/staging/ directory and many sub-directories for drivers or
|
||||
filesystems that are on their way to being added to the kernel tree
|
||||
proper, but they remain in drivers/staging/ while they still need more
|
||||
work.
|
||||
2.4.1: STAGING TREES
|
||||
|
||||
The kernel source tree now contains the drivers/staging/ directory, where
|
||||
many sub-directories for drivers or filesystems that are on their way to
|
||||
being added to the kernel tree live. They remain in drivers/staging while
|
||||
they still need more work; once complete, they can be moved into the
|
||||
kernel proper. This is a way to keep track of drivers that aren't
|
||||
up to Linux kernel coding or quality standards, but people may want to use
|
||||
them and track development.
|
||||
|
||||
Greg Kroah-Hartman currently (as of 2.6.36) maintains the staging tree.
|
||||
Drivers that still need work are sent to him, with each driver having
|
||||
its own subdirectory in drivers/staging/. Along with the driver source
|
||||
files, a TODO file should be present in the directory as well. The TODO
|
||||
file lists the pending work that the driver needs for acceptance into
|
||||
the kernel proper, as well as a list of people that should be Cc'd for any
|
||||
patches to the driver. Staging drivers that don't currently build should
|
||||
have their config entries depend upon CONFIG_BROKEN. Once they can
|
||||
be successfully built without outside patches, CONFIG_BROKEN can be removed.
|
||||
|
||||
2.5: TOOLS
|
||||
|
||||
|
||||
@@ -1,129 +0,0 @@
|
||||
|
||||
Device Interfaces
|
||||
|
||||
Introduction
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Device interfaces are the logical interfaces of device classes that correlate
|
||||
directly to userspace interfaces, like device nodes.
|
||||
|
||||
Each device class may have multiple interfaces through which you can
|
||||
access the same device. An input device may support the mouse interface,
|
||||
the 'evdev' interface, and the touchscreen interface. A SCSI disk would
|
||||
support the disk interface, the SCSI generic interface, and possibly a raw
|
||||
device interface.
|
||||
|
||||
Device interfaces are registered with the class they belong to. As devices
|
||||
are added to the class, they are added to each interface registered with
|
||||
the class. The interface is responsible for determining whether the device
|
||||
supports the interface or not.
|
||||
|
||||
|
||||
Programming Interface
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
struct device_interface {
|
||||
char * name;
|
||||
rwlock_t lock;
|
||||
u32 devnum;
|
||||
struct device_class * devclass;
|
||||
|
||||
struct list_head node;
|
||||
struct driver_dir_entry dir;
|
||||
|
||||
int (*add_device)(struct device *);
|
||||
int (*add_device)(struct intf_data *);
|
||||
};
|
||||
|
||||
int interface_register(struct device_interface *);
|
||||
void interface_unregister(struct device_interface *);
|
||||
|
||||
|
||||
An interface must specify the device class it belongs to. It is added
|
||||
to that class's list of interfaces on registration.
|
||||
|
||||
|
||||
Interfaces can be added to a device class at any time. Whenever it is
|
||||
added, each device in the class is passed to the interface's
|
||||
add_device callback. When an interface is removed, each device is
|
||||
removed from the interface.
|
||||
|
||||
|
||||
Devices
|
||||
~~~~~~~
|
||||
Once a device is added to a device class, it is added to each
|
||||
interface that is registered with the device class. The class
|
||||
is expected to place a class-specific data structure in
|
||||
struct device::class_data. The interface can use that (along with
|
||||
other fields of struct device) to determine whether or not the driver
|
||||
and/or device support that particular interface.
|
||||
|
||||
|
||||
Data
|
||||
~~~~
|
||||
|
||||
struct intf_data {
|
||||
struct list_head node;
|
||||
struct device_interface * intf;
|
||||
struct device * dev;
|
||||
u32 intf_num;
|
||||
};
|
||||
|
||||
int interface_add_data(struct interface_data *);
|
||||
|
||||
The interface is responsible for allocating and initializing a struct
|
||||
intf_data and calling interface_add_data() to add it to the device's list
|
||||
of interfaces it belongs to. This list will be iterated over when the device
|
||||
is removed from the class (instead of all possible interfaces for a class).
|
||||
This structure should probably be embedded in whatever per-device data
|
||||
structure the interface is allocating anyway.
|
||||
|
||||
Devices are enumerated within the interface. This happens in interface_add_data()
|
||||
and the enumerated value is stored in the struct intf_data for that device.
|
||||
|
||||
sysfs
|
||||
~~~~~
|
||||
Each interface is given a directory in the directory of the device
|
||||
class it belongs to:
|
||||
|
||||
Interfaces get a directory in the class's directory as well:
|
||||
|
||||
class/
|
||||
`-- input
|
||||
|-- devices
|
||||
|-- drivers
|
||||
|-- mouse
|
||||
`-- evdev
|
||||
|
||||
When a device is added to the interface, a symlink is created that points
|
||||
to the device's directory in the physical hierarchy:
|
||||
|
||||
class/
|
||||
`-- input
|
||||
|-- devices
|
||||
| `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
|
||||
|-- drivers
|
||||
| `-- usb:usb_mouse -> ../../../bus/drivers/usb_mouse/
|
||||
|-- mouse
|
||||
| `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
|
||||
`-- evdev
|
||||
`-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
|
||||
|
||||
|
||||
Future Plans
|
||||
~~~~~~~~~~~~
|
||||
A device interface is correlated directly with a userspace interface
|
||||
for a device, specifically a device node. For instance, a SCSI disk
|
||||
exposes at least two interfaces to userspace: the standard SCSI disk
|
||||
interface and the SCSI generic interface. It might also export a raw
|
||||
device interface.
|
||||
|
||||
Many interfaces have a major number associated with them and each
|
||||
device gets a minor number. Or, multiple interfaces might share one
|
||||
major number, and each will receive a range of minor numbers (like in
|
||||
the case of input devices).
|
||||
|
||||
These major and minor numbers could be stored in the interface
|
||||
structure. Major and minor allocations could happen when the interface
|
||||
is registered with the class, or via a helper function.
|
||||
|
||||
@@ -196,7 +196,7 @@ csrow3.
|
||||
The representation of the above is reflected in the directory tree
|
||||
in EDAC's sysfs interface. Starting in directory
|
||||
/sys/devices/system/edac/mc each memory controller will be represented
|
||||
by its own 'mcX' directory, where 'X" is the index of the MC.
|
||||
by its own 'mcX' directory, where 'X' is the index of the MC.
|
||||
|
||||
|
||||
..../edac/mc/
|
||||
@@ -207,7 +207,7 @@ by its own 'mcX' directory, where 'X" is the index of the MC.
|
||||
....
|
||||
|
||||
Under each 'mcX' directory each 'csrowX' is again represented by a
|
||||
'csrowX', where 'X" is the csrow index:
|
||||
'csrowX', where 'X' is the csrow index:
|
||||
|
||||
|
||||
.../mc/mc0/
|
||||
@@ -232,7 +232,7 @@ EDAC control and attribute files.
|
||||
|
||||
|
||||
In 'mcX' directories are EDAC control and attribute files for
|
||||
this 'X" instance of the memory controllers:
|
||||
this 'X' instance of the memory controllers:
|
||||
|
||||
|
||||
Counter reset control file:
|
||||
@@ -343,7 +343,7 @@ Sdram memory scrubbing rate:
|
||||
'csrowX' DIRECTORIES
|
||||
|
||||
In the 'csrowX' directories are EDAC control and attribute files for
|
||||
this 'X" instance of csrow:
|
||||
this 'X' instance of csrow:
|
||||
|
||||
|
||||
Total Uncorrectable Errors count attribute file:
|
||||
|
||||
@@ -4,33 +4,41 @@ please mail me.
|
||||
Geert Uytterhoeven <geert@linux-m68k.org>
|
||||
|
||||
00-INDEX
|
||||
- this file
|
||||
- this file.
|
||||
arkfb.txt
|
||||
- info on the fbdev driver for ARK Logic chips.
|
||||
aty128fb.txt
|
||||
- info on the ATI Rage128 frame buffer driver.
|
||||
cirrusfb.txt
|
||||
- info on the driver for Cirrus Logic chipsets.
|
||||
cmap_xfbdev.txt
|
||||
- an introduction to fbdev's cmap structures.
|
||||
deferred_io.txt
|
||||
- an introduction to deferred IO.
|
||||
efifb.txt
|
||||
- info on the EFI platform driver for Intel based Apple computers.
|
||||
ep93xx-fb.txt
|
||||
- info on the driver for EP93xx LCD controller.
|
||||
fbcon.txt
|
||||
- intro to and usage guide for the framebuffer console (fbcon).
|
||||
framebuffer.txt
|
||||
- introduction to frame buffer devices.
|
||||
imacfb.txt
|
||||
- info on the generic EFI platform driver for Intel based Macs.
|
||||
gxfb.txt
|
||||
- info on the framebuffer driver for AMD Geode GX2 based processors.
|
||||
intel810.txt
|
||||
- documentation for the Intel 810/815 framebuffer driver.
|
||||
intelfb.txt
|
||||
- docs for Intel 830M/845G/852GM/855GM/865G/915G/945G fb driver.
|
||||
internals.txt
|
||||
- quick overview of frame buffer device internals.
|
||||
lxfb.txt
|
||||
- info on the framebuffer driver for AMD Geode LX based processors.
|
||||
matroxfb.txt
|
||||
- info on the Matrox framebuffer driver for Alpha, Intel and PPC.
|
||||
metronomefb.txt
|
||||
- info on the driver for the Metronome display controller.
|
||||
modedb.txt
|
||||
- info on the video mode database.
|
||||
matroxfb.txt
|
||||
- info on the Matrox frame buffer driver.
|
||||
pvr2fb.txt
|
||||
- info on the PowerVR 2 frame buffer driver.
|
||||
pxafb.txt
|
||||
@@ -39,13 +47,23 @@ s3fb.txt
|
||||
- info on the fbdev driver for S3 Trio/Virge chips.
|
||||
sa1100fb.txt
|
||||
- information about the driver for the SA-1100 LCD controller.
|
||||
sh7760fb.txt
|
||||
- info on the SH7760/SH7763 integrated LCDC Framebuffer driver.
|
||||
sisfb.txt
|
||||
- info on the framebuffer device driver for various SiS chips.
|
||||
sstfb.txt
|
||||
- info on the frame buffer driver for 3dfx' Voodoo Graphics boards.
|
||||
tgafb.txt
|
||||
- info on the TGA (DECChip 21030) frame buffer driver
|
||||
- info on the TGA (DECChip 21030) frame buffer driver.
|
||||
tridentfb.txt
|
||||
info on the framebuffer driver for some Trident chip based cards.
|
||||
uvesafb.txt
|
||||
- info on the userspace VESA (VBE2+ compliant) frame buffer device.
|
||||
vesafb.txt
|
||||
- info on the VESA frame buffer device
|
||||
- info on the VESA frame buffer device.
|
||||
viafb.modes
|
||||
- list of modes for VIA Integration Graphic Chip.
|
||||
viafb.txt
|
||||
- info on the VIA Integration Graphic Chip console framebuffer driver.
|
||||
vt8623fb.txt
|
||||
- info on the fb driver for the graphics core in VIA VT8623 chipsets.
|
||||
|
||||
@@ -554,3 +554,13 @@ Why: This is a legacy interface which have been replaced by a more
|
||||
Who: NeilBrown <neilb@suse.de>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: i2c_adapter.id
|
||||
When: June 2011
|
||||
Why: This field is deprecated. I2C device drivers shouldn't change their
|
||||
behavior based on the underlying I2C adapter. Instead, the I2C
|
||||
adapter driver should instantiate the I2C devices and provide the
|
||||
needed platform-specific information.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
@@ -89,7 +89,7 @@ static ssize_t childless_storeme_write(struct childless *childless,
|
||||
char *p = (char *) page;
|
||||
|
||||
tmp = simple_strtoul(p, &p, 10);
|
||||
if (!p || (*p && (*p != '\n')))
|
||||
if ((*p != '\0') && (*p != '\n'))
|
||||
return -EINVAL;
|
||||
|
||||
if (tmp > INT_MAX)
|
||||
|
||||
@@ -660,11 +660,10 @@ struct address_space_operations {
|
||||
releasepage: releasepage is called on PagePrivate pages to indicate
|
||||
that the page should be freed if possible. ->releasepage
|
||||
should remove any private data from the page and clear the
|
||||
PagePrivate flag. It may also remove the page from the
|
||||
address_space. If this fails for some reason, it may indicate
|
||||
failure with a 0 return value.
|
||||
This is used in two distinct though related cases. The first
|
||||
is when the VM finds a clean page with no active users and
|
||||
PagePrivate flag. If releasepage() fails for some reason, it must
|
||||
indicate failure with a 0 return value.
|
||||
releasepage() is used in two distinct though related cases. The
|
||||
first is when the VM finds a clean page with no active users and
|
||||
wants to make it a free page. If ->releasepage succeeds, the
|
||||
page will be removed from the address_space and become free.
|
||||
|
||||
|
||||
@@ -794,17 +794,6 @@ designed.
|
||||
|
||||
Roadmap:
|
||||
|
||||
2.6.37 Remove experimental tag from mount option
|
||||
=> should be roughly 6 months after initial merge
|
||||
=> enough time to:
|
||||
=> gain confidence and fix problems reported by early
|
||||
adopters (a.k.a. guinea pigs)
|
||||
=> address worst performance regressions and undesired
|
||||
behaviours
|
||||
=> start tuning/optimising code for parallelism
|
||||
=> start tuning/optimising algorithms consuming
|
||||
excessive CPU time
|
||||
|
||||
2.6.39 Switch default mount option to use delayed logging
|
||||
=> should be roughly 12 months after initial merge
|
||||
=> enough time to shake out remaining problems before next round of
|
||||
|
||||
@@ -617,6 +617,16 @@ and have the following read/write attributes:
|
||||
is configured as an output, this value may be written;
|
||||
any nonzero value is treated as high.
|
||||
|
||||
If the pin can be configured as interrupt-generating interrupt
|
||||
and if it has been configured to generate interrupts (see the
|
||||
description of "edge"), you can poll(2) on that file and
|
||||
poll(2) will return whenever the interrupt was triggered. If
|
||||
you use poll(2), set the events POLLPRI and POLLERR. If you
|
||||
use select(2), set the file descriptor in exceptfds. After
|
||||
poll(2) returns, either lseek(2) to the beginning of the sysfs
|
||||
file and read the new value or close the file and re-open it
|
||||
to read the value.
|
||||
|
||||
"edge" ... reads as either "none", "rising", "falling", or
|
||||
"both". Write these strings to select the signal edge(s)
|
||||
that will make poll(2) on the "value" file return.
|
||||
|
||||
@@ -11,7 +11,7 @@ Authors:
|
||||
Mark M. Hoffman <mhoffman@lightlink.com>
|
||||
Ported to 2.6 by Eric J. Bowersox <ericb@aspsys.com>
|
||||
Adapted to 2.6.20 by Carsten Emde <ce@osadl.org>
|
||||
Modified for mainline integration by Hans J. Koch <hjk@linutronix.de>
|
||||
Modified for mainline integration by Hans J. Koch <hjk@hansjkoch.de>
|
||||
|
||||
Module Parameters
|
||||
-----------------
|
||||
|
||||
@@ -8,7 +8,7 @@ Supported chips:
|
||||
Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
|
||||
|
||||
Authors:
|
||||
Hans J. Koch <hjk@linutronix.de>
|
||||
Hans J. Koch <hjk@hansjkoch.de>
|
||||
John Morris <john.morris@spirentcom.com>
|
||||
Claus Gindhart <claus.gindhart@kontron.com>
|
||||
|
||||
|
||||
@@ -706,7 +706,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
|
||||
|
||||
elevator= [IOSCHED]
|
||||
Format: {"anticipatory" | "cfq" | "deadline" | "noop"}
|
||||
Format: {"cfq" | "deadline" | "noop"}
|
||||
See Documentation/block/as-iosched.txt and
|
||||
Documentation/block/deadline-iosched.txt for details.
|
||||
|
||||
@@ -2385,6 +2385,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
improve throughput, but will also increase the
|
||||
amount of memory reserved for use by the client.
|
||||
|
||||
swapaccount[=0|1]
|
||||
[KNL] Enable accounting of swap in memory resource
|
||||
controller if no parameter or 1 is given or disable
|
||||
it if 0 is given (See Documentation/cgroups/memory.txt)
|
||||
|
||||
swiotlb= [IA-64] Number of I/O TLB slabs
|
||||
|
||||
switches= [HW,M68k]
|
||||
|
||||
@@ -60,15 +60,18 @@ Hardware accelerated blink of LEDs
|
||||
|
||||
Some LEDs can be programmed to blink without any CPU interaction. To
|
||||
support this feature, a LED driver can optionally implement the
|
||||
blink_set() function (see <linux/leds.h>). If implemented, triggers can
|
||||
attempt to use it before falling back to software timers. The blink_set()
|
||||
function should return 0 if the blink setting is supported, or -EINVAL
|
||||
otherwise, which means that LED blinking will be handled by software.
|
||||
blink_set() function (see <linux/leds.h>). To set an LED to blinking,
|
||||
however, it is better to use use the API function led_blink_set(),
|
||||
as it will check and implement software fallback if necessary.
|
||||
|
||||
The blink_set() function should choose a user friendly blinking
|
||||
value if it is called with *delay_on==0 && *delay_off==0 parameters. In
|
||||
this case the driver should give back the chosen value through delay_on
|
||||
and delay_off parameters to the leds subsystem.
|
||||
To turn off blinking again, use the API function led_brightness_set()
|
||||
as that will not just set the LED brightness but also stop any software
|
||||
timers that may have been required for blinking.
|
||||
|
||||
The blink_set() function should choose a user friendly blinking value
|
||||
if it is called with *delay_on==0 && *delay_off==0 parameters. In this
|
||||
case the driver should give back the chosen value through delay_on and
|
||||
delay_off parameters to the leds subsystem.
|
||||
|
||||
Setting the brightness to zero with brightness_set() callback function
|
||||
should completely turn off the LED and cancel the previously programmed
|
||||
|
||||
@@ -0,0 +1,88 @@
|
||||
Kernel driver for lp5521
|
||||
========================
|
||||
|
||||
* National Semiconductor LP5521 led driver chip
|
||||
* Datasheet: http://www.national.com/pf/LP/LP5521.html
|
||||
|
||||
Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo
|
||||
Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
LP5521 can drive up to 3 channels. Leds can be controlled directly via
|
||||
the led class control interface. Channels have generic names:
|
||||
lp5521:channelx, where x is 0 .. 2
|
||||
|
||||
All three channels can be also controlled using the engine micro programs.
|
||||
More details of the instructions can be found from the public data sheet.
|
||||
|
||||
Control interface for the engines:
|
||||
x is 1 .. 3
|
||||
enginex_mode : disabled, load, run
|
||||
enginex_load : store program (visible only in engine load mode)
|
||||
|
||||
Example (start to blink the channel 2 led):
|
||||
cd /sys/class/leds/lp5521:channel2/device
|
||||
echo "load" > engine3_mode
|
||||
echo "037f4d0003ff6000" > engine3_load
|
||||
echo "run" > engine3_mode
|
||||
|
||||
stop the engine:
|
||||
echo "disabled" > engine3_mode
|
||||
|
||||
sysfs contains a selftest entry.
|
||||
The test communicates with the chip and checks that
|
||||
the clock mode is automatically set to the requested one.
|
||||
|
||||
Each channel has its own led current settings.
|
||||
/sys/class/leds/lp5521:channel0/led_current - RW
|
||||
/sys/class/leds/lp5521:channel0/max_current - RO
|
||||
Format: 10x mA i.e 10 means 1.0 mA
|
||||
|
||||
example platform data:
|
||||
|
||||
Note: chan_nr can have values between 0 and 2.
|
||||
|
||||
static struct lp5521_led_config lp5521_led_config[] = {
|
||||
{
|
||||
.chan_nr = 0,
|
||||
.led_current = 50,
|
||||
.max_current = 130,
|
||||
}, {
|
||||
.chan_nr = 1,
|
||||
.led_current = 0,
|
||||
.max_current = 130,
|
||||
}, {
|
||||
.chan_nr = 2,
|
||||
.led_current = 0,
|
||||
.max_current = 130,
|
||||
}
|
||||
};
|
||||
|
||||
static int lp5521_setup(void)
|
||||
{
|
||||
/* setup HW resources */
|
||||
}
|
||||
|
||||
static void lp5521_release(void)
|
||||
{
|
||||
/* Release HW resources */
|
||||
}
|
||||
|
||||
static void lp5521_enable(bool state)
|
||||
{
|
||||
/* Control of chip enable signal */
|
||||
}
|
||||
|
||||
static struct lp5521_platform_data lp5521_platform_data = {
|
||||
.led_config = lp5521_led_config,
|
||||
.num_channels = ARRAY_SIZE(lp5521_led_config),
|
||||
.clock_mode = LP5521_CLOCK_EXT,
|
||||
.setup_resources = lp5521_setup,
|
||||
.release_resources = lp5521_release,
|
||||
.enable = lp5521_enable,
|
||||
};
|
||||
|
||||
If the current is set to 0 in the platform data, that channel is
|
||||
disabled and it is not visible in the sysfs.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user