summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2017-06-16drm/nouveau/disp/dp: use new devinit script interpreter entry-pointBen Skeggs1-38/+30
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/dp: determine link bandwidth requirements from head stateBen Skeggs7-2/+62
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 <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp: introduce acquire/release display path methodsBen Skeggs16-40/+287
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 <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp: remove hw-specific customisation of output pathsBen Skeggs28-342/+36
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 <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/gf119-: port OR DP VCPI control to nvkm_iorBen Skeggs7-14/+16
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/gt215-: port HDA ELD controls to nvkm_iorBen Skeggs20-136/+161
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/g94-: port OR DP drive setting control to nvkm_iorBen Skeggs12-143/+66
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/g94-: port OR DP training pattern control to nvkm_iorBen Skeggs12-30/+27
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/g94-: port OR DP link power control to nvkm_iorBen Skeggs12-43/+17
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/g94-: port OR DP link setup to nvkm_iorBen Skeggs12-30/+47
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/g94-: port OR DP lane mapping to nvkm_iorBen Skeggs9-9/+30
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/g84-: port OR HDMI control to nvkm_iorBen Skeggs29-219/+134
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/nv50-: port OR manual sink detection to nvkm_iorBen Skeggs17-80/+40
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/nv50-: port OR power state control to nvkm_iorBen Skeggs32-257/+108
Also removes the user-facing methods to these controls, as they're not currently utilised by the DD anyway. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/nv50-: fetch head/OR state at beginning of supervisorBen Skeggs17-0/+165
This data will be used by essentially every part of the supervisor handling process. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/nv50-: execute supervisor on its own workqueueBen Skeggs3-3/+10
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/dp: train link only when actively displaying an imageBen Skeggs2-10/+6
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>
2017-06-16drm/nouveau/disp/dp: only check for re-train when the link is activeBen Skeggs4-45/+13
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>
2017-06-16drm/nouveau/disp/dp: determine a failsafe link training rateBen Skeggs1-19/+35
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>
2017-06-16drm/nouveau/disp/dp: use cached link configuration when checking link statusBen Skeggs1-22/+17
Saves some trips across the aux channel. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/dp: no need for lt_state except during manual link trainingBen Skeggs1-31/+24
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>
2017-06-16drm/nouveau/disp/dp: store current link configuration in nvkm_iorBen Skeggs2-33/+41
We care about this information outside of link training. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp/dp: remove DP_PWR methodBen Skeggs2-31/+0
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>
2017-06-16drm/nouveau/disp: identity-map display paths to output resourcesBen Skeggs4-8/+89
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>
2017-06-16drm/nouveau/disp: fork off some new hw-specific implementationsBen Skeggs20-13/+336
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>
2017-06-16drm/nouveau/disp: introduce input/output resource abstractionBen Skeggs25-8/+262
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>
2017-06-16drm/nouveau/disp: common implementation of scanoutpos method in nvkm_headBen Skeggs21-150/+161
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp: move vblank_{get,put} methods into nvkm_headBen Skeggs20-99/+60
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp: introduce object to track per-head functions/stateBen Skeggs29-88/+351
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>
2017-06-16drm/nouveau/disp: delay output path / connector construction until oneinit()Ben Skeggs2-69/+69
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>
2017-06-16drm/nouveau/disp: s/nvkm_connector/nvkm_conn/Ben Skeggs5-31/+31
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/disp: rename nvkm_output_dp to nvkm_dpBen Skeggs3-188/+181
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>
2017-06-16drm/nouveau/disp: rename nvkm_output to nvkm_outpBen Skeggs5-38/+42
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>
2017-06-16drm/nouveau/disp: shuffle functions aroundBen Skeggs33-1243/+1183
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>
2017-06-16drm/nouveau/kms/nv04: use new devinit script interpreter entry-pointBen Skeggs1-12/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/fb/ram/nv40-: use new devinit script interpreter entry-pointBen Skeggs3-22/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/devinit: use new devinit script interpreter entry-pointBen Skeggs2-30/+11
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/bios/init: add a new devinit script interpreter entry-pointBen Skeggs1-0/+13
This will ensure unspecified args are easily identified. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/bios/init: add or/link args separate from output pathBen Skeggs2-4/+12
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>
2017-06-16drm/nouveau/bios/init: bump script offset to 32-bitsBen Skeggs2-4/+4
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>
2017-06-16drm/nouveau/bios/init: rename 'crtc' to 'head'Ben Skeggs2-14/+18
Compatibility temporarily in place until all callers have been updated. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/bios/init: remove internal use of nvbios_init.biosBen Skeggs1-82/+84
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>
2017-06-16drm/nouveau/bios/init: rename nvbios_init() to nvbios_devinit()Ben Skeggs3-3/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-16drm/nouveau/tmr: remove nvkm_timer_alarm_cancel()Ben Skeggs6-15/+5
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>
2017-06-16drm/nouveau/bios/iccsense: rails for power sensors have a mask of 0xf8 for ↵Karol Herbst1-1/+4
version 0x10 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>
2017-06-16drm/nouveau/bios/volt: Parse min and max for Version 0x40Karol Herbst1-3/+3
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>
2017-06-16drm/nouveau: Enable stereoscopic 3D output over HDMIAlastair Bridgewater1-0/+7
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>
2017-06-16drm/nouveau: Handle frame-packing mode geometry and timing effectsAlastair Bridgewater2-7/+17
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>
2017-06-16drm/nouveau/disp/gk104-: Use supplied HDMI InfoFramesAlastair Bridgewater1-6/+30
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>
2017-06-16drm/nouveau/disp/gf119: Use supplied HDMI InfoFramesAlastair Bridgewater1-6/+34
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-06 18:49:00 +0000