Documentation: Minor fixes in Tickless OS documentation

* Documentation/reference/os/time_clock.rst:
  Add missing Kconfig code-block, found at CWIKI [1].
  Fix some typos.

References:
[1] https://cwiki.apache.org/confluence/display/NUTTX/Tickless+OS

Author: hartmannathan

Documentation/reference/os/time_clock.rst

@@ -209,13 +209,13 @@ are, in increasing order of importance:
 
 -  **Overhead**: Although the CPU usage of the system timer
    interrupt at 100Hz is really very low, it is still mostly
-   wasted processing time. One most timer interrupts, there is
-   really nothing that needs be done other than incrementing the
+   wasted processing time. On most timer interrupts, there is
+   really nothing that needs to be done other than incrementing the
    counter.
 -  **Resolution**: Resolution of all system timing is also
-   determined by ``CONFIG_USEC_PER_TICK``. So nothing that be time
-   with resolution finer than 10 milliseconds be default. To
-   increase this resolution, ``CONFIG_USEC_PER_TICK`` an be
+   determined by ``CONFIG_USEC_PER_TICK``. So nothing can be timed
+   with resolution finer than 10 milliseconds by default. To
+   increase this resolution, ``CONFIG_USEC_PER_TICK`` can be
    reduced. However, then the system timer interrupts use more of
    the CPU bandwidth processing useless interrupts.
 -  **Power Usage**: But the biggest issue is power usage. When the
@@ -226,7 +226,7 @@ are, in increasing order of importance:
    greater power consumption.
 
 **Tickless OS**. The so-called *Tickless OS* provides one solution
-to issue. The basic concept here is that the periodic, timer
+to this issue. The basic concept here is that the periodic, timer
 interrupt is eliminated and replaced with a one-shot, interval
 timer. It becomes event driven instead of polled: The default
 system timer is a polled design. On each interrupt, the NuttX
@@ -255,18 +255,26 @@ Tickless Configuration Options
 
 -  ``CONFIG_ARCH_HAVE_TICKLESS``: If the platform provides
    support for the *Tickless OS*, then this setting should be
-   selected in the ``Kconfig`` file for the board. Here is what
-   the selection looks in the ``arch/Kconfig`` file for the
+   selected in the ``Kconfig`` file for the architecture. Here is
+   what the selection looks in the ``arch/Kconfig`` file for the
    simulated platform:
 
+   .. code-block:: console
+ 
+     config ARCH_SIM
+        bool "Simulation"
+        select ARCH_HAVE_TICKLESS
+        ---help---
+                Linux/Cywgin user-mode simulation.
+
    When the simulation platform is selected,
    ``ARCH_HAVE_TICKLESS`` is automatically selected, informing the
    configuration system that *Tickless OS* options can be
    selected.
 
--  ``CONFIG_SCHED_TICKLESS``: If ``CONFIG_ARCH_HAVE_TICKLESS``
-   is selected, then it will enable the Tickless OS features in
-   NuttX.
+-  ``CONFIG_SCHED_TICKLESS``: If ``CONFIG_ARCH_HAVE_TICKLESS`` is
+   selected, then you will be able to use this option to enable the
+   *Tickless OS* features in NuttX.
 
 -  ``CONFIG_SCHED_TICKLESS_ALARM``: The tickless option can be
    supported either via a simple interval timer (plus elapsed
@@ -277,15 +285,15 @@ Tickless Configuration Options
 
    The advantage of an alarm is that it avoids some small timing
    errors; the advantage of the use of the interval timer is that
-   the hardware requirement may be less.
+   the hardware requirement may be simpler.
 
 -  ``CONFIG_USEC_PER_TICK``: This option is not unique to
    *Tickless OS* operation, but changes its relevance when the
-   *Tickless OS* is selected. In the default configuration where
+   *Tickless OS* is selected. In the default configuration, where
    system time is provided by a periodic timer interrupt, the
-   default system timer is configure the timer for 100Hz or
+   default system timer is configured for 100Hz, that is,
    ``CONFIG_USEC_PER_TICK=10000``. If ``CONFIG_SCHED_TICKLESS`` is
-   selected, then there are no system timer interrupt. In this
+   selected, then there are no system timer interrupts. In this
    case, ``CONFIG_USEC_PER_TICK`` does not control any timer
    rates. Rather, it only determines the resolution of time
    reported by ``clock_systime_ticks()`` and the resolution of
@@ -342,26 +350,23 @@ platform code must provide the following verify similar functions:
 -  ``up_timer_start()``: Starts (or re-starts)
    the interval timer.
 
-Note that a platform-specific implementation would probably
-require two hardware timers: (1) A interval timer to satisfy the
-requirements of ``up_timer_start()`` and
-``up_timer_cancel()``, and a (2) a counter to
-handle the requirement of
-``up_timer_gettime()``. Ideally, both timers
+Note that a platform-specific implementation would probably require two
+hardware timers: (1) A interval timer to satisfy the requirements of
+``up_timer_start()`` and ``up_timer_cancel()``, and (2) a counter to
+handle the requirement of ``up_timer_gettime()``. Ideally, both timers
 would run at the rate determined by ``CONFIG_USEC_PER_TICK`` (and
 certainly never slower than that rate).
 
-Since timers are a limited resource, the use of two timers could
-be an issue on some systems. The job could be done with a single
-timer if, for example, the single timer were kept in a
-free-running at all times. Some timer/counters have the capability
-to generate a compare interrupt when the timer matches a
-comparison value but also to continue counting without stopping.
-If your hardware supports such counters, one might used the
-``CONFIG_SCHED_TICKLESS_ALARM`` option and be able to simply set
-the comparison count at the value of the free running timer *PLUS*
-the desired delay. Then you could have both with a single timer:
-An alarm and a free-running counter with the same timer!
+Since timers are a limited resource, the use of two timers could be an
+issue on some systems. The job could be done with a single timer if, for
+example, the single timer were kept in a free-running mode at all times.
+Some timer/counters have the capability to generate a compare interrupt
+when the timer matches a comparison value but also to continue counting
+without stopping. If your hardware supports such counters, one might use
+the ``CONFIG_SCHED_TICKLESS_ALARM`` option and be able to simply set the
+comparison count at the value of the free running timer *PLUS* the
+desired delay. Then you could have both with a single timer: An alarm
+and a free-running counter with the same timer!
 
 In addition to these imported interfaces, the RTOS will export the
 following interfaces for use by the platform-specific interval