linux/drivers/gpu/vga, branch v3.17

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

2014-09-20T17:10:14Z

Pull drm fixes from Dave Airlie: "A bunch of radeon fixes for oops on module unload, and problems with resetting the dma engine, one nouveau fix for black boxes in rendering on my mbp retina, one sti fix, and a couple of intel fixes" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/nouveau: ltc/gf100-: fix cbc issues on certain boards drm/bochs: add missing drm_connector_register call drm/cirrus: add missing drm_connector_register call drm/radeon: Fix typo 'addr' -> 'entry' in rs400_gart_set_page drm/nouveau/runpm: fix module unload drm/radeon/px: fix module unload vgaswitcheroo: add vga_switcheroo_fini_domain_pm_ops drm/radeon: don't reset dma on r6xx-evergreen init drm/radeon: don't reset sdma on CIK init drm/radeon: don't reset dma on NI/SI init drm/radeon/dpm: fix resume on mullins drm/radeon: Disable HDP flush before every CS again for < r600 drm/radeon: delete unused PTE_* defines drm/i915: Add limited color range readout for HDMI/DP ports on g4x/vlv/chv drm: sti: do not iterate over the info frame array drm/i915: Fix SRC_COPY width on 830/845g

vgaswitcheroo: add vga_switcheroo_fini_domain_pm_ops

2014-09-18T23:21:20Z

Drivers should call this on unload to unregister pmops. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=84431 Reviewed-by: Ben Skeggs Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Pali Rohár Cc: Ben Skeggs

vgaarb: Drop obsolete #ifndef

2014-09-16T21:02:55Z

Commit 20cde694027e ("x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()") moved boot video device detection from efifb to x86 and ia64 pci/fixup.c. Remove the left-over #ifndef check that will always match since the corresponding arch-specific define is gone with above patch. Signed-off-by: Bruno Prémont Signed-off-by: Bjorn Helgaas CC: Matthew Garrett

vgaarb: Don't default exclusively to first video device with mem+io

2014-09-16T19:06:18Z

Commit 20cde694027e ("x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()") moved boot video device detection from efifb to x86 and ia64 pci/fixup.c. For dual-GPU Apple computers above change represents a regression as code in efifb did forcefully override vga_default_device while the merge did not (vgaarb happens prior to PCI fixup). To improve on initial device selection by vgaarb (it cannot know if PCI device not behind bridges see/decode legacy VGA I/O or not), move the screen_info based check from pci_video_fixup() to vgaarb's init function and use it to refine/override decision taken while adding the individual PCI VGA devices. This way PCI fixup has no reason to adjust vga_default_device anymore but can depend on its value for flagging shadowed VBIOS. This has the nice benefit of removing duplicated code but does introduce a #if defined() block in vgaarb. Not all architectures have screen_info and would cause compile to fail without it. Link: https://bugzilla.kernel.org/show_bug.cgi?id=84461 Reported-and-Tested-By: Andreas Noever Signed-off-by: Bruno Prémont Signed-off-by: Bjorn Helgaas CC: Matthew Garrett CC: stable@vger.kernel.org # v3.5+

vgaarb: We can own non-decoded resources

2014-07-08T01:15:09Z

The VGA arbiter does not allow devices to "own" resources that it doesn't "decode". However, it does allow devices to "lock" resources that it doesn't decode. This gets us into trouble because locking the resource goes through the same bridge routing updates regardless of whether we decode the resource. This means that when a non-decoded resource is released, the bridge is left with VGA routing enabled and locking a different device won't clear it. This happens in the following scenario: VGA device 01:00.0 (VGA1) is owned by the radeon driver, which registers a set_vga_decode function which releases legacy VGA decodes. VGA device 02:00.0 (VGA2) is any VGA device. VGA1 user locks VGA resources triggering first_use callback of set_vga_decoded, clearing "decode" and "owns" of legacy resources on VGA1. VGA1 user unlocks VGA resources. VGA2 user locks VGA resources, which skips VGA1 as conflicting as it does not "own" legacy resources, although VGA routing is still enabled for the VGA1 bridge. VGA routing is enabled on VGA2 bridge. VGA2 may or may not receive VGA transactions depending on the bus priority of VGA1 vs VGA2 bridge. To resolve this, we need to allow devices to "own" resources that they do not "decode". This way we can track bus ownership of VGA. When a device decodes VGA, it only means that we must update the command bits in cases where the conflicting device is on the same bus. Signed-off-by: Alex Williamson Cc: Ville Syrjälä Cc: Daniel Vetter Cc: Dave Airlie Signed-off-by: Dave Airlie

