Merge branch 'linus' into tracing/core

###

# The targets that may be used.

PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs

PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs

BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))

xmldocs: $(BOOKS)

dochelp:

	@echo  ' Linux kernel internal documentation in different formats:'

	@echo  '  htmldocs        - HTML'

	@echo  '  installmandocs  - install man pages generated by mandocs'

	@echo  '  mandocs         - man pages'

	@echo  '  pdfdocs         - PDF'

	@echo  '  psdocs          - Postscript'

	@echo  '  xmldocs         - XML DocBook'

	@echo  '  mandocs         - man pages'

	@echo  '  installmandocs  - install man pages generated by mandocs'

	@echo  '  cleandocs       - clean all generated DocBook files'

###

# Temporary files left by various tools

clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man

cleandocs:

	$(Q)rm -f $(call objectify, $(clean-files))

	$(Q)rm -rf $(call objectify, $(clean-dirs))

# Declare the contents of the .PHONY variable as phony.  We keep that

# information in a variable se we can use it in if_changed and friends.

	After a reasonable transition period, we will remove the legacy

	fakephp interface.

Who:	Alex Chiang <achiang@hp.com>

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

What:	i2c-voodoo3 driver

When:	October 2009

Why:	Superseded by tdfxfb. I2C/DDC support used to live in a separate

	driver but this caused driver conflicts.

Who:	Jean Delvare <khali@linux-fr.org>

	Krzysztof Helt <krzysztof.h1@wp.pl>

  The P_Key for any interface is given by the "pkey" file, and the

  main interface for a subinterface is in "parent."

Datagram vs Connected modes

  The IPoIB driver supports two modes of operation: datagram and

  connected.  The mode is set and read through an interface's

  /sys/class/net/<intf name>/mode file.

  In datagram mode, the IB UD (Unreliable Datagram) transport is used

  and so the interface MTU has is equal to the IB L2 MTU minus the

  IPoIB encapsulation header (4 bytes).  For example, in a typical IB

  fabric with a 2K MTU, the IPoIB MTU will be 2048 - 4 = 2044 bytes.

  In connected mode, the IB RC (Reliable Connected) transport is used.

  Connected mode is to takes advantage of the connected nature of the

  IB transport and allows an MTU up to the maximal IP packet size of

  64K, which reduces the number of IP packets needed for handling

  large UDP datagrams, TCP segments, etc and increases the performance

  for large messages.

  In connected mode, the interface's UD QP is still used for multicast

  and communication with peers that don't support connected mode. In

  this case, RX emulation of ICMP PMTU packets is used to cause the

  networking stack to use the smaller UD MTU for these neighbours.

Stateless offloads

  If the IB HW supports IPoIB stateless offloads, IPoIB advertises

  TCP/IP checksum and/or Large Send (LSO) offloading capability to the

  network stack.

  Large Receive (LRO) offloading is also implemented and may be turned

  on/off using ethtool calls.  Currently LRO is supported only for

  checksum offload capable devices.

  Stateless offloads are supported only in datagram mode.  

Interrupt moderation

  If the underlying IB device supports CQ event moderation, one can

  use ethtool to set interrupt mitigation parameters and thus reduce

  the overhead incurred by handling interrupts.  The main code path of

  IPoIB doesn't use events for TX completion signaling so only RX

  moderation is supported.

Debugging Information

  By compiling the IPoIB driver with CONFIG_INFINIBAND_IPOIB_DEBUG set

    http://ietf.org/rfc/rfc4391.txt 

  IP over InfiniBand (IPoIB) Architecture (RFC 4392)

    http://ietf.org/rfc/rfc4392.txt 

  IP over InfiniBand: Connected Mode (RFC 4755)

    http://ietf.org/rfc/rfc4755.txt

rotary-encoder - a generic driver for GPIO connected devices

Daniel Mack <daniel@caiaq.de>, Feb 2009

0. Function

-----------

Rotary encoders are devices which are connected to the CPU or other

peripherals with two wires. The outputs are phase-shifted by 90 degrees

and by triggering on falling and rising edges, the turn direction can

be determined.

The phase diagram of these two outputs look like this:

                  _____       _____       _____

                 |     |     |     |     |     |

  Channel A  ____|     |_____|     |_____|     |____

                 :  :  :  :  :  :  :  :  :  :  :  :

            __       _____       _____       _____

              |     |     |     |     |     |     |

  Channel B   |_____|     |_____|     |_____|     |__

                 :  :  :  :  :  :  :  :  :  :  :  :

  Event          a  b  c  d  a  b  c  d  a  b  c  d

                |<-------->|

	          one step

For more information, please see

	http://en.wikipedia.org/wiki/Rotary_encoder

1. Events / state machine

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

a) Rising edge on channel A, channel B in low state

	This state is used to recognize a clockwise turn

