[FlareCoding]

Summary

With the chosen output's link found and its DisplayPort facts read, bring-up trains the link at the lowest configuration that carries the chosen mode, as NVIDIA's DisplayPort library chooses it, and then makes its own check of the training against the link status the monitor and each PHY repeater (a retimer between the GPU and the monitor) report.

Changes

• Trains the link at the lowest configuration carrying the mode: set_up_output_link (display_link.h, display_link.cpp) takes from displayport::find_lowest_configuration the lowest link configuration that carries the mode under the output's link facts, its connector's, its monitor's and the resource's, and train_link sends NVIDIA's DP_CTRL (re-declared in rm.h) setting the lane count and the rate, enhanced framing when the link runs it and PHY repeater training, as NVIDIA's library sets them. It trains each PHY repeater before the monitor when the resource's facts say the firmware trains them and the output's count of repeaters matches the one phy_repeater_count reads from the monitor's DPCD, as NVIDIA's library counts them, and the monitor alone otherwise.
• Leaves out the PHY repeaters the firmware does not train: when the resource's DisplayPort facts say the firmware trains none, set_up_output_link gives the configuration's search, the training and the check a copy of the DPCD without them, as NVIDIA's library then reads none.
• Waits as an accepted training reply asks: train_link spins for the wait an accepted reply names, as NVIDIA's library waits after any reply, on the calling CPU since bring-up may run on a thread that cannot sleep.
• Checks the training: read_link_status reads the lane status and alignment bytes from the monitor's link status indicators, or from its link status field when its DPCD revision or the GPU is below DisplayPort 1.2, and ANDs in each PHY repeater's, and set_up_output_link logs whether the link's lanes are all trained, a link they show untrained counting as not set up.
• Bring-up stops the link at the first step that fails: a refusal, or a mode no configuration carries, logs one error line naming the steps it skips ("so the link's DisplayPort facts are not read and the link is not trained", "so the link is not trained", "so its link is not checked"). Bring-up then logs that the link is not set up and takes the display engine down before the mode set's end, the set-up returning OK; a request failing other than by display common's refusal, such as one whose reply never arrives, fails the set-up after the take-down and the end.
• Departure, a refused training: a refused DP_CTRL stops the link, where NVIDIA's library sends it again after the wait its reply names, up to 3 times, since firmware::control gives no refused request's reply.
• Departure, the granted adjustment: POST_LT_ADJ_REQ_GRANTED is never sent, where NVIDIA's library sends it to a monitor granting it; the card's monitor does not grant it.
• Departure, a refused repeater training: a refused PHY repeater training stops the link, where NVIDIA's library trains again in transparent mode; the card's link has no PHY repeaters.
• Departure, the status field: the status bytes come from the link status indicators on every monitor of DPCD 1.2 or later with a GPU supporting 1.2, where NVIDIA's library reads the link status field for an eDP 1.4 or 1.4a panel and for a monitor whose revision its workaround lowers to 1.1.
• Departure, no fallback: a failed training stops the link, where NVIDIA's library tries other configurations.
• Departure, always the lowest configuration: the link trains at the lowest configuration carrying the mode in every case, where NVIDIA's library trains at another for a preferred configuration its caller sets, for a device with the forceMaxLinkConfig quirk and for a protocol converter, so a quirked panel or a DisplayPort to HDMI adapter trains at the lowest.
• Departure, PHY repeaters the chip table leaves out: on a chip whose table says the firmware trains no PHY repeaters, the monitor's DPCD is read before the mode set without the repeaters' capabilities, so the link counts none and the monitor alone is trained and checked even when the resource's facts say the firmware trains them, where NVIDIA's library reads the repeaters whenever those facts say so.
• Departure, the check's timing: the training check reads the status bytes at once after training, where NVIDIA's library reads them after an interrupt.
• Card: on the RTX 3080 driving an IOC 25G2S monitor over DisplayPort at 2560 by 1440 at 60 Hz, runs land-link-r3f-c2-a1 (QEMU's display as the boot display, no head active) and land-link-r3f-c2-b1 (the card's own boot display, its head stopped by the shutdown update first), boots of db6d3564, an earlier version whose kernel, stripped of debug information, is byte-identical to this commit's, logged nvidia: display common trained display id 0x100's link at 1 lane at DisplayPort rate 0x1E (command 0x2083, 0 PHY repeaters trained first) and nvidia: display id 0x100's link status reads 0x07 0x00 0x01, so its 1 lane is trained between the mode set's start and end, with no take-down, then ended bring-up with the driver attached, with 0 IOMMU or PCIe faults on the host. No head drives the trained link before the driver lights an output of its own, so the monitor shows no picture; the screen was not captured.
• Tests: nvidia_display_link checks the training request with NVIDIA's command, each lane count in its data's low bits, each PHY repeater trained from the GPU's side before the monitor, each request zeroed but for what it sends though the one before left its frame dirty, only the monitor trained unless the firmware counts the repeaters, a refused training sent once and logged with its lanes, rate, command and data, an accepted reply's wait timed against the kernel's clock, the repeaters counted as NVIDIA counts them, an error other than a refusal passed on for the training and the status read, the status read with each repeater's bytes ANDed in, the monitor's own field below DisplayPort 1.2, and a refused status read giving no status. nvidia_display_engine checks that a set-up trains the chosen output's link after reading its facts and then reads its status, once each, logging both; that the training follows the resource's DisplayPort facts where they differ from the chip table's (2 lanes at HBR2 under a lower highest rate, no configuration and no training under the lowest, no PHY repeater training when the firmware trains none, a repeater read under a chip table saying the firmware trains them left out of the configuration, the training and the check when the facts say it trains none, the monitor's own status field without DisplayPort 1.2); that under a chip table saying the firmware trains no PHY repeaters a repeater between the GPU and the monitor is not read, and the monitor alone is trained, with the repeater bit, and checked; that refused DisplayPort facts leave the link untrained, a refused training leaves its status unread and a training whose reply never arrives fails the set-up; that a status showing the link untrained is logged as such at 1 lane, with the engine taken down before the mode set's end, and at 2; and that a refused status read logs its line and no status line.

[cursor]

Current version of PR was reviewed by /review-bugbot with additional instructions on Oct 29, 14:11. It flagged 0 findings.

^{Bugbot on commit fcda430 is skipped.}