Merge branch 'master' into upstream

#

# This list is used by git-shortlog to fix a few botched name translations

# in the git archive, either because the author's full name was messed up

# and/or not always written the same way, making contributions from the

# same person appearing not to be so or badly displayed.

#

# repo-abbrev: /pub/scm/linux/kernel/git/

#

Aaron Durbin <adurbin@google.com>

Adam Oldham <oldhamca@gmail.com>

Adam Radford <aradford@gmail.com>

Adrian Bunk <bunk@stusta.de>

Alan Cox <alan@lxorguk.ukuu.org.uk>

Alan Cox <root@hraefn.swansea.linux.org.uk>

Aleksey Gorelov <aleksey_gorelov@phoenix.com>

Al Viro <viro@ftp.linux.org.uk>

Al Viro <viro@zenIV.linux.org.uk>

Andreas Herrmann <aherrman@de.ibm.com>

Andrew Morton <akpm@osdl.org>

Andrew Vasquez <andrew.vasquez@qlogic.com>

Andy Adamson <andros@citi.umich.edu>

Arnaud Patard <arnaud.patard@rtp-net.org>

Arnd Bergmann <arnd@arndb.de>

Axel Dyks <xl@xlsigned.net>

Ben Gardner <bgardner@wabtec.com>

Ben M Cahill <ben.m.cahill@intel.com>

Björn Steinbrink <B.Steinbrink@gmx.de>

Brian Avery <b.avery@hp.com>

Brian King <brking@us.ibm.com>

Christoph Hellwig <hch@lst.de>

Corey Minyard <minyard@acm.org>

David Brownell <david-b@pacbell.net>

David Woodhouse <dwmw2@shinybook.infradead.org>

Domen Puncer <domen@coderock.org>

Douglas Gilbert <dougg@torque.net>

Ed L. Cashin <ecashin@coraid.com>

Evgeniy Polyakov <johnpol@2ka.mipt.ru>

Felipe W Damasio <felipewd@terra.com.br>

Felix Kuhling <fxkuehl@gmx.de>

Felix Moeller <felix@derklecks.de>

Filipe Lautert <filipe@icewall.org>

Franck Bui-Huu <vagabon.xyz@gmail.com>

Frank Zago <fzago@systemfabricworks.com>

Greg Kroah-Hartman <greg@echidna.(none)>

Greg Kroah-Hartman <gregkh@suse.de>

Greg Kroah-Hartman <greg@kroah.com>

Henk Vergonet <Henk.Vergonet@gmail.com>

Henrik Kretzschmar <henne@nachtwindheim.de>

Herbert Xu <herbert@gondor.apana.org.au>

Jacob Shin <Jacob.Shin@amd.com>

James Bottomley <jejb@mulgrave.(none)>

James Bottomley <jejb@titanic.il.steeleye.com>

James E Wilson <wilson@specifix.com>

James Ketrenos <jketreno@io.(none)>

Jean Tourrilhes <jt@hpl.hp.com>

Jeff Garzik <jgarzik@pretzel.yyz.us>

Jens Axboe <axboe@suse.de>

Jens Osterkamp <Jens.Osterkamp@de.ibm.com>

John Stultz <johnstul@us.ibm.com>

Juha Yrjola <at solidboot.com>

Juha Yrjola <juha.yrjola@nokia.com>

Juha Yrjola <juha.yrjola@solidboot.com>

Kay Sievers <kay.sievers@vrfy.org>

Kenneth W Chen <kenneth.w.chen@intel.com>

Koushik <raghavendra.koushik@neterion.com>

Leonid I Ananiev <leonid.i.ananiev@intel.com>

Linas Vepstas <linas@austin.ibm.com>

Matthieu CASTET <castet.matthieu@free.fr>

Michel Dänzer <michel@tungstengraphics.com>

Mitesh shah <mshah@teja.com>

Morten Welinder <terra@gnome.org>

Morten Welinder <welinder@anemone.rentec.com>

Morten Welinder <welinder@darter.rentec.com>

Morten Welinder <welinder@troll.com>

Nguyen Anh Quynh <aquynh@gmail.com>

Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>

Patrick Mochel <mochel@digitalimplant.org>

Peter A Jonsson <pj@ludd.ltu.se>

Praveen BP <praveenbp@ti.com>

Rajesh Shah <rajesh.shah@intel.com>

Ralf Baechle <ralf@linux-mips.org>

Ralf Wildenhues <Ralf.Wildenhues@gmx.de>

Rémi Denis-Courmont <rdenis@simphalempin.com>

Rudolf Marek <R.Marek@sh.cvut.cz>

Rui Saraiva <rmps@joel.ist.utl.pt>

Sachin P Sant <ssant@in.ibm.com>

Sam Ravnborg <sam@mars.ravnborg.org>

Simon Kelley <simon@thekelleys.org.uk>

Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>

Stephen Hemminger <shemminger@osdl.org>

Tejun Heo <htejun@gmail.com>

Thomas Graf <tgraf@suug.ch>

Tony Luck <tony.luck@intel.com>

Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>

Valdis Kletnieks <Valdis.Kletnieks@vt.edu>

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

GPIOs are identified by unsigned integers in the range 0..MAX_INT.  That

reserves "negative" numbers for other purposes like marking signals as

"not available on this board", or indicating faults.

"not available on this board", or indicating faults.  Code that doesn't

touch the underlying hardware treats these integers as opaque cookies.

Platforms define how they use those integers, and usually #define symbols

for the GPIO lines so that board-specific setup code directly corresponds

The get/set calls have no error returns because "invalid GPIO" should have

been reported earlier in gpio_set_direction().  However, note that not all

platforms can read the value of output pins; those that can't should always

return zero.  Also, these calls will be ignored for GPIOs that can't safely

be accessed wihtout sleeping (see below).

return zero.  Also, using these calls for GPIOs that can't safely be accessed

without sleeping (see below) is an error.

Platform-specific implementations are encouraged to optimise the two

Platform-specific implementations are encouraged to optimize the two

calls to access the GPIO value in cases where the GPIO number (and for

output, value) are constant.  It's normal for them to need only a couple

of instructions in such cases (reading or writing a hardware register),

system wakeup capabilities.

Non-error values returned from irq_to_gpio() would most commonly be used

with gpio_get_value().

with gpio_get_value(), for example to initialize or update driver state

when the IRQ is edge-triggered.

There are other system-specific mechanisms that are not specified here,

like the aforementioned options for input de-glitching and wire-OR output.

Hardware may support reading or writing GPIOs in gangs, but that's usually

configuration dependednt:  for GPIOs sharing the same bank.  (GPIOs are

configuration dependent:  for GPIOs sharing the same bank.  (GPIOs are

commonly grouped in banks of 16 or 32, with a given SOC having several such

banks.)  Code relying on such mechanisms will necessarily be nonportable.

banks.)  Some systems can trigger IRQs from output GPIOs.  Code relying on

such mechanisms will necessarily be nonportable.

Dynamic definition of GPIOs is not currently supported; for example, as

a side effect of configuring an add-on board with some GPIO expanders.

timer_stats - timer usage statistics

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

timer_stats is a debugging facility to make the timer (ab)usage in a Linux

system visible to kernel and userspace developers. It is not intended for

production usage as it adds significant overhead to the (hr)timer code and the

(hr)timer data structures.

timer_stats should be used by kernel and userspace developers to verify that

their code does not make unduly use of timers. This helps to avoid unnecessary

wakeups, which should be avoided to optimize power consumption.

It can be enabled by CONFIG_TIMER_STATS in the "Kernel hacking" configuration

section.

timer_stats collects information about the timer events which are fired in a

Linux system over a sample period:

- the pid of the task(process) which initialized the timer

- the name of the process which initialized the timer

- the function where the timer was intialized

- the callback function which is associated to the timer

- the number of events (callbacks)

timer_stats adds an entry to /proc: /proc/timer_stats

This entry is used to control the statistics functionality and to read out the

sampled information.

The timer_stats functionality is inactive on bootup.

To activate a sample period issue:

# echo 1 >/proc/timer_stats

To stop a sample period issue:

# echo 0 >/proc/timer_stats

The statistics can be retrieved by:

# cat /proc/timer_stats

The readout of /proc/timer_stats automatically disables sampling. The sampled

information is kept until a new sample period is started. This allows multiple

readouts.

Sample output of /proc/timer_stats:

Timerstats sample period: 3.888770 s

  12,     0 swapper          hrtimer_stop_sched_tick (hrtimer_sched_tick)

  15,     1 swapper          hcd_submit_urb (rh_timer_func)

   4,   959 kedac            schedule_timeout (process_timeout)

   1,     0 swapper          page_writeback_init (wb_timer_fn)

  28,     0 swapper          hrtimer_stop_sched_tick (hrtimer_sched_tick)

  22,  2948 IRQ 4            tty_flip_buffer_push (delayed_work_timer_fn)

   3,  3100 bash             schedule_timeout (process_timeout)

   1,     1 swapper          queue_delayed_work_on (delayed_work_timer_fn)

   1,     1 swapper          queue_delayed_work_on (delayed_work_timer_fn)

   1,     1 swapper          neigh_table_init_no_netlink (neigh_periodic_timer)

   1,  2292 ip               __netdev_watchdog_up (dev_watchdog)

   1,    23 events/1         do_cache_clean (delayed_work_timer_fn)

90 total events, 30.0 events/sec

The first column is the number of events, the second column the pid, the third

column is the name of the process. The forth column shows the function which

initialized the timer and in parantheses the callback function which was

executed on expiry.

    Thomas, Ingo

High resolution timers and dynamic ticks design notes

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

Further information can be found in the paper of the OLS 2006 talk "hrtimers

and beyond". The paper is part of the OLS 2006 Proceedings Volume 1, which can

be found on the OLS website:

http://www.linuxsymposium.org/2006/linuxsymposium_procv1.pdf

The slides to this talk are available from:

http://tglx.de/projects/hrtimers/ols2006-hrtimers.pdf

The slides contain five figures (pages 2, 15, 18, 20, 22), which illustrate the

changes in the time(r) related Linux subsystems. Figure #1 (p. 2) shows the

design of the Linux time(r) system before hrtimers and other building blocks

got merged into mainline.

Note: the paper and the slides are talking about "clock event source", while we

switched to the name "clock event devices" in meantime.

The design contains the following basic building blocks:

- hrtimer base infrastructure

- timeofday and clock source management

- clock event management

- high resolution timer functionality

- dynamic ticks

hrtimer base infrastructure

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

The hrtimer base infrastructure was merged into the 2.6.16 kernel. Details of

the base implementation are covered in Documentation/hrtimers/hrtimer.txt. See

also figure #2 (OLS slides p. 15)

The main differences to the timer wheel, which holds the armed timer_list type

timers are:

       - time ordered enqueueing into a rb-tree

       - independent of ticks (the processing is based on nanoseconds)

timeofday and clock source management

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

John Stultz's Generic Time Of Day (GTOD) framework moves a large portion of

code out of the architecture-specific areas into a generic management

framework, as illustrated in figure #3 (OLS slides p. 18). The architecture

specific portion is reduced to the low level hardware details of the clock

sources, which are registered in the framework and selected on a quality based

decision. The low level code provides hardware setup and readout routines and

initializes data structures, which are used by the generic time keeping code to

convert the clock ticks to nanosecond based time values. All other time keeping

related functionality is moved into the generic code. The GTOD base patch got

merged into the 2.6.18 kernel.

Further information about the Generic Time Of Day framework is available in the

OLS 2005 Proceedings Volume 1:

http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf

The paper "We Are Not Getting Any Younger: A New Approach to Time and

Timers" was written by J. Stultz, D.V. Hart, & N. Aravamudan.

Figure #3 (OLS slides p.18) illustrates the transformation.

clock event management

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

While clock sources provide read access to the monotonically increasing time

value, clock event devices are used to schedule the next event

interrupt(s). The next event is currently defined to be periodic, with its

period defined at compile time. The setup and selection of the event device

for various event driven functionalities is hardwired into the architecture

dependent code. This results in duplicated code across all architectures and

makes it extremely difficult to change the configuration of the system to use

event interrupt devices other than those already built into the

architecture. Another implication of the current design is that it is necessary

to touch all the architecture-specific implementations in order to provide new

functionality like high resolution timers or dynamic ticks.

The clock events subsystem tries to address this problem by providing a generic

solution to manage clock event devices and their usage for the various clock

event driven kernel functionalities. The goal of the clock event subsystem is

to minimize the clock event related architecture dependent code to the pure

hardware related handling and to allow easy addition and utilization of new

clock event devices. It also minimizes the duplicated code across the

architectures as it provides generic functionality down to the interrupt

service handler, which is almost inherently hardware dependent.

Clock event devices are registered either by the architecture dependent boot

code or at module insertion time. Each clock event device fills a data

structure with clock-specific property parameters and callback functions. The

clock event management decides, by using the specified property parameters, the

set of system functions a clock event device will be used to support. This

includes the distinction of per-CPU and per-system global event devices.

System-level global event devices are used for the Linux periodic tick. Per-CPU

event devices are used to provide local CPU functionality such as process

accounting, profiling, and high resolution timers.

The management layer assignes one or more of the folliwing functions to a clock

event device:

      - system global periodic tick (jiffies update)

      - cpu local update_process_times

      - cpu local profiling

      - cpu local next event interrupt (non periodic mode)

The clock event device delegates the selection of those timer interrupt related

functions completely to the management layer. The clock management layer stores

a function pointer in the device description structure, which has to be called

from the hardware level handler. This removes a lot of duplicated code from the

architecture specific timer interrupt handlers and hands the control over the

clock event devices and the assignment of timer interrupt related functionality

to the core code.

The clock event layer API is rather small. Aside from the clock event device

registration interface it provides functions to schedule the next event

interrupt, clock event device notification service and support for suspend and

resume.

The framework adds about 700 lines of code which results in a 2KB increase of

the kernel binary size. The conversion of i386 removes about 100 lines of

code. The binary size decrease is in the range of 400 byte. We believe that the

increase of flexibility and the avoidance of duplicated code across

architectures justifies the slight increase of the binary size.

The conversion of an architecture has no functional impact, but allows to

utilize the high resolution and dynamic tick functionalites without any change

to the clock event device and timer interrupt code. After the conversion the

enabling of high resolution timers and dynamic ticks is simply provided by

adding the kernel/time/Kconfig file to the architecture specific Kconfig and

adding the dynamic tick specific calls to the idle routine (a total of 3 lines

added to the idle function and the Kconfig file)

Figure #4 (OLS slides p.20) illustrates the transformation.

high resolution timer functionality

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

During system boot it is not possible to use the high resolution timer

functionality, while making it possible would be difficult and would serve no

useful function. The initialization of the clock event device framework, the

clock source framework (GTOD) and hrtimers itself has to be done and

appropriate clock sources and clock event devices have to be registered before

the high resolution functionality can work. Up to the point where hrtimers are

initialized, the system works in the usual low resolution periodic mode. The

clock source and the clock event device layers provide notification functions

which inform hrtimers about availability of new hardware. hrtimers validates

the usability of the registered clock sources and clock event devices before

switching to high resolution mode. This ensures also that a kernel which is

configured for high resolution timers can run on a system which lacks the

necessary hardware support.

The high resolution timer code does not support SMP machines which have only

global clock event devices. The support of such hardware would involve IPI

calls when an interrupt happens. The overhead would be much larger than the

benefit. This is the reason why we currently disable high resolution and

dynamic ticks on i386 SMP systems which stop the local APIC in C3 power

state. A workaround is available as an idea, but the problem has not been

tackled yet.

The time ordered insertion of timers provides all the infrastructure to decide

whether the event device has to be reprogrammed when a timer is added. The

decision is made per timer base and synchronized across per-cpu timer bases in

a support function. The design allows the system to utilize separate per-CPU

clock event devices for the per-CPU timer bases, but currently only one

reprogrammable clock event device per-CPU is utilized.

When the timer interrupt happens, the next event interrupt handler is called

from the clock event distribution code and moves expired timers from the

red-black tree to a separate double linked list and invokes the softirq

handler. An additional mode field in the hrtimer structure allows the system to

execute callback functions directly from the next event interrupt handler. This

is restricted to code which can safely be executed in the hard interrupt

context. This applies, for example, to the common case of a wakeup function as

used by nanosleep. The advantage of executing the handler in the interrupt

context is the avoidance of up to two context switches - from the interrupted

context to the softirq and to the task which is woken up by the expired

timer.

Once a system has switched to high resolution mode, the periodic tick is

switched off. This disables the per system global periodic clock event device -

e.g. the PIT on i386 SMP systems.

The periodic tick functionality is provided by an per-cpu hrtimer. The callback

function is executed in the next event interrupt context and updates jiffies

and calls update_process_times and profiling. The implementation of the hrtimer

based periodic tick is designed to be extended with dynamic tick functionality.

This allows to use a single clock event device to schedule high resolution

timer and periodic events (jiffies tick, profiling, process accounting) on UP

systems. This has been proved to work with the PIT on i386 and the Incrementer

on PPC.

The softirq for running the hrtimer queues and executing the callbacks has been

separated from the tick bound timer softirq to allow accurate delivery of high

resolution timer signals which are used by itimer and POSIX interval

timers. The execution of this softirq can still be delayed by other softirqs,

but the overall latencies have been significantly improved by this separation.

Figure #5 (OLS slides p.22) illustrates the transformation.

dynamic ticks

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

Dynamic ticks are the logical consequence of the hrtimer based periodic tick

replacement (sched_tick). The functionality of the sched_tick hrtimer is

extended by three functions:

- hrtimer_stop_sched_tick

- hrtimer_restart_sched_tick

- hrtimer_update_jiffies

hrtimer_stop_sched_tick() is called when a CPU goes into idle state. The code

evaluates the next scheduled timer event (from both hrtimers and the timer

wheel) and in case that the next event is further away than the next tick it

reprograms the sched_tick to this future event, to allow longer idle sleeps

without worthless interruption by the periodic tick. The function is also

called when an interrupt happens during the idle period, which does not cause a

reschedule. The call is necessary as the interrupt handler might have armed a

new timer whose expiry time is before the time which was identified as the

nearest event in the previous call to hrtimer_stop_sched_tick.

hrtimer_restart_sched_tick() is called when the CPU leaves the idle state before

it calls schedule(). hrtimer_restart_sched_tick() resumes the periodic tick,

which is kept active until the next call to hrtimer_stop_sched_tick().

hrtimer_update_jiffies() is called from irq_enter() when an interrupt happens

in the idle period to make sure that jiffies are up to date and the interrupt

handler has not to deal with an eventually stale jiffy value.

The dynamic tick feature provides statistical values which are exported to

userspace via /proc/stats and can be made available for enhanced power

management control.

The implementation leaves room for further development like full tickless

systems, where the time slice is controlled by the scheduler, variable

frequency profiling, and a complete removal of jiffies in the future.

Aside the current initial submission of i386 support, the patchset has been

extended to x86_64 and ARM already. Initial (work in progress) support is also

available for MIPS and PowerPC.

	  Thomas, Ingo