- 16 Jun, 2017 40 commits
-
-
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 <bskeggs@redhat.com>
-
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 <bskeggs@redhat.com>
-
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 <bskeggs@redhat.com>
-
Ben Skeggs authored
Saves some trips across the aux channel. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
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 <bskeggs@redhat.com>
-
Ben Skeggs authored
We care about this information outside of link training. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
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 <bskeggs@redhat.com>
-
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 <bskeggs@redhat.com>
-
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 <bskeggs@redhat.com>
-
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 <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
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 <bskeggs@redhat.com>
-
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 <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
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 <bskeggs@redhat.com>
-
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 <bskeggs@redhat.com>
-
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 <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
This will ensure unspecified args are easily identified. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
As of DCB 4.1, these are not the same thing. Compatibility temporarily in place until callers have been updated. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
No (known) case yet, but other tables have been moving beyond 16-bits, so we may as well be prepared. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Compatibility temporarily in place until all callers have been updated. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
We already have a subdev pointer, from which we can locate the device's BIOS subdev. No need for a separate pointer. Structure/callers not updated yet, as I want to batch more changes and only touch the callers once. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
nvkm_timer_alarm() already handles this as part of protecting against callers passing in no timeout value. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Karol Herbst authored
I only saw those values inside the vbios: 0xff, 0xfd, 0xfc, 0xfa for valid rails. No idea what the lower value does, but at least we get power readings on a lot of Fermi GPUs with that. v2: add missing parentheses Signed-off-by:
Karol Herbst <karolherbst@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Karol Herbst authored
This is according to what we have in nvbios. Fixes "ERROR: Can't get value of subfeature in0_min: Can't read" errors in sensors for some GPUs. Signed-off-by:
Karol Herbst <karolherbst@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alastair Bridgewater authored
Enable stereoscopic output for HDMI and DisplayPort connectors on NV50+ (G80+) hardware. We do not enable stereoscopy on older hardware in case there is some older board that still has HDMI output but for which we have no logic for setting the Vendor InfoFrame. With this, I get an obvious 3D output when using the "testdisplay" program from intel-gpu-tools with the "-3" parameter and outputting to a 3D-capable HDMI display, for all available 3D modes (be they TB, SBSH, or FP) on all four G80+ DISPs. Signed-off-by:
Alastair Bridgewater <alastair.bridgewater@gmail.com>
-
Alastair Bridgewater authored
Frame-packing modes add an extra vtotal raster lines to each frame above and beyond what the basic mode description calls for. Account for this during scaler configuration (possibly a bit of a hack), during CRTC configuration (clearly not a hack), and when checking that a mode is valid for a given connector (cribbed from the i915 driver). Signed-off-by:
Alastair Bridgewater <alastair.bridgewater@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alastair Bridgewater authored
Now that we have the InfoFrame data being provided, for the most part, program the hardware to use it. While we're here, and since the functionality will come in handy for supporting 3D stereoscopy, implement setting the Vendor ("generic"?) InfoFrame. Also don't enable any InfoFrame that is not provided, and disable the Vendor InfoFrame when disabling the output. Signed-off-by:
Alastair Bridgewater <alastair.bridgewater@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alastair Bridgewater authored
Now that we have the InfoFrame data being provided, for the most part, program the hardware to use it. While we're here, and since the functionality will come in handy for supporting 3D stereoscopy, implement setting the Vendor ("generic"?) InfoFrame. Also don't enable any InfoFrame that is not provided, and disable the Vendor InfoFrame when disabling the output. Signed-off-by:
Alastair Bridgewater <alastair.bridgewater@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alastair Bridgewater authored
Now that we have the InfoFrame data being provided, for the most part, program the hardware to use it. While we're here, and since the functionality will come in handy for supporting 3D stereoscopy, implement setting the Vendor ("generic") InfoFrame. Also don't enable any AVI or Vendor InfoFrame that is not provided, and disable the Vendor InfoFrame when disabling the output. Ignore the Audio InfoFrame: We don't supply it, and altering HDMI audio semantics (for better or worse) on this hardware is out of scope for me at this time. Signed-off-by:
Alastair Bridgewater <alastair.bridgewater@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alastair Bridgewater authored
Now that we have the InfoFrame data being provided, for the most part, program the hardware to use it. While we're here, and since the functionality will come in handy for supporting 3D stereoscopy, implement setting the Vendor ("generic"?) InfoFrame. Also don't enable any AVI or Vendor InfoFrame that is not provided, and disable the Vendor InfoFrame when disabling the output. Ignore the Audio InfoFrame: We don't supply it, and altering HDMI audio semantics (for better or worse) on this hardware is out of scope for me at this time. Signed-off-by:
Alastair Bridgewater <alastair.bridgewater@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alastair Bridgewater authored
HDMI InfoFrames are passed to NVKM as bags of bytes, but the hardware needs them to be packed into words. Rather than having four (or more) copies of the packing logic introduce a single copy now, in a central place. We currently need these for AVI and Vendor InfoFrames, but we may also expect to need them for Audio InfoFrames at some point. Signed-off-by:
Alastair Bridgewater <alastair.bridgewater@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alastair Bridgewater authored
Now that we have mechanism by which to pass mode-dependent HDMI InfoFrames to the low-level hardware driver, it is incumbent upon us to do so. Signed-off-by:
Alastair Bridgewater <alastair.bridgewater@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alastair Bridgewater authored
The nouveau driver, in the Linux 3.7 days, used to try and set the AVI InfoFrame based on the selected display mode. These days, it uses a fixed set of InfoFrames. Start to correct that, by providing a mechanism whereby InfoFrame data may be passed to the NVKM functions that do the actual configuration. At this point, only establish the new parameters and their parsing, don't actually use the data anywhere yet (since it's not supplied anywhere). Signed-off-by:
Alastair Bridgewater <alastair.bridgewater@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Alastair Bridgewater authored
drm_mode_set_crtcinfo() does compensation for interlace and doublescan timing effects already, so do it first and use the compensated figures instead of the constant "vscan / ilace" terms that we had before. And then it turns out that the hardware model for how the timing parameters are configured is basically the standard model, but starting one clock before the sync pulse rather than at the start of the display area, which lets us drastically simplify the overall timing calculations (verifying the changes by algebraic operations is left as an exercise for the reader). Finally, there were a couple of issues with the computation of m->v.blankus that are addressed here. Interlaced modes would generate a negative intermediate result. Double scan modes would generate an overestimate rather than an underestimate. And when enabling frame-packing modes, a rather extreme overestimate would be generated. Fixed, by using the timings as adjusted for the CRTC to find the length of the vertical blanking period instead of mixing adjusted and pre-adjustment timing parameters. Signed-off-by:
Alastair Bridgewater <alastair.bridgewater@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-