Bugfix/lint collection

source/buildroot/Overview.rst

@@ -44,7 +44,7 @@ to github repository.
 Repository structure
 ====================
 
-.. code-block::
+.. code-block:: text
 
     buildroot-external-TI
     ├── external.desc

source/common/EVM_Hardware_Setup/_AM68_SK_Hardware_Setup.rst

@@ -8,7 +8,7 @@ AM68 SK is a low cost, small form factor board designed
 to bring smart cameras, robots and intelligent machines to life.
 For more information related to the board, full list of peripherals supported,
 pin settings for boot modes and more
-visit AM68 SK `User guide <https://www.ti.com/lit/pdf/spruj68>`_
+visit AM68 SK `User guide <https://www.ti.com/lit/pdf/spruj68>`__
 
 To run the demos on AM68 SK you will require,
 
@@ -23,7 +23,7 @@ To run the demos on AM68 SK you will require,
 
         a. Nominal Output Voltage: 5-20VDC
         b. Maximum Output Current: 5000 mA
-        c. Refer to AM68 SK `User guide <https://www.ti.com/lit/pdf/spruj68>`_
+        c. Refer to AM68 SK `User guide <https://www.ti.com/lit/pdf/spruj68>`__
            for more details.
 
 Connect the components to the EVM as shown in the image.

source/common/EVM_Hardware_Setup/_AM69_SK_Hardware_Setup.rst

@@ -8,7 +8,7 @@ AM69 SK is a low cost, small form factor board designed
 to bring smart cameras, robots and intelligent machines to life.
 For more information related to the board, full list of peripherals supported,
 pin settings for boot modes and more
-visit AM69 SK `User guide <https://www.ti.com/lit/pdf/spruj70>`_
+visit AM69 SK `User guide <https://www.ti.com/lit/pdf/spruj70>`__
 
 To run the demos on AM69 SK you will require,
 
@@ -23,7 +23,7 @@ To run the demos on AM69 SK you will require,
 
         a. Nominal Output Voltage: 5-20VDC
         b. Maximum Output Current: 5000 mA
-        c. Refer to AM69 SK `User guide <https://www.ti.com/lit/pdf/spruj70>`_
+        c. Refer to AM69 SK `User guide <https://www.ti.com/lit/pdf/spruj70>`__
            for more details.
 
 Connect the components to the EVM as shown in the image.

source/common/EVM_Hardware_Setup/_OMAPL137_EVM_Hardware_Setup.rst

@@ -1,6 +1,6 @@
 
 OMAP-L137/C6747 EVM Hardware Setup Guide
-======================================
+========================================
 
 Setting up the Hardware
 -----------------------

source/common/EVM_Hardware_Setup/_OMAPL138-C6748_LCDK_Hardware_Setup.rst

@@ -111,6 +111,7 @@ Connecting to Target and Loading/Running Program
 The following GEL outputs should appear in the CCS Console view.
 
 **OMAP-L138 LCDK:**
+
 ::
 
 	ARM9_0: Output: 	Target Connected.
@@ -131,6 +132,7 @@ The following GEL outputs should appear in the CCS Console view.
 	ARM9_0: Output: 	---------------------------------------------
 
 **C6748 LCDK:**
+
 ::
 
 	C674X_0: Output: 	Target Connected.

source/debian/Building_Debian_Image.rst

@@ -31,15 +31,15 @@ The scripts are hosted at https://github.com/TexasInstruments/ti-bdebstrap
 
 To clone the repository, run:
 
-.. code-block::
+.. code-block:: console
 
     git clone https://github.com/TexasInstruments/ti-bdebstrap.git
 
 
 Repository Structure
 --------------------
 
-.. code-block::
+.. code-block:: text
 
     ti-bdebstrap
     ├── build.sh
@@ -108,13 +108,13 @@ Install Pre-requisite Packages
 
 First, ensure that your repositories are up-to-date:
 
-.. code-block::
+.. code-block:: console
 
     sudo apt update
 
 Then, install packages as follows:
 
-.. code-block::
+.. code-block:: console
 
     sudo apt install -y \
         pigz expect pv \
@@ -128,13 +128,13 @@ Then, install packages as follows:
 
 Ensure that all packages were correctly installed using:
 
-.. code-block::
+.. code-block:: console
 
     sudo apt install --fix-broken
 
 Finally, install ``toml-cli`` and ``yamllint``:
 
-.. code-block::
+.. code-block:: console
 
     pip3 install toml-cli
     pip3 install yamllint
@@ -182,7 +182,7 @@ Building the Image
 
 To build an image, you need to run the :file:`build.sh` script:
 
