Platform Customization#

LAPTSA_IMP Tool#

LAPTSA-IMP is a host-side tool (Linux, X86_64) to validate that a platform’s chosen display configuration is possible. If it is, LAPTSA-IMP also generates the Device Tree (DT) fragment required to support your chosen display configuration. This DT fragment is used by NVIDIA when building the firmware for your device.

DRAM utilization can vary depending on the characteristics of the request stream, and can also pause for periodic training, refresh, etc. But certain clients and traffic streams have hard bandwidth requirements that the system must satisfy despite the variable overall DRAM utilization. T264, like other SoC chips before it, includes bandwidth guarantee logic at its snap arbiter inputs.

Definitions

IMP - (“Is Mode Possible”) A series of architecture-specific calculations that determine if there is sufficient bandwidth available to support a particular display configuration.
LA - (“Latency Allowance”) Describes how late (measured in ticks) a request from the client is allowed to become, before that request becomes a high priority.
PTSA - (“Priority Tier Snap Arbiter”) This is the portion of Tegra that arbitrates priority among the various MC clients.

The LAPTSA_IMP tool on some chips generates LA/PTSA DT fragment. This fragment has LA and PTSA values calculated for give display configuration. MB2 parses this fragment and sets values to LA and PTSA register. For T264, we use the default/power-on-reset LA and PTSA register values, so the tool does not generate LA/PTSA DT fragment.

Usage#

laptsa-imp <soc> impdt:[qnx|linux] <json-file>

Arguments:

“socs”	(required, case-insensitive) The particular Tegra device to perform calculations for. This should be ‘t264’, but in general LAPTSA-IMP supports every device that is supported by a particular release of DriveOS.
impdt:linux	(required, case-insensitive) A command verb indicating that LAPTSA-IMP should generate an IMPDT fragment, is compatible with Linux operating system.
<json-file>	(required) A local filesystem path to a json file, describing the desired display configuration.

Output:

Output similar to below is generated.

{
  display@8808c00000 {
    static-imp-data {

        /* Window and cursor pool config */
        window-pool-config = <0x292 0x292 0x292 0x292 0x292 0x292 0x292 0x292 0x292 0x292 0x292 0x292 0x292 0x292 0x292 0x292>;
        cursor-pool-config = <0x40 0x40 0x40 0x40 0x40 0x40 0x40 0x40>;

        /* Window and cursor drain meter config */
        window-drain-meter-config = <0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1>;
        cursor-drain-meter-config = <0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1>;

        /* Window and cursor fetch meter config */
        window-fetch-meter-config = <0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1>;
        cursor-fetch-meter-config = <0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1>;

        /* Delay before a START_FETCH command is sent to IsoHub */
        start-fetch-delay-us = <0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0>;

        /* Elv start value */
        elv-start = <0x1 0x1 0x1 0x1 0x1 0x1 0x1 0x1>;

        /* Clock Frequencies */
        hub-clock-khz = <88310>;
        disp-clock-khz = <540000>;
    };
  };
};

LA/PTSA calculations are not yet supported. Use default/power-on values.

The tool is not aware of the max value for dispclk and hubclk, which is supported by the power profile that you are going to use. You must validate that the tool generated hub-clock-khz and disp-clock-khz value are within the power profile limit.

JSON Format

Since display configuration and surface topologies can be quite complex, there are dozens of parameters that you must describe for each display configuration. The LAPTSA-IMP tool expects the user to provide a .JSON file with the following format:

{
    "socs": ["T264"],
    "memory": "LPDDR5_16CH_ECC_2RANK",
    "clocks": {
        "dramclk": 3200,
    }

    "windows": [{...}, {...}],
    "heads": [{...}, {...}]
}

Top-Level Entries

The following table explains the expected top-level parameters within the .JSON file:

“socs”	(required) An array of strings identifying all the SOCs that this .JSON file applies to. One of the strings must match the <soc> parameter given by the user on the command line.
“memory”	(required) A string of the form <TYPE>_<CH>[_ECC]_<RANK> where ‘<TYPE>’ for T234, must be “LPDDR5” ‘<CH>’ should be one of “4CH”, “8CH”, or “16CH” ‘_ECC’ should be present iff ECC is used on the platform ‘<RANK>’ should be one of “1RANK” or “2RANK”
“clocks”	(required) A JSON object listing the following clock information: - “dramclk” : the frequency of the DRAM, expressed in MHz as either an integral or decimal number. (The tool infers mcclk from this value.) - “mchubclk” : the MC hubclk frequency, expressed in MHz as either an integral or decimal number.
“windows”	(required) An array of (for T264) 1 to 4 window descriptor objects. See Windows, below.
“heads”	(required) An array of (for T264) 1 to 2 head description objects. See Heads, below.

