diff --git a/Makefile b/Makefile
index a650cdc..500b0fc 100644
--- a/Makefile
+++ b/Makefile
@@ -56,7 +56,7 @@
 BASE_COMMIT			:= origin/master
 # NS timer register save and restore
 NS_TIMER_SWITCH			:= 0
-# By default, Bl1 acts as the reset handler, not BL31
+# By default, BL1 acts as the reset handler, not BL31
 RESET_TO_BL31			:= 0
 # Include FP registers in cpu context
 CTX_INCLUDE_FPREGS		:= 0
@@ -295,7 +295,7 @@
 endif
 
 # Include the CPU specific operations makefile. By default all CPU errata
-# workarounds and CPU specifc optimisations are disabled. This can be
+# workarounds and CPU specific optimisations are disabled. This can be
 # overridden by the platform.
 include lib/cpus/cpu-ops.mk
 
@@ -309,7 +309,7 @@
         CFLAGS		+= 	-pedantic
 endif
 
-# Using the ARM Trusted Firmware BL2 implies that a BL33 image also need to be
+# Using the ARM Trusted Firmware BL2 implies that a BL33 image also needs to be
 # supplied for the FIP and Certificate generation tools. This flag can be
 # overridden by the platform.
 ifdef BL2_SOURCES
diff --git a/bl31/aarch64/crash_reporting.S b/bl31/aarch64/crash_reporting.S
index 7edbbf2..1d1e60d 100644
--- a/bl31/aarch64/crash_reporting.S
+++ b/bl31/aarch64/crash_reporting.S
@@ -359,7 +359,7 @@
 report_unhandled_interrupt:
 	b	crash_panic
 endfunc report_unhandled_exception
-#endif	/* CRASH_REPORING */
+#endif	/* CRASH_REPORTING */
 
 
 func crash_panic
diff --git a/bl31/bl31.mk b/bl31/bl31.mk
index 8951159..0f14bfa 100644
--- a/bl31/bl31.mk
+++ b/bl31/bl31.mk
@@ -61,7 +61,7 @@
 
 BL31_LINKERFILE		:=	bl31/bl31.ld.S
 
-# Flag used to inidicate if Crash reporting via console should be included
+# Flag used to indicate if Crash reporting via console should be included
 # in BL31. This defaults to being present in DEBUG builds only
 ifndef CRASH_REPORTING
 CRASH_REPORTING		:=	$(DEBUG)
diff --git a/bl31/runtime_svc.c b/bl31/runtime_svc.c
index fd64c82..5b7a21c 100644
--- a/bl31/runtime_svc.c
+++ b/bl31/runtime_svc.c
@@ -110,7 +110,7 @@
 		}
 
 		/*
-		 * The runtime service may have seperate rt_svc_desc_t
+		 * The runtime service may have separate rt_svc_desc_t
 		 * for its fast smc and standard smc. Since the service itself
 		 * need to be initialized only once, only one of them will have
 		 * an initialisation routine defined. Call the initialisation
diff --git a/common/aarch64/context.S b/common/aarch64/context.S
index 3d13a80..0baa9b2 100644
--- a/common/aarch64/context.S
+++ b/common/aarch64/context.S
@@ -303,7 +303,7 @@
 
 	/*
 	 * No explict ISB required here as ERET to
-	 * swtich to secure EL1 or non-secure world
+	 * switch to secure EL1 or non-secure world
 	 * covers it
 	 */
 
diff --git a/contributing.md b/contributing.md
index 6b24fb5..6bf3900 100644
--- a/contributing.md
+++ b/contributing.md
@@ -8,7 +8,8 @@
 Individual CLA. Companies that want to contribute must sign and return a
 Corporate CLA if their employees' intellectual property has been assigned to
 the employer. Copies of the CLAs are available from the [contributing page] of
-the ARM website.
+the ARM website. Please wait for ARM to confirm acceptance of your CLA before
+making contributions.
 
 For this project, ARM also requires the GitHub account name(s) associated with
 each individual contributor or the designated employees of corporate