-.. code-block::
+.. code-block:: console
 
     sudo ./build.sh <build-name>
 
@@ -192,7 +192,7 @@ After the build, the RootFS, Boot partition and bsp_sources are stored in :file:
 
 Example: to build for ``trixie-am62pxx-evm``, run:
 
-.. code-block::
+.. code-block:: console
 
     sudo ./build.sh trixie-am62pxx-evm
 
@@ -205,13 +205,13 @@ This step can be skipped if you do not want to share the generated Image with an
 
 To generate an SD Card Image with the generated RootFS and Boot partition files, run:
 
-.. code-block::
+.. code-block:: console
 
    ./create-wic.sh <build-name>
 
 Example: to build for ``trixie-am62pxx-evm``, run:
 
-.. code-block::
+.. code-block:: console
 
    ./create-wic.sh trixie-am62pxx-evm
 
@@ -222,13 +222,13 @@ Flash Image to SD Card using Script
 
 To flash the SD card without generating a wic image, use the :file:`create-sdcard.sh` script. Run it using the below command and follow with the prompts.
 
-.. code-block::
+.. code-block:: console
 
     sudo ./create-sdcard.sh <build-name>
 
 For example, if the image is ``trixie-am62pxx-evm``, type:
 
-.. code-block::
+.. code-block:: console
 
     sudo ./create-sdcard.sh trixie-am62pxx-evm
 

source/devices/AM57X/linux/Release_Specific_Performance_Guide.rst

@@ -721,6 +721,7 @@ OpenSSL Performance
 |
 
 ::
+
     time -v openssl speed -elapsed -evp aes-128-cbc
 
 

source/devices/J7_Family/linux/Release_Specific_Yocto_layer_Configuration.rst

@@ -27,6 +27,7 @@ Yocto Layer Configuration
       ./oe-layertool-setup.sh -f configs/processor-sdk-linux/<Config File>
 
 The Linux SDK package also has the above tool cloned at the top level. If you have it installed:
+
 ::
 
     cd <SDK INSTALL DIR>/yocto-build

source/linux/Examples_and_Demos/Application_Demos/Dual_Camera_Demo.rst

@@ -6,27 +6,23 @@ Below diagram illustrates the video data processing flow of dual camera demo.
 
 .. Image:: /images/Dual_camera_demo.png
 
-**Dual camera example demo demonstrates following-**
+**Dual camera example demo demonstrates the following**
 
-1. Video capture using V4L2 interface from up to two cameras.
-2. QT QWidget based drawing of user interface using linuxfb plugin. linuxfb is fbdev based software drawn QPA.
+#. Video capture using V4L2 interface from up to two cameras.
+#. QT QWidget based drawing of user interface using linuxfb plugin, where linuxfb is an fbdev based software drawn QPA.
 #. Hardware accelerated scaling of input video from primary camera to display resolution using DSS IP.
 #. Hardware accelerated scaling of input video from secondary camera (if connected) to lower resolution using DSS IP.
 #. Hardware accelerated overlaying of two video planes and graphics plane using DSS IP.
 #. Scaling of two video planes and overlaying with graphics plane happens on the fly in single pass inside DSS IP using DRM atomic APIs.
-#. Snapshot of the screen using JPEG compression running on ARM. The captured images are stored in filesystem under /usr/share/camera-images/ folder
-#. The camera and display driver shares video buffer using dmabuf protocol. Capture driver writes captured content to a buffer which is directly read by the display driver without copying the content locally to another buffer (zero copy involved).
+#. Snapshot of the screen using JPEG compression running on ARM. The captured images are stored in filesystem under the :file:`/usr/share/camera-images/` folder
+#. The camera and display driver shares video buffer using DMA buffers. The capture driver writes content to a buffer which is directly read by the GPU and potentially the display without copying the content locally to another buffer (zero copy involved).
 #. The application also demonstrates allocating the buffer from either omap_bo (from omapdrm) memory pool or from cmem buffer pool. The option to pick omap_bo or cmem memory pool is provided runtime using cmd line.
 #. If the application has need to do some CPU based processing on captured buffer, then it is recommended to allocate the buffer using CMEM buffer pool. The reason being omap_bo memory pool doesn't support cache read operation. Due to this any CPU operation involving video buffer read will be 10x to 15x slower. CMEM pool supports cache operation and hence CPU operations on capture video buffer are fast.
