lwn.git/drivers/gpu/drm/radeon/radeon_device.c, branch v3.9.9

drm/radeon: fix card_posted check for newer asics

2013-06-07T19:53:03+00:00

commit 09fb8bd1a63b0f9f15e655c4fe8d047e5d2bf67a upstream. Newer asics have variable numbers of crtcs. Use that rather than the asic family to determine which crtcs to check. This avoids checking non-existent crtcs or missing crtcs on certain asics. Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

Merge branch 'drm-next-3.9' of git://people.freedesktop.org/~agd5f/linux into drm-next

2013-02-20T21:15:16+00:00

More drm-next bits for radeon. Just bug fixes. * 'drm-next-3.9' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: properly validate the atpx interface drm/radeon: switch get_gpu_clock() to a callback (v2) drm/radeon: add a asic callback to get the xclk drm/radeon: Avoid NULL pointer dereference from atom_index_iio() allocation failure drm/radeon: remove overzealous warning in hdmi handling drm/radeon: fix multi-head power profile stability on BTC+ asics

drm/radeon: Avoid NULL pointer dereference from atom_index_iio() allocation failure

2013-02-20T13:51:19+00:00

Smatch anlysis: drivers/gpu/drm/radeon/atom.c:1242 atom_index_iio() error: potential null dereference 'ctx->iio'. (kzalloc returns null) Also cleaned up some checks before calls to kfree(). kfree(NULL) is OK. Cc: David Airlie Cc: Alex Deucher Cc: "Michel Dänzer" Cc: Dave Airlie Cc: "Christian König" Cc: Jerome Glisse Cc: dri-devel@lists.freedesktop.org Signed-off-by: Tim Gardner Signed-off-by: Alex Deucher

Merge branch 'drm-next-3.9' of git://people.freedesktop.org/~agd5f/linux into drm-next

2013-02-08T03:27:28+00:00

Alex writes: - CS ioctl cleanup and unification. Unification of a lot of functionality that was duplicated across multiple generates of hardware. - Add support for Oland GPUs - Deprecate UMS support. Mesa and the ddx dropped support for UMS and apparently very few people still use it since the UMS CS ioctl was broken for several kernels and no one reported it. It was fixed in 3.8/stable. - Rework GPU reset. Use the status registers to determine what blocks to reset. This better matches the recommended reset programming model. This also allows us to properly reset blocks besides GFX and DMA. - Switch the VM set page code to use an IB rather than the ring. This fixes overflow issues when doing large page table updates using a small ring like DMA. - Several small cleanups and bug fixes. * 'drm-next-3.9' of git://people.freedesktop.org/~agd5f/linux: (38 commits) drm/radeon/dce6: fix display powergating drm/radeon: add Oland pci ids drm/radeon: radeon-asic updates for Oland drm/radeon: add ucode loading support for Oland drm/radeon: fill in gpu init for Oland drm/radeon: add Oland chip family drm/radeon: switch back to using the DMA ring for VM PT updates drm/radeon: use IBs for VM page table updates v2 drm/radeon: don't reset the MC on IGPs/APUs drm/radeon: use the reset mask to determine if rings are hung drm/radeon: halt engines before disabling MC (si) drm/radeon: halt engines before disabling MC (cayman/TN) drm/radeon: halt engines before disabling MC (evergreen) drm/radeon: halt engines before disabling MC (6xx/7xx) drm/radeon: use status regs to determine what to reset (si) drm/radeon: use status regs to determine what to reset (cayman) drm/radeon: use status regs to determine what to reset (evergreen) drm/radeon: use status regs to determine what to reset (6xx/7xx) drm/radeon: rework GPU reset on cayman/TN drm/radeon: rework GPU reset on cayman/TN ...

drm/radeon: add Oland chip family

2013-02-02T00:34:23+00:00

Oland is a new asic in the SI family. Signed-off-by: Alex Deucher

efi: Make 'efi_enabled' a function to query EFI facilities

2013-01-30T19:51:59+00:00

Originally 'efi_enabled' indicated whether a kernel was booted from EFI firmware. Over time its semantics have changed, and it now indicates whether or not we are booted on an EFI machine with bit-native firmware, e.g. 64-bit kernel with 64-bit firmware. The immediate motivation for this patch is the bug report at, https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557 which details how running a platform driver on an EFI machine that is designed to run under BIOS can cause the machine to become bricked. Also, the following report, https://bugzilla.kernel.org/show_bug.cgi?id=47121 details how running said driver can also cause Machine Check Exceptions. Drivers need a new means of detecting whether they're running on an EFI machine, as sadly the expression, if (!efi_enabled) hasn't been a sufficient condition for quite some time. Users actually want to query 'efi_enabled' for different reasons - what they really want access to is the list of available EFI facilities. For instance, the x86 reboot code needs to know whether it can invoke the ResetSystem() function provided by the EFI runtime services, while the ACPI OSL code wants to know whether the EFI config tables were mapped successfully. There are also checks in some of the platform driver code to simply see if they're running on an EFI machine (which would make it a bad idea to do BIOS-y things). This patch is a prereq for the samsung-laptop fix patch. Cc: David Airlie Cc: Corentin Chary Cc: Matthew Garrett Cc: Dave Jiang Cc: Olof Johansson Cc: Peter Jones Cc: Colin Ian King Cc: Steve Langasek Cc: Tony Luck Cc: Konrad Rzeszutek Wilk Cc: Rafael J. Wysocki Cc: Signed-off-by: Matt Fleming Signed-off-by: H. Peter Anvin

drm/radeon: add quirk for d3 delay during switcheroo poweron for apple macbooks

2013-01-07T15:13:36+00:00

vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI configuration space is not restored correctly, resulting in MSI not working after switch. Only useful item in dmesg is: [ 33.922807] radeon 0000:01:00.0: Refused to change power state, currently in D3 I did some testing, dumping the difference in ms between first succesful switch from D3 to D0, and it seems that there is slightly more than 20 ms difference when the device is re-enabled through vga-switcheroo. So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not working on my system after switcheroo-ing. Default d3_delay value is PCI_PM_D3_WAIT, 10 ms. Signed-off-by: Maarten Lankhorst Signed-off-by: Alex Deucher

drm/radeon: restore modeset late in GPU reset path

2012-12-19T22:44:06+00:00

Modeset path seems to conflict sometimes with the memory management leading to kernel deadlock. This move modesetting reset after GPU acceleration reset. Signed-off-by: Jerome Glisse Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org

drm/radeon: avoid deadlock in pm path when waiting for fence

2012-12-19T22:44:05+00:00

radeon_fence_wait_empty_locked should not trigger GPU reset as no place where it's call from would benefit from such thing and it actually lead to a kernel deadlock in case the reset is triggered from pm codepath. Instead force ring completion in place where it makes sense or return early in others. Signed-off-by: Jerome Glisse Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org

drm/radeon: don't leave fence blocked process on failed GPU reset

2012-12-19T22:44:05+00:00

Force all fence to signal if GPU reset failed so no process get stuck on waiting fence. Signed-off-by: Jerome Glisse Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org