- 13 Jul, 2015 2 commits
-
-
Akash Goel authored
Ring frequency table programming changes for SKL. No need for a floor on ring frequency, as the issue of performance impact with ring running below DDR frequency, is believed to be fixed on SKL v2: Removed the check for avoiding ring frequency programming for BXT (Rodrigo) Issue: VIZ-5144 Signed-off-by:
Akash Goel <akash.goel@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Akash Goel authored
Read the efficient frequency (aka RPe) value through the the mailbox command (0x1A) from the pcode, as done on Haswell and Broadwell. The turbo minimum frequency softlimit is not revised as per the efficient frequency value. v2: Replaced the conditional expression operator with 'if' statement (Tom) v3: Corrected the derivation of efficient frequency & shifted the GEN9_FREQ_SCALER multiplications downwards (Ville) Issue: VIZ-5143 Signed-off-by:
-
- 09 Jul, 2015 9 commits
-
-
Rodrigo Vivi authored
This fbdev restore mode was another corner case that was now calling frontbuffer flip and flush and making we miss screen updates with PSR enabled. So let's also add the invalidate hack here while we don't have a reliable dirty fbdev op. v2: As pointed by Paulo: removed seg fault risk, used fb_helper when possible and put brackets on if. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Testcase: igt/kms_fbcon_fbt/psr Signed-off-by:
-
Rodrigo Vivi authored
fbdev_set_par is called when fbcon is taking over control. In the past frontbuffer was being invalidated on set_to_gtt_domain, but it moved to set_domain fixing that case, but left this behind and broken in commit 031b698a Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jun 26 19:35:16 2015 +0200 drm/i915: Unconditionally do fb tracking invalidate in set_domain Note that even before this commit it wasn't perfect since the invalidate was omitted if the fbcon was already in the GTT domain, which it usually was. Since we are also invalidating in other fbdev cases this one was masked here. At least until now that I found this corner case: On boot with plymouth doing a splash screen when returning to the console frontbuffer wans't being invalidated causing missed screen updates with PSR enabled. So this patch fixes this issue. v2: Make invalidate directly and unconditionally and fix commit message indicating the set_domain fix as pointed out by Daniel. v3: Remove unecessary if(obj) added by mistake Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Rodrigo Vivi authored
Idle frames the number of identical frames needed before panel can enter PSR. There are some panels that requires up to minimum of 4 idle frames available on the market. For these cases usually VBT should be used to configure the number of idle frames, but unfortunately this isn't always true and VBT isn't being set at all. Let's trust VBT when it is set + 1 and use minimum of 4 + 1 when VBT isn't set. "+1" covers the "of-by-one" case. Signed-off-by:
-
Rodrigo Vivi authored
By Spec we should only mask memup and hotplug detection for hardware tracking cases. However we always masked LPSP because with power well always enabled on audio PSR was never being activated and residency was always zeroed. Apparently audio driver is tying power well management and runtime PM for some reason. But with audio runtime PM working or with audio completely out of picture we should remove this mask, otherwise we have a high risk of miss screen updates as faced by Matthew. WARNING: With this patch if snd_intel_hda driver is running and not releasing power well properly PSR will constant Exit and Performance Counter will be 0. But the best thing of this patch is that with one more HW tracking working the risks of missed blank screen are minimized at most. This affects just core platforms where PSR exit are also helped by HW tracking: Haswell, Broadwell and Skylake for now. v2: Fix commit message explanation. It has nothing to do with runtime PM on i915 as previously advertised. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by:
-
Paulo Zanoni authored
Reported by the kbuild test robot. Regression introduced by: commit fdbff928 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jun 18 11:23:24 2015 +0200 drm/i915: Clear fb_tracking.busy_bits also for synchronous flips (I reviewed this commit, so it's also my fault) Signed-off-by:
-
Paulo Zanoni authored
So make it static. Signed-off-by:
-
Paulo Zanoni authored
Reported by the kbuild test robot. Regression introduced by: commit de152b62 Author: Rodrigo Vivi <rodrigo.vivi@intel.com> Date: Tue Jul 7 16:28:51 2015 -0700 drm/i915: Add origin to frontbuffer tracking flush (I reviewed this commit, so it's also my fault) Signed-off-by:
-
Rodrigo Vivi authored
Let's do a frontbuffer flush on dirty fb. To be used for DIRTYFB drm ioctl. This patch solves the biggest PSR known issue, that is missed screen updates during boot, mainly when there is a splash screen involved like Plymouth. Previously PSR was being invalidated by fbdev and Plymounth was taking control with PSR yet invalidated and could get screen updates normally. However with some atomic modeset changes Pymouth modeset over ioctl was now causing frontbuffer flushes making PSR gets back to work while it cannot track the screen updates and exit properly. By adding this flush on dirtyfb we properly track frontbuffer writes and properly exit PSR. Actually all mmap_wc users should call this dirty callback in order to have a proper frontbuffer tracking. In the future it can be extended to return 0 if the whole screen has being flushed or the number of rects flushed as Chris suggested. v2: Remove ORIGIN_FB_DIRTY and use ORIGIN_GTT instead since dirty callback is just called after few screen updates and not on everyone as pointed by Daniel. v3: Use flush instead of invalidate since flush means invalidate + flush and dirty means drawn had finished and it can be flushed. v4: Remove PSR from subject since it is purely frontbuffer tracking change and that can be useful for FBC as well. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: -
Rodrigo Vivi authored
Since flush actually means invalidate + flush we need to force psr exit on PSR flush. On Core platforms there is no way to disable hw tracking and do the pure sw tracking so we simulate it by fully disable psr and reschedule a enable back. So a good idea is to minimize sequential disable/enable in cases we know that HW tracking like when flush has been originated by a flip. Also flip had just invalidated it already. It also uses origin to minimize the a bit the amount of disable/enabled, mainly when flip already had invalidated. With this patch in place it is possible to do a flush on dirty areas properly in a following patch. v2: Remove duplicated exit on HSW+Sprites as pointed out by Paulo. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
- 08 Jul, 2015 9 commits
-
-
Rodrigo Vivi authored
This will be useful to PSR and FBC once we start making dirty fb calls to also flush frontbuffer. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Arun Siluvery authored
wa_ctx_emit() depends on the name of a local variable; if the name of that variable is changed then we get compile errors. In this case it is unlikely to be changed as this macro is only used in this set of functions but Kernel coding guidelines doesn't recommend doing this. It was my mistake as I should have corrected it at the beginning but missed so correct this before there are more usages of this macro (Bob Beckett). https://www.kernel.org/doc/Documentation/CodingStyle, Chapter 12, "Things to avoid when using macros", point 2): " 2) macros that depend on having a local variable with a magic name: #define FOO(val) bar(index, val) might look like a good thing, but it's confusing as hell when one reads the code and it's prone to breakage from seemingly innocent changes. " v2: Optimization to avoid multiple evaluation of 'index' in the macro. Since we invoke it multiple times, compiler, if it can, should be able to coalesce them into a single condition and remove multiple WARN_ON checks (Chris). Suggested-by:
Robert Beckett <robert.beckett@intel.com> Cc: Robert Beckett <robert.beckett@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Sonika Jindal authored
Writing to PCH_PORT_HOTPLUG for each interrupt is not required. Handle it only if hpd has actually occurred like we handle other interrupts. v2: Make few variables local to if block (Ville) v3: Add check for ibx/cpt both (Ville). While at it, remove the redundant check for hotplug_trigger from pch_get_hpd_pins v4: Indentation (Ville) Reviewed-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Sonika Jindal <sonika.jindal@intel.com> Signed-off-by:
-
Paulo Zanoni authored
So now all the calls are inside __intel_fbc_update(). Consistency! Signed-off-by:
-
Paulo Zanoni authored
I have two separate refactor ideas that require extracting this to a separate function. I'm not sure which idea I'll end choosing, but since both will require extracting this function, let's do this now. Notice that this is just code moving. Any possible problems with the current multiple pipes check should be fixed in later commits. Signed-off-by:
-
Paulo Zanoni authored
The poor in_dbg_master() check was the only one without a reason string. Give it a reason string so it won't feel excluded. Signed-off-by:
-
Paulo Zanoni authored
This is all internal i915.ko work, let's start using intel_crtc for everything. Signed-off-by:
-
Paulo Zanoni authored
Because the cool kids use dev_priv and FBC wants to be cool too. We've been historically using struct drm_device on the FBC function arguments, but we only really need it for intel_vgpu_active(): we can use dev_priv everywhere else. So let's fully switch to dev_priv since I'm getting tired of adding "struct drm_device *dev = dev_priv->dev" everywhere. If I get a NACK here I'll propose the opposite: convert all the functions that currently take dev_priv to take dev. Signed-off-by:
-
Paulo Zanoni authored
Because it makes more sense there, IMHO. Signed-off-by:
-
- 07 Jul, 2015 3 commits
-
-
Daniel Vetter authored
After the register save/restore code is gone there's just one user left and it just obfuscates that one. Remove it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
-
Daniel Vetter authored
Burning cpu cycles isn't awesome, so use sleeps instead. Signed-off-by:
-
Daniel Vetter authored
Since that's really what we want to test for. Note remove the gen5 case doesn't change anything: In intel_setup_outputs ilk is handled already in the HAS_PCH_SPLIT case, and the register save/restore code touches registers which simply doesn't exist anymore at all. v2: Drop UMS parts. v3: Update commit message to reflect that the reg save/restore code is gone (Ville). Reviewed-by:
-
- 06 Jul, 2015 17 commits
-
-
Ville Syrjälä authored
Follow the correct pipe vs port disable sequence for the PCH LVDS ports, ie. disable the port after the pipe. Other PCH port were already converted in the following commits: 1ea56e26 drm/i915: Disable CRT port after pipe on PCH platforms 3c65d1d1 drm/i915: Disable SDVO port after the pipe on PCH platforms a4790cec drm/i915: Disable HDMI port after the pipe on PCH platforms 08aff3fe drm/i915: Move DP port disable to post_disable for pch platforms but LVDS was forgotten. Signed-off-by:
-
Matt Roper authored
intel_atomic_setup_scalers() dereferences 'plane' before the plane has been assigned. The plane ID assignment doing this dereference is only needed for debugging messages later in the function, so just move the assignment farther down the function to a point where plane will no longer be NULL. This was introduced in: commit 133b0d12 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Mon Jun 15 12:33:39 2015 +0200 drm/i915: Clean up intel_atomic_setup_scalers slightly. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Reported-by:Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Mika Kuoppala authored
Now when we have requests this deep on call chain, we can mark the elsp being submitted when it actually is. Remove temp variable and readjust commenting to more closely fit to the code. v2: Avoid tmp variable and reduce number of writes (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Mika Kuoppala authored
Pass around requests to carry context deeper in callchain. Signed-off-by:
-
Mika Kuoppala authored
Pass around requests to carry context deeper in callchain. Signed-off-by:
-
Mika Kuoppala authored
Pass around requests to carry context deeper in callchain. Signed-off-by:
-
Mika Kuoppala authored
In preparation to make intel_lr_context_pin|unpin to accept requests, assign ringbuf into request before we call the pinning. v2: No need to unset ringbuf on error path (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Mika Kuoppala authored
Pass around requests to carry context deeper in callchain. Signed-off-by:
-
Mika Kuoppala authored
Pass around requests to carry context deeper in callchain. Signed-off-by:
-
Niu,Bing authored
It is found that i915 will not reset gpu under execlist mode when unload module. that will lead to some issues when unload/load module with different submission mode. e.g. from execlist mode to ring buffer mode via loading/unloading i915. Because HW is not in a reset state and registers are not clean under such condition. Signed-off-by:
Niu,Bing <bing.niu@intel.com> Reviewed-by:
-
Arun Siluvery authored
In this WA we need to set GEN8_L3SQCREG4[21:21] and reset it after PIPE_CONTROL instruction but there is a slight complication as this is applied in WA batch where the values are only initialized once. Dave identified an issue with the current implementation where the register value is read once at the beginning and it is reused; this patch corrects this by saving the register value to memory, update register with the bit of our interest and restore it back with original value. This implementation uses MI_LOAD_REGISTER_MEM which is currently only used by command parser and was using a default length of 0. This is now updated with correct length and moved to appropriate place. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
-
Paulo Zanoni authored
Now all the functions called by other files check whether FBC has been initialized. This allows us to drop the checks on the static functions. v2: - s/HAS_FBC/dev_priv->display.enable_fbc/ everywhere but the init function (Chris). Suggested-by:
-
Paulo Zanoni authored
Everything is covered either by fbc.lock or mm.stolen_lock, and intel_fbc.c is already responsible for grabbing the appropriate locks when it needs them. Reviewed-by:
-
Paulo Zanoni authored
So don't grab the lock before calling the function. Reviewed-by:
-
Paulo Zanoni authored
So release the lock earlier. Reviewed-by:
-
Paulo Zanoni authored
Make sure we're not going to have weird races in really weird cases where a lot of different CRTCs are doing rendering and modesets at the same time. With this change and the stolen_lock from the previous patch, we can start removing the struct_mutex locking we have around FBC in the next patches. v2: - Rebase (6 months later) - Also lock debugfs and stolen. v3: - Don't lock a single value read (Chris). - Replace lockdep assertions with WARNs (Daniel). - Improve commit message. - Don't forget intel_pre_plane_update() locking. v4: - Don't remove struct_mutex at intel_pre_plane_update() (Chris). - Add comment regarding locking dependencies (Chris). - Rebase after the stolen code rework. - Rebase again after drm-intel-nightly changes. v5: - Rebase after the new stolen_lock patch. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4) Signed-off-by:
-
Paulo Zanoni authored
Which should protect dev_priv->mm.stolen usage. This will allow us to simplify the relationship between stolen memory, FBC and struct_mutex. v2: - Rebase after the stolen_remove_node() dev_priv patch move. - I realized that after we fixed a few things related to the FBC CFB size checks, we're not reallocating the CFB anymore with FBC enabled, so we can just move all the locking to i915_gem_stolen.c and stop worrying about freezing all the stolen alocations while freeing/rellocating the CFB. This allows us to fix the "Too coarse" observation from Chris. Suggested-by:
-
