- 11 May, 2013 40 commits
-
-
Alex Deucher authored
commit 441e76ca upstream. The code was mis-handling variable sized arrays. Reported-by:
Sylvain BERTRAND <sylware@legeek.net> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alex Deucher authored
commit 62d1f92e upstream. Signed-off-by:
-
Alex Deucher authored
commit f8e6bfc2 upstream. If we have a empty power table, bail early and allocate the default power state. Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=63865Signed-off-by:
-
Alex Deucher authored
commit beb71fc6 upstream. Reviwed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Alex Deucher authored
commit e884fc64 upstream. Just disabling the mem requests should be enough, but that doesn't seem to work correctly on efi systems. v2: blank displays first, then disable. Signed-off-by:
-
Jerome Glisse authored
commit 466476df upstream. This is slightly cleaned up version of Jerome's patch. There seems to be an issue tracking the last flush of the VM which results in hangs in certain cases when VM is used. For now just flush the VM for every IB. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=62959 https://bugs.freedesktop.org/show_bug.cgi?id=62997Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 79b52d6a upstream. Signed-off-by:
-
Alex Deucher authored
commit dcb85290 upstream. These chips were previously skipped since they are pre-R600. Signed-off-by:
-
Alex Deucher authored
commit 0cd9cb76 upstream. If we fail to map the mmio BAR, skip driver tear down that requires mmio. Should fix: https://bugzilla.kernel.org/show_bug.cgi?id=56541Signed-off-by:
-
Alex Deucher authored
commit 2e97be73 upstream. Avoids potential interrupt storms when the display is disabled. May fix: https://bugzilla.kernel.org/show_bug.cgi?id=56041Signed-off-by:
-
Alex Deucher authored
commit 18932a28 upstream. Signed-off-by:
-
Alex Deucher authored
commit abf1457b upstream. Just disabling the mem requests should be enough, but that doesn't seem to work correctly on efi systems. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=57567 https://bugs.freedesktop.org/show_bug.cgi?id=43655 https://bugzilla.kernel.org/show_bug.cgi?id=56441 v2: blank displays first, then disable. Signed-off-by:
-
Alex Deucher authored
commit 2b48b968 upstream. Properly wait for the next vblank region. The previous code didn't always wait long enough depending on the timing. Signed-off-by:
-
Alex Deucher authored
commit 2f86e2ed upstream. Need to wait for the new addresses to take affect before re-enabling the MC. Signed-off-by:
-
Alex Deucher authored
commit 968c0166 upstream. Need to wait for the new addresses to take affect before re-enabling the MC. Signed-off-by:
-
Alex Deucher authored
commit 10257a6d upstream. Properly wait for the next vblank region. The previous code didn't always wait long enough depending on the timing. Signed-off-by:
-
Alex Deucher authored
commit bea5497b upstream. Properly wait for the next vblank region. The previous code didn't always wait long enough depending on the timing. Signed-off-by:
-
Alex Deucher authored
commit 7c1c7c18 upstream. A new tiling config register for the display blocks was added on DCE6. May fix: https://bugs.freedesktop.org/show_bug.cgi?id=62889 https://bugs.freedesktop.org/show_bug.cgi?id=57919Signed-off-by:
-
Alex Deucher authored
commit 367cbe2f upstream. Doesn't affect anything as the same address gets written in both cases. Signed-off-by:
-
Alex Deucher authored
commit 41167828 upstream. Monitors seem to prefer it. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=37696Signed-off-by:
-
Alex Deucher authored
commit bf05d998 upstream. It doesn't work reliably. Just report back the currently selected engine clock. Partially fixes: https://bugs.freedesktop.org/show_bug.cgi?id=62493Signed-off-by:
-
Zhang, Xiong Y authored
commit 43b27290 upstream. When ppgtt is enabled, dev_priv->gtt.total has excluded the gtt space occupied by ppgtt table in i915_gem_init_global_gtt() function. So the calculation of first_pd_entry_in_global_pt doesn't need to subtract I915_PPGTT_PD_ENTRIES again. Or else PPGTT directory table will be destroyed by global gtt allocation. This regression has been introduced in commit a54c0c27 Author: Ben Widawsky <ben@bwidawsk.net> Date: Thu Jan 24 14:45:00 2013 -0800 drm/i915: remove intel_gtt structure The breakage is pretty subtile since the old gtt_total_entries included the pde range, whereas the new on did not. Signed-off-by: Xiong Zhang<xiong.y.zhang@intel.com> [danvet: Add regression citation and cc: stable. Thanks to Chris for correcting my wrong guess about which commit broke things.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
David Müller authored
commit e4bfff54 upstream. As discussed in this thread http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html GMBUS based DVO transmitter detection seems to be unreliable which could result in an unusable DVO port. The attached patch fixes this by falling back to bit banging mode for the time DVO transmitter detection is in progress. Signed-off-by:
David Müller <d.mueller@elsoft.ch> Tested-by:
-
Daniel Vetter authored
commit b6c5164d upstream. Yet again our current confusion between doing the modeset globally, but only having the new parameters for one crtc at a time. So that intel_set_mode essentially already does a global modeset: intel_modeset_affected_pipes compares the current state with where we want to go to (which is carefully set up by intel_crtc_set_config) and then goes through the modeset sequence for any crtc which needs updating. Now the issue is that the actual interface with the remaining code still only works on one crtc, and so we only pass in one fb and one mode. In intel_set_mode we also only compute one intel_crtc_config (which should be the one for the crtc we're doing a modeset on). The reason for that mismatch is twofold: - We want to eventually do all modeset as global state changes, so it's just infrastructure prep. - But even the old semantics can change more than one crtc when you e.g. move a connector from crtc A to crtc B, then both crtc A and B need to be updated. Usually that means one pipe is disabled and the other enabled. This is also the reason why the hack doesn't touch the disable_pipes mask. Now hilarity ensued in our kms config restore paths when we actually try to do a modeset on all crtcs: If the first crtc should be off and the second should be on, then the call on the first crtc will notice that the 2nd one should be switched on and so tries to compute the pipe_config. But due to a lack of passed-in fb (crtc 1 should be off after all) it only results in tears. This case is ridiculously easy to hit on gen2/3 where the lvds output is restricted to pipe B. Note that before the pipe_config bpp rework gen2/3 didn't care really about the fb->depth, so this is a regression brought to light with commit 4e53c2e0 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw But apparently Ajax also managed to blow up pch platforms, probably with some randomized configs, and pch platforms trip up over the lack of an fb even in the old code. So this actually goes back to the first introduction of the new modeset restore code in commit 45e2b5f6 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Nov 23 18:16:34 2012 +0100 drm/i915: force restore on lid open Fix this mess by now by justing shunting all the cool new global modeset logic in intel_modeset_affected_pipes. v2: Improve commit message and clean up all the comments in intel_modeset_affected_pipes - since the introduction of the modeset restore code they've been a bit outdated. Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725 References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.htmlTested-by:
Richard Cochran <richardcochran@gmail.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Paulo Zanoni authored
commit c40c0f5b upstream. We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not have CRT, so just check for !IS_ULT. This problem happened on a real machine and resulted in a very ugly dmesg. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Jani Nikula authored
commit dc652f90 upstream. Backlight cleanup in the eDP connector destroy callback caused the backlight device to be removed on some systems that first initialized LVDS and then attempted to initialize eDP. Prevent multiple backlight initializations, and ensure backlight cleanup is only done once by moving it to modeset cleanup. A small wrinkle is the introduced asymmetry in backlight setup/cleanup. This could be solved by adding refcounting, but it seems overkill considering that there should only ever be one backlight device. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Tested-by:
Peter Verthez <peter.verthez@skynet.be> Signed-off-by:
-
Daniel Vetter authored
commit f30da187 upstream. It will be only consistent once we've restored all the crtcs. Since a bunch of other callers also want to just restore a single crtc, add a boolean to disable checking only where it doesn't make sense. Note that intel_modeset_setup_hw_state already has a call to intel_modeset_check_state at the end, so we don't reduce the amount of checking. v2: Try harder not to create a big patch (Chris). v3: Even smaller (still Chris). Also fix a trailing space. Reviewed-by:
Tomas Melin <tomas.melin@iki.fi> Tested-by:
-
Paulo Zanoni authored
commit 3f704fa2 upstream. Check the VBT to see if the machine has inverted FDI RX polarity on CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2 registers. This should fix some machines that were showing black screens on all outputs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60029Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Chris Wilson authored
commit 4615d4c9 upstream. Enabling context support increases SwapBuffers latency by about 20% (measured on an i7-3720qm). We can offset that loss slightly by enabling faster caching for the contexts. As they are not backed by any particular cache (such as the sampler or render caches) our only option is to select the generic mid-level cache. This reduces the latency of the swap by about 5%. Oddly this effect can be observed running smokin-guns on IVB at 1280x1024: Using BLT copies for swaps: 151.67 fps Using Render copies for swaps (unpatched): 141.70 fps With contexts disabled: 150.23 fps With contexts in L3$: 150.77 fps Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
Chris Wilson authored
commit 25ff1195 upstream. In order to fully serialize access to the fenced region and the update to the fence register we need to take extreme measures on SNB+, and manually flush writes to memory prior to writing the fence register in conjunction with the memory barriers placed around the register write. Fixes i-g-t/gem_fence_thrash v2: Bring a bigger gun v3: Switch the bigger gun for heavier bullets (Arjan van de Ven) v4: Remove changes for working generations. v5: Reduce to a per-cpu wbinvd() call prior to updating the fences. v6: Rewrite comments to ellide forgotten history. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62191Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Egbert Eich authored
commit 7a7d1fb7 upstream. The connector associated with the encoder is considered active when the output associtated with this connector is active on the encoder. The encoder itself is considered active when either there is an active output on it or the respective SDVO channel is active. Having active outputs when the SDVO channel is inactive seems to be inconsistent: such states can be found when intel_modeset_setup_hw_state() collects the hardware state set by the BIOS. This inconsistency will be fixed in intel_sanitize_crtc() (when intel_crtc_update_dpms() is called), this however only happens when the encoder is associated with a crtc. This patch also reverts: commit bd6946e8 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Apr 2 21:30:34 2013 +0200 drm/i915: Fix sdvo connector get_hw_state function Signed-off-by:
Egbert Eich <eich@suse.de> Suggested-by:
-
Christian Lamparter authored
commit 9e9dd0e8 upstream. The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900 mini desktop PCs are probably misleading the LVDS detection code in intel_lvds_supported. Nothing is connected to the LVDS ports in these systems. Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Daniel Vetter authored
commit bd6946e8 upstream. The active output is only the currently selected one, which does not imply that it's actually enabled. Since we don't use the sdvo encoder side dpms support, we need to check whether the chip-side sdvo port is enabled instead. v2: Fix up Bugzilla links. v3: Simplify logic a bit (Chris). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60138 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63031 Cc: Egbert Eich <eich@pdx.freedesktop.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Egbert Eich <eich@pdx.freedesktop.org> (v2) Signed-off-by:
-
Dave Airlie authored
commit 306373b6 upstream. Port over the mgag200 fix to ast as it suffers the same issue. On F19 testing, it was noticed we get a lot of errors in dmesg about being unable to reserve the buffer when plymouth starts, this is due to the buffer being in the process of migrating, so it makes sense we can't reserve it. In order to deal with it, this adds delayed updates for the dirty updates, when the bo is unreservable, in the normal console case this shouldn't ever happen, its just when plymouth or X is pushing the console bo to system memory. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Dave Airlie authored
commit 219b4733 upstream. Currently we have a problem with this: 1. i915: create gem object 2. i915: export gem object to prime 3. radeon: import gem object 4. close prime fd 5. radeon: unref object 6. i915: unref object i915 has an imported object reference in its file priv, that isn't cleaned up properly until fd close. The reference gets added at step 2, but at step 6 we don't have enough info to clean it up. The solution is to take a reference on the dma-buf when we export it, and drop the reference when the gem handle goes away. So when we export a dma_buf from a gem object, we keep track of it with the handle, we take a reference to the dma_buf. When we close the handle (i.e. userspace is finished with the buffer), we drop the reference to the dma_buf, and it gets collected. This patch isn't meant to fix any other problem or bikesheds, and it doesn't fix any races with other scenarios. v1.1: move export symbol line back up. v2: okay I had to do a bit more, as the first patch showed a leak on one of my tests, that I found using the dma-buf debugfs support, the problem case is exporting a buffer twice with the same handle, we'd add another export handle for it unnecessarily, however we now fail if we try to export the same object with a different gem handle, however I'm not sure if that is a case I want to support, and I've gotten the code to WARN_ON if we hit something like that. v2.1: rebase this patch, write better commit msg. v3: cleanup error handling, track import vs export in linked list, these two patches were separate previously, but seem to work better like this. v4: danvet is correct, this code is no longer useful, since the buffer better exist, so remove it. v5: always take a reference to the dma buf object, import or export. (Imre Deak contributed this originally) v6: square the circle, remove import vs export tracking now that there is no difference Reviewed-by:
-
Imre Deak authored
commit 011c2282 upstream. In commit be8a42ae we inroduced a refcount problem, where on the drm_gem_prime_fd_to_handle() error path we'll call dma_buf_put() for self imported dma buffers. Fix this by taking a reference on the dma buffer in the .gem_import hook instead of assuming the caller had taken one. Besides fixing the bug this is also more logical. Signed-off-by:
-
Anisse Astier authored
commit e127dc28 upstream. Backlight hotkeys weren't working before on certain cedartrail laptops. The source of this problem is that the hotkeys' ASLE opregion interrupts were simply ignored. Driver seemed to expect the interrupt to be associated with a pipe, but it wasn't. Accepting the ASLE interrupt without an associated pipe event flag fixes the issue, the backlight code is called when needed, making the brightness keys work properly. [patrik: This patch affects irq handling on any netbook with opregion support] Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=833597 Reference: http://lists.freedesktop.org/archives/dri-devel/2012-July/025279.htmlSigned-off-by:
Anisse Astier <anisse@astier.eu> Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by:
-
Dave Airlie authored
commit 64171959 upstream. On F19 testing, it was noticed we get a lot of errors in dmesg about being unable to reserve the buffer when plymouth starts, this is due to the buffer being in the process of migrating, so it makes sense we can't reserve it. In order to deal with it, this adds delayed updates for the dirty updates, when the bo is unreservable, in the normal console case this shouldn't ever happen, its just when plymouth or X is pushing the console bo to system memory. Signed-off-by:
-
Dave Airlie authored
commit f3b2bbdc upstream. Port over the mgag200 fix to cirrus as it suffers the same issue. On F19 testing, it was noticed we get a lot of errors in dmesg about being unable to reserve the buffer when plymouth starts, this is due to the buffer being in the process of migrating, so it makes sense we can't reserve it. In order to deal with it, this adds delayed updates for the dirty updates, when the bo is unreservable, in the normal console case this shouldn't ever happen, its just when plymouth or X is pushing the console bo to system memory. Signed-off-by:
-
James Bottomley authored
commit 871dd928 upstream. linux-v3.8-rc1 and later support for plug for blkdev_issue_discard with commit 0cfbcafc (block: add plug for blkdev_issue_discard ) For example, 1) DISCARD rq-1 with size size 4GB 2) DISCARD rq-2 with size size 1GB If these 2 discard requests get merged, final request size will be 5GB. In this case, request's __data_len field may overflow as it can store max 4GB(unsigned int). This issue was observed while doing mkfs.f2fs on 5GB SD card: https://lkml.org/lkml/2013/4/1/292 Info: sector size = 512 Info: total sectors = 11370496 (in 512bytes) Info: zone aligned segment0 blkaddr: 512 [ 257.789764] blk_update_request: bio idx 0 >= vcnt 0 mkfs process gets stuck in D state and I see the following in the dmesg: [ 257.789733] __end_that: dev mmcblk0: type=1, flags=122c8081 [ 257.789764] sector 4194304, nr/cnr 2981888/4294959104 [ 257.789764] bio df3840c0, biotail df3848c0, buffer (null), len 1526726656 [ 257.789764] blk_update_request: bio idx 0 >= vcnt 0 [ 257.794921] request botched: dev mmcblk0: type=1, flags=122c8081 [ 257.794921] sector 4194304, nr/cnr 2981888/4294959104 [ 257.794921] bio df3840c0, biotail df3848c0, buffer (null), len 1526726656 This patch fixes this issue. Reported-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Namjae Jeon <namjae.jeon@samsung.com> Tested-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
