summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds2013-01-311-1/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Peter Anvin: "This is a collection of miscellaneous fixes, the most important one is the fix for the Samsung laptop bricking issue (auto-blacklisting the samsung-laptop driver); the efi_enabled() changes you see below are prerequisites for that fix. The other issues fixed are booting on OLPC XO-1.5, an UV fix, NMI debugging, and requiring CAP_SYS_RAWIO for MSR references, just as with I/O port references." * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: samsung-laptop: Disable on EFI hardware efi: Make 'efi_enabled' a function to query EFI facilities smp: Fix SMP function call empty cpu mask race x86/msr: Add capabilities check x86/dma-debug: Bump PREALLOC_DMA_DEBUG_ENTRIES x86/olpc: Fix olpc-xo1-sci.c build errors arch/x86/platform/uv: Fix incorrect tlb flush all issue x86-64: Fix unwind annotations in recent NMI changes x86-32: Start out cr0 clean, disable paging before modifying cr3/4
| * efi: Make 'efi_enabled' a function to query EFI facilitiesMatt Fleming2013-01-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <airlied@linux.ie> Cc: Corentin Chary <corentincj@iksaif.net> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Dave Jiang <dave.jiang@intel.com> Cc: Olof Johansson <olof@lixom.net> Cc: Peter Jones <pjones@redhat.com> Cc: Colin Ian King <colin.king@canonical.com> Cc: Steve Langasek <steve.langasek@canonical.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Konrad Rzeszutek Wilk <konrad@kernel.org> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: <stable@vger.kernel.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
* | Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intelDave Airlie2013-01-263-6/+21
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just a few small things: - 2x workaround bits from Chris to fix up the new scanline waits enabled in 3.8 on snb. People who've been struck by this on dual-screen also need to upgrade the ddx. - Dump the kernel version into i915_error_state, we've had a few mixups there recently. - Disable gfx DMAR on gen4 devices, acked by David Woodhouse. * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: dump UTS_RELEASE into the error_state iommu/intel: disable DMAR for g4x integrated gfx drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waits drm/i915: Disable AsyncFlip performance optimisations
| * | drm/i915: dump UTS_RELEASE into the error_stateDaniel Vetter2013-01-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Useful for statistics or on overflowing bug reports to keep things all lined up. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waitsChris Wilson2013-01-231-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On SNB, if bit 13 of GFX_MODE, Flush TLB Invalidate Mode, is not set to 1, the hardware can not program the scanline values. Those scanline values then control when the signal is sent from the display engine to the render ring for MI_WAIT_FOR_EVENTs. Note setting this bit means that TLB invalidations must be performed explicitly through the appropriate bits being set in PIPE_CONTROL. References: https://bugzilla.kernel.org/show_bug.cgi?id=52311 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Disable AsyncFlip performance optimisationsChris Wilson2013-01-232-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a required workarounds for all products, especially on gen6+ where it causes the command streamer to fail to parse instructions following a WAIT_FOR_EVENT. We use WAIT_FOR_EVENT for synchronising between the GPU and the display engines, and so this bit being unset may cause hangs. References: https://bugzilla.kernel.org/show_bug.cgi?id=52311 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | drm/exynos: add check for the device power statusShirish S2013-01-252-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | V2: Add mutex protection, while read. The hdmi and mixer win_commit calls currently are not checking the status of IP before updating the respective registers, this patch adds this check. Signed-off-by: Shirish S <s.shirish@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
* | | drm/exynos: Make 'drm_hdmi_get_edid' staticSachin Kamat2013-01-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the following warning: drivers/gpu/drm/exynos/exynos_drm_hdmi.c:111:13: warning: symbol 'drm_hdmi_get_edid' was not declared. Should it be static? Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
* | | drm/exynos: fimd and ipp are broken on multiplatformArnd Bergmann2013-01-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While the exynos DRM support in principle can work on multiplatform, the FIMD and IPP sections of it both include the plat/map-base.h header file, which is not available on multiplatform. Rather than disabling the entire driver, we can just conditionally build these two parts. Without this patch, building allyesconfig results in: drivers/gpu/drm/exynos/exynos_drm_fimc.c:19:27: fatal error: plat/map-base.h: No such file or directory drivers/gpu/drm/exynos/exynos_drm_ipp.c:20:27: fatal error: plat/map-base.h: No such file or directory Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
* | | drm/exynos: don't include plat/gpio-cfg.hArnd Bergmann2013-01-251-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch 9eb3e9e6f3 "drm/exynos: add support for ARCH_MULTIPLATFORM" allowed building the exynos hdmi driver on non-samsung platforms, which unfortunately broke compilation in combination with 22c4f42897 "drm: exynos: hdmi: add support for exynos5 hdmi", which added an inclusion of the samsung-specific plat/gpio-cfg.h header file. Fortunately, that header file is not required any more here, so we can simply revert the inclusion in order to build the ARM allyesconfig again without getting this error: drivers/gpu/drm/exynos/exynos_hdmi.c:37:27: fatal error: plat/gpio-cfg.h: No such file or directory Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
* | | drm/exynos: Remove "internal" interrupt handlingSean Paul2013-01-251-60/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the "internal" interrupt handling since it's never invoked and remove "external" reference. This patch removes a bunch of dead code and clarifies how hotplugging is handled in the HDMI driver. Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
* | | drm/exynos: Add missing static specifiers in exynos_drm_rotator.cSachin Kamat2013-01-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the following warnings: drivers/gpu/drm/exynos/exynos_drm_rotator.c:737:24: warning: symbol 'rot_limit_tbl' was not declared. Should it be static? drivers/gpu/drm/exynos/exynos_drm_rotator.c:754:27: warning: symbol 'rotator_driver_ids' was not declared. Should it be static? Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
* | | drm/exynos: Replace mdelay with usleep_rangeSean Paul2013-01-252-8/+8
| | | | | | | | | | | | | | | | | | | | | Replace the unnecessary atomic mdelay calls with usleep_range calls. Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
* | | drm/exynos: Make ipp_handle_cmd_work staticSachin Kamat2013-01-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the following warning: drivers/gpu/drm/exynos/exynos_drm_ipp.c:872:6: warning: symbol 'ipp_handle_cmd_work' was not declared. Should it be static? Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
* | | drm/exynos: Make g2d_userptr_get_dma_addr staticSachin Kamat2013-01-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the following warning: drivers/gpu/drm/exynos/exynos_drm_g2d.c:327:12: warning: symbol 'g2d_userptr_get_dma_addr' was not declared. Should it be static? Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
* | | drm/exynos: consider DMA_NONE flag to dmabuf importInki Dae2013-01-251-14/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch considers DMA_NONE flag for other drivers not using dma mapping framework with iommu such as 3d gpu driver or others. For example, there might be 3d gpu driver that has its own iommu hw unit and iommu table mapping mechnism. So in this case, the dmabuf buffer imported into this driver needs just only sg table to map the buffer with its own iommu table itself. So this patch makes dma_buf_map_attachment ignore dma_map_sg call and just return sg table containing pages if dma_data_direction is DMA_NONE. Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
* | | drm/exynos: free sg object if dma_map_sg is failedInki Dae2013-01-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch releases sgt's sg object allocated by sgt_alloc_table correctly. When exynos_gem_map_dma_buf was called by dma_buf_map_attachmemt(), the sgt's sg object was allocated by sg_alloc_tale() so if dma_map_sg() is failed, the sg object should be released. Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
* | | drm/exynos: added validation of edid for vidi connectionSeung-Woo Kim2013-01-251-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If edid of vidi from user is invalid, size calculated from a number of cea extensions can be wrong. So, validation should be checked. Changelog v2: - just code cleanup . declare raw_edid only if vidi->connection is enabled. Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
* | | drm/exynos: let drm handle edid allocationsRahul Sharma2013-01-256-48/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no need to allocate edid twice and do a memcpy when drm helpers exist to do just that. This patch cleans that interaction up, and doesn't keep the edid hanging around in the connector. v4: - removed error check for drm_mode_connector_update_edid_property which is expected to fail for Virtual Connectors like VIDI. Thanks to Seung-Woo Kim. v3: - removed MAX_EDID as it is not used anymore. v2: - changed vidi_get_edid callback inside vidi driver. Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
* | | drm/radeon: Enable DMA_IB_SWAP_ENABLE on big endian hosts.Michel Dänzer2013-01-242-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes GPU hang during DMA ring IB test. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59672 Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | drm/radeon: fix a rare case of double kfreeIlija Hadzic2013-01-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If one (but not both) allocations of p->chunks[].kpage[] in radeon_cs_parser_init fail, the error path will free the successfully allocated page, but leave a stale pointer value in the kpage[] field. This will later cause a double-free when radeon_cs_parser_fini is called. This patch fixes the issue by forcing both pointers to NULL after kfree in the error path. The circumstances under which the problem happens are very rare. The card must be AGP and the system must run out of kmalloc area just at the right time so that one allocation succeeds, while the other fails. Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | | radeon_display: Use pointer return error codesxueminsu2013-01-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | drm_mode_addfb() expects fb_create return error code instead of NULL. Signed-off-by: xueminsu <xuemin.su@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | | drm/radeon: fix cursor corruption on DCE6 and newerJerome Glisse2013-01-231-1/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | Aruba and newer gpu does not need the avivo cursor work around, quite the opposite this work around lead to corruption. agd5f: check DCE6 rather than ARUBA since the issue is DCE version specific rather than family specific. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | ttm: on move memory failure don't leave a node danglingDave Airlie2013-01-211-0/+1
| | | | | | | | | | | | | | | | | | | | if we have a move notify callback, when moving fails, we call move notify the opposite way around, however this ends up with *mem containing the mm_node from the bo, which means we double free it. This is a follow on to the previous fix. Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | ttm: don't destroy old mm_node on memcpy failureDave Airlie2013-01-211-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When we are using memcpy to move objects around, and we fail to memcpy due to lack of memory to populate or failure to finish the copy, we don't want to destroy the mm_node that has been copied into old_copy. While working on a new kms driver that uses memcpy, if I overallocated bo's up to the memory limits, and eviction failed, then machine would oops soon after due to having an active bo with an already freed drm_mm embedded in it, freeing it a second time didn't end well. Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | Merge branch 'drm-intel-fixes' of ↵Dave Airlie2013-01-217-20/+84
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next More important fixes for 3.9: - error_state improvements to help debug the new scanline wait code added for gen6+ - bug reports started popping up :( patch from Chris Wilson. - fix a panel power sequence confusion between the eDP and lvds detection code resulting in black screens - regression introduce in 3.8 (Jani Nikula) - Chris fixed the root-cause of the ilk relocation vs. evict bug. - Another piece of cargo-culted rc6 lore from Jani, fixes up a regression where a system refused to go into rc6 after suspend sometimes. * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: fix FORCEWAKE posting reads drm/i915: Invalidate the relocation presumed_offsets along the slow path drm/i915/eDP: do not write power sequence registers for ghost eDP drm/i915: Record DERRMR, FORCEWAKE and RING_CTL in error-state
| * | drm/i915: fix FORCEWAKE posting readsJani Nikula2013-01-171-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We stopped reading FORCEWAKE for posting reads in commit 8dee3eea3ccd3b6c00a8d3a08dd715d6adf737dd Author: Ben Widawsky <ben@bwidawsk.net> Date: Sat Sep 1 22:59:50 2012 -0700 drm/i915: Never read FORCEWAKE and started using something from the same cacheline instead. On the bug reporter's machine this broke entering rc6 states after a suspend/resume cycle. It turns out reading ECOBUS as posting read worked fine, while GTFIFODBG did not, preventing RC6 states after suspend/resume per the bug report referenced below. It's not entirely clear why, but clearly GTFIFODBG was nowhere near the same cacheline or address range as FORCEWAKE. Trying out various registers for posting reads showed that all tested registers for which NEEDS_FORCE_WAKE() (in i915_drv.c) returns true work. Conversely, most (but not quite all) registers for which NEEDS_FORCE_WAKE() returns false do not work. Details in the referenced bug. Based on the above, add posting reads on ECOBUS where GTFIFODBG was previously relied on. In true cargo cult spirit, add posting reads for FORCEWAKE_VLV writes as well, but instead of ECOBUS, use FORCEWAKE_ACK_VLV which is in the same address range as FORCEWAKE_VLV. v2: Add more details to the commit message. No functional changes. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52411 Reported-and-tested-by: Alexander Bersenev <bay@hackerdom.ru> CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org [danvet: add cc: stable and make the commit message a bit clearer that this is a regression fix and what exactly broke.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Invalidate the relocation presumed_offsets along the slow pathChris Wilson2013-01-161-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the slow path, we are forced to copy the relocations prior to acquiring the struct mutex in order to handle pagefaults. We forgo copying the new offsets back into the relocation entries in order to prevent a recursive locking bug should we trigger a pagefault whilst holding the mutex for the reservations of the execbuffer. Therefore, we need to reset the presumed_offsets just in case the objects are rebound back into their old locations after relocating for this exexbuffer - if that were to happen we would assume the relocations were valid and leave the actual pointers to the kernels dangling, instant hang. Fixes regression from commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Nov 21 22:07:12 2010 +0000 drm/i915: Handle pagefaults in execbuffer user relocations Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55984 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@fwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/eDP: do not write power sequence registers for ghost eDPJani Nikula2013-01-161-15/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some machines detect an eDP port even if it's not really there, and eDP initialization has a fail path for this. Typically such machines have an LVDS display instead. A regression introduced in commit 82ed61fa1a4e08d5f9e86fb1b715b50ed678b6ac Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Oct 20 20:57:41 2012 +0200 drm/i915: make edp panel power sequence setup more robust updated the power sequence registers PCH_PP_ON_DELAYS, PCH_PP_OFF_DELAYS, and PCH_PP_DIVISOR also in the ghost eDP case, messing up the LVDS display. Split the power sequencer initialization into two, delaying the register updates until after we know the eDP is real. Note: Keep the PP_CONTROL unlocking in the first part, even if it does not update registers, per the commit message of the above mentioned commit. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52601 Reported-and-tested-by: Ryan Coe <ryan@rycomotorsports.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Record DERRMR, FORCEWAKE and RING_CTL in error-stateChris Wilson2013-01-154-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | These are useful for investigating hangs involving WAIT_FOR_EVENT. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Apply a droplet of Future-Proof in the if-ladder.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | Revert "drm/radeon: do not move bo to different placement at each cs"Alex Deucher2013-01-172-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit d025e9e2b890db679f1246037bf65bd4be512627. This causes corruption for a number of users and needs further investigation in the next cycle. https://bugzilla.kernel.org/show_bug.cgi?id=52491 https://bugs.freedesktop.org/show_bug.cgi?id=58659 http://lists.freedesktop.org/archives/dri-devel/2013-January/032961.html Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | drm/radeon: improve semaphore debugging on lockupJerome Glisse2013-01-153-0/+8
| | | | | | | | | | | | | | | Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | drm/radeon: allow FP16 color clear registers on r500Marek Olšák2013-01-152-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | Probably not a candidate for stable kernels because of conflicts in DRM versioning. Signed-off-by: Marek Olšák <maraeo@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | drm/radeon: clear reset flags if engines are idleAlex Deucher2013-01-154-0/+24
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes a hard lock in the gpu reset code after the rework for DMA support (0ecebb9e0d14e9948e0b1529883a776758117d6f "drm/radeon: switch to a finer grained reset for evergreen") due to not bailing before the MC shutdown if the relevant engines are idle. Discussion: http://lists.freedesktop.org/archives/dri-devel/2013-January/032985.html Reported-by: Eldad Zack <eldad@fogrefinery.com> Tested-by: Eldad Zack <eldad@fogrefinery.com> Acked-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | udldrmfb: udl_get_edid: drop unneeded i--Hans de Goede2013-01-141-1/+0
| | | | | | | | | | | | | | | | | | This is a left-over from when udl_get_edid returned the amount of bytes successfully read, which it no longer does. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* | udldrmfb: udl_get_edid: usb_control_msg buffer must not be on the stackHans de Goede2013-01-141-1/+7
| | | | | | | | | | | | | | | | | | | | The buffer passed to usb_control_msg may end up in scatter-gather list, and may thus not be on the stack. Having it on the stack usually works on x86, but not on other archs. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* | udldrmfb: Fix EDID not working with monitors with EDID extension blocksHans de Goede2013-01-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | udldrmfb only reads the main EDID block, and if that advertises extensions the drm_edid code expects them to be present, and starts reading beyond the buffer udldrmfb passes it. Although it may be possible to read more EDID info with the udl we simpy don't know how, and even if trial and error gets it working on one device, that is no guarantee it will work on other revisions. So this patch does a simple fix in the form of patching the EDID info to report 0 extension blocks, this fixes udldrmfb only doing 1024x768 on monitors with EDID extension blocks. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* | Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2013-01-143-9/+20
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-next Fixes for UMS mode which has been broken for a while plus an rn50 fix and a dma fix. * 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux: radeon/kms: fix dma relocation checking radeon/kms: force rn50 chip to always report connected on analog output drm/radeon: fix error path in kpage allocation drm/radeon: fix a bogus kfree drm/radeon: fix NULL pointer dereference in UMS mode
| * | radeon/kms: fix dma relocation checkingJerome Glisse2013-01-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | We were checking the index against the size of the relocation buffer instead of against the last index. This fix kernel segfault when userspace submit ill formated command stream/relocation buffer pair. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | radeon/kms: force rn50 chip to always report connected on analog outputJerome Glisse2013-01-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those rn50 chip are often connected to console remoting hw and load detection often fails with those. Just don't try to load detect and report connect. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| * | drm/radeon: fix error path in kpage allocationIlija Hadzic2013-01-101-2/+2
| | | | | | | | | | | | | | | | | | | | | Index into chunks[] array doesn't look right. Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | drm/radeon: fix a bogus kfreeIlija Hadzic2013-01-101-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | parser->chunks[.].kpage[.] is not always kmalloc-ed by the parser initialization, so parser_fini should not try to kfree it if it didn't allocate it. This patch fixes a kernel oops that can be provoked in UMS mode. Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * | drm/radeon: fix NULL pointer dereference in UMS modeIlija Hadzic2013-01-101-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | In UMS mode parser->rdev is NULL, so dereferencing will cause an oops. Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | Merge branch 'drm-nouveau-fixes' of ↵Dave Airlie2013-01-1417-52/+114
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next Regression fixes since rework mostly. * 'drm-nouveau-fixes' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: drm/nvc0/fb: fix crash when different mutex is used to protect same list drm/nouveau/clock: fix support for more than 2 monitors on nve0 drm/nv50/disp: fix selection of bios script for analog outputs drm/nv17-50: restore fence buffer on resume drm/nouveau: fix blank LVDS screen regression on pre-nv50 cards drm/nouveau: fix nouveau_client allocation failure path drm/nouveau: don't return freed object from nouveau_handle_create drm/nouveau/vm: fix memory corruption when pgt allocation fails drm/nouveau: add locking around instobj list operations drm/nouveau: do not forcibly power on lvds panels drm/nouveau/devinit: ensure legacy vga control is enabled during post
| * | drm/nvc0/fb: fix crash when different mutex is used to protect same listAleksi Torhamo2013-01-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes regression introduced in commit 861d2107 "drm/nouveau/fb: merge fb/vram and port to subdev interfaces" nv50_fb_vram_{new,del} functions were changed to use nouveau_subdev->mutex instead of the old nouveau_mm->mutex. nvc0_fb_vram_new still uses the nouveau_mm->mutex, but nvc0 doesn't have its own fb_vram_del function, using nv50_fb_vram_del instead. Because of this, on nvc0 a different mutex ends up being used to protect additions and deletions to the same list. This patch is a -stable candidate for 3.7. Signed-off-by: Aleksi Torhamo <aleksi@torhamo.net> Reported-by: Roy Spliet <r.spliet@student.tudelft.nl> Tested-by: Roy Spliet <r.spliet@student.tudelft.nl> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
| * | drm/nouveau/clock: fix support for more than 2 monitors on nve0Aleksi Torhamo2013-01-132-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes regression introduced in commit 70790f4f "drm/nouveau/clock: pull in the implementation from all over the place" When code was moved from nv50_crtc_set_clock to nvc0_clock_pll_set, the PLLs it is used for got limited to only the first two VPLLs. nv50_crtc_set_clock was only called to change VPLLs, so it didn't limit what it was used for in any way. Since nvc0_clock_pll_set is used for all PLLs, it has to specify which PLLs the code is used for, and only listed the first two VPLLs. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=58735 This patch is a -stable candidate for 3.7. Signed-off-by: Aleksi Torhamo <aleksi@torhamo.net> Tested-by: Aleksi Torhamo <aleksi@torhamo.net> Tested-by: Sean Santos <quantheory@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
| * | drm/nv50/disp: fix selection of bios script for analog outputsMarcin Slusarz2013-01-131-20/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Analog output number was overwritten by value from digital output path. Fix it. Fixes resume from s2ram: https://bugs.freedesktop.org/show_bug.cgi?id=58729 (as stumbled on by J Binder, Pontus Fuchs and me) Fixes blank screen on module load (reported by Sune Mølgaard). Fixes regression from commit 186ecad21c854385823a430b1402053ae7fd59dc ("drm/nv50/disp: move remaining interrupt handling into core"). Reported-by: J Binder <wheel@herr-der-mails.de> Reported-by: Pontus Fuchs <pontus.fuchs@gmail.com> Reported-by: Sune Mølgaard <sune@molgaard.org> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Tested-by: Marcin Slusarz <marcin.slusarz@gmail.com> Tested-by: Sune Mølgaard <sune@molgaard.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * | drm/nv17-50: restore fence buffer on resumeMarcin Slusarz2013-01-133-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 5e120f6e4b3f35b741c5445dfc755f50128c3c44 "drm/nouveau/fence: convert to exec engine, and improve channel sync" nouveau fence sync implementation for nv17-50 and nvc0+ started to rely on state of fence buffer left by previous sync operation. But as pinned bo's (where fence state is stored) are not saved+restored across suspend/resume, we need to do it manually. nvc0+ was fixed by commit d6ba6d215a538a58f0f0026f0961b0b9125e8042 "drm/nvc0/fence: restore pre-suspend fence buffer context on resume". Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=50121 Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
| * | drm/nouveau: fix blank LVDS screen regression on pre-nv50 cardsMarcin Slusarz2013-01-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 2a44e499 ("drm/nouveau/disp: introduce proper init/fini, separate from create/destroy") started to call display init routines on pre-nv50 hardware on module load. But LVDS init code sets driver state in a way which prevents modesetting code from operating properly. nv04_display_init calls nv04_dfp_restore, which sets encoder->last_dpms to NV_DPMS_CLEARED. drm_crtc_helper_set_mode nv04_dfp_prepare nv04_lvds_dpms(DRM_MODE_DPMS_OFF) nv04_lvds_dpms checks last_dpms mode (which is NV_DPMS_CLEARED) and wrongly assumes it's a "powersaving mode", the new one (DRM_MODE_DPMS_OFF) is too, so it skips calling some crucial lvds scripts. Reported-by: Chris Paulson-Ellis <chris@edesix.com> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
| * | drm/nouveau: fix nouveau_client allocation failure pathMarcin Slusarz2013-01-133-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | Depending on the point of failure, freed object would be returned or memory leak would happen. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
OpenPOWER on IntegriCloud