Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 29534
b: refs/heads/master
c: 71d530c
h: refs/heads/master
v: v3
  • Loading branch information
Jeff Garzik committed Jun 23, 2006
1 parent 8004dab commit 1d8bff0
Show file tree
Hide file tree
Showing 2,779 changed files with 113,071 additions and 92,463 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: d7a80dad2fe19a2b8c119c8e9cba605474a75a2b
refs/heads/master: 71d530cd1b6d97094481002a04c77fea1c8e1c22
77 changes: 77 additions & 0 deletions trunk/Documentation/ABI/README
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
This directory attempts to document the ABI between the Linux kernel and
userspace, and the relative stability of these interfaces. Due to the
everchanging nature of Linux, and the differing maturity levels, these
interfaces should be used by userspace programs in different ways.

We have four different levels of ABI stability, as shown by the four
different subdirectories in this location. Interfaces may change levels
of stability according to the rules described below.

The different levels of stability are:

stable/
This directory documents the interfaces that the developer has
defined to be stable. Userspace programs are free to use these
interfaces with no restrictions, and backward compatibility for
them will be guaranteed for at least 2 years. Most interfaces
(like syscalls) are expected to never change and always be
available.

testing/
This directory documents interfaces that are felt to be stable,
as the main development of this interface has been completed.
The interface can be changed to add new features, but the
current interface will not break by doing this, unless grave
errors or security problems are found in them. Userspace
programs can start to rely on these interfaces, but they must be
aware of changes that can occur before these interfaces move to
be marked stable. Programs that use these interfaces are
strongly encouraged to add their name to the description of
these interfaces, so that the kernel developers can easily
notify them if any changes occur (see the description of the
layout of the files below for details on how to do this.)

obsolete/
This directory documents interfaces that are still remaining in
the kernel, but are marked to be removed at some later point in
time. The description of the interface will document the reason
why it is obsolete and when it can be expected to be removed.
The file Documentation/feature-removal-schedule.txt may describe
some of these interfaces, giving a schedule for when they will
be removed.

removed/
This directory contains a list of the old interfaces that have
been removed from the kernel.

Every file in these directories will contain the following information:

What: Short description of the interface
Date: Date created
KernelVersion: Kernel version this feature first showed up in.
Contact: Primary contact for this interface (may be a mailing list)
Description: Long description of the interface and how to use it.
Users: All users of this interface who wish to be notified when
it changes. This is very important for interfaces in
the "testing" stage, so that kernel developers can work
with userspace developers to ensure that things do not
break in ways that are unacceptable. It is also
important to get feedback for these interfaces to make
sure they are working in a proper way and do not need to
be changed further.


How things move between levels:

Interfaces in stable may move to obsolete, as long as the proper
notification is given.

Interfaces may be removed from obsolete and the kernel as long as the
documented amount of time has gone by.

Interfaces in the testing state can move to the stable state when the
developers feel they are finished. They cannot be removed from the
kernel tree without going through the obsolete state first.

