- 16 Jun, 2017 40 commits
-
-
Ben Skeggs authored
This makes use of all the additional routing and state added in previous commits, making it possible to deal with GM20x macro link routing, while also sharing code between the NV50 and GF119 implementations. Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This makes use of all the additional routing and state added in previous commits, making it possible to deal with GM20x macro link routing, while also sharing code between the NV50 and GF119 implementations. Signed-off-by: -
Ben Skeggs authored
This makes use of all the additional routing and state added in previous commits, making it possible to deal with GM20x macro link routing, while also sharing code between the NV50 and GF119 implementations. Signed-off-by: -
Ben Skeggs authored
This makes use of all the additional routing and state added in previous commits, making it possible to deal with GM20x macro link routing, while also sharing code between the NV50 and GF119 implementations. Signed-off-by: -
Ben Skeggs authored
This shouldn't have been needed ever since we started executing the DisableLT script when shutting down heads. Testing of the board this was originally written for seems to agree. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Training/Untraining will be hooked up to the routing logic, which doesn't allow us to pass in a data rate. Signed-off-by: -
Ben Skeggs authored
These exist to give NVKM information on the set of display paths that the DD needs to be active at any given time. Previously, the supervisor attempted to determine this solely from OR state, but there's a few configurations where this information on its own isn't enough to determine the specific display paths in question: - ANX9805, where the PIOR protocol for both DP and TMDS is TMDS. - On a device using DCB Switched Outputs. - On GM20x and newer, with a crossbar between the SOR and macro links. After this commit, the DD tells NVKM *exactly* which display path it's attempting a modeset on. Signed-off-by: -
Ben Skeggs authored
All of the necessary hw-specific logic is now handled at the output resource level, so all of this can go away. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Also removes the user-facing methods to these controls, as they're not currently utilised by the DD anyway. Signed-off-by: -
Ben Skeggs authored
This data will be used by essentially every part of the supervisor handling process. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This essentially (unless the link becomes unstable and needs to be re-trained) gives us a single entry-point to link training, during supervisor handling, where we can ensure all routing is up to date. Signed-off-by: -
Ben Skeggs authored
An upcoming commit will limit link training to only when the sink is meant to be displaying an image. We still need IRQs enabled even when the link isn't trained (for MST messages), but don't want to train the link unnecessarily. Signed-off-by: -
Ben Skeggs authored
The aim here is to protect the OR against locking up when something unexpected happens (such as the display disappearing during modeset, or the DD misbehaving). Signed-off-by: -
Ben Skeggs authored
Saves some trips across the aux channel. Signed-off-by: -
Ben Skeggs authored
This struct doesn't hold link configuration data anymore, so we can limit its use to internal DP training (anx9805 handles training for external DP). Signed-off-by: -
Ben Skeggs authored
We care about this information outside of link training. Signed-off-by: -
Ben Skeggs authored
This hasn't been used since atomic. We may want to re-implement "fast" DPMS at some point, but for now, this just gets in the way. Signed-off-by: -
Ben Skeggs authored
This essentially replicates our current behaviour in a way that's compatible with the new model that's emerging, so that we're able to start porting the hw-specific functions to it. Signed-off-by: -
Ben Skeggs authored
Upcoming commits make supervisor handling share code between the NV50 and GF119 implementations. Because of this, and a few other cleanups, we need to allow some additional customisation. Signed-off-by: -
Ben Skeggs authored
In order to properly support the SOR -> SOR + pad macro separation that occurred with GM20x GPUs, we need to separate OR handling out of the output path code. This will be used as the base to support ORs (DAC, SOR, PIOR). Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Primarily intended as a way to pass per-head state around during supervisor handling, and share logic between NV50/GF119. Signed-off-by: -
Ben Skeggs authored
This is to allow hw-specific code to instantiate output resources first, so we can cull unsupported output paths based on them. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Not all users of nvkm_output_dp have been changed here. The remaining ones belong to code that's disappearing in upcoming commits. This also modifies the debug level of some messages. Signed-off-by: -
Ben Skeggs authored
This isn't technically "output", but, "display/output path". Not all users of nvkm_output have been changed here. The remaining ones belong to code that's disappearing in upcoming commits. Signed-off-by: -
Ben Skeggs authored
Upcoming changes to split OR from output path drastically change the placement of various operations. In order to make the real changes clearer, do the moving around part ahead of time. Signed-off-by: -
Ben Skeggs authored
Signed-off-by:
-