vgaswitcheroo: switch the mux to the igp on power down when runpm is enabled

2014-06-02T14:25:08Z

Avoids blank screens on muxed systems when runpm is active. bug: https://bugs.freedesktop.org/show_bug.cgi?id=75917 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org

vgaarb: Fix VGA decodes changes

2013-09-03T17:17:59Z

When VGA decodes change we need to do a bit more evaluation of exactly what has changed. We don't necessarily give up all the old owns resources and we need to account for resources with locks. The new algorithm is: If something is added, update decodes. If legacy resources were added and none were there before, we have a new participant. If something is removed, update decodes. If we previously owned it, we no longer own it. If it was previously locked, invalidate all locks and release it. If legacy resources were removed and none are left, remove the participant from VGA arbitration. Previously we updated decodes, released ownership of everything that was previously decoded, ignored all locks, and went off looking for another device to transfer VGA to. In a test case where Intel IGD removes only legacy VGA memory decoding, this left the arbiter switching to discrete graphics without actually disabling legacy VGA IO from the IGD. As a bonus, we bumped up the count of VGA arbitration participants for no good reason. Signed-off-by: Alex Williamson Cc: Dave Airlie Acked-by: Dave Airlie Reviewed-by: Ville Syrjälä [danvet: Kill now unused variables, reported by the 0-day kernel builtbot.] Signed-off-by: Daniel Vetter

vgaarb: Don't disable resources that are not owned

2013-09-03T17:17:58Z

If a device does not own a resource then we don't need to disable it. This resolves the case where an Intel IGD device can be configured to disable decode of VGA memory but we still need the arbiter to handle VGA I/O port routing. When the IGD device is in conflict, only PCI_COMMAND_IO should be disabled since VGA memory does not require arbitration on this device. Signed-off-by: Alex Williamson Cc: Dave Airlie Acked-by: Dave Airlie Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter

gpu/vga_switcheroo: add driver control power feature. (v3)

2013-08-29T03:30:21Z

For optimus and powerxpress muxless we really want the GPU driver deciding when to power up/down the GPU, not userspace. This adds the ability for a driver to dynamically power up/down the GPU and remove the switcheroo from controlling it, the switcheroo reports the dynamic state to userspace also. It also adds 2 power domains, one for machine where the power switch is controlled outside the GPU D3 state, so the powerdown ordering is done correctly, and the second for the hdmi audio device to make sure it can resume for PCI config space accesses. v1.1: fix build with switcheroo off v2: add power domain support for radeon and v1 nvidia dsms v2.1: fix typo in off case v3: add audio power domain for hdmi audio + misc audio fixes v4: use PCI_SLOT macro, drop power reference on hdmi audio resume failure also. Signed-off-by: Dave Airlie

fbcon: fix locking harder

2013-02-08T02:02:43Z

Okay so Alan's patch handled the case where there was no registered fbcon, however the other path entered in set_con2fb_map pit. In there we called fbcon_takeover, but we also took the console lock in a couple of places. So push the console lock out to the callers of set_con2fb_map, this means fbmem and switcheroo needed to take the lock around the fb notifier entry points that lead to this. This should fix the efifb regression seen by Maarten. Tested-by: Maarten Lankhorst Tested-by: Lu Hua Signed-off-by: Dave Airlie