It's up to the developer to place their interfaces in the category they
wish for it to start out in.
13 changes: 13 additions & 0 deletions trunk/Documentation/ABI/obsolete/devfs
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
What: devfs
Date: July 2005
Contact: Greg Kroah-Hartman <gregkh@suse.de>
Description:
devfs has been unmaintained for a number of years, has unfixable
races, contains a naming policy within the kernel that is
against the LSB, and can be replaced by using udev.
The files fs/devfs/*, include/linux/devfs_fs*.h will be removed,
along with the the assorted devfs function calls throughout the
kernel tree.

Users:

10 changes: 10 additions & 0 deletions trunk/Documentation/ABI/stable/syscalls
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
What: The kernel syscall interface
Description:
This interface matches much of the POSIX interface and is based
on it and other Unix based interfaces. It will only be added to
over time, and not have things removed from it.

Note that this interface is different for every architecture
that Linux supports. Please see the architecture-specific
documentation for details on the syscall numbers that are to be
mapped to each syscall.
30 changes: 30 additions & 0 deletions trunk/Documentation/ABI/stable/sysfs-module
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
What: /sys/module
Description:
The /sys/module tree consists of the following structure:

/sys/module/MODULENAME
The name of the module that is in the kernel. This
module name will show up either if the module is built
directly into the kernel, or if it is loaded as a
dyanmic module.

/sys/module/MODULENAME/parameters
This directory contains individual files that are each
individual parameters of the module that are able to be
changed at runtime. See the individual module
documentation as to the contents of these parameters and
what they accomplish.

Note: The individual parameter names and values are not
considered stable, only the fact that they will be
placed in this location within sysfs. See the
individual driver documentation for details as to the
stability of the different parameters.

/sys/module/MODULENAME/refcnt
If the module is able to be unloaded from the kernel, this file
will contain the current reference count of the module.

Note: If the module is built into the kernel, or if the
CONFIG_MODULE_UNLOAD kernel configuration value is not enabled,
this file will not be present.
16 changes: 16 additions & 0 deletions trunk/Documentation/ABI/testing/sysfs-class
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
What: /sys/class/
Date: Febuary 2006
Contact: Greg Kroah-Hartman <gregkh@suse.de>
Description:
The /sys/class directory will consist of a group of
subdirectories describing individual classes of devices
in the kernel. The individual directories will consist
of either subdirectories, or symlinks to other
directories.

All programs that use this directory tree must be able
to handle both subdirectories or symlinks in order to
work properly.

Users:
udev <linux-hotplug-devel@lists.sourceforge.net>
25 changes: 25 additions & 0 deletions trunk/Documentation/ABI/testing/sysfs-devices
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
What: /sys/devices
Date: February 2006
Contact: Greg Kroah-Hartman <gregkh@suse.de>
Description:
The /sys/devices tree contains a snapshot of the
internal state of the kernel device tree. Devices will
be added and removed dynamically as the machine runs,
and between different kernel versions, the layout of the
devices within this tree will change.

Please do not rely on the format of this tree because of
this. If a program wishes to find different things in
the tree, please use the /sys/class structure and rely
on the symlinks there to point to the proper location
within the /sys/devices tree of the individual devices.
Or rely on the uevent messages to notify programs of
devices being added and removed from this tree to find
the location of those devices.

Note that sometimes not all devices along the directory
chain will have emitted uevent messages, so userspace
programs must be able to handle such occurrences.

Users:
udev <linux-hotplug-devel@lists.sourceforge.net>
61 changes: 61 additions & 0 deletions trunk/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
README on the ADC/Touchscreen Controller
========================================

The LH79524 and LH7A404 include a built-in Analog to Digital
controller (ADC) that is used to process input from a touchscreen.
The driver only implements a four-wire touch panel protocol.

The touchscreen driver is maintenance free except for the pen-down or
touch threshold. Some resistive displays and board combinations may
require tuning of this threshold. The driver exposes some of it's
internal state in the sys filesystem. If the kernel is configured
with it, CONFIG_SYSFS, and sysfs is mounted at /sys, there will be a
directory

/sys/devices/platform/adc-lh7.0

containing these files.

-r--r--r-- 1 root root 4096 Jan 1 00:00 samples
-rw-r--r-- 1 root root 4096 Jan 1 00:00 threshold
-r--r--r-- 1 root root 4096 Jan 1 00:00 threshold_range

The threshold is the current touch threshold. It defaults to 750 on
most targets.

# cat threshold
750

The threshold_range contains the range of valid values for the
threshold. Values outside of this range will be silently ignored.

# cat threshold_range
0 1023

To change the threshold, write a value to the threshold file.

# echo 500 > threshold
# cat threshold
500

The samples file contains the most recently sampled values from the
ADC. There are 12. Below are typical of the last sampled values when
the pen has been released. The first two and last two samples are for
detecting whether or not the pen is down. The third through sixth are
X coordinate samples. The seventh through tenth are Y coordinate
samples.

# cat samples
1023 1023 0 0 0 0 530 529 530 529 1023 1023

To determine a reasonable threshold, press on the touch panel with an
appropriate stylus and read the values from samples.

# cat samples
1023 676 92 103 101 102 855 919 922 922 1023 679

The first and eleventh samples are discarded. Thus, the important
values are the second and twelfth which are used to determine if the
pen is down. When both are below the threshold, the driver registers
that the pen is down. When either is above the threshold, it
registers then pen is up.
59 changes: 59 additions & 0 deletions trunk/Documentation/arm/Sharp-LH/LCDPanels
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
README on the LCD Panels
========================

Configuration options for several LCD panels, available from Logic PD,
are included in the kernel source. This README will help you
understand the configuration data and give you some guidance for
adding support for other panels if you wish.


lcd-panels.h
------------

There is no way, at present, to detect which panel is attached to the
system at runtime. Thus the kernel configuration is static. The file
arch/arm/mach-ld7a40x/lcd-panels.h (or similar) defines all of the
panel specific parameters.

It should be possible for this data to be shared among several device
families. The current layout may be insufficiently general, but it is
amenable to improvement.


PIXEL_CLOCK
-----------

The panel data sheets will give a range of acceptable pixel clocks.
The fundamental LCDCLK input frequency is divided down by a PCD
constant in field '.tim2'. It may happen that it is impossible to set
the pixel clock within this range. A clock which is too slow will
tend to flicker. For the highest quality image, set the clock as high
as possible.


MARGINS
-------

These values may be difficult to glean from the panel data sheet. In
the case of the Sharp panels, the upper margin is explicitly called
out as a specific number of lines from the top of the frame. The
other values may not matter as much as the panels tend to
automatically center the image.


Sync Sense
----------

The sense of the hsync and vsync pulses may be called out in the data
sheet. On one panel, the sense of these pulses determine the height
of the visible region on the panel. Most of the Sharp panels use
negative sense sync pulses set by the TIM2_IHS and TIM2_IVS bits in
'.tim2'.


Pel Layout
----------

The Sharp color TFT panels are all configured for 16 bit direct color
modes. The amba-lcd driver sets the pel mode to 565 for 5 bits of
each red and blue and 6 bits of green.
13 changes: 2 additions & 11 deletions trunk/Documentation/feature-removal-schedule.txt
Original file line number Diff line number Diff line change
Expand Up @@ -49,11 +49,11 @@ Who: Paul E. McKenney <paulmck@us.ibm.com>
---------------------------

What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
When: November 2005
When: November 2006
Why: Deprecated in favour of the new ioctl-based rawiso interface, which is
more efficient. You should really be using libraw1394 for raw1394
access anyway.
Who: Jody McIntyre <scjody@steamballoon.com>
Who: Jody McIntyre <scjody@modernduck.com>

---------------------------

Expand Down Expand Up @@ -212,15 +212,6 @@ Who: Greg Kroah-Hartman <gregkh@suse.de>

---------------------------

What: Support for NEC DDB5074 and DDB5476 evaluation boards.
When: June 2006
Why: Board specific code doesn't build anymore since ~2.6.0 and no
users have complained indicating there is no more need for these
boards. This should really be considered a last call.
Who: Ralf Baechle <ralf@linux-mips.org>

---------------------------

What: USB driver API moves to EXPORT_SYMBOL_GPL
When: Febuary 2008
Files: include/linux/usb.h, drivers/usb/core/driver.c
Expand Down
Loading

0 comments on commit 1d8bff0

Please sign in to comment.