summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2013-02-08drm/ttm: fix fence locking in ttm_buffer_object_transfer, 2nd tryDaniel Vetter
This fixes up commit e8e89622ed361c46bf90ba4828e685a8b603f7e5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Dec 18 22:25:11 2012 +0100 drm/ttm: fix fence locking in ttm_buffer_object_transfer which leaves behind a might_sleep in atomic context, since the fence_lock spinlock is held over a kmalloc(GFP_KERNEL) call. The fix is to revert the above commit and only take the lock where we need it, around the call to ->sync_obj_ref. v2: Fixup things noticed by Maarten Lankhorst: - Brown paper bag locking bug. - No need for kzalloc if we clear the entire thing on the next line. - check for bo->sync_obj (totally unlikely race, but still someone else could have snuck in) and clear fbo->sync_obj if it's cleared already. Reported-by: Dave Airlie <airlied@gmail.com> Cc: Jerome Glisse <jglisse@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-02-04Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds
Pull radeon fixes from Dave Airlie: "I got these late last week, the main chunks of these fix a rendering regression since 3.7, and the settle ones all fix the issue where we don't wait long enough for the memory controller to settle after turning it off which causes bad memory reads, they all fix real users bugs, and most of them are destined for stable. Can't remember if you had net connection on that island :-)" I don't know if the "two tin-cans and a string" thing here on "that island" can really be considered internet, but I guess I can pull things. Barely. * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/radeon: switch back to the CP ring for VM PT updates drm/radeon: prevent crash in the ring space allocation drm/radeon: Calling object_unrefer() when creating fb failure drm/radeon/r5xx-r7xx: wait for the MC to settle after MC blackout drm/radeon/evergreen+: wait for the MC to settle after MC blackout drm/radeon: protect against div by 0 in backend setup drm/radeon: fix backend map setup on 1 RB sumo boards drm/radeon: add quirk for RV100 board drm/radeon: add WAIT_UNTIL to the non-VM safe regs list for cayman/TN drm/radeon: fix MC blackout on evergreen+
2013-01-31drm/radeon: switch back to the CP ring for VM PT updatesAlex Deucher
For large VM page table updates, we can sometimes generate more packets than there is space on the ring. This happens more readily with the DMA ring since it is 64K (vs 1M for the CP). For now, switch back to the CP. For the next kernel, I have a patch to utilize IBs for VM PT updates which alleviates this problem. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=58354 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31drm/radeon: prevent crash in the ring space allocationAlex Deucher
If the requested number of DWs on the ring is larger than the size of the ring itself, return an error. In testing with large VM updates, we've seen crashes when we try and allocate more space on the ring than the total size of the ring without checking. This prevents the crash but for large VM updates or bo moves of very large buffers, we will need to break the transaction down into multiple batches. I have patches to use IBs for the next kernel. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-01-31drm/radeon: Calling object_unrefer() when creating fb failureliu chuansheng
When kzalloc() failed in radeon_user_framebuffer_create(), need to call object_unreference() to match the object_reference(). Signed-off-by: liu chuansheng <chuansheng.liu@intel.com> Signed-off-by: xueminsu <xuemin.su@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-01-31drm/radeon/r5xx-r7xx: wait for the MC to settle after MC blackoutAlex Deucher
Some chips seem to need a little delay after blacking out the MC before the requests actually stop. Stop DMAR errors reported by Shuah Khan. Reported-by: Shuah Khan <shuahkhan@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-31drm/radeon/evergreen+: wait for the MC to settle after MC blackoutAlex Deucher
Some chips seem to need a little delay after blacking out the MC before the requests actually stop. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=56139 https://bugs.freedesktop.org/show_bug.cgi?id=57567 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-01-31Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds
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
2013-01-30efi: Make 'efi_enabled' a function to query EFI facilitiesMatt Fleming
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>
2013-01-30drm/radeon: protect against div by 0 in backend setupMikko Tiihonen
Make sure at least one RB is enabled in r6xx_remap_render_backend() to avoid an division by zero in some corner cases. See: https://bugzilla.redhat.com/show_bug.cgi?id=892233 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-01-30drm/radeon: fix backend map setup on 1 RB sumo boardsAlex Deucher
Need to adjust the backend map depending on which RB is enabled. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=892233 Reported-by: Mikko Tiihonen <mikko.tiihonen@iki.fi> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-01-29drm/radeon: add quirk for RV100 boardAlex Deucher
vbios says external TMDS while the board is actually internal TMDS. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=60037 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-01-27drm/radeon: add WAIT_UNTIL to the non-VM safe regs list for cayman/TNAlex Deucher
Newer versions of mesa emit this. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-01-27drm/radeon: fix MC blackout on evergreen+Christopher Staite
Force the crtc mem requests on/off immediately rather than waiting for the double buffered updates to kick in. Seems we miss the update in certain conditions. Also handle the DCE6 case. Signed-off-by: Christopher Staite <chris@yourdreamnet.co.uk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2013-01-26Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intelDave Airlie
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
2013-01-25drm/exynos: add check for the device power statusShirish S
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>
2013-01-25drm/exynos: Make 'drm_hdmi_get_edid' staticSachin Kamat
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>
2013-01-25drm/exynos: fimd and ipp are broken on multiplatformArnd Bergmann
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>
2013-01-25drm/exynos: don't include plat/gpio-cfg.hArnd Bergmann
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>
2013-01-25drm/exynos: Remove "internal" interrupt handlingSean Paul
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>
2013-01-25drm/exynos: Add missing static specifiers in exynos_drm_rotator.cSachin Kamat
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>
2013-01-25drm/exynos: Replace mdelay with usleep_rangeSean Paul
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>
2013-01-25drm/exynos: Make ipp_handle_cmd_work staticSachin Kamat
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>
2013-01-25drm/exynos: Make g2d_userptr_get_dma_addr staticSachin Kamat
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>
2013-01-25drm/exynos: consider DMA_NONE flag to dmabuf importInki Dae
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>
2013-01-25drm/exynos: free sg object if dma_map_sg is failedInki Dae
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>
2013-01-25drm/exynos: added validation of edid for vidi connectionSeung-Woo Kim
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>
2013-01-25drm/exynos: let drm handle edid allocationsRahul Sharma
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>
2013-01-24drm/radeon: Enable DMA_IB_SWAP_ENABLE on big endian hosts.Michel Dänzer
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>
2013-01-23drm/radeon: fix a rare case of double kfreeIlija Hadzic
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
2013-01-23radeon_display: Use pointer return error codesxueminsu
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
2013-01-23drm/radeon: fix cursor corruption on DCE6 and newerJerome Glisse
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
2013-01-23drm/i915: dump UTS_RELEASE into the error_stateDaniel Vetter
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>
2013-01-23drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waitsChris Wilson
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>
2013-01-23drm/i915: Disable AsyncFlip performance optimisationsChris Wilson
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>
2013-01-21ttm: on move memory failure don't leave a node danglingDave Airlie
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>
2013-01-21ttm: don't destroy old mm_node on memcpy failureDave Airlie
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>
2013-01-21Merge branch 'drm-intel-fixes' of ↵Dave Airlie
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
2013-01-17Revert "drm/radeon: do not move bo to different placement at each cs"Alex Deucher
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>
2013-01-17drm/i915: fix FORCEWAKE posting readsJani Nikula
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>
2013-01-16drm/i915: Invalidate the relocation presumed_offsets along the slow pathChris Wilson
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>
2013-01-16drm/i915/eDP: do not write power sequence registers for ghost eDPJani Nikula
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>
2013-01-15drm/radeon: improve semaphore debugging on lockupJerome Glisse
Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2013-01-15drm/radeon: allow FP16 color clear registers on r500Marek Olšák
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>
2013-01-15drm/radeon: clear reset flags if engines are idleAlex Deucher
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>
2013-01-15drm/i915: Record DERRMR, FORCEWAKE and RING_CTL in error-stateChris Wilson
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>
2013-01-14udldrmfb: udl_get_edid: drop unneeded i--Hans de Goede
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>
2013-01-14udldrmfb: udl_get_edid: usb_control_msg buffer must not be on the stackHans de Goede
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>
2013-01-14udldrmfb: Fix EDID not working with monitors with EDID extension blocksHans de Goede
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>
2013-01-14Merge branch 'drm-fixes-3.8' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
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