- 20 Mar, 2014 8 commits
-
-
Chris Wilson authored
The point of this measure is to gauge why a process has a lot of gem objects in uses and why. Especially for compositors it's interesting to know whether it's a leak of private objects or just a lot of use from buffers shared with clients. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> [danvet: Add a bit of commit message flesh to address Ben's comment.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
The idea of printing objects used by each process is to judge how each process is using them. This means that we need to evaluate whether the object is bound for that particular process, rather than just whether it is bound into the global GTT. v2: Restore the non-full-ppgtt path for simplicity as we may not even create vma with older hardware. v3: Tweak handling of global entries and default context entries. Signed-off-by: -
Ben Widawsky authored
With the renamed RPS struct members, it's easier to skip the local variables which no longer clarify anything, and if anything just make the code harder to read. The real motivation for this patch is actually the next patch, which attempts to consolidate some of the functionality. Cc: Jeff McGee <jeff.mcgee@intel.com> Signed-off-by:
-
Ben Widawsky authored
The values created at initialization must always exist to use the interface. Reading them again is confusing, and pointless. More cleanups are coming in the next patch. Since I am not 100% certain, moreover on BYT, (though I am extremely close to that) that there is no need to leave the MMIO here, I wanted to make it a separate patch for the bisectable 'just-in-case' Signed-off-by:
-
Ben Widawsky authored
The names of the struct members for RPS are stupid. Every time I need to do anything in this code I have to spend a significant amount of time to remember what it all means. By renaming the variables (and adding the comments) I hope to clear up the situation. Indeed doing this make some upcoming patches more readable. I've avoided ILK because it's possible that the naming used for Ironlake matches what is in the docs. I believe the ILK power docs were never published, and I am too lazy to dig them up. v2: leave rp0, and rp1 in the names. It is useful to have these limits available at times. min_freq and max_freq (which may be equal to rp0, or rp1 depending on the platform) represent the actual HW min and max. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ben Widawsky authored
this leaves a temporarily awkward min_delay (the soft limit) with the new min_freq (the hardware limit). It's fixed in the next patch. Signed-off-by:
-
Ben Widawsky authored
Introduced: commit b8a5ff8d Author: Jeff McGee <jeff.mcgee@intel.com> Date: Tue Feb 4 11:37:01 2014 -0600 drm/i915: Update rps interrupt limits Cc: Jeff McGee <jeff.mcgee@intel.com> Signed-off-by:
-
Ben Widawsky authored
The existing code (which I changed last) was very convoluted. I believe it was attempting to skip the overclock portion if the previous pcode write failed. When I last touched the code, I was preserving this behavior. There is some benefit to doing it that way in that if the first pcode access fails, the later is likely invalid. Having a bit more confidence in my understanding of how things work, I now feel it's better to have clear, readable, code than to try to skip over this one operation in an unusual case. Signed-off-by:
-
- 19 Mar, 2014 21 commits
-
-
Paulo Zanoni authored
Function intel_init_runtime_pm is supposed to start allowing runtime PM from that point, but it's called very late on the driver initialization code, to prevent the driver from trying to suspend while still initializing. The problem is that variables are accessed earlier than that, so initalize them at intel_pm_setup, which is supposed to be the correct place. Notice that this shouldn't fix any specific bugs because dev_priv is zeroed when allocated, so the value is already correct right from the start. v2: - Rebase. Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
Now that PC8 got much simpler, there are less things to document. Also, runtime PM already has a nice documentation, so we don't need to re-explain it on our driver. v2: - Rebase. - Fix typo (Jesse). Reviewed-by: -
Paulo Zanoni authored
After we removed all the intermediate abstractions, we can rename these functions to just hsw_{en,dis}able_pc8. v2: - Rebase. Reviewed-by: -
Paulo Zanoni authored
The only remaining field of the struct was the lock, which was useless. v2: - Rebase. Reviewed-by:
-
Paulo Zanoni authored
When other platforms add runtime PM support they will also need to disable interrupts, so move the variable to the runtime PM struct. Also notice that the longer-term goal is to completely kill the regsave struct, and I even have patches for that. v2: - Rebase. v3: - Rebase. Reviewed-by:
-
Paulo Zanoni authored
It was just being used on debugfs and on a WARN inside hsw_set_power_well. But now that we PC8 is part of runtime PM and we get/put runtime PM when we get/put any power domain, we shouldn't need the WARN anymore. v2: - Rebase. v3: - Rebase. Reviewed-by:
-
Paulo Zanoni authored
Because we already get/put runtime PM every time we get/put any power domain, and now PC8 and runtime PM are the same thing. With this, we can also now kill the hsw_{en,dis}able_package_c8 functions. v2: - Rebase. v3: - Rebase. v4: - Rebase. Reviewed-by: -
Paulo Zanoni authored
Because we merged the PC8 and runtime PM features, so calling intel_runtime_pm_get now has the same meaning, and we plan to just remove hsw_disable_package_c8 for this exact reason. My first patch tried to completely kill intel_aux_display_runtime_get/put, because I was assuming that whoever needed more than just runtime PM would have to get the appropriate power domain instead of that, but it seems some people still want the intel_aux_display_runtime_get abstraction, so keep it until someone else tries to replace it with the more-standard power domain calls. Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Paulo Zanoni authored
We already get runtime PM references, and PC8 is now part of runtime PM, so this is enough. v2: - Rebase. Reviewed-by:
-
Paulo Zanoni authored
After the latest changes, the indirection is useless. Reviewed-by:
-
Paulo Zanoni authored
Since after the latest patches it's only being used to prevent getting/putting the runtime PM refcount. Reviewed-by:
-
Paulo Zanoni authored
... instead of PC8 references. Now that both are the same thing and we are killing PC8, just get the runtime PM reference. Reviewed-by:
-
Paulo Zanoni authored
The requirements_met variable was used to track two things: enabled CRTCs and the power well. After the latest chagnes, we get a runtime PM reference whenever we get any of the power domains, and we get power domains when we enable CRTCs or the power well, so we should already be covered, not needing this specific tracking. v2: - Rebase. v3: - Rebase. Signed-off-by:
-
Paulo Zanoni authored
Any power domain will require the HW to be in PCI D0 state, so just do the simple thing. Dear maintainer: since intel_display_power_put() and intel_display_power_get() are almost identical, git-am has failed apply the patch on my local machine once: it added both chunks to put(), instead of one chunk to get() and another to put(). When you apply this patch to your tree, please check if it is correct. v2: - Add the warning above. v3: - Rebase. Reviewed-by:
-
Paulo Zanoni authored
Currently, when our driver becomes idle for i915.pc8_timeout (default: 5s) we enable PC8, so we save some power, but not everything we can. Then, while PC8 is enabled, if we stay idle for more autosuspend_delay_ms (default: 10s) we'll enter runtime PM and put the graphics device in D3 state, saving even more power. The two features are separate things with increasing levels of power savings, but if we disable PC8 we'll never get into D3. While from the modularity point of view it would be nice to keep these features as separate, we have reasons to merge them: - We are not aware of anybody wanting a "PC8 without D3" environment. - If we keep both features as separate, we'll have to to test both PC8 and PC8+D3 code paths. We're already having a major pain to make QA do automated testing of just one thing, testing both paths will cost even more. - Only Haswell+ supports PC8, so if we want to add runtime PM support to, for example, IVB, we'll have to copy some code from the PC8 feature to runtime PM, so merging both features as a single thing will make it easier for enabling runtime PM on other platforms. This patch only does the very basic steps required to have PC8 and runtime PM merged on a single feature: the next patches will take care of cleaning up everything. v2: - Rebase. v3: - Rebase. - Fully remove the deprecated i915 params since Daniel doesn't consider them as part of the ABI. v4: - Rebase. - Fix typo in the commit message. v5: - Rebase, again. - Add a huge comment explaining the different forcewake usage (Chris, Daniel). - Use open-coded forcewake functions (Daniel). Signed-off-by: -
Paulo Zanoni authored
When we merge PC8 and runtime PM, these new functions are going to be called by the runtime suspend/resume functions, and their callers are going to be removed. v2: - Rebase Reviewed-by: Imre Deak <imre.deak@intel.com> (v1) Signed-off-by:
-
Daniel Vetter authored
Conflicts: drivers/gpu/drm/i915/intel_dp.c A bit a mess with reverts which differe in details between -fixes and -next and some other unrelated shuffling. Signed-off-by: -
Matt Roper authored
The name 'update_plane' was used both for the primary plane functions in intel_display.c and the sprite/overlay functions in intel_sprite.c. Rename the primary plane functions to 'update_primary_plane' to avoid confusion. On a similar note, intel_display.c already had a function called intel_disable_primary_plane() that programs the hardware to disable a pipe's primary plane. When we hook up primary planes through the DRM plane interface, one of the natural handler names will be intel_primary_plane_disable(), which is very similar. To avoid confusion, rename the existing intel_disable_primary_plane() to intel_disable_primary_hw_plane() to make the two names a little more distinct. Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> [danvet: Fix up conflicts.] Signed-off-by:
-
Jesse Barnes authored
So don't try to allocate and program it, we're only fooling ourselves. Reported-by:
"Chang, Junxiao" <junxiao.chang@intel.com> Signed-off-by:
-
Ben Widawsky authored
Apparently it is wiped out from under us, and we get some really fun caching artifacts upon resume (it seems to be WB for all types by default). Reported-by:
James Ausmus <james.ausmus@intel.com> Signed-off-by:
Timo Aaltonen <timo.aaltonen@canonical.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Steven Rostedt authored
The TP_printk() should never dereference any pointers, because the ring buffer can be read at some unknown time in the future. If a device no longer exists, it can cause a kernel oops. This also makes this event useless when saving the ring buffer in userspaces tools such as perf and trace-cmd. The i915_gem_evict_vm dereferences the vm pointer which may also not exist when the ring buffer is read sometime in the future. Link: http://lkml.kernel.org/r/1395095198-20034-3-git-send-email-artagnon@gmail.comReported-by:
Ramkumar Ramachandra <artagnon@gmail.com> Cc: stable@vger.kernel.org # 3.13+ Fixes: bcccff84 "drm/i915: trace vm eviction instead of everything" Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> [danvet: Try to make it actually compile] Signed-off-by:
-
- 18 Mar, 2014 11 commits
-
-
Damien Lespiau authored
When compiling on 32bits, I have the following warning: drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 7 has type ‘int’ [-Wformat=] DRM_DEBUG_DRIVER("CMD: Command length exceeds batch length: 0x%08X length=%d batchlen=%ld\n", The ptrdiff_t type has its own modifier: 't'. Cc: Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by:Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by:
-
Damien Lespiau authored
This function is only used on ILK+, so rename it accordingly. Signed-off-by:
-
Damien Lespiau authored
No need of any here. Signed-off-by:
-
Jani Nikula authored
This is a small follow-up fix to the series of eDP VDD back and forth we've had recently. This is effectively a combined revert of three commits: commit 2c2894f698fffd8ff53e1e1d3834f9e1035b1f39 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Mar 7 20:05:20 2014 -0300 drm/i915: properly disable the VDD when disabling the panel commit b3064154 Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Date: Tue Mar 4 00:42:44 2014 +0100 drm/i915: Don't just say it, actually force edp vdd commit dff392db Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Dec 6 17:32:41 2013 -0200 drm/i915: don't touch the VDD when disabling the panel which shows that we're pretty close back to where we started already. The first two were basically reverting the last, but missing the WARN. Add that back. We also OCD the intel_ prefix back to intel_edp_panel_vdd_on() which was lost somewhere in between. The circle closes. For future reference, "drm/i915: don't touch the VDD when disabling the panel" failed to take into account commit 6cb49835 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun May 20 17:14:50 2012 +0200 drm/i915: enable vdd when switching off the eDP panel and commit 35a38556 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Aug 12 22:17:14 2012 +0200 drm/i915: reorder edp disabling to fix ivb MacBook Air Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Daniel Vetter authored
Without this the new drv_suspend/forcewake subtest I've created doesn't result in immediately visible failures. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: -
Ben Widawsky authored
I have been seeing this for a long time, but ignored it because it's typically not terribly important. Recently, I really needed this info, and it was garbage. Proof that I should have fixed it sooner. Originally wrong from: commit 6c7a01ec Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Thu Jan 30 00:19:40 2014 -0800 drm/i915: Capture PPGTT info on error capture Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Paulo Zanoni authored
Commit b3064154 tried to revert commit dff392db, but wasn't complete, which resulted in regressions on Haswell. So this commit should fix b3064154 by undoing what it did and providing an actual complete revert of dff392db. Fixes regression introduced by: commit b3064154 Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Date: Tue Mar 4 00:42:44 2014 +0100 drm/i915: Don't just say it, actually force edp vdd Testcase: igt/pm_pc8 Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by:
-
Mika Kuoppala authored
We used to have per file descriptor hang stats for the i915_get_reset_stats_ioctl() and for default context banning. commit 0eea67eb Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Dec 6 14:11:19 2013 -0800 drm/i915: Create a per file_priv default context made having separate hangstats in file_private redundant as i915_hw_context already contained hangstats. So commit c482972a Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Fri Dec 6 14:11:20 2013 -0800 drm/i915: Piggy back hangstats off of contexts consolidated the hangstats and enabled further improvements. commit 44e2c070 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Thu Jan 30 16:01:15 2014 +0200 drm/i915: Use i915_hw_context to set reset stats tried to reap full benefits of consolidation but fell short as we never 'switch' to the fake private context on gens that don't have hw_contexts, so request->ctx remained NULL on those. Fix this by 'switching' to fake context so that when request is submitted to ring, proper context gets assigned to it. Testcase: igt/drv_hangman Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76055Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Daniel Vetter authored
This is a regression introduced in commit 0294ae7b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Mar 13 12:00:29 2014 +0000 drm/i915: Consolidate forcewake resetting to a single function The reordered setup sequence ended up calling del_timer_sync before the timer was set up correctly, resulting in endless hilarity when loading the driver. Compared to Ben's patch (which moved around the setup_timer call to sanitize_early) this moves the sanitize_early call around in the driver load call. This way we avoid calling setup_timer again in the resume code (where we also call sanitize_early). Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Tested-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76242Signed-off-by:
-
Jani Nikula authored
The functionality remains largerly the same. The main difference is that i2c-over-aux defer timeouts are increased to be safe for all use cases instead of depending on DP device type and properties. Signed-off-by:
-
Jani Nikula authored
Do a slight rearrangement of the switch to prep for follow-up. Signed-off-by:
-
