Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

###

# 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.

process (bash) into it. CPU time consumed by this bash and its children

can be obtained from g1/cpuacct.usage and the same is accumulated in

/cgroups/cpuacct.usage also.

cpuacct.stat file lists a few statistics which further divide the

CPU time obtained by the cgroup into user and system times. Currently

the following statistics are supported:

user: Time spent by tasks of the cgroup in user mode.

system: Time spent by tasks of the cgroup in kernel mode.

user and system are in USER_HZ unit.

cpuacct controller uses percpu_counter interface to collect user and

system times. This has two side effects:

- It is theoretically possible to see wrong values for user and system times.

  This is because percpu_counter_read() on 32bit systems isn't safe

  against concurrent writes.

- It is possible to see slightly outdated values for user and system times

  due to the batch processing nature of percpu_counter.

	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,

	}

};