@@ -76,7 +77,7 @@
 Submitting Changes
 ------------------
 
-*   Ensure we have your signed CLA.
+*   Ensure ARM has your signed CLA and has confirmed acceptance of it.
 *   Push your local changes to your fork of the repository.
 *   Submit a [pull request] to the [arm-trusted-firmware] `integration` branch.
     *   The changes in the [pull request] will then undergo further review and
diff --git a/docs/firmware-design.md b/docs/firmware-design.md
index c32f0bd..5b6923a 100644
--- a/docs/firmware-design.md
+++ b/docs/firmware-design.md
@@ -99,8 +99,8 @@
 
 Whenever a CPU is released from reset, BL1 needs to distinguish between a warm
 boot and a cold boot. This is done using platform-specific mechanisms (see the
-`platform_get_entrypoint()` function in the [Porting Guide]). In the case of a
-warm boot, a CPU is expected to continue execution from a seperate
+`plat_get_my_entrypoint()` function in the [Porting Guide]). In the case of a
+warm boot, a CPU is expected to continue execution from a separate
 entrypoint. In the case of a cold boot, the secondary CPUs are placed in a safe
 platform-specific state (see the `plat_secondary_cold_boot_setup()` function in
 the [Porting Guide]) while the primary CPU executes the remaining cold boot path
@@ -217,7 +217,7 @@
     there is not enough free trusted SRAM the following error message is
     printed:
 
-        "Failed to load boot loader stage 2 (BL2) firmware."
+        "Failed to load BL2 firmware."
 
     If the load is successful, BL1 updates the limits of the remaining free
     trusted SRAM. It also populates information about the amount of trusted
@@ -228,7 +228,7 @@
 2.  BL1 prints the following string from the primary CPU to indicate successful
     execution of the BL1 stage:
 
-        "Booting trusted firmware boot loader stage 1"
+        "Booting Trusted Firmware"
 
 3.  BL1 passes control to the BL2 image at Secure EL1, starting from its load
     address.
@@ -712,7 +712,7 @@
 | PSCI v1.0 API         |Supported| Comments                                  |
 |:----------------------|:--------|:------------------------------------------|
 |`PSCI_VERSION`         | Yes     | The version returned is 1.0               |
-|`CPU_SUSPEND`          | Yes*    | The original `power_state` format is used |
+|`CPU_SUSPEND`          | Yes*    |                                           |
 |`CPU_OFF`              | Yes*    |                                           |
 |`CPU_ON`               | Yes*    |                                           |
 |`AFFINITY_INFO`        | Yes     |                                           |
@@ -796,7 +796,7 @@
 initialization of the SPD service. The BL32 initialization function has this
 prototype:
 
-    int32_t init();
+    int32_t init(void);
 
 and is registered using the `bl31_register_bl32_init()` function.
 
@@ -806,7 +806,7 @@
 1.  In the BL32 setup function, use `bl31_set_next_image_type()` to
     request that the exit from `bl31_main()` is to the BL32 entrypoint in
     Secure-EL1. BL31 will exit to BL32 using the asynchronous method by
-    calling bl31_prepare_next_image_entry() and el3_exit().
+    calling `bl31_prepare_next_image_entry()` and `el3_exit()`.
 
     When the BL32 has completed initialization at Secure-EL1, it returns to
     BL31 by issuing an SMC, using a Function ID allocated to the SPD. On
@@ -816,7 +816,7 @@
     the normal world firmware BL33. On return from the handler the framework
     will exit to EL2 and run BL33.
 
-2.  The BL32 setup function registers a initialization function using
+2.  The BL32 setup function registers an initialization function using
     `bl31_register_bl32_init()` which provides a SPD-defined mechanism to
     invoke a 'world-switch synchronous call' to Secure-EL1 to run the BL32
     entrypoint.
@@ -1501,7 +1501,7 @@
 because it can be accessed by multple CPUs, either with caches enabled or
 disabled.
 