Windows#

Within the impdt .JSON input file, the “windows” entry is an array of window descriptor objects, each of which contains the following format:

“wid”	(integer, required) The ID of the HW window that this JSON object is describing. As there are 16 available HW windows in T264, valid window IDs are the integral values between 0 and 15, inclusive. Every window entry within the .JSON file must use a different wid value. On T264, only wid 0, 2, 4 and 6 support scaling.
“input”	(<rect-string>, required) A formatted string that describes the size (and optionally, the position) of the window’s input surface rectangle. See Window, below.
“output”	(<rect-string>, required) A formatted string that describes the size and position of the window’s output region within the controlling head’s active raster. See Window, below.
“color”	(string, required) One of a set of recognized strings that name the color format of the input region. See Window Color Formats, below.
“surface”	(string, required) One of a set of recognized strings that name the surface layout of the window’s input region. See Window Surface Formats, below.
“rotate”	(bool, optional, default=false) Whether or not the input surface needs to be rotated. (For purposes of IMP calculation, the actual direction of rotation does not matter.)

Window <rect-string>

This is the format used by the input and output fields of an impdt window descriptor object. Rect-strings have the form WxH or WxH+X,Y to describe the width, height, and positional origin of a rectangular region. For window input values, a rect-string describes the size and position of some region of the framebuffer that pixel data is fetched from. For window output values, a rect-string describes the size and position of some region within the controlling head’s raster that receives those (possibly color-transformed, rotated, and/or decompressed) pixels.

If the “+X,Y” is omitted, then the positional origin is assumed to be (0,0).
Differences in size between “input” and “output” values for “WxH” imply precomp scaling.

Window Color Formats

T264 (and LAPTSA-IMP) support the following input color formats (case-insensitive):

1BPP_PACKED
2BPP_PACKED
4BPP_PACKED
8BPP_PACKED
422_PACKED
420_PLANAR
444_PLANAR
420_SP
422_SP
422R_SP
444_SP
EXT_420_PLANAR
EXT_444_PLANAR
EXT_420_SP
EXT_422_SP
EXT_422R_SP
EXT_444_SP

Window Surface Formats

T264 (and LAPTSA-IMP) support the following input surface layouts (case insensitive):

PITCH”
BL2 (for BLOCKLINEAR2 format)
BL4 (for BLOCKLINEAR4 format)

Heads

Within the impdt .JSON input file, the heads entry is an array of head descriptor objects, each of which matches the following format:

“hid”	(integer; required) The ID of the HW display head that this JSON object is describing. As there are 8 available HW display heads in T264, valid head IDs are the integral values between 0 and 7, inclusive. Every head entry within the .JSON file must use a different hid value.
“wids”	(array of integers; required) An array of HW window IDs that are bound to this head.
“pclk”	(integral or decimal value; required) This should specify the head’s pixel clock frequency, expressed in Megahertz, and represented as either an integral or a decimal value. For example: If the head’s output mode is expected to be VESA 640x480@60Hz, then the value of “pclk” should be 25.175.
“raster”	(<raster-string>; required) A formatted string that describes the horizontal and vertical timing of this display head. See Head, below.
“cursor”	(bool; optional, default=false) Indicates whether or not an active hardware cursor is assigned to this head.
“dsc”	(bool; optional, default=false) Indicates whether or not DSC is active on this head.
“olut”	(bool; optional, default=false) Indicates whether or not this head’s output lut is being used.

Head <raster-string>

This is the format used by the raster field of an impdt head descriptor object. Raster-Strings have the form WxH+X,Y or WxH+X L:XT,YL:YT to describe the active and blanking regions of the raster.

The following assumes no border:

WxH provides the horizontal (W) and vertical (H) active dimensions.
X L provides the number of leading horizontal blanking pixels (i.e., the pixel-clock ticks taken up by the horizontal sync pulse, and the horizontal back porch).
X T provides the number of trailing horizontal blanking pixels (i.e., the pixel-clock ticks taken up by the horizontal front porch).
If only X is given (providing the total number of horizontal blanking pixels), then XT is defaulted to X/2, and X L is defaulted to X-XT.
Y L provides the number of leading vertical blanking lines (i.e., vertical sync pulse, and the vertical back porch).
Y T provides the number of trailing vertical blanking lines (i.e., the vertical front porch).
If only Y is given (providing the total number of vertical blanking lines), then Y T is defaulted to Y/2, and Y L is defaulted to Y-YT.