-#. The application runs in nullDRM/full screen mode (no windows manager like wayland/x11) and the linuxfb QPA runs in fbdev mode. This gives applicationfull control of DRM resource DSS to control and display the video planes.
+#. The application runs in nullDRM/full screen mode (no compositors like Weston) and the linuxfb QPA runs in fbdev mode. This gives application full control of DRM resource DSS to control and display the video planes.
 
 **Instructions to run dual camera demo**
 
 * Since the application need control of DRM resource (DSS) and there can be only one master, make sure that the wayland/weston is not running.
-#/etc/init.d/weston stop
-
-* Run the dual camera application
-#dual-camera -platform linuxfb <0/1>
-
+* Run the dual camera application ``dual-camera -platform linuxfb <0/1>``
 * When last argument is set as 0, capture and display driver allocates memory from omap_bo pool.
 * When it is set to 1, the buffers are allocated from CMEM pool.

source/linux/Examples_and_Demos/Application_Demos/Video_Graphics_Test.rst

@@ -50,6 +50,7 @@ The APIs required to achieve scaling, overlaying and alpha-blending using the DS
 Running the Test
 ----------------
 In order for the users to run the video graphics test, please type the following commands on the EVM:
+
 ::
 
     target # insmod /lib/modules/<kernel_version>/extra/galcore.ko baseAddress=0x80000000 physSize=0x80000000

source/linux/Foundational_Components/IPC/_IPC_for_K2x.rst

@@ -562,8 +562,6 @@ So we will need to add the following lines to place the trace buffer and resourc
 	var Resource = xdc.useModule('ti.ipc.remoteproc.Resource');
 	Resource.loadSegment = "L2SRAM"
 
-::
-
 Now follow the steps in `Running the Bundled IPC Examples`_.
 
 

source/linux/Foundational_Components/IPC/_Multiple_Ways_of_ARM-DSP_Communication.rst

@@ -225,7 +225,6 @@ and DSP processors in a multi-processor environment.
   <http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/
   rtos/index_Foundational_Components.html#ipc>`__
 
-|
 .. rubric:: User Cases
    :name: user-cases
 

source/linux/Foundational_Components/Kernel/Kernel_Drivers/Camera/CAL.rst

@@ -200,6 +200,7 @@ properly configure the DPHY.
 .. seealso:: `MIPI CSI-2 Kernel API reference <https://www.kernel.org/doc/Documentation/media/kapi/csi2.rst>`_
 
 As you can see in the above link, typically the pixel rate is calculated as follows:
+
 ::
 
    pixel_rate = link_freq * 2 * nr_of_lanes / bits_per_sample
@@ -210,6 +211,7 @@ therefore sensor dependent. This is also the most accurate method.
 Alternatively, if you trust that your sensor is configured correctly for a
 specific resolution/pixel format and frame interval then the pixel rate can
 be calculated using this simplified formula:
+
 ::
 
    pixel_rate = total horizontal width * total vertical lines * frame per second
@@ -218,6 +220,7 @@ Here total horizontal width and total vertical lines includes blanking.
 This information is also sensor dependent or at least configuration dependent.
 
 For example if we take a look at the ov5640 configuration for 1920x1080\@30 fps:
+
 ::
 
    total horizontal width = 2500
@@ -347,11 +350,11 @@ can be enable as follows:
 -  echo 3 >/sys/class/video4linux/video1/dev\_debug
 
    This allows V4L2 ioctl calls to be logged.
-|
+
 -  echo 3 > /sys/module/videobuf2\_core/parameters/debug
 
    This allows VB2 buffers operation to be logged.
-|
+
 In addition ti-cal also has specific debug log which can be enabled as
 follows:
 

source/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/CPSW-PTP.rst

@@ -676,6 +676,7 @@ PTP with Transparent Clock (Switch mode)
 Use the following ptp config file on the device that acts as the transparent clock:
 
 **tc-ptp.cfg**
+
 ::
 
     [global]

source/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/NetCP.rst

@@ -734,6 +734,7 @@ M / (2^S \* D) = 5000 / (2^10 \* 3)
 hence
 
 M = 5000, S = 10, D = 3
+
 |
 
 Note 3: cpts driver keeps a table of M/S/D for some common frequencies

source/linux/Foundational_Components/Kernel/Kernel_Drivers/PCIe/PCIe_Backplane.rst

@@ -70,7 +70,6 @@ DRA7x boards communicate with each other using J721E as backplane.
    :name: backplane-configuration
 
 .. rubric:: *Backplane DTS Overlay File*
-   :name: backplane-configuration
 
 The following DTS overlay file configures the PCIe controller in EP mode and
 also contains a device tree node to create a NTB function device: