- 31 May, 2013 28 commits
-
-
Ben Widawsky authored
Like the other rings, the VECS supports semaphores. The semaphore stuff is a bit wonky so this patch on it's own should be nice for review. This patch should have no functional impact. v2: Fix the English parts of clarification (again, register names were right, text was reversed) (Damien) Restore the still valid invariant. (Damien) The bsd semaphore register should be MI_SEMAPHORE_SYNC_VVE (Damien) Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
The video enhancement command streamer is a new ring on HSW which does what it sounds like it does. This patch provides the most minimal inception of the ring. In order to support a new ring, we need to bump the number. The patch may look trivial to the untrained eye, but bumping the number of rings is a bit scary. As such the patch is not terribly useful by itself, but a pretty nice place to find issues during a bisection. Reviewed-by:
-
Ben Widawsky authored
This replaces the existing MBOX update code with a more generalized calculation for emitting mbox updates. We also create a sentinel for doing the updates so we can more abstractly deal with the rings. When doing MBOX updates the code must be aware of the /other/ rings. Until now the platforms which supported semaphores had a fixed number of rings and so it made sense for the code to be very specialized (hardcoded). The patch does contain a functional change, but should have no behavioral changes. Signed-off-by:
-
Ben Widawsky authored
Semaphores are tied very closely to the rings in the GPU. Trivial patch adds comments to the existing code so that when we add new rings we can include comments there as well. It also helps distinguish the ring to semaphore mailbox interactions by using the ringname in the semaphore data structures. This patch should have no functional impact. v2: The English parts (as opposed to register names) of the comments were reversed. (Damien) Signed-off-by:
-
Mika Kuoppala authored
crtc is holding a reference to a cursor bo and it needs to be released when crtc is destroyed so that we don't leak the cursor bo. v2: Enhance set and move cursor so that disabled cursor is handled correctly (Ville Syrjälä) Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Chris Wilson authored
It appears that a beneficial side-effect of Mika's more accurate hangman work is to speed up hang detection and execution. This exposes a bug in the reset code that then treats repeated simulated hangs as an indication that the machine is wedged. Jiggle the code around so that we only do the simulation processing from the hangcheck and avoid confusing it with a real hang. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65060Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
- Correct cpu->pch display matching is already check when we detect the PCH type at driver load. - Plane/pipe state is already checked both when a) enabling, b) disabling and in c) the modeset state checker. No need to go overboard and also check it in in between a) and b). Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Daniel Vetter authored
All this pipe config abstraction adds another layer of complexity, so it's good to have better visibility into what's going on exactly. Doesn't dump out everything yet, and some bits are a bit duplicated but this should be a good start. Note that at boot-up a lot of the fields are 0 even for enabled pipes, this is simply because our hw state readout code doesn't support everything. v2: Remove a few more now redudant debug output lines. v3: Review from Paulo - use transcoder_name - fix up format specifiers - add missing ':' in debug output Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
-
Wei Yongjun authored
Fix to return -ENOMEM in the kmap() error handling case instead of 0, as done elsewhere in this function. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
Jani Nikula authored
In the cloned case, changing just one output but keeping the other, the pipe state won't change and intel_crtc_update_dpms will be a nop, but we still need to update the dpms state of the output being changed. Only dvo, sdvo and crt are cloneable, so only those three have special dpms functions. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Daniel Vetter authored
This allows us to drop a bunch of ugly hacks and finally implement what commit cc464b2a Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Jan 25 16:59:16 2013 -0200 drm/i915: set TRANSCODER_EDP even earlier tried to achieve, but that was reverted again in commit bba2181c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Mar 22 10:53:40 2013 +0100 Revert "drm/i915: set TRANSCODER_EDP even earlier" Now we should always have a consistent cpu_transcoder in the pipe_config. v2: Fix up the code as spotted by Paulo: - read the register for real - assign the right pipes - break out if the hw state doesn't make sense v3: Shut up gcc. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Daniel Vetter authored
Well, as well as we can without completely revamping the drm vblank code. The issue are that - The vblank code needs to work on both ums and kms. - It deals always deals with pipes. - It doesn't take any of the kms locks. The last part is not really fixable without revamping the drm vblank code, since the drm core <-> driver interactions is a veritable pile of spaghettis. But the other pieces can be fixed by switching on the MODESET driver flag and either checking the hw state directly (ums case) or just querying our sw tracking (with broken locking, but that's not worse than what we've had). Note that this essentially reverts commit 702e7a56 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Tue Oct 23 18:29:59 2012 -0200 drm/i915: convert PIPECONF to use transcoder instead of pipe for the ums case, which will fix a NULL deref (since we really don't have any crtcs set up). But the real reason to do this is to drop our reliance on the cpu_transcoder: By only checking intel_crtc->active we don't need to make sure that the pipe_config (or at least the cpu_transcoder) contain safe values even when the pipe is off. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
-
Imre Deak authored
Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Imre Deak authored
The patch changes all remaining is_cpu_edp() check with a check for port A. We can do this, since in all these cases ValleyView is handled separately and port A is always a CPU side eDP port. Signed-off-by:
-
Imre Deak authored
On ValleyView for both eDP and DP the AUX input clock is 200MHz, so we can calculate for both the clock divider for the 2MHz target rate at the same place. Afterwards we can also replace the is_cpu_edp() check with a check for port A. Signed-off-by:
-
Imre Deak authored
Based on 3739850b - "drm/i915: disable the cpu edp port after the cpu pipe" and the bspec disabling sequence for IVB and older it seems we have to distinguish only the CPU vs. PCH port case, whether it's a DP or eDP doesn't seem to matter. For IVB and older on the CPU side we can only have eDP on port A, DP ports can only be on the PCH side. On VLV we have only CPU side eDP/DP ports, no PCH. So the condition for the disabling sequence we need for CPU ports is port == A || IS_VLV. This allows us to remove is_cpu_edp() completely in a later patch. v2: - simplify (and fix) the condition for CPU side ports and adjust the commit message accordingly (Daniel) Signed-off-by:
-
Imre Deak authored
Signed-off-by:
-
Ben Widawsky authored
If contexts were actually initialized, and we fail somewhere later during init this would possibly leak memory, and lead to some error messages about unclean takedown. As the odds of this occurring, and someone actually caring/noticing are pretty slim, the patch isn't terribly important. Found by code inspection while working on something else. Signed-off-by:
-
Ben Widawsky authored
Add some debug messages to help figure out what goes wrong on context initialization. Later in the PPGTT series, I ended up having a lot of failures after reset. In many cases it was extra difficult to debug because I hadn't even realized that contexts failed to reinitialize after reset (again an artifact of some later patches). This fairly benign patch does help debug some potential issues which arise later. Signed-off-by:
-
Ben Widawsky authored
I noticed this while doing the VMA abstraction. AFAICT, it won't actually fix anything, but it is the correct thing to do. Signed-off-by:
-
Ben Widawsky authored
The GTT start is either 0 in the KMS case, or some value which is set only after the init IOCTL in the UMS case. In both cases, we don't have this information until after we've tried to kick out the firmware fb. This patch should have no functional change since we kzalloc the GTT struct anyway. It only clarifies the situation for people who end up having to look at that code. This weirdness was introduced in: commit 93d18799 Author: Ben Widawsky <ben@bwidawsk.net> Date: Thu Jan 17 12:45:17 2013 -0800 drm/i915: Remove use of gtt_mappable_entries Signed-off-by:
-
Ben Widawsky authored
Since I'll need to modify i915_gem_object_bind_to_gtt(), fix the errors now to get checkpatch to not complain. Signed-off-by:
-
Ben Widawsky authored
Found with kmemleak. Signed-off-by:
-
Mika Kuoppala authored
In preparation to track per ring progress in hangcheck, add i915_hangcheck_ring_hung. v2: omit dev parameter (Ben Widawsky) Signed-off-by:
-
Mika Kuoppala authored
Instead of relying in acthd, track ring seqno progression to detect if ring has hung. v2: put hangcheck stuff inside struct (Chris Wilson) v3: initialize hangcheck.seqno (Ben Widawsky) Signed-off-by:
-
Mika Kuoppala authored
In preparation for next commit, pass seqno as a parameter to i915_hangcheck_ring_idle as it will be used inside i915_hangcheck_elapsed. Signed-off-by:
-
Paulo Zanoni authored
On Haswell, whenever we change the sprites we need to completely recalculate all the watermarks, because the sprites are one of the parameters to the LP watermarks, so a change on the sprites may trigger a change on which LP levels are enabled. So on this commit we store all the parameters we need to store for proper recalculation of the Haswell WMs and then call haswell_update_wm. Notice that for now our haswell_update_wm function is not really using these parameters we're storing, but on the next commits we'll use these parameters. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Paulo Zanoni authored
Because we want to call it from the "sprite disable" paths, since on Haswell we need to update the sprite watermarks when we disable sprites. For now, all this patch does is to add the "enable" argument and call intel_update_sprite_watermarks from inside ivb_disable_plane. This shouldn't change how the code behaves because on sandybridge_update_sprite_wm we just ignore the "!enable" case. The patches that implement Haswell watermarks will make use of the changes introduced by this patch. Signed-off-by:
-
- 23 May, 2013 12 commits
-
-
Jani Nikula authored
We never check the return values, and there's not much we could do on errors anyway. Just simplify the signatures. No functional changes. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Jani Nikula authored
Rename all VLV IOSF sideband register accessor functions to vlv_<port>_{read,write}. No functional changes. Signed-off-by: -
Jani Nikula authored
The lower level sideband read/write functions already do this. Signed-off-by:
-
Jani Nikula authored
Both the intel_dpio_{read,write} and valleyview_{punit,nc}_{read,write} use the IOSF sideband interface. They access the same registers and do mostly the same stuff, but no shared code. There are even duplicate register defines for the same registers. Both have locking, but the former use dpio_lock and the latter rps.hw_lock. It's racy. This patch refactors the sideband access to a single function that expects dpio_lock to be held. The dpio_lock is only used for sideband stuff, so it's a better match than rps.hw_lock for the purpose. The rps stuff still needs rps.hw_lock, since it's used to protect more than just the register access, so rps code will need to hold both locks. Based on the work by Shobhit Kumar <shobhit.kumar@intel.com> and Yogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>. Signed-off-by: -
Jani Nikula authored
Group both the HSW/LPT SBI interface and VLV IOSF sideband register accessor functions into a new file. No functional changes. v2: also move intel_sbi_{read,write} (Daniel) Signed-off-by: -
Mika Kuoppala authored
Sometimes when user is trying to get error state out from debugfs after gpu hang, the memory is low and/or fragmented enough that kmalloc in seq_file will fail. Prevent big kmalloc by avoiding seq_file and instead convert error state to string in smaller chunks. v2: better alloc flags, better truncate, correct locking, and error handling improvements (Chris Wilson) v3: printf annotations (Daniel Vetter) Signed-off-by:
-
Ville Syrjälä authored
The 'struct' keyword was missing so struct drm_rect documentation never ended up in the generated docs. Also move the drm_rect documentations to a new section alognside the various helper functions and add a short description about the intended purpose of drm_rect. v2: Move to new section and add general description Signed-off-by:
-
Thomas Meyer authored
Signed-off-by:
Thomas Meyer <thomas@m3y3r.de> Signed-off-by:
-
Chris Wilson authored
In commit 25ff1195 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Apr 4 21:31:03 2013 +0100 drm/i915: Workaround incoherence between fences and LLC across multiple CPUs we introduced an empirical workaround for memory corruption when using fences from multiple CPUs. At the time, we did not have any results for Valleyview, so the presumption was that it was limited to recent generations using LLC. Now we have evidence that Valleyview also suffers incoherence and requires a similar but different workaround. For Valleyview, the wbinvd instruction is insufficient and we require the serialising register write per-CPU. Conversely, that serialising register write is not enough for SNB/IVB/HSW. To compromise and keep the code relatively clean, employ both serialisation techniques in the same workaround. Reported-by:
Jon Bloomfield <jon.bloomfield@intel.com> Tested-by:
-
Ville Syrjälä authored
WARN_ON(!spin_is_locked()) is not a good idea on a UP system w/o spinlock debugging. Use WARN_ON_SMP() instead. This check has been added in commit 8ba2d185 Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Apr 12 15:18:37 2013 +0300 drm/i915: protect backlight registers and data with a spinlock Signed-off-by:
-
Chris Wilson authored
This should help debugging the truly unexpected cases where it occurs - in particular to see which value is garbage. References: https://bugzilla.kernel.org/show_bug.cgi?id=58511Signed-off-by:
-
Paulo Zanoni authored
Commit 1544d9d5 added a workaround inside haswell_init_clock_gating and mentioned it is "a workaround for early silicon revisions and should be removed later". This workaround is documented in bit 31 of PRI_CTL. I asked Arthur and he mentioned that setting FORCE_ARB_IDLE_PLANES replaces that workaround for the newer machines. So use the new one. Also notice that there's still another workaround for PRI_CTL that involves WM_DBG, but it's not the one we're reverting. And notice that we were previously setting WM_DBG_DISALLOW_MULTIPIPE_LP which disables the LP watermarks when more than one pipe is used, and we really don't want this because we need the LP watermarks if we want to reach deeper PC states. Signed-off-by:
-