-typedef struct non_cpu_pwr_domain_node {
+    typedef struct non_cpu_pwr_domain_node {
         /*
          * Index of the first CPU power domain node level 0 which has this node
          * as its parent.
@@ -1527,7 +1527,7 @@
 
         /* For indexing the psci_lock array*/
         unsigned char lock_index;
-} non_cpu_pd_node_t;
+    } non_cpu_pd_node_t;
 
 In order to move this data structure to normal memory, the use of each of its
 fields must be analyzed. Fields like `cpu_start_idx`, `ncpus`, `parent_node`
@@ -1659,7 +1659,7 @@
 *   Multiple cache line reads for each lock operation, since the bakery locks
     for each CPU are distributed across different cache lines.
 
-The implementation has been optimized to mimimize this additional overhead.
+The implementation has been optimized to minimize this additional overhead.
 Measurements indicate that when bakery locks are allocated in Normal memory, the
 minimum latency of acquiring a lock is on an average 3-4 micro seconds whereas
 in Device memory the same is 2 micro seconds. The measurements were done on the
diff --git a/docs/interrupt-framework-design.md b/docs/interrupt-framework-design.md
index 5f7b39d..060bbf2 100644
--- a/docs/interrupt-framework-design.md
+++ b/docs/interrupt-framework-design.md
@@ -359,7 +359,7 @@
 
 Once the handler routine completes, execution will return to either the secure
 or non-secure state. The handler routine should return a pointer to
-`cpu_context` structure of the current CPU for the the target security state. It
+`cpu_context` structure of the current CPU for the target security state. It
 should treat all error conditions as critical errors and take appropriate action
 within its implementation e.g. use assertion failures.
 
diff --git a/docs/porting-guide.md b/docs/porting-guide.md
index 57e167b..4047d62 100644
--- a/docs/porting-guide.md
+++ b/docs/porting-guide.md
@@ -430,8 +430,8 @@
 If the platform needs to allocate data within the per-cpu data framework in
 BL31, it should define the following macro. Currently this is only required if
 the platform decides not to use the coherent memory section by undefining the
-USE_COHERENT_MEM build flag. In this case, the framework allocates the required
-memory within the the per-cpu data to minimize wastage.
+`USE_COHERENT_MEM` build flag. In this case, the framework allocates the
+required memory within the the per-cpu data to minimize wastage.
 
 *   **#define : PLAT_PCPU_DATA_SIZE**
 
@@ -477,7 +477,7 @@
 
 BL1 by default implements the reset vector where execution starts from a cold
 or warm boot. BL31 can be optionally set as a reset vector using the
-RESET_TO_BL31 make variable.
+`RESET_TO_BL31` make variable.
 
 For each CPU, the reset vector code is responsible for the following tasks:
 
@@ -1437,7 +1437,7 @@
 CPUs which share some state on which power management operations can be
 performed as specified by [PSCI]. Each CPU in the system is assigned a cpu
 index which is a unique number between `0` and `PLATFORM_CORE_COUNT - 1`.
-The _power domains_ are arranged in a hierarchial tree structure and
+The _power domains_ are arranged in a hierarchical tree structure and
 each _power domain_ can be identified in a system by the cpu index of any CPU
 that is part of that domain and a _power domain level_. A processing element
 (for example, a CPU) is at level 0. If the _power domain_ node above a CPU is
@@ -1725,7 +1725,7 @@
     Return   : uint32_t
 
 This API returns the id of the highest priority pending interrupt at the
-platform IC. INTR_ID_UNAVAILABLE is returned when there is no interrupt
+platform IC. `INTR_ID_UNAVAILABLE` is returned when there is no interrupt
 pending.
 
 In the case of ARM standard platforms using GICv2, the _Highest Priority
