- 25 1月, 2013 9 次提交
-
-
由 Sachin 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: NSachin Kamat <sachin.kamat@linaro.org> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Sean Paul 提交于
Replace the unnecessary atomic mdelay calls with usleep_range calls. Signed-off-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Sachin 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: NSachin Kamat <sachin.kamat@linaro.org> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Sachin 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: NSachin Kamat <sachin.kamat@linaro.org> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Inki 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: NInki Dae <inki.dae@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
-
由 Inki 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: NInki Dae <inki.dae@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
-
由 Seung-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: NSeung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Rahul 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: NSean Paul <seanpaul@chromium.org> Signed-off-by: NRahul Sharma <rahul.sharma@samsung.com> Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Michel Dänzer 提交于
Fixes GPU hang during DMA ring IB test. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59672Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 24 1月, 2013 3 次提交
-
-
由 Ilija 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: NIlija Hadzic <ihadzic@research.bell-labs.com> Cc: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 xueminsu 提交于
drm_mode_addfb() expects fb_create return error code instead of NULL. Signed-off-by: Nxueminsu <xuemin.su@intel.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Jerome 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: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 21 1月, 2013 2 次提交
-
-
由 Dave 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: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave 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: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 18 1月, 2013 1 次提交
-
-
由 Alex Deucher 提交于
This reverts commit d025e9e2. 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.htmlSigned-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 17 1月, 2013 1 次提交
-
-
由 Jani Nikula 提交于
We stopped reading FORCEWAKE for posting reads in commit 8dee3eea 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=52411Reported-and-tested-by: NAlexander Bersenev <bay@hackerdom.ru> CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NChris 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: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 16 1月, 2013 2 次提交
-
-
由 Chris 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 bcf50e27 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=55984Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@fwll.ch> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani 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 82ed61fa 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=52601Reported-and-tested-by: NRyan Coe <ryan@rycomotorsports.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 15 1月, 2013 4 次提交
-
-
由 Jerome Glisse 提交于
Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Marek Olšák 提交于
Probably not a candidate for stable kernels because of conflicts in DRM versioning. Signed-off-by: NMarek Olšák <maraeo@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Fixes a hard lock in the gpu reset code after the rework for DMA support (0ecebb9e "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.htmlReported-by: NEldad Zack <eldad@fogrefinery.com> Tested-by: NEldad Zack <eldad@fogrefinery.com> Acked-by: NPaul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Chris Wilson 提交于
These are useful for investigating hangs involving WAIT_FOR_EVENT. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> [danvet: Apply a droplet of Future-Proof in the if-ladder.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 1月, 2013 3 次提交
-
-
由 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: NHans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Hans 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: NHans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Hans 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: NHans de Goede <hdegoede@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 13 1月, 2013 11 次提交
-
-
由 Aleksi Torhamo 提交于
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: NAleksi Torhamo <aleksi@torhamo.net> Reported-by: NRoy Spliet <r.spliet@student.tudelft.nl> Tested-by: NRoy Spliet <r.spliet@student.tudelft.nl> Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
由 Aleksi Torhamo 提交于
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: NAleksi Torhamo <aleksi@torhamo.net> Tested-by: NAleksi Torhamo <aleksi@torhamo.net> Tested-by: NSean Santos <quantheory@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
由 Marcin Slusarz 提交于
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 186ecad2 ("drm/nv50/disp: move remaining interrupt handling into core"). Reported-by: NJ Binder <wheel@herr-der-mails.de> Reported-by: NPontus Fuchs <pontus.fuchs@gmail.com> Reported-by: NSune Mølgaard <sune@molgaard.org> Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Tested-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Tested-by: NSune Mølgaard <sune@molgaard.org> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
Since commit 5e120f6e "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 d6ba6d21 "drm/nvc0/fence: restore pre-suspend fence buffer context on resume". Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=50121Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
由 Marcin Slusarz 提交于
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: NChris Paulson-Ellis <chris@edesix.com> Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
由 Marcin Slusarz 提交于
Depending on the point of failure, freed object would be returned or memory leak would happen. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
If we return freed vm, nouveau_drm_open will happily call nouveau_cli_destroy, which will try to free it again. Reported-by: NPeter Hurley <peter@hurleysoftware.com> Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Marcin Slusarz 提交于
Fixes memory corruptions, oopses, etc. when multiple gpuobjs are simultaneously created or destroyed. Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
由 Ben Skeggs 提交于
This fix was put in place to fix a bug where the eDP panel on certain laptops fails to respond over the aux channel after suspend. It appears that on some systems (Dell M6600, with LVDS panel) there's a very bad interaction with the eDP init table that causes the SOR to get very confused and not drive the panel correctly, leading to bleed. A DPMS off/on cycle is enough to bring it back, but, this will avoid the problem by not touching the panel GPIOs at times we're not meant to. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Fixes ACPI backlight control after suspend on some systems. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
- 11 1月, 2013 4 次提交
-
-
由 Jerome Glisse 提交于
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: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Jerome Glisse 提交于
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: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Ilija Hadzic 提交于
Index into chunks[] array doesn't look right. Signed-off-by: NIlija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Ilija Hadzic 提交于
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: NIlija Hadzic <ihadzic@research.bell-labs.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-