- 06 Dec, 2013 1 commit
-
-
Paulo Zanoni authored
Currently, PC8 is enabled at modeset_global_resources, which is called after intel_modeset_update_state. Due to this, there's a small race condition on the case where we start enabling PC8, then do a modeset while PC8 is still being enabled. The racing condition triggers a WARN because intel_modeset_update_state will mark the CRTC as enabled, then the thread that's still enabling PC8 might look at the data structure and think that PC8 is being enabled while a pipe is enabled. Despite the WARN, this is not really a bug since we'll wait for the PC8-enabling thread to finish when we call modeset_global_resources. The spec says the CRTC cannot be enabled when we disable LCPLL, so we had a check for crtc->base.enabled. If we change to crtc->active we will still prevent disabling LCPLL while the CRTC is enabled, and we will also prevent the WARN above. This is a replacement for the previous patch named "drm/i915: get/put PC8 when we get/put a CRTC" Testcase: igt/pm_pc8/modeset-lpsp-stress-no-wait Signed-off-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 05 Dec, 2013 1 commit
-
-
Chris Wilson authored
If we force the hw to idle as our first step during unload, we can abort the unload upon failure. Later we can probe whether the hardware remain active even after we try to shut it down. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
- 04 Dec, 2013 8 commits
-
-
Mika Kuoppala authored
Doing it early prevents moving and relocating objects in vain for contexts that won't get any GPU time. Reported-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Chris Wilson authored
It is useful to assert that if the object is bound, then it must have its pages pinned to prevent the shrinker from reaping its backing store. This is even more useful with the introduction of real-ppgtt whereupon we may have the object bound into several vma, with each instance pinning the backing store. This assertion breaks down during unbind where we unpinned the backing store before decoupling the vma binding. This can be fixed with a trivial reording of the unbind sequence, which reinforces the pin pages bind to vma ... unbind from vma unpin pages concept. v2: Bonus comment Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Tested-by:
-
Deepak S authored
On VLV, FIFO will be shared by both SW and HW. So, we read the free entries through register and update dev_priv variable and wait for only 20 entries to be free From Deepak's follow-up mail explaining why vlv is special: "On SB, Out of 64 FIFO Entries, 20 Entries will be used by HW and remaining 44 will be used by the SW,. I think due to this reason, we have a threshold of 20 Entries." "On VLV, HW and SW can access all 64 fifo entries, I don't think having a threshold of 20 Entries is mandatory on VLV. Also, since both SW and HW can access all 64 Entries. I think on VLV, we need to update the fifo_count before waiting for the FIFO." v2: Apply mask when we read the number of free FIFO entries (Ville). v3: Mask applied after reading the register (Deepak). Signed-off-by:
Deepak S <deepak.s@intel.com> [danvet: Add further explanation from Deepak to commit message.] Signed-off-by:
-
Ville Syrjälä authored
Only plane A is FBC capable on gen2 (like gen3), but the panel fitter is hooked up to pipe B, so we want to prefer pipe B + plane A. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
Initialize the FBC vfuncs on gen2 and gen3 chipsets. Also make a clean split for gen7+ vs. gen5+ vfunc initialization. Signed-off-by:
-
Ville Syrjälä authored
On gen2 and gen3 chipsets FBC is supported only on plane A. Fix (and simplify) the plane checks in intel_update_fbc() accordingly. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Add a REG_WRITE_FOOTER macro as a counterpart to the REG_WRITE_HEADER. The current code has the spin_lock() in the HEADER, but the spin_unlock() is open coded, which looks rather confusing on the first glance. A bit of additional symmetry might help. Signed-off-by:
-
- 03 Dec, 2013 5 commits
-
-
Chris Wilson authored
When inspecting reports that boot/suspend/resume times are unusual it would be useful to clearly identify the time we must spend waiting for the hardware to complete its task. In this case we have a notification before we start waiting for the panel to change state, but none afterwards - which would be useful. Signed-off-by:
-
Jani Nikula authored
Checkpatch tells me WARNING: __packed is preferred over __attribute__((packed)) so switch over to __packed across the driver before adding new packed structs. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Check that the N and P dividers don't cause a divide by zero. This shouldn't happen under normal circumstances, but can happen eg. under simulation. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Damien Lespiau authored
Sweeping some dead code away. Signed-off-by:
-
Damien Lespiau authored
It's all about tiny details. Signed-off-by:
-
- 02 Dec, 2013 1 commit
-
-
Daniel Vetter authored
It's a pain for two reasons: - The vga plane redisablign requires actual legacy vgao i/o to pull of. The hw engineers really botched this one here :( - There seem to be some BIOS out there which send out lid events when unplugging. Together with our broken DP code, which disables the port when the cable is lost, this results in an immediate modeset call, which can hang on the wait for outstanding flips. - Also we don't want to force a modeset on machines where it's not really needed, see the referenced bug. We might want to extend this in general to also all machines that support opregion, since there the BIOS supposedly should manage the gfx hardware more cooperatively. v2: Pimp commit message a bit. Cc: Roland Dreier <roland@kernel.org> References: https://bugs.freedesktop.org/show_bug.cgi?id=65486Acked-by:
-
- 29 Nov, 2013 1 commit
-
-
Ville Syrjälä authored
We're currently misprinting the port name when vlv_wait_port_ready() times out. Fix it by using port_name(). Signed-off-by:
-
- 28 Nov, 2013 13 commits
-
-
Damien Lespiau authored
We had some mode_valid() vfuncs returning an int, others the enum. Let's use the latter everywhere. Signed-off-by:
-
Imre Deak authored
Atm we call intel_display_power_enabled() from i915_capture_error_state() in IRQ context and then take a mutex. To fix this add a new intel_display_power_enabled_sw() which returns the domain state based on software tracking as opposed to reading the actual HW state. Since we use domain_use_count for this without locking on the reader side make sure we increase the counter only after enabling all required power wells and decrease it before disabling any of these power wells. Regression introduced in commit 1b02383464b4a915627ef3b8fd0ad7f07168c54c Author: Imre Deak <imre.deak@intel.com> Date: Tue Sep 24 16:17:09 2013 +0300 drm/i915: support for multiple power wells Note that atm we depend on the value returned by intel_display_power_enabled_sw() in i915_capture_error_state() to avoid unclaimed register access reports. This was never guaranteed though, since another thread can disable the power concurrently. If this is a problem we need another explicit way to disable the reporting during error captures. v2: - remove barriers as the caller can't depend on the value returned from i915_capture_error_state_sw() anyway (Ville) - dump the state of pipe/transcoder power domain state (Daniel) Reported-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Jesse Barnes authored
This should just be a debug. Add another debug msg to the inherit path while we're at it. Signed-off-by:
-
Jesse Barnes authored
Setting this bit restores all ring contexts in parallel rather than serially. Matches current BWG recommendations. Tested-by:
"Meng, Mengmeng" <mengmeng.meng@intel.com> Signed-off-by:
Deepak S <deepak.s@inel.com> Signed-off-by:
-
Jesse Barnes authored
We use timeout mode, and we need to lower the timeout to get good RC6 residency when loads are running. This gets me from 0% residency during glxgears to 77%, which is a pretty good improvement. This value also matches the current BWG recommentations. Tested-by:
-
Daniel Vetter authored
It leads to a big mess when stuff interleaves. Especially with the new patch I've submitted for the drm core to no longer artificially split up debug messages. v2: The size parameter to snprintf includes the terminating 0, but the return value does not. Adjust the logic accordingly. Spotted by Mika. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
It doesn't like that we assign 0 to a pointer, it wants the real NULL. On closer look that initialization is actually bogus, and the compiler can easily see that we never use it unitialized. So let's just drop this. Cc: Deepak S <deepak.s@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
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: -
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ä 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 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:
-
- 26 Nov, 2013 9 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:
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:
-
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:
-