diff --git a/docs/rt-svc-writers-guide.md b/docs/rt-svc-writers-guide.md
index e9d489c..40cee14 100644
--- a/docs/rt-svc-writers-guide.md
+++ b/docs/rt-svc-writers-guide.md
@@ -127,7 +127,7 @@
         typedef uint64_t (*rt_svc_handle)(uint32_t smc_fid,
                                           uint64_t x1, uint64_t x2,
                                           uint64_t x3, uint64_t x4,
-                                          void *reserved,
+                                          void *cookie,
                                           void *handle,
                                           uint64_t flags);
 
@@ -296,7 +296,7 @@
 
 - - - - - - - - - - - - - - - - - - - - - - - - - -
 
-_Copyright (c) 2014, ARM Limited and Contributors. All rights reserved._
+_Copyright (c) 2014-2015, ARM Limited and Contributors. All rights reserved._
 
 
 [Firmware Design]:  ./firmware-design.md
@@ -304,7 +304,7 @@
 [`services`]:               ../services
 [`services/std_svc/psci`]:  ../services/std_svc/psci
 [`std_svc_setup.c`]:        ../services/std_svc/std_svc_setup.c
-[`runtime_svc.h`]:          ../include/runtime_svc.h
+[`runtime_svc.h`]:          ../include/bl31/runtime_svc.h
 [`smcc_helpers.h`]:          ../include/common/smcc_helpers.h
 [PSCI]:                     http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf "Power State Coordination Interface PDD (ARM DEN 0022C)"
 [SMCCC]:                    http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html "SMC Calling Convention PDD (ARM DEN 0028A)"
diff --git a/docs/user-guide.md b/docs/user-guide.md
index 45b6f50..435a903 100644
--- a/docs/user-guide.md
+++ b/docs/user-guide.md
@@ -57,47 +57,43 @@
 4.  Getting the Trusted Firmware source code
 --------------------------------------------
 
-The Trusted Firmware source code can be obtained as part of the standard Linaro
-releases, which provide a full software stack, including the Trusted Firmware,
-normal world firmware, Linux kernel and device tree, file system as well as any
-additional micro-controller firmware required by the platform. This version of
-Trusted Firmware is tested with the [Linaro 15.10 Release][Linaro Release Notes].
+The Trusted Firmware (TF) source code can be obtained as part of the standard
+Linaro releases, which provide a full software stack, including TF, normal
+world firmware, Linux kernel and device tree, file system as well as any
+additional micro-controller firmware required by the platform. This TF version
+is tested with the [Linaro 15.10 Release][Linaro Release Notes].
 
-Note 1: Both the LSK kernel or the latest tracking kernel can be used with the
-ARM Trusted Firmware, choose the one that best suits your needs.
+Note 1: Both the LSK kernel or the latest tracking kernel can be used with TF;
+choose the one that best suits your needs.
 
 Note 2: Currently to run the latest tracking kernel on FVP with GICv3 driver,
 some modifications are required to UEFI. Refer
 [here](#11--changes-required-for-booting-linux-on-fvp-in-gicv3-mode)
 for more details.
 
-The Trusted Firmware source code can then be found in the `arm-tf/` directory.
-This is the full git repository cloned from Github. The revision checked out by
-the `repo` tool is indicated by the manifest file. Depending on the manifest
-file you're using, this might not be the latest development version. To
-synchronize your copy of the repository and get the latest updates, use the
-following commands:
+The TF source code will then be in `arm-tf/`. This is the upstream git
+repository cloned from GitHub. The revision checked out by the `repo` tool is
+indicated by the manifest file. Depending on the manifest file you're using,
+this might not be the latest upstream version. To synchronize your copy of the
+repository and get the latest updates, use the following commands:
 
     # Change to the Trusted Firmware directory.
     cd arm-tf
 
-    # Download the latest code from Github.
+    # Download the latest code from GitHub.
     git fetch github
 
     # Update your working copy to the latest master.
     # This command will create a local branch master that tracks the remote
-    # branch master from Github.
+    # branch master from GitHub.
     git checkout --track github/master
 
 
-Alternatively, the Trusted Firmware source code can be fetched on its own
-from GitHub:
+Alternatively, the TF source code can be separately cloned from the upstream
+GitHub repository:
 
     git clone https://github.com/ARM-software/arm-trusted-firmware.git
 
-However, the rest of this document assumes that you got the Trusted Firmware
-as part of the Linaro release.
-
 
 5.  Building the Trusted Firmware
 ---------------------------------
@@ -136,7 +132,7 @@
     *   `build/<platform>/<build-type>/bl31.bin`
 
     where `<platform>` is the name of the chosen platform and `<build-type>` is
-    either `debug` or `release`. A Firmare Image Package (FIP) will be created
+    either `debug` or `release`. A Firmware Image Package (FIP) will be created
     as part of the build. It contains all boot loader images except for
     `bl1.bin`.
 
@@ -171,8 +167,8 @@
     the specified binary in the final FIP image. Please note that BL32 will be
     included in the build, only if the `SPD` build option is specified.
 
-    For example, specifying BL2=<path-to>/<bl2_image> in the build option, will
-    skip compilation of BL2 source in trusted firmware, but include the BL2
+    For example, specifying `BL2=<path-to>/<bl2_image>` in the build option,
+    will skip compilation of BL2 source in trusted firmware, but include the BL2
     binary specified in the final FIP image.
 
 ### Summary of build options
@@ -403,8 +399,8 @@
 *   `SPIN_ON_BL1_EXIT`: This option introduces an infinite loop in BL1. It can
     take either 0 (no loop) or 1 (add a loop). 0 is the default. This loop stops
     execution in BL1 just before handing over to BL31. At this point, all
-    firmware images have been loaded in memory and the MMU as well as the caches
-    are turned off. Refer to the "Debugging options" section for more details.
+    firmware images have been loaded in memory, and the MMU and caches are
+    turned off. Refer to the "Debugging options" section for more details.
 
 *   `EL3_PAYLOAD_BASE`: This option enables booting an EL3 payload instead of
     the normal boot flow. It must specify the entry point address of the EL3
@@ -520,7 +516,7 @@
     - EL3 Runtime Firmware BL31: offset=0x8270, size=0xC218
     ---------------------------
 
-Existing package entries can be individially updated:
+Existing package entries can be individually updated:
 
     # Change the BL2 from Debug to Release version
     ./tools/fip_create/fip_create fip.bin --dump \
@@ -603,7 +599,7 @@
 
 The FIP will now contain the additional BL32 image. Here is an example
 output from an FVP build in release mode including BL32 and using
-FVP_AARCH64_EFI.fd as BL33 image:
+`FVP_AARCH64_EFI.fd` as BL33 image:
 
     Firmware Image Package ToC:
     ---------------------------
diff --git a/include/bl31/services/psci.h b/include/bl31/services/psci.h
index 6298a40..acf0786 100644
--- a/include/bl31/services/psci.h
+++ b/include/bl31/services/psci.h
@@ -38,7 +38,7 @@
 #endif
 
 /*******************************************************************************
- * Number of power domains whose state this psci imp. can track
+ * Number of power domains whose state this PSCI implementation can track
  ******************************************************************************/
 #ifdef PLAT_NUM_PWR_DOMAINS
 #define PSCI_NUM_PWR_DOMAINS	PLAT_NUM_PWR_DOMAINS
@@ -60,7 +60,7 @@
 #define PSCI_MAX_PWR_LVL	3
 
 /*******************************************************************************
- * Defines for runtime services func ids
+ * Defines for runtime services function ids
  ******************************************************************************/
 #define PSCI_VERSION			0x84000000
 #define PSCI_CPU_SUSPEND_AARCH32	0x84000001
@@ -255,7 +255,7 @@
 
 /*******************************************************************************
  * Structure populated by platform specific code to export routines which
- * perform common low level pm functions
+ * perform common low level power management functions
  ******************************************************************************/
 typedef struct plat_psci_ops {
 	void (*cpu_standby)(plat_local_state_t cpu_state);
@@ -276,7 +276,7 @@
 
 /*******************************************************************************
  * Optional structure populated by the Secure Payload Dispatcher to be given a
- * chance to perform any bookkeeping before PSCI executes a power mgmt.
+ * chance to perform any bookkeeping before PSCI executes a power management
  * operation. It also allows PSCI to determine certain properties of the SP e.g.
  * migrate capability etc.
  ******************************************************************************/
diff --git a/plat/arm/board/fvp/aarch64/fvp_helpers.S b/plat/arm/board/fvp/aarch64/fvp_helpers.S
index 338d158..fe7358f 100644
--- a/plat/arm/board/fvp/aarch64/fvp_helpers.S
+++ b/plat/arm/board/fvp/aarch64/fvp_helpers.S
@@ -139,7 +139,7 @@
 	 * For a warm boot, read the mailbox and return the address it contains.
 	 *
 	 * TODO: PSYSR is a common register and should be
-	 * 	accessed using locks. Since its not possible
+	 * 	accessed using locks. Since it is not possible
 	 * 	to use locks immediately after a cold reset
 	 * 	we are relying on the fact that after a cold
 	 * 	reset all cpus will read the same WK field
diff --git a/plat/arm/board/fvp/fvp_pm.c b/plat/arm/board/fvp/fvp_pm.c
index c5129a6..f959fab 100644
--- a/plat/arm/board/fvp/fvp_pm.c
+++ b/plat/arm/board/fvp/fvp_pm.c
@@ -154,11 +154,9 @@
 	unsigned int psysr;
 
 	/*
-	 * Ensure that we do not cancel an inflight power off request
-	 * for the target cpu. That would leave it in a zombie wfi.
-	 * Wait for it to power off, program the jump address for the
-	 * target cpu and then program the power controller to turn
-	 * that cpu on
+	 * Ensure that we do not cancel an inflight power off request for the
+	 * target cpu. That would leave it in a zombie wfi. Wait for it to power
+	 * off and then program the power controller to turn that CPU on.
 	 */
 	do {
 		psysr = fvp_pwrc_read_psysr(mpidr);
diff --git a/services/spd/tspd/tspd_main.c b/services/spd/tspd/tspd_main.c
index 4b89425..1a06459 100644
--- a/services/spd/tspd/tspd_main.c
+++ b/services/spd/tspd/tspd_main.c
@@ -231,7 +231,7 @@
 		return 1;
 
 	/*
-	 * We could inspect the SP image and determine it's execution
+	 * We could inspect the SP image and determine its execution
 	 * state i.e whether AArch32 or AArch64. Assuming it's AArch64
 	 * for the time being.
 	 */
@@ -461,7 +461,7 @@
 #endif
 
 	/*
-	 * These function IDs is used only by the SP to indicate it has
+	 * These function IDs are used only by the SP to indicate it has
 	 * finished:
 	 * 1. turning itself on in response to an earlier psci
 	 *    cpu_on request
@@ -472,7 +472,7 @@
 	case TSP_RESUME_DONE:
 
 	/*
-	 * These function IDs is used only by the SP to indicate it has
+	 * These function IDs are used only by the SP to indicate it has
 	 * finished:
 	 * 1. suspending itself after an earlier psci cpu_suspend
 	 *    request.
diff --git a/services/std_svc/psci/psci_private.h b/services/std_svc/psci/psci_private.h
index 8c028a7..3286cf6 100644
--- a/services/std_svc/psci/psci_private.h
+++ b/services/std_svc/psci/psci_private.h
@@ -206,10 +206,10 @@
 void psci_cpu_on_finish(unsigned int cpu_idx,
 			psci_power_state_t *state_info);
 
-/* Private exported functions from psci_cpu_off.c */
+/* Private exported functions from psci_off.c */
 int psci_do_cpu_off(unsigned int end_pwrlvl);
 
-/* Private exported functions from psci_pwrlvl_suspend.c */
+/* Private exported functions from psci_suspend.c */
 void psci_cpu_suspend_start(entry_point_info_t *ep,
 			unsigned int end_pwrlvl,
 			psci_power_state_t *state_info,