- 28 Nov, 2013 6 commits
-
-
Daniel Vetter authored
This was fumbled in the conversion to per-engine forcewake. Cc: Deepak S <deepak.s@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
On VLV the GTFIFOCTL register has other bits besides the number of free entries in the GT wake FIFO. Apply a mask when we read th register to make sure we don't misinterpret the number of free FIFO entries. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: There's some unclarity about hsw, but brushed off as todays' Bspec just acting up a bit.] Signed-off-by:
-
Ville Syrjälä authored
On VLV GTFIFODBG has more bits. Just report them all. Signed-off-by:
-
Deepak S authored
Forcewake counts for valleyview are not exposed throgh DebugFS. Exposing with this change. Signed-off-by:
Deepak S <deepak.s@intel.com> Reviewed-by:
-
Deepak S authored
Split vlv force wake routines to help individually control Media/Render well based on the register access. We've seen power savings in the lower sub-1W range on workloads that only need on of the power wells, e.g. glbenchmark, media playback Note: The same split isn't there for the forcewake queue, only the forcwake domains are split. Signed-off-by:
-
Deepak S authored
Added power well arguments to all the force wake routines to help us individually control power well based on the scenario. Signed-off-by:
-
- 27 Nov, 2013 1 commit
-
-
Chris Wilson authored
Due to user fudging (for instance using video=VGA-1:e with FBDEV=n) we can attempt to reset an inconsistent CRTC that is marked as active but has no assigned fb. It would be wise to fix this earlier, but the long term plan is to have primary and secondary planes associated with a CRTC, in which crtc->fb being NULL will be expected. So for a quick short term fix with pretensions of grandeur, just check for a NULL fb during GPU reset and ignore the plane restoration. This fixes a potential hard hang (a panic in the panic handler) following a GPU hang. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> [danvet: Add a corresponding fixme comment.] Signed-off-by:
-
- 26 Nov, 2013 18 commits
-
-
Imre Deak authored
Add a debugfs entry showing the use-count for all power domains of each power well. v3: address comments from Paulo: - simplify power_domain_str() by using a switch table - move power_well::domain_count to power_domains - WARN_ON decrementing a 0 refcount Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by:
-
Imre Deak authored
So far we distinguished platforms without a dynamic power well with the HAS_POWER_WELL macro and for such platforms we didn't call any power domain functions. Instead of doing this check we can add an always-on power well for these platforms and call the power domain functions unconditionally. For always-on power wells we only increase/decrease their refcounts, otherwise they are nop. This makes high level driver code more readable and as a bonus provides some idea of the current power domains state for all platforms (once the relevant debugfs entry is added). v3: rename intel_power_wells to i9xx_always_on_power_well (Paulo) Signed-off-by:
-
Imre Deak authored
Signed-off-by:
-
Jesse Barnes authored
This may need work if other platforms do the same thing, but in the meantime we should avoid looking at HSW specific bits in this generic function. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> [added IS_BROADWELL too as that needs the same handling (Imre)] Signed-off-by:
-
Imre Deak authored
In intel_display_capture_error_state we use HAS_POWER_WELL to check if we are running on Haswell/Broadwell when accessing HSW_PWR_WELL_DRIVER which is specific to these platforms. Future platforms with power wells don't have this register, so HAS_POWER_WELL won't work there any more. Use IS_HASWELL/IS_BROADWELL instead. v3: fix using logical || instead of bitwise | (Paulo) Signed-off-by:
-
Imre Deak authored
Instead of using a separate function to check whether a power domain is is always on, add an always-on power well covering all these power domains and do the usual get/put on these unconditionally. Since we don't assign a .set handler for these the get/put won't have any effect besides the adjusted refcount. This makes the code more readable and provides debug info also on the use of always-on power wells (once the relevant debugfs entry is added.) v3: make is_always_on to be bool instead of a bit field (Paulo) Signed-off-by:
-
Imre Deak authored
HW generations so far had only one always-on power well and optionally one dynamic power well. Upcoming HW gens may have multiple dynamic power wells, so add some infrastructure to support them. The idea is to keep the existing power domain API used by the rest of the driver and create a mapping between these power domains and the underlying power wells. This mapping can differ from one HW to another but high level driver code doesn't need to know about this. Through the existing get/put API it would just ask for a given power domain and the power domain framework would make sure the relevant power wells get enabled in the right order. Signed-off-by:
-
Imre Deak authored
This way the code is simpler and can also be used for other platforms where the audio power domain->power well mapping is different. Signed-off-by:
-
Jesse Barnes authored
If we use a stolen buffer, our probe callback shouldn't allocate a new buffer; we should re-use the one from the BIOS instead if possible. v2: fix locking (Jesse) Reviewed-by:
-
Chris Wilson authored
I believe, and an evening of i-g-t, that our original workaround for the missed interrupts on Sandybridge, that of holding forcewake whilst we wait for an interrupts, is no longer required. This leaves us dependent on the second workaround of forcing an UC read of the ACTHD before reading back the seqno from the snooped HWS. Dropping the forcewake should allow us to conserve a little power, not much as the GPU is meant to be busy whilst we wait for it! Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ben Widawsky authored
Our VM code already has a cleanup function, and this is a nice place to put the drm_mm_takedown. This should have no functional impact, it just leaves the unload function a bit cleaer, and is more logical IMO Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Ben Widawsky authored
This belonged in commit 07fe0b12 Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Jul 31 17:00:10 2013 -0700 drm/i915: plumb VM into bind/unbind code But it was somehow missed along the way. Signed-off-by:
-
Ben Widawsky authored
Signed-off-by:
-
Ben Widawsky authored
i915_gem_execbuffer_relocate became defunct in: commit 27173f1f Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Aug 14 11:38:36 2013 +0200 drm/i915: Convert execbuf code to use vmas eb_create: never used? Signed-off-by:
-
Ben Widawsky authored
Many tests call this ad naseum now (in an infinite loop, very often). It clutters the logs. Actually, I'd rather drop it completely... Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ben Widawsky authored
This would have never worked. Signed-off-by:
-
Ben Widawsky authored
This should really have been added in BDW integration, as well as: commit 93bd8649 Author: Ben Widawsky <ben@bwidawsk.net> Date: Tue Jul 16 16:50:06 2013 -0700 drm/i915: Put the mm in the parent address space It didn't really matter before, but it will in the future. Signed-off-by:
-
Ben Widawsky authored
When we fail for some reason on loading the PDPs, it would be wise to disable the PPGTT in the ring registers. If we do not do this, we have undefined results. Signed-off-by:
-
- 25 Nov, 2013 2 commits
-
-
Ville Syrjälä authored
SNB has another register where the actual FBC CPU fence number is stored. The documenation explicitly states that the fence number in DPFC_CTL must be 0 on SNB. And in fact when it's not zero, the GTT tracking simply doesn't work. Signed-off-by:
-
Daniel Vetter authored
Oops, makes testing early boot failures in i915.ko a bit more pain, so let's fix it. v2: We already have a bit of static storage to track this (Chris). Reviewed-by:
-
- 21 Nov, 2013 8 commits
-
-
Borislav Petkov authored
Too many t's. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Borislav Petkov authored
gcc complains that: drivers/gpu/drm/i915/i915_debugfs.c: In function ‘display_crc_ctl_write’: drivers/gpu/drm/i915/i915_debugfs.c:2393:2: warning: ‘val’ may be used uninitialized in this function [-Wuninitialized] drivers/gpu/drm/i915/i915_debugfs.c:2350:6: note: ‘val’ was declared here but it can't see that we're going to use val only in the success case. So shut it up. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Chris Wilson authored
We need to hold the pc8 lock around toggling the value of gpu_idle. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
We send the primary and cursor plane data through the gamma unit. In order to get matching output from sprites, also send the sprite data through the gamma unit. In the future we should add some properties to control this explicitly, and also add properties for the per-sprite gamma ramps what have you, but for now this seems like a reasonable thing to do. Signed-off-by:
-
Ville Syrjälä authored
All the other .enable_fbc() funcs use plane_name(). Make gen7_enable_fbc() do the same. Signed-off-by:
-
Ville Syrjälä authored
At least since SNB (perhaps even earlier) even the desktop parts should have FBC. Signed-off-by:
-
Ville Syrjälä authored
The spec tells us that we need to emit an SRM after the LRI to MSG_FBC_REND_STATE. Signed-off-by:
-
Ville Syrjälä authored
Don't issue the FBC nuke/cache clean command when invalidate_domains!=0. That would indicate that we're not being called for the post-batch flush. Signed-off-by:
-
- 18 Nov, 2013 3 commits
-
-
Daniel Vetter authored
This was forgotten in commit 9d1cb914 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Nov 1 13:32:08 2013 -0200 drm/i915: avoid unclaimed registers when capturing the error state Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Paulo Zanoni authored
It seems we do have machines with 3 HDMI/DVI outputs, so sharing WRPLLs is the only way to get 3 pipes working. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68485Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Daniel Vetter authored
Now we have this everywhere. Next up would be to wire up the DP hotplug pin to speed up panel power sequencing for eDP panels ... I've decided to leave the has_aux_irq logic in the code, it should come handy for hw bringup. For testing/fail-safety the dp aux code already has a timeout when waiting for interrupts to signal completion and screams rather loud if they don't arrive in time. Given that we need a real piece of hw to talk to anyway this is probably as good as it gets. v2: Don't check the dp aux channel bits on i965 machines, they have a different meaning there. Yay for reusing bits at will! Spotted by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 15 Nov, 2013 2 commits
-
-
Daniel Vetter authored
Pull in Jani's backlight rework branch. This was merged through a separate branch to be able to sort out the Broadwell conflicts properly before pulling it into the main development branch. Conflicts: drivers/gpu/drm/i915/intel_display.c Signed-off-by: -
Daniel Vetter authored
Merge the bdw changes into the backlight rework branch so that we can adapt the new code for bdw, too. This is a bit a mess, but doing this another way would have delayed the merging of the backlight refactoring. Mea culpa. As discussed with Jani on irc only do bdw-specific callbacks for the set/get methods and bake in the only other special-case into the pch enable function. Conflicts: drivers/gpu/drm/i915/intel_panel.c v2: Don't enable the PWM too early for bdw (Jani). v3: Create new bdw_ functions for setup and enable - the rules change sufficiently imo with the switch from controlling the pwm from the cpu to controlling it completel from the pch to warrant this. v4: Rip out unused pipe variable in bdw_enable_backlight (0-day builder). Tested-by: Ben Widawsky <ben@bwidawsk.net> (on bdw) Reviewed-by:
-