b) Rising edge on channel B, channel A in high state

	When entering this state, the encoder is put into 'armed' state,

	meaning that there it has seen half the way of a one-step transition.

c) Falling edge on channel A, channel B in high state

	This state is used to recognize a counter-clockwise turn

d) Falling edge on channel B, channel A in low state

	Parking position. If the encoder enters this state, a full transition

	should have happend, unless it flipped back on half the way. The

	'armed' state tells us about that.

2. Platform requirements

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

As there is no hardware dependent call in this driver, the platform it is

used with must support gpiolib. Another requirement is that IRQs must be

able to fire on both edges.

3. Board integration

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

To use this driver in your system, register a platform_device with the

name 'rotary-encoder' and associate the IRQs and some specific platform

data with it.

struct rotary_encoder_platform_data is declared in

include/linux/rotary-encoder.h and needs to be filled with the number of

steps the encoder has and can carry information about externally inverted

signals (because of used invertig buffer or other reasons).

Because GPIO to IRQ mapping is platform specific, this information must

be given in seperately to the driver. See the example below.

---------<snip>---------

/* board support file example */

#include <linux/input.h>

#include <linux/rotary_encoder.h>

#define GPIO_ROTARY_A 1

#define GPIO_ROTARY_B 2

static struct rotary_encoder_platform_data my_rotary_encoder_info = {

	.steps		= 24,

	.axis		= ABS_X,

	.gpio_a		= GPIO_ROTARY_A,

	.gpio_b		= GPIO_ROTARY_B,

	.inverted_a	= 0,

	.inverted_b	= 0,

};

static struct platform_device rotary_encoder_device = {

	.name		= "rotary-encoder",

	.id		= 0,

	.dev		= {

		.platform_data = &my_rotary_encoder_info,

	}

};

	   --- 6.7 Custom kbuild commands

	   --- 6.8 Preprocessing linker scripts

	=== 7 Kbuild Variables

	=== 8 Makefile language

	=== 9 Credits

	=== 10 TODO

	=== 7 Kbuild syntax for exported headers

		--- 7.1 header-y

		--- 7.2 objhdr-y

		--- 7.3 destination-y

		--- 7.4 unifdef-y (deprecated)

	=== 8 Kbuild Variables

	=== 9 Makefile language

	=== 10 Credits

	=== 11 TODO

=== 1 Overview

	The kbuild infrastructure for *lds file are used in several

	architecture-specific files.

=== 7 Kbuild syntax for exported headers

The kernel include a set of headers that is exported to userspace.

Many headers can be exported as-is but other headers requires  a

minimal pre-processing before they are ready for user-space.

The pre-processing does:

- drop kernel specific annotations

- drop include of compiler.h

- drop all sections that is kernel internat (guarded by ifdef __KERNEL__)

Each relevant directory contain a file name "Kbuild" which specify the

headers to be exported.

See subsequent chapter for the syntax of the Kbuild file.

	--- 7.1 header-y

	header-y specify header files to be exported.

		Example:

			#include/linux/Kbuild

			header-y += usb/

			header-y += aio_abi.h

	The convention is to list one file per line and

	preferably in alphabetic order.

	header-y also specify which subdirectories to visit.

	A subdirectory is identified by a trailing '/' which

	can be seen in the example above for the usb subdirectory.

	Subdirectories are visited before their parent directories.

	--- 7.2 objhdr-y

	objhdr-y specifies generated files to be exported.

	Generated files are special as they need to be looked

	up in another directory when doing 'make O=...' builds.

		Example:

			#include/linux/Kbuild

			objhdr-y += version.h

	--- 7.3 destination-y

	When an architecture have a set of exported headers that needs to be

	exported to a different directory destination-y is used.

	destination-y specify the destination directory for all exported

	headers in the file where it is present.

		Example:

			#arch/xtensa/platforms/s6105/include/platform/Kbuild

			destination-y := include/linux

	In the example above all exported headers in the Kbuild file

	will be located in the directory "include/linux" when exported.

	--- 7.4 unifdef-y (deprecated)

	unifdef-y is deprecated. A direct replacement is header-y.

=== 7 Kbuild Variables

=== 8 Kbuild Variables

The top Makefile exports the following variables:

	INSTALL_MOD_STRIP will used as the option(s) to the strip command.

=== 8 Makefile language

=== 9 Makefile language

The kernel Makefiles are designed to be run with GNU Make.  The Makefiles

use only the documented features of GNU Make, but they do use many

There are some cases where "=" is appropriate.  Usually, though, ":="

is the right choice.

=== 9 Credits

=== 10 Credits

Original version made by Michael Elizabeth Chastain, <mailto:mec@shout.net>

Updates by Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>

Updates by Sam Ravnborg <sam@ravnborg.org>

Language QA by Jan Engelhardt <jengelh@gmx.de>

=== 10 TODO

=== 11 TODO

- Describe how kbuild supports shipped files with _shipped.

- Generating offset header files.