Commit a2ab67fa authored by Russell King's avatar Russell King Committed by Russell King

Merge branch 'for-rmk-devel' of git://git.pengutronix.de/git/imx/linux-2.6 into devel

Conflicts:
	arch/arm/Kconfig
	arch/arm/Makefile
parents 6d0485a9 135cad36
......@@ -143,7 +143,8 @@ quiet_cmd_db2pdf = PDF $@
$(call cmd,db2pdf)
main_idx = Documentation/DocBook/index.html
index = index.html
main_idx = Documentation/DocBook/$(index)
build_main_index = rm -rf $(main_idx) && \
echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \
echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \
......@@ -232,7 +233,7 @@ clean-files := $(DOCBOOKS) \
$(patsubst %.xml, %.pdf, $(DOCBOOKS)) \
$(patsubst %.xml, %.html, $(DOCBOOKS)) \
$(patsubst %.xml, %.9, $(DOCBOOKS)) \
$(C-procfs-example)
$(C-procfs-example) $(index)
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man
......
......@@ -190,16 +190,20 @@ X!Ekernel/module.c
!Edrivers/pci/pci.c
!Edrivers/pci/pci-driver.c
!Edrivers/pci/remove.c
!Edrivers/pci/pci-acpi.c
!Edrivers/pci/search.c
!Edrivers/pci/msi.c
!Edrivers/pci/bus.c
!Edrivers/pci/access.c
!Edrivers/pci/irq.c
!Edrivers/pci/htirq.c
<!-- FIXME: Removed for now since no structured comments in source
X!Edrivers/pci/hotplug.c
-->
!Edrivers/pci/probe.c
!Edrivers/pci/slot.c
!Edrivers/pci/rom.c
!Edrivers/pci/iov.c
!Idrivers/pci/pci-sysfs.c
</sect1>
<sect1><title>PCI Hotplug Support Library</title>
!Edrivers/pci/hotplug/pci_hotplug_core.c
......
......@@ -512,16 +512,24 @@ locking rules:
BKL mmap_sem PageLocked(page)
open: no yes
close: no yes
fault: no yes
page_mkwrite: no yes no
fault: no yes can return with page locked
page_mkwrite: no yes can return with page locked
access: no yes
->page_mkwrite() is called when a previously read-only page is
about to become writeable. The file system is responsible for
protecting against truncate races. Once appropriate action has been
taking to lock out truncate, the page range should be verified to be
within i_size. The page mapping should also be checked that it is not
NULL.
->fault() is called when a previously not present pte is about
to be faulted in. The filesystem must find and return the page associated
with the passed in "pgoff" in the vm_fault structure. If it is possible that
the page may be truncated and/or invalidated, then the filesystem must lock
the page, then ensure it is not already truncated (the page lock will block
subsequent truncate), and then return with VM_FAULT_LOCKED, and the page
locked. The VM will unlock the page.
->page_mkwrite() is called when a previously read-only pte is
about to become writeable. The filesystem again must ensure that there are
no truncate/invalidate races, and then return with the page locked. If
the page has been truncated, the filesystem should not look up a new page
like the ->fault() handler, but simply return with VM_FAULT_NOPAGE, which
will cause the VM to retry the fault.
->access() is called when get_user_pages() fails in
acces_process_vm(), typically used to debug a process through
......
BCM5974 Driver (bcm5974)
------------------------
Copyright (C) 2008-2009 Henrik Rydberg <rydberg@euromail.se>
The USB initialization and package decoding was made by Scott Shawcroft as
part of the touchd user-space driver project:
Copyright (C) 2008 Scott Shawcroft (scott.shawcroft@gmail.com)
The BCM5974 driver is based on the appletouch driver:
Copyright (C) 2001-2004 Greg Kroah-Hartman (greg@kroah.com)
Copyright (C) 2005 Johannes Berg (johannes@sipsolutions.net)
Copyright (C) 2005 Stelian Pop (stelian@popies.net)
Copyright (C) 2005 Frank Arnold (frank@scirocco-5v-turbo.de)
Copyright (C) 2005 Peter Osterlund (petero2@telia.com)
Copyright (C) 2005 Michael Hanselmann (linux-kernel@hansmi.ch)
Copyright (C) 2006 Nicolas Boichat (nicolas@boichat.ch)
This driver adds support for the multi-touch trackpad on the new Apple
Macbook Air and Macbook Pro laptops. It replaces the appletouch driver on
those computers, and integrates well with the synaptics driver of the Xorg
system.
Known to work on Macbook Air, Macbook Pro Penryn and the new unibody
Macbook 5 and Macbook Pro 5.
Usage
-----
The driver loads automatically for the supported usb device ids, and
becomes available both as an event device (/dev/input/event*) and as a
mouse via the mousedev driver (/dev/input/mice).
USB Race
--------
The Apple multi-touch trackpads report both mouse and keyboard events via
different interfaces of the same usb device. This creates a race condition
with the HID driver, which, if not told otherwise, will find the standard
HID mouse and keyboard, and claim the whole device. To remedy, the usb
product id must be listed in the mouse_ignore list of the hid driver.
Debug output
------------
To ease the development for new hardware version, verbose packet output can
be switched on with the debug kernel module parameter. The range [1-9]
yields different levels of verbosity. Example (as root):
echo -n 9 > /sys/module/bcm5974/parameters/debug
tail -f /var/log/debug
echo -n 0 > /sys/module/bcm5974/parameters/debug
Trivia
------
The driver was developed at the ubuntu forums in June 2008 [1], and now has
a more permanent home at bitmath.org [2].
Links
-----
[1] http://ubuntuforums.org/showthread.php?t=840040
[2] http://http://bitmath.org/code/
Multi-touch (MT) Protocol
-------------------------
Copyright (C) 2009 Henrik Rydberg <rydberg@euromail.se>
Introduction
------------
In order to utilize the full power of the new multi-touch devices, a way to
report detailed finger data to user space is needed. This document
describes the multi-touch (MT) protocol which allows kernel drivers to
report details for an arbitrary number of fingers.
Usage
-----
Anonymous finger details are sent sequentially as separate packets of ABS
events. Only the ABS_MT events are recognized as part of a finger
packet. The end of a packet is marked by calling the input_mt_sync()
function, which generates a SYN_MT_REPORT event. The end of multi-touch
transfer is marked by calling the usual input_sync() function.
A set of ABS_MT events with the desired properties is defined. The events
are divided into categories, to allow for partial implementation. The
minimum set consists of ABS_MT_TOUCH_MAJOR, ABS_MT_POSITION_X and
ABS_MT_POSITION_Y, which allows for multiple fingers to be tracked. If the
device supports it, the ABS_MT_WIDTH_MAJOR may be used to provide the size
of the approaching finger. Anisotropy and direction may be specified with
ABS_MT_TOUCH_MINOR, ABS_MT_WIDTH_MINOR and ABS_MT_ORIENTATION. Devices with
more granular information may specify general shapes as blobs, i.e., as a
sequence of rectangular shapes grouped together by an
ABS_MT_BLOB_ID. Finally, the ABS_MT_TOOL_TYPE may be used to specify
whether the touching tool is a finger or a pen or something else.
Event Semantics
---------------
The word "contact" is used to describe a tool which is in direct contact
with the surface. A finger, a pen or a rubber all classify as contacts.
ABS_MT_TOUCH_MAJOR
The length of the major axis of the contact. The length should be given in
surface units. If the surface has an X times Y resolution, the largest
possible value of ABS_MT_TOUCH_MAJOR is sqrt(X^2 + Y^2), the diagonal.
ABS_MT_TOUCH_MINOR
The length, in surface units, of the minor axis of the contact. If the
contact is circular, this event can be omitted.
ABS_MT_WIDTH_MAJOR
The length, in surface units, of the major axis of the approaching
tool. This should be understood as the size of the tool itself. The
orientation of the contact and the approaching tool are assumed to be the
same.
ABS_MT_WIDTH_MINOR
The length, in surface units, of the minor axis of the approaching
tool. Omit if circular.
The above four values can be used to derive additional information about
the contact. The ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR approximates
the notion of pressure. The fingers of the hand and the palm all have
different characteristic widths [1].
ABS_MT_ORIENTATION
The orientation of the ellipse. The value should describe half a revolution
clockwise around the touch center. The scale of the value is arbitrary, but
zero should be returned for an ellipse aligned along the Y axis of the
surface. As an example, an index finger placed straight onto the axis could
return zero orientation, something negative when twisted to the left, and
something positive when twisted to the right. This value can be omitted if
the touching object is circular, or if the information is not available in
the kernel driver.
ABS_MT_POSITION_X
The surface X coordinate of the center of the touching ellipse.
ABS_MT_POSITION_Y
The surface Y coordinate of the center of the touching ellipse.
ABS_MT_TOOL_TYPE
The type of approaching tool. A lot of kernel drivers cannot distinguish
between different tool types, such as a finger or a pen. In such cases, the
event should be omitted. The protocol currently supports MT_TOOL_FINGER and
MT_TOOL_PEN [2].
ABS_MT_BLOB_ID
The BLOB_ID groups several packets together into one arbitrarily shaped
contact. This is a low-level anonymous grouping, and should not be confused
with the high-level contactID, explained below. Most kernel drivers will
not have this capability, and can safely omit the event.
Finger Tracking
---------------
The kernel driver should generate an arbitrary enumeration of the set of
anonymous contacts currently on the surface. The order in which the packets
appear in the event stream is not important.
The process of finger tracking, i.e., to assign a unique contactID to each
initiated contact on the surface, is left to user space; preferably the
multi-touch X driver [3]. In that driver, the contactID stays the same and
unique until the contact vanishes (when the finger leaves the surface). The
problem of assigning a set of anonymous fingers to a set of identified
fingers is a euclidian bipartite matching problem at each event update, and
relies on a sufficiently rapid update rate.
Notes
-----
In order to stay compatible with existing applications, the data
reported in a finger packet must not be recognized as single-touch
events. In addition, all finger data must bypass input filtering,
since subsequent events of the same type refer to different fingers.
The first kernel driver to utilize the MT protocol is the bcm5974 driver,
where examples can be found.
[1] With the extension ABS_MT_APPROACH_X and ABS_MT_APPROACH_Y, the
difference between the contact position and the approaching tool position
could be used to derive tilt.
[2] The list can of course be extended.
[3] The multi-touch X driver is currently in the prototyping stage. At the
time of writing (April 2009), the MT protocol is not yet merged, and the
prototype implements finger matching, basic mouse support and two-finger
scrolling. The project aims at improving the quality of current multi-touch
functionality available in the synaptics X driver, and in addition
implement more advanced gestures.
......@@ -2,8 +2,14 @@
- this file (info on ISDN implementation for Linux)
CREDITS
- list of the kind folks that brought you this stuff.
HiSax.cert
- information about the ITU approval certification of the HiSax driver.
INTERFACE
- description of Linklevel and Hardwarelevel ISDN interface.
- description of isdn4linux Link Level and Hardware Level interfaces.
INTERFACE.fax
- description of the fax subinterface of isdn4linux.
INTERFACE.CAPI
- description of kernel CAPI Link Level to Hardware Level interface.
README
- general info on what you need and what to do for Linux ISDN.
README.FAQ
......@@ -12,6 +18,8 @@ README.audio
- info for running audio over ISDN.
README.fax
- info for using Fax over ISDN.
README.gigaset
- info on the drivers for Siemens Gigaset ISDN adapters.
README.icn
- info on the ICN-ISDN-card and its driver.
README.HiSax
......@@ -37,7 +45,8 @@ README.diversion
README.sc
- info on driver for Spellcaster cards.
README.x25
_ info for running X.25 over ISDN.
- info for running X.25 over ISDN.
README.hysdn
- info on driver for Hypercope active HYSDN cards
- info on driver for Hypercope active HYSDN cards
README.mISDN
- info on the Modular ISDN subsystem (mISDN).
Kernel CAPI Interface to Hardware Drivers
-----------------------------------------
1. Overview
From the CAPI 2.0 specification:
COMMON-ISDN-API (CAPI) is an application programming interface standard used
to access ISDN equipment connected to basic rate interfaces (BRI) and primary
rate interfaces (PRI).
Kernel CAPI operates as a dispatching layer between CAPI applications and CAPI
hardware drivers. Hardware drivers register ISDN devices (controllers, in CAPI
lingo) with Kernel CAPI to indicate their readiness to provide their service
to CAPI applications. CAPI applications also register with Kernel CAPI,
requesting association with a CAPI device. Kernel CAPI then dispatches the
application registration to an available device, forwarding it to the
corresponding hardware driver. Kernel CAPI then forwards CAPI messages in both
directions between the application and the hardware driver.
Format and semantics of CAPI messages are specified in the CAPI 2.0 standard.
This standard is freely available from http://www.capi.org.
2. Driver and Device Registration
CAPI drivers optionally register themselves with Kernel CAPI by calling the
Kernel CAPI function register_capi_driver() with a pointer to a struct
capi_driver. This structure must be filled with the name and revision of the
driver, and optionally a pointer to a callback function, add_card(). The
registration can be revoked by calling the function unregister_capi_driver()
with a pointer to the same struct capi_driver.
CAPI drivers must register each of the ISDN devices they control with Kernel
CAPI by calling the Kernel CAPI function attach_capi_ctr() with a pointer to a
struct capi_ctr before they can be used. This structure must be filled with
the names of the driver and controller, and a number of callback function
pointers which are subsequently used by Kernel CAPI for communicating with the
driver. The registration can be revoked by calling the function
detach_capi_ctr() with a pointer to the same struct capi_ctr.
Before the device can be actually used, the driver must fill in the device
information fields 'manu', 'version', 'profile' and 'serial' in the capi_ctr
structure of the device, and signal its readiness by calling capi_ctr_ready().
From then on, Kernel CAPI may call the registered callback functions for the
device.
If the device becomes unusable for any reason (shutdown, disconnect ...), the
driver has to call capi_ctr_reseted(). This will prevent further calls to the
callback functions by Kernel CAPI.
3. Application Registration and Communication
Kernel CAPI forwards registration requests from applications (calls to CAPI
operation CAPI_REGISTER) to an appropriate hardware driver by calling its
register_appl() callback function. A unique Application ID (ApplID, u16) is
allocated by Kernel CAPI and passed to register_appl() along with the
parameter structure provided by the application. This is analogous to the
open() operation on regular files or character devices.
After a successful return from register_appl(), CAPI messages from the
application may be passed to the driver for the device via calls to the
send_message() callback function. The CAPI message to send is stored in the
data portion of an skb. Conversely, the driver may call Kernel CAPI's
capi_ctr_handle_message() function to pass a received CAPI message to Kernel
CAPI for forwarding to an application, specifying its ApplID.
Deregistration requests (CAPI operation CAPI_RELEASE) from applications are
forwarded as calls to the release_appl() callback function, passing the same
ApplID as with register_appl(). After return from release_appl(), no CAPI
messages for that application may be passed to or from the device anymore.
4. Data Structures
4.1 struct capi_driver
This structure describes a Kernel CAPI driver itself. It is used in the
register_capi_driver() and unregister_capi_driver() functions, and contains
the following non-private fields, all to be set by the driver before calling
register_capi_driver():
char name[32]
the name of the driver, as a zero-terminated ASCII string
char revision[32]
the revision number of the driver, as a zero-terminated ASCII string
int (*add_card)(struct capi_driver *driver, capicardparams *data)
a callback function pointer (may be NULL)
4.2 struct capi_ctr
This structure describes an ISDN device (controller) handled by a Kernel CAPI
driver. After registration via the attach_capi_ctr() function it is passed to
all controller specific lower layer interface and callback functions to
identify the controller to operate on.
It contains the following non-private fields:
- to be set by the driver before calling attach_capi_ctr():
struct module *owner
pointer to the driver module owning the device
void *driverdata
an opaque pointer to driver specific data, not touched by Kernel CAPI
char name[32]
the name of the controller, as a zero-terminated ASCII string
char *driver_name
the name of the driver, as a zero-terminated ASCII string
int (*load_firmware)(struct capi_ctr *ctrlr, capiloaddata *ldata)
(optional) pointer to a callback function for sending firmware and
configuration data to the device
void (*reset_ctr)(struct capi_ctr *ctrlr)
pointer to a callback function for performing a reset on the device,
releasing all registered applications
void (*register_appl)(struct capi_ctr *ctrlr, u16 applid,
capi_register_params *rparam)
void (*release_appl)(struct capi_ctr *ctrlr, u16 applid)
pointers to callback functions for registration and deregistration of
applications with the device
u16 (*send_message)(struct capi_ctr *ctrlr, struct sk_buff *skb)
pointer to a callback function for sending a CAPI message to the
device
char *(*procinfo)(struct capi_ctr *ctrlr)
pointer to a callback function returning the entry for the device in
the CAPI controller info table, /proc/capi/controller
read_proc_t *ctr_read_proc
pointer to the read_proc callback function for the device's proc file
system entry, /proc/capi/controllers/<n>; will be called with a
pointer to the device's capi_ctr structure as the last (data) argument
- to be filled in before calling capi_ctr_ready():
u8 manu[CAPI_MANUFACTURER_LEN]
value to return for CAPI_GET_MANUFACTURER
capi_version version
value to return for CAPI_GET_VERSION
capi_profile profile
value to return for CAPI_GET_PROFILE
u8 serial[CAPI_SERIAL_LEN]
value to return for CAPI_GET_SERIAL
5. Lower Layer Interface Functions
(declared in <linux/isdn/capilli.h>)
void register_capi_driver(struct capi_driver *drvr)
void unregister_capi_driver(struct capi_driver *drvr)
register/unregister a driver with Kernel CAPI
int attach_capi_ctr(struct capi_ctr *ctrlr)
int detach_capi_ctr(struct capi_ctr *ctrlr)
register/unregister a device (controller) with Kernel CAPI
void capi_ctr_ready(struct capi_ctr *ctrlr)
void capi_ctr_reseted(struct capi_ctr *ctrlr)
signal controller ready/not ready
void capi_ctr_suspend_output(struct capi_ctr *ctrlr)
void capi_ctr_resume_output(struct capi_ctr *ctrlr)
signal suspend/resume
void capi_ctr_handle_message(struct capi_ctr * ctrlr, u16 applid,
struct sk_buff *skb)
pass a received CAPI message to Kernel CAPI
for forwarding to the specified application
6. Helper Functions and Macros
Library functions (from <linux/isdn/capilli.h>):
void capilib_new_ncci(struct list_head *head, u16 applid,
u32 ncci, u32 winsize)
void capilib_free_ncci(struct list_head *head, u16 applid, u32 ncci)
void capilib_release_appl(struct list_head *head, u16 applid)
void capilib_release(struct list_head *head)
void capilib_data_b3_conf(struct list_head *head, u16 applid,
u32 ncci, u16 msgid)
u16 capilib_data_b3_req(struct list_head *head, u16 applid,
u32 ncci, u16 msgid)
Macros to extract/set element values from/in a CAPI message header
(from <linux/isdn/capiutil.h>):
Get Macro Set Macro Element (Type)
CAPIMSG_LEN(m) CAPIMSG_SETLEN(m, len) Total Length (u16)
CAPIMSG_APPID(m) CAPIMSG_SETAPPID(m, applid) ApplID (u16)
CAPIMSG_COMMAND(m) CAPIMSG_SETCOMMAND(m,cmd) Command (u8)
CAPIMSG_SUBCOMMAND(m) CAPIMSG_SETSUBCOMMAND(m, cmd) Subcommand (u8)
CAPIMSG_CMD(m) - Command*256
+ Subcommand (u16)
CAPIMSG_MSGID(m) CAPIMSG_SETMSGID(m, msgid) Message Number (u16)
CAPIMSG_CONTROL(m) CAPIMSG_SETCONTROL(m, contr) Controller/PLCI/NCCI
(u32)
CAPIMSG_DATALEN(m) CAPIMSG_SETDATALEN(m, len) Data Length (u16)
......@@ -269,7 +269,10 @@ Use the argument mechanism to document members or constants.
Inside a struct description, you can use the "private:" and "public:"
comment tags. Structure fields that are inside a "private:" area
are not listed in the generated output documentation.
are not listed in the generated output documentation. The "private:"
and "public:" tags must begin immediately following a "/*" comment
marker. They may optionally include comments between the ":" and the
ending "*/" marker.
Example:
......@@ -283,7 +286,7 @@ Example:
struct my_struct {
int a;
int b;
/* private: */
/* private: internal use only */
int c;
};
......
......@@ -1620,6 +1620,8 @@ and is between 256 and 4096 characters. It is defined in the file
nowb [ARM]
nox2apic [X86-64,APIC] Do not enable x2APIC mode.
nptcg= [IA64] Override max number of concurrent global TLB
purges which is reported from either PAL_VM_SUMMARY or
SAL PALO.
......
This source diff could not be displayed because it is too large. You can view the blob instead.
Tux is taking a three month sabbatical to work as a barber, so Tuz is
standing in. He's taken pains to ensure you'll hardly notice.
This is the full-colour version of the currently unofficial Linux logo
("currently unofficial" just means that there has been no paperwork and
that I have not really announced it yet). It was created by Larry Ewing,
and is freely usable as long as you acknowledge Larry as the original
artist.
Note that there are black-and-white versions of this available that
scale down to smaller sizes and are better for letterheads or whatever
you want to use it for: for the full range of logos take a look at
Larry's web-page:
http://www.isc.tamu.edu/~lewing/linux/
Image by Andrew McGown and Josh Bush. Image is licensed CC BY-SA.
......@@ -90,6 +90,10 @@ will itself start writeback.
If dirty_bytes is written, dirty_ratio becomes a function of its value
(dirty_bytes / the amount of dirtyable system memory).
Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any
value lower than this limit will be ignored and the old configuration will be
retained.
==============================================================
dirty_expire_centisecs
......
......@@ -3448,7 +3448,7 @@ P: Matt Porter
M: mporter@kernel.crashing.org
W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
S: Maintained
LINUX FOR POWERPC EMBEDDED XILINX VIRTEX
......@@ -4189,7 +4189,7 @@ P: Joel Becker
M: joel.becker@oracle.com
L: ocfs2-devel@oss.oracle.com (moderated for non-subscribers)
W: http://oss.oracle.com/projects/ocfs2/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2.git