diff options
Diffstat (limited to 'Documentation/arm')
24 files changed, 517 insertions, 42 deletions
diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX index 82e418d648d0..7f5fc3ba9c91 100644 --- a/Documentation/arm/00-INDEX +++ b/Documentation/arm/00-INDEX @@ -20,6 +20,8 @@ Samsung-S3C24XX - S3C24XX ARM Linux Overview Sharp-LH - Linux on Sharp LH79524 and LH7A40X System On a Chip (SOC) +SPEAr + - ST SPEAr platform Linux Overview VFP/ - Release notes for Linux Kernel Vector Floating Point support code empeg/ diff --git a/Documentation/arm/IXP2000 b/Documentation/arm/IXP2000 index e0148b6b2c40..68d21d92a30b 100644 --- a/Documentation/arm/IXP2000 +++ b/Documentation/arm/IXP2000 @@ -14,7 +14,7 @@ telecom systems. In addition to an XScale core, it contains up to 8 interfaces (UTOPIA, SPI, etc), a PCI host bridge, one serial port, flash interface, and some other odds and ends. For more information, see: -http://developer.intel.com/design/network/products/npfamily/ixp2xxx.htm +http://developer.intel.com 2. Linux Support diff --git a/Documentation/arm/IXP4xx b/Documentation/arm/IXP4xx index 72fbcc4fcab0..133c5fa6c7a1 100644 --- a/Documentation/arm/IXP4xx +++ b/Documentation/arm/IXP4xx @@ -45,7 +45,7 @@ require the use of Intel's propietary CSR softare: If you need to use any of the above, you need to download Intel's software from: - http://developer.intel.com/design/network/products/npfamily/ixp425swr1.htm + http://developer.intel.com/design/network/products/npfamily/ixp425.htm DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPIETARY SOFTWARE. @@ -53,7 +53,7 @@ SOFTWARE. There are several websites that provide directions/pointers on using Intel's software: -http://ixp4xx-osdg.sourceforge.net/ + http://sourceforge.net/projects/ixp4xx-osdg/ Open Source Developer's Guide for using uClinux and the Intel libraries http://gatewaymaker.sourceforge.net/ @@ -112,21 +112,21 @@ http://www.adiengineering.com/productsCoyote.html Finally, there is an IDE port hanging off the expansion bus. Gateworks Avila Network Platform -http://www.gateworks.com/avila_sbc.htm +http://www.gateworks.com/support/overview.php The Avila platform is basically and IXDP425 with the 4 PCI slots replaced with mini-PCI slots and a CF IDE interface hanging off the expansion bus. Intel IXDP425 Development Platform -http://developer.intel.com/design/network/products/npfamily/ixdp425.htm +http://www.intel.com/design/network/products/npfamily/ixdpg425.htm This is Intel's standard reference platform for the IXDP425 and is also known as the Richfield board. It contains 4 PCI slots, 16MB of flash, two 10/100 ports and one ADSL port. Intel IXDP465 Development Platform -http://developer.intel.com/design/network/products/npfamily/ixdp465.htm +http://www.intel.com/design/network/products/npfamily/ixdp465.htm This is basically an IXDP425 with an IXP465 and 32M of flash instead of just 16. @@ -141,15 +141,13 @@ Intel IXDPG425 Development Platform a pivot_root to NFS. Motorola PrPMC1100 Processor Mezanine Card -http://www.fountainsys.com/datasheet/PrPMC1100.pdf +http://www.fountainsys.com The PrPMC1100 is based on the IXCP1100 and is meant to plug into and IXP2400/2800 system to act as the system controller. It simply contains a CPU and 16MB of flash on the board and needs to be plugged into a carrier board to function. Currently Linux only supports the Motorola PrPMC carrier board for this platform. - See https://mcg.motorola.com/us/ds/pdf/ds0144.pdf for info - on the carrier board. 5. TODO LIST diff --git a/Documentation/arm/README b/Documentation/arm/README index d98783fbe0c7..aea34095cdcf 100644 --- a/Documentation/arm/README +++ b/Documentation/arm/README @@ -41,12 +41,12 @@ Bug reports etc --------------- Please send patches to the patch system. For more information, see - http://www.arm.linux.org.uk/patches/info.html Always include some + http://www.arm.linux.org.uk/developer/patches/info.php Always include some explanation as to what the patch does and why it is needed. Bug reports should be sent to linux-arm-kernel@lists.arm.linux.org.uk, or submitted through the web form at - http://www.arm.linux.org.uk/forms/solution.shtml + http://www.arm.linux.org.uk/developer/ When sending bug reports, please ensure that they contain all relevant information, eg. the kernel messages that were printed before/during diff --git a/Documentation/arm/SA1100/ADSBitsy b/Documentation/arm/SA1100/ADSBitsy index 7197a9e958ee..f9f62e8c0719 100644 --- a/Documentation/arm/SA1100/ADSBitsy +++ b/Documentation/arm/SA1100/ADSBitsy @@ -32,7 +32,7 @@ Notes: - The flash on board is divided into 3 partitions. You should be careful to use flash on board. - It's partition is different from GraphicsClient Plus and GraphicsMaster + Its partition is different from GraphicsClient Plus and GraphicsMaster - 16bpp mode requires a different cable than what ships with the board. Contact ADS or look through the manual to wire your own. Currently, diff --git a/Documentation/arm/SA1100/Assabet b/Documentation/arm/SA1100/Assabet index 91f7ce7ba426..08b885d35674 100644 --- a/Documentation/arm/SA1100/Assabet +++ b/Documentation/arm/SA1100/Assabet @@ -2,8 +2,7 @@ The Intel Assabet (SA-1110 evaluation) board ============================================ Please see: -http://developer.intel.com/design/strong/quicklist/eval-plat/sa-1110.htm -http://developer.intel.com/design/strong/guides/278278.htm +http://developer.intel.com Also some notes from John G Dorsey <jd5q@andrew.cmu.edu>: http://www.cs.cmu.edu/~wearable/software/assabet.html @@ -64,7 +63,7 @@ Initial RedBoot configuration ----------------------------- The commands used here are explained in The RedBoot User's Guide available -on-line at http://sources.redhat.com/ecos/docs-latest/redboot/redboot.html. +on-line at http://sources.redhat.com/ecos/docs.html. Please refer to it for explanations. If you have a CF network card (my Assabet kit contained a CF+ LP-E from diff --git a/Documentation/arm/SA1100/Brutus b/Documentation/arm/SA1100/Brutus index b1cfd405dccc..6a3aa95e9bfd 100644 --- a/Documentation/arm/SA1100/Brutus +++ b/Documentation/arm/SA1100/Brutus @@ -1,7 +1,7 @@ Brutus is an evaluation platform for the SA1100 manufactured by Intel. For more details, see: -http://developer.intel.com/design/strong/applnots/sa1100lx/getstart.htm +http://developer.intel.com To compile for Brutus, you must issue the following commands: diff --git a/Documentation/arm/SA1100/FreeBird b/Documentation/arm/SA1100/FreeBird index eda28b3232e7..fb23b770aaf4 100644 --- a/Documentation/arm/SA1100/FreeBird +++ b/Documentation/arm/SA1100/FreeBird @@ -1,5 +1,5 @@ Freebird-1.1 is produced by Legned(C) ,Inc. -(http://www.legend.com.cn) +http://web.archive.org/web/*/http://www.legend.com.cn and software/linux mainatined by Coventive(C),Inc. (http://www.coventive.com) diff --git a/Documentation/arm/SA1100/GraphicsClient b/Documentation/arm/SA1100/GraphicsClient index 6c9c4f5a36e1..867bb35943af 100644 --- a/Documentation/arm/SA1100/GraphicsClient +++ b/Documentation/arm/SA1100/GraphicsClient @@ -71,7 +71,7 @@ Supported peripherals: - serial ports (ttyS[0-2]) - ttyS0 is default for serial console - Smart I/O (ADC, keypad, digital inputs, etc) - See http://www.applieddata.com/developers/linux for IOCTL documentation + See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation and example user space code. ps/2 keybd is multiplexed through this driver To do: diff --git a/Documentation/arm/SA1100/GraphicsMaster b/Documentation/arm/SA1100/GraphicsMaster index ee7c6595f23f..9145088a0ba2 100644 --- a/Documentation/arm/SA1100/GraphicsMaster +++ b/Documentation/arm/SA1100/GraphicsMaster @@ -28,7 +28,7 @@ Supported peripherals: - serial ports (ttyS[0-2]) - ttyS0 is default for serial console - Smart I/O (ADC, keypad, digital inputs, etc) - See http://www.applieddata.com/developers/linux for IOCTL documentation + See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation and example user space code. ps/2 keybd is multiplexed through this driver To do: diff --git a/Documentation/arm/SA1100/Itsy b/Documentation/arm/SA1100/Itsy index 3b594534323b..44b94997fa0d 100644 --- a/Documentation/arm/SA1100/Itsy +++ b/Documentation/arm/SA1100/Itsy @@ -4,7 +4,7 @@ research projects at Compaq that are related to pocket computing. For more information, see: - http://www.research.digital.com/wrl/itsy/index.html + http://www.hpl.hp.com/downloads/crl/itsy/ Notes on initial 2.4 Itsy support (8/27/2000) : The port was done on an Itsy version 1.5 machine with a daughtercard with diff --git a/Documentation/arm/SA1100/PLEB b/Documentation/arm/SA1100/PLEB index 92cae066908d..b9c8a631a351 100644 --- a/Documentation/arm/SA1100/PLEB +++ b/Documentation/arm/SA1100/PLEB @@ -6,6 +6,6 @@ PLEB support has yet to be fully integrated. For more information, see: - http://www.cse.unsw.edu.au/~pleb/ + http://www.cse.unsw.edu.au diff --git a/Documentation/arm/SA1100/Victor b/Documentation/arm/SA1100/Victor index f938a29fdc20..9cff415da5a7 100644 --- a/Documentation/arm/SA1100/Victor +++ b/Documentation/arm/SA1100/Victor @@ -3,7 +3,7 @@ VisuAide, Inc. to be used by blind people. For more information related to Victor, see: - http://www.visuaide.com/victor + http://www.humanware.com/en-usa/products Of course Victor is using Linux as its main operating system. The Victor implementation for Linux is maintained by Nicolas Pitre: diff --git a/Documentation/arm/SA1100/nanoEngine b/Documentation/arm/SA1100/nanoEngine index fc431cbfefc2..48a7934f95f6 100644 --- a/Documentation/arm/SA1100/nanoEngine +++ b/Documentation/arm/SA1100/nanoEngine @@ -7,5 +7,5 @@ for more info. (Ref: Stuart Adams <sja@brightstareng.com>) Also visit Larry Doolittle's "Linux for the nanoEngine" site: -http://recycle.lbl.gov/~ldoolitt/bse/ +http://www.brightstareng.com/arm/nanoeng.htm diff --git a/Documentation/arm/SPEAr/overview.txt b/Documentation/arm/SPEAr/overview.txt new file mode 100644 index 000000000000..253a35c6f782 --- /dev/null +++ b/Documentation/arm/SPEAr/overview.txt @@ -0,0 +1,60 @@ + SPEAr ARM Linux Overview + ========================== + +Introduction +------------ + + SPEAr (Structured Processor Enhanced Architecture). + weblink : http://www.st.com/spear + + The ST Microelectronics SPEAr range of ARM9/CortexA9 System-on-Chip CPUs are + supported by the 'spear' platform of ARM Linux. Currently SPEAr300, + SPEAr310, SPEAr320 and SPEAr600 SOCs are supported. Support for the SPEAr13XX + series is in progress. + + Hierarchy in SPEAr is as follows: + + SPEAr (Platform) + - SPEAr3XX (3XX SOC series, based on ARM9) + - SPEAr300 (SOC) + - SPEAr300_EVB (Evaluation Board) + - SPEAr310 (SOC) + - SPEAr310_EVB (Evaluation Board) + - SPEAr320 (SOC) + - SPEAr320_EVB (Evaluation Board) + - SPEAr6XX (6XX SOC series, based on ARM9) + - SPEAr600 (SOC) + - SPEAr600_EVB (Evaluation Board) + - SPEAr13XX (13XX SOC series, based on ARM CORTEXA9) + - SPEAr1300 (SOC) + + Configuration + ------------- + + A generic configuration is provided for each machine, and can be used as the + default by + make spear600_defconfig + make spear300_defconfig + make spear310_defconfig + make spear320_defconfig + + Layout + ------ + + The common files for multiple machine families (SPEAr3XX, SPEAr6XX and + SPEAr13XX) are located in the platform code contained in arch/arm/plat-spear + with headers in plat/. + + Each machine series have a directory with name arch/arm/mach-spear followed by + series name. Like mach-spear3xx, mach-spear6xx and mach-spear13xx. + + Common file for machines of spear3xx family is mach-spear3xx/spear3xx.c and for + spear6xx is mach-spear6xx/spear6xx.c. mach-spear* also contain soc/machine + specific files, like spear300.c, spear310.c, spear320.c and spear600.c. + mach-spear* also contains board specific files for each machine type. + + + Document Author + --------------- + + Viresh Kumar, (c) 2010 ST Microelectronics diff --git a/Documentation/arm/Samsung-S3C24XX/CPUfreq.txt b/Documentation/arm/Samsung-S3C24XX/CPUfreq.txt index 76b3a11e90be..fa968aa99d67 100644 --- a/Documentation/arm/Samsung-S3C24XX/CPUfreq.txt +++ b/Documentation/arm/Samsung-S3C24XX/CPUfreq.txt @@ -14,8 +14,8 @@ Introduction how the clocks are arranged. The first implementation used as single PLL to feed the ARM, memory and peripherals via a series of dividers and muxes and this is the implementation that is documented here. A - newer version where there is a seperate PLL and clock divider for the - ARM core is available as a seperate driver. + newer version where there is a separate PLL and clock divider for the + ARM core is available as a separate driver. Layout diff --git a/Documentation/arm/Samsung-S3C24XX/GPIO.txt b/Documentation/arm/Samsung-S3C24XX/GPIO.txt index 2af2cf39915f..816d6071669e 100644 --- a/Documentation/arm/Samsung-S3C24XX/GPIO.txt +++ b/Documentation/arm/Samsung-S3C24XX/GPIO.txt @@ -12,6 +12,8 @@ Introduction of the s3c2410 GPIO system, please read the Samsung provided data-sheet/users manual to find out the complete list. + See Documentation/arm/Samsung/GPIO.txt for the core implemetation. + GPIOLIB ------- @@ -24,8 +26,60 @@ GPIOLIB listed below will be removed (they may be marked as __deprecated in the near future). - - s3c2410_gpio_getpin - - s3c2410_gpio_setpin + The following functions now either have a s3c_ specific variant + or are merged into gpiolib. See the definitions in + arch/arm/plat-samsung/include/plat/gpio-cfg.h: + + s3c2410_gpio_setpin() gpio_set_value() or gpio_direction_output() + s3c2410_gpio_getpin() gpio_get_value() or gpio_direction_input() + s3c2410_gpio_getirq() gpio_to_irq() + s3c2410_gpio_cfgpin() s3c_gpio_cfgpin() + s3c2410_gpio_getcfg() s3c_gpio_getcfg() + s3c2410_gpio_pullup() s3c_gpio_setpull() + + +GPIOLIB conversion +------------------ + +If you need to convert your board or driver to use gpiolib from the exiting +s3c2410 api, then here are some notes on the process. + +1) If your board is exclusively using an GPIO, say to control peripheral + power, then it will require to claim the gpio with gpio_request() before + it can use it. + + It is recommended to check the return value, with at least WARN_ON() + during initialisation. + +2) The s3c2410_gpio_cfgpin() can be directly replaced with s3c_gpio_cfgpin() + as they have the same arguments, and can either take the pin specific + values, or the more generic special-function-number arguments. + +3) s3c2410_gpio_pullup() changs have the problem that whilst the + s3c2410_gpio_pullup(x, 1) can be easily translated to the + s3c_gpio_setpull(x, S3C_GPIO_PULL_NONE), the s3c2410_gpio_pullup(x, 0) + are not so easy. + + The s3c2410_gpio_pullup(x, 0) case enables the pull-up (or in the case + of some of the devices, a pull-down) and as such the new API distinguishes + between the UP and DOWN case. There is currently no 'just turn on' setting + which may be required if this becomes a problem. + +4) s3c2410_gpio_setpin() can be replaced by gpio_set_value(), the old call + does not implicitly configure the relevant gpio to output. The gpio + direction should be changed before using gpio_set_value(). + +5) s3c2410_gpio_getpin() is replaceable by gpio_get_value() if the pin + has been set to input. It is currently unknown what the behaviour is + when using gpio_get_value() on an output pin (s3c2410_gpio_getpin + would return the value the pin is supposed to be outputting). + +6) s3c2410_gpio_getirq() should be directly replacable with the + gpio_to_irq() call. + +The s3c2410_gpio and gpio_ calls have always operated on the same gpio +numberspace, so there is no problem with converting the gpio numbering +between the calls. Headers @@ -54,6 +108,11 @@ PIN Numbers eg S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell the GPIO functions which pin is to be used. + With the conversion to gpiolib, there is no longer a direct conversion + from gpio pin number to register base address as in earlier kernels. This + is due to the number space required for newer SoCs where the later + GPIOs are not contiguous. + Configuring a pin ----------------- @@ -71,6 +130,8 @@ Configuring a pin which would turn GPA(0) into the lowest Address line A0, and set GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line. + The s3c_gpio_cfgpin() call is a functional replacement for this call. + Reading the current configuration --------------------------------- @@ -82,6 +143,9 @@ Reading the current configuration The return value will be from the same set of values which can be passed to s3c2410_gpio_cfgpin(). + The s3c_gpio_getcfg() call should be a functional replacement for + this call. + Configuring a pull-up resistor ------------------------------ @@ -95,6 +159,10 @@ Configuring a pull-up resistor Where the to value is zero to set the pull-up off, and 1 to enable the specified pull-up. Any other values are currently undefined. + The s3c_gpio_setpull() offers similar functionality, but with the + ability to encode whether the pull is up or down. Currently there + is no 'just on' state, so up or down must be selected. + Getting the state of a PIN -------------------------- @@ -106,6 +174,9 @@ Getting the state of a PIN This will return either zero or non-zero. Do not count on this function returning 1 if the pin is set. + This call is now implemented by the relevant gpiolib calls, convert + your board or driver to use gpiolib. + Setting the state of a PIN -------------------------- @@ -117,6 +188,9 @@ Setting the state of a PIN Which sets the given pin to the value. Use 0 to write 0, and 1 to set the output to 1. + This call is now implemented by the relevant gpiolib calls, convert + your board or driver to use gpiolib. + Getting the IRQ number associated with a PIN -------------------------------------------- @@ -128,6 +202,9 @@ Getting the IRQ number associated with a PIN Note, not all pins have an IRQ. + This call is now implemented by the relevant gpiolib calls, convert + your board or driver to use gpiolib. + Authour ------- diff --git a/Documentation/arm/Samsung-S3C24XX/Overview.txt b/Documentation/arm/Samsung-S3C24XX/Overview.txt index 081892df4fda..c12bfc1a00c9 100644 --- a/Documentation/arm/Samsung-S3C24XX/Overview.txt +++ b/Documentation/arm/Samsung-S3C24XX/Overview.txt @@ -8,10 +8,16 @@ Introduction The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported by the 's3c2410' architecture of ARM Linux. Currently the S3C2410, - S3C2412, S3C2413, S3C2440, S3C2442 and S3C2443 devices are supported. + S3C2412, S3C2413, S3C2416 S3C2440, S3C2442, S3C2443 and S3C2450 devices + are supported. Support for the S3C2400 and S3C24A0 series are in progress. + The S3C2416 and S3C2450 devices are very similar and S3C2450 support is + included under the arch/arm/mach-s3c2416 directory. Note, whilst core + support for these SoCs is in, work on some of the extra peripherals + and extra interrupts is still ongoing. + Configuration ------------- @@ -209,6 +215,13 @@ GPIO Newer kernels carry GPIOLIB, and support is being moved towards this with some of the older support in line to be removed. + As of v2.6.34, the move towards using gpiolib support is almost + complete, and very little of the old calls are left. + + See Documentation/arm/Samsung-S3C24XX/GPIO.txt for the S3C24XX specific + support and Documentation/arm/Samsung/GPIO.txt for the core Samsung + implementation. + Clock Management ---------------- diff --git a/Documentation/arm/Samsung/GPIO.txt b/Documentation/arm/Samsung/GPIO.txt new file mode 100644 index 000000000000..05850c62abeb --- /dev/null +++ b/Documentation/arm/Samsung/GPIO.txt @@ -0,0 +1,42 @@ + Samsung GPIO implementation + =========================== + +Introduction +------------ + +This outlines the Samsung GPIO implementation and the architecture +specfic calls provided alongisde the drivers/gpio core. + + +S3C24XX (Legacy) +---------------- + +See Documentation/arm/Samsung-S3C24XX/GPIO.txt for more information +about these devices. Their implementation is being brought into line +with the core samsung implementation described in this document. + + +GPIOLIB integration +------------------- + +The gpio implementation uses gpiolib as much as possible, only providing +specific calls for the items that require Samsung specific handling, such +as pin special-function or pull resistor control. + +GPIO numbering is synchronised between the Samsung and gpiolib system. + + +PIN configuration +----------------- + +Pin configuration is specific to the Samsung architecutre, with each SoC +registering the necessary information for the core gpio configuration +implementation to configure pins as necessary. + +The s3c_gpio_cfgpin() and s3c_gpio_setpull() provide the means for a +driver or machine to change gpio configuration. + +See arch/arm/plat-samsung/include/plat/gpio-cfg.h for more information +on these functions. + + diff --git a/Documentation/arm/Samsung/Overview.txt b/Documentation/arm/Samsung/Overview.txt new file mode 100644 index 000000000000..c3094ea51aa7 --- /dev/null +++ b/Documentation/arm/Samsung/Overview.txt @@ -0,0 +1,99 @@ + Samsung ARM Linux Overview + ========================== + +Introduction +------------ + + The Samsung range of ARM SoCs spans many similar devices, from the initial + ARM9 through to the newest ARM cores. This document shows an overview of + the current kernel support, how to use it and where to find the code + that supports this. + + The currently supported SoCs are: + + - S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list + - S3C64XX: S3C6400 and S3C6410 + - S5P6440 + - S5P6442 + - S5PC100 + - S5PC110 / S5PV210 + + +S3C24XX Systems +--------------- + + There is still documentation in Documnetation/arm/Samsung-S3C24XX/ which + deals with the architecture and drivers specific to these devices. + + See Documentation/arm/Samsung-S3C24XX/Overview.txt for more information + on the implementation details and specific support. + + +Configuration +------------- + + A number of configurations are supplied, as there is no current way of + unifying all the SoCs into one kernel. + + s5p6440_defconfig - S5P6440 specific default configuration + s5p6442_defconfig - S5P6442 specific default configuration + s5pc100_defconfig - S5PC100 specific default configuration + s5pc110_defconfig - S5PC110 specific default configuration + s5pv210_defconfig - S5PV210 specific default configuration + + +Layout +------ + + The directory layout is currently being restructured, and consists of + several platform directories and then the machine specific directories + of the CPUs being built for. + + plat-samsung provides the base for all the implementations, and is the + last in the line of include directories that are processed for the build + specific information. It contains the base clock, GPIO and device definitions + to get the system running. + + plat-s3c24xx is for s3c24xx specific builds, see the S3C24XX docs. + + plat-s5p is for s5p specific builds, and contains common support for the + S5P specific systems. Not all S5Ps use all the features in this directory + due to differences in the hardware. + + +Layout changes +-------------- + + The old plat-s3c and plat-s5pc1xx directories have been removed, with + support moved to either plat-samsung or plat-s5p as necessary. These moves + where to simplify the include and dependency issues involved with having + so many different platform directories. + + It was decided to remove plat-s5pc1xx as some of the support was already + in plat-s5p or plat-samsung, with the S5PC110 support added with S5PV210 + the only user was the S5PC100. The S5PC100 specific items where moved to + arch/arm/mach-s5pc100. + + + + +Port Contributors +----------------- + + Ben Dooks (BJD) + Vincent Sanders + Herbert Potzl + Arnaud Patard (RTP) + Roc Wu + Klaus Fetscher + Dimitry Andric + Shannon Holland + Guillaume Gourat (NexVision) + Christer Weinigel (wingel) (Acer N30) + Lucas Correia Villa Real (S3C2400 port) + + +Document Author +--------------- + +Copyright 2009-2010 Ben Dooks <ben-linux@fluff.org> diff --git a/Documentation/arm/Samsung/clksrc-change-registers.awk b/Documentation/arm/Samsung/clksrc-change-registers.awk new file mode 100755 index 000000000000..0c50220851fb --- /dev/null +++ b/Documentation/arm/Samsung/clksrc-change-registers.awk @@ -0,0 +1,167 @@ +#!/usr/bin/awk -f +# +# Copyright 2010 Ben Dooks <ben-linux@fluff.org> +# +# Released under GPLv2 + +# example usage +# ./clksrc-change-registers.awk arch/arm/plat-s5pc1xx/include/plat/regs-clock.h < src > dst + +function extract_value(s) +{ + eqat = index(s, "=") + comat = index(s, ",") + return substr(s, eqat+2, (comat-eqat)-2) +} + +function remove_brackets(b) +{ + return substr(b, 2, length(b)-2) +} + +function splitdefine(l, p) +{ + r = split(l, tp) + + p[0] = tp[2] + p[1] = remove_brackets(tp[3]) +} + +function find_length(f) +{ + if (0) + printf "find_length " f "\n" > "/dev/stderr" + + if (f ~ /0x1/) + return 1 + else if (f ~ /0x3/) + return 2 + else if (f ~ /0x7/) + return 3 + else if (f ~ /0xf/) + return 4 + + printf "unknown legnth " f "\n" > "/dev/stderr" + exit +} + +function find_shift(s) +{ + id = index(s, "<") + if (id <= 0) { + printf "cannot find shift " s "\n" > "/dev/stderr" + exit + } + + return substr(s, id+2) +} + + +BEGIN { + if (ARGC < 2) { + print "too few arguments" > "/dev/stderr" + exit + } + +# read the header file and find the mask values that we will need +# to replace and create an associative array of values + + while (getline line < ARGV[1] > 0) { + if (line ~ /\#define.*_MASK/ && + !(line ~ /S5PC100_EPLL_MASK/) && + !(line ~ /USB_SIG_MASK/)) { + splitdefine(line, fields) + name = fields[0] + if (0) + printf "MASK " line "\n" > "/dev/stderr" + dmask[name,0] = find_length(fields[1]) + dmask[name,1] = find_shift(fields[1]) + if (0) + printf "=> '" name "' LENGTH=" dmask[name,0] " SHIFT=" dmask[name,1] "\n" > "/dev/stderr" + } else { + } + } + + delete ARGV[1] +} + +/clksrc_clk.*=.*{/ { + shift="" + mask="" + divshift="" + reg_div="" + reg_src="" + indent=1 + + print $0 + + for(; indent >= 1;) { + if ((getline line) <= 0) { + printf "unexpected end of file" > "/dev/stderr" + exit 1; + } + + if (line ~ /\.shift/) { + shift = extract_value(line) + } else if (line ~ /\.mask/) { + mask = extract_value(line) + } else if (line ~ /\.reg_divider/) { + reg_div = extract_value(line) + } else if (line ~ /\.reg_source/) { + reg_src = extract_value(line) + } else if (line ~ /\.divider_shift/) { + divshift = extract_value(line) + } else if (line ~ /{/) { + indent++ + print line + } else if (line ~ /}/) { + indent-- + + if (indent == 0) { + if (0) { + printf "shift '" shift "' ='" dmask[shift,0] "'\n" > "/dev/stderr" + printf "mask '" mask "'\n" > "/dev/stderr" + printf "dshft '" divshift "'\n" > "/dev/stderr" + printf "rdiv '" reg_div "'\n" > "/dev/stderr" + printf "rsrc '" reg_src "'\n" > "/dev/stderr" + } + + generated = mask + sub(reg_src, reg_div, generated) + + if (0) { + printf "/* rsrc " reg_src " */\n" + printf "/* rdiv " reg_div " */\n" + printf "/* shift " shift " */\n" + printf "/* mask " mask " */\n" + printf "/* generated " generated " */\n" + } + + if (reg_div != "") { + printf "\t.reg_div = { " + printf ".reg = " reg_div ", " + printf ".shift = " dmask[generated,1] ", " + printf ".size = " dmask[generated,0] ", " + printf "},\n" + } + + printf "\t.reg_src = { " + printf ".reg = " reg_src ", " + printf ".shift = " dmask[mask,1] ", " + printf ".size = " dmask[mask,0] ", " + + printf "},\n" + + } + + print line + } else { + print line + } + + if (0) + printf indent ":" line "\n" > "/dev/stderr" + } +} + +// && ! /clksrc_clk.*=.*{/ { print $0 } diff --git a/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen b/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen index 1e6a23fdf2fc..dc460f055647 100644 --- a/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen +++ b/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen @@ -7,7 +7,7 @@ The driver only implements a four-wire touch panel protocol. The touchscreen driver is maintenance free except for the pen-down or touch threshold. Some resistive displays and board combinations may -require tuning of this threshold. The driver exposes some of it's +require tuning of this threshold. The driver exposes some of its internal state in the sys filesystem. If the kernel is configured with it, CONFIG_SYSFS, and sysfs is mounted at /sys, there will be a directory diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt index 9d58c7c5eddd..771d48d3b335 100644 --- a/Documentation/arm/memory.txt +++ b/Documentation/arm/memory.txt @@ -33,7 +33,13 @@ ffff0000 ffff0fff CPU vector page. 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. @@ -59,7 +65,11 @@ PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region. This maps the platforms RAM, and typically maps all platform RAM in a 1:1 relationship. -TASK_SIZE PAGE_OFFSET-1 Kernel module space +PKMAP_BASE PAGE_OFFSET-1 Permanent kernel mappings + One way of mapping HIGHMEM pages into kernel + space. + +MODULES_VADDR MODULES_END-1 Kernel module space Kernel modules inserted via insmod are placed here using dynamic mappings. diff --git a/Documentation/arm/tcm.txt b/Documentation/arm/tcm.txt index 77fd9376e6d7..7c15871c1885 100644 --- a/Documentation/arm/tcm.txt +++ b/Documentation/arm/tcm.txt @@ -19,8 +19,8 @@ defines a CPUID_TCM register that you can read out from the 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 @@ -35,7 +35,15 @@ The TCM memory can then be remapped to another address again using 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: @@ -65,18 +73,18 @@ in <asm/tcm.h>. Using this interface it is possible to: 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; |