Merge branch 'master' into for-next

	- directory with DocBook templates etc. for kernel documentation.

HOWTO

	- the process and procedures of how to do Linux kernel development.

IO-mapping.txt

	- how to access I/O mapped memory from within device drivers.

IPMI.txt

	- info on Linux Intelligent Platform Management Interface (IPMI) Driver.

IRQ-affinity.txt

	- info on block devices & drivers

btmrvl.txt

	- info on Marvell Bluetooth driver usage.

bus-virt-phys-mapping.txt

	- how to access I/O mapped memory from within device drivers.

cachetlb.txt

	- describes the cache/TLB flushing interfaces Linux uses.

cdrom/

	- how to use the RAM disk as an initial/temporary root filesystem.

input/

	- info on Linux input device support.

io-mapping.txt

	- description of io_mapping functions in linux/io-mapping.h

io_ordering.txt

	- info on ordering I/O writes to memory-mapped addresses.

ioctl/

fffe0000	fffeffff	XScale cache flush area.  This is used

				in proc-xscale.S to flush the whole data

				cache.  Free for other usage on non-XScale.

				cache. (XScale does not have TCM.)

fffe8000	fffeffff	DTCM mapping area for platforms with

				DTCM mounted inside the CPU.

fffe0000	fffe7fff	ITCM mapping area for platforms with

				ITCM mounted inside the CPU.

fff00000	fffdffff	Fixmap mapping region.  Addresses provided

				by fix_to_virt() will be located here.

system control coprocessor. Documentation from ARM can be found

at http://infocenter.arm.com, search for "TCM Status Register"

to see documents for all CPUs. Reading this register you can

determine if ITCM (bit 0) and/or DTCM (bit 16) is present in the

machine.

determine if ITCM (bits 1-0) and/or DTCM (bit 17-16) is present

in the machine.

There is further a TCM region register (search for "TCM Region

Registers" at the ARM site) that can report and modify the location

the MMU, but notice that the TCM if often used in situations where

the MMU is turned off. To avoid confusion the current Linux

implementation will map the TCM 1 to 1 from physical to virtual

memory in the location specified by the machine.

memory in the location specified by the kernel. Currently Linux

will map ITCM to 0xfffe0000 and on, and DTCM to 0xfffe8000 and

on, supporting a maximum of 32KiB of ITCM and 32KiB of DTCM.

Newer versions of the region registers also support dividing these

TCMs in two separate banks, so for example an 8KiB ITCM is divided

into two 4KiB banks with its own control registers. The idea is to

be able to lock and hide one of the banks for use by the secure

world (TrustZone).

TCM is used for a few things:

  memory. Such a heap is great for things like saving

  device state when shutting off device power domains.

A machine that has TCM memory shall select HAVE_TCM in

arch/arm/Kconfig for itself, and then the

rest of the functionality will depend on the physical

location and size of ITCM and DTCM to be defined in

mach/memory.h for the machine. Code that needs to use

TCM shall #include <asm/tcm.h> If the TCM is not located

at the place given in memory.h it will be moved using

the TCM Region registers.

A machine that has TCM memory shall select HAVE_TCM from

arch/arm/Kconfig for itself. Code that needs to use TCM shall

#include <asm/tcm.h>

Functions to go into itcm can be tagged like this:

int __tcmfunc foo(int bar);

Since these are marked to become long_calls and you may want

to have functions called locally inside the TCM without

wasting space, there is also the __tcmlocalfunc prefix that

will make the call relative.

Variables to go into dtcm can be tagged like this:

int __tcmdata foo;

This does all the RCU magic inside of it.  The caller must call put_cred() on

the credentials so obtained when they're finished with.

 [*] Note: The result of __task_cred() should not be passed directly to

     get_cred() as this may race with commit_cred().

There are a couple of convenience functions to access bits of another task's

credentials, hiding the RCU magic from the caller: