doc: Apply it's/its grammar pedantry

doc/source/additional_topics.rst

@@ -6,10 +6,10 @@ Modules
 
 Modules are essentially plug-ins for Extensions. They provide a way of defining 
 common and reusable functionality. An Extension can load zero or more modules
-during it's creation. Loaded modules will then add their capabilities (see
+during its creation. Loaded modules will then add their capabilities (see
 Capabilities_) to those of the Extension. When calling code tries to access an
 attribute of an Extension the Extension doesn't have, it will try to find the
-attribute among it's loaded modules and will return that instead. 
+attribute among its loaded modules and will return that instead.
 
 .. note:: Modules are themselves extensions, and can therefore load their own
           modules. *Do not* abuse this.

doc/source/device_setup.rst

@@ -64,7 +64,7 @@ you might want to change are outlined below.
    advanced WA functionality (like setting of core-related runtime parameters
    such as governors, frequencies, etc). ``core_names`` should be a list of
    core names matching the order in which they are exposed in sysfs. For
-   example, ARM TC2 SoC is a 2x3 big.LITTLE system; it's core_names would be
+   example, ARM TC2 SoC is a 2x3 big.LITTLE system; its core_names would be
    ``['a7', 'a7', 'a7', 'a15', 'a15']``, indicating that cpu0-cpu2 in cpufreq
    sysfs structure are A7's and cpu3 and cpu4 are A15's.
 

doc/source/writing_extensions.rst

@@ -11,7 +11,7 @@ interesting of these are
             can be benchmarks, high-level use cases, or pretty much anything else.
 :devices: These are interfaces to the physical devices (development boards or end-user
           devices, such as smartphones) that use cases run on. Typically each model of a
-          physical device would require it's own interface class (though some functionality
+          physical device would require its own interface class (though some functionality
           may be reused by subclassing from an existing base).
 :instruments: Instruments allow collecting additional data from workload execution (e.g.
               system traces). Instruments are not specific to a particular Workload. Instruments

wlauto/core/configuration.py

@@ -425,7 +425,7 @@ class RunConfiguration(object):
       is validated (to make sure there are no missing settings, etc).
     - Extensions are loaded through the run config object, which instantiates
       them with appropriate parameters based on the "raw" config collected earlier. When an
-      Extension is instantiated in such a way, it's config is "officially" added to run configuration
+      Extension is instantiated in such a way, its config is "officially" added to run configuration
       tracked by the run config object. Raw config is discarded at the end of the run, so
       that any config that wasn't loaded in this way is not recoded (as it was not actually used).
     - Extension parameters a validated individually (for type, value ranges, etc) as they are

wlauto/core/device.py

@@ -174,7 +174,7 @@ class Device(Extension):
                   description="""
                   This is a list indicating the cluster affinity of the CPU cores,
                   each element correponding to the cluster ID of the core coresponding
-                  to it's index. E.g. ``[0, 0, 1]`` indicates that cpu0 and cpu1 are on
+                  to its index. E.g. ``[0, 0, 1]`` indicates that cpu0 and cpu1 are on
                   cluster 0, while cpu2 is on cluster 1. If this is not specified, this
                   will be inferred from ``core_names`` if possible (assuming all cores with
                   the same name are on the same cluster).

wlauto/core/execution.py

@@ -72,7 +72,7 @@ REBOOT_DELAY = 3
 
 class RunInfo(object):
     """
-    Information about the current run, such as it's unique ID, run
+    Information about the current run, such as its unique ID, run
     time, etc.
 
     """

wlauto/core/extension.py

@@ -303,7 +303,7 @@ class Artifact(object):
                         network filer archiver may choose to archive them).
 
         .. note: The kind parameter is intended to represent the logical function of a particular
-                 artifact, not it's intended means of processing -- this is left entirely up to the
+                 artifact, not its intended means of processing -- this is left entirely up to the
                  result processors.
 
     """
@@ -406,7 +406,7 @@ class ExtensionMeta(type):
     def _propagate_attributes(mcs, bases, attrs):
         """
         For attributes specified by to_propagate, their values will be a union of
-        that specified for cls and it's bases (cls values overriding those of bases
+        that specified for cls and its bases (cls values overriding those of bases
         in case of conflicts).
 
         """
@@ -665,7 +665,7 @@ class Module(Extension):
     In other words, a Module is roughly equivalent to a kernel module and its primary purpose is to
     implement WA "drivers" for various peripherals that may or may not be present in a particular setup.
 
-    .. note:: A mudule is itself an Extension and can therefore have it's own modules.
+    .. note:: A mudule is itself an Extension and can therefore have its own modules.
 
     """
 

wlauto/core/resource.py

@@ -82,7 +82,7 @@ class ResourceGetter(Extension):
     Base class for implementing resolvers. Defines resolver interface. Resolvers are
     responsible for discovering resources (such as particular kinds of files) they know
     about based on the parameters that are passed to them. Each resolver also has a dict of
-    attributes that describe it's operation, and may be used to determine which get invoked.
+    attributes that describe its operation, and may be used to determine which get invoked.
     There is no pre-defined set of attributes and resolvers may define their own.
 
     Class attributes:

wlauto/utils/trace_cmd.py

@@ -173,13 +173,13 @@ def regex_body_parser(regex, flags=0):
     return regex_parser_func
 
 
-# Maps event onto the corresponding parser for it's body text. A parser may be
+# Maps event onto the corresponding parser for its body text. A parser may be
 # a callable with signature
 #
 #   parser(event, bodytext)
 #
 # a re.RegexObject, or a string (in which case it will be compiled into a
-# regex). In case of a string/regex, it's named groups will be used to populate
+# regex). In case of a string/regex, its named groups will be used to populate
 # the event's attributes.
 EVENT_PARSER_MAP = {
     'sched_switch': re.compile(