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/_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/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/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/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

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:

source/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/pru-icssg-pwm.rst

@@ -36,16 +36,16 @@ The PRU PWM Linux kernel driver depends on the PRU-ICSS kernel driver. So
 the following kernel Kconfig options should be enabled to use the PRU PWM
 module.
 
-.. code::
+.. code-block:: menuconfig
 
-  Device Drivers  --->
-  	SOC (System On Chip) specific Drivers  --->
-		[*] TI SOC drivers support  --->
-			<M>   TI PRU-ICSS Subsystem Platform drivers
+   Device Drivers  --->
+      SOC (System On Chip) specific Drivers  --->
+         [*] TI SOC drivers support  --->
+            <M> TI PRU-ICSS Subsystem Platform drivers
 
-  Device Drivers  --->
-  	Pulse-Width Modulation (PWM) Support  --->
-		PRU-ICSS PWM support
+   Device Drivers  --->
+      Pulse-Width Modulation (PWM) Support  --->
+         PRU-ICSS PWM support
 
 
 .. rubric:: PRU PWM Sysfs Usage

source/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/pru-sw-uart.rst

@@ -42,16 +42,16 @@ in PRU R30 and R31.
 
 For details please refer to the kernel device tree binding doc:
 
-.. code::
+.. code-block:: text
 
-    Documentation/devicetree/bindings/serial/pru-suart.txt
+   Documentation/devicetree/bindings/serial/pru-suart.txt
 
 The Processor SDK Linux kernel also provides an device tree example for
 Beaglebone Black:
 
-.. code::
+.. code-block:: text
 
-    arch/arm/boot/dts/am335x-boneblack-prusuart.dts
+   arch/arm/boot/dts/am335x-boneblack-prusuart.dts
 
 This example defines the 3 UARTs on PRU0 without hardware flow control and 3
 UARTs on PRU1 with hardware flow control. All the UART pins are available on
@@ -64,16 +64,16 @@ The PRU Soft UART Linux kernel driver depends on the PRU-ICSS kernel driver. So
 the following kernel Kconfig options should be enabled to use the PRU Soft UART
 module.
 
-.. code::
+.. code-block:: menuconfig
 
-  Device Drivers  --->
-  	SOC (System On Chip) specific Drivers  --->
-		[*] TI SOC drivers support  --->
-			<M>   TI PRU-ICSS Subsystem Platform drivers
+   Device Drivers  --->
+      SOC (System On Chip) specific Drivers  --->
+         [*] TI SOC drivers support  --->
+            <M> TI PRU-ICSS Subsystem Platform drivers
 
-  Device Drivers  --->
-  	Character devices  --->
-		Serial drivers  --->
-			<M> TI PRU Software UART suppor
+   Device Drivers  --->
+      Character devices  --->
+         Serial drivers  --->
+            <M> TI PRU Software UART suppor
 
 

source/linux/Foundational_Components/PRU-ICSS/Linux_Drivers/pruss-uart.rst

@@ -30,45 +30,45 @@ The PRUSS UART Linux kernel driver depends on the PRU-ICSS kernel drivers. So
 the following kernel Kconfig options should be enabled to use the PRUSS UART
 module.
 
-.. code::
+.. code-block:: menuconfig
 
-  Device Drivers  --->
-	SOC (System On Chip) specific Drivers  --->
-		[*] TI SOC drivers support  --->
-			<M>   TI PRU-ICSS Subsystem Platform drivers
+   Device Drivers  --->
+      SOC (System On Chip) specific Drivers  --->
+         [*] TI SOC drivers support  --->
+            <M> TI PRU-ICSS Subsystem Platform drivers
 
-  Device Drivers  --->
-	IRQ chip support  --->
-		<M>   TI PRU-ICSS Interrupt Controller
+   Device Drivers  --->
+      IRQ chip support  --->
+         <M> TI PRU-ICSS Interrupt Controller
 
-  Device Drivers  --->
-	Character devices  --->
-		Serial drivers  --->
-			<M> TI PRU-ICSS UART support
+   Device Drivers  --->
+      Character devices  --->
+         Serial drivers  --->
+            <M> TI PRU-ICSS UART support
 
 
 .. rubric:: Example DT configuration
 
 From am335x-evmsk.dts
 
-.. code::
+.. code-block:: dts
 
-    &pruss_uart {
-	    prus = <&pru0>;
-	    ti,pru-interrupt-map = <0 6 2 2>;
-	    pinctrl-names = "default";
-	    pinctrl-0 = <&prussuart_pins>;
-	    status = "okay";
-    };
+   &pruss_uart {
+      prus = <&pru0>;
+      ti,pru-interrupt-map = <0 6 2 2>;
+      pinctrl-names = "default";
+      pinctrl-0 = <&prussuart_pins>;
+      status = "okay";
+   };
 
 
 .. rubric:: Driver Usage
 
 Once the driver is probed, kernel log shows the following message.
 
-.. code::
+.. code-block:: dmesg
 
-    [   28.617700] 4a328000.serial: ttyS1 at MMIO 0x4a328000 (irq = 77, base_baud = 12000000) is a 16550A
+   [   28.617700] 4a328000.serial: ttyS1 at MMIO 0x4a328000 (irq = 77, base_baud = 12000000) is a 16550A
 
 Therefore the device node /dev/ttyS1 is associated to the PRUSS UART, user
 space application can read/write this serial port. For detalls please refer