doc: Documentation edits for 2.7.99-cs1 release

Added firmware bundle compatibility table.
Updated nRF54H20 GS guide.
Added initial power management documentation.
Added initial clock control documentation

Signed-off-by: Francesco Domenico Servidio <francesco.servidio@nordicsemi.no>

doc/nrf/app_dev/device_guides/nrf54h.rst

@@ -21,6 +21,19 @@ Zephyr and the |NCS| provide support and contain board definitions for developin
        | ``nrf54h20dk_nrf54h20_cpurad``
        | ``nrf54h20dk_nrf54h20_cpuppr``
 
+The following table indicates the compatibility between nRF54H20 firmware bundle versions and |NCS| versions:
+
+.. list-table::
+   :header-rows: 1
+
+   * - |NCS| version
+     - nRF54H20 firmware bundle version
+   * - v2.7
+     - v0.5.0
+   * - v2.7.99-cs1
+     - v0.6.2
+
+
 .. toctree::
    :maxdepth: 2
    :caption: Subpages:

doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture.rst

@@ -21,3 +21,4 @@ The following pages briefly describe topics like the responsibilities of the cor
    ug_nrf54h20_architecture_ipc
    ug_nrf54h20_architecture_boot
    ug_nrf54h20_architecture_lifecycle
+   ug_nrf54h20_architecture_pm

doc/nrf/app_dev/device_guides/working_with_nrf/nrf54h/ug_nrf54h20_architecture_clockman.rst

@@ -0,0 +1,110 @@
+.. _ug_nrf54h20_architecture_clockman:
+
+nRF54H20 Clock Management
+#########################
+
+.. contents::
+   :local:
+   :depth: 2
+
+The nRF54H20 SoC consists of multiple asynchronous clock domains and requires clock sources for correct operation.
+Each of the clock sources needs proper management:
+
+* To start and stop the clock at the appropriate time.
+* To select the proper clock source.
+* To calibrate or synchronize the clock to a more accurate source.
+
+Some of the clock management operations are performed solely by the hardware circuits, but others require software intervention.
+Most of the clocks can be locked to other, more accurate ones to improve their accuracy.
+
+Clock Domains
+*************
+
+The nRF54H20 SoC consists of the following clock domains:
+
+* LFCLK
+* HFXO
+* FLL16M
+* HSFLL Application
+* HSFLL Radio
+* HSFLL Secure
+* HSFLL Global
+
+Each clock domain is enabled independently of others and it is automatically enabled when at least one sink is active.
+The firmware can choose to keep each clock domains enabled even when all its sinks are inactive.
+
+Clock domain source selection differs between clock domains:
+
+* The LFCLK source is selected by the System Controller Firmware.
+* The HFXO source is selected by the System Controller Firmware.
+* The FLL16M source is selected by local domains or System Controller Firmware (SCFW) in all scenarios, except one:
+  When the firmware selects open-loop, but any of the HSFLL sources is in closed-loop, the FLL16M is automatically switched by the hardware to closed-loop.
+
+* HSFLLs sources are selected by firmware (depending on an HSFLL instance: local domain or System Controller).
+
+The application-facing APIs expose only the domain that directly clocks the component used by the application.
+The management of the clocks on which this domain depends is handled internally by the clock driver associated with this domain.
+
+For example, a firmware module might request better timing accuracy for a fast UART instance.
+In this case, the firmware module requests the accuracy from the global HSFLL device driver, which directly clocks the UART.
+The dependencies, such as FLL16M and LFXO, are managed internally by the global HSFLL driver, not directly by the firmware module.
+
+
+LFCLK
+=====
+
+The Low-Frequency Clock domain is responsible for generating a 32768 Hz clock signal for ultra-low-power peripherals like ``GRTC`` or ``RTC``.
+
+HFXO
+====
+
+The High-Frequency Crystal Oscillator domain is responsible for clocking peripherals requiring high accuracy and MHz range frequency.
+The drawback of this clock source is relatively high power consumption so it is enabled only when needed.
+
+Hardware capabilities
+---------------------
+
+The HFXO, like any other clock domain, can be connected in hardware to one of the available sources.
+And it provides the clock signal to all of its sinks.
+
+FLL16M
+======
+
+The FLL16M clock domain clocks most of the peripherals in the system ("slow", 16 MHz).
+Its accuracy results in the timing accuracy of slow ``UART``, ``SPI``, ``TWI``, ``PWM``, ``SAADC``, etc.
+
+Local HSFLLs
+============
+
+Local HSFLLs are clocking CPUs in local domains, fast peripherals around them, and local RAM.
+
+Global HSFLL
+============
+
+Global HSFLL clocks "fast" peripherals, FLPR, RAM, and MRAM blocks.
+
+Zephyr clock control API
+************************
+
+Zephyr RTOS contains a ``clock_control`` device driver class for managing clocks.
+The ``clock_control`` API is designed to support multiple requestors.
+Moreover, the ``clock_control`` API supports blocking or asynchronous operations based on notifications when the requested clock settings are applied.
+
+The ``clock_control`` subsystem exposes portable parameters in its functions:
+
+* Accuracy requests in ppm values.
+* Precision requests in enumerated high- and low-precision modes.
+
+For more details, see the following links:
+
+* :ref:`zephyr:clock_control_api`.
+* The following calls in the `Zephyr's nRF clock control API extensions`_ (:file:`include/zephyr/drivers/clock_control/nrf_clock_control.h`):
+
+  * ``nrf_clock_control_request()``: Requests a reservation to use a given clock with specified attributes.
+  * ``nrf_clock_control_release()``: Releases a reserved use of a clock.
+  * ``nrf_clock_control_cancel_or_release()``: Safely cancels a reservation request.
+
+* The following calls in the `clocks devicetree macro API`_ (:file:`include/zephyr/devicetree/clocks.h`):
+
+  * ``DT_CLOCKS_CTLR_BY_IDX()``: Gets the node identifier for the controller phandle from a *clocks* phandle-array property at an index.
+  * ``DT_CLOCKS_CTLR()``: It is equivalent to ``DT_CLOCKS_CTLR_BY_IDX()``.