doc: Misc fixes

Fix typos, formatting and irrelevant information.

doc/source/how_tos/users/agenda.rst

@@ -347,8 +347,8 @@ Classifiers
 ------------
 
 Classifiers can be used in 2 distinct ways, the first use is being supplied in
-an agenda as a set of key-value pairs which can be used to help identify sub-
-tests of a run, for example if you have multiple sections in your agenda running
+an agenda as a set of key-value pairs which can be used to help identify sub-tests
+of a run, for example if you have multiple sections in your agenda running
 your workloads at different frequencies you might want to set a classifier
 specifying which frequencies are being used. These can then be utilized later,
 for example with the ``csv`` :ref:`output processor <output-processors>` with
@@ -384,9 +384,9 @@ An example agenda is shown here:
 The other way that they can used is by being automatically added by some
 workloads to identify their results metrics and artifacts. For example some
 workloads perform multiple tests with the same execution run and therefore will
-use metrics to differentiate between them, For example the ``recentfling``
-workload will use classifiers to distinguish between which loop a particular
-result is for or whether it is an average across all loops ran.
+use metrics to differentiate between them, e.g. the ``recentfling`` workload
+will use classifiers to distinguish between which loop a particular result is
+for or whether it is an average across all loops ran.
 
 The output from the agenda above will produce a csv file similar to what is
 shown below. Some columns have been omitted for clarity however as can been seen
@@ -500,7 +500,7 @@ turn override global settings.
 
 
 
-Augmentationts
+Augmentations
 --------------
 
 Augmentations are plugins that augment the execution of workload jobs with
@@ -509,7 +509,7 @@ metrics and/or artifacts, such as traces or logs. There are two types of
 augmentations:
 
 Instruments
-        These "instrument" a WA run in order to change it's behavior (e.g.
+        These "instrument" a WA run in order to change it's behaviour (e.g.
         introducing delays between successive job executions), or collect
         additional measurements (e.g. energy usage). Some instruments may depend
         on particular features being enabled on the target (e.g. cpufreq), or
@@ -677,9 +677,11 @@ Each workload will be run in two configurations: once, to collect energy
 measurements, and once to collect thermal data and kernel trace. Trace can give
 insight into why a workload is using more or less energy than expected, but it
 can be relatively intrusive and might impact absolute energy and performance
-metrics, which is why it is collected separately. classifiers_ are used to
+metrics, which is why it is collected separately. Classifiers_ are used to
 separate metrics from the two configurations in the results.
 
+.. _other-agenda-configuration:
+
 Other Configuration
 -------------------
 

doc/source/how_tos/users/device_setup.rst

@@ -20,12 +20,11 @@ Android
 General Device Setup
 ^^^^^^^^^^^^^^^^^^^^
 
-You can specify the device interface by setting ``device`` setting in
-``~/.workload_automation/config.yaml``. Available interfaces can be viewed by
-running ``wa list targets`` command. If you don't see your specific platform
-listed (which is likely unless you're using one of the Arm-supplied platforms), then
-you should use ``generic_android`` interface (this is set in the config by
-default).
+You can specify the device interface by setting ``device`` setting in a
+``config`` file or section. Available interfaces can be viewed by running ``wa
+list targets`` command. If you don't see your specific platform listed (which is
+likely unless you're using one of the Arm-supplied platforms), then you should
+use ``generic_android`` interface (this is what is used by the default config).
 
 .. code-block:: yaml
 
@@ -38,7 +37,8 @@ common parameters you might want to change are outlined below.
 .. confval:: device
 
    If you have multiple Android devices connected to the host machine, you will
-   need to set this to indicate to WA which device you want it to use.
+   need to set this to indicate to WA which device you want it to use. The will
+   be the adb name the is displayed when running ``adb devices``
 
 .. confval:: working_directory
 
@@ -81,7 +81,7 @@ A typical ``device_config`` inside ``config.yaml`` may look something like
 
         device_config:
                 device: 0123456789ABCDEF
-                # ...
+        # ...
 
 
 or a more specific config could be be
@@ -172,12 +172,11 @@ Linux
 General Device Setup
 ^^^^^^^^^^^^^^^^^^^^
 
-You can specify the device interface by setting ``device`` setting in
-``~/.workload_automation/config.yaml``. Available interfaces can be viewed by
-running ``wa list targets`` command. If you don't see your specific platform
-listed (which is likely unless you're using one of the Arm-supplied platforms), then
-you should use ``generic_linux`` interface (this is set in the config by
-default).
+You can specify the device interface by setting ``device`` setting in a
+``config`` file or section. Available interfaces can be viewed by running
+``wa list targets`` command. If you don't see your specific platform listed
+(which is likely unless you're using one of the Arm-supplied platforms), then
+you should use ``generic_linux`` interface.
 
 .. code-block:: yaml
 
@@ -239,25 +238,24 @@ Chrome OS
 General Device Setup
 ^^^^^^^^^^^^^^^^^^^^
 
-You can specify the device interface by setting ``device`` setting in
-``~/.workload_automation/config.yaml``. Available interfaces can be viewed by
+You can specify the device interface by setting ``device`` setting in a
+``config`` file or section. Available interfaces can be viewed by
 running ``wa list targets`` command. If you don't see your specific platform
 listed (which is likely unless you're using one of the Arm-supplied platforms), then
-you should use ``generic_chromeos`` interface (this is set in the config by
-default).
+you should use ``generic_chromeos`` interface.
 
 .. code-block:: yaml
 
         device: generic_chromeos
 
 The device interface may be configured through ``device_config`` setting, who's
-value is a ``dict`` mapping setting names to their values. The chrome os target
+value is a ``dict`` mapping setting names to their values. The ChromeOS target
 is essentially the same as a linux device and requires a similar setup, however
 it also optionally supports connecting to an android container running on the
-device which will be automatically deted if present. If the device supports
+device which will be automatically detected if present. If the device supports
 android applications then the android configuration is also supported. In order
-to support this then WA will open 2 connections to the device, one via SSH to
-the main ChomeOS OS and another via ADB to the android container where a limited
+to support this WA will open 2 connections to the device, one via SSH to
+the main OS and another via ADB to the android container where a limited
 subset of functionality can be performed.
 
 In order to distinguish between the two connections some of the android specific

doc/source/how_tos/users/revent.rst

@@ -94,7 +94,7 @@ command with an example output shown below::
     INFO     Recording(s) are available at: '$WA_USER_DIRECTORY/dependencies/angrybirds_rio/revent_files'
 
 Once you have made your desired recordings, you can either manually playback
-individual recordings using the :ref:`reply <replay-command>` command or, with
+individual recordings using the :ref:`replay <replay-command>` command or, with
 the recordings in the appropriate dependencies location, simply run the workload
 using the :ref:`run <run-command>` command and then all the available recordings will be
 played back automatically.