diff options
Diffstat (limited to 'Documentation/arm')
61 files changed, 0 insertions, 6914 deletions
diff --git a/Documentation/arm/arm.rst b/Documentation/arm/arm.rst deleted file mode 100644 index 99d660fdf73f..000000000000 --- a/Documentation/arm/arm.rst +++ /dev/null @@ -1,212 +0,0 @@ -======================= -ARM Linux 2.6 and upper -======================= - - 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> - which contain - the source files and include/mach/ to support the machine class. - - 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." - - For platforms that support device tree (DT), the machine selection is - controlled at runtime by passing the device tree blob to the kernel. At - compile-time, support for the machine type must be selected. This allows for - a single multiplatform kernel build to be used for several machine types. - - For platforms that do not use device tree, this machine 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/> - - Note: Please do not register a machine type for DT-only platforms. If your - platform is DT-only, you do not need a registered machine type. - ---- - -Russell King (15/03/2004) diff --git a/Documentation/arm/booting.rst b/Documentation/arm/booting.rst deleted file mode 100644 index 5974e37b3d20..000000000000 --- a/Documentation/arm/booting.rst +++ /dev/null @@ -1,237 +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. Load initramfs. -6. 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/admin-guide/kernel-parameters.rst. - - -3. Detect the machine type --------------------------- - -Existing boot loaders: - OPTIONAL -New boot loaders: - MANDATORY except for DT-only platforms - -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). This -should be passed to the kernel in register r1. - -For DT-only platforms, the machine type will be determined by device -tree. set the machine type to all ones (~0). This is not strictly -necessary, but assures that it will not match any existing 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 at https://www.devicetree.org/specifications/. -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, while remaining within the region which will be covered -by the kernel's low-memory mapping. - -A safe location is just above the 128MiB boundary from start of RAM. - -5. Load initramfs. ------------------- - -Existing boot loaders: - OPTIONAL -New boot loaders: - OPTIONAL - -If an initramfs is in use then, as with the dtb, it must be placed in -a region of memory where the kernel decompressor will not overwrite it -while also with the region which will be covered by the kernel's -low-memory mapping. - -A safe location is just above the device tree blob which itself will -be loaded just above the 128MiB boundary from the start of RAM as -recommended above. - -6. 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 and called there. The -kernel should be placed in the first 128MiB of RAM. It is recommended -that it is loaded above 32MiB in order to avoid the need to relocate -prior to decompression, which will make the boot process slightly -faster. - -When booting a raw (non-zImage) kernel the constraints are tighter. -In this case the kernel must be loaded at an offset into system equal -to TEXT_OFFSET - PAGE_OFFSET. - -In any 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) - - For CPUs which do not include the ARM virtualization extensions, the - CPU must be in SVC mode. (A special exception exists for Angel) - - CPUs which include support for the virtualization extensions can be - entered in HYP mode in order to enable the kernel to make full use of - these extensions. This is the recommended boot method for such CPUs, - unless the virtualisations are already in use by a pre-installed - hypervisor. - - If the kernel is not entered in HYP mode for any reason, it must be - entered in SVC mode. - -- Caches, MMUs - - The MMU must be off. - - Instruction cache may be on or off. - - Data cache must be off. - - If the kernel is entered in HYP mode, the above requirements apply to - the HYP mode configuration in addition to the ordinary PL1 (privileged - kernel modes) configuration. In addition, all traps into the - hypervisor must be disabled, and PL1 access must be granted for all - peripherals and CPU resources for which this is architecturally - possible. Except for entering in HYP mode, the system configuration - should be such that a kernel which does not include support for the - virtualization extensions can boot correctly without extra help. - -- 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/cluster-pm-race-avoidance.rst b/Documentation/arm/cluster-pm-race-avoidance.rst deleted file mode 100644 index aa58603d3f28..000000000000 --- a/Documentation/arm/cluster-pm-race-avoidance.rst +++ /dev/null @@ -1,533 +0,0 @@ -========================================================= -Cluster-wide Power-up/power-down race avoidance algorithm -========================================================= - -This file documents the algorithm which is used to coordinate CPU and -cluster setup and teardown operations and to manage hardware coherency -controls safely. - -The section "Rationale" explains what the algorithm is for and why it is -needed. "Basic model" explains general concepts using a simplified view -of the system. The other sections explain the actual details of the -algorithm in use. - - -Rationale ---------- - -In a system containing multiple CPUs, it is desirable to have the -ability to turn off individual CPUs when the system is idle, reducing -power consumption and thermal dissipation. - -In a system containing multiple clusters of CPUs, it is also desirable -to have the ability to turn off entire clusters. - -Turning entire clusters off and on is a risky business, because it -involves performing potentially destructive operations affecting a group -of independently running CPUs, while the OS continues to run. This -means that we need some coordination in order to ensure that critical -cluster-level operations are only performed when it is truly safe to do -so. - -Simple locking may not be sufficient to solve this problem, because -mechanisms like Linux spinlocks may rely on coherency mechanisms which -are not immediately enabled when a cluster powers up. Since enabling or -disabling those mechanisms may itself be a non-atomic operation (such as -writing some hardware registers and invalidating large caches), other -methods of coordination are required in order to guarantee safe -power-down and power-up at the cluster level. - -The mechanism presented in this document describes a coherent memory -based protocol for performing the needed coordination. It aims to be as -lightweight as possible, while providing the required safety properties. - - -Basic model ------------ - -Each cluster and CPU is assigned a state, as follows: - - - DOWN - - COMING_UP - - UP - - GOING_DOWN - -:: - - +---------> UP ----------+ - | v - - COMING_UP GOING_DOWN - - ^ | - +--------- DOWN <--------+ - - -DOWN: - The CPU or cluster is not coherent, and is either powered off or - suspended, or is ready to be powered off or suspended. - -COMING_UP: - The CPU or cluster has committed to moving to the UP state. - It may be part way through the process of initialisation and - enabling coherency. - -UP: - The CPU or cluster is active and coherent at the hardware - level. A CPU in this state is not necessarily being used - actively by the kernel. - -GOING_DOWN: - The CPU or cluster has committed to moving to the DOWN - state. It may be part way through the process of teardown and - coherency exit. - - -Each CPU has one of these states assigned to it at any point in time. -The CPU states are described in the "CPU state" section, below. - -Each cluster is also assigned a state, but it is necessary to split the -state value into two parts (the "cluster" state and "inbound" state) and -to introduce additional states in order to avoid races between different -CPUs in the cluster simultaneously modifying the state. The cluster- -level states are described in the "Cluster state" section. - -To help distinguish the CPU states from cluster states in this -discussion, the state names are given a `CPU_` prefix for the CPU states, -and a `CLUSTER_` or `INBOUND_` prefix for the cluster states. - - -CPU state ---------- - -In this algorithm, each individual core in a multi-core processor is -referred to as a "CPU". CPUs are assumed to be single-threaded: -therefore, a CPU can only be doing one thing at a single point in time. - -This means that CPUs fit the basic model closely. - -The algorithm defines the following states for each CPU in the system: - - - CPU_DOWN - - CPU_COMING_UP - - CPU_UP - - CPU_GOING_DOWN - -:: - - cluster setup and - CPU setup complete policy decision - +-----------> CPU_UP ------------+ - | v - - CPU_COMING_UP CPU_GOING_DOWN - - ^ | - +----------- CPU_DOWN <----------+ - policy decision CPU teardown complete - or hardware event - - -The definitions of the four states correspond closely to the states of -the basic model. - -Transitions between states occur as follows. - -A trigger event (spontaneous) means that the CPU can transition to the -next state as a result of making local progress only, with no -requirement for any external event to happen. - - -CPU_DOWN: - A CPU reaches the CPU_DOWN state when it is ready for - power-down. On reaching this state, the CPU will typically - power itself down or suspend itself, via a WFI instruction or a - firmware call. - - Next state: - CPU_COMING_UP - Conditions: - none - - Trigger events: - a) an explicit hardware power-up operation, resulting - from a policy decision on another CPU; - - b) a hardware event, such as an interrupt. - - -CPU_COMING_UP: - A CPU cannot start participating in hardware coherency until the - cluster is set up and coherent. If the cluster is not ready, - then the CPU will wait in the CPU_COMING_UP state until the - cluster has been set up. - - Next state: - CPU_UP - Conditions: - The CPU's parent cluster must be in CLUSTER_UP. - Trigger events: - Transition of the parent cluster to CLUSTER_UP. - - Refer to the "Cluster state" section for a description of the - CLUSTER_UP state. - - -CPU_UP: - When a CPU reaches the CPU_UP state, it is safe for the CPU to - start participating in local coherency. - - This is done by jumping to the kernel's CPU resume code. - - Note that the definition of this state is slightly different - from the basic model definition: CPU_UP does not mean that the - CPU is coherent yet, but it does mean that it is safe to resume - the kernel. The kernel handles the rest of the resume - procedure, so the remaining steps are not visible as part of the - race avoidance algorithm. - - The CPU remains in this state until an explicit policy decision - is made to shut down or suspend the CPU. - - Next state: - CPU_GOING_DOWN - Conditions: - none - Trigger events: - explicit policy decision - - -CPU_GOING_DOWN: - While in this state, the CPU exits coherency, including any - operations required to achieve this (such as cleaning data - caches). - - Next state: - CPU_DOWN - Conditions: - local CPU teardown complete - Trigger events: - (spontaneous) - - -Cluster state -------------- - -A cluster is a group of connected CPUs with some common resources. -Because a cluster contains multiple CPUs, it can be doing multiple -things at the same time. This has some implications. In particular, a -CPU can start up while another CPU is tearing the cluster down. - -In this discussion, the "outbound side" is the view of the cluster state -as seen by a CPU tearing the cluster down. The "inbound side" is the -view of the cluster state as seen by a CPU setting the CPU up. - -In order to enable safe coordination in such situations, it is important -that a CPU which is setting up the cluster can advertise its state -independently of the CPU which is tearing down the cluster. For this -reason, the cluster state is split into two parts: - - "cluster" state: The global state of the cluster; or the state - on the outbound side: - - - CLUSTER_DOWN - - CLUSTER_UP - - CLUSTER_GOING_DOWN - - "inbound" state: The state of the cluster on the inbound side. - - - INBOUND_NOT_COMING_UP - - INBOUND_COMING_UP - - - The different pairings of these states results in six possible - states for the cluster as a whole:: - - CLUSTER_UP - +==========> INBOUND_NOT_COMING_UP -------------+ - # | - | - CLUSTER_UP <----+ | - INBOUND_COMING_UP | v - - ^ CLUSTER_GOING_DOWN CLUSTER_GOING_DOWN - # INBOUND_COMING_UP <=== INBOUND_NOT_COMING_UP - - CLUSTER_DOWN | | - INBOUND_COMING_UP <----+ | - | - ^ | - +=========== CLUSTER_DOWN <------------+ - INBOUND_NOT_COMING_UP - - Transitions -----> can only be made by the outbound CPU, and - only involve changes to the "cluster" state. - - Transitions ===##> can only be made by the inbound CPU, and only - involve changes to the "inbound" state, except where there is no - further transition possible on the outbound side (i.e., the - outbound CPU has put the cluster into the CLUSTER_DOWN state). - - The race avoidance algorithm does not provide a way to determine - which exact CPUs within the cluster play these roles. This must - be decided in advance by some other means. Refer to the section - "Last man and first man selection" for more explanation. - - - CLUSTER_DOWN/INBOUND_NOT_COMING_UP is the only state where the - cluster can actually be powered down. - - The parallelism of the inbound and outbound CPUs is observed by - the existence of two different paths from CLUSTER_GOING_DOWN/ - INBOUND_NOT_COMING_UP (corresponding to GOING_DOWN in the basic - model) to CLUSTER_DOWN/INBOUND_COMING_UP (corresponding to - COMING_UP in the basic model). The second path avoids cluster - teardown completely. - - CLUSTER_UP/INBOUND_COMING_UP is equivalent to UP in the basic - model. The final transition to CLUSTER_UP/INBOUND_NOT_COMING_UP - is trivial and merely resets the state machine ready for the - next cycle. - - Details of the allowable transitions follow. - - The next state in each case is notated - - <cluster state>/<inbound state> (<transitioner>) - - where the <transitioner> is the side on which the transition - can occur; either the inbound or the outbound side. - - -CLUSTER_DOWN/INBOUND_NOT_COMING_UP: - Next state: - CLUSTER_DOWN/INBOUND_COMING_UP (inbound) - Conditions: - none - - Trigger events: - a) an explicit hardware power-up operation, resulting - from a policy decision on another CPU; - - b) a hardware event, such as an interrupt. - - -CLUSTER_DOWN/INBOUND_COMING_UP: - - In this state, an inbound CPU sets up the cluster, including - enabling of hardware coherency at the cluster level and any - other operations (such as cache invalidation) which are required - in order to achieve this. - - The purpose of this state is to do sufficient cluster-level - setup to enable other CPUs in the cluster to enter coherency - safely. - - Next state: - CLUSTER_UP/INBOUND_COMING_UP (inbound) - Conditions: - cluster-level setup and hardware coherency complete - Trigger events: - (spontaneous) - - -CLUSTER_UP/INBOUND_COMING_UP: - - Cluster-level setup is complete and hardware coherency is - enabled for the cluster. Other CPUs in the cluster can safely - enter coherency. - - This is a transient state, leading immediately to - CLUSTER_UP/INBOUND_NOT_COMING_UP. All other CPUs on the cluster - should consider treat these two states as equivalent. - - Next state: - CLUSTER_UP/INBOUND_NOT_COMING_UP (inbound) - Conditions: - none - Trigger events: - (spontaneous) - - -CLUSTER_UP/INBOUND_NOT_COMING_UP: - - Cluster-level setup is complete and hardware coherency is - enabled for the cluster. Other CPUs in the cluster can safely - enter coherency. - - The cluster will remain in this state until a policy decision is - made to power the cluster down. - - Next state: - CLUSTER_GOING_DOWN/INBOUND_NOT_COMING_UP (outbound) - Conditions: - none - Trigger events: - policy decision to power down the cluster - - -CLUSTER_GOING_DOWN/INBOUND_NOT_COMING_UP: - - An outbound CPU is tearing the cluster down. The selected CPU - must wait in this state until all CPUs in the cluster are in the - CPU_DOWN state. - - When all CPUs are in the CPU_DOWN state, the cluster can be torn - down, for example by cleaning data caches and exiting - cluster-level coherency. - - To avoid wasteful unnecessary teardown operations, the outbound - should check the inbound cluster state for asynchronous - transitions to INBOUND_COMING_UP. Alternatively, individual - CPUs can be checked for entry into CPU_COMING_UP or CPU_UP. - - - Next states: - - CLUSTER_DOWN/INBOUND_NOT_COMING_UP (outbound) - Conditions: - cluster torn down and ready to power off - Trigger events: - (spontaneous) - - CLUSTER_GOING_DOWN/INBOUND_COMING_UP (inbound) - Conditions: - none - - Trigger events: - a) an explicit hardware power-up operation, - resulting from a policy decision on another - CPU; - - b) a hardware event, such as an interrupt. - - -CLUSTER_GOING_DOWN/INBOUND_COMING_UP: - - The cluster is (or was) being torn down, but another CPU has - come online in the meantime and is trying to set up the cluster - again. - - If the outbound CPU observes this state, it has two choices: - - a) back out of teardown, restoring the cluster to the - CLUSTER_UP state; - - b) finish tearing the cluster down and put the cluster - in the CLUSTER_DOWN state; the inbound CPU will - set up the cluster again from there. - - Choice (a) permits the removal of some latency by avoiding - unnecessary teardown and setup operations in situations where - the cluster is not really going to be powered down. - - - Next states: - - CLUSTER_UP/INBOUND_COMING_UP (outbound) - Conditions: - cluster-level setup and hardware - coherency complete - - Trigger events: - (spontaneous) - - CLUSTER_DOWN/INBOUND_COMING_UP (outbound) - Conditions: - cluster torn down and ready to power off - - Trigger events: - (spontaneous) - - -Last man and First man selection --------------------------------- - -The CPU which performs cluster tear-down operations on the outbound side -is commonly referred to as the "last man". - -The CPU which performs cluster setup on the inbound side is commonly -referred to as the "first man". - -The race avoidance algorithm documented above does not provide a -mechanism to choose which CPUs should play these roles. - - -Last man: - -When shutting down the cluster, all the CPUs involved are initially -executing Linux and hence coherent. Therefore, ordinary spinlocks can -be used to select a last man safely, before the CPUs become -non-coherent. - - -First man: - -Because CPUs may power up asynchronously in response to external wake-up -events, a dynamic mechanism is needed to make sure that only one CPU -attempts to play the first man role and do the cluster-level -initialisation: any other CPUs must wait for this to complete before -proceeding. - -Cluster-level initialisation may involve actions such as configuring -coherency controls in the bus fabric. - -The current implementation in mcpm_head.S uses a separate mutual exclusion -mechanism to do this arbitration. This mechanism is documented in -detail in vlocks.txt. - - -Features and Limitations ------------------------- - -Implementation: - - The current ARM-based implementation is split between - arch/arm/common/mcpm_head.S (low-level inbound CPU operations) and - arch/arm/common/mcpm_entry.c (everything else): - - __mcpm_cpu_going_down() signals the transition of a CPU to the - CPU_GOING_DOWN state. - - __mcpm_cpu_down() signals the transition of a CPU to the CPU_DOWN - state. - - A CPU transitions to CPU_COMING_UP and then to CPU_UP via the - low-level power-up code in mcpm_head.S. This could - involve CPU-specific setup code, but in the current - implementation it does not. - - __mcpm_outbound_enter_critical() and __mcpm_outbound_leave_critical() - handle transitions from CLUSTER_UP to CLUSTER_GOING_DOWN - and from there to CLUSTER_DOWN or back to CLUSTER_UP (in - the case of an aborted cluster power-down). - - These functions are more complex than the __mcpm_cpu_*() - functions due to the extra inter-CPU coordination which - is needed for safe transitions at the cluster level. - - A cluster transitions from CLUSTER_DOWN back to CLUSTER_UP via - the low-level power-up code in mcpm_head.S. This - typically involves platform-specific setup code, - provided by the platform-specific power_up_setup - function registered via mcpm_sync_init. - -Deep topologies: - - As currently described and implemented, the algorithm does not - support CPU topologies involving more than two levels (i.e., - clusters of clusters are not supported). The algorithm could be - extended by replicating the cluster-level states for the - additional topological levels, and modifying the transition - rules for the intermediate (non-outermost) cluster levels. - - -Colophon --------- - -Originally created and documented by Dave Martin for Linaro Limited, in -collaboration with Nicolas Pitre and Achin Gupta. - -Copyright (C) 2012-2013 Linaro Limited -Distributed under the terms of Version 2 of the GNU General Public -License, as defined in linux/COPYING. diff --git a/Documentation/arm/features.rst b/Documentation/arm/features.rst deleted file mode 100644 index 7414ec03dd15..000000000000 --- a/Documentation/arm/features.rst +++ /dev/null @@ -1,3 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -.. kernel-feat:: $srctree/Documentation/features arm diff --git a/Documentation/arm/firmware.rst b/Documentation/arm/firmware.rst deleted file mode 100644 index efd844baec1d..000000000000 --- a/Documentation/arm/firmware.rst +++ /dev/null @@ -1,72 +0,0 @@ -========================================================================== -Interface for registering and calling firmware-specific operations for ARM -========================================================================== - -Written by Tomasz Figa <t.figa@samsung.com> - -Some boards are running with secure firmware running in TrustZone secure -world, which changes the way some things have to be initialized. This makes -a need to provide an interface for such platforms to specify available firmware -operations and call them when needed. - -Firmware operations can be specified by filling in a struct firmware_ops -with appropriate callbacks and then registering it with register_firmware_ops() -function:: - - void register_firmware_ops(const struct firmware_ops *ops) - -The ops pointer must be non-NULL. More information about struct firmware_ops -and its members can be found in arch/arm/include/asm/firmware.h header. - -There is a default, empty set of operations provided, so there is no need to -set anything if platform does not require firmware operations. - -To call a firmware operation, a helper macro is provided:: - - #define call_firmware_op(op, ...) \ - ((firmware_ops->op) ? firmware_ops->op(__VA_ARGS__) : (-ENOSYS)) - -the macro checks if the operation is provided and calls it or otherwise returns --ENOSYS to signal that given operation is not available (for example, to allow -fallback to legacy operation). - -Example of registering firmware operations:: - - /* board file */ - - static int platformX_do_idle(void) - { - /* tell platformX firmware to enter idle */ - return 0; - } - - static int platformX_cpu_boot(int i) - { - /* tell platformX firmware to boot CPU i */ - return 0; - } - - static const struct firmware_ops platformX_firmware_ops = { - .do_idle = exynos_do_idle, - .cpu_boot = exynos_cpu_boot, - /* other operations not available on platformX */ - }; - - /* init_early callback of machine descriptor */ - static void __init board_init_early(void) - { - register_firmware_ops(&platformX_firmware_ops); - } - -Example of using a firmware operation:: - - /* some platform code, e.g. SMP initialization */ - - __raw_writel(__pa_symbol(exynos4_secondary_startup), - CPU1_BOOT_REG); - - /* Call Exynos specific smc call */ - if (call_firmware_op(cpu_boot, cpu) == -ENOSYS) - cpu_boot_legacy(...); /* Try legacy way */ - - gic_raise_softirq(cpumask_of(cpu), 1); diff --git a/Documentation/arm/google/chromebook-boot-flow.rst b/Documentation/arm/google/chromebook-boot-flow.rst deleted file mode 100644 index 36da77684bba..000000000000 --- a/Documentation/arm/google/chromebook-boot-flow.rst +++ /dev/null @@ -1,69 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -====================================== -Chromebook Boot Flow -====================================== - -Most recent Chromebooks that use device tree are using the opensource -depthcharge_ bootloader. Depthcharge_ expects the OS to be packaged as a `FIT -Image`_ which contains an OS image as well as a collection of device trees. It -is up to depthcharge_ to pick the right device tree from the `FIT Image`_ and -provide it to the OS. - -The scheme that depthcharge_ uses to pick the device tree takes into account -three variables: - -- Board name, specified at depthcharge_ compile time. This is $(BOARD) below. -- Board revision number, determined at runtime (perhaps by reading GPIO - strappings, perhaps via some other method). This is $(REV) below. -- SKU number, read from GPIO strappings at boot time. This is $(SKU) below. - -For recent Chromebooks, depthcharge_ creates a match list that looks like this: - -- google,$(BOARD)-rev$(REV)-sku$(SKU) -- google,$(BOARD)-rev$(REV) -- google,$(BOARD)-sku$(SKU) -- google,$(BOARD) - -Note that some older Chromebooks use a slightly different list that may -not include SKU matching or may prioritize SKU/rev differently. - -Note that for some boards there may be extra board-specific logic to inject -extra compatibles into the list, but this is uncommon. - -Depthcharge_ will look through all device trees in the `FIT Image`_ trying to -find one that matches the most specific compatible. It will then look -through all device trees in the `FIT Image`_ trying to find the one that -matches the *second most* specific compatible, etc. - -When searching for a device tree, depthcharge_ doesn't care where the -compatible string falls within a device tree's root compatible string array. -As an example, if we're on board "lazor", rev 4, SKU 0 and we have two device -trees: - -- "google,lazor-rev5-sku0", "google,lazor-rev4-sku0", "qcom,sc7180" -- "google,lazor", "qcom,sc7180" - -Then depthcharge_ will pick the first device tree even though -"google,lazor-rev4-sku0" was the second compatible listed in that device tree. -This is because it is a more specific compatible than "google,lazor". - -It should be noted that depthcharge_ does not have any smarts to try to -match board or SKU revisions that are "close by". That is to say that -if depthcharge_ knows it's on "rev4" of a board but there is no "rev4" -device tree then depthcharge_ *won't* look for a "rev3" device tree. - -In general when any significant changes are made to a board the board -revision number is increased even if none of those changes need to -be reflected in the device tree. Thus it's fairly common to see device -trees with multiple revisions. - -It should be noted that, taking into account the above system that -depthcharge_ has, the most flexibility is achieved if the device tree -supporting the newest revision(s) of a board omits the "-rev{REV}" -compatible strings. When this is done then if you get a new board -revision and try to run old software on it then we'll at pick the -newest device tree we know about. - -.. _depthcharge: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/depthcharge/ -.. _`FIT Image`: https://doc.coreboot.org/lib/payloads/fit.html diff --git a/Documentation/arm/index.rst b/Documentation/arm/index.rst deleted file mode 100644 index fd43502ae924..000000000000 --- a/Documentation/arm/index.rst +++ /dev/null @@ -1,85 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -================ -ARM Architecture -================ - -.. toctree:: - :maxdepth: 1 - - arm - booting - cluster-pm-race-avoidance - firmware - interrupts - kernel_mode_neon - kernel_user_helpers - memory - mem_alignment - tcm - setup - swp_emulation - uefi - vlocks - porting - - features - -SoC-specific documents -====================== - -.. toctree:: - :maxdepth: 1 - - google/chromebook-boot-flow - - ixp4xx - - marvell - microchip - - netwinder - nwfpe/index - - keystone/overview - keystone/knav-qmss - - omap/index - - pxa/mfp - - - sa1100/index - - stm32/stm32f746-overview - stm32/overview - stm32/stm32h743-overview - stm32/stm32h750-overview - stm32/stm32f769-overview - stm32/stm32f429-overview - stm32/stm32mp13-overview - stm32/stm32mp151-overview - stm32/stm32mp157-overview - stm32/stm32-dma-mdma-chaining - - sunxi - - samsung/index - - sunxi/clocks - - spear/overview - - sti/stih407-overview - sti/stih418-overview - sti/overview - - vfp/release-notes - - -.. only:: subproject and html - - Indices - ======= - - * :ref:`genindex` diff --git a/Documentation/arm/interrupts.rst b/Documentation/arm/interrupts.rst deleted file mode 100644 index 2ae70e0e9732..000000000000 --- a/Documentation/arm/interrupts.rst +++ /dev/null @@ -1,169 +0,0 @@ -========== -Interrupts -========== - -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/ixp4xx.rst b/Documentation/arm/ixp4xx.rst deleted file mode 100644 index a57235616294..000000000000 --- a/Documentation/arm/ixp4xx.rst +++ /dev/null @@ -1,173 +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 software: - -- 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/kernel_mode_neon.rst b/Documentation/arm/kernel_mode_neon.rst deleted file mode 100644 index 9bfb71a2a9b9..000000000000 --- a/Documentation/arm/kernel_mode_neon.rst +++ /dev/null @@ -1,124 +0,0 @@ -================ -Kernel mode NEON -================ - -TL;DR summary -------------- -* Use only NEON instructions, or VFP instructions that don't rely on support - code -* Isolate your NEON code in a separate compilation unit, and compile it with - '-march=armv7-a -mfpu=neon -mfloat-abi=softfp' -* Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your - NEON code -* Don't sleep in your NEON code, and be aware that it will be executed with - preemption disabled - - -Introduction ------------- -It is possible to use NEON instructions (and in some cases, VFP instructions) in -code that runs in kernel mode. However, for performance reasons, the NEON/VFP -register file is not preserved and restored at every context switch or taken -exception like the normal register file is, so some manual intervention is -required. Furthermore, special care is required for code that may sleep [i.e., -may call schedule()], as NEON or VFP instructions will be executed in a -non-preemptible section for reasons outlined below. - - -Lazy preserve and restore -------------------------- -The NEON/VFP register file is managed using lazy preserve (on UP systems) and -lazy restore (on both SMP and UP systems). This means that the register file is -kept 'live', and is only preserved and restored when multiple tasks are -contending for the NEON/VFP unit (or, in the SMP case, when a task migrates to -another core). Lazy restore is implemented by disabling the NEON/VFP unit after -every context switch, resulting in a trap when subsequently a NEON/VFP -instruction is issued, allowing the kernel to step in and perform the restore if -necessary. - -Any use of the NEON/VFP unit in kernel mode should not interfere with this, so -it is required to do an 'eager' preserve of the NEON/VFP register file, and -enable the NEON/VFP unit explicitly so no exceptions are generated on first -subsequent use. This is handled by the function kernel_neon_begin(), which -should be called before any kernel mode NEON or VFP instructions are issued. -Likewise, the NEON/VFP unit should be disabled again after use to make sure user -mode will hit the lazy restore trap upon next use. This is handled by the -function kernel_neon_end(). - - -Interruptions in kernel mode ----------------------------- -For reasons of performance and simplicity, it was decided that there shall be no -preserve/restore mechanism for the kernel mode NEON/VFP register contents. This -implies that interruptions of a kernel mode NEON section can only be allowed if -they are guaranteed not to touch the NEON/VFP registers. For this reason, the -following rules and restrictions apply in the kernel: -* NEON/VFP code is not allowed in interrupt context; -* NEON/VFP code is not allowed to sleep; -* NEON/VFP code is executed with preemption disabled. - -If latency is a concern, it is possible to put back to back calls to -kernel_neon_end() and kernel_neon_begin() in places in your code where none of -the NEON registers are live. (Additional calls to kernel_neon_begin() should be -reasonably cheap if no context switch occurred in the meantime) - - -VFP and support code --------------------- -Earlier versions of VFP (prior to version 3) rely on software support for things -like IEEE-754 compliant underflow handling etc. When the VFP unit needs such -software assistance, it signals the kernel by raising an undefined instruction -exception. The kernel responds by inspecting the VFP control registers and the -current instruction and arguments, and emulates the instruction in software. - -Such software assistance is currently not implemented for VFP instructions -executed in kernel mode. If such a condition is encountered, the kernel will -fail and generate an OOPS. - - -Separating NEON code from ordinary code ---------------------------------------- -The compiler is not aware of the special significance of kernel_neon_begin() and -kernel_neon_end(), i.e., that it is only allowed to issue NEON/VFP instructions -between calls to these respective functions. Furthermore, GCC may generate NEON -instructions of its own at -O3 level if -mfpu=neon is selected, and even if the -kernel is currently compiled at -O2, future changes may result in NEON/VFP -instructions appearing in unexpected places if no special care is taken. - -Therefore, the recommended and only supported way of using NEON/VFP in the -kernel is by adhering to the following rules: - -* isolate the NEON code in a separate compilation unit and compile it with - '-march=armv7-a -mfpu=neon -mfloat-abi=softfp'; -* issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls - into the unit containing the NEON code from a compilation unit which is *not* - built with the GCC flag '-mfpu=neon' set. - -As the kernel is compiled with '-msoft-float', the above will guarantee that -both NEON and VFP instructions will only ever appear in designated compilation -units at any optimization level. - - -NEON assembler --------------- -NEON assembler is supported with no additional caveats as long as the rules -above are followed. - - -NEON code generated by GCC --------------------------- -The GCC option -ftree-vectorize (implied by -O3) tries to exploit implicit -parallelism, and generates NEON code from ordinary C source code. This is fully -supported as long as the rules above are followed. - - -NEON intrinsics ---------------- -NEON intrinsics are also supported. However, as code using NEON intrinsics -relies on the GCC header <arm_neon.h>, (which #includes <stdint.h>), you should -observe the following in addition to the rules above: - -* Compile the unit containing the NEON intrinsics with '-ffreestanding' so GCC - uses its builtin version of <stdint.h> (this is a C99 header which the kernel - does not supply); -* Include <arm_neon.h> last, or at least after <linux/types.h> diff --git a/Documentation/arm/kernel_user_helpers.rst b/Documentation/arm/kernel_user_helpers.rst deleted file mode 100644 index eb6f3d916622..000000000000 --- a/Documentation/arm/kernel_user_helpers.rst +++ /dev/null @@ -1,268 +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/keystone/knav-qmss.rst b/Documentation/arm/keystone/knav-qmss.rst deleted file mode 100644 index 7f7638d80b42..000000000000 --- a/Documentation/arm/keystone/knav-qmss.rst +++ /dev/null @@ -1,60 +0,0 @@ -====================================================================== -Texas Instruments Keystone Navigator Queue Management SubSystem driver -====================================================================== - -Driver source code path - drivers/soc/ti/knav_qmss.c - drivers/soc/ti/knav_qmss_acc.c - -The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of -the main hardware sub system which forms the backbone of the Keystone -multi-core Navigator. QMSS consist of queue managers, packed-data structure -processors(PDSP), linking RAM, descriptor pools and infrastructure -Packet DMA. -The Queue Manager is a hardware module that is responsible for accelerating -management of the packet queues. Packets are queued/de-queued by writing or -reading descriptor address to a particular memory mapped location. The PDSPs -perform QMSS related functions like accumulation, QoS, or event management. -Linking RAM registers are used to link the descriptors which are stored in -descriptor RAM. Descriptor RAM is configurable as internal or external memory. -The QMSS driver manages the PDSP setups, linking RAM regions, -queue pool management (allocation, push, pop and notify) and descriptor -pool management. - -knav qmss driver provides a set of APIs to drivers to open/close qmss queues, -allocate descriptor pools, map the descriptors, push/pop to queues etc. For -details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h - -DT documentation is available at -Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt - -Accumulator QMSS queues using PDSP firmware -============================================ -The QMSS PDSP firmware support accumulator channel that can monitor a single -queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the -driver that interface with the accumulator PDSP. This configures -accumulator channels defined in DTS (example in DT documentation) to monitor -1 or 32 queues per channel. More description on the firmware is available in -CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at - - git://git.ti.com/keystone-rtos/qmss-lld.git - -k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator -channels. This firmware is available under ti-keystone folder of -firmware.git at - - git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git - -To use copy the firmware image to lib/firmware folder of the initramfs or -ubifs file system and provide a sym link to k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin -in the file system and boot up the kernel. User would see - - "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP" - -in the boot up log if loading of firmware to PDSP is successful. - -Use of accumulated queues requires the firmware image to be present in the -file system. The driver doesn't acc queues to the supported queue range if -PDSP is not running in the SoC. The API call fails if there is a queue open -request to an acc queue and PDSP is not running. So make sure to copy firmware -to file system before using these queue types. diff --git a/Documentation/arm/keystone/overview.rst b/Documentation/arm/keystone/overview.rst deleted file mode 100644 index cd90298c493c..000000000000 --- a/Documentation/arm/keystone/overview.rst +++ /dev/null @@ -1,74 +0,0 @@ -========================== -TI Keystone Linux Overview -========================== - -Introduction ------------- -Keystone range of SoCs are based on ARM Cortex-A15 MPCore Processors -and c66x DSP cores. This document describes essential information required -for users to run Linux on Keystone based EVMs from Texas Instruments. - -Following SoCs & EVMs are currently supported:- - -K2HK SoC and EVM -================= - -a.k.a Keystone 2 Hawking/Kepler SoC -TCI6636K2H & TCI6636K2K: See documentation at - - http://www.ti.com/product/tci6638k2k - http://www.ti.com/product/tci6638k2h - -EVM: - http://www.advantech.com/Support/TI-EVM/EVMK2HX_sd.aspx - -K2E SoC and EVM -=============== - -a.k.a Keystone 2 Edison SoC - -K2E - 66AK2E05: - -See documentation at - - http://www.ti.com/product/66AK2E05/technicaldocuments - -EVM: - https://www.einfochips.com/index.php/partnerships/texas-instruments/k2e-evm.html - -K2L SoC and EVM -=============== - -a.k.a Keystone 2 Lamarr SoC - -K2L - TCI6630K2L: - -See documentation at - http://www.ti.com/product/TCI6630K2L/technicaldocuments - -EVM: - https://www.einfochips.com/index.php/partnerships/texas-instruments/k2l-evm.html - -Configuration -------------- - -All of the K2 SoCs/EVMs share a common defconfig, keystone_defconfig and same -image is used to boot on individual EVMs. The platform configuration is -specified through DTS. Following are the DTS used: - - K2HK EVM: - k2hk-evm.dts - K2E EVM: - k2e-evm.dts - K2L EVM: - k2l-evm.dts - -The device tree documentation for the keystone machines are located at - - Documentation/devicetree/bindings/arm/keystone/keystone.txt - -Document Author ---------------- -Murali Karicheri <m-karicheri2@ti.com> - -Copyright 2015 Texas Instruments diff --git a/Documentation/arm/marvell.rst b/Documentation/arm/marvell.rst deleted file mode 100644 index 3d369a566038..000000000000 --- a/Documentation/arm/marvell.rst +++ /dev/null @@ -1,527 +0,0 @@ -================ -ARM Marvell SoCs -================ - -This document lists all the ARM Marvell SoCs that are currently -supported in mainline by the Linux kernel. As the Marvell families of -SoCs are large and complex, it is hard to understand where the support -for a particular SoC is available in the Linux kernel. This document -tries to help in understanding where those SoCs are supported, and to -match them with their corresponding public datasheet, when available. - -Orion family ------------- - - Flavors: - - 88F5082 - - 88F5181 a.k.a Orion-1 - - 88F5181L a.k.a Orion-VoIP - - 88F5182 a.k.a Orion-NAS - - - Datasheet: https://web.archive.org/web/20210124231420/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-datasheet.pdf - - Programmer's User Guide: https://web.archive.org/web/20210124231536/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-opensource-manual.pdf - - User Manual: https://web.archive.org/web/20210124231631/http://csclub.uwaterloo.ca/~board/ts7800/MV88F5182-usermanual.pdf - - Functional Errata: https://web.archive.org/web/20210704165540/https://www.digriz.org.uk/ts78xx/88F5182_Functional_Errata.pdf - - 88F5281 a.k.a Orion-2 - - - Datasheet: https://web.archive.org/web/20131028144728/http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf - - 88F6183 a.k.a Orion-1-90 - Homepage: - https://web.archive.org/web/20080607215437/http://www.marvell.com/products/media/index.jsp - Core: - Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible - Linux kernel mach directory: - arch/arm/mach-orion5x - Linux kernel plat directory: - arch/arm/plat-orion - -Kirkwood family ---------------- - - Flavors: - - 88F6282 a.k.a Armada 300 - - - Product Brief : https://web.archive.org/web/20111027032509/http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf - - 88F6283 a.k.a Armada 310 - - - Product Brief : https://web.archive.org/web/20111027032509/http://www.marvell.com/embedded-processors/armada-300/assets/armada_310.pdf - - 88F6190 - - - Product Brief : https://web.archive.org/web/20130730072715/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6190-003_WEB.pdf - - Hardware Spec : https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf - - Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf - - 88F6192 - - - Product Brief : https://web.archive.org/web/20131113121446/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6192-003_ver1.pdf - - Hardware Spec : https://web.archive.org/web/20121021182835/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F619x_OpenSource.pdf - - Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf - - 88F6182 - - 88F6180 - - - Product Brief : https://web.archive.org/web/20120616201621/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-003_ver1.pdf - - Hardware Spec : https://web.archive.org/web/20130730091654/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf - - Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf - - 88F6280 - - - Product Brief : https://web.archive.org/web/20130730091058/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6280_SoC_PB-001.pdf - - 88F6281 - - - Product Brief : https://web.archive.org/web/20120131133709/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf - - Hardware Spec : https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf - - Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf - - 88F6321 - - 88F6322 - - 88F6323 - - - Product Brief : https://web.archive.org/web/20120616201639/http://www.marvell.com/embedded-processors/kirkwood/assets/88f632x_pb.pdf - Homepage: - https://web.archive.org/web/20160513194943/http://www.marvell.com/embedded-processors/kirkwood/ - Core: - Feroceon 88fr131 ARMv5 compatible - Linux kernel mach directory: - arch/arm/mach-mvebu - Linux kernel plat directory: - none - -Discovery family ----------------- - - Flavors: - - MV78100 - - - Product Brief : https://web.archive.org/web/20120616194711/http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78100-003_WEB.pdf - - Hardware Spec : https://web.archive.org/web/20141005120451/http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78100_OpenSource.pdf - - Functional Spec: https://web.archive.org/web/20111110081125/http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf - - MV78200 - - - Product Brief : https://web.archive.org/web/20140801121623/http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV78200-002_WEB.pdf - - Hardware Spec : https://web.archive.org/web/20141005120458/http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV78200_OpenSource.pdf - - Functional Spec: https://web.archive.org/web/20111110081125/http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf - - - MV76100 - - - Product Brief : https://web.archive.org/web/20140722064429/http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV76100-002_WEB.pdf - - Hardware Spec : https://web.archive.org/web/20140722064425/http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV76100_OpenSource.pdf - - Functional Spec: https://web.archive.org/web/20111110081125/http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf - - Not supported by the Linux kernel. - - Homepage: - https://web.archive.org/web/20110924171043/http://www.marvell.com/embedded-processors/discovery-innovation/ - Core: - Feroceon 88fr571-vd ARMv5 compatible - - Linux kernel mach directory: - arch/arm/mach-mv78xx0 - Linux kernel plat directory: - arch/arm/plat-orion - -EBU Armada family ------------------ - - Armada 370 Flavors: - - 88F6710 - - 88F6707 - - 88F6W11 - - - Product infos: https://web.archive.org/web/20141002083258/http://www.marvell.com/embedded-processors/armada-370/ - - Product Brief: https://web.archive.org/web/20121115063038/http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf - - Hardware Spec: https://web.archive.org/web/20140617183747/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf - - Functional Spec: https://web.archive.org/web/20140617183701/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf - - Core: - Sheeva ARMv7 compatible PJ4B - - Armada XP Flavors: - - MV78230 - - MV78260 - - MV78460 - - NOTE: - not to be confused with the non-SMP 78xx0 SoCs - - - Product infos: https://web.archive.org/web/20150101215721/http://www.marvell.com/embedded-processors/armada-xp/ - - Product Brief: https://web.archive.org/web/20121021173528/http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf - - Functional Spec: https://web.archive.org/web/20180829171131/http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf - - Hardware Specs: - - https://web.archive.org/web/20141127013651/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF - - https://web.archive.org/web/20141222000224/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF - - https://web.archive.org/web/20141222000230/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF - - Core: - Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP - - Armada 375 Flavors: - - 88F6720 - - - Product infos: https://web.archive.org/web/20140108032402/http://www.marvell.com/embedded-processors/armada-375/ - - Product Brief: https://web.archive.org/web/20131216023516/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf - - Core: - ARM Cortex-A9 - - Armada 38x Flavors: - - 88F6810 Armada 380 - - 88F6811 Armada 381 - - 88F6821 Armada 382 - - 88F6W21 Armada 383 - - 88F6820 Armada 385 - - 88F6825 - - 88F6828 Armada 388 - - - Product infos: https://web.archive.org/web/20181006144616/http://www.marvell.com/embedded-processors/armada-38x/ - - Functional Spec: https://web.archive.org/web/20200420191927/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-38x-functional-specifications-2015-11.pdf - - Hardware Spec: https://web.archive.org/web/20180713105318/https://www.marvell.com/docs/embedded-processors/assets/marvell-embedded-processors-armada-38x-hardware-specifications-2017-03.pdf - - Design guide: https://web.archive.org/web/20180712231737/https://www.marvell.com/docs/embedded-processors/assets/marvell-embedded-processors-armada-38x-hardware-design-guide-2017-08.pdf - - Core: - ARM Cortex-A9 - - Armada 39x Flavors: - - 88F6920 Armada 390 - - 88F6925 Armada 395 - - 88F6928 Armada 398 - - - Product infos: https://web.archive.org/web/20181020222559/http://www.marvell.com/embedded-processors/armada-39x/ - - Core: - ARM Cortex-A9 - - Linux kernel mach directory: - arch/arm/mach-mvebu - Linux kernel plat directory: - none - -EBU Armada family ARMv8 ------------------------ - - Armada 3710/3720 Flavors: - - 88F3710 - - 88F3720 - - Core: - ARM Cortex A53 (ARMv8) - - Homepage: - https://web.archive.org/web/20181103003602/http://www.marvell.com/embedded-processors/armada-3700/ - - Product Brief: - https://web.archive.org/web/20210121194810/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-37xx-product-brief-2016-01.pdf - - Hardware Spec: - https://web.archive.org/web/20210202162011/http://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-37xx-hardware-specifications-2019-09.pdf - - Device tree files: - arch/arm64/boot/dts/marvell/armada-37* - - Armada 7K Flavors: - - 88F6040 (AP806 Quad 600 MHz + one CP110) - - 88F7020 (AP806 Dual + one CP110) - - 88F7040 (AP806 Quad + one CP110) - - Core: ARM Cortex A72 - - Homepage: - https://web.archive.org/web/20181020222606/http://www.marvell.com/embedded-processors/armada-70xx/ - - Product Brief: - - https://web.archive.org/web/20161010105541/http://www.marvell.com/embedded-processors/assets/Armada7020PB-Jan2016.pdf - - https://web.archive.org/web/20160928154533/http://www.marvell.com/embedded-processors/assets/Armada7040PB-Jan2016.pdf - - Device tree files: - arch/arm64/boot/dts/marvell/armada-70* - - Armada 8K Flavors: - - 88F8020 (AP806 Dual + two CP110) - - 88F8040 (AP806 Quad + two CP110) - Core: - ARM Cortex A72 - - Homepage: - https://web.archive.org/web/20181022004830/http://www.marvell.com/embedded-processors/armada-80xx/ - - Product Brief: - - https://web.archive.org/web/20210124233728/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-8020-product-brief-2017-12.pdf - - https://web.archive.org/web/20161010105532/http://www.marvell.com/embedded-processors/assets/Armada8040PB-Jan2016.pdf - - Device tree files: - arch/arm64/boot/dts/marvell/armada-80* - - Octeon TX2 CN913x Flavors: - - CN9130 (AP807 Quad + one internal CP115) - - CN9131 (AP807 Quad + one internal CP115 + one external CP115 / 88F8215) - - CN9132 (AP807 Quad + one internal CP115 + two external CP115 / 88F8215) - - Core: - ARM Cortex A72 - - Homepage: - https://web.archive.org/web/20200803150818/https://www.marvell.com/products/infrastructure-processors/multi-core-processors/octeon-tx2/octeon-tx2-cn9130.html - - Product Brief: - https://web.archive.org/web/20200803150818/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-infrastructure-processors-octeon-tx2-cn913x-product-brief-2020-02.pdf - - Device tree files: - arch/arm64/boot/dts/marvell/cn913* - -Avanta family -------------- - - Flavors: - - 88F6500 - - 88F6510 - - 88F6530P - - 88F6550 - - 88F6560 - - 88F6601 - - Homepage: - https://web.archive.org/web/20181005145041/http://www.marvell.com/broadband/ - - Product Brief: - https://web.archive.org/web/20180829171057/http://www.marvell.com/broadband/assets/Marvell_Avanta_88F6510_305_060-001_product_brief.pdf - - No public datasheet available. - - Core: - ARMv5 compatible - - Linux kernel mach directory: - no code in mainline yet, planned for the future - Linux kernel plat directory: - no code in mainline yet, planned for the future - -Storage family --------------- - - Armada SP: - - 88RC1580 - - Product infos: - https://web.archive.org/web/20191129073953/http://www.marvell.com/storage/armada-sp/ - - Core: - Sheeva ARMv7 compatible Quad-core PJ4C - - (not supported in upstream Linux kernel) - -Dove family (application processor) ------------------------------------ - - Flavors: - - 88AP510 a.k.a Armada 510 - - Product Brief: - https://web.archive.org/web/20111102020643/http://www.marvell.com/application-processors/armada-500/assets/Marvell_Armada510_SoC.pdf - - Hardware Spec: - https://web.archive.org/web/20160428160231/http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Hardware-Spec.pdf - - Functional Spec: - https://web.archive.org/web/20120130172443/http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf - - Homepage: - https://web.archive.org/web/20160822232651/http://www.marvell.com/application-processors/armada-500/ - - Core: - ARMv7 compatible - - Directory: - - arch/arm/mach-mvebu (DT enabled platforms) - - arch/arm/mach-dove (non-DT enabled platforms) - -PXA 2xx/3xx/93x/95x family --------------------------- - - Flavors: - - PXA21x, PXA25x, PXA26x - - Application processor only - - Core: ARMv5 XScale1 core - - PXA270, PXA271, PXA272 - - Product Brief : https://web.archive.org/web/20150927135510/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_pb.pdf - - Design guide : https://web.archive.org/web/20120111181937/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_design_guide.pdf - - Developers manual : https://web.archive.org/web/20150927164805/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_dev_man.pdf - - Specification : https://web.archive.org/web/20140211221535/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_emts.pdf - - Specification update : https://web.archive.org/web/20120111104906/http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf - - Application processor only - - Core: ARMv5 XScale2 core - - PXA300, PXA310, PXA320 - - PXA 300 Product Brief : https://web.archive.org/web/20120111121203/http://www.marvell.com/application-processors/pxa-family/assets/PXA300_PB_R4.pdf - - PXA 310 Product Brief : https://web.archive.org/web/20120111104515/http://www.marvell.com/application-processors/pxa-family/assets/PXA310_PB_R4.pdf - - PXA 320 Product Brief : https://web.archive.org/web/20121021182826/http://www.marvell.com/application-processors/pxa-family/assets/PXA320_PB_R4.pdf - - Design guide : https://web.archive.org/web/20130727144625/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Design_Guide.pdf - - Developers manual : https://web.archive.org/web/20130727144605/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Developers_Manual.zip - - Specifications : https://web.archive.org/web/20130727144559/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_EMTS.pdf - - Specification Update : https://web.archive.org/web/20150927183411/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Spec_Update.zip - - Reference Manual : https://web.archive.org/web/20120111103844/http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_TavorP_BootROM_Ref_Manual.pdf - - Application processor only - - Core: ARMv5 XScale3 core - - PXA930, PXA935 - - Application processor with Communication processor - - Core: ARMv5 XScale3 core - - PXA955 - - Application processor with Communication processor - - Core: ARMv7 compatible Sheeva PJ4 core - - Comments: - - * This line of SoCs originates from the XScale family developed by - Intel and acquired by Marvell in ~2006. The PXA21x, PXA25x, - PXA26x, PXA27x, PXA3xx and PXA93x were developed by Intel, while - the later PXA95x were developed by Marvell. - - * Due to their XScale origin, these SoCs have virtually nothing in - common with the other (Kirkwood, Dove, etc.) families of Marvell - SoCs, except with the MMP/MMP2 family of SoCs. - - Linux kernel mach directory: - arch/arm/mach-pxa - -MMP/MMP2/MMP3 family (communication processor) ----------------------------------------------- - - Flavors: - - PXA168, a.k.a Armada 168 - - Homepage : https://web.archive.org/web/20110926014256/http://www.marvell.com/application-processors/armada-100/armada-168.jsp - - Product brief : https://web.archive.org/web/20111102030100/http://www.marvell.com/application-processors/armada-100/assets/pxa_168_pb.pdf - - Hardware manual : https://web.archive.org/web/20160428165359/http://www.marvell.com/application-processors/armada-100/assets/armada_16x_datasheet.pdf - - Software manual : https://web.archive.org/web/20160428154454/http://www.marvell.com/application-processors/armada-100/assets/armada_16x_software_manual.pdf - - Specification update : https://web.archive.org/web/20150927160338/http://www.marvell.com/application-processors/armada-100/assets/ARMADA16x_Spec_update.pdf - - Boot ROM manual : https://web.archive.org/web/20130727205559/http://www.marvell.com/application-processors/armada-100/assets/armada_16x_ref_manual.pdf - - App node package : https://web.archive.org/web/20141005090706/http://www.marvell.com/application-processors/armada-100/assets/armada_16x_app_note_package.pdf - - Application processor only - - Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk) - - PXA910/PXA920 - - Homepage : https://web.archive.org/web/20150928121236/http://www.marvell.com/communication-processors/pxa910/ - - Product Brief : https://archive.org/download/marvell-pxa910-pb/Marvell_PXA910_Platform-001_PB.pdf - - Application processor with Communication processor - - Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk) - - PXA688, a.k.a. MMP2, a.k.a Armada 610 (OLPC XO-1.75) - - Product Brief : https://web.archive.org/web/20111102023255/http://www.marvell.com/application-processors/armada-600/assets/armada610_pb.pdf - - Application processor only - - Core: ARMv7 compatible Sheeva PJ4 88sv581x core - - PXA2128, a.k.a. MMP3, a.k.a Armada 620 (OLPC XO-4) - - Product Brief : https://web.archive.org/web/20120824055155/http://www.marvell.com/application-processors/armada/pxa2128/assets/Marvell-ARMADA-PXA2128-SoC-PB.pdf - - Application processor only - - Core: Dual-core ARMv7 compatible Sheeva PJ4C core - - PXA960/PXA968/PXA978 (Linux support not upstream) - - Application processor with Communication Processor - - Core: ARMv7 compatible Sheeva PJ4 core - - PXA986/PXA988 (Linux support not upstream) - - Application processor with Communication Processor - - Core: Dual-core ARMv7 compatible Sheeva PJ4B-MP core - - PXA1088/PXA1920 (Linux support not upstream) - - Application processor with Communication Processor - - Core: quad-core ARMv7 Cortex-A7 - - PXA1908/PXA1928/PXA1936 - - Application processor with Communication Processor - - Core: multi-core ARMv8 Cortex-A53 - - Comments: - - * This line of SoCs originates from the XScale family developed by - Intel and acquired by Marvell in ~2006. All the processors of - this MMP/MMP2 family were developed by Marvell. - - * Due to their XScale origin, these SoCs have virtually nothing in - common with the other (Kirkwood, Dove, etc.) families of Marvell - SoCs, except with the PXA family of SoCs listed above. - - Linux kernel mach directory: - arch/arm/mach-mmp - -Berlin family (Multimedia Solutions) -------------------------------------- - - - Flavors: - - 88DE3010, Armada 1000 (no Linux support) - - Core: Marvell PJ1 (ARMv5TE), Dual-core - - Product Brief: https://web.archive.org/web/20131103162620/http://www.marvell.com/digital-entertainment/assets/armada_1000_pb.pdf - - 88DE3005, Armada 1500 Mini - - Design name: BG2CD - - Core: ARM Cortex-A9, PL310 L2CC - - 88DE3006, Armada 1500 Mini Plus - - Design name: BG2CDP - - Core: Dual Core ARM Cortex-A7 - - 88DE3100, Armada 1500 - - Design name: BG2 - - Core: Marvell PJ4B-MP (ARMv7), Tauros3 L2CC - - 88DE3114, Armada 1500 Pro - - Design name: BG2Q - - Core: Quad Core ARM Cortex-A9, PL310 L2CC - - 88DE3214, Armada 1500 Pro 4K - - Design name: BG3 - - Core: ARM Cortex-A15, CA15 integrated L2CC - - 88DE3218, ARMADA 1500 Ultra - - Core: ARM Cortex-A53 - - Homepage: https://www.synaptics.com/products/multimedia-solutions - Directory: arch/arm/mach-berlin - - Comments: - - * This line of SoCs is based on Marvell Sheeva or ARM Cortex CPUs - with Synopsys DesignWare (IRQ, GPIO, Timers, ...) and PXA IP (SDHCI, USB, ETH, ...). - - * The Berlin family was acquired by Synaptics from Marvell in 2017. - -CPU Cores ---------- - -The XScale cores were designed by Intel, and shipped by Marvell in the older -PXA processors. Feroceon is a Marvell designed core that developed in-house, -and that evolved into Sheeva. The XScale and Feroceon cores were phased out -over time and replaced with Sheeva cores in later products, which subsequently -got replaced with licensed ARM Cortex-A cores. - - XScale 1 - CPUID 0x69052xxx - ARMv5, iWMMXt - XScale 2 - CPUID 0x69054xxx - ARMv5, iWMMXt - XScale 3 - CPUID 0x69056xxx or 0x69056xxx - ARMv5, iWMMXt - Feroceon-1850 88fr331 "Mohawk" - CPUID 0x5615331x or 0x41xx926x - ARMv5TE, single issue - Feroceon-2850 88fr531-vd "Jolteon" - CPUID 0x5605531x or 0x41xx926x - ARMv5TE, VFP, dual-issue - Feroceon 88fr571-vd "Jolteon" - CPUID 0x5615571x - ARMv5TE, VFP, dual-issue - Feroceon 88fr131 "Mohawk-D" - CPUID 0x5625131x - ARMv5TE, single-issue in-order - Sheeva PJ1 88sv331 "Mohawk" - CPUID 0x561584xx - ARMv5, single-issue iWMMXt v2 - Sheeva PJ4 88sv581x "Flareon" - CPUID 0x560f581x - ARMv7, idivt, optional iWMMXt v2 - Sheeva PJ4B 88sv581x - CPUID 0x561f581x - ARMv7, idivt, optional iWMMXt v2 - Sheeva PJ4B-MP / PJ4C - CPUID 0x562f584x - ARMv7, idivt/idiva, LPAE, optional iWMMXt v2 and/or NEON - -Long-term plans ---------------- - - * Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ into the - mach-mvebu/ to support all SoCs from the Marvell EBU (Engineering - Business Unit) in a single mach-<foo> directory. The plat-orion/ - would therefore disappear. - -Credits -------- - -- Maen Suleiman <maen@marvell.com> -- Lior Amsalem <alior@marvell.com> -- Thomas Petazzoni <thomas.petazzoni@free-electrons.com> -- Andrew Lunn <andrew@lunn.ch> -- Nicolas Pitre <nico@fluxnic.net> -- Eric Miao <eric.y.miao@gmail.com> diff --git a/Documentation/arm/mem_alignment.rst b/Documentation/arm/mem_alignment.rst deleted file mode 100644 index aa22893b62bc..000000000000 --- a/Documentation/arm/mem_alignment.rst +++ /dev/null @@ -1,63 +0,0 @@ -================ -Memory alignment -================ - -Too many problems popped 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/cpu/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.rst b/Documentation/arm/memory.rst deleted file mode 100644 index 0cb1e2938823..000000000000 --- a/Documentation/arm/memory.rst +++ /dev/null @@ -1,103 +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. - -ffc80000 ffefffff Fixmap mapping region. Addresses provided - by fix_to_virt() will be located here. - -ffc00000 ffc7ffff Guard region - -ff800000 ffbfffff Permanent, fixed read-only mapping of the - firmware provided DT blob - -fee00000 feffffff Mapping of PCI I/O space. This is a static - mapping within the vmalloc space. - -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 0xff800000. - -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. - -TASK_SIZE MODULES_VADDR-1 KASAn shadow memory when KASan is in use. - The range from MODULES_VADDR to the top - of the memory is shadowed here with 1 bit - per byte of memory. - -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/microchip.rst b/Documentation/arm/microchip.rst deleted file mode 100644 index e721d855f2c9..000000000000 --- a/Documentation/arm/microchip.rst +++ /dev/null @@ -1,230 +0,0 @@ -============================= -ARM Microchip SoCs (aka AT91) -============================= - - -Introduction ------------- -This document gives useful information about the ARM Microchip SoCs that are -currently supported in Linux Mainline (you know, the one on kernel.org). - -It is important to note that the Microchip (previously Atmel) ARM-based MPU -product line is historically named "AT91" or "at91" throughout the Linux kernel -development process even if this product prefix has completely disappeared from -the official Microchip product name. Anyway, files, directories, git trees, -git branches/tags and email subject always contain this "at91" sub-string. - - -AT91 SoCs ---------- -Documentation and detailed datasheet for each product are available on -the Microchip website: http://www.microchip.com. - - Flavors: - * ARM 920 based SoC - - at91rm9200 - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-1768-32-bit-ARM920T-Embedded-Microprocessor-AT91RM9200_Datasheet.pdf - - * ARM 926 based SoCs - - at91sam9260 - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6221-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9260_Datasheet.pdf - - - at91sam9xe - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6254-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9XE_Datasheet.pdf - - - at91sam9261 - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6062-ARM926EJ-S-Microprocessor-SAM9261_Datasheet.pdf - - - at91sam9263 - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6249-32-bit-ARM926EJ-S-Embedded-Microprocessor-SAM9263_Datasheet.pdf - - - at91sam9rl - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/doc6289.pdf - - - at91sam9g20 - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001516A.pdf - - - at91sam9g45 family - - at91sam9g45 - - at91sam9g46 - - at91sam9m10 - - at91sam9m11 (device superset) - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-6437-32-bit-ARM926-Embedded-Microprocessor-SAM9M11_Datasheet.pdf - - - at91sam9x5 family (aka "The 5 series") - - at91sam9g15 - - at91sam9g25 - - at91sam9g35 - - at91sam9x25 - - at91sam9x35 - - * Datasheet (can be considered as covering the whole family) - - http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11055-32-bit-ARM926EJ-S-Microcontroller-SAM9X35_Datasheet.pdf - - - at91sam9n12 - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001517A.pdf - - - sam9x60 - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/SAM9X60-Data-Sheet-DS60001579A.pdf - - * ARM Cortex-A5 based SoCs - - sama5d3 family - - - sama5d31 - - sama5d33 - - sama5d34 - - sama5d35 - - sama5d36 (device superset) - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-11121-32-bit-Cortex-A5-Microcontroller-SAMA5D3_Datasheet_B.pdf - - * ARM Cortex-A5 + NEON based SoCs - - sama5d4 family - - - sama5d41 - - sama5d42 - - sama5d43 - - sama5d44 (device superset) - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/60001525A.pdf - - - sama5d2 family - - - sama5d21 - - sama5d22 - - sama5d23 - - sama5d24 - - sama5d26 - - sama5d27 (device superset) - - sama5d28 (device superset + environmental monitors) - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/DS60001476B.pdf - - * ARM Cortex-A7 based SoCs - - sama7g5 family - - - sama7g51 - - sama7g52 - - sama7g53 - - sama7g54 (device superset) - - * Datasheet - - Coming soon - - - lan966 family - - lan9662 - - lan9668 - - * Datasheet - - Coming soon - - * ARM Cortex-M7 MCUs - - sams70 family - - - sams70j19 - - sams70j20 - - sams70j21 - - sams70n19 - - sams70n20 - - sams70n21 - - sams70q19 - - sams70q20 - - sams70q21 - - - samv70 family - - - samv70j19 - - samv70j20 - - samv70n19 - - samv70n20 - - samv70q19 - - samv70q20 - - - samv71 family - - - samv71j19 - - samv71j20 - - samv71j21 - - samv71n19 - - samv71n20 - - samv71n21 - - samv71q19 - - samv71q20 - - samv71q21 - - * Datasheet - - http://ww1.microchip.com/downloads/en/DeviceDoc/SAM-E70-S70-V70-V71-Family-Data-Sheet-DS60001527D.pdf - - -Linux kernel information ------------------------- -Linux kernel mach directory: arch/arm/mach-at91 -MAINTAINERS entry is: "ARM/Microchip (AT91) SoC support" - - -Device Tree for AT91 SoCs and boards ------------------------------------- -All AT91 SoCs are converted to Device Tree. Since Linux 3.19, these products -must use this method to boot the Linux kernel. - -Work In Progress statement: -Device Tree files and Device Tree bindings that apply to AT91 SoCs and boards are -considered as "Unstable". To be completely clear, any at91 binding can change at -any time. So, be sure to use a Device Tree Binary and a Kernel Image generated from -the same source tree. -Please refer to the Documentation/devicetree/bindings/ABI.rst file for a -definition of a "Stable" binding/ABI. -This statement will be removed by AT91 MAINTAINERS when appropriate. - -Naming conventions and best practice: - -- SoCs Device Tree Source Include files are named after the official name of - the product (at91sam9g20.dtsi or sama5d33.dtsi for instance). -- Device Tree Source Include files (.dtsi) are used to collect common nodes that can be - shared across SoCs or boards (sama5d3.dtsi or at91sam9x5cm.dtsi for instance). - When collecting nodes for a particular peripheral or topic, the identifier have to - be placed at the end of the file name, separated with a "_" (at91sam9x5_can.dtsi - or sama5d3_gmac.dtsi for example). -- board Device Tree Source files (.dts) are prefixed by the string "at91-" so - that they can be identified easily. Note that some files are historical exceptions - to this rule (sama5d3[13456]ek.dts, usb_a9g20.dts or animeo_ip.dts for example). diff --git a/Documentation/arm/netwinder.rst b/Documentation/arm/netwinder.rst deleted file mode 100644 index 8eab66caa2ac..000000000000 --- a/Documentation/arm/netwinder.rst +++ /dev/null @@ -1,85 +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/nwfpe/index.rst b/Documentation/arm/nwfpe/index.rst deleted file mode 100644 index 3c4d2f9aa10e..000000000000 --- a/Documentation/arm/nwfpe/index.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -=================================== -NetWinder's floating point emulator -=================================== - -.. toctree:: - :maxdepth: 1 - - nwfpe - netwinder-fpe - notes - todo diff --git a/Documentation/arm/nwfpe/netwinder-fpe.rst b/Documentation/arm/nwfpe/netwinder-fpe.rst deleted file mode 100644 index cbb320960fc4..000000000000 --- a/Documentation/arm/nwfpe/netwinder-fpe.rst +++ /dev/null @@ -1,162 +0,0 @@ -============= -Current State -============= - -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/notes.rst b/Documentation/arm/nwfpe/notes.rst deleted file mode 100644 index 102e55af8439..000000000000 --- a/Documentation/arm/nwfpe/notes.rst +++ /dev/null @@ -1,32 +0,0 @@ -Notes -===== - -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/nwfpe.rst b/Documentation/arm/nwfpe/nwfpe.rst deleted file mode 100644 index 35cd90dacbff..000000000000 --- a/Documentation/arm/nwfpe/nwfpe.rst +++ /dev/null @@ -1,74 +0,0 @@ -Introduction -============ - -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/todo.rst b/Documentation/arm/nwfpe/todo.rst deleted file mode 100644 index 393f11b14540..000000000000 --- a/Documentation/arm/nwfpe/todo.rst +++ /dev/null @@ -1,72 +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/omap/dss.rst b/Documentation/arm/omap/dss.rst deleted file mode 100644 index a40c4d9c717a..000000000000 --- a/Documentation/arm/omap/dss.rst +++ /dev/null @@ -1,372 +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 standard dma allocator. You -can enable Contiguous Memory Allocator (CONFIG_CMA) to improve the dma -allocator, and if CMA is enabled, you use "cma=" kernel parameter to increase -the global memory area for CMA. - -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 ---------------------- - -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/index.rst b/Documentation/arm/omap/index.rst deleted file mode 100644 index 8b365b212e49..000000000000 --- a/Documentation/arm/omap/index.rst +++ /dev/null @@ -1,12 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -======= -TI OMAP -======= - -.. toctree:: - :maxdepth: 1 - - omap - omap_pm - dss diff --git a/Documentation/arm/omap/omap.rst b/Documentation/arm/omap/omap.rst deleted file mode 100644 index f440c0f4613f..000000000000 --- a/Documentation/arm/omap/omap.rst +++ /dev/null @@ -1,18 +0,0 @@ -============ -OMAP history -============ - -This file contains documentation for running mainline -kernel on omaps. - -====== ====================================================== -KERNEL NEW DEPENDENCIES -====== ====================================================== -v4.3+ Update is needed for custom .config files to make sure - CONFIG_REGULATOR_PBIAS is enabled for MMC1 to work - properly. - -v4.18+ Update is needed for custom .config files to make sure - CONFIG_MMC_SDHCI_OMAP is enabled for all MMC instances - to work in DRA7 and K2G based boards. -====== ====================================================== diff --git a/Documentation/arm/omap/omap_pm.rst b/Documentation/arm/omap/omap_pm.rst deleted file mode 100644 index a335e4c8ce2c..000000000000 --- a/Documentation/arm/omap/omap_pm.rst +++ /dev/null @@ -1,165 +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 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.rst b/Documentation/arm/porting.rst deleted file mode 100644 index bd21958bdb2d..000000000000 --- a/Documentation/arm/porting.rst +++ /dev/null @@ -1,137 +0,0 @@ -======= -Porting -======= - -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/pxa/mfp.rst b/Documentation/arm/pxa/mfp.rst deleted file mode 100644 index ac34e5d7ee44..000000000000 --- a/Documentation/arm/pxa/mfp.rst +++ /dev/null @@ -1,288 +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/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 "mfp-pxa25x.h" - - #include "mfp-pxa27x.h" - - #include "mfp-pxa300.h" - - #include "mfp-pxa320.h" - - #include "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/mfp-pxa3xx.h - - for PXA3xx specific MFPR register bit definitions and PXA3xx common pin - configurations - - - arch/arm/mach-pxa/mfp-pxa2xx.h - - for PXA2xx specific definitions and PXA25x/PXA27x common pin configurations - - - arch/arm/mach-pxa/mfp-pxa25x.h - arch/arm/mach-pxa/mfp-pxa27x.h - arch/arm/mach-pxa/mfp-pxa300.h - arch/arm/mach-pxa/mfp-pxa320.h - arch/arm/mach-pxa/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/sa1100/assabet.rst b/Documentation/arm/sa1100/assabet.rst deleted file mode 100644 index a761e128fb08..000000000000 --- a/Documentation/arm/sa1100/assabet.rst +++ /dev/null @@ -1,301 +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_defconfig - 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 automate 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. - - 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/cerf.rst b/Documentation/arm/sa1100/cerf.rst deleted file mode 100644 index 7fa71b609bf9..000000000000 --- a/Documentation/arm/sa1100/cerf.rst +++ /dev/null @@ -1,35 +0,0 @@ -============== -CerfBoard/Cube -============== - -*** 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/index.rst b/Documentation/arm/sa1100/index.rst deleted file mode 100644 index c9aed43280ff..000000000000 --- a/Documentation/arm/sa1100/index.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -==================== -Intel StrongARM 1100 -==================== - -.. toctree:: - :maxdepth: 1 - - assabet - cerf - lart - serial_uart diff --git a/Documentation/arm/sa1100/lart.rst b/Documentation/arm/sa1100/lart.rst deleted file mode 100644 index 94c0568d1095..000000000000 --- a/Documentation/arm/sa1100/lart.rst +++ /dev/null @@ -1,15 +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/serial_uart.rst b/Documentation/arm/sa1100/serial_uart.rst deleted file mode 100644 index ea983642b9be..000000000000 --- a/Documentation/arm/sa1100/serial_uart.rst +++ /dev/null @@ -1,51 +0,0 @@ -================== -SA1100 serial port -================== - -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/samsung/bootloader-interface.rst b/Documentation/arm/samsung/bootloader-interface.rst deleted file mode 100644 index a56f325dae78..000000000000 --- a/Documentation/arm/samsung/bootloader-interface.rst +++ /dev/null @@ -1,81 +0,0 @@ -========================================================== -Interface between kernel and boot loaders on Exynos boards -========================================================== - -Author: Krzysztof Kozlowski - -Date : 6 June 2015 - -The document tries to describe currently used interface between Linux kernel -and boot loaders on Samsung Exynos based boards. This is not a definition -of interface but rather a description of existing state, a reference -for information purpose only. - -In the document "boot loader" means any of following: U-boot, proprietary -SBOOT or any other firmware for ARMv7 and ARMv8 initializing the board before -executing kernel. - - -1. Non-Secure mode - -Address: sysram_ns_base_addr - -============= ============================================ ================== -Offset Value Purpose -============= ============================================ ================== -0x08 exynos_cpu_resume_ns, mcpm_entry_point System suspend -0x0c 0x00000bad (Magic cookie) System suspend -0x1c exynos4_secondary_startup Secondary CPU boot -0x1c + 4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot -0x20 0xfcba0d10 (Magic cookie) AFTR -0x24 exynos_cpu_resume_ns AFTR -0x28 + 4*cpu 0x8 (Magic cookie, Exynos3250) AFTR -0x28 0x0 or last value during resume (Exynos542x) System suspend -============= ============================================ ================== - - -2. Secure mode - -Address: sysram_base_addr - -============= ============================================ ================== -Offset Value Purpose -============= ============================================ ================== -0x00 exynos4_secondary_startup Secondary CPU boot -0x04 exynos4_secondary_startup (Exynos542x) Secondary CPU boot -4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot -0x20 exynos_cpu_resume (Exynos4210 r1.0) AFTR -0x24 0xfcba0d10 (Magic cookie, Exynos4210 r1.0) AFTR -============= ============================================ ================== - -Address: pmu_base_addr - -============= ============================================ ================== -Offset Value Purpose -============= ============================================ ================== -0x0800 exynos_cpu_resume AFTR, suspend -0x0800 mcpm_entry_point (Exynos542x with MCPM) AFTR, suspend -0x0804 0xfcba0d10 (Magic cookie) AFTR -0x0804 0x00000bad (Magic cookie) System suspend -0x0814 exynos4_secondary_startup (Exynos4210 r1.1) Secondary CPU boot -0x0818 0xfcba0d10 (Magic cookie, Exynos4210 r1.1) AFTR -0x081C exynos_cpu_resume (Exynos4210 r1.1) AFTR -============= ============================================ ================== - -3. Other (regardless of secure/non-secure mode) - -Address: pmu_base_addr - -============= =============================== =============================== -Offset Value Purpose -============= =============================== =============================== -0x0908 Non-zero Secondary CPU boot up indicator - on Exynos3250 and Exynos542x -============= =============================== =============================== - - -4. Glossary - -AFTR - ARM Off Top Running, a low power mode, Cortex cores and many other -modules are power gated, except the TOP modules -MCPM - Multi-Cluster Power Management diff --git a/Documentation/arm/samsung/clksrc-change-registers.awk b/Documentation/arm/samsung/clksrc-change-registers.awk deleted file mode 100755 index 7be1b8aa7cd9..000000000000 --- a/Documentation/arm/samsung/clksrc-change-registers.awk +++ /dev/null @@ -1,166 +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 length " 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 ~ /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/samsung/gpio.rst b/Documentation/arm/samsung/gpio.rst deleted file mode 100644 index 27fae0d50361..000000000000 --- a/Documentation/arm/samsung/gpio.rst +++ /dev/null @@ -1,32 +0,0 @@ -=========================== -Samsung GPIO implementation -=========================== - -Introduction ------------- - -This outlines the Samsung GPIO implementation and the architecture -specific calls provided alongside the drivers/gpio core. - - -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 architecture, 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/mach-s3c/gpio-cfg.h for more information on these functions. diff --git a/Documentation/arm/samsung/index.rst b/Documentation/arm/samsung/index.rst deleted file mode 100644 index 8142cce3d23e..000000000000 --- a/Documentation/arm/samsung/index.rst +++ /dev/null @@ -1,12 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -=========== -Samsung SoC -=========== - -.. toctree:: - :maxdepth: 1 - - gpio - bootloader-interface - overview diff --git a/Documentation/arm/samsung/overview.rst b/Documentation/arm/samsung/overview.rst deleted file mode 100644 index 8b15a190169b..000000000000 --- a/Documentation/arm/samsung/overview.rst +++ /dev/null @@ -1,76 +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: - - - S3C64XX: S3C6400 and S3C6410 - - S5PC110 / S5PV210 - - -Configuration -------------- - - A number of configurations are supplied, as there is no current way of - unifying all the SoCs into one kernel. - - 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-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. - - -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/setup.rst b/Documentation/arm/setup.rst deleted file mode 100644 index 8e12ef3fb9a7..000000000000 --- a/Documentation/arm/setup.rst +++ /dev/null @@ -1,108 +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/spear/overview.rst b/Documentation/arm/spear/overview.rst deleted file mode 100644 index 1a77f6b213b6..000000000000 --- a/Documentation/arm/spear/overview.rst +++ /dev/null @@ -1,66 +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 <vireshk@kernel.org>, (c) 2010-2012 ST Microelectronics diff --git a/Documentation/arm/sti/overview.rst b/Documentation/arm/sti/overview.rst deleted file mode 100644 index ae16aced800f..000000000000 --- a/Documentation/arm/sti/overview.rst +++ /dev/null @@ -1,32 +0,0 @@ -====================== -STi ARM Linux Overview -====================== - -Introduction ------------- - - The ST Microelectronics Multimedia and Application Processors range of - CortexA9 System-on-Chip are supported by the 'STi' platform of - ARM Linux. Currently STiH407, STiH410 and STiH418 are supported. - - -configuration -------------- - - The configuration for the STi platform is supported via the multi_v7_defconfig. - -Layout ------- - - All the files for multiple machine families (STiH407, STiH410, and STiH418) - are located in the platform code contained in arch/arm/mach-sti - - There is a generic board board-dt.c in the mach folder which support - Flattened Device Tree, which means, It works with any compatible board with - Device Trees. - - -Document Author ---------------- - - Srinivas Kandagatla <srinivas.kandagatla@st.com>, (c) 2013 ST Microelectronics diff --git a/Documentation/arm/sti/stih407-overview.rst b/Documentation/arm/sti/stih407-overview.rst deleted file mode 100644 index 027e75bc7b7c..000000000000 --- a/Documentation/arm/sti/stih407-overview.rst +++ /dev/null @@ -1,19 +0,0 @@ -================ -STiH407 Overview -================ - -Introduction ------------- - - The STiH407 is the new generation of SoC for Multi-HD, AVC set-top boxes - and server/connected client application for satellite, cable, terrestrial - and IP-STB markets. - - Features - - ARM Cortex-A9 1.5 GHz dual core CPU (28nm) - - SATA2, USB 3.0, PCIe, Gbit Ethernet - -Document Author ---------------- - - Maxime Coquelin <maxime.coquelin@st.com>, (c) 2014 ST Microelectronics diff --git a/Documentation/arm/sti/stih418-overview.rst b/Documentation/arm/sti/stih418-overview.rst deleted file mode 100644 index b563c1f4fe5a..000000000000 --- a/Documentation/arm/sti/stih418-overview.rst +++ /dev/null @@ -1,21 +0,0 @@ -================ -STiH418 Overview -================ - -Introduction ------------- - - The STiH418 is the new generation of SoC for UHDp60 set-top boxes - and server/connected client application for satellite, cable, terrestrial - and IP-STB markets. - - Features - - ARM Cortex-A9 1.5 GHz quad core CPU (28nm) - - SATA2, USB 3.0, PCIe, Gbit Ethernet - - HEVC L5.1 Main 10 - - VP9 - -Document Author ---------------- - - Maxime Coquelin <maxime.coquelin@st.com>, (c) 2015 ST Microelectronics diff --git a/Documentation/arm/stm32/overview.rst b/Documentation/arm/stm32/overview.rst deleted file mode 100644 index 85cfc8410798..000000000000 --- a/Documentation/arm/stm32/overview.rst +++ /dev/null @@ -1,34 +0,0 @@ -======================== -STM32 ARM Linux Overview -======================== - -Introduction ------------- - -The STMicroelectronics STM32 family of Cortex-A microprocessors (MPUs) and -Cortex-M microcontrollers (MCUs) are supported by the 'STM32' platform of -ARM Linux. - -Configuration -------------- - -For MCUs, use the provided default configuration: - make stm32_defconfig -For MPUs, use multi_v7 configuration: - make multi_v7_defconfig - -Layout ------- - -All the files for multiple machine families are located in the platform code -contained in arch/arm/mach-stm32 - -There is a generic board board-dt.c in the mach folder which support -Flattened Device Tree, which means, it works with any compatible board with -Device Trees. - -:Authors: - -- Maxime Coquelin <mcoquelin.stm32@gmail.com> -- Ludovic Barre <ludovic.barre@st.com> -- Gerald Baeza <gerald.baeza@st.com> diff --git a/Documentation/arm/stm32/stm32-dma-mdma-chaining.rst b/Documentation/arm/stm32/stm32-dma-mdma-chaining.rst deleted file mode 100644 index 2945e0e33104..000000000000 --- a/Documentation/arm/stm32/stm32-dma-mdma-chaining.rst +++ /dev/null @@ -1,415 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -======================= -STM32 DMA-MDMA chaining -======================= - - -Introduction ------------- - - This document describes the STM32 DMA-MDMA chaining feature. But before going - further, let's introduce the peripherals involved. - - To offload data transfers from the CPU, STM32 microprocessors (MPUs) embed - direct memory access controllers (DMA). - - STM32MP1 SoCs embed both STM32 DMA and STM32 MDMA controllers. STM32 DMA - request routing capabilities are enhanced by a DMA request multiplexer - (STM32 DMAMUX). - - **STM32 DMAMUX** - - STM32 DMAMUX routes any DMA request from a given peripheral to any STM32 DMA - controller (STM32MP1 counts two STM32 DMA controllers) channels. - - **STM32 DMA** - - STM32 DMA is mainly used to implement central data buffer storage (usually in - the system SRAM) for different peripheral. It can access external RAMs but - without the ability to generate convenient burst transfer ensuring the best - load of the AXI. - - **STM32 MDMA** - - STM32 MDMA (Master DMA) is mainly used to manage direct data transfers between - RAM data buffers without CPU intervention. It can also be used in a - hierarchical structure that uses STM32 DMA as first level data buffer - interfaces for AHB peripherals, while the STM32 MDMA acts as a second level - DMA with better performance. As a AXI/AHB master, STM32 MDMA can take control - of the AXI/AHB bus. - - -Principles ----------- - - STM32 DMA-MDMA chaining feature relies on the strengths of STM32 DMA and - STM32 MDMA controllers. - - STM32 DMA has a circular Double Buffer Mode (DBM). At each end of transaction - (when DMA data counter - DMA_SxNDTR - reaches 0), the memory pointers - (configured with DMA_SxSM0AR and DMA_SxM1AR) are swapped and the DMA data - counter is automatically reloaded. This allows the SW or the STM32 MDMA to - process one memory area while the second memory area is being filled/used by - the STM32 DMA transfer. - - With STM32 MDMA linked-list mode, a single request initiates the data array - (collection of nodes) to be transferred until the linked-list pointer for the - channel is null. The channel transfer complete of the last node is the end of - transfer, unless first and last nodes are linked to each other, in such a - case, the linked-list loops on to create a circular MDMA transfer. - - STM32 MDMA has direct connections with STM32 DMA. This enables autonomous - communication and synchronization between peripherals, thus saving CPU - resources and bus congestion. Transfer Complete signal of STM32 DMA channel - can triggers STM32 MDMA transfer. STM32 MDMA can clear the request generated - by the STM32 DMA by writing to its Interrupt Clear register (whose address is - stored in MDMA_CxMAR, and bit mask in MDMA_CxMDR). - - .. table:: STM32 MDMA interconnect table with STM32 DMA - - +--------------+----------------+-----------+------------+ - | STM32 DMAMUX | STM32 DMA | STM32 DMA | STM32 MDMA | - | channels | channels | Transfer | request | - | | | complete | | - | | | signal | | - +==============+================+===========+============+ - | Channel *0* | DMA1 channel 0 | dma1_tcf0 | *0x00* | - +--------------+----------------+-----------+------------+ - | Channel *1* | DMA1 channel 1 | dma1_tcf1 | *0x01* | - +--------------+----------------+-----------+------------+ - | Channel *2* | DMA1 channel 2 | dma1_tcf2 | *0x02* | - +--------------+----------------+-----------+------------+ - | Channel *3* | DMA1 channel 3 | dma1_tcf3 | *0x03* | - +--------------+----------------+-----------+------------+ - | Channel *4* | DMA1 channel 4 | dma1_tcf4 | *0x04* | - +--------------+----------------+-----------+------------+ - | Channel *5* | DMA1 channel 5 | dma1_tcf5 | *0x05* | - +--------------+----------------+-----------+------------+ - | Channel *6* | DMA1 channel 6 | dma1_tcf6 | *0x06* | - +--------------+----------------+-----------+------------+ - | Channel *7* | DMA1 channel 7 | dma1_tcf7 | *0x07* | - +--------------+----------------+-----------+------------+ - | Channel *8* | DMA2 channel 0 | dma2_tcf0 | *0x08* | - +--------------+----------------+-----------+------------+ - | Channel *9* | DMA2 channel 1 | dma2_tcf1 | *0x09* | - +--------------+----------------+-----------+------------+ - | Channel *10* | DMA2 channel 2 | dma2_tcf2 | *0x0A* | - +--------------+----------------+-----------+------------+ - | Channel *11* | DMA2 channel 3 | dma2_tcf3 | *0x0B* | - +--------------+----------------+-----------+------------+ - | Channel *12* | DMA2 channel 4 | dma2_tcf4 | *0x0C* | - +--------------+----------------+-----------+------------+ - | Channel *13* | DMA2 channel 5 | dma2_tcf5 | *0x0D* | - +--------------+----------------+-----------+------------+ - | Channel *14* | DMA2 channel 6 | dma2_tcf6 | *0x0E* | - +--------------+----------------+-----------+------------+ - | Channel *15* | DMA2 channel 7 | dma2_tcf7 | *0x0F* | - +--------------+----------------+-----------+------------+ - - STM32 DMA-MDMA chaining feature then uses a SRAM buffer. STM32MP1 SoCs embed - three fast access static internal RAMs of various size, used for data storage. - Due to STM32 DMA legacy (within microcontrollers), STM32 DMA performances are - bad with DDR, while they are optimal with SRAM. Hence the SRAM buffer used - between STM32 DMA and STM32 MDMA. This buffer is split in two equal periods - and STM32 DMA uses one period while STM32 MDMA uses the other period - simultaneously. - :: - - dma[1:2]-tcf[0:7] - .----------------. - ____________ ' _________ V____________ - | STM32 DMA | / __|>_ \ | STM32 MDMA | - |------------| | / \ | |------------| - | DMA_SxM0AR |<=>| | SRAM | |<=>| []-[]...[] | - | DMA_SxM1AR | | \_____/ | | | - |____________| \___<|____/ |____________| - - STM32 DMA-MDMA chaining uses (struct dma_slave_config).peripheral_config to - exchange the parameters needed to configure MDMA. These parameters are - gathered into a u32 array with three values: - - * the STM32 MDMA request (which is actually the DMAMUX channel ID), - * the address of the STM32 DMA register to clear the Transfer Complete - interrupt flag, - * the mask of the Transfer Complete interrupt flag of the STM32 DMA channel. - -Device Tree updates for STM32 DMA-MDMA chaining support -------------------------------------------------------- - - **1. Allocate a SRAM buffer** - - SRAM device tree node is defined in SoC device tree. You can refer to it in - your board device tree to define your SRAM pool. - :: - - &sram { - my_foo_device_dma_pool: dma-sram@0 { - reg = <0x0 0x1000>; - }; - }; - - Be careful of the start index, in case there are other SRAM consumers. - Define your pool size strategically: to optimise chaining, the idea is that - STM32 DMA and STM32 MDMA can work simultaneously, on each buffer of the - SRAM. - If the SRAM period is greater than the expected DMA transfer, then STM32 DMA - and STM32 MDMA will work sequentially instead of simultaneously. It is not a - functional issue but it is not optimal. - - Don't forget to refer to your SRAM pool in your device node. You need to - define a new property. - :: - - &my_foo_device { - ... - my_dma_pool = &my_foo_device_dma_pool; - }; - - Then get this SRAM pool in your foo driver and allocate your SRAM buffer. - - **2. Allocate a STM32 DMA channel and a STM32 MDMA channel** - - You need to define an extra channel in your device tree node, in addition to - the one you should already have for "classic" DMA operation. - - This new channel must be taken from STM32 MDMA channels, so, the phandle of - the DMA controller to use is the MDMA controller's one. - :: - - &my_foo_device { - [...] - my_dma_pool = &my_foo_device_dma_pool; - dmas = <&dmamux1 ...>, // STM32 DMA channel - <&mdma1 0 0x3 0x1200000a 0 0>; // + STM32 MDMA channel - }; - - Concerning STM32 MDMA bindings: - - 1. The request line number : whatever the value here, it will be overwritten - by MDMA driver with the STM32 DMAMUX channel ID passed through - (struct dma_slave_config).peripheral_config - - 2. The priority level : choose Very High (0x3) so that your channel will - take priority other the other during request arbitration - - 3. A 32bit mask specifying the DMA channel configuration : source and - destination address increment, block transfer with 128 bytes per single - transfer - - 4. The 32bit value specifying the register to be used to acknowledge the - request: it will be overwritten by MDMA driver, with the DMA channel - interrupt flag clear register address passed through - (struct dma_slave_config).peripheral_config - - 5. The 32bit mask specifying the value to be written to acknowledge the - request: it will be overwritten by MDMA driver, with the DMA channel - Transfer Complete flag passed through - (struct dma_slave_config).peripheral_config - -Driver updates for STM32 DMA-MDMA chaining support in foo driver ----------------------------------------------------------------- - - **0. (optional) Refactor the original sg_table if dmaengine_prep_slave_sg()** - - In case of dmaengine_prep_slave_sg(), the original sg_table can't be used as - is. Two new sg_tables must be created from the original one. One for - STM32 DMA transfer (where memory address targets now the SRAM buffer instead - of DDR buffer) and one for STM32 MDMA transfer (where memory address targets - the DDR buffer). - - The new sg_list items must fit SRAM period length. Here is an example for - DMA_DEV_TO_MEM: - :: - - /* - * Assuming sgl and nents, respectively the initial scatterlist and its - * length. - * Assuming sram_dma_buf and sram_period, respectively the memory - * allocated from the pool for DMA usage, and the length of the period, - * which is half of the sram_buf size. - */ - struct sg_table new_dma_sgt, new_mdma_sgt; - struct scatterlist *s, *_sgl; - dma_addr_t ddr_dma_buf; - u32 new_nents = 0, len; - int i; - - /* Count the number of entries needed */ - for_each_sg(sgl, s, nents, i) - if (sg_dma_len(s) > sram_period) - new_nents += DIV_ROUND_UP(sg_dma_len(s), sram_period); - else - new_nents++; - - /* Create sg table for STM32 DMA channel */ - ret = sg_alloc_table(&new_dma_sgt, new_nents, GFP_ATOMIC); - if (ret) - dev_err(dev, "DMA sg table alloc failed\n"); - - for_each_sg(new_dma_sgt.sgl, s, new_dma_sgt.nents, i) { - _sgl = sgl; - sg_dma_len(s) = min(sg_dma_len(_sgl), sram_period); - /* Targets the beginning = first half of the sram_buf */ - s->dma_address = sram_buf; - /* - * Targets the second half of the sram_buf - * for odd indexes of the item of the sg_list - */ - if (i & 1) - s->dma_address += sram_period; - } - - /* Create sg table for STM32 MDMA channel */ - ret = sg_alloc_table(&new_mdma_sgt, new_nents, GFP_ATOMIC); - if (ret) - dev_err(dev, "MDMA sg_table alloc failed\n"); - - _sgl = sgl; - len = sg_dma_len(sgl); - ddr_dma_buf = sg_dma_address(sgl); - for_each_sg(mdma_sgt.sgl, s, mdma_sgt.nents, i) { - size_t bytes = min_t(size_t, len, sram_period); - - sg_dma_len(s) = bytes; - sg_dma_address(s) = ddr_dma_buf; - len -= bytes; - - if (!len && sg_next(_sgl)) { - _sgl = sg_next(_sgl); - len = sg_dma_len(_sgl); - ddr_dma_buf = sg_dma_address(_sgl); - } else { - ddr_dma_buf += bytes; - } - } - - Don't forget to release these new sg_tables after getting the descriptors - with dmaengine_prep_slave_sg(). - - **1. Set controller specific parameters** - - First, use dmaengine_slave_config() with a struct dma_slave_config to - configure STM32 DMA channel. You just have to take care of DMA addresses, - the memory address (depending on the transfer direction) must point on your - SRAM buffer, and set (struct dma_slave_config).peripheral_size != 0. - - STM32 DMA driver will check (struct dma_slave_config).peripheral_size to - determine if chaining is being used or not. If it is used, then STM32 DMA - driver fills (struct dma_slave_config).peripheral_config with an array of - three u32 : the first one containing STM32 DMAMUX channel ID, the second one - the channel interrupt flag clear register address, and the third one the - channel Transfer Complete flag mask. - - Then, use dmaengine_slave_config with another struct dma_slave_config to - configure STM32 MDMA channel. Take care of DMA addresses, the device address - (depending on the transfer direction) must point on your SRAM buffer, and - the memory address must point to the buffer originally used for "classic" - DMA operation. Use the previous (struct dma_slave_config).peripheral_size - and .peripheral_config that have been updated by STM32 DMA driver, to set - (struct dma_slave_config).peripheral_size and .peripheral_config of the - struct dma_slave_config to configure STM32 MDMA channel. - :: - - struct dma_slave_config dma_conf; - struct dma_slave_config mdma_conf; - - memset(&dma_conf, 0, sizeof(dma_conf)); - [...] - config.direction = DMA_DEV_TO_MEM; - config.dst_addr = sram_dma_buf; // SRAM buffer - config.peripheral_size = 1; // peripheral_size != 0 => chaining - - dmaengine_slave_config(dma_chan, &dma_config); - - memset(&mdma_conf, 0, sizeof(mdma_conf)); - config.direction = DMA_DEV_TO_MEM; - mdma_conf.src_addr = sram_dma_buf; // SRAM buffer - mdma_conf.dst_addr = rx_dma_buf; // original memory buffer - mdma_conf.peripheral_size = dma_conf.peripheral_size; // <- dma_conf - mdma_conf.peripheral_config = dma_config.peripheral_config; // <- dma_conf - - dmaengine_slave_config(mdma_chan, &mdma_conf); - - **2. Get a descriptor for STM32 DMA channel transaction** - - In the same way you get your descriptor for your "classic" DMA operation, - you just have to replace the original sg_list (in case of - dmaengine_prep_slave_sg()) with the new sg_list using SRAM buffer, or to - replace the original buffer address, length and period (in case of - dmaengine_prep_dma_cyclic()) with the new SRAM buffer. - - **3. Get a descriptor for STM32 MDMA channel transaction** - - If you previously get descriptor (for STM32 DMA) with - - * dmaengine_prep_slave_sg(), then use dmaengine_prep_slave_sg() for - STM32 MDMA; - * dmaengine_prep_dma_cyclic(), then use dmaengine_prep_dma_cyclic() for - STM32 MDMA. - - Use the new sg_list using SRAM buffer (in case of dmaengine_prep_slave_sg()) - or, depending on the transfer direction, either the original DDR buffer (in - case of DMA_DEV_TO_MEM) or the SRAM buffer (in case of DMA_MEM_TO_DEV), the - source address being previously set with dmaengine_slave_config(). - - **4. Submit both transactions** - - Before submitting your transactions, you may need to define on which - descriptor you want a callback to be called at the end of the transfer - (dmaengine_prep_slave_sg()) or the period (dmaengine_prep_dma_cyclic()). - Depending on the direction, set the callback on the descriptor that finishes - the overal transfer: - - * DMA_DEV_TO_MEM: set the callback on the "MDMA" descriptor - * DMA_MEM_TO_DEV: set the callback on the "DMA" descriptor - - Then, submit the descriptors whatever the order, with dmaengine_tx_submit(). - - **5. Issue pending requests (and wait for callback notification)** - - As STM32 MDMA channel transfer is triggered by STM32 DMA, you must issue - STM32 MDMA channel before STM32 DMA channel. - - If any, your callback will be called to warn you about the end of the overal - transfer or the period completion. - - Don't forget to terminate both channels. STM32 DMA channel is configured in - cyclic Double-Buffer mode so it won't be disabled by HW, you need to terminate - it. STM32 MDMA channel will be stopped by HW in case of sg transfer, but not - in case of cyclic transfer. You can terminate it whatever the kind of transfer. - - **STM32 DMA-MDMA chaining DMA_MEM_TO_DEV special case** - - STM32 DMA-MDMA chaining in DMA_MEM_TO_DEV is a special case. Indeed, the - STM32 MDMA feeds the SRAM buffer with the DDR data, and the STM32 DMA reads - data from SRAM buffer. So some data (the first period) have to be copied in - SRAM buffer when the STM32 DMA starts to read. - - A trick could be pausing the STM32 DMA channel (that will raise a Transfer - Complete signal, triggering the STM32 MDMA channel), but the first data read - by the STM32 DMA could be "wrong". The proper way is to prepare the first SRAM - period with dmaengine_prep_dma_memcpy(). Then this first period should be - "removed" from the sg or the cyclic transfer. - - Due to this complexity, rather use the STM32 DMA-MDMA chaining for - DMA_DEV_TO_MEM and keep the "classic" DMA usage for DMA_MEM_TO_DEV, unless - you're not afraid. - -Resources ---------- - - Application note, datasheet and reference manual are available on ST website - (STM32MP1_). - - Dedicated focus on three application notes (AN5224_, AN4031_ & AN5001_) - dealing with STM32 DMAMUX, STM32 DMA and STM32 MDMA. - -.. _STM32MP1: https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html -.. _AN5224: https://www.st.com/resource/en/application_note/an5224-stm32-dmamux-the-dma-request-router-stmicroelectronics.pdf -.. _AN4031: https://www.st.com/resource/en/application_note/dm00046011-using-the-stm32f2-stm32f4-and-stm32f7-series-dma-controller-stmicroelectronics.pdf -.. _AN5001: https://www.st.com/resource/en/application_note/an5001-stm32cube-expansion-package-for-stm32h7-series-mdma-stmicroelectronics.pdf - -:Authors: - -- Amelie Delaunay <amelie.delaunay@foss.st.com>
\ No newline at end of file diff --git a/Documentation/arm/stm32/stm32f429-overview.rst b/Documentation/arm/stm32/stm32f429-overview.rst deleted file mode 100644 index a7ebe8ea6697..000000000000 --- a/Documentation/arm/stm32/stm32f429-overview.rst +++ /dev/null @@ -1,25 +0,0 @@ -================== -STM32F429 Overview -================== - -Introduction ------------- - -The STM32F429 is a Cortex-M4 MCU aimed at various applications. -It features: - -- ARM Cortex-M4 up to 180MHz with FPU -- 2MB internal Flash Memory -- External memory support through FMC controller (PSRAM, SDRAM, NOR, NAND) -- I2C, SPI, SAI, CAN, USB OTG, Ethernet controllers -- LCD controller & Camera interface -- Cryptographic processor - -Resources ---------- - -Datasheet and reference manual are publicly available on ST website (STM32F429_). - -.. _STM32F429: http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1577/LN1806?ecmp=stm32f429-439_pron_pr-ces2014_nov2013 - -:Authors: Maxime Coquelin <mcoquelin.stm32@gmail.com> diff --git a/Documentation/arm/stm32/stm32f746-overview.rst b/Documentation/arm/stm32/stm32f746-overview.rst deleted file mode 100644 index 78befddc7740..000000000000 --- a/Documentation/arm/stm32/stm32f746-overview.rst +++ /dev/null @@ -1,32 +0,0 @@ -================== -STM32F746 Overview -================== - -Introduction ------------- - -The STM32F746 is a Cortex-M7 MCU aimed at various applications. -It features: - -- Cortex-M7 core running up to @216MHz -- 1MB internal flash, 320KBytes internal RAM (+4KB of backup SRAM) -- FMC controller to connect SDRAM, NOR and NAND memories -- Dual mode QSPI -- SD/MMC/SDIO support -- Ethernet controller -- USB OTFG FS & HS controllers -- I2C, SPI, CAN busses support -- Several 16 & 32 bits general purpose timers -- Serial Audio interface -- LCD controller -- HDMI-CEC -- SPDIFRX - -Resources ---------- - -Datasheet and reference manual are publicly available on ST website (STM32F746_). - -.. _STM32F746: http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f7-series/stm32f7x6/stm32f746ng.html - -:Authors: Alexandre Torgue <alexandre.torgue@st.com> diff --git a/Documentation/arm/stm32/stm32f769-overview.rst b/Documentation/arm/stm32/stm32f769-overview.rst deleted file mode 100644 index e482980ddf21..000000000000 --- a/Documentation/arm/stm32/stm32f769-overview.rst +++ /dev/null @@ -1,34 +0,0 @@ -================== -STM32F769 Overview -================== - -Introduction ------------- - -The STM32F769 is a Cortex-M7 MCU aimed at various applications. -It features: - -- Cortex-M7 core running up to @216MHz -- 2MB internal flash, 512KBytes internal RAM (+4KB of backup SRAM) -- FMC controller to connect SDRAM, NOR and NAND memories -- Dual mode QSPI -- SD/MMC/SDIO support*2 -- Ethernet controller -- USB OTFG FS & HS controllers -- I2C*4, SPI*6, CAN*3 busses support -- Several 16 & 32 bits general purpose timers -- Serial Audio interface*2 -- LCD controller -- HDMI-CEC -- DSI -- SPDIFRX -- MDIO salave interface - -Resources ---------- - -Datasheet and reference manual are publicly available on ST website (STM32F769_). - -.. _STM32F769: http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32-high-performance-mcus/stm32f7-series/stm32f7x9/stm32f769ni.html - -:Authors: Alexandre Torgue <alexandre.torgue@st.com> diff --git a/Documentation/arm/stm32/stm32h743-overview.rst b/Documentation/arm/stm32/stm32h743-overview.rst deleted file mode 100644 index 4e15f1a42730..000000000000 --- a/Documentation/arm/stm32/stm32h743-overview.rst +++ /dev/null @@ -1,33 +0,0 @@ -================== -STM32H743 Overview -================== - -Introduction ------------- - -The STM32H743 is a Cortex-M7 MCU aimed at various applications. -It features: - -- Cortex-M7 core running up to @400MHz -- 2MB internal flash, 1MBytes internal RAM -- FMC controller to connect SDRAM, NOR and NAND memories -- Dual mode QSPI -- SD/MMC/SDIO support -- Ethernet controller -- USB OTFG FS & HS controllers -- I2C, SPI, CAN busses support -- Several 16 & 32 bits general purpose timers -- Serial Audio interface -- LCD controller -- HDMI-CEC -- SPDIFRX -- DFSDM - -Resources ---------- - -Datasheet and reference manual are publicly available on ST website (STM32H743_). - -.. _STM32H743: http://www.st.com/en/microcontrollers/stm32h7x3.html?querycriteria=productId=LN2033 - -:Authors: Alexandre Torgue <alexandre.torgue@st.com> diff --git a/Documentation/arm/stm32/stm32h750-overview.rst b/Documentation/arm/stm32/stm32h750-overview.rst deleted file mode 100644 index 0e51235c9547..000000000000 --- a/Documentation/arm/stm32/stm32h750-overview.rst +++ /dev/null @@ -1,34 +0,0 @@ -================== -STM32H750 Overview -================== - -Introduction ------------- - -The STM32H750 is a Cortex-M7 MCU aimed at various applications. -It features: - -- Cortex-M7 core running up to @480MHz -- 128K internal flash, 1MBytes internal RAM -- FMC controller to connect SDRAM, NOR and NAND memories -- Dual mode QSPI -- SD/MMC/SDIO support -- Ethernet controller -- USB OTFG FS & HS controllers -- I2C, SPI, CAN busses support -- Several 16 & 32 bits general purpose timers -- Serial Audio interface -- LCD controller -- HDMI-CEC -- SPDIFRX -- DFSDM - -Resources ---------- - -Datasheet and reference manual are publicly available on ST website (STM32H750_). - -.. _STM32H750: https://www.st.com/en/microcontrollers-microprocessors/stm32h750-value-line.html - -:Authors: Dillon Min <dillon.minfei@gmail.com> - diff --git a/Documentation/arm/stm32/stm32mp13-overview.rst b/Documentation/arm/stm32/stm32mp13-overview.rst deleted file mode 100644 index 3bb9492dad49..000000000000 --- a/Documentation/arm/stm32/stm32mp13-overview.rst +++ /dev/null @@ -1,37 +0,0 @@ -=================== -STM32MP13 Overview -=================== - -Introduction ------------- - -The STM32MP131/STM32MP133/STM32MP135 are Cortex-A MPU aimed at various applications. -They feature: - -- One Cortex-A7 application core -- Standard memories interface support -- Standard connectivity, widely inherited from the STM32 MCU family -- Comprehensive security support - -More details: - -- Cortex-A7 core running up to @900MHz -- FMC controller to connect SDRAM, NOR and NAND memories -- QSPI -- SD/MMC/SDIO support -- 2*Ethernet controller -- CAN -- ADC/DAC -- USB EHCI/OHCI controllers -- USB OTG -- I2C, SPI, CAN busses support -- Several general purpose timers -- Serial Audio interface -- LCD controller -- DCMIPP -- SPDIFRX -- DFSDM - -:Authors: - -- Alexandre Torgue <alexandre.torgue@foss.st.com> diff --git a/Documentation/arm/stm32/stm32mp151-overview.rst b/Documentation/arm/stm32/stm32mp151-overview.rst deleted file mode 100644 index f42a2ac309c0..000000000000 --- a/Documentation/arm/stm32/stm32mp151-overview.rst +++ /dev/null @@ -1,36 +0,0 @@ -=================== -STM32MP151 Overview -=================== - -Introduction ------------- - -The STM32MP151 is a Cortex-A MPU aimed at various applications. -It features: - -- Single Cortex-A7 application core -- Standard memories interface support -- Standard connectivity, widely inherited from the STM32 MCU family -- Comprehensive security support - -More details: - -- Cortex-A7 core running up to @800MHz -- FMC controller to connect SDRAM, NOR and NAND memories -- QSPI -- SD/MMC/SDIO support -- Ethernet controller -- ADC/DAC -- USB EHCI/OHCI controllers -- USB OTG -- I2C, SPI busses support -- Several general purpose timers -- Serial Audio interface -- LCD-TFT controller -- DCMIPP -- SPDIFRX -- DFSDM - -:Authors: - -- Roan van Dijk <roan@protonic.nl> diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arm/stm32/stm32mp157-overview.rst deleted file mode 100644 index f62fdc8e7d8d..000000000000 --- a/Documentation/arm/stm32/stm32mp157-overview.rst +++ /dev/null @@ -1,20 +0,0 @@ -=================== -STM32MP157 Overview -=================== - -Introduction ------------- - -The STM32MP157 is a Cortex-A MPU aimed at various applications. -It features: - -- Dual core Cortex-A7 application core -- 2D/3D image composition with GPU -- Standard memories interface support -- Standard connectivity, widely inherited from the STM32 MCU family -- Comprehensive security support - -:Authors: - -- Ludovic Barre <ludovic.barre@st.com> -- Gerald Baeza <gerald.baeza@st.com> diff --git a/Documentation/arm/sunxi.rst b/Documentation/arm/sunxi.rst deleted file mode 100644 index b85d1e2f2d47..000000000000 --- a/Documentation/arm/sunxi.rst +++ /dev/null @@ -1,170 +0,0 @@ -================== -ARM Allwinner SoCs -================== - -This document lists all the ARM Allwinner SoCs that are currently -supported in mainline by the Linux kernel. This document will also -provide links to documentation and/or datasheet for these SoCs. - -SunXi family ------------- - Linux kernel mach directory: arch/arm/mach-sunxi - - Flavors: - - * ARM926 based SoCs - - Allwinner F20 (sun3i) - - * Not Supported - - * ARM Cortex-A8 based SoCs - - Allwinner A10 (sun4i) - - * Datasheet - - http://dl.linux-sunxi.org/A10/A10%20Datasheet%20-%20v1.21%20%282012-04-06%29.pdf - * User Manual - - http://dl.linux-sunxi.org/A10/A10%20User%20Manual%20-%20v1.20%20%282012-04-09%2c%20DECRYPTED%29.pdf - - - Allwinner A10s (sun5i) - - * Datasheet - - http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf - - - Allwinner A13 / R8 (sun5i) - - * Datasheet - - http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf - * User Manual - - http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20-%20v1.2%20%282013-01-08%29.pdf - - - Next Thing Co GR8 (sun5i) - - * Single ARM Cortex-A7 based SoCs - - Allwinner V3s (sun8i) - - * Datasheet - - http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf - - * Dual ARM Cortex-A7 based SoCs - - Allwinner A20 (sun7i) - - * User Manual - - http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf - - - Allwinner A23 (sun8i) - - * Datasheet - - http://dl.linux-sunxi.org/A23/A23%20Datasheet%20V1.0%2020130830.pdf - - * User Manual - - http://dl.linux-sunxi.org/A23/A23%20User%20Manual%20V1.0%2020130830.pdf - - * Quad ARM Cortex-A7 based SoCs - - Allwinner A31 (sun6i) - - * Datasheet - - http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20datasheet%20V1.3%2020131106.pdf - - * User Manual - - http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20user%20manual%20V1.1%2020130630.pdf - - - Allwinner A31s (sun6i) - - * Datasheet - - http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20datasheet%20V1.3%2020131106.pdf - - * User Manual - - http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20User%20Manual%20%20V1.0%2020130322.pdf - - - Allwinner A33 (sun8i) - - * Datasheet - - http://dl.linux-sunxi.org/A33/A33%20Datasheet%20release%201.1.pdf - - * User Manual - - http://dl.linux-sunxi.org/A33/A33%20user%20manual%20release%201.1.pdf - - - Allwinner H2+ (sun8i) - - * No document available now, but is known to be working properly with - H3 drivers and memory map. - - - Allwinner H3 (sun8i) - - * Datasheet - - https://linux-sunxi.org/images/4/4b/Allwinner_H3_Datasheet_V1.2.pdf - - - Allwinner R40 (sun8i) - - * Datasheet - - https://github.com/tinalinux/docs/raw/r40-v1.y/R40_Datasheet_V1.0.pdf - - * User Manual - - https://github.com/tinalinux/docs/raw/r40-v1.y/Allwinner_R40_User_Manual_V1.0.pdf - - * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs - - Allwinner A80 - - * Datasheet - - http://dl.linux-sunxi.org/A80/A80_Datasheet_Revision_1.0_0404.pdf - - * Octa ARM Cortex-A7 based SoCs - - Allwinner A83T - - * Datasheet - - https://github.com/allwinner-zh/documents/raw/master/A83T/A83T_Datasheet_v1.3_20150510.pdf - - * User Manual - - https://github.com/allwinner-zh/documents/raw/master/A83T/A83T_User_Manual_v1.5.1_20150513.pdf - - * Quad ARM Cortex-A53 based SoCs - - Allwinner A64 - - * Datasheet - - http://dl.linux-sunxi.org/A64/A64_Datasheet_V1.1.pdf - - * User Manual - - http://dl.linux-sunxi.org/A64/Allwinner%20A64%20User%20Manual%20v1.0.pdf - - - Allwinner H6 - - * Datasheet - - https://linux-sunxi.org/images/5/5c/Allwinner_H6_V200_Datasheet_V1.1.pdf - - * User Manual - - https://linux-sunxi.org/images/4/46/Allwinner_H6_V200_User_Manual_V1.1.pdf - - - Allwinner H616 - - * Datasheet - - https://linux-sunxi.org/images/b/b9/H616_Datasheet_V1.0_cleaned.pdf - - * User Manual - - https://linux-sunxi.org/images/2/24/H616_User_Manual_V1.0_cleaned.pdf diff --git a/Documentation/arm/sunxi/clocks.rst b/Documentation/arm/sunxi/clocks.rst deleted file mode 100644 index 23bd03f3e21f..000000000000 --- a/Documentation/arm/sunxi/clocks.rst +++ /dev/null @@ -1,57 +0,0 @@ -======================================================= -Frequently asked questions about the sunxi clock system -======================================================= - -This document contains useful bits of information that people tend to ask -about the sunxi clock system, as well as accompanying ASCII art when adequate. - -Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the - system? - -A: The 24MHz oscillator allows gating to save power. Indeed, if gated - carelessly the system would stop functioning, but with the right - steps, one can gate it and keep the system running. Consider this - simplified suspend example: - - While the system is operational, you would see something like:: - - 24MHz 32kHz - | - PLL1 - \ - \_ CPU Mux - | - [CPU] - - When you are about to suspend, you switch the CPU Mux to the 32kHz - oscillator:: - - 24Mhz 32kHz - | | - PLL1 | - / - CPU Mux _/ - | - [CPU] - - Finally you can gate the main oscillator:: - - 32kHz - | - | - / - CPU Mux _/ - | - [CPU] - -Q: Were can I learn more about the sunxi clocks? - -A: The linux-sunxi wiki contains a page documenting the clock registers, - you can find it at - - http://linux-sunxi.org/A10/CCM - - The authoritative source for information at this time is the ccmu driver - released by Allwinner, you can find it at - - https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.0/arch/arm/mach-sun4i/clock/ccmu diff --git a/Documentation/arm/swp_emulation.rst b/Documentation/arm/swp_emulation.rst deleted file mode 100644 index 6a608a9c3715..000000000000 --- a/Documentation/arm/swp_emulation.rst +++ /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.rst b/Documentation/arm/tcm.rst deleted file mode 100644 index 1dc6c39220f9..000000000000 --- a/Documentation/arm/tcm.rst +++ /dev/null @@ -1,161 +0,0 @@ -================================================== -ARM TCM (Tightly-Coupled Memory) handling in Linux -================================================== - -Written by Linus Walleij <linus.walleij@stericsson.com> - -Some ARM SoCs 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 CPUs 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 is 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); - } - } diff --git a/Documentation/arm/uefi.rst b/Documentation/arm/uefi.rst deleted file mode 100644 index baebe688a006..000000000000 --- a/Documentation/arm/uefi.rst +++ /dev/null @@ -1,70 +0,0 @@ -================================================ -The Unified Extensible Firmware Interface (UEFI) -================================================ - -UEFI, the Unified Extensible Firmware Interface, is a specification -governing the behaviours of compatible firmware interfaces. It is -maintained by the UEFI Forum - http://www.uefi.org/. - -UEFI is an evolution of its predecessor 'EFI', so the terms EFI and -UEFI are used somewhat interchangeably in this document and associated -source code. As a rule, anything new uses 'UEFI', whereas 'EFI' refers -to legacy code or specifications. - -UEFI support in Linux -===================== -Booting on a platform with firmware compliant with the UEFI specification -makes it possible for the kernel to support additional features: - -- UEFI Runtime Services -- Retrieving various configuration information through the standardised - interface of UEFI configuration tables. (ACPI, SMBIOS, ...) - -For actually enabling [U]EFI support, enable: - -- CONFIG_EFI=y -- CONFIG_EFIVAR_FS=y or m - -The implementation depends on receiving information about the UEFI environment -in a Flattened Device Tree (FDT) - so is only available with CONFIG_OF. - -UEFI stub -========= -The "stub" is a feature that extends the Image/zImage into a valid UEFI -PE/COFF executable, including a loader application that makes it possible to -load the kernel directly from the UEFI shell, boot menu, or one of the -lightweight bootloaders like Gummiboot or rEFInd. - -The kernel image built with stub support remains a valid kernel image for -booting in non-UEFI environments. - -UEFI kernel support on ARM -========================== -UEFI kernel support on the ARM architectures (arm and arm64) is only available -when boot is performed through the stub. - -When booting in UEFI mode, the stub deletes any memory nodes from a provided DT. -Instead, the kernel reads the UEFI memory map. - -The stub populates the FDT /chosen node with (and the kernel scans for) the -following parameters: - -========================== ====== =========================================== -Name Size Description -========================== ====== =========================================== -linux,uefi-system-table 64-bit Physical address of the UEFI System Table. - -linux,uefi-mmap-start 64-bit Physical address of the UEFI memory map, - populated by the UEFI GetMemoryMap() call. - -linux,uefi-mmap-size 32-bit Size in bytes of the UEFI memory map - pointed to in previous entry. - -linux,uefi-mmap-desc-size 32-bit Size in bytes of each entry in the UEFI - memory map. - -linux,uefi-mmap-desc-ver 32-bit Version of the mmap descriptor format. - -kaslr-seed 64-bit Entropy used to randomize the kernel image - base address location. -========================== ====== =========================================== diff --git a/Documentation/arm/vfp/release-notes.rst b/Documentation/arm/vfp/release-notes.rst deleted file mode 100644 index c6b04937cee3..000000000000 --- a/Documentation/arm/vfp/release-notes.rst +++ /dev/null @@ -1,57 +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/vlocks.rst b/Documentation/arm/vlocks.rst deleted file mode 100644 index a40a1742110b..000000000000 --- a/Documentation/arm/vlocks.rst +++ /dev/null @@ -1,212 +0,0 @@ -====================================== -vlocks for Bare-Metal Mutual Exclusion -====================================== - -Voting Locks, or "vlocks" provide a simple low-level mutual exclusion -mechanism, with reasonable but minimal requirements on the memory -system. - -These are intended to be used to coordinate critical activity among CPUs -which are otherwise non-coherent, in situations where the hardware -provides no other mechanism to support this and ordinary spinlocks -cannot be used. - - -vlocks make use of the atomicity provided by the memory system for -writes to a single memory location. To arbitrate, every CPU "votes for -itself", by storing a unique number to a common memory location. The -final value seen in that memory location when all the votes have been -cast identifies the winner. - -In order to make sure that the election produces an unambiguous result -in finite time, a CPU will only enter the election in the first place if -no winner has been chosen and the election does not appear to have -started yet. - - -Algorithm ---------- - -The easiest way to explain the vlocks algorithm is with some pseudo-code:: - - - int currently_voting[NR_CPUS] = { 0, }; - int last_vote = -1; /* no votes yet */ - - bool vlock_trylock(int this_cpu) - { - /* signal our desire to vote */ - currently_voting[this_cpu] = 1; - if (last_vote != -1) { - /* someone already volunteered himself */ - currently_voting[this_cpu] = 0; - return false; /* not ourself */ - } - - /* let's suggest ourself */ - last_vote = this_cpu; - currently_voting[this_cpu] = 0; - - /* then wait until everyone else is done voting */ - for_each_cpu(i) { - while (currently_voting[i] != 0) - /* wait */; - } - - /* result */ - if (last_vote == this_cpu) - return true; /* we won */ - return false; - } - - bool vlock_unlock(void) - { - last_vote = -1; - } - - -The currently_voting[] array provides a way for the CPUs to determine -whether an election is in progress, and plays a role analogous to the -"entering" array in Lamport's bakery algorithm [1]. - -However, once the election has started, the underlying memory system -atomicity is used to pick the winner. This avoids the need for a static -priority rule to act as a tie-breaker, or any counters which could -overflow. - -As long as the last_vote variable is globally visible to all CPUs, it -will contain only one value that won't change once every CPU has cleared -its currently_voting flag. - - -Features and limitations ------------------------- - - * vlocks are not intended to be fair. In the contended case, it is the - _last_ CPU which attempts to get the lock which will be most likely - to win. - - vlocks are therefore best suited to situations where it is necessary - to pick a unique winner, but it does not matter which CPU actually - wins. - - * Like other similar mechanisms, vlocks will not scale well to a large - number of CPUs. - - vlocks can be cascaded in a voting hierarchy to permit better scaling - if necessary, as in the following hypothetical example for 4096 CPUs:: - - /* first level: local election */ - my_town = towns[(this_cpu >> 4) & 0xf]; - I_won = vlock_trylock(my_town, this_cpu & 0xf); - if (I_won) { - /* we won the town election, let's go for the state */ - my_state = states[(this_cpu >> 8) & 0xf]; - I_won = vlock_lock(my_state, this_cpu & 0xf)); - if (I_won) { - /* and so on */ - I_won = vlock_lock(the_whole_country, this_cpu & 0xf]; - if (I_won) { - /* ... */ - } - vlock_unlock(the_whole_country); - } - vlock_unlock(my_state); - } - vlock_unlock(my_town); - - -ARM implementation ------------------- - -The current ARM implementation [2] contains some optimisations beyond -the basic algorithm: - - * By packing the members of the currently_voting array close together, - we can read the whole array in one transaction (providing the number - of CPUs potentially contending the lock is small enough). This - reduces the number of round-trips required to external memory. - - In the ARM implementation, this means that we can use a single load - and comparison:: - - LDR Rt, [Rn] - CMP Rt, #0 - - ...in place of code equivalent to:: - - LDRB Rt, [Rn] - CMP Rt, #0 - LDRBEQ Rt, [Rn, #1] - CMPEQ Rt, #0 - LDRBEQ Rt, [Rn, #2] - CMPEQ Rt, #0 - LDRBEQ Rt, [Rn, #3] - CMPEQ Rt, #0 - - This cuts down on the fast-path latency, as well as potentially - reducing bus contention in contended cases. - - The optimisation relies on the fact that the ARM memory system - guarantees coherency between overlapping memory accesses of - different sizes, similarly to many other architectures. Note that - we do not care which element of currently_voting appears in which - bits of Rt, so there is no need to worry about endianness in this - optimisation. - - If there are too many CPUs to read the currently_voting array in - one transaction then multiple transations are still required. The - implementation uses a simple loop of word-sized loads for this - case. The number of transactions is still fewer than would be - required if bytes were loaded individually. - - - In principle, we could aggregate further by using LDRD or LDM, but - to keep the code simple this was not attempted in the initial - implementation. - - - * vlocks are currently only used to coordinate between CPUs which are - unable to enable their caches yet. This means that the - implementation removes many of the barriers which would be required - when executing the algorithm in cached memory. - - packing of the currently_voting array does not work with cached - memory unless all CPUs contending the lock are cache-coherent, due - to cache writebacks from one CPU clobbering values written by other - CPUs. (Though if all the CPUs are cache-coherent, you should be - probably be using proper spinlocks instead anyway). - - - * The "no votes yet" value used for the last_vote variable is 0 (not - -1 as in the pseudocode). This allows statically-allocated vlocks - to be implicitly initialised to an unlocked state simply by putting - them in .bss. - - An offset is added to each CPU's ID for the purpose of setting this - variable, so that no CPU uses the value 0 for its ID. - - -Colophon --------- - -Originally created and documented by Dave Martin for Linaro Limited, for -use in ARM-based big.LITTLE platforms, with review and input gratefully -received from Nicolas Pitre and Achin Gupta. Thanks to Nicolas for -grabbing most of this text out of the relevant mail thread and writing -up the pseudocode. - -Copyright (C) 2012-2013 Linaro Limited -Distributed under the terms of Version 2 of the GNU General Public -License, as defined in linux/COPYING. - - -References ----------- - -[1] Lamport, L. "A New Solution of Dijkstra's Concurrent Programming - Problem", Communications of the ACM 17, 8 (August 1974), 453-455. - - https://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm - -[2] linux/arch/arm/common/vlock.S, www.kernel.org. |