diff options
Diffstat (limited to 'Documentation/arm')
60 files changed, 0 insertions, 5665 deletions
diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX deleted file mode 100644 index 36420e116c9..00000000000 --- a/Documentation/arm/00-INDEX +++ /dev/null @@ -1,36 +0,0 @@ -00-INDEX - - this file -Booting - - requirements for booting -Interrupts - - ARM Interrupt subsystem documentation -msm - - MSM specific documentation -Netwinder - - Netwinder specific documentation -Porting - - Symbol definitions for porting Linux to a new ARM machine. -Setup - - Kernel initialization parameters on ARM Linux -README - - General ARM documentation -SA1100/ - - SA1100 documentation -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/ - - Ltd's Empeg MP3 Car Audio Player -mem_alignment - - alignment abort handler documentation -memory.txt - - description of the virtual memory layout -nwfpe/ - - NWFPE floating point emulator documentation -swp_emulation - - SWP/SWPB emulation handler/logging description diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting deleted file mode 100644 index a341d87d276..00000000000 --- a/Documentation/arm/Booting +++ /dev/null @@ -1,171 +0,0 @@ - Booting ARM Linux - ================= - -Author: Russell King -Date : 18 May 2002 - -The following documentation is relevant to 2.4.18-rmk6 and beyond. - -In order to boot ARM Linux, you require a boot loader, which is a small -program that runs before the main kernel. The boot loader is expected -to initialise various devices, and eventually call the Linux kernel, -passing information to the kernel. - -Essentially, the boot loader should provide (as a minimum) the -following: - -1. Setup and initialise the RAM. -2. Initialise one serial port. -3. Detect the machine type. -4. Setup the kernel tagged list. -5. Call the kernel image. - - -1. Setup and initialise RAM ---------------------------- - -Existing boot loaders: MANDATORY -New boot loaders: MANDATORY - -The boot loader is expected to find and initialise all RAM that the -kernel will use for volatile data storage in the system. It performs -this in a machine dependent manner. (It may use internal algorithms -to automatically locate and size all RAM, or it may use knowledge of -the RAM in the machine, or any other method the boot loader designer -sees fit.) - - -2. Initialise one serial port ------------------------------ - -Existing boot loaders: OPTIONAL, RECOMMENDED -New boot loaders: OPTIONAL, RECOMMENDED - -The boot loader should initialise and enable one serial port on the -target. This allows the kernel serial driver to automatically detect -which serial port it should use for the kernel console (generally -used for debugging purposes, or communication with the target.) - -As an alternative, the boot loader can pass the relevant 'console=' -option to the kernel via the tagged lists specifying the port, and -serial format options as described in - - Documentation/kernel-parameters.txt. - - -3. Detect the machine type --------------------------- - -Existing boot loaders: OPTIONAL -New boot loaders: MANDATORY - -The boot loader should detect the machine type its running on by some -method. Whether this is a hard coded value or some algorithm that -looks at the connected hardware is beyond the scope of this document. -The boot loader must ultimately be able to provide a MACH_TYPE_xxx -value to the kernel. (see linux/arch/arm/tools/mach-types). - -4. Setup boot data ------------------- - -Existing boot loaders: OPTIONAL, HIGHLY RECOMMENDED -New boot loaders: MANDATORY - -The boot loader must provide either a tagged list or a dtb image for -passing configuration data to the kernel. The physical address of the -boot data is passed to the kernel in register r2. - -4a. Setup the kernel tagged list --------------------------------- - -The boot loader must create and initialise the kernel tagged list. -A valid tagged list starts with ATAG_CORE and ends with ATAG_NONE. -The ATAG_CORE tag may or may not be empty. An empty ATAG_CORE tag -has the size field set to '2' (0x00000002). The ATAG_NONE must set -the size field to zero. - -Any number of tags can be placed in the list. It is undefined -whether a repeated tag appends to the information carried by the -previous tag, or whether it replaces the information in its -entirety; some tags behave as the former, others the latter. - -The boot loader must pass at a minimum the size and location of -the system memory, and root filesystem location. Therefore, the -minimum tagged list should look: - - +-----------+ -base -> | ATAG_CORE | | - +-----------+ | - | ATAG_MEM | | increasing address - +-----------+ | - | ATAG_NONE | | - +-----------+ v - -The tagged list should be stored in system RAM. - -The tagged list must be placed in a region of memory where neither -the kernel decompressor nor initrd 'bootp' program will overwrite -it. The recommended placement is in the first 16KiB of RAM. - -4b. Setup the device tree -------------------------- - -The boot loader must load a device tree image (dtb) into system ram -at a 64bit aligned address and initialize it with the boot data. The -dtb format is documented in Documentation/devicetree/booting-without-of.txt. -The kernel will look for the dtb magic value of 0xd00dfeed at the dtb -physical address to determine if a dtb has been passed instead of a -tagged list. - -The boot loader must pass at a minimum the size and location of the -system memory, and the root filesystem location. The dtb must be -placed in a region of memory where the kernel decompressor will not -overwrite it. The recommended placement is in the first 16KiB of RAM -with the caveat that it may not be located at physical address 0 since -the kernel interprets a value of 0 in r2 to mean neither a tagged list -nor a dtb were passed. - -5. Calling the kernel image ---------------------------- - -Existing boot loaders: MANDATORY -New boot loaders: MANDATORY - -There are two options for calling the kernel zImage. If the zImage -is stored in flash, and is linked correctly to be run from flash, -then it is legal for the boot loader to call the zImage in flash -directly. - -The zImage may also be placed in system RAM (at any location) and -called there. Note that the kernel uses 16K of RAM below the image -to store page tables. The recommended placement is 32KiB into RAM. - -In either case, the following conditions must be met: - -- Quiesce all DMA capable devices so that memory does not get - corrupted by bogus network packets or disk data. This will save - you many hours of debug. - -- CPU register settings - r0 = 0, - r1 = machine type number discovered in (3) above. - r2 = physical address of tagged list in system RAM, or - physical address of device tree block (dtb) in system RAM - -- CPU mode - All forms of interrupts must be disabled (IRQs and FIQs) - The CPU must be in SVC mode. (A special exception exists for Angel) - -- Caches, MMUs - The MMU must be off. - Instruction cache may be on or off. - Data cache must be off. - -- The boot loader is expected to call the kernel image by jumping - directly to the first instruction of the kernel image. - - On CPUs supporting the ARM instruction set, the entry must be - made in ARM state, even for a Thumb-2 kernel. - - On CPUs supporting only the Thumb instruction set such as - Cortex-M class CPUs, the entry must be made in Thumb state. diff --git a/Documentation/arm/IXP4xx b/Documentation/arm/IXP4xx deleted file mode 100644 index 7b9351f2f55..00000000000 --- a/Documentation/arm/IXP4xx +++ /dev/null @@ -1,172 +0,0 @@ - -------------------------------------------------------------------------- -Release Notes for Linux on Intel's IXP4xx Network Processor - -Maintained by Deepak Saxena <dsaxena@plexity.net> -------------------------------------------------------------------------- - -1. Overview - -Intel's IXP4xx network processor is a highly integrated SOC that -is targeted for network applications, though it has become popular -in industrial control and other areas due to low cost and power -consumption. The IXP4xx family currently consists of several processors -that support different network offload functions such as encryption, -routing, firewalling, etc. The IXP46x family is an updated version which -supports faster speeds, new memory and flash configurations, and more -integration such as an on-chip I2C controller. - -For more information on the various versions of the CPU, see: - - http://developer.intel.com/design/network/products/npfamily/ixp4xx.htm - -Intel also made the IXCP1100 CPU for sometime which is an IXP4xx -stripped of much of the network intelligence. - -2. Linux Support - -Linux currently supports the following features on the IXP4xx chips: - -- Dual serial ports -- PCI interface -- Flash access (MTD/JFFS) -- I2C through GPIO on IXP42x -- GPIO for input/output/interrupts - See arch/arm/mach-ixp4xx/include/mach/platform.h for access functions. -- Timers (watchdog, OS) - -The following components of the chips are not supported by Linux and -require the use of Intel's proprietary CSR softare: - -- USB device interface -- Network interfaces (HSS, Utopia, NPEs, etc) -- Network offload functionality - -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/ixp425.htm - -DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPRIETARY -SOFTWARE. - -There are several websites that provide directions/pointers on using -Intel's software: - - http://sourceforge.net/projects/ixp4xx-osdg/ - Open Source Developer's Guide for using uClinux and the Intel libraries - -http://gatewaymaker.sourceforge.net/ - Simple one page summary of building a gateway using an IXP425 and Linux - -http://ixp425.sourceforge.net/ - ATM device driver for IXP425 that relies on Intel's libraries - -3. Known Issues/Limitations - -3a. Limited inbound PCI window - -The IXP4xx family allows for up to 256MB of memory but the PCI interface -can only expose 64MB of that memory to the PCI bus. This means that if -you are running with > 64MB, all PCI buffers outside of the accessible -range will be bounced using the routines in arch/arm/common/dmabounce.c. - -3b. Limited outbound PCI window - -IXP4xx provides two methods of accessing PCI memory space: - -1) A direct mapped window from 0x48000000 to 0x4bffffff (64MB). - To access PCI via this space, we simply ioremap() the BAR - into the kernel and we can use the standard read[bwl]/write[bwl] - macros. This is the preffered method due to speed but it - limits the system to just 64MB of PCI memory. This can be - problamatic if using video cards and other memory-heavy devices. - -2) If > 64MB of memory space is required, the IXP4xx can be - configured to use indirect registers to access PCI This allows - for up to 128MB (0x48000000 to 0x4fffffff) of memory on the bus. - The disadvantage of this is that every PCI access requires - three local register accesses plus a spinlock, but in some - cases the performance hit is acceptable. In addition, you cannot - mmap() PCI devices in this case due to the indirect nature - of the PCI window. - -By default, the direct method is used for performance reasons. If -you need more PCI memory, enable the IXP4XX_INDIRECT_PCI config option. - -3c. GPIO as Interrupts - -Currently the code only handles level-sensitive GPIO interrupts - -4. Supported platforms - -ADI Engineering Coyote Gateway Reference Platform -http://www.adiengineering.com/productsCoyote.html - - The ADI Coyote platform is reference design for those building - small residential/office gateways. One NPE is connected to a 10/100 - interface, one to 4-port 10/100 switch, and the third to and ADSL - interface. In addition, it also supports to POTs interfaces connected - via SLICs. Note that those are not supported by Linux ATM. Finally, - the platform has two mini-PCI slots used for 802.11[bga] cards. - Finally, there is an IDE port hanging off the expansion bus. - -Gateworks Avila Network Platform -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://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://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. - -Intel IXDPG425 Development Platform - - This is basically and ADI Coyote board with a NEC EHCI controller - added. One issue with this board is that the mini-PCI slots only - have the 3.3v line connected, so you can't use a PCI to mini-PCI - adapter with an E100 card. So to NFS root you need to use either - the CSR or a WiFi card and a ramdisk that BOOTPs and then does - a pivot_root to NFS. - -Motorola PrPMC1100 Processor Mezanine Card -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. - -5. TODO LIST - -- Add support for Coyote IDE -- Add support for edge-based GPIO interrupts -- Add support for CF IDE on expansion bus - -6. Thanks - -The IXP4xx work has been funded by Intel Corp. and MontaVista Software, Inc. - -The following people have contributed patches/comments/etc: - -Lennerty Buytenhek -Lutz Jaenicke -Justin Mayfield -Robert E. Ranslam -[I know I've forgotten others, please email me to be added] - -------------------------------------------------------------------------- - -Last Update: 01/04/2005 diff --git a/Documentation/arm/Interrupts b/Documentation/arm/Interrupts deleted file mode 100644 index f09ab1b90ef..00000000000 --- a/Documentation/arm/Interrupts +++ /dev/null @@ -1,167 +0,0 @@ -2.5.2-rmk5 ----------- - -This is the first kernel that contains a major shake up of some of the -major architecture-specific subsystems. - -Firstly, it contains some pretty major changes to the way we handle the -MMU TLB. Each MMU TLB variant is now handled completely separately - -we have TLB v3, TLB v4 (without write buffer), TLB v4 (with write buffer), -and finally TLB v4 (with write buffer, with I TLB invalidate entry). -There is more assembly code inside each of these functions, mainly to -allow more flexible TLB handling for the future. - -Secondly, the IRQ subsystem. - -The 2.5 kernels will be having major changes to the way IRQs are handled. -Unfortunately, this means that machine types that touch the irq_desc[] -array (basically all machine types) will break, and this means every -machine type that we currently have. - -Lets take an example. On the Assabet with Neponset, we have: - - GPIO25 IRR:2 - SA1100 ------------> Neponset -----------> SA1111 - IIR:1 - -----------> USAR - IIR:0 - -----------> SMC9196 - -The way stuff currently works, all SA1111 interrupts are mutually -exclusive of each other - if you're processing one interrupt from the -SA1111 and another comes in, you have to wait for that interrupt to -finish processing before you can service the new interrupt. Eg, an -IDE PIO-based interrupt on the SA1111 excludes all other SA1111 and -SMC9196 interrupts until it has finished transferring its multi-sector -data, which can be a long time. Note also that since we loop in the -SA1111 IRQ handler, SA1111 IRQs can hold off SMC9196 IRQs indefinitely. - - -The new approach brings several new ideas... - -We introduce the concept of a "parent" and a "child". For example, -to the Neponset handler, the "parent" is GPIO25, and the "children"d -are SA1111, SMC9196 and USAR. - -We also bring the idea of an IRQ "chip" (mainly to reduce the size of -the irqdesc array). This doesn't have to be a real "IC"; indeed the -SA11x0 IRQs are handled by two separate "chip" structures, one for -GPIO0-10, and another for all the rest. It is just a container for -the various operations (maybe this'll change to a better name). -This structure has the following operations: - -struct irqchip { - /* - * Acknowledge the IRQ. - * If this is a level-based IRQ, then it is expected to mask the IRQ - * as well. - */ - void (*ack)(unsigned int irq); - /* - * Mask the IRQ in hardware. - */ - void (*mask)(unsigned int irq); - /* - * Unmask the IRQ in hardware. - */ - void (*unmask)(unsigned int irq); - /* - * Re-run the IRQ - */ - void (*rerun)(unsigned int irq); - /* - * Set the type of the IRQ. - */ - int (*type)(unsigned int irq, unsigned int, type); -}; - -ack - required. May be the same function as mask for IRQs - handled by do_level_IRQ. -mask - required. -unmask - required. -rerun - optional. Not required if you're using do_level_IRQ for all - IRQs that use this 'irqchip'. Generally expected to re-trigger - the hardware IRQ if possible. If not, may call the handler - directly. -type - optional. If you don't support changing the type of an IRQ, - it should be null so people can detect if they are unable to - set the IRQ type. - -For each IRQ, we keep the following information: - - - "disable" depth (number of disable_irq()s without enable_irq()s) - - flags indicating what we can do with this IRQ (valid, probe, - noautounmask) as before - - status of the IRQ (probing, enable, etc) - - chip - - per-IRQ handler - - irqaction structure list - -The handler can be one of the 3 standard handlers - "level", "edge" and -"simple", or your own specific handler if you need to do something special. - -The "level" handler is what we currently have - its pretty simple. -"edge" knows about the brokenness of such IRQ implementations - that you -need to leave the hardware IRQ enabled while processing it, and queueing -further IRQ events should the IRQ happen again while processing. The -"simple" handler is very basic, and does not perform any hardware -manipulation, nor state tracking. This is useful for things like the -SMC9196 and USAR above. - -So, what's changed? - -1. Machine implementations must not write to the irqdesc array. - -2. New functions to manipulate the irqdesc array. The first 4 are expected - to be useful only to machine specific code. The last is recommended to - only be used by machine specific code, but may be used in drivers if - absolutely necessary. - - set_irq_chip(irq,chip) - - Set the mask/unmask methods for handling this IRQ - - set_irq_handler(irq,handler) - - Set the handler for this IRQ (level, edge, simple) - - set_irq_chained_handler(irq,handler) - - Set a "chained" handler for this IRQ - automatically - enables this IRQ (eg, Neponset and SA1111 handlers). - - set_irq_flags(irq,flags) - - Set the valid/probe/noautoenable flags. - - set_irq_type(irq,type) - - Set active the IRQ edge(s)/level. This replaces the - SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge() - function. Type should be one of IRQ_TYPE_xxx defined in - <linux/irq.h> - -3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type. - -4. Direct access to SA1111 INTPOL is deprecated. Use set_irq_type instead. - -5. A handler is expected to perform any necessary acknowledgement of the - parent IRQ via the correct chip specific function. For instance, if - the SA1111 is directly connected to a SA1110 GPIO, then you should - acknowledge the SA1110 IRQ each time you re-read the SA1111 IRQ status. - -6. For any child which doesn't have its own IRQ enable/disable controls - (eg, SMC9196), the handler must mask or acknowledge the parent IRQ - while the child handler is called, and the child handler should be the - "simple" handler (not "edge" nor "level"). After the handler completes, - the parent IRQ should be unmasked, and the status of all children must - be re-checked for pending events. (see the Neponset IRQ handler for - details). - -7. fixup_irq() is gone, as is arch/arm/mach-*/include/mach/irq.h - -Please note that this will not solve all problems - some of them are -hardware based. Mixing level-based and edge-based IRQs on the same -parent signal (eg neponset) is one such area where a software based -solution can't provide the full answer to low IRQ latency. - diff --git a/Documentation/arm/Netwinder b/Documentation/arm/Netwinder deleted file mode 100644 index f1b457fbd3d..00000000000 --- a/Documentation/arm/Netwinder +++ /dev/null @@ -1,78 +0,0 @@ -NetWinder specific documentation -================================ - -The NetWinder is a small low-power computer, primarily designed -to run Linux. It is based around the StrongARM RISC processor, -DC21285 PCI bridge, with PC-type hardware glued around it. - -Port usage -========== - -Min - Max Description ---------------------------- -0x0000 - 0x000f DMA1 -0x0020 - 0x0021 PIC1 -0x0060 - 0x006f Keyboard -0x0070 - 0x007f RTC -0x0080 - 0x0087 DMA1 -0x0088 - 0x008f DMA2 -0x00a0 - 0x00a3 PIC2 -0x00c0 - 0x00df DMA2 -0x0180 - 0x0187 IRDA -0x01f0 - 0x01f6 ide0 -0x0201 Game port -0x0203 RWA010 configuration read -0x0220 - ? SoundBlaster -0x0250 - ? WaveArtist -0x0279 RWA010 configuration index -0x02f8 - 0x02ff Serial ttyS1 -0x0300 - 0x031f Ether10 -0x0338 GPIO1 -0x033a GPIO2 -0x0370 - 0x0371 W83977F configuration registers -0x0388 - ? AdLib -0x03c0 - 0x03df VGA -0x03f6 ide0 -0x03f8 - 0x03ff Serial ttyS0 -0x0400 - 0x0408 DC21143 -0x0480 - 0x0487 DMA1 -0x0488 - 0x048f DMA2 -0x0a79 RWA010 configuration write -0xe800 - 0xe80f ide0/ide1 BM DMA - - -Interrupt usage -=============== - -IRQ type Description ---------------------------- - 0 ISA 100Hz timer - 1 ISA Keyboard - 2 ISA cascade - 3 ISA Serial ttyS1 - 4 ISA Serial ttyS0 - 5 ISA PS/2 mouse - 6 ISA IRDA - 7 ISA Printer - 8 ISA RTC alarm - 9 ISA -10 ISA GP10 (Orange reset button) -11 ISA -12 ISA WaveArtist -13 ISA -14 ISA hda1 -15 ISA - -DMA usage -========= - -DMA type Description ---------------------------- - 0 ISA IRDA - 1 ISA - 2 ISA cascade - 3 ISA WaveArtist - 4 ISA - 5 ISA - 6 ISA - 7 ISA WaveArtist diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS deleted file mode 100644 index a564ceea9e9..00000000000 --- a/Documentation/arm/OMAP/DSS +++ /dev/null @@ -1,364 +0,0 @@ -OMAP2/3 Display Subsystem -------------------------- - -This is an almost total rewrite of the OMAP FB driver in drivers/video/omap -(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI, -TV-out and multiple display support, but there are lots of small improvements -also. - -The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB, -panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live -currently side by side, you can choose which one to use. - -Features --------- - -Working and tested features include: - -- MIPI DPI (parallel) output -- MIPI DSI output in command mode -- MIPI DBI (RFBI) output -- SDI output -- TV output -- All pieces can be compiled as a module or inside kernel -- Use DISPC to update any of the outputs -- Use CPU to update RFBI or DSI output -- OMAP DISPC planes -- RGB16, RGB24 packed, RGB24 unpacked -- YUV2, UYVY -- Scaling -- Adjusting DSS FCK to find a good pixel clock -- Use DSI DPLL to create DSS FCK - -Tested boards include: -- OMAP3 SDP board -- Beagle board -- N810 - -omapdss driver --------------- - -The DSS driver does not itself have any support for Linux framebuffer, V4L or -such like the current ones, but it has an internal kernel API that upper level -drivers can use. - -The DSS driver models OMAP's overlays, overlay managers and displays in a -flexible way to enable non-common multi-display configuration. In addition to -modelling the hardware overlays, omapdss supports virtual overlays and overlay -managers. These can be used when updating a display with CPU or system DMA. - -omapdss driver support for audio --------------------------------- -There exist several display technologies and standards that support audio as -well. Hence, it is relevant to update the DSS device driver to provide an audio -interface that may be used by an audio driver or any other driver interested in -the functionality. - -The audio_enable function is intended to prepare the relevant -IP for playback (e.g., enabling an audio FIFO, taking in/out of reset -some IP, enabling companion chips, etc). It is intended to be called before -audio_start. The audio_disable function performs the reverse operation and is -intended to be called after audio_stop. - -While a given DSS device driver may support audio, it is possible that for -certain configurations audio is not supported (e.g., an HDMI display using a -VESA video timing). The audio_supported function is intended to query whether -the current configuration of the display supports audio. - -The audio_config function is intended to configure all the relevant audio -parameters of the display. In order to make the function independent of any -specific DSS device driver, a struct omap_dss_audio is defined. Its purpose -is to contain all the required parameters for audio configuration. At the -moment, such structure contains pointers to IEC-60958 channel status word -and CEA-861 audio infoframe structures. This should be enough to support -HDMI and DisplayPort, as both are based on CEA-861 and IEC-60958. - -The audio_enable/disable, audio_config and audio_supported functions could be -implemented as functions that may sleep. Hence, they should not be called -while holding a spinlock or a readlock. - -The audio_start/audio_stop function is intended to effectively start/stop audio -playback after the configuration has taken place. These functions are designed -to be used in an atomic context. Hence, audio_start should return quickly and be -called only after all the needed resources for audio playback (audio FIFOs, -DMA channels, companion chips, etc) have been enabled to begin data transfers. -audio_stop is designed to only stop the audio transfers. The resources used -for playback are released using audio_disable. - -The enum omap_dss_audio_state may be used to help the implementations of -the interface to keep track of the audio state. The initial state is _DISABLED; -then, the state transitions to _CONFIGURED, and then, when it is ready to -play audio, to _ENABLED. The state _PLAYING is used when the audio is being -rendered. - - -Panel and controller drivers ----------------------------- - -The drivers implement panel or controller specific functionality and are not -usually visible to users except through omapfb driver. They register -themselves to the DSS driver. - -omapfb driver -------------- - -The omapfb driver implements arbitrary number of standard linux framebuffers. -These framebuffers can be routed flexibly to any overlays, thus allowing very -dynamic display architecture. - -The driver exports some omapfb specific ioctls, which are compatible with the -ioctls in the old driver. - -The rest of the non standard features are exported via sysfs. Whether the final -implementation will use sysfs, or ioctls, is still open. - -V4L2 drivers ------------- - -V4L2 is being implemented in TI. - -From omapdss point of view the V4L2 drivers should be similar to framebuffer -driver. - -Architecture --------------------- - -Some clarification what the different components do: - - - Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the - pixel data for the image. Framebuffer has width and height and color - depth. - - Overlay defines where the pixels are read from and where they go on the - screen. The overlay may be smaller than framebuffer, thus displaying only - part of the framebuffer. The position of the overlay may be changed if - the overlay is smaller than the display. - - Overlay manager combines the overlays in to one image and feeds them to - display. - - Display is the actual physical display device. - -A framebuffer can be connected to multiple overlays to show the same pixel data -on all of the overlays. Note that in this case the overlay input sizes must be -the same, but, in case of video overlays, the output size can be different. Any -framebuffer can be connected to any overlay. - -An overlay can be connected to one overlay manager. Also DISPC overlays can be -connected only to DISPC overlay managers, and virtual overlays can be only -connected to virtual overlays. - -An overlay manager can be connected to one display. There are certain -restrictions which kinds of displays an overlay manager can be connected: - - - DISPC TV overlay manager can be only connected to TV display. - - Virtual overlay managers can only be connected to DBI or DSI displays. - - DISPC LCD overlay manager can be connected to all displays, except TV - display. - -Sysfs ------ -The sysfs interface is mainly used for testing. I don't think sysfs -interface is the best for this in the final version, but I don't quite know -what would be the best interfaces for these things. - -The sysfs interface is divided to two parts: DSS and FB. - -/sys/class/graphics/fb? directory: -mirror 0=off, 1=on -rotate Rotation 0-3 for 0, 90, 180, 270 degrees -rotate_type 0 = DMA rotation, 1 = VRFB rotation -overlays List of overlay numbers to which framebuffer pixels go -phys_addr Physical address of the framebuffer -virt_addr Virtual address of the framebuffer -size Size of the framebuffer - -/sys/devices/platform/omapdss/overlay? directory: -enabled 0=off, 1=on -input_size width,height (ie. the framebuffer size) -manager Destination overlay manager name -name -output_size width,height -position x,y -screen_width width -global_alpha global alpha 0-255 0=transparent 255=opaque - -/sys/devices/platform/omapdss/manager? directory: -display Destination display -name -alpha_blending_enabled 0=off, 1=on -trans_key_enabled 0=off, 1=on -trans_key_type gfx-destination, video-source -trans_key_value transparency color key (RGB24) -default_color default background color (RGB24) - -/sys/devices/platform/omapdss/display? directory: -ctrl_name Controller name -mirror 0=off, 1=on -update_mode 0=off, 1=auto, 2=manual -enabled 0=off, 1=on -name -rotate Rotation 0-3 for 0, 90, 180, 270 degrees -timings Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw) - When writing, two special timings are accepted for tv-out: - "pal" and "ntsc" -panel_name -tear_elim Tearing elimination 0=off, 1=on -output_type Output type (video encoder only): "composite" or "svideo" - -There are also some debugfs files at <debugfs>/omapdss/ which show information -about clocks and registers. - -Examples --------- - -The following definitions have been made for the examples below: - -ovl0=/sys/devices/platform/omapdss/overlay0 -ovl1=/sys/devices/platform/omapdss/overlay1 -ovl2=/sys/devices/platform/omapdss/overlay2 - -mgr0=/sys/devices/platform/omapdss/manager0 -mgr1=/sys/devices/platform/omapdss/manager1 - -lcd=/sys/devices/platform/omapdss/display0 -dvi=/sys/devices/platform/omapdss/display1 -tv=/sys/devices/platform/omapdss/display2 - -fb0=/sys/class/graphics/fb0 -fb1=/sys/class/graphics/fb1 -fb2=/sys/class/graphics/fb2 - -Default setup on OMAP3 SDP --------------------------- - -Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI -and TV-out are not in use. The columns from left to right are: -framebuffers, overlays, overlay managers, displays. Framebuffers are -handled by omapfb, and the rest by the DSS. - -FB0 --- GFX -\ DVI -FB1 --- VID1 --+- LCD ---- LCD -FB2 --- VID2 -/ TV ----- TV - -Example: Switch from LCD to DVI ----------------------- - -w=`cat $dvi/timings | cut -d "," -f 2 | cut -d "/" -f 1` -h=`cat $dvi/timings | cut -d "," -f 3 | cut -d "/" -f 1` - -echo "0" > $lcd/enabled -echo "" > $mgr0/display -fbset -fb /dev/fb0 -xres $w -yres $h -vxres $w -vyres $h -# at this point you have to switch the dvi/lcd dip-switch from the omap board -echo "dvi" > $mgr0/display -echo "1" > $dvi/enabled - -After this the configuration looks like: - -FB0 --- GFX -\ -- DVI -FB1 --- VID1 --+- LCD -/ LCD -FB2 --- VID2 -/ TV ----- TV - -Example: Clone GFX overlay to LCD and TV -------------------------------- - -w=`cat $tv/timings | cut -d "," -f 2 | cut -d "/" -f 1` -h=`cat $tv/timings | cut -d "," -f 3 | cut -d "/" -f 1` - -echo "0" > $ovl0/enabled -echo "0" > $ovl1/enabled - -echo "" > $fb1/overlays -echo "0,1" > $fb0/overlays - -echo "$w,$h" > $ovl1/output_size -echo "tv" > $ovl1/manager - -echo "1" > $ovl0/enabled -echo "1" > $ovl1/enabled - -echo "1" > $tv/enabled - -After this the configuration looks like (only relevant parts shown): - -FB0 +-- GFX ---- LCD ---- LCD - \- VID1 ---- TV ---- TV - -Misc notes ----------- - -OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator. - -Using DSI DPLL to generate pixel clock it is possible produce the pixel clock -of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI. - -Rotation and mirroring currently only supports RGB565 and RGB8888 modes. VRFB -does not support mirroring. - -VRFB rotation requires much more memory than non-rotated framebuffer, so you -probably need to increase your vram setting before using VRFB rotation. Also, -many applications may not work with VRFB if they do not pay attention to all -framebuffer parameters. - -Kernel boot arguments ---------------------- - -vram=<size>[,<physaddr>] - - Amount of total VRAM to preallocate and optionally a physical start - memory address. For example, "10M". omapfb allocates memory for - framebuffers from VRAM. - -omapfb.mode=<display>:<mode>[,...] - - Default video mode for specified displays. For example, - "dvi:800x400MR-24@60". See drivers/video/modedb.c. - There are also two special modes: "pal" and "ntsc" that - can be used to tv out. - -omapfb.vram=<fbnum>:<size>[@<physaddr>][,...] - - VRAM allocated for a framebuffer. Normally omapfb allocates vram - depending on the display size. With this you can manually allocate - more or define the physical address of each framebuffer. For example, - "1:4M" to allocate 4M for fb1. - -omapfb.debug=<y|n> - - Enable debug printing. You have to have OMAPFB debug support enabled - in kernel config. - -omapfb.test=<y|n> - - Draw test pattern to framebuffer whenever framebuffer settings change. - You need to have OMAPFB debug support enabled in kernel config. - -omapfb.vrfb=<y|n> - - Use VRFB rotation for all framebuffers. - -omapfb.rotate=<angle> - - Default rotation applied to all framebuffers. - 0 - 0 degree rotation - 1 - 90 degree rotation - 2 - 180 degree rotation - 3 - 270 degree rotation - -omapfb.mirror=<y|n> - - Default mirror for all framebuffers. Only works with DMA rotation. - -omapdss.def_disp=<display> - - Name of default display, to which all overlays will be connected. - Common examples are "lcd" or "tv". - -omapdss.debug=<y|n> - - Enable debug printing. You have to have DSS debug support enabled in - kernel config. - -TODO ----- - -DSS locking - -Error checking -- Lots of checks are missing or implemented just as BUG() - -System DMA update for DSI -- Can be used for RGB16 and RGB24P modes. Probably not for RGB24U (how - to skip the empty byte?) - -OMAP1 support -- Not sure if needed - diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm deleted file mode 100644 index 9012bb03909..00000000000 --- a/Documentation/arm/OMAP/omap_pm +++ /dev/null @@ -1,154 +0,0 @@ - -The OMAP PM interface -===================== - -This document describes the temporary OMAP PM interface. Driver -authors use these functions to communicate minimum latency or -throughput constraints to the kernel power management code. -Over time, the intention is to merge features from the OMAP PM -interface into the Linux PM QoS code. - -Drivers need to express PM parameters which: - -- support the range of power management parameters present in the TI SRF; - -- separate the drivers from the underlying PM parameter - implementation, whether it is the TI SRF or Linux PM QoS or Linux - latency framework or something else; - -- specify PM parameters in terms of fundamental units, such as - latency and throughput, rather than units which are specific to OMAP - or to particular OMAP variants; - -- allow drivers which are shared with other architectures (e.g., - DaVinci) to add these constraints in a way which won't affect non-OMAP - systems, - -- can be implemented immediately with minimal disruption of other - architectures. - - -This document proposes the OMAP PM interface, including the following -five power management functions for driver code: - -1. Set the maximum MPU wakeup latency: - (*pdata->set_max_mpu_wakeup_lat)(struct device *dev, unsigned long t) - -2. Set the maximum device wakeup latency: - (*pdata->set_max_dev_wakeup_lat)(struct device *dev, unsigned long t) - -3. Set the maximum system DMA transfer start latency (CORE pwrdm): - (*pdata->set_max_sdma_lat)(struct device *dev, long t) - -4. Set the minimum bus throughput needed by a device: - (*pdata->set_min_bus_tput)(struct device *dev, u8 agent_id, unsigned long r) - -5. Return the number of times the device has lost context - (*pdata->get_dev_context_loss_count)(struct device *dev) - - -Further documentation for all OMAP PM interface functions can be -found in arch/arm/plat-omap/include/mach/omap-pm.h. - - -The OMAP PM layer is intended to be temporary ---------------------------------------------- - -The intention is that eventually the Linux PM QoS layer should support -the range of power management features present in OMAP3. As this -happens, existing drivers using the OMAP PM interface can be modified -to use the Linux PM QoS code; and the OMAP PM interface can disappear. - - -Driver usage of the OMAP PM functions -------------------------------------- - -As the 'pdata' in the above examples indicates, these functions are -exposed to drivers through function pointers in driver .platform_data -structures. The function pointers are initialized by the board-*.c -files to point to the corresponding OMAP PM functions: -.set_max_dev_wakeup_lat will point to -omap_pm_set_max_dev_wakeup_lat(), etc. Other architectures which do -not support these functions should leave these function pointers set -to NULL. Drivers should use the following idiom: - - if (pdata->set_max_dev_wakeup_lat) - (*pdata->set_max_dev_wakeup_lat)(dev, t); - -The most common usage of these functions will probably be to specify -the maximum time from when an interrupt occurs, to when the device -becomes accessible. To accomplish this, driver writers should use the -set_max_mpu_wakeup_lat() function to to constrain the MPU wakeup -latency, and the set_max_dev_wakeup_lat() function to constrain the -device wakeup latency (from clk_enable() to accessibility). For -example, - - /* Limit MPU wakeup latency */ - if (pdata->set_max_mpu_wakeup_lat) - (*pdata->set_max_mpu_wakeup_lat)(dev, tc); - - /* Limit device powerdomain wakeup latency */ - if (pdata->set_max_dev_wakeup_lat) - (*pdata->set_max_dev_wakeup_lat)(dev, td); - - /* total wakeup latency in this example: (tc + td) */ - -The PM parameters can be overwritten by calling the function again -with the new value. The settings can be removed by calling the -function with a t argument of -1 (except in the case of -set_max_bus_tput(), which should be called with an r argument of 0). - -The fifth function above, omap_pm_get_dev_context_loss_count(), -is intended as an optimization to allow drivers to determine whether the -device has lost its internal context. If context has been lost, the -driver must restore its internal context before proceeding. - - -Other specialized interface functions -------------------------------------- - -The five functions listed above are intended to be usable by any -device driver. DSPBridge and CPUFreq have a few special requirements. -DSPBridge expresses target DSP performance levels in terms of OPP IDs. -CPUFreq expresses target MPU performance levels in terms of MPU -frequency. The OMAP PM interface contains functions for these -specialized cases to convert that input information (OPPs/MPU -frequency) into the form that the underlying power management -implementation needs: - -6. (*pdata->dsp_get_opp_table)(void) - -7. (*pdata->dsp_set_min_opp)(u8 opp_id) - -8. (*pdata->dsp_get_opp)(void) - -9. (*pdata->cpu_get_freq_table)(void) - -10. (*pdata->cpu_set_freq)(unsigned long f) - -11. (*pdata->cpu_get_freq)(void) - -Customizing OPP for platform -============================ -Defining CONFIG_PM should enable OPP layer for the silicon -and the registration of OPP table should take place automatically. -However, in special cases, the default OPP table may need to be -tweaked, for e.g.: - * enable default OPPs which are disabled by default, but which - could be enabled on a platform - * Disable an unsupported OPP on the platform - * Define and add a custom opp table entry -in these cases, the board file needs to do additional steps as follows: -arch/arm/mach-omapx/board-xyz.c - #include "pm.h" - .... - static void __init omap_xyz_init_irq(void) - { - .... - /* Initialize the default table */ - omapx_opp_init(); - /* Do customization to the defaults */ - .... - } -NOTE: omapx_opp_init will be omap3_opp_init or as required -based on the omap family. diff --git a/Documentation/arm/Porting b/Documentation/arm/Porting deleted file mode 100644 index a492233931b..00000000000 --- a/Documentation/arm/Porting +++ /dev/null @@ -1,135 +0,0 @@ -Taken from list archive at http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2001-July/004064.html - -Initial definitions -------------------- - -The following symbol definitions rely on you knowing the translation that -__virt_to_phys() does for your machine. This macro converts the passed -virtual address to a physical address. Normally, it is simply: - - phys = virt - PAGE_OFFSET + PHYS_OFFSET - - -Decompressor Symbols --------------------- - -ZTEXTADDR - Start address of decompressor. There's no point in talking about - virtual or physical addresses here, since the MMU will be off at - the time when you call the decompressor code. You normally call - the kernel at this address to start it booting. This doesn't have - to be located in RAM, it can be in flash or other read-only or - read-write addressable medium. - -ZBSSADDR - Start address of zero-initialised work area for the decompressor. - This must be pointing at RAM. The decompressor will zero initialise - this for you. Again, the MMU will be off. - -ZRELADDR - This is the address where the decompressed kernel will be written, - and eventually executed. The following constraint must be valid: - - __virt_to_phys(TEXTADDR) == ZRELADDR - - The initial part of the kernel is carefully coded to be position - independent. - -INITRD_PHYS - Physical address to place the initial RAM disk. Only relevant if - you are using the bootpImage stuff (which only works on the old - struct param_struct). - -INITRD_VIRT - Virtual address of the initial RAM disk. The following constraint - must be valid: - - __virt_to_phys(INITRD_VIRT) == INITRD_PHYS - -PARAMS_PHYS - Physical address of the struct param_struct or tag list, giving the - kernel various parameters about its execution environment. - - -Kernel Symbols --------------- - -PHYS_OFFSET - Physical start address of the first bank of RAM. - -PAGE_OFFSET - Virtual start address of the first bank of RAM. During the kernel - boot phase, virtual address PAGE_OFFSET will be mapped to physical - address PHYS_OFFSET, along with any other mappings you supply. - This should be the same value as TASK_SIZE. - -TASK_SIZE - The maximum size of a user process in bytes. Since user space - always starts at zero, this is the maximum address that a user - process can access+1. The user space stack grows down from this - address. - - Any virtual address below TASK_SIZE is deemed to be user process - area, and therefore managed dynamically on a process by process - basis by the kernel. I'll call this the user segment. - - Anything above TASK_SIZE is common to all processes. I'll call - this the kernel segment. - - (In other words, you can't put IO mappings below TASK_SIZE, and - hence PAGE_OFFSET). - -TEXTADDR - Virtual start address of kernel, normally PAGE_OFFSET + 0x8000. - This is where the kernel image ends up. With the latest kernels, - it must be located at 32768 bytes into a 128MB region. Previous - kernels placed a restriction of 256MB here. - -DATAADDR - Virtual address for the kernel data segment. Must not be defined - when using the decompressor. - -VMALLOC_START -VMALLOC_END - Virtual addresses bounding the vmalloc() area. There must not be - any static mappings in this area; vmalloc will overwrite them. - The addresses must also be in the kernel segment (see above). - Normally, the vmalloc() area starts VMALLOC_OFFSET bytes above the - last virtual RAM address (found using variable high_memory). - -VMALLOC_OFFSET - Offset normally incorporated into VMALLOC_START to provide a hole - between virtual RAM and the vmalloc area. We do this to allow - out of bounds memory accesses (eg, something writing off the end - of the mapped memory map) to be caught. Normally set to 8MB. - -Architecture Specific Macros ----------------------------- - -BOOT_MEM(pram,pio,vio) - `pram' specifies the physical start address of RAM. Must always - be present, and should be the same as PHYS_OFFSET. - - `pio' is the physical address of an 8MB region containing IO for - use with the debugging macros in arch/arm/kernel/debug-armv.S. - - `vio' is the virtual address of the 8MB debugging region. - - It is expected that the debugging region will be re-initialised - by the architecture specific code later in the code (via the - MAPIO function). - -BOOT_PARAMS - Same as, and see PARAMS_PHYS. - -FIXUP(func) - Machine specific fixups, run before memory subsystems have been - initialised. - -MAPIO(func) - Machine specific function to map IO areas (including the debug - region above). - -INITIRQ(func) - Machine specific function to initialise interrupts. - diff --git a/Documentation/arm/README b/Documentation/arm/README deleted file mode 100644 index aea34095cdc..00000000000 --- a/Documentation/arm/README +++ /dev/null @@ -1,197 +0,0 @@ - ARM Linux 2.6 - ============= - - Please check <ftp://ftp.arm.linux.org.uk/pub/armlinux> for - updates. - -Compilation of kernel ---------------------- - - In order to compile ARM Linux, you will need a compiler capable of - generating ARM ELF code with GNU extensions. GCC 3.3 is known to be - a good compiler. Fortunately, you needn't guess. The kernel will report - an error if your compiler is a recognized offender. - - To build ARM Linux natively, you shouldn't have to alter the ARCH = line - in the top level Makefile. However, if you don't have the ARM Linux ELF - tools installed as default, then you should change the CROSS_COMPILE - line as detailed below. - - If you wish to cross-compile, then alter the following lines in the top - level make file: - - ARCH = <whatever> - with - ARCH = arm - - and - - CROSS_COMPILE= - to - CROSS_COMPILE=<your-path-to-your-compiler-without-gcc> - eg. - CROSS_COMPILE=arm-linux- - - Do a 'make config', followed by 'make Image' to build the kernel - (arch/arm/boot/Image). A compressed image can be built by doing a - 'make zImage' instead of 'make Image'. - - -Bug reports etc ---------------- - - Please send patches to the patch system. For more information, see - 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/developer/ - - When sending bug reports, please ensure that they contain all relevant - information, eg. the kernel messages that were printed before/during - the problem, what you were doing, etc. - - -Include files -------------- - - Several new include directories have been created under include/asm-arm, - which are there to reduce the clutter in the top-level directory. These - directories, and their purpose is listed below: - - arch-* machine/platform specific header files - hardware driver-internal ARM specific data structures/definitions - mach descriptions of generic ARM to specific machine interfaces - proc-* processor dependent header files (currently only two - categories) - - -Machine/Platform support ------------------------- - - The ARM tree contains support for a lot of different machine types. To - continue supporting these differences, it has become necessary to split - machine-specific parts by directory. For this, the machine category is - used to select which directories and files get included (we will use - $(MACHINE) to refer to the category) - - To this end, we now have arch/arm/mach-$(MACHINE) directories which are - designed to house the non-driver files for a particular machine (eg, PCI, - memory management, architecture definitions etc). For all future - machines, there should be a corresponding arch/arm/mach-$(MACHINE)/include/mach - directory. - - -Modules -------- - - Although modularisation is supported (and required for the FP emulator), - each module on an ARM2/ARM250/ARM3 machine when is loaded will take - memory up to the next 32k boundary due to the size of the pages. - Therefore, is modularisation on these machines really worth it? - - However, ARM6 and up machines allow modules to take multiples of 4k, and - as such Acorn RiscPCs and other architectures using these processors can - make good use of modularisation. - - -ADFS Image files ----------------- - - You can access image files on your ADFS partitions by mounting the ADFS - partition, and then using the loopback device driver. You must have - losetup installed. - - Please note that the PCEmulator DOS partitions have a partition table at - the start, and as such, you will have to give '-o offset' to losetup. - - -Request to developers ---------------------- - - When writing device drivers which include a separate assembler file, please - include it in with the C file, and not the arch/arm/lib directory. This - allows the driver to be compiled as a loadable module without requiring - half the code to be compiled into the kernel image. - - In general, try to avoid using assembler unless it is really necessary. It - makes drivers far less easy to port to other hardware. - - -ST506 hard drives ------------------ - - The ST506 hard drive controllers seem to be working fine (if a little - slowly). At the moment they will only work off the controllers on an - A4x0's motherboard, but for it to work off a Podule just requires - someone with a podule to add the addresses for the IRQ mask and the - HDC base to the source. - - As of 31/3/96 it works with two drives (you should get the ADFS - *configure harddrive set to 2). I've got an internal 20MB and a great - big external 5.25" FH 64MB drive (who could ever want more :-) ). - - I've just got 240K/s off it (a dd with bs=128k); thats about half of what - RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting - last week :-) - - Known bug: Drive data errors can cause a hang; including cases where - the controller has fixed the error using ECC. (Possibly ONLY - in that case...hmm). - - -1772 Floppy ------------ - This also seems to work OK, but hasn't been stressed much lately. It - hasn't got any code for disc change detection in there at the moment which - could be a bit of a problem! Suggestions on the correct way to do this - are welcome. - - -CONFIG_MACH_ and CONFIG_ARCH_ ------------------------------ - A change was made in 2003 to the macro names for new machines. - Historically, CONFIG_ARCH_ was used for the bonafide architecture, - e.g. SA1100, as well as implementations of the architecture, - e.g. Assabet. It was decided to change the implementation macros - to read CONFIG_MACH_ for clarity. Moreover, a retroactive fixup has - not been made because it would complicate patching. - - Previous registrations may be found online. - - <http://www.arm.linux.org.uk/developer/machines/> - -Kernel entry (head.S) --------------------------- - The initial entry into the kernel is via head.S, which uses machine - independent code. The machine is selected by the value of 'r1' on - entry, which must be kept unique. - - Due to the large number of machines which the ARM port of Linux provides - for, we have a method to manage this which ensures that we don't end up - duplicating large amounts of code. - - We group machine (or platform) support code into machine classes. A - class typically based around one or more system on a chip devices, and - acts as a natural container around the actual implementations. These - classes are given directories - arch/arm/mach-<class> and - arch/arm/mach-<class> - which contain the source files to/include/mach - support the machine class. This directories also contain any machine - specific supporting code. - - For example, the SA1100 class is based upon the SA1100 and SA1110 SoC - devices, and contains the code to support the way the on-board and off- - board devices are used, or the device is setup, and provides that - machine specific "personality." - - This fine-grained machine specific selection is controlled by the machine - type ID, which acts both as a run-time and a compile-time code selection - method. - - You can register a new machine via the web site at: - - <http://www.arm.linux.org.uk/developer/machines/> - ---- -Russell King (15/03/2004) diff --git a/Documentation/arm/SA1100/ADSBitsy b/Documentation/arm/SA1100/ADSBitsy deleted file mode 100644 index f9f62e8c071..00000000000 --- a/Documentation/arm/SA1100/ADSBitsy +++ /dev/null @@ -1,43 +0,0 @@ -ADS Bitsy Single Board Computer -(It is different from Bitsy(iPAQ) of Compaq) - -For more details, contact Applied Data Systems or see -http://www.applieddata.net/products.html - -The Linux support for this product has been provided by -Woojung Huh <whuh@applieddata.net> - -Use 'make adsbitsy_config' before any 'make config'. -This will set up defaults for ADS Bitsy support. - -The kernel zImage is linked to be loaded and executed at 0xc0400000. - -Linux can be used with the ADS BootLoader that ships with the -newer rev boards. See their documentation on how to load Linux. - -Supported peripherals: -- SA1100 LCD frame buffer (8/16bpp...sort of) -- SA1111 USB Master -- SA1100 serial port -- pcmcia, compact flash -- touchscreen(ucb1200) -- console on LCD screen -- serial ports (ttyS[0-2]) - - ttyS0 is default for serial console - -To do: -- everything else! :-) - -Notes: - -- The flash on board is divided into 3 partitions. - You should be careful to use flash on board. - 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, - if you compile with 16bit mode support and switch into a lower bpp - mode, the timing is off so the image is corrupted. This will be - fixed soon. - -Any contribution can be sent to nico@fluxnic.net and will be greatly welcome! diff --git a/Documentation/arm/SA1100/Assabet b/Documentation/arm/SA1100/Assabet deleted file mode 100644 index 08b885d3567..00000000000 --- a/Documentation/arm/SA1100/Assabet +++ /dev/null @@ -1,300 +0,0 @@ -The Intel Assabet (SA-1110 evaluation) board -============================================ - -Please see: -http://developer.intel.com - -Also some notes from John G Dorsey <jd5q@andrew.cmu.edu>: -http://www.cs.cmu.edu/~wearable/software/assabet.html - - -Building the kernel -------------------- - -To build the kernel with current defaults: - - make assabet_config - make oldconfig - make zImage - -The resulting kernel image should be available in linux/arch/arm/boot/zImage. - - -Installing a bootloader ------------------------ - -A couple of bootloaders able to boot Linux on Assabet are available: - -BLOB (http://www.lartmaker.nl/lartware/blob/) - - BLOB is a bootloader used within the LART project. Some contributed - patches were merged into BLOB to add support for Assabet. - -Compaq's Bootldr + John Dorsey's patch for Assabet support -(http://www.handhelds.org/Compaq/bootldr.html) -(http://www.wearablegroup.org/software/bootldr/) - - Bootldr is the bootloader developed by Compaq for the iPAQ Pocket PC. - John Dorsey has produced add-on patches to add support for Assabet and - the JFFS filesystem. - -RedBoot (http://sources.redhat.com/redboot/) - - RedBoot is a bootloader developed by Red Hat based on the eCos RTOS - hardware abstraction layer. It supports Assabet amongst many other - hardware platforms. - -RedBoot is currently the recommended choice since it's the only one to have -networking support, and is the most actively maintained. - -Brief examples on how to boot Linux with RedBoot are shown below. But first -you need to have RedBoot installed in your flash memory. A known to work -precompiled RedBoot binary is available from the following location: - -ftp://ftp.netwinder.org/users/n/nico/ -ftp://ftp.arm.linux.org.uk/pub/linux/arm/people/nico/ -ftp://ftp.handhelds.org/pub/linux/arm/sa-1100-patches/ - -Look for redboot-assabet*.tgz. Some installation infos are provided in -redboot-assabet*.txt. - - -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.html. -Please refer to it for explanations. - -If you have a CF network card (my Assabet kit contained a CF+ LP-E from -Socket Communications Inc.), you should strongly consider using it for TFTP -file transfers. You must insert it before RedBoot runs since it can't detect -it dynamically. - -To initialize the flash directory: - - fis init -f - -To initialize the non-volatile settings, like whether you want to use BOOTP or -a static IP address, etc, use this command: - - fconfig -i - - -Writing a kernel image into flash ---------------------------------- - -First, the kernel image must be loaded into RAM. If you have the zImage file -available on a TFTP server: - - load zImage -r -b 0x100000 - -If you rather want to use Y-Modem upload over the serial port: - - load -m ymodem -r -b 0x100000 - -To write it to flash: - - fis create "Linux kernel" -b 0x100000 -l 0xc0000 - - -Booting the kernel ------------------- - -The kernel still requires a filesystem to boot. A ramdisk image can be loaded -as follows: - - load ramdisk_image.gz -r -b 0x800000 - -Again, Y-Modem upload can be used instead of TFTP by replacing the file name -by '-y ymodem'. - -Now the kernel can be retrieved from flash like this: - - fis load "Linux kernel" - -or loaded as described previously. To boot the kernel: - - exec -b 0x100000 -l 0xc0000 - -The ramdisk image could be stored into flash as well, but there are better -solutions for on-flash filesystems as mentioned below. - - -Using JFFS2 ------------ - -Using JFFS2 (the Second Journalling Flash File System) is probably the most -convenient way to store a writable filesystem into flash. JFFS2 is used in -conjunction with the MTD layer which is responsible for low-level flash -management. More information on the Linux MTD can be found on-line at: -http://www.linux-mtd.infradead.org/. A JFFS howto with some infos about -creating JFFS/JFFS2 images is available from the same site. - -For instance, a sample JFFS2 image can be retrieved from the same FTP sites -mentioned below for the precompiled RedBoot image. - -To load this file: - - load sample_img.jffs2 -r -b 0x100000 - -The result should look like: - -RedBoot> load sample_img.jffs2 -r -b 0x100000 -Raw file loaded 0x00100000-0x00377424 - -Now we must know the size of the unallocated flash: - - fis free - -Result: - -RedBoot> fis free - 0x500E0000 .. 0x503C0000 - -The values above may be different depending on the size of the filesystem and -the type of flash. See their usage below as an example and take care of -substituting yours appropriately. - -We must determine some values: - -size of unallocated flash: 0x503c0000 - 0x500e0000 = 0x2e0000 -size of the filesystem image: 0x00377424 - 0x00100000 = 0x277424 - -We want to fit the filesystem image of course, but we also want to give it all -the remaining flash space as well. To write it: - - fis unlock -f 0x500E0000 -l 0x2e0000 - fis erase -f 0x500E0000 -l 0x2e0000 - fis write -b 0x100000 -l 0x277424 -f 0x500E0000 - fis create "JFFS2" -n -f 0x500E0000 -l 0x2e0000 - -Now the filesystem is associated to a MTD "partition" once Linux has discovered -what they are in the boot process. From Redboot, the 'fis list' command -displays them: - -RedBoot> fis list -Name FLASH addr Mem addr Length Entry point -RedBoot 0x50000000 0x50000000 0x00020000 0x00000000 -RedBoot config 0x503C0000 0x503C0000 0x00020000 0x00000000 -FIS directory 0x503E0000 0x503E0000 0x00020000 0x00000000 -Linux kernel 0x50020000 0x00100000 0x000C0000 0x00000000 -JFFS2 0x500E0000 0x500E0000 0x002E0000 0x00000000 - -However Linux should display something like: - -SA1100 flash: probing 32-bit flash bus -SA1100 flash: Found 2 x16 devices at 0x0 in 32-bit mode -Using RedBoot partition definition -Creating 5 MTD partitions on "SA1100 flash": -0x00000000-0x00020000 : "RedBoot" -0x00020000-0x000e0000 : "Linux kernel" -0x000e0000-0x003c0000 : "JFFS2" -0x003c0000-0x003e0000 : "RedBoot config" -0x003e0000-0x00400000 : "FIS directory" - -What's important here is the position of the partition we are interested in, -which is the third one. Within Linux, this correspond to /dev/mtdblock2. -Therefore to boot Linux with the kernel and its root filesystem in flash, we -need this RedBoot command: - - fis load "Linux kernel" - exec -b 0x100000 -l 0xc0000 -c "root=/dev/mtdblock2" - -Of course other filesystems than JFFS might be used, like cramfs for example. -You might want to boot with a root filesystem over NFS, etc. It is also -possible, and sometimes more convenient, to flash a filesystem directly from -within Linux while booted from a ramdisk or NFS. The Linux MTD repository has -many tools to deal with flash memory as well, to erase it for example. JFFS2 -can then be mounted directly on a freshly erased partition and files can be -copied over directly. Etc... - - -RedBoot scripting ------------------ - -All the commands above aren't so useful if they have to be typed in every -time the Assabet is rebooted. Therefore it's possible to automatize the boot -process using RedBoot's scripting capability. - -For example, I use this to boot Linux with both the kernel and the ramdisk -images retrieved from a TFTP server on the network: - -RedBoot> fconfig -Run script at boot: false true -Boot script: -Enter script, terminate with empty line ->> load zImage -r -b 0x100000 ->> load ramdisk_ks.gz -r -b 0x800000 ->> exec -b 0x100000 -l 0xc0000 ->> -Boot script timeout (1000ms resolution): 3 -Use BOOTP for network configuration: true -GDB connection port: 9000 -Network debug at boot time: false -Update RedBoot non-volatile configuration - are you sure (y/n)? y - -Then, rebooting the Assabet is just a matter of waiting for the login prompt. - - - -Nicolas Pitre -nico@fluxnic.net -June 12, 2001 - - -Status of peripherals in -rmk tree (updated 14/10/2001) -------------------------------------------------------- - -Assabet: - Serial ports: - Radio: TX, RX, CTS, DSR, DCD, RI - PM: Not tested. - COM: TX, RX, CTS, DSR, DCD, RTS, DTR, PM - PM: Not tested. - I2C: Implemented, not fully tested. - L3: Fully tested, pass. - PM: Not tested. - - Video: - LCD: Fully tested. PM - (LCD doesn't like being blanked with - neponset connected) - Video out: Not fully - - Audio: - UDA1341: - Playback: Fully tested, pass. - Record: Implemented, not tested. - PM: Not tested. - - UCB1200: - Audio play: Implemented, not heavily tested. - Audio rec: Implemented, not heavily tested. - Telco audio play: Implemented, not heavily tested. - Telco audio rec: Implemented, not heavily tested. - POTS control: No - Touchscreen: Yes - PM: Not tested. - - Other: - PCMCIA: - LPE: Fully tested, pass. - USB: No - IRDA: - SIR: Fully tested, pass. - FIR: Fully tested, pass. - PM: Not tested. - -Neponset: - Serial ports: - COM1,2: TX, RX, CTS, DSR, DCD, RTS, DTR - PM: Not tested. - USB: Implemented, not heavily tested. - PCMCIA: Implemented, not heavily tested. - PM: Not tested. - CF: Implemented, not heavily tested. - PM: Not tested. - -More stuff can be found in the -np (Nicolas Pitre's) tree. - diff --git a/Documentation/arm/SA1100/Brutus b/Documentation/arm/SA1100/Brutus deleted file mode 100644 index 6a3aa95e9bf..00000000000 --- a/Documentation/arm/SA1100/Brutus +++ /dev/null @@ -1,66 +0,0 @@ -Brutus is an evaluation platform for the SA1100 manufactured by Intel. -For more details, see: - -http://developer.intel.com - -To compile for Brutus, you must issue the following commands: - - make brutus_config - make config - [accept all the defaults] - make zImage - -The resulting kernel will end up in linux/arch/arm/boot/zImage. This file -must be loaded at 0xc0008000 in Brutus's memory and execution started at -0xc0008000 as well with the value of registers r0 = 0 and r1 = 16 upon -entry. - -But prior to execute the kernel, a ramdisk image must also be loaded in -memory. Use memory address 0xd8000000 for this. Note that the file -containing the (compressed) ramdisk image must not exceed 4 MB. - -Typically, you'll need angelboot to load the kernel. -The following angelboot.opt file should be used: - ------ begin angelboot.opt ----- -base 0xc0008000 -entry 0xc0008000 -r0 0x00000000 -r1 0x00000010 -device /dev/ttyS0 -options "9600 8N1" -baud 115200 -otherfile ramdisk_img.gz -otherbase 0xd8000000 ------ end angelboot.opt ----- - -Then load the kernel and ramdisk with: - - angelboot -f angelboot.opt zImage - -The first Brutus serial port (assumed to be linked to /dev/ttyS0 on your -host PC) is used by angel to load the kernel and ramdisk image. The serial -console is provided through the second Brutus serial port. To access it, -you may use minicom configured with /dev/ttyS1, 9600 baud, 8N1, no flow -control. - -Currently supported: - - RS232 serial ports - - audio output - - LCD screen - - keyboard - -The actual Brutus support may not be complete without extra patches. -If such patches exist, they should be found from -ftp.netwinder.org/users/n/nico. - -A full PCMCIA support is still missing, although it's possible to hack -some drivers in order to drive already inserted cards at boot time with -little modifications. - -Any contribution is welcome. - -Please send patches to nico@fluxnic.net - -Have Fun ! - diff --git a/Documentation/arm/SA1100/CERF b/Documentation/arm/SA1100/CERF deleted file mode 100644 index b3d845301ef..00000000000 --- a/Documentation/arm/SA1100/CERF +++ /dev/null @@ -1,29 +0,0 @@ -*** The StrongARM version of the CerfBoard/Cube has been discontinued *** - -The Intrinsyc CerfBoard is a StrongARM 1110-based computer on a board -that measures approximately 2" square. It includes an Ethernet -controller, an RS232-compatible serial port, a USB function port, and -one CompactFlash+ slot on the back. Pictures can be found at the -Intrinsyc website, http://www.intrinsyc.com. - -This document describes the support in the Linux kernel for the -Intrinsyc CerfBoard. - -Supported in this version: - - CompactFlash+ slot (select PCMCIA in General Setup and any options - that may be required) - - Onboard Crystal CS8900 Ethernet controller (Cerf CS8900A support in - Network Devices) - - Serial ports with a serial console (hardcoded to 38400 8N1) - -In order to get this kernel onto your Cerf, you need a server that runs -both BOOTP and TFTP. Detailed instructions should have come with your -evaluation kit on how to use the bootloader. This series of commands -will suffice: - - make ARCH=arm CROSS_COMPILE=arm-linux- cerfcube_defconfig - make ARCH=arm CROSS_COMPILE=arm-linux- zImage - make ARCH=arm CROSS_COMPILE=arm-linux- modules - cp arch/arm/boot/zImage <TFTP directory> - -support@intrinsyc.com diff --git a/Documentation/arm/SA1100/FreeBird b/Documentation/arm/SA1100/FreeBird deleted file mode 100644 index ab9193663b2..00000000000 --- a/Documentation/arm/SA1100/FreeBird +++ /dev/null @@ -1,21 +0,0 @@ -Freebird-1.1 is produced by Legend(C), Inc. -http://web.archive.org/web/*/http://www.legend.com.cn -and software/linux maintained by Coventive(C), Inc. -(http://www.coventive.com) - -Based on the Nicolas's strongarm kernel tree. - -=============================================================== -Maintainer: - -Chester Kuo <chester@coventive.com> - <chester@linux.org.tw> - -Author : -Tim wu <timwu@coventive.com> -CIH <cih@coventive.com> -Eric Peng <ericpeng@coventive.com> -Jeff Lee <jeff_lee@coventive.com> -Allen Cheng -Tony Liu <tonyliu@coventive.com> - diff --git a/Documentation/arm/SA1100/GraphicsClient b/Documentation/arm/SA1100/GraphicsClient deleted file mode 100644 index 867bb35943a..00000000000 --- a/Documentation/arm/SA1100/GraphicsClient +++ /dev/null @@ -1,98 +0,0 @@ -ADS GraphicsClient Plus Single Board Computer - -For more details, contact Applied Data Systems or see -http://www.applieddata.net/products.html - -The original Linux support for this product has been provided by -Nicolas Pitre <nico@fluxnic.net>. Continued development work by -Woojung Huh <whuh@applieddata.net> - -It's currently possible to mount a root filesystem via NFS providing a -complete Linux environment. Otherwise a ramdisk image may be used. The -board supports MTD/JFFS, so you could also mount something on there. - -Use 'make graphicsclient_config' before any 'make config'. This will set up -defaults for GraphicsClient Plus support. - -The kernel zImage is linked to be loaded and executed at 0xc0200000. -Also the following registers should have the specified values upon entry: - - r0 = 0 - r1 = 29 (this is the GraphicsClient architecture number) - -Linux can be used with the ADS BootLoader that ships with the -newer rev boards. See their documentation on how to load Linux. -Angel is not available for the GraphicsClient Plus AFAIK. - -There is a board known as just the GraphicsClient that ADS used to -produce but has end of lifed. This code will not work on the older -board with the ADS bootloader, but should still work with Angel, -as outlined below. In any case, if you're planning on deploying -something en masse, you should probably get the newer board. - -If using Angel on the older boards, here is a typical angel.opt option file -if the kernel is loaded through the Angel Debug Monitor: - ------ begin angelboot.opt ----- -base 0xc0200000 -entry 0xc0200000 -r0 0x00000000 -r1 0x0000001d -device /dev/ttyS1 -options "38400 8N1" -baud 115200 -#otherfile ramdisk.gz -#otherbase 0xc0800000 -exec minicom ------ end angelboot.opt ----- - -Then the kernel (and ramdisk if otherfile/otherbase lines above are -uncommented) would be loaded with: - - angelboot -f angelboot.opt zImage - -Here it is assumed that the board is connected to ttyS1 on your PC -and that minicom is preconfigured with /dev/ttyS1, 38400 baud, 8N1, no flow -control by default. - -If any other bootloader is used, ensure it accomplish the same, especially -for r0/r1 register values before jumping into the kernel. - - -Supported peripherals: -- SA1100 LCD frame buffer (8/16bpp...sort of) -- on-board SMC 92C96 ethernet NIC -- SA1100 serial port -- flash memory access (MTD/JFFS) -- pcmcia -- touchscreen(ucb1200) -- ps/2 keyboard -- console on LCD screen -- serial ports (ttyS[0-2]) - - ttyS0 is default for serial console -- Smart I/O (ADC, keypad, digital inputs, etc) - 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: -- UCB1200 audio with new ucb_generic layer -- everything else! :-) - -Notes: - -- The flash on board is divided into 3 partitions. mtd0 is where - the ADS boot ROM and zImage is stored. It's been marked as - read-only to keep you from blasting over the bootloader. :) mtd1 is - for the ramdisk.gz image. mtd2 is user flash space and can be - utilized for either JFFS or if you're feeling crazy, running ext2 - on top of it. If you're not using the ADS bootloader, you're - welcome to blast over the mtd1 partition also. - -- 16bpp mode requires a different cable than what ships with the board. - Contact ADS or look through the manual to wire your own. Currently, - if you compile with 16bit mode support and switch into a lower bpp - mode, the timing is off so the image is corrupted. This will be - fixed soon. - -Any contribution can be sent to nico@fluxnic.net and will be greatly welcome! - diff --git a/Documentation/arm/SA1100/GraphicsMaster b/Documentation/arm/SA1100/GraphicsMaster deleted file mode 100644 index 9145088a0ba..00000000000 --- a/Documentation/arm/SA1100/GraphicsMaster +++ /dev/null @@ -1,53 +0,0 @@ -ADS GraphicsMaster Single Board Computer - -For more details, contact Applied Data Systems or see -http://www.applieddata.net/products.html - -The original Linux support for this product has been provided by -Nicolas Pitre <nico@fluxnic.net>. Continued development work by -Woojung Huh <whuh@applieddata.net> - -Use 'make graphicsmaster_config' before any 'make config'. -This will set up defaults for GraphicsMaster support. - -The kernel zImage is linked to be loaded and executed at 0xc0400000. - -Linux can be used with the ADS BootLoader that ships with the -newer rev boards. See their documentation on how to load Linux. - -Supported peripherals: -- SA1100 LCD frame buffer (8/16bpp...sort of) -- SA1111 USB Master -- on-board SMC 92C96 ethernet NIC -- SA1100 serial port -- flash memory access (MTD/JFFS) -- pcmcia, compact flash -- touchscreen(ucb1200) -- ps/2 keyboard -- console on LCD screen -- serial ports (ttyS[0-2]) - - ttyS0 is default for serial console -- Smart I/O (ADC, keypad, digital inputs, etc) - 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: -- everything else! :-) - -Notes: - -- The flash on board is divided into 3 partitions. mtd0 is where - the zImage is stored. It's been marked as read-only to keep you - from blasting over the bootloader. :) mtd1 is - for the ramdisk.gz image. mtd2 is user flash space and can be - utilized for either JFFS or if you're feeling crazy, running ext2 - on top of it. If you're not using the ADS bootloader, you're - welcome to blast over the mtd1 partition also. - -- 16bpp mode requires a different cable than what ships with the board. - Contact ADS or look through the manual to wire your own. Currently, - if you compile with 16bit mode support and switch into a lower bpp - mode, the timing is off so the image is corrupted. This will be - fixed soon. - -Any contribution can be sent to nico@fluxnic.net and will be greatly welcome! diff --git a/Documentation/arm/SA1100/HUW_WEBPANEL b/Documentation/arm/SA1100/HUW_WEBPANEL deleted file mode 100644 index fd56b48d483..00000000000 --- a/Documentation/arm/SA1100/HUW_WEBPANEL +++ /dev/null @@ -1,17 +0,0 @@ -The HUW_WEBPANEL is a product of the german company Hoeft & Wessel AG - -If you want more information, please visit -http://www.hoeft-wessel.de - -To build the kernel: - make huw_webpanel_config - make oldconfig - [accept all defaults] - make zImage - -Mostly of the work is done by: -Roman Jordan jor@hoeft-wessel.de -Christoph Schulz schu@hoeft-wessel.de - -2000/12/18/ - diff --git a/Documentation/arm/SA1100/Itsy b/Documentation/arm/SA1100/Itsy deleted file mode 100644 index 44b94997fa0..00000000000 --- a/Documentation/arm/SA1100/Itsy +++ /dev/null @@ -1,39 +0,0 @@ -Itsy is a research project done by the Western Research Lab, and Systems -Research Center in Palo Alto, CA. The Itsy project is one of several -research projects at Compaq that are related to pocket computing. - -For more information, see: - - 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 -64 Meg of DRAM and 32 Meg of Flash. The initial work includes support for -serial console (to see what you're doing). No other devices have been -enabled. - -To build, do a "make menuconfig" (or xmenuconfig) and select Itsy support. -Disable Flash and LCD support. and then do a make zImage. -Finally, you will need to cd to arch/arm/boot/tools and execute a make there -to build the params-itsy program used to boot the kernel. - -In order to install the port of 2.4 to the itsy, You will need to set the -configuration parameters in the monitor as follows: -Arg 1:0x08340000, Arg2: 0xC0000000, Arg3:18 (0x12), Arg4:0 -Make sure the start-routine address is set to 0x00060000. - -Next, flash the params-itsy program to 0x00060000 ("p 1 0x00060000" in the -flash menu) Flash the kernel in arch/arm/boot/zImage into 0x08340000 -("p 1 0x00340000"). Finally flash an initial ramdisk into 0xC8000000 -("p 2 0x0") We used ramdisk-2-30.gz from the 0.11 version directory on -handhelds.org. - -The serial connection we established was at: - 8-bit data, no parity, 1 stop bit(s), 115200.00 b/s. in the monitor, in the -params-itsy program, and in the kernel itself. This can be changed, but -not easily. The monitor parameters are easily changed, the params program -setup is assembly outl's, and the kernel is a configuration item specific to -the itsy. (i.e. grep for CONFIG_SA1100_ITSY and you'll find where it is.) - - -This should get you a properly booting 2.4 kernel on the itsy. diff --git a/Documentation/arm/SA1100/LART b/Documentation/arm/SA1100/LART deleted file mode 100644 index 6d412b68559..00000000000 --- a/Documentation/arm/SA1100/LART +++ /dev/null @@ -1,14 +0,0 @@ -Linux Advanced Radio Terminal (LART) ------------------------------------- - -The LART is a small (7.5 x 10cm) SA-1100 board, designed for embedded -applications. It has 32 MB DRAM, 4MB Flash ROM, double RS232 and all -other StrongARM-gadgets. Almost all SA signals are directly accessible -through a number of connectors. The powersupply accepts voltages -between 3.5V and 16V and is overdimensioned to support a range of -daughterboards. A quad Ethernet / IDE / PS2 / sound daughterboard -is under development, with plenty of others in different stages of -planning. - -The hardware designs for this board have been released under an open license; -see the LART page at http://www.lartmaker.nl/ for more information. diff --git a/Documentation/arm/SA1100/PLEB b/Documentation/arm/SA1100/PLEB deleted file mode 100644 index b9c8a631a35..00000000000 --- a/Documentation/arm/SA1100/PLEB +++ /dev/null @@ -1,11 +0,0 @@ -The PLEB project was started as a student initiative at the School of -Computer Science and Engineering, University of New South Wales to make a -pocket computer capable of running the Linux Kernel. - -PLEB support has yet to be fully integrated. - -For more information, see: - - http://www.cse.unsw.edu.au - - diff --git a/Documentation/arm/SA1100/Pangolin b/Documentation/arm/SA1100/Pangolin deleted file mode 100644 index 077a6120e12..00000000000 --- a/Documentation/arm/SA1100/Pangolin +++ /dev/null @@ -1,23 +0,0 @@ -Pangolin is a StrongARM 1110-based evaluation platform produced -by Dialogue Technology (http://www.dialogue.com.tw/). -It has EISA slots for ease of configuration with SDRAM/Flash -memory card, USB/Serial/Audio card, Compact Flash card, -PCMCIA/IDE card and TFT-LCD card. - -To compile for Pangolin, you must issue the following commands: - - make pangolin_config - make oldconfig - make zImage - -Supported peripherals: -- SA1110 serial port (UART1/UART2/UART3) -- flash memory access -- compact flash driver -- UDA1341 sound driver -- SA1100 LCD controller for 800x600 16bpp TFT-LCD -- MQ-200 driver for 800x600 16bpp TFT-LCD -- Penmount(touch panel) driver -- PCMCIA driver -- SMC91C94 LAN driver -- IDE driver (experimental) diff --git a/Documentation/arm/SA1100/Tifon b/Documentation/arm/SA1100/Tifon deleted file mode 100644 index dd1934d9c85..00000000000 --- a/Documentation/arm/SA1100/Tifon +++ /dev/null @@ -1,7 +0,0 @@ -Tifon ------ - -More info has to come... - -Contact: Peter Danielsson <peter.danielsson@era-t.ericsson.se> - diff --git a/Documentation/arm/SA1100/Victor b/Documentation/arm/SA1100/Victor deleted file mode 100644 index 9cff415da5a..00000000000 --- a/Documentation/arm/SA1100/Victor +++ /dev/null @@ -1,16 +0,0 @@ -Victor is known as a "digital talking book player" manufactured by -VisuAide, Inc. to be used by blind people. - -For more information related to Victor, see: - - 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: - - nico@visuaide.com - nico@fluxnic.net - -For any comments, please feel free to contact me through the above -addresses. - diff --git a/Documentation/arm/SA1100/Yopy b/Documentation/arm/SA1100/Yopy deleted file mode 100644 index e14f16d836a..00000000000 --- a/Documentation/arm/SA1100/Yopy +++ /dev/null @@ -1,2 +0,0 @@ -See http://www.yopydeveloper.org for more. - diff --git a/Documentation/arm/SA1100/empeg b/Documentation/arm/SA1100/empeg deleted file mode 100644 index 4ece4849a42..00000000000 --- a/Documentation/arm/SA1100/empeg +++ /dev/null @@ -1,2 +0,0 @@ -See ../empeg/README - diff --git a/Documentation/arm/SA1100/nanoEngine b/Documentation/arm/SA1100/nanoEngine deleted file mode 100644 index 48a7934f95f..00000000000 --- a/Documentation/arm/SA1100/nanoEngine +++ /dev/null @@ -1,11 +0,0 @@ -nanoEngine ----------- - -"nanoEngine" is a SA1110 based single board computer from -Bright Star Engineering Inc. See www.brightstareng.com/arm -for more info. -(Ref: Stuart Adams <sja@brightstareng.com>) - -Also visit Larry Doolittle's "Linux for the nanoEngine" site: -http://www.brightstareng.com/arm/nanoeng.htm - diff --git a/Documentation/arm/SA1100/serial_UART b/Documentation/arm/SA1100/serial_UART deleted file mode 100644 index a63966f1d08..00000000000 --- a/Documentation/arm/SA1100/serial_UART +++ /dev/null @@ -1,47 +0,0 @@ -The SA1100 serial port had its major/minor numbers officially assigned: - -> Date: Sun, 24 Sep 2000 21:40:27 -0700 -> From: H. Peter Anvin <hpa@transmeta.com> -> To: Nicolas Pitre <nico@CAM.ORG> -> Cc: Device List Maintainer <device@lanana.org> -> Subject: Re: device -> -> Okay. Note that device numbers 204 and 205 are used for "low density -> serial devices", so you will have a range of minors on those majors (the -> tty device layer handles this just fine, so you don't have to worry about -> doing anything special.) -> -> So your assignments are: -> -> 204 char Low-density serial ports -> 5 = /dev/ttySA0 SA1100 builtin serial port 0 -> 6 = /dev/ttySA1 SA1100 builtin serial port 1 -> 7 = /dev/ttySA2 SA1100 builtin serial port 2 -> -> 205 char Low-density serial ports (alternate device) -> 5 = /dev/cusa0 Callout device for ttySA0 -> 6 = /dev/cusa1 Callout device for ttySA1 -> 7 = /dev/cusa2 Callout device for ttySA2 -> - -You must create those inodes in /dev on the root filesystem used -by your SA1100-based device: - - mknod ttySA0 c 204 5 - mknod ttySA1 c 204 6 - mknod ttySA2 c 204 7 - mknod cusa0 c 205 5 - mknod cusa1 c 205 6 - mknod cusa2 c 205 7 - -In addition to the creation of the appropriate device nodes above, you -must ensure your user space applications make use of the correct device -name. The classic example is the content of the /etc/inittab file where -you might have a getty process started on ttyS0. In this case: - -- replace occurrences of ttyS0 with ttySA0, ttyS1 with ttySA1, etc. - -- don't forget to add 'ttySA0', 'console', or the appropriate tty name - in /etc/securetty for root to be allowed to login as well. - - diff --git a/Documentation/arm/SH-Mobile/Makefile b/Documentation/arm/SH-Mobile/Makefile deleted file mode 100644 index 8771d832cf8..00000000000 --- a/Documentation/arm/SH-Mobile/Makefile +++ /dev/null @@ -1,8 +0,0 @@ -BIN := vrl4 - -.PHONY: all -all: $(BIN) - -.PHONY: clean -clean: - rm -f *.o $(BIN) diff --git a/Documentation/arm/SH-Mobile/vrl4.c b/Documentation/arm/SH-Mobile/vrl4.c deleted file mode 100644 index e8a191358ad..00000000000 --- a/Documentation/arm/SH-Mobile/vrl4.c +++ /dev/null @@ -1,169 +0,0 @@ -/* - * vrl4 format generator - * - * Copyright (C) 2010 Simon Horman - * - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - */ - -/* - * usage: vrl4 < zImage > out - * dd if=out of=/dev/sdx bs=512 seek=1 # Write the image to sector 1 - * - * Reads a zImage from stdin and writes a vrl4 image to stdout. - * In practice this means writing a padded vrl4 header to stdout followed - * by the zImage. - * - * The padding places the zImage at ALIGN bytes into the output. - * The vrl4 uses ALIGN + START_BASE as the start_address. - * This is where the mask ROM will jump to after verifying the header. - * - * The header sets copy_size to min(sizeof(zImage), MAX_BOOT_PROG_LEN) + ALIGN. - * That is, the mask ROM will load the padded header (ALIGN bytes) - * And then MAX_BOOT_PROG_LEN bytes of the image, or the entire image, - * whichever is smaller. - * - * The zImage is not modified in any way. - */ - -#define _BSD_SOURCE -#include <endian.h> -#include <unistd.h> -#include <stdint.h> -#include <stdio.h> -#include <errno.h> - -struct hdr { - uint32_t magic1; - uint32_t reserved1; - uint32_t magic2; - uint32_t reserved2; - uint16_t copy_size; - uint16_t boot_options; - uint32_t reserved3; - uint32_t start_address; - uint32_t reserved4; - uint32_t reserved5; - char reserved6[308]; -}; - -#define DECLARE_HDR(h) \ - struct hdr (h) = { \ - .magic1 = htole32(0xea000000), \ - .reserved1 = htole32(0x56), \ - .magic2 = htole32(0xe59ff008), \ - .reserved3 = htole16(0x1) } - -/* Align to 512 bytes, the MMCIF sector size */ -#define ALIGN_BITS 9 -#define ALIGN (1 << ALIGN_BITS) - -#define START_BASE 0xe55b0000 - -/* - * With an alignment of 512 the header uses the first sector. - * There is a 128 sector (64kbyte) limit on the data loaded by the mask ROM. - * So there are 127 sectors left for the boot programme. But in practice - * Only a small portion of a zImage is needed, 16 sectors should be more - * than enough. - * - * Note that this sets how much of the zImage is copied by the mask ROM. - * The entire zImage is present after the header and is loaded - * by the code in the boot program (which is the first portion of the zImage). - */ -#define MAX_BOOT_PROG_LEN (16 * 512) - -#define ROUND_UP(x) ((x + ALIGN - 1) & ~(ALIGN - 1)) - -ssize_t do_read(int fd, void *buf, size_t count) -{ - size_t offset = 0; - ssize_t l; - - while (offset < count) { - l = read(fd, buf + offset, count - offset); - if (!l) - break; - if (l < 0) { - if (errno == EAGAIN || errno == EWOULDBLOCK) - continue; - perror("read"); - return -1; - } - offset += l; - } - - return offset; -} - -ssize_t do_write(int fd, const void *buf, size_t count) -{ - size_t offset = 0; - ssize_t l; - - while (offset < count) { - l = write(fd, buf + offset, count - offset); - if (l < 0) { - if (errno == EAGAIN || errno == EWOULDBLOCK) - continue; - perror("write"); - return -1; - } - offset += l; - } - - return offset; -} - -ssize_t write_zero(int fd, size_t len) -{ - size_t i = len; - - while (i--) { - const char x = 0; - if (do_write(fd, &x, 1) < 0) - return -1; - } - - return len; -} - -int main(void) -{ - DECLARE_HDR(hdr); - char boot_program[MAX_BOOT_PROG_LEN]; - size_t aligned_hdr_len, alligned_prog_len; - ssize_t prog_len; - - prog_len = do_read(0, boot_program, sizeof(boot_program)); - if (prog_len <= 0) - return -1; - - aligned_hdr_len = ROUND_UP(sizeof(hdr)); - hdr.start_address = htole32(START_BASE + aligned_hdr_len); - alligned_prog_len = ROUND_UP(prog_len); - hdr.copy_size = htole16(aligned_hdr_len + alligned_prog_len); - - if (do_write(1, &hdr, sizeof(hdr)) < 0) - return -1; - if (write_zero(1, aligned_hdr_len - sizeof(hdr)) < 0) - return -1; - - if (do_write(1, boot_program, prog_len) < 0) - return 1; - - /* Write out the rest of the kernel */ - while (1) { - prog_len = do_read(0, boot_program, sizeof(boot_program)); - if (prog_len < 0) - return 1; - if (prog_len == 0) - break; - if (do_write(1, boot_program, prog_len) < 0) - return 1; - } - - return 0; -} diff --git a/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt b/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt deleted file mode 100644 index efff8ae2713..00000000000 --- a/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt +++ /dev/null @@ -1,29 +0,0 @@ -ROM-able zImage boot from MMC ------------------------------ - -An ROM-able zImage compiled with ZBOOT_ROM_MMCIF may be written to MMC and -SuperH Mobile ARM will to boot directly from the MMCIF hardware block. - -This is achieved by the mask ROM loading the first portion of the image into -MERAM and then jumping to it. This portion contains loader code which -copies the entire image to SDRAM and jumps to it. From there the zImage -boot code proceeds as normal, uncompressing the image into its final -location and then jumping to it. - -This code has been tested on an AP4EB board using the developer 1A eMMC -boot mode which is configured using the following jumper settings. -The board used for testing required a patched mask ROM in order for -this mode to function. - - 8 7 6 5 4 3 2 1 - x|x|x|x|x| |x| -S4 -+-+-+-+-+-+-+- - | | | | |x| |x on - -The zImage must be written to the MMC card at sector 1 (512 bytes) in -vrl4 format. A utility vrl4 is supplied to accomplish this. - -e.g. - vrl4 < zImage | dd of=/dev/sdX bs=512 seek=1 - -A dual-voltage MMC 4.0 card was used for testing. diff --git a/Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt b/Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt deleted file mode 100644 index 441959846e1..00000000000 --- a/Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt +++ /dev/null @@ -1,42 +0,0 @@ -ROM-able zImage boot from eSD ------------------------------ - -An ROM-able zImage compiled with ZBOOT_ROM_SDHI may be written to eSD and -SuperH Mobile ARM will to boot directly from the SDHI hardware block. - -This is achieved by the mask ROM loading the first portion of the image into -MERAM and then jumping to it. This portion contains loader code which -copies the entire image to SDRAM and jumps to it. From there the zImage -boot code proceeds as normal, uncompressing the image into its final -location and then jumping to it. - -This code has been tested on an mackerel board using the developer 1A eSD -boot mode which is configured using the following jumper settings. - - 8 7 6 5 4 3 2 1 - x|x|x|x| |x|x| -S4 -+-+-+-+-+-+-+- - | | | |x| | |x on - -The eSD card needs to be present in SDHI slot 1 (CN7). -As such S1 and S33 also need to be configured as per -the notes in arch/arm/mach-shmobile/board-mackerel.c. - -A partial zImage must be written to physical partition #1 (boot) -of the eSD at sector 0 in vrl4 format. A utility vrl4 is supplied to -accomplish this. - -e.g. - vrl4 < zImage | dd of=/dev/sdX bs=512 count=17 - -A full copy of _the same_ zImage should be written to physical partition #1 -(boot) of the eSD at sector 0. This should _not_ be in vrl4 format. - - vrl4 < zImage | dd of=/dev/sdX bs=512 - -Note: The commands above assume that the physical partition has been -switched. No such facility currently exists in the Linux Kernel. - -Physical partitions are described in the eSD specification. At the time of -writing they are not the same as partitions that are typically configured -using fdisk and visible through /proc/partitions diff --git a/Documentation/arm/SPEAr/overview.txt b/Documentation/arm/SPEAr/overview.txt deleted file mode 100644 index 65610bf52eb..00000000000 --- a/Documentation/arm/SPEAr/overview.txt +++ /dev/null @@ -1,63 +0,0 @@ - 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 SPEAr1310, - SPEAr1340, SPEAr300, SPEAr310, SPEAr320 and SPEAr600 SOCs are supported. - - Hierarchy in SPEAr is as follows: - - SPEAr (Platform) - - SPEAr3XX (3XX SOC series, based on ARM9) - - SPEAr300 (SOC) - - SPEAr300 Evaluation Board - - SPEAr310 (SOC) - - SPEAr310 Evaluation Board - - SPEAr320 (SOC) - - SPEAr320 Evaluation Board - - SPEAr6XX (6XX SOC series, based on ARM9) - - SPEAr600 (SOC) - - SPEAr600 Evaluation Board - - SPEAr13XX (13XX SOC series, based on ARM CORTEXA9) - - SPEAr1310 (SOC) - - SPEAr1310 Evaluation Board - - SPEAr1340 (SOC) - - SPEAr1340 Evaluation Board - - Configuration - ------------- - - A generic configuration is provided for each machine, and can be used as the - default by - make spear13xx_defconfig - make spear3xx_defconfig - make spear6xx_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, for - spear6xx is mach-spear6xx/spear6xx.c and for spear13xx family is - mach-spear13xx/spear13xx.c. mach-spear* also contain soc/machine specific - files, like spear1310.c, spear1340.c spear300.c, spear310.c, spear320.c and - spear600.c. mach-spear* doesn't contains board specific files as they fully - support Flattened Device Tree. - - - Document Author - --------------- - - Viresh Kumar <viresh.linux@gmail.com>, (c) 2010-2012 ST Microelectronics diff --git a/Documentation/arm/Samsung-S3C24XX/CPUfreq.txt b/Documentation/arm/Samsung-S3C24XX/CPUfreq.txt deleted file mode 100644 index fa968aa99d6..00000000000 --- a/Documentation/arm/Samsung-S3C24XX/CPUfreq.txt +++ /dev/null @@ -1,75 +0,0 @@ - S3C24XX CPUfreq support - ======================= - -Introduction ------------- - - The S3C24XX series support a number of power saving systems, such as - the ability to change the core, memory and peripheral operating - frequencies. The core control is exported via the CPUFreq driver - which has a number of different manual or automatic controls over the - rate the core is running at. - - There are two forms of the driver depending on the specific CPU and - 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 separate PLL and clock divider for the - ARM core is available as a separate driver. - - -Layout ------- - - The code core manages the CPU specific drivers, any data that they - need to register and the interface to the generic drivers/cpufreq - system. Each CPU registers a driver to control the PLL, clock dividers - and anything else associated with it. Any board that wants to use this - framework needs to supply at least basic details of what is required. - - The core registers with drivers/cpufreq at init time if all the data - necessary has been supplied. - - -CPU support ------------ - - The support for each CPU depends on the facilities provided by the - SoC and the driver as each device has different PLL and clock chains - associated with it. - - -Slow Mode ---------- - - The SLOW mode where the PLL is turned off altogether and the - system is fed by the external crystal input is currently not - supported. - - -sysfs ------ - - The core code exports extra information via sysfs in the directory - devices/system/cpu/cpu0/arch-freq. - - -Board Support -------------- - - Each board that wants to use the cpufreq code must register some basic - information with the core driver to provide information about what the - board requires and any restrictions being placed on it. - - The board needs to supply information about whether it needs the IO bank - timings changing, any maximum frequency limits and information about the - SDRAM refresh rate. - - - - -Document Author ---------------- - -Ben Dooks, Copyright 2009 Simtec Electronics -Licensed under GPLv2 diff --git a/Documentation/arm/Samsung-S3C24XX/DMA.txt b/Documentation/arm/Samsung-S3C24XX/DMA.txt deleted file mode 100644 index 3ed82383efe..00000000000 --- a/Documentation/arm/Samsung-S3C24XX/DMA.txt +++ /dev/null @@ -1,46 +0,0 @@ - S3C2410 DMA - =========== - -Introduction ------------- - - The kernel provides an interface to manage DMA transfers - using the DMA channels in the CPU, so that the central - duty of managing channel mappings, and programming the - channel generators is in one place. - - -DMA Channel Ordering --------------------- - - Many of the range do not have connections for the DMA - channels to all sources, which means that some devices - have a restricted number of channels that can be used. - - To allow flexibility for each CPU type and board, the - DMA code can be given a DMA ordering structure which - allows the order of channel search to be specified, as - well as allowing the prohibition of certain claims. - - struct s3c24xx_dma_order has a list of channels, and - each channel within has a slot for a list of DMA - channel numbers. The slots are searched in order for - the presence of a DMA channel number with DMA_CH_VALID - or-ed in. - - If the order has the flag DMA_CH_NEVER set, then after - checking the channel list, the system will return no - found channel, thus denying the request. - - A board support file can call s3c24xx_dma_order_set() - to register a complete ordering set. The routine will - copy the data, so the original can be discarded with - __initdata. - - -Authour -------- - -Ben Dooks, -Copyright (c) 2007 Ben Dooks, Simtec Electronics -Licensed under the GPL v2 diff --git a/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt b/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt deleted file mode 100644 index b87292e05f2..00000000000 --- a/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt +++ /dev/null @@ -1,58 +0,0 @@ - Simtec Electronics EB2410ITX (BAST) - =================================== - - http://www.simtec.co.uk/products/EB2410ITX/ - -Introduction ------------- - - The EB2410ITX is a S3C2410 based development board with a variety of - peripherals and expansion connectors. This board is also known by - the shortened name of Bast. - - -Configuration -------------- - - To set the default configuration, use `make bast_defconfig` which - supports the commonly used features of this board. - - -Support -------- - - Official support information can be found on the Simtec Electronics - website, at the product page http://www.simtec.co.uk/products/EB2410ITX/ - - Useful links: - - - Resources Page http://www.simtec.co.uk/products/EB2410ITX/resources.html - - - Board FAQ at http://www.simtec.co.uk/products/EB2410ITX/faq.html - - - Bootloader info http://www.simtec.co.uk/products/SWABLE/resources.html - and FAQ http://www.simtec.co.uk/products/SWABLE/faq.html - - -MTD ---- - - The NAND and NOR support has been merged from the linux-mtd project. - Any problems, see http://www.linux-mtd.infradead.org/ for more - information or up-to-date versions of linux-mtd. - - -IDE ---- - - Both onboard IDE ports are supported, however there is no support for - changing speed of devices, PIO Mode 4 capable drives should be used. - - -Maintainers ------------ - - This board is maintained by Simtec Electronics. - - -Copyright 2004 Ben Dooks, Simtec Electronics diff --git a/Documentation/arm/Samsung-S3C24XX/GPIO.txt b/Documentation/arm/Samsung-S3C24XX/GPIO.txt deleted file mode 100644 index 816d6071669..00000000000 --- a/Documentation/arm/Samsung-S3C24XX/GPIO.txt +++ /dev/null @@ -1,214 +0,0 @@ - S3C2410 GPIO Control - ==================== - -Introduction ------------- - - The s3c2410 kernel provides an interface to configure and - manipulate the state of the GPIO pins, and find out other - information about them. - - There are a number of conditions attached to the configuration - 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 -------- - - With the event of the GPIOLIB in drivers/gpio, support for some - of the GPIO functions such as reading and writing a pin will - be removed in favour of this common access method. - - Once all the extant drivers have been converted, the functions - listed below will be removed (they may be marked as __deprecated - in the near future). - - 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 -------- - - See arch/arm/mach-s3c2410/include/mach/regs-gpio.h for the list - of GPIO pins, and the configuration values for them. This - is included by using #include <mach/regs-gpio.h> - - The GPIO management functions are defined in the hardware - header arch/arm/mach-s3c2410/include/mach/hardware.h which can be - included by #include <mach/hardware.h> - - A useful amount of documentation can be found in the hardware - header on how the GPIO functions (and others) work. - - Whilst a number of these functions do make some checks on what - is passed to them, for speed of use, they may not always ensure - that the user supplied data to them is correct. - - -PIN Numbers ------------ - - Each pin has an unique number associated with it in regs-gpio.h, - 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 ------------------ - - The following function allows the configuration of a given pin to - be changed. - - void s3c2410_gpio_cfgpin(unsigned int pin, unsigned int function); - - Eg: - - s3c2410_gpio_cfgpin(S3C2410_GPA(0), S3C2410_GPA0_ADDR0); - s3c2410_gpio_cfgpin(S3C2410_GPE(8), S3C2410_GPE8_SDDAT1); - - 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 ---------------------------------- - - The current configuration of a pin can be read by using: - - s3c2410_gpio_getcfg(unsigned int pin); - - 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 ------------------------------- - - A large proportion of the GPIO pins on the S3C2410 can have weak - pull-up resistors enabled. This can be configured by the following - function: - - void s3c2410_gpio_pullup(unsigned int pin, unsigned int to); - - 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 --------------------------- - - The state of a pin can be read by using the function: - - unsigned int s3c2410_gpio_getpin(unsigned int 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 --------------------------- - - The value an pin is outputing can be modified by using the following: - - void s3c2410_gpio_setpin(unsigned int pin, unsigned int to); - - 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 --------------------------------------------- - - The following function can map the given pin number to an IRQ - number to pass to the IRQ system. - - int s3c2410_gpio_getirq(unsigned int 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 -------- - - -Ben Dooks, 03 October 2004 -Copyright 2004 Ben Dooks, Simtec Electronics diff --git a/Documentation/arm/Samsung-S3C24XX/H1940.txt b/Documentation/arm/Samsung-S3C24XX/H1940.txt deleted file mode 100644 index f4a7b22c866..00000000000 --- a/Documentation/arm/Samsung-S3C24XX/H1940.txt +++ /dev/null @@ -1,40 +0,0 @@ - HP IPAQ H1940 - ============= - -http://www.handhelds.org/projects/h1940.html - -Introduction ------------- - - The HP H1940 is a S3C2410 based handheld device, with - bluetooth connectivity. - - -Support -------- - - A variety of information is available - - handhelds.org project page: - - http://www.handhelds.org/projects/h1940.html - - handhelds.org wiki page: - - http://handhelds.org/moin/moin.cgi/HpIpaqH1940 - - Herbert Pötzl pages: - - http://vserver.13thfloor.at/H1940/ - - -Maintainers ------------ - - This project is being maintained and developed by a variety - of people, including Ben Dooks, Arnaud Patard, and Herbert Pötzl. - - Thanks to the many others who have also provided support. - - -(c) 2005 Ben Dooks
\ No newline at end of file diff --git a/Documentation/arm/Samsung-S3C24XX/NAND.txt b/Documentation/arm/Samsung-S3C24XX/NAND.txt deleted file mode 100644 index bc478a3409b..00000000000 --- a/Documentation/arm/Samsung-S3C24XX/NAND.txt +++ /dev/null @@ -1,30 +0,0 @@ - S3C24XX NAND Support - ==================== - -Introduction ------------- - -Small Page NAND ---------------- - -The driver uses a 512 byte (1 page) ECC code for this setup. The -ECC code is not directly compatible with the default kernel ECC -code, so the driver enforces its own OOB layout and ECC parameters - -Large Page NAND ---------------- - -The driver is capable of handling NAND flash with a 2KiB page -size, with support for hardware ECC generation and correction. - -Unlike the 512byte page mode, the driver generates ECC data for -each 256 byte block in an 2KiB page. This means that more than -one error in a page can be rectified. It also means that the -OOB layout remains the default kernel layout for these flashes. - - -Document Author ---------------- - -Ben Dooks, Copyright 2007 Simtec Electronics - diff --git a/Documentation/arm/Samsung-S3C24XX/Overview.txt b/Documentation/arm/Samsung-S3C24XX/Overview.txt deleted file mode 100644 index 359587b2367..00000000000 --- a/Documentation/arm/Samsung-S3C24XX/Overview.txt +++ /dev/null @@ -1,318 +0,0 @@ - S3C24XX ARM Linux Overview - ========================== - - - -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, S3C2416, S3C2440, S3C2442, S3C2443 and S3C2450 devices - are supported. - - Support for the S3C2400 and S3C24A0 series was never completed and the - corresponding code has been removed after a while. If someone wishes to - revive this effort, partial support can be retrieved from earlier Linux - versions. - - 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 -------------- - - A generic S3C2410 configuration is provided, and can be used as the - default by `make s3c2410_defconfig`. This configuration has support - for all the machines, and the commonly used features on them. - - Certain machines may have their own default configurations as well, - please check the machine specific documentation. - - -Layout ------- - - The core support files are located in the platform code contained in - arch/arm/plat-s3c24xx with headers in include/asm-arm/plat-s3c24xx. - This directory should be kept to items shared between the platform - code (arch/arm/plat-s3c24xx) and the arch/arm/mach-s3c24* code. - - Each cpu has a directory with the support files for it, and the - machines that carry the device. For example S3C2410 is contained - in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440 - - Register, kernel and platform data definitions are held in the - arch/arm/mach-s3c2410 directory./include/mach - -arch/arm/plat-s3c24xx: - - Files in here are either common to all the s3c24xx family, - or are common to only some of them with names to indicate this - status. The files that are not common to all are generally named - with the initial cpu they support in the series to ensure a short - name without any possibility of confusion with newer devices. - - As an example, initially s3c244x would cover s3c2440 and s3c2442, but - with the s3c2443 which does not share many of the same drivers in - this directory, the name becomes invalid. We stick to s3c2440-<x> - to indicate a driver that is s3c2440 and s3c2442 compatible. - - This does mean that to find the status of any given SoC, a number - of directories may need to be searched. - - -Machines --------- - - The currently supported machines are as follows: - - Simtec Electronics EB2410ITX (BAST) - - A general purpose development board, see EB2410ITX.txt for further - details - - Simtec Electronics IM2440D20 (Osiris) - - CPU Module from Simtec Electronics, with a S3C2440A CPU, nand flash - and a PCMCIA controller. - - Samsung SMDK2410 - - Samsung's own development board, geared for PDA work. - - Samsung/Aiji SMDK2412 - - The S3C2412 version of the SMDK2440. - - Samsung/Aiji SMDK2413 - - The S3C2412 version of the SMDK2440. - - Samsung/Meritech SMDK2440 - - The S3C2440 compatible version of the SMDK2440, which has the - option of an S3C2440 or S3C2442 CPU module. - - Thorcom VR1000 - - Custom embedded board - - HP IPAQ 1940 - - Handheld (IPAQ), available in several varieties - - HP iPAQ rx3715 - - S3C2440 based IPAQ, with a number of variations depending on - features shipped. - - Acer N30 - - A S3C2410 based PDA from Acer. There is a Wiki page at - http://handhelds.org/moin/moin.cgi/AcerN30Documentation . - - AML M5900 - - American Microsystems' M5900 - - Nex Vision Nexcoder - Nex Vision Otom - - Two machines by Nex Vision - - -Adding New Machines -------------------- - - The architecture has been designed to support as many machines as can - be configured for it in one kernel build, and any future additions - should keep this in mind before altering items outside of their own - machine files. - - Machine definitions should be kept in linux/arch/arm/mach-s3c2410, - and there are a number of examples that can be looked at. - - Read the kernel patch submission policies as well as the - Documentation/arm directory before submitting patches. The - ARM kernel series is managed by Russell King, and has a patch system - located at http://www.arm.linux.org.uk/developer/patches/ - as well as mailing lists that can be found from the same site. - - As a courtesy, please notify <ben-linux@fluff.org> of any new - machines or other modifications. - - Any large scale modifications, or new drivers should be discussed - on the ARM kernel mailing list (linux-arm-kernel) before being - attempted. See http://www.arm.linux.org.uk/mailinglists/ for the - mailing list information. - - -I2C ---- - - The hardware I2C core in the CPU is supported in single master - mode, and can be configured via platform data. - - -RTC ---- - - Support for the onboard RTC unit, including alarm function. - - This has recently been upgraded to use the new RTC core, - and the module has been renamed to rtc-s3c to fit in with - the new rtc naming scheme. - - -Watchdog --------- - - The onchip watchdog is available via the standard watchdog - interface. - - -NAND ----- - - The current kernels now have support for the s3c2410 NAND - controller. If there are any problems the latest linux-mtd - code can be found from http://www.linux-mtd.infradead.org/ - - For more information see Documentation/arm/Samsung-S3C24XX/NAND.txt - - -SD/MMC ------- - - The SD/MMC hardware pre S3C2443 is supported in the current - kernel, the driver is drivers/mmc/host/s3cmci.c and supports - 1 and 4 bit SD or MMC cards. - - The SDIO behaviour of this driver has not been fully tested. There is no - current support for hardware SDIO interrupts. - - -Serial ------- - - The s3c2410 serial driver provides support for the internal - serial ports. These devices appear as /dev/ttySAC0 through 3. - - To create device nodes for these, use the following commands - - mknod ttySAC0 c 204 64 - mknod ttySAC1 c 204 65 - mknod ttySAC2 c 204 66 - - -GPIO ----- - - The core contains support for manipulating the GPIO, see the - documentation in GPIO.txt in the same directory as this file. - - 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 ----------------- - - The core provides the interface defined in the header file - include/asm-arm/hardware/clock.h, to allow control over the - various clock units - - -Suspend to RAM --------------- - - For boards that provide support for suspend to RAM, the - system can be placed into low power suspend. - - See Suspend.txt for more information. - - -SPI ---- - - SPI drivers are available for both the in-built hardware - (although there is no DMA support yet) and a generic - GPIO based solution. - - -LEDs ----- - - There is support for GPIO based LEDs via a platform driver - in the LED subsystem. - - -Platform Data -------------- - - Whenever a device has platform specific data that is specified - on a per-machine basis, care should be taken to ensure the - following: - - 1) that default data is not left in the device to confuse the - driver if a machine does not set it at startup - - 2) the data should (if possible) be marked as __initdata, - to ensure that the data is thrown away if the machine is - not the one currently in use. - - The best way of doing this is to make a function that - kmalloc()s an area of memory, and copies the __initdata - and then sets the relevant device's platform data. Making - the function `__init` takes care of ensuring it is discarded - with the rest of the initialisation code - - static __init void s3c24xx_xxx_set_platdata(struct xxx_data *pd) - { - struct s3c2410_xxx_mach_info *npd; - - npd = kmalloc(sizeof(struct s3c2410_xxx_mach_info), GFP_KERNEL); - if (npd) { - memcpy(npd, pd, sizeof(struct s3c2410_xxx_mach_info)); - s3c_device_xxx.dev.platform_data = npd; - } else { - printk(KERN_ERR "no memory for xxx platform data\n"); - } - } - - Note, since the code is marked as __init, it should not be - exported outside arch/arm/mach-s3c2410/, or exported to - modules via EXPORT_SYMBOL() and related functions. - - -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 ---------------- - -Ben Dooks, Copyright 2004-2006 Simtec Electronics diff --git a/Documentation/arm/Samsung-S3C24XX/S3C2412.txt b/Documentation/arm/Samsung-S3C24XX/S3C2412.txt deleted file mode 100644 index f057876b920..00000000000 --- a/Documentation/arm/Samsung-S3C24XX/S3C2412.txt +++ /dev/null @@ -1,120 +0,0 @@ - S3C2412 ARM Linux Overview - ========================== - -Introduction ------------- - - The S3C2412 is part of the S3C24XX range of ARM9 System-on-Chip CPUs - from Samsung. This part has an ARM926-EJS core, capable of running up - to 266MHz (see data-sheet for more information) - - -Clock ------ - - The core clock code provides a set of clocks to the drivers, and allows - for source selection and a number of other features. - - -Power ------ - - No support for suspend/resume to RAM in the current system. - - -DMA ---- - - No current support for DMA. - - -GPIO ----- - - There is support for setting the GPIO to input/output/special function - and reading or writing to them. - - -UART ----- - - The UART hardware is similar to the S3C2440, and is supported by the - s3c2410 driver in the drivers/serial directory. - - -NAND ----- - - The NAND hardware is similar to the S3C2440, and is supported by the - s3c2410 driver in the drivers/mtd/nand directory. - - -USB Host --------- - - The USB hardware is similar to the S3C2410, with extended clock source - control. The OHCI portion is supported by the ohci-s3c2410 driver, and - the clock control selection is supported by the core clock code. - - -USB Device ----------- - - No current support in the kernel - - -IRQs ----- - - All the standard, and external interrupt sources are supported. The - extra sub-sources are not yet supported. - - -RTC ---- - - The RTC hardware is similar to the S3C2410, and is supported by the - s3c2410-rtc driver. - - -Watchdog --------- - - The watchdog hardware is the same as the S3C2410, and is supported by - the s3c2410_wdt driver. - - -MMC/SD/SDIO ------------ - - No current support for the MMC/SD/SDIO block. - -IIC ---- - - The IIC hardware is the same as the S3C2410, and is supported by the - i2c-s3c24xx driver. - - -IIS ---- - - No current support for the IIS interface. - - -SPI ---- - - No current support for the SPI interfaces. - - -ATA ---- - - No current support for the on-board ATA block. - - -Document Author ---------------- - -Ben Dooks, Copyright 2006 Simtec Electronics diff --git a/Documentation/arm/Samsung-S3C24XX/S3C2413.txt b/Documentation/arm/Samsung-S3C24XX/S3C2413.txt deleted file mode 100644 index 909bdc7dd7b..00000000000 --- a/Documentation/arm/Samsung-S3C24XX/S3C2413.txt +++ /dev/null @@ -1,21 +0,0 @@ - S3C2413 ARM Linux Overview - ========================== - -Introduction ------------- - - The S3C2413 is an extended version of the S3C2412, with an camera - interface and mobile DDR memory support. See the S3C2412 support - documentation for more information. - - -Camera Interface ---------------- - - This block is currently not supported. - - -Document Author ---------------- - -Ben Dooks, Copyright 2006 Simtec Electronics diff --git a/Documentation/arm/Samsung-S3C24XX/SMDK2440.txt b/Documentation/arm/Samsung-S3C24XX/SMDK2440.txt deleted file mode 100644 index 32e1eae6a25..00000000000 --- a/Documentation/arm/Samsung-S3C24XX/SMDK2440.txt +++ /dev/null @@ -1,56 +0,0 @@ - Samsung/Meritech SMDK2440 - ========================= - -Introduction ------------- - - The SMDK2440 is a two part evaluation board for the Samsung S3C2440 - processor. It includes support for LCD, SmartMedia, Audio, SD and - 10MBit Ethernet, and expansion headers for various signals, including - the camera and unused GPIO. - - -Configuration -------------- - - To set the default configuration, use `make smdk2440_defconfig` which - will configure the common features of this board, or use - `make s3c2410_config` to include support for all s3c2410/s3c2440 machines - - -Support -------- - - Ben Dooks' SMDK2440 site at http://www.fluff.org/ben/smdk2440/ which - includes linux based USB download tools. - - Some of the h1940 patches that can be found from the H1940 project - site at http://www.handhelds.org/projects/h1940.html can also be - applied to this board. - - -Peripherals ------------ - - There is no current support for any of the extra peripherals on the - base-board itself. - - -MTD ---- - - The NAND flash should be supported by the in kernel MTD NAND support, - NOR flash will be added later. - - -Maintainers ------------ - - This board is being maintained by Ben Dooks, for more info, see - http://www.fluff.org/ben/smdk2440/ - - Many thanks to Dimitry Andric of TomTom for the loan of the SMDK2440, - and to Simtec Electronics for allowing me time to work on this. - - -(c) 2004 Ben Dooks
\ No newline at end of file diff --git a/Documentation/arm/Samsung-S3C24XX/Suspend.txt b/Documentation/arm/Samsung-S3C24XX/Suspend.txt deleted file mode 100644 index 1ca63b3e563..00000000000 --- a/Documentation/arm/Samsung-S3C24XX/Suspend.txt +++ /dev/null @@ -1,137 +0,0 @@ - S3C24XX Suspend Support - ======================= - - -Introduction ------------- - - The S3C24XX supports a low-power suspend mode, where the SDRAM is kept - in Self-Refresh mode, and all but the essential peripheral blocks are - powered down. For more information on how this works, please look - at the relevant CPU datasheet from Samsung. - - -Requirements ------------- - - 1) A bootloader that can support the necessary resume operation - - 2) Support for at least 1 source for resume - - 3) CONFIG_PM enabled in the kernel - - 4) Any peripherals that are going to be powered down at the same - time require suspend/resume support. - - -Resuming --------- - - The S3C2410 user manual defines the process of sending the CPU to - sleep and how it resumes. The default behaviour of the Linux code - is to set the GSTATUS3 register to the physical address of the - code to resume Linux operation. - - GSTATUS4 is currently left alone by the sleep code, and is free to - use for any other purposes (for example, the EB2410ITX uses this to - save memory configuration in). - - -Machine Support ---------------- - - The machine specific functions must call the s3c_pm_init() function - to say that its bootloader is capable of resuming. This can be as - simple as adding the following to the machine's definition: - - INITMACHINE(s3c_pm_init) - - A board can do its own setup before calling s3c_pm_init, if it - needs to setup anything else for power management support. - - There is currently no support for over-riding the default method of - saving the resume address, if your board requires it, then contact - the maintainer and discuss what is required. - - Note, the original method of adding an late_initcall() is wrong, - and will end up initialising all compiled machines' pm init! - - The following is an example of code used for testing wakeup from - an falling edge on IRQ_EINT0: - - -static irqreturn_t button_irq(int irq, void *pw) -{ - return IRQ_HANDLED; -} - -statuc void __init machine_init(void) -{ - ... - - request_irq(IRQ_EINT0, button_irq, IRQF_TRIGGER_FALLING, - "button-irq-eint0", NULL); - - enable_irq_wake(IRQ_EINT0); - - s3c_pm_init(); -} - - -Debugging ---------- - - There are several important things to remember when using PM suspend: - - 1) The uart drivers will disable the clocks to the UART blocks when - suspending, which means that use of printascii() or similar direct - access to the UARTs will cause the debug to stop. - - 2) Whilst the pm code itself will attempt to re-enable the UART clocks, - care should be taken that any external clock sources that the UARTs - rely on are still enabled at that point. - - 3) If any debugging is placed in the resume path, then it must have the - relevant clocks and peripherals setup before use (ie, bootloader). - - For example, if you transmit a character from the UART, the baud - rate and uart controls must be setup beforehand. - - -Configuration -------------- - - The S3C2410 specific configuration in `System Type` defines various - aspects of how the S3C2410 suspend and resume support is configured - - `S3C2410 PM Suspend debug` - - This option prints messages to the serial console before and after - the actual suspend, giving detailed information on what is - happening - - - `S3C2410 PM Suspend Memory CRC` - - Allows the entire memory to be checksummed before and after the - suspend to see if there has been any corruption of the contents. - - Note, the time to calculate the CRC is dependent on the CPU speed - and the size of memory. For an 64Mbyte RAM area on an 200MHz - S3C2410, this can take approximately 4 seconds to complete. - - This support requires the CRC32 function to be enabled. - - - `S3C2410 PM Suspend CRC Chunksize (KiB)` - - Defines the size of memory each CRC chunk covers. A smaller value - will mean that the CRC data block will take more memory, but will - identify any faults with better precision - - -Document Author ---------------- - -Ben Dooks, Copyright 2004 Simtec Electronics - diff --git a/Documentation/arm/Samsung-S3C24XX/USB-Host.txt b/Documentation/arm/Samsung-S3C24XX/USB-Host.txt deleted file mode 100644 index f82b1faefad..00000000000 --- a/Documentation/arm/Samsung-S3C24XX/USB-Host.txt +++ /dev/null @@ -1,93 +0,0 @@ - S3C24XX USB Host support - ======================== - - - -Introduction ------------- - - This document details the S3C2410/S3C2440 in-built OHCI USB host support. - -Configuration -------------- - - Enable at least the following kernel options: - - menuconfig: - - Device Drivers ---> - USB support ---> - <*> Support for Host-side USB - <*> OHCI HCD support - - - .config: - CONFIG_USB - CONFIG_USB_OHCI_HCD - - - Once these options are configured, the standard set of USB device - drivers can be configured and used. - - -Board Support -------------- - - The driver attaches to a platform device, which will need to be - added by the board specific support file in linux/arch/arm/mach-s3c2410, - such as mach-bast.c or mach-smdk2410.c - - The platform device's platform_data field is only needed if the - board implements extra power control or over-current monitoring. - - The OHCI driver does not ensure the state of the S3C2410's MISCCTRL - register, so if both ports are to be used for the host, then it is - the board support file's responsibility to ensure that the second - port is configured to be connected to the OHCI core. - - -Platform Data -------------- - - See arch/arm/mach-s3c2410/include/mach/usb-control.h for the - descriptions of the platform device data. An implementation - can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c . - - The `struct s3c2410_hcd_info` contains a pair of functions - that get called to enable over-current detection, and to - control the port power status. - - The ports are numbered 0 and 1. - - power_control: - - Called to enable or disable the power on the port. - - enable_oc: - - Called to enable or disable the over-current monitoring. - This should claim or release the resources being used to - check the power condition on the port, such as an IRQ. - - report_oc: - - The OHCI driver fills this field in for the over-current code - to call when there is a change to the over-current state on - an port. The ports argument is a bitmask of 1 bit per port, - with bit X being 1 for an over-current on port X. - - The function s3c2410_usb_report_oc() has been provided to - ensure this is called correctly. - - port[x]: - - This is struct describes each port, 0 or 1. The platform driver - should set the flags field of each port to S3C_HCDFLG_USED if - the port is enabled. - - - -Document Author ---------------- - -Ben Dooks, Copyright 2005 Simtec Electronics diff --git a/Documentation/arm/Samsung/GPIO.txt b/Documentation/arm/Samsung/GPIO.txt deleted file mode 100644 index 513f2562c1a..00000000000 --- a/Documentation/arm/Samsung/GPIO.txt +++ /dev/null @@ -1,42 +0,0 @@ - Samsung GPIO implementation - =========================== - -Introduction ------------- - -This outlines the Samsung GPIO implementation and the architecture -specific 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 deleted file mode 100644 index 658abb258ce..00000000000 --- a/Documentation/arm/Samsung/Overview.txt +++ /dev/null @@ -1,97 +0,0 @@ - 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 - - 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 - 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 deleted file mode 100755 index 0c50220851f..00000000000 --- a/Documentation/arm/Samsung/clksrc-change-registers.awk +++ /dev/null @@ -1,167 +0,0 @@ -#!/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/Setup b/Documentation/arm/Setup deleted file mode 100644 index 0cb1e64bde8..00000000000 --- a/Documentation/arm/Setup +++ /dev/null @@ -1,129 +0,0 @@ -Kernel initialisation parameters on ARM Linux ---------------------------------------------- - -The following document describes the kernel initialisation parameter -structure, otherwise known as 'struct param_struct' which is used -for most ARM Linux architectures. - -This structure is used to pass initialisation parameters from the -kernel loader to the Linux kernel proper, and may be short lived -through the kernel initialisation process. As a general rule, it -should not be referenced outside of arch/arm/kernel/setup.c:setup_arch(). - -There are a lot of parameters listed in there, and they are described -below: - - page_size - - This parameter must be set to the page size of the machine, and - will be checked by the kernel. - - nr_pages - - This is the total number of pages of memory in the system. If - the memory is banked, then this should contain the total number - of pages in the system. - - If the system contains separate VRAM, this value should not - include this information. - - ramdisk_size - - This is now obsolete, and should not be used. - - flags - - Various kernel flags, including: - bit 0 - 1 = mount root read only - bit 1 - unused - bit 2 - 0 = load ramdisk - bit 3 - 0 = prompt for ramdisk - - rootdev - - major/minor number pair of device to mount as the root filesystem. - - video_num_cols - video_num_rows - - These two together describe the character size of the dummy console, - or VGA console character size. They should not be used for any other - purpose. - - It's generally a good idea to set these to be either standard VGA, or - the equivalent character size of your fbcon display. This then allows - all the bootup messages to be displayed correctly. - - video_x - video_y - - This describes the character position of cursor on VGA console, and - is otherwise unused. (should not be used for other console types, and - should not be used for other purposes). - - memc_control_reg - - MEMC chip control register for Acorn Archimedes and Acorn A5000 - based machines. May be used differently by different architectures. - - sounddefault - - Default sound setting on Acorn machines. May be used differently by - different architectures. - - adfsdrives - - Number of ADFS/MFM disks. May be used differently by different - architectures. - - bytes_per_char_h - bytes_per_char_v - - These are now obsolete, and should not be used. - - pages_in_bank[4] - - Number of pages in each bank of the systems memory (used for RiscPC). - This is intended to be used on systems where the physical memory - is non-contiguous from the processors point of view. - - pages_in_vram - - Number of pages in VRAM (used on Acorn RiscPC). This value may also - be used by loaders if the size of the video RAM can't be obtained - from the hardware. - - initrd_start - initrd_size - - This describes the kernel virtual start address and size of the - initial ramdisk. - - rd_start - - Start address in sectors of the ramdisk image on a floppy disk. - - system_rev - - system revision number. - - system_serial_low - system_serial_high - - system 64-bit serial number - - mem_fclk_21285 - - The speed of the external oscillator to the 21285 (footbridge), - which control's the speed of the memory bus, timer & serial port. - Depending upon the speed of the cpu its value can be between - 0-66 MHz. If no params are passed or a value of zero is passed, - then a value of 50 Mhz is the default on 21285 architectures. - - paths[8][128] - - These are now obsolete, and should not be used. - - commandline - - Kernel command line parameters. Details can be found elsewhere. diff --git a/Documentation/arm/VFP/release-notes.txt b/Documentation/arm/VFP/release-notes.txt deleted file mode 100644 index 28a2795705c..00000000000 --- a/Documentation/arm/VFP/release-notes.txt +++ /dev/null @@ -1,55 +0,0 @@ -Release notes for Linux Kernel VFP support code ------------------------------------------------ - -Date: 20 May 2004 -Author: Russell King - -This is the first release of the Linux Kernel VFP support code. It -provides support for the exceptions bounced from VFP hardware found -on ARM926EJ-S. - -This release has been validated against the SoftFloat-2b library by -John R. Hauser using the TestFloat-2a test suite. Details of this -library and test suite can be found at: - - http://www.jhauser.us/arithmetic/SoftFloat.html - -The operations which have been tested with this package are: - - - fdiv - - fsub - - fadd - - fmul - - fcmp - - fcmpe - - fcvtd - - fcvts - - fsito - - ftosi - - fsqrt - -All the above pass softfloat tests with the following exceptions: - -- fadd/fsub shows some differences in the handling of +0 / -0 results - when input operands differ in signs. -- the handling of underflow exceptions is slightly different. If a - result underflows before rounding, but becomes a normalised number - after rounding, we do not signal an underflow exception. - -Other operations which have been tested by basic assembly-only tests -are: - - - fcpy - - fabs - - fneg - - ftoui - - ftosiz - - ftouiz - -The combination operations have not been tested: - - - fmac - - fnmac - - fmsc - - fnmsc - - fnmul diff --git a/Documentation/arm/kernel_user_helpers.txt b/Documentation/arm/kernel_user_helpers.txt deleted file mode 100644 index 5673594717c..00000000000 --- a/Documentation/arm/kernel_user_helpers.txt +++ /dev/null @@ -1,267 +0,0 @@ -Kernel-provided User Helpers -============================ - -These are segment of kernel provided user code reachable from user space -at a fixed address in kernel memory. This is used to provide user space -with some operations which require kernel help because of unimplemented -native feature and/or instructions in many ARM CPUs. The idea is for this -code to be executed directly in user mode for best efficiency but which is -too intimate with the kernel counter part to be left to user libraries. -In fact this code might even differ from one CPU to another depending on -the available instruction set, or whether it is a SMP systems. In other -words, the kernel reserves the right to change this code as needed without -warning. Only the entry points and their results as documented here are -guaranteed to be stable. - -This is different from (but doesn't preclude) a full blown VDSO -implementation, however a VDSO would prevent some assembly tricks with -constants that allows for efficient branching to those code segments. And -since those code segments only use a few cycles before returning to user -code, the overhead of a VDSO indirect far call would add a measurable -overhead to such minimalistic operations. - -User space is expected to bypass those helpers and implement those things -inline (either in the code emitted directly by the compiler, or part of -the implementation of a library call) when optimizing for a recent enough -processor that has the necessary native support, but only if resulting -binaries are already to be incompatible with earlier ARM processors due to -usage of similar native instructions for other things. In other words -don't make binaries unable to run on earlier processors just for the sake -of not using these kernel helpers if your compiled code is not going to -use new instructions for other purpose. - -New helpers may be added over time, so an older kernel may be missing some -helpers present in a newer kernel. For this reason, programs must check -the value of __kuser_helper_version (see below) before assuming that it is -safe to call any particular helper. This check should ideally be -performed only once at process startup time, and execution aborted early -if the required helpers are not provided by the kernel version that -process is running on. - -kuser_helper_version --------------------- - -Location: 0xffff0ffc - -Reference declaration: - - extern int32_t __kuser_helper_version; - -Definition: - - This field contains the number of helpers being implemented by the - running kernel. User space may read this to determine the availability - of a particular helper. - -Usage example: - -#define __kuser_helper_version (*(int32_t *)0xffff0ffc) - -void check_kuser_version(void) -{ - if (__kuser_helper_version < 2) { - fprintf(stderr, "can't do atomic operations, kernel too old\n"); - abort(); - } -} - -Notes: - - User space may assume that the value of this field never changes - during the lifetime of any single process. This means that this - field can be read once during the initialisation of a library or - startup phase of a program. - -kuser_get_tls -------------- - -Location: 0xffff0fe0 - -Reference prototype: - - void * __kuser_get_tls(void); - -Input: - - lr = return address - -Output: - - r0 = TLS value - -Clobbered registers: - - none - -Definition: - - Get the TLS value as previously set via the __ARM_NR_set_tls syscall. - -Usage example: - -typedef void * (__kuser_get_tls_t)(void); -#define __kuser_get_tls (*(__kuser_get_tls_t *)0xffff0fe0) - -void foo() -{ - void *tls = __kuser_get_tls(); - printf("TLS = %p\n", tls); -} - -Notes: - - - Valid only if __kuser_helper_version >= 1 (from kernel version 2.6.12). - -kuser_cmpxchg -------------- - -Location: 0xffff0fc0 - -Reference prototype: - - int __kuser_cmpxchg(int32_t oldval, int32_t newval, volatile int32_t *ptr); - -Input: - - r0 = oldval - r1 = newval - r2 = ptr - lr = return address - -Output: - - r0 = success code (zero or non-zero) - C flag = set if r0 == 0, clear if r0 != 0 - -Clobbered registers: - - r3, ip, flags - -Definition: - - Atomically store newval in *ptr only if *ptr is equal to oldval. - Return zero if *ptr was changed or non-zero if no exchange happened. - The C flag is also set if *ptr was changed to allow for assembly - optimization in the calling code. - -Usage example: - -typedef int (__kuser_cmpxchg_t)(int oldval, int newval, volatile int *ptr); -#define __kuser_cmpxchg (*(__kuser_cmpxchg_t *)0xffff0fc0) - -int atomic_add(volatile int *ptr, int val) -{ - int old, new; - - do { - old = *ptr; - new = old + val; - } while(__kuser_cmpxchg(old, new, ptr)); - - return new; -} - -Notes: - - - This routine already includes memory barriers as needed. - - - Valid only if __kuser_helper_version >= 2 (from kernel version 2.6.12). - -kuser_memory_barrier --------------------- - -Location: 0xffff0fa0 - -Reference prototype: - - void __kuser_memory_barrier(void); - -Input: - - lr = return address - -Output: - - none - -Clobbered registers: - - none - -Definition: - - Apply any needed memory barrier to preserve consistency with data modified - manually and __kuser_cmpxchg usage. - -Usage example: - -typedef void (__kuser_dmb_t)(void); -#define __kuser_dmb (*(__kuser_dmb_t *)0xffff0fa0) - -Notes: - - - Valid only if __kuser_helper_version >= 3 (from kernel version 2.6.15). - -kuser_cmpxchg64 ---------------- - -Location: 0xffff0f60 - -Reference prototype: - - int __kuser_cmpxchg64(const int64_t *oldval, - const int64_t *newval, - volatile int64_t *ptr); - -Input: - - r0 = pointer to oldval - r1 = pointer to newval - r2 = pointer to target value - lr = return address - -Output: - - r0 = success code (zero or non-zero) - C flag = set if r0 == 0, clear if r0 != 0 - -Clobbered registers: - - r3, lr, flags - -Definition: - - Atomically store the 64-bit value pointed by *newval in *ptr only if *ptr - is equal to the 64-bit value pointed by *oldval. Return zero if *ptr was - changed or non-zero if no exchange happened. - - The C flag is also set if *ptr was changed to allow for assembly - optimization in the calling code. - -Usage example: - -typedef int (__kuser_cmpxchg64_t)(const int64_t *oldval, - const int64_t *newval, - volatile int64_t *ptr); -#define __kuser_cmpxchg64 (*(__kuser_cmpxchg64_t *)0xffff0f60) - -int64_t atomic_add64(volatile int64_t *ptr, int64_t val) -{ - int64_t old, new; - - do { - old = *ptr; - new = old + val; - } while(__kuser_cmpxchg64(&old, &new, ptr)); - - return new; -} - -Notes: - - - This routine already includes memory barriers as needed. - - - Due to the length of this sequence, this spans 2 conventional kuser - "slots", therefore 0xffff0f80 is not used as a valid entry point. - - - Valid only if __kuser_helper_version >= 5 (from kernel version 3.1). diff --git a/Documentation/arm/mem_alignment b/Documentation/arm/mem_alignment deleted file mode 100644 index c7c7a114c78..00000000000 --- a/Documentation/arm/mem_alignment +++ /dev/null @@ -1,58 +0,0 @@ -Too many problems poped up because of unnoticed misaligned memory access in -kernel code lately. Therefore the alignment fixup is now unconditionally -configured in for SA11x0 based targets. According to Alan Cox, this is a -bad idea to configure it out, but Russell King has some good reasons for -doing so on some f***ed up ARM architectures like the EBSA110. However -this is not the case on many design I'm aware of, like all SA11x0 based -ones. - -Of course this is a bad idea to rely on the alignment trap to perform -unaligned memory access in general. If those access are predictable, you -are better to use the macros provided by include/asm/unaligned.h. The -alignment trap can fixup misaligned access for the exception cases, but at -a high performance cost. It better be rare. - -Now for user space applications, it is possible to configure the alignment -trap to SIGBUS any code performing unaligned access (good for debugging bad -code), or even fixup the access by software like for kernel code. The later -mode isn't recommended for performance reasons (just think about the -floating point emulation that works about the same way). Fix your code -instead! - -Please note that randomly changing the behaviour without good thought is -real bad - it changes the behaviour of all unaligned instructions in user -space, and might cause programs to fail unexpectedly. - -To change the alignment trap behavior, simply echo a number into -/proc/cpu/alignment. The number is made up from various bits: - -bit behavior when set ---- ----------------- - -0 A user process performing an unaligned memory access - will cause the kernel to print a message indicating - process name, pid, pc, instruction, address, and the - fault code. - -1 The kernel will attempt to fix up the user process - performing the unaligned access. This is of course - slow (think about the floating point emulator) and - not recommended for production use. - -2 The kernel will send a SIGBUS signal to the user process - performing the unaligned access. - -Note that not all combinations are supported - only values 0 through 5. -(6 and 7 don't make sense). - -For example, the following will turn on the warnings, but without -fixing up or sending SIGBUS signals: - - echo 1 > /proc/sys/debug/alignment - -You can also read the content of the same file to get statistical -information on unaligned access occurrences plus the current mode of -operation for user space code. - - -Nicolas Pitre, Mar 13, 2001. Modified Russell King, Nov 30, 2001. diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt deleted file mode 100644 index 208a2d465b9..00000000000 --- a/Documentation/arm/memory.txt +++ /dev/null @@ -1,92 +0,0 @@ - Kernel Memory Layout on ARM Linux - - Russell King <rmk@arm.linux.org.uk> - November 17, 2005 (2.6.15) - -This document describes the virtual memory layout which the Linux -kernel uses for ARM processors. It indicates which regions are -free for platforms to use, and which are used by generic code. - -The ARM CPU is capable of addressing a maximum of 4GB virtual memory -space, and this must be shared between user space processes, the -kernel, and hardware devices. - -As the ARM architecture matures, it becomes necessary to reserve -certain regions of VM space for use for new facilities; therefore -this document may reserve more VM space over time. - -Start End Use --------------------------------------------------------------------------- -ffff8000 ffffffff copy_user_page / clear_user_page use. - For SA11xx and Xscale, this is used to - setup a minicache mapping. - -ffff4000 ffffffff cache aliasing on ARMv6 and later CPUs. - -ffff1000 ffff7fff Reserved. - Platforms must not use this address range. - -ffff0000 ffff0fff CPU vector page. - The CPU vectors are mapped here if the - CPU supports vector relocation (control - register V bit.) - -fffe0000 fffeffff XScale cache flush area. This is used - in proc-xscale.S to flush the whole data - 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. - -ffc00000 ffefffff DMA memory mapping region. Memory returned - by the dma_alloc_xxx functions will be - dynamically mapped here. - -ff000000 ffbfffff Reserved for future expansion of DMA - mapping region. - -VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space. - Memory returned by vmalloc/ioremap will - be dynamically placed in this region. - Machine specific static mappings are also - located here through iotable_init(). - VMALLOC_START is based upon the value - of the high_memory variable, and VMALLOC_END - is equal to 0xff000000. - -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. - -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. - -00001000 TASK_SIZE-1 User space mappings - Per-thread mappings are placed here via - the mmap() system call. - -00000000 00000fff CPU vector page / null pointer trap - CPUs which do not support vector remapping - place their vector page here. NULL pointer - dereferences by both the kernel and user - space are also caught via this mapping. - -Please note that mappings which collide with the above areas may result -in a non-bootable kernel, or may cause the kernel to (eventually) panic -at run time. - -Since future CPUs may impact the kernel mapping layout, user programs -must not access any memory which is not mapped inside their 0x0001000 -to TASK_SIZE address range. If they wish to access these areas, they -must set up their own mappings using open() and mmap(). diff --git a/Documentation/arm/msm/gpiomux.txt b/Documentation/arm/msm/gpiomux.txt deleted file mode 100644 index 67a81620adf..00000000000 --- a/Documentation/arm/msm/gpiomux.txt +++ /dev/null @@ -1,176 +0,0 @@ -This document provides an overview of the msm_gpiomux interface, which -is used to provide gpio pin multiplexing and configuration on mach-msm -targets. - -History -======= - -The first-generation API for gpio configuration & multiplexing on msm -is the function gpio_tlmm_config(). This function has a few notable -shortcomings, which led to its deprecation and replacement by gpiomux: - -The 'disable' parameter: Setting the second parameter to -gpio_tlmm_config to GPIO_CFG_DISABLE tells the peripheral -processor in charge of the subsystem to perform a look-up into a -low-power table and apply the low-power/sleep setting for the pin. -As the msm family evolved this became problematic. Not all pins -have sleep settings, not all peripheral processors will accept requests -to apply said sleep settings, and not all msm targets have their gpio -subsystems managed by a peripheral processor. In order to get consistent -behavior on all targets, drivers are forced to ignore this parameter, -rendering it useless. - -The 'direction' flag: for all mux-settings other than raw-gpio (0), -the output-enable bit of a gpio is hard-wired to a known -input (usually VDD or ground). For those settings, the direction flag -is meaningless at best, and deceptive at worst. In addition, using the -direction flag to change output-enable (OE) directly can cause trouble in -gpiolib, which has no visibility into gpio direction changes made -in this way. Direction control in gpio mode should be made through gpiolib. - -Key Features of gpiomux -======================= - -- A consistent interface across all generations of msm. Drivers can expect -the same results on every target. -- gpiomux plays nicely with gpiolib. Functions that should belong to gpiolib -are left to gpiolib and not duplicated here. gpiomux is written with the -intent that gpio_chips will call gpiomux reference-counting methods -from their request() and free() hooks, providing full integration. -- Tabular configuration. Instead of having to call gpio_tlmm_config -hundreds of times, gpio configuration is placed in a single table. -- Per-gpio sleep. Each gpio is individually reference counted, allowing only -those lines which are in use to be put in high-power states. -- 0 means 'do nothing': all flags are designed so that the default memset-zero -equates to a sensible default of 'no configuration', preventing users -from having to provide hundreds of 'no-op' configs for unused or -unwanted lines. - -Usage -===== - -To use gpiomux, provide configuration information for relevant gpio lines -in the msm_gpiomux_configs table. Since a 0 equates to "unconfigured", -only those lines to be managed by gpiomux need to be specified. Here -is a completely fictional example: - -struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = { - [12] = { - .active = GPIOMUX_VALID | GPIOMUX_DRV_8MA | GPIOMUX_FUNC_1, - .suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN, - }, - [34] = { - .suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN, - }, -}; - -To indicate that a gpio is in use, call msm_gpiomux_get() to increase -its reference count. To decrease the reference count, call msm_gpiomux_put(). - -The effect of this configuration is as follows: - -When the system boots, gpios 12 and 34 will be initialized with their -'suspended' configurations. All other gpios, which were left unconfigured, -will not be touched. - -When msm_gpiomux_get() is called on gpio 12 to raise its reference count -above 0, its active configuration will be applied. Since no other gpio -line has a valid active configuration, msm_gpiomux_get() will have no -effect on any other line. - -When msm_gpiomux_put() is called on gpio 12 or 34 to drop their reference -count to 0, their suspended configurations will be applied. -Since no other gpio line has a valid suspended configuration, no other -gpio line will be effected by msm_gpiomux_put(). Since gpio 34 has no valid -active configuration, this is effectively a no-op for gpio 34 as well, -with one small caveat, see the section "About Output-Enable Settings". - -All of the GPIOMUX_VALID flags may seem like unnecessary overhead, but -they address some important issues. As unused entries (all those -except 12 and 34) are zero-filled, gpiomux needs a way to distinguish -the used fields from the unused. In addition, the all-zero pattern -is a valid configuration! Therefore, gpiomux defines an additional bit -which is used to indicate when a field is used. This has the pleasant -side-effect of allowing calls to msm_gpiomux_write to use '0' to indicate -that a value should not be changed: - - msm_gpiomux_write(0, GPIOMUX_VALID, 0); - -replaces the active configuration of gpio 0 with an all-zero configuration, -but leaves the suspended configuration as it was. - -Static Configurations -===================== - -To install a static configuration, which is applied at boot and does -not change after that, install a configuration with a suspended component -but no active component, as in the previous example: - - [34] = { - .suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN, - }, - -The suspended setting is applied during boot, and the lack of any valid -active setting prevents any other setting from being applied at runtime. -If other subsystems attempting to access the line is a concern, one could -*really* anchor the configuration down by calling msm_gpiomux_get on the -line at initialization to move the line into active mode. With the line -held, it will never be re-suspended, and with no valid active configuration, -no new configurations will be applied. - -But then, if having other subsystems grabbing for the line is truly a concern, -it should be reserved with gpio_request instead, which carries an implicit -msm_gpiomux_get. - -gpiomux and gpiolib -=================== - -It is expected that msm gpio_chips will call msm_gpiomux_get() and -msm_gpiomux_put() from their request and free hooks, like this fictional -example: - -static int request(struct gpio_chip *chip, unsigned offset) -{ - return msm_gpiomux_get(chip->base + offset); -} - -static void free(struct gpio_chip *chip, unsigned offset) -{ - msm_gpiomux_put(chip->base + offset); -} - - ...somewhere in a gpio_chip declaration... - .request = request, - .free = free, - -This provides important functionality: -- It guarantees that a gpio line will have its 'active' config applied - when the line is requested, and will not be suspended while the line - remains requested; and -- It guarantees that gpio-direction settings from gpiolib behave sensibly. - See "About Output-Enable Settings." - -This mechanism allows for "auto-request" of gpiomux lines via gpiolib -when it is suitable. Drivers wishing more exact control are, of course, -free to also use msm_gpiomux_set and msm_gpiomux_get. - -About Output-Enable Settings -============================ - -Some msm targets do not have the ability to query the current gpio -configuration setting. This means that changes made to the output-enable -(OE) bit by gpiolib cannot be consistently detected and preserved by gpiomux. -Therefore, when gpiomux applies a configuration setting, any direction -settings which may have been applied by gpiolib are lost and the default -input settings are re-applied. - -For this reason, drivers should not assume that gpio direction settings -continue to hold if they free and then re-request a gpio. This seems like -common sense - after all, anybody could have obtained the line in the -meantime - but it needs saying. - -This also means that calls to msm_gpiomux_write will reset the OE bit, -which means that if the gpio line is held by a client of gpiolib and -msm_gpiomux_write is called, the direction setting has been lost and -gpiolib's internal state has been broken. -Release gpio lines before reconfiguring them. diff --git a/Documentation/arm/nwfpe/NOTES b/Documentation/arm/nwfpe/NOTES deleted file mode 100644 index 40577b5a49d..00000000000 --- a/Documentation/arm/nwfpe/NOTES +++ /dev/null @@ -1,29 +0,0 @@ -There seems to be a problem with exp(double) and our emulator. I haven't -been able to track it down yet. This does not occur with the emulator -supplied by Russell King. - -I also found one oddity in the emulator. I don't think it is serious but -will point it out. The ARM calling conventions require floating point -registers f4-f7 to be preserved over a function call. The compiler quite -often uses an stfe instruction to save f4 on the stack upon entry to a -function, and an ldfe instruction to restore it before returning. - -I was looking at some code, that calculated a double result, stored it in f4 -then made a function call. Upon return from the function call the number in -f4 had been converted to an extended value in the emulator. - -This is a side effect of the stfe instruction. The double in f4 had to be -converted to extended, then stored. If an lfm/sfm combination had been used, -then no conversion would occur. This has performance considerations. The -result from the function call and f4 were used in a multiplication. If the -emulator sees a multiply of a double and extended, it promotes the double to -extended, then does the multiply in extended precision. - -This code will cause this problem: - -double x, y, z; -z = log(x)/log(y); - -The result of log(x) (a double) will be calculated, returned in f0, then -moved to f4 to preserve it over the log(y) call. The division will be done -in extended precision, due to the stfe instruction used to save f4 in log(y). diff --git a/Documentation/arm/nwfpe/README b/Documentation/arm/nwfpe/README deleted file mode 100644 index 771871de0c8..00000000000 --- a/Documentation/arm/nwfpe/README +++ /dev/null @@ -1,70 +0,0 @@ -This directory contains the version 0.92 test release of the NetWinder -Floating Point Emulator. - -The majority of the code was written by me, Scott Bambrough It is -written in C, with a small number of routines in inline assembler -where required. It was written quickly, with a goal of implementing a -working version of all the floating point instructions the compiler -emits as the first target. I have attempted to be as optimal as -possible, but there remains much room for improvement. - -I have attempted to make the emulator as portable as possible. One of -the problems is with leading underscores on kernel symbols. Elf -kernels have no leading underscores, a.out compiled kernels do. I -have attempted to use the C_SYMBOL_NAME macro wherever this may be -important. - -Another choice I made was in the file structure. I have attempted to -contain all operating system specific code in one module (fpmodule.*). -All the other files contain emulator specific code. This should allow -others to port the emulator to NetBSD for instance relatively easily. - -The floating point operations are based on SoftFloat Release 2, by -John Hauser. SoftFloat is a software implementation of floating-point -that conforms to the IEC/IEEE Standard for Binary Floating-point -Arithmetic. As many as four formats are supported: single precision, -double precision, extended double precision, and quadruple precision. -All operations required by the standard are implemented, except for -conversions to and from decimal. We use only the single precision, -double precision and extended double precision formats. The port of -SoftFloat to the ARM was done by Phil Blundell, based on an earlier -port of SoftFloat version 1 by Neil Carson for NetBSD/arm32. - -The file README.FPE contains a description of what has been implemented -so far in the emulator. The file TODO contains a information on what -remains to be done, and other ideas for the emulator. - -Bug reports, comments, suggestions should be directed to me at -<scottb@netwinder.org>. General reports of "this program doesn't -work correctly when your emulator is installed" are useful for -determining that bugs still exist; but are virtually useless when -attempting to isolate the problem. Please report them, but don't -expect quick action. Bugs still exist. The problem remains in isolating -which instruction contains the bug. Small programs illustrating a specific -problem are a godsend. - -Legal Notices -------------- - -The NetWinder Floating Point Emulator is free software. Everything Rebel.com -has written is provided under the GNU GPL. See the file COPYING for copying -conditions. Excluded from the above is the SoftFloat code. John Hauser's -legal notice for SoftFloat is included below. - -------------------------------------------------------------------------------- -SoftFloat Legal Notice - -SoftFloat was written by John R. Hauser. This work was made possible in -part by the International Computer Science Institute, located at Suite 600, -1947 Center Street, Berkeley, California 94704. Funding was partially -provided by the National Science Foundation under grant MIP-9311980. The -original version of this code was written as part of a project to build -a fixed-point vector processor in collaboration with the University of -California at Berkeley, overseen by Profs. Nelson Morgan and John Wawrzynek. - -THIS SOFTWARE IS DISTRIBUTED AS IS, FOR FREE. Although reasonable effort -has been made to avoid it, THIS SOFTWARE MAY CONTAIN FAULTS THAT WILL AT -TIMES RESULT IN INCORRECT BEHAVIOR. USE OF THIS SOFTWARE IS RESTRICTED TO -PERSONS AND ORGANIZATIONS WHO CAN AND WILL TAKE FULL RESPONSIBILITY FOR ANY -AND ALL LOSSES, COSTS, OR OTHER PROBLEMS ARISING FROM ITS USE. -------------------------------------------------------------------------------- diff --git a/Documentation/arm/nwfpe/README.FPE b/Documentation/arm/nwfpe/README.FPE deleted file mode 100644 index 26f5d7bb9a4..00000000000 --- a/Documentation/arm/nwfpe/README.FPE +++ /dev/null @@ -1,156 +0,0 @@ -The following describes the current state of the NetWinder's floating point -emulator. - -In the following nomenclature is used to describe the floating point -instructions. It follows the conventions in the ARM manual. - -<S|D|E> = <single|double|extended>, no default -{P|M|Z} = {round to +infinity,round to -infinity,round to zero}, - default = round to nearest - -Note: items enclosed in {} are optional. - -Floating Point Coprocessor Data Transfer Instructions (CPDT) ------------------------------------------------------------- - -LDF/STF - load and store floating - -<LDF|STF>{cond}<S|D|E> Fd, Rn -<LDF|STF>{cond}<S|D|E> Fd, [Rn, #<expression>]{!} -<LDF|STF>{cond}<S|D|E> Fd, [Rn], #<expression> - -These instructions are fully implemented. - -LFM/SFM - load and store multiple floating - -Form 1 syntax: -<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn] -<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn, #<expression>]{!} -<LFM|SFM>{cond}<S|D|E> Fd, <count>, [Rn], #<expression> - -Form 2 syntax: -<LFM|SFM>{cond}<FD,EA> Fd, <count>, [Rn]{!} - -These instructions are fully implemented. They store/load three words -for each floating point register into the memory location given in the -instruction. The format in memory is unlikely to be compatible with -other implementations, in particular the actual hardware. Specific -mention of this is made in the ARM manuals. - -Floating Point Coprocessor Register Transfer Instructions (CPRT) ----------------------------------------------------------------- - -Conversions, read/write status/control register instructions - -FLT{cond}<S,D,E>{P,M,Z} Fn, Rd Convert integer to floating point -FIX{cond}{P,M,Z} Rd, Fn Convert floating point to integer -WFS{cond} Rd Write floating point status register -RFS{cond} Rd Read floating point status register -WFC{cond} Rd Write floating point control register -RFC{cond} Rd Read floating point control register - -FLT/FIX are fully implemented. - -RFS/WFS are fully implemented. - -RFC/WFC are fully implemented. RFC/WFC are supervisor only instructions, and -presently check the CPU mode, and do an invalid instruction trap if not called -from supervisor mode. - -Compare instructions - -CMF{cond} Fn, Fm Compare floating -CMFE{cond} Fn, Fm Compare floating with exception -CNF{cond} Fn, Fm Compare negated floating -CNFE{cond} Fn, Fm Compare negated floating with exception - -These are fully implemented. - -Floating Point Coprocessor Data Instructions (CPDT) ---------------------------------------------------- - -Dyadic operations: - -ADF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - add -SUF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - subtract -RSF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse subtract -MUF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - multiply -DVF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - divide -RDV{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse divide - -These are fully implemented. - -FML{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast multiply -FDV{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast divide -FRD{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - fast reverse divide - -These are fully implemented as well. They use the same algorithm as the -non-fast versions. Hence, in this implementation their performance is -equivalent to the MUF/DVF/RDV instructions. This is acceptable according -to the ARM manual. The manual notes these are defined only for single -operands, on the actual FPA11 hardware they do not work for double or -extended precision operands. The emulator currently does not check -the requested permissions conditions, and performs the requested operation. - -RMF{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - IEEE remainder - -This is fully implemented. - -Monadic operations: - -MVF{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - move -MNF{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - move negated - -These are fully implemented. - -ABS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - absolute value -SQT{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - square root -RND{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - round - -These are fully implemented. - -URD{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - unnormalized round -NRM{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - normalize - -These are implemented. URD is implemented using the same code as the RND -instruction. Since URD cannot return a unnormalized number, NRM becomes -a NOP. - -Library calls: - -POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power -RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power -POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2) - -LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10 -LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e -EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent -SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine -COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine -TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent -ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine -ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine -ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent - -These are not implemented. They are not currently issued by the compiler, -and are handled by routines in libc. These are not implemented by the FPA11 -hardware, but are handled by the floating point support code. They should -be implemented in future versions. - -Signalling: - -Signals are implemented. However current ELF kernels produced by Rebel.com -have a bug in them that prevents the module from generating a SIGFPE. This -is caused by a failure to alias fp_current to the kernel variable -current_set[0] correctly. - -The kernel provided with this distribution (vmlinux-nwfpe-0.93) contains -a fix for this problem and also incorporates the current version of the -emulator directly. It is possible to run with no floating point module -loaded with this kernel. It is provided as a demonstration of the -technology and for those who want to do floating point work that depends -on signals. It is not strictly necessary to use the module. - -A module (either the one provided by Russell King, or the one in this -distribution) can be loaded to replace the functionality of the emulator -built into the kernel. diff --git a/Documentation/arm/nwfpe/TODO b/Documentation/arm/nwfpe/TODO deleted file mode 100644 index 8027061b60e..00000000000 --- a/Documentation/arm/nwfpe/TODO +++ /dev/null @@ -1,67 +0,0 @@ -TODO LIST ---------- - -POW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - power -RPW{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - reverse power -POL{cond}<S|D|E>{P,M,Z} Fd, Fn, <Fm,#value> - polar angle (arctan2) - -LOG{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base 10 -LGN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - logarithm to base e -EXP{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - exponent -SIN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - sine -COS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - cosine -TAN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - tangent -ASN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arcsine -ACS{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arccosine -ATN{cond}<S|D|E>{P,M,Z} Fd, <Fm,#value> - arctangent - -These are not implemented. They are not currently issued by the compiler, -and are handled by routines in libc. These are not implemented by the FPA11 -hardware, but are handled by the floating point support code. They should -be implemented in future versions. - -There are a couple of ways to approach the implementation of these. One -method would be to use accurate table methods for these routines. I have -a couple of papers by S. Gal from IBM's research labs in Haifa, Israel that -seem to promise extreme accuracy (in the order of 99.8%) and reasonable speed. -These methods are used in GLIBC for some of the transcendental functions. - -Another approach, which I know little about is CORDIC. This stands for -Coordinate Rotation Digital Computer, and is a method of computing -transcendental functions using mostly shifts and adds and a few -multiplications and divisions. The ARM excels at shifts and adds, -so such a method could be promising, but requires more research to -determine if it is feasible. - -Rounding Methods - -The IEEE standard defines 4 rounding modes. Round to nearest is the -default, but rounding to + or - infinity or round to zero are also allowed. -Many architectures allow the rounding mode to be specified by modifying bits -in a control register. Not so with the ARM FPA11 architecture. To change -the rounding mode one must specify it with each instruction. - -This has made porting some benchmarks difficult. It is possible to -introduce such a capability into the emulator. The FPCR contains -bits describing the rounding mode. The emulator could be altered to -examine a flag, which if set forced it to ignore the rounding mode in -the instruction, and use the mode specified in the bits in the FPCR. - -This would require a method of getting/setting the flag, and the bits -in the FPCR. This requires a kernel call in ArmLinux, as WFC/RFC are -supervisor only instructions. If anyone has any ideas or comments I -would like to hear them. - -[NOTE: pulled out from some docs on ARM floating point, specifically - for the Acorn FPE, but not limited to it: - - The floating point control register (FPCR) may only be present in some - implementations: it is there to control the hardware in an implementation- - specific manner, for example to disable the floating point system. The user - mode of the ARM is not permitted to use this register (since the right is - reserved to alter it between implementations) and the WFC and RFC - instructions will trap if tried in user mode. - - Hence, the answer is yes, you could do this, but then you will run a high - risk of becoming isolated if and when hardware FP emulation comes out - -- Russell]. diff --git a/Documentation/arm/pxa/mfp.txt b/Documentation/arm/pxa/mfp.txt deleted file mode 100644 index a179e5bc02c..00000000000 --- a/Documentation/arm/pxa/mfp.txt +++ /dev/null @@ -1,286 +0,0 @@ - MFP Configuration for PXA2xx/PXA3xx Processors - - Eric Miao <eric.miao@marvell.com> - -MFP stands for Multi-Function Pin, which is the pin-mux logic on PXA3xx and -later PXA series processors. This document describes the existing MFP API, -and how board/platform driver authors could make use of it. - - Basic Concept -=============== - -Unlike the GPIO alternate function settings on PXA25x and PXA27x, a new MFP -mechanism is introduced from PXA3xx to completely move the pin-mux functions -out of the GPIO controller. In addition to pin-mux configurations, the MFP -also controls the low power state, driving strength, pull-up/down and event -detection of each pin. Below is a diagram of internal connections between -the MFP logic and the remaining SoC peripherals: - - +--------+ - | |--(GPIO19)--+ - | GPIO | | - | |--(GPIO...) | - +--------+ | - | +---------+ - +--------+ +------>| | - | PWM2 |--(PWM_OUT)-------->| MFP | - +--------+ +------>| |-------> to external PAD - | +---->| | - +--------+ | | +-->| | - | SSP2 |---(TXD)----+ | | +---------+ - +--------+ | | - | | - +--------+ | | - | Keypad |--(MKOUT4)----+ | - +--------+ | - | - +--------+ | - | UART2 |---(TXD)--------+ - +--------+ - -NOTE: the external pad is named as MFP_PIN_GPIO19, it doesn't necessarily -mean it's dedicated for GPIO19, only as a hint that internally this pin -can be routed from GPIO19 of the GPIO controller. - -To better understand the change from PXA25x/PXA27x GPIO alternate function -to this new MFP mechanism, here are several key points: - - 1. GPIO controller on PXA3xx is now a dedicated controller, same as other - internal controllers like PWM, SSP and UART, with 128 internal signals - which can be routed to external through one or more MFPs (e.g. GPIO<0> - can be routed through either MFP_PIN_GPIO0 as well as MFP_PIN_GPIO0_2, - see arch/arm/mach-pxa/mach/include/mfp-pxa300.h) - - 2. Alternate function configuration is removed from this GPIO controller, - the remaining functions are pure GPIO-specific, i.e. - - - GPIO signal level control - - GPIO direction control - - GPIO level change detection - - 3. Low power state for each pin is now controlled by MFP, this means the - PGSRx registers on PXA2xx are now useless on PXA3xx - - 4. Wakeup detection is now controlled by MFP, PWER does not control the - wakeup from GPIO(s) any more, depending on the sleeping state, ADxER - (as defined in pxa3xx-regs.h) controls the wakeup from MFP - -NOTE: with such a clear separation of MFP and GPIO, by GPIO<xx> we normally -mean it is a GPIO signal, and by MFP<xxx> or pin xxx, we mean a physical -pad (or ball). - - MFP API Usage -=============== - -For board code writers, here are some guidelines: - -1. include ONE of the following header files in your <board>.c: - - - #include <mach/mfp-pxa25x.h> - - #include <mach/mfp-pxa27x.h> - - #include <mach/mfp-pxa300.h> - - #include <mach/mfp-pxa320.h> - - #include <mach/mfp-pxa930.h> - - NOTE: only one file in your <board>.c, depending on the processors used, - because pin configuration definitions may conflict in these file (i.e. - same name, different meaning and settings on different processors). E.g. - for zylonite platform, which support both PXA300/PXA310 and PXA320, two - separate files are introduced: zylonite_pxa300.c and zylonite_pxa320.c - (in addition to handle MFP configuration differences, they also handle - the other differences between the two combinations). - - NOTE: PXA300 and PXA310 are almost identical in pin configurations (with - PXA310 supporting some additional ones), thus the difference is actually - covered in a single mfp-pxa300.h. - -2. prepare an array for the initial pin configurations, e.g.: - - static unsigned long mainstone_pin_config[] __initdata = { - /* Chip Select */ - GPIO15_nCS_1, - - /* LCD - 16bpp Active TFT */ - GPIOxx_TFT_LCD_16BPP, - GPIO16_PWM0_OUT, /* Backlight */ - - /* MMC */ - GPIO32_MMC_CLK, - GPIO112_MMC_CMD, - GPIO92_MMC_DAT_0, - GPIO109_MMC_DAT_1, - GPIO110_MMC_DAT_2, - GPIO111_MMC_DAT_3, - - ... - - /* GPIO */ - GPIO1_GPIO | WAKEUP_ON_EDGE_BOTH, - }; - - a) once the pin configurations are passed to pxa{2xx,3xx}_mfp_config(), - and written to the actual registers, they are useless and may discard, - adding '__initdata' will help save some additional bytes here. - - b) when there is only one possible pin configurations for a component, - some simplified definitions can be used, e.g. GPIOxx_TFT_LCD_16BPP on - PXA25x and PXA27x processors - - c) if by board design, a pin can be configured to wake up the system - from low power state, it can be 'OR'ed with any of: - - WAKEUP_ON_EDGE_BOTH - WAKEUP_ON_EDGE_RISE - WAKEUP_ON_EDGE_FALL - WAKEUP_ON_LEVEL_HIGH - specifically for enabling of keypad GPIOs, - - to indicate that this pin has the capability of wake-up the system, - and on which edge(s). This, however, doesn't necessarily mean the - pin _will_ wakeup the system, it will only when set_irq_wake() is - invoked with the corresponding GPIO IRQ (GPIO_IRQ(xx) or gpio_to_irq()) - and eventually calls gpio_set_wake() for the actual register setting. - - d) although PXA3xx MFP supports edge detection on each pin, the - internal logic will only wakeup the system when those specific bits - in ADxER registers are set, which can be well mapped to the - corresponding peripheral, thus set_irq_wake() can be called with - the peripheral IRQ to enable the wakeup. - - - MFP on PXA3xx -=============== - -Every external I/O pad on PXA3xx (excluding those for special purpose) has -one MFP logic associated, and is controlled by one MFP register (MFPR). - -The MFPR has the following bit definitions (for PXA300/PXA310/PXA320): - - 31 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 - +-------------------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | RESERVED |PS|PU|PD| DRIVE |SS|SD|SO|EC|EF|ER|--| AF_SEL | - +-------------------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - Bit 3: RESERVED - Bit 4: EDGE_RISE_EN - enable detection of rising edge on this pin - Bit 5: EDGE_FALL_EN - enable detection of falling edge on this pin - Bit 6: EDGE_CLEAR - disable edge detection on this pin - Bit 7: SLEEP_OE_N - enable outputs during low power modes - Bit 8: SLEEP_DATA - output data on the pin during low power modes - Bit 9: SLEEP_SEL - selection control for low power modes signals - Bit 13: PULLDOWN_EN - enable the internal pull-down resistor on this pin - Bit 14: PULLUP_EN - enable the internal pull-up resistor on this pin - Bit 15: PULL_SEL - pull state controlled by selected alternate function - (0) or by PULL{UP,DOWN}_EN bits (1) - - Bit 0 - 2: AF_SEL - alternate function selection, 8 possibilities, from 0-7 - Bit 10-12: DRIVE - drive strength and slew rate - 0b000 - fast 1mA - 0b001 - fast 2mA - 0b002 - fast 3mA - 0b003 - fast 4mA - 0b004 - slow 6mA - 0b005 - fast 6mA - 0b006 - slow 10mA - 0b007 - fast 10mA - - MFP Design for PXA2xx/PXA3xx -============================== - -Due to the difference of pin-mux handling between PXA2xx and PXA3xx, a unified -MFP API is introduced to cover both series of processors. - -The basic idea of this design is to introduce definitions for all possible pin -configurations, these definitions are processor and platform independent, and -the actual API invoked to convert these definitions into register settings and -make them effective there-after. - - Files Involved - -------------- - - - arch/arm/mach-pxa/include/mach/mfp.h - - for - 1. Unified pin definitions - enum constants for all configurable pins - 2. processor-neutral bit definitions for a possible MFP configuration - - - arch/arm/mach-pxa/include/mach/mfp-pxa3xx.h - - for PXA3xx specific MFPR register bit definitions and PXA3xx common pin - configurations - - - arch/arm/mach-pxa/include/mach/mfp-pxa2xx.h - - for PXA2xx specific definitions and PXA25x/PXA27x common pin configurations - - - arch/arm/mach-pxa/include/mach/mfp-pxa25x.h - arch/arm/mach-pxa/include/mach/mfp-pxa27x.h - arch/arm/mach-pxa/include/mach/mfp-pxa300.h - arch/arm/mach-pxa/include/mach/mfp-pxa320.h - arch/arm/mach-pxa/include/mach/mfp-pxa930.h - - for processor specific definitions - - - arch/arm/mach-pxa/mfp-pxa3xx.c - - arch/arm/mach-pxa/mfp-pxa2xx.c - - for implementation of the pin configuration to take effect for the actual - processor. - - Pin Configuration - ----------------- - - The following comments are copied from mfp.h (see the actual source code - for most updated info) - - /* - * a possible MFP configuration is represented by a 32-bit integer - * - * bit 0.. 9 - MFP Pin Number (1024 Pins Maximum) - * bit 10..12 - Alternate Function Selection - * bit 13..15 - Drive Strength - * bit 16..18 - Low Power Mode State - * bit 19..20 - Low Power Mode Edge Detection - * bit 21..22 - Run Mode Pull State - * - * to facilitate the definition, the following macros are provided - * - * MFP_CFG_DEFAULT - default MFP configuration value, with - * alternate function = 0, - * drive strength = fast 3mA (MFP_DS03X) - * low power mode = default - * edge detection = none - * - * MFP_CFG - default MFPR value with alternate function - * MFP_CFG_DRV - default MFPR value with alternate function and - * pin drive strength - * MFP_CFG_LPM - default MFPR value with alternate function and - * low power mode - * MFP_CFG_X - default MFPR value with alternate function, - * pin drive strength and low power mode - */ - - Examples of pin configurations are: - - #define GPIO94_SSP3_RXD MFP_CFG_X(GPIO94, AF1, DS08X, FLOAT) - - which reads GPIO94 can be configured as SSP3_RXD, with alternate function - selection of 1, driving strength of 0b101, and a float state in low power - modes. - - NOTE: this is the default setting of this pin being configured as SSP3_RXD - which can be modified a bit in board code, though it is not recommended to - do so, simply because this default setting is usually carefully encoded, - and is supposed to work in most cases. - - Register Settings - ----------------- - - Register settings on PXA3xx for a pin configuration is actually very - straight-forward, most bits can be converted directly into MFPR value - in a easier way. Two sets of MFPR values are calculated: the run-time - ones and the low power mode ones, to allow different settings. - - The conversion from a generic pin configuration to the actual register - settings on PXA2xx is a bit complicated: many registers are involved, - including GAFRx, GPDRx, PGSRx, PWER, PKWR, PFER and PRER. Please see - mfp-pxa2xx.c for how the conversion is made. diff --git a/Documentation/arm/swp_emulation b/Documentation/arm/swp_emulation deleted file mode 100644 index af903d22fd9..00000000000 --- a/Documentation/arm/swp_emulation +++ /dev/null @@ -1,27 +0,0 @@ -Software emulation of deprecated SWP instruction (CONFIG_SWP_EMULATE) ---------------------------------------------------------------------- - -ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommeds -moving to the load-locked/store-conditional instructions LDREX and STREX. - -ARMv7 multiprocessing extensions introduce the ability to disable these -instructions, triggering an undefined instruction exception when executed. -Trapped instructions are emulated using an LDREX/STREX or LDREXB/STREXB -sequence. If a memory access fault (an abort) occurs, a segmentation fault is -signalled to the triggering process. - -/proc/cpu/swp_emulation holds some statistics/information, including the PID of -the last process to trigger the emulation to be invocated. For example: ---- -Emulated SWP: 12 -Emulated SWPB: 0 -Aborted SWP{B}: 1 -Last process: 314 ---- - -NOTE: when accessing uncached shared regions, LDREX/STREX rely on an external -transaction monitoring block called a global monitor to maintain update -atomicity. If your system does not implement a global monitor, this option can -cause programs that perform SWP operations to uncached memory to deadlock, as -the STREX operation will always fail. - diff --git a/Documentation/arm/tcm.txt b/Documentation/arm/tcm.txt deleted file mode 100644 index 7c15871c188..00000000000 --- a/Documentation/arm/tcm.txt +++ /dev/null @@ -1,155 +0,0 @@ -ARM TCM (Tightly-Coupled Memory) handling in Linux ----- -Written by Linus Walleij <linus.walleij@stericsson.com> - -Some ARM SoC:s have a so-called TCM (Tightly-Coupled Memory). -This is usually just a few (4-64) KiB of RAM inside the ARM -processor. - -Due to being embedded inside the CPU The TCM has a -Harvard-architecture, so there is an ITCM (instruction TCM) -and a DTCM (data TCM). The DTCM can not contain any -instructions, but the ITCM can actually contain data. -The size of DTCM or ITCM is minimum 4KiB so the typical -minimum configuration is 4KiB ITCM and 4KiB DTCM. - -ARM CPU:s have special registers to read out status, physical -location and size of TCM memories. arch/arm/include/asm/cputype.h -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 (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 -size of TCM memories at runtime. This is used to read out and modify -TCM location and size. Notice that this is not a MMU table: you -actually move the physical location of the TCM around. At the -place you put it, it will mask any underlying RAM from the -CPU so it is usually wise not to overlap any physical RAM with -the TCM. - -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 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: - -- FIQ and other interrupt handlers that need deterministic - timing and cannot wait for cache misses. - -- Idle loops where all external RAM is set to self-refresh - retention mode, so only on-chip RAM is accessible by - the CPU and then we hang inside ITCM waiting for an - interrupt. - -- Other operations which implies shutting off or reconfiguring - the external RAM controller. - -There is an interface for using TCM on the ARM architecture -in <asm/tcm.h>. Using this interface it is possible to: - -- Define the physical address and size of ITCM and DTCM. - -- Tag functions to be compiled into ITCM. - -- Tag data and constants to be allocated to DTCM and ITCM. - -- Have the remaining TCM RAM added to a special - allocation pool with gen_pool_create() and gen_pool_add() - and provice tcm_alloc() and tcm_free() for this - 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 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; - -Constants can be tagged like this: -int __tcmconst foo; - -To put assembler into TCM just use -.section ".tcm.text" or .section ".tcm.data" -respectively. - -Example code: - -#include <asm/tcm.h> - -/* Uninitialized data */ -static u32 __tcmdata tcmvar; -/* Initialized data */ -static u32 __tcmdata tcmassigned = 0x2BADBABEU; -/* Constant */ -static const u32 __tcmconst tcmconst = 0xCAFEBABEU; - -static void __tcmlocalfunc tcm_to_tcm(void) -{ - int i; - for (i = 0; i < 100; i++) - tcmvar ++; -} - -static void __tcmfunc hello_tcm(void) -{ - /* Some abstract code that runs in ITCM */ - int i; - for (i = 0; i < 100; i++) { - tcmvar ++; - } - tcm_to_tcm(); -} - -static void __init test_tcm(void) -{ - u32 *tcmem; - int i; - - hello_tcm(); - printk("Hello TCM executed from ITCM RAM\n"); - - printk("TCM variable from testrun: %u @ %p\n", tcmvar, &tcmvar); - tcmvar = 0xDEADBEEFU; - printk("TCM variable: 0x%x @ %p\n", tcmvar, &tcmvar); - - printk("TCM assigned variable: 0x%x @ %p\n", tcmassigned, &tcmassigned); - - printk("TCM constant: 0x%x @ %p\n", tcmconst, &tcmconst); - - /* Allocate some TCM memory from the pool */ - tcmem = tcm_alloc(20); - if (tcmem) { - printk("TCM Allocated 20 bytes of TCM @ %p\n", tcmem); - tcmem[0] = 0xDEADBEEFU; - tcmem[1] = 0x2BADBABEU; - tcmem[2] = 0xCAFEBABEU; - tcmem[3] = 0xDEADBEEFU; - tcmem[4] = 0x2BADBABEU; - for (i = 0; i < 5; i++) - printk("TCM tcmem[%d] = %08x\n", i, tcmem[i]); - tcm_free(tcmem, 20); - } -} |