- 11 Apr, 2016 7 commits
-
-
Chris Wilson authored
After we pin the ringbuffer into the GGTT, all error paths need to unpin it again. Move this common step into one block, and make the unable to iomap error code consistent (i.e. treat it as out of memory to avoid confusing it with a invalid argument). Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460113874-17366-3-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
We only need the struct_mutex to manipulate the pages_pin_count on the object, we do not need to hold our BKL when freeing the exported scatterlist. Signed-off-by:
-
Tim Gore authored
This is to fix a GPU hang seen with mid thread pre-emption and pooled EUs. v2. Use IS_BXT_REVID instead of IS_BROXTON and INTEL_REVID v3. And use correct type for register addresses Signed-off-by:
Tim Gore <tim.gore@intel.com> Reviewed-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
-
Dongwon Kim authored
For BXT, description of polarities of PORT_PLL_REF_SEL has been reversed for newer Gen9LP steppings according to the recent update in Bspec. This bit now should be set for "Non-SSC" mode for all Gen9LP starting from B0 stepping. v2: Only B0 and newer stepping should be affected by this change. Signed-off-by:
Dongwon Kim <dongwon.kim@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94866Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
Check functions are used by atomic to see if the new state will be allowed. There's also a hw state checker which checks afterwards that the committed state is correct. Rename it to hw state verifier to reduce some confusion. Suggested-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56FB8785.8020506@linux.intel.comReviewed-by:
-
Maarten Lankhorst authored
The modeset state verifier no longer has full access to the hardware, instead it should only verify affected crtc's. Looking for disabled stuff can be verified immediately after all crtc disables have completed, while each enabled crtc can be verified right after being enabled. Signed-off-by:
-
Maarten Lankhorst authored
This will make it easier to keep the crtc checker when atomic commit is reworked for asynchronous commits. This prevents checking crtc's that were not part of the state. It's safe to verify disabled encoders, connectors and dpll's that are not part of the state, because during modeset connection_mutex is held. Signed-off-by:
-
- 09 Apr, 2016 6 commits
-
-
Chris Wilson authored
When reading from the HWS page, we use barrier() to prevent the compiler optimising away the read from the volatile (may be updated by the GPU) memory address. This is more suited to READ_ONCE(); make it so. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460195877-20520-5-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
Rather than call a function to compute the matching cachelines and clflush them, just call the clflush *instruction* directly. We also know that we can use the unpatched plain clflush rather than the clflushopt alternative. Signed-off-by:
-
Chris Wilson authored
Only declare a missed interrupt if we find that the GPU is idle with waiters and a hangcheck interval has passed in which no new user interrupts have been raised. v2: Clear the stuck interrupt marker between successful batches Signed-off-by:
-
Chris Wilson authored
In order to simplify future patches, extract the lazy_coherency optimisation our of the engine->get_seqno() vfunc into its own callback. v2: Rename the barrier to engine->irq_seqno_barrier to try and better reflect that the barrier is only required after the user interrupt before reading the seqno (to ensure that the seqno update lands in time as we do not have strict seqno-irq ordering on all platforms). Reviewed-by: Dave Gordon <david.s.gordon@intel.com> [#v2] v3: Comments for hangcheck paranoia. Mika wanted to keep the extra barrier inside the hangcheck, just in case. I can argue that it doesn't provide a barrier against anything, but the side-effects of applying the barrier may prevent a false declaration of a hung GPU. Signed-off-by:
-
Chris Wilson authored
In order to ensure seqno/irq coherency, we currently read a ring register. The mmio transaction following the interrupt delays the inspection of the seqno long enough for the MI_STORE_DWORD_IMM to update the CPU cache. However, it is only the memory timing that is important for the purposes of the delay, we do not need nor desire the extra forcewake. v3: Update commentary Signed-off-by:
-
Akash Goel authored
Currently for the case where there is enough space at the end of Ring buffer for accommodating only the base request, the wrapround is done immediately and as a result the base request gets added at the start of Ring buffer. But there may not be enough free space at the beginning to accommodate the base request, as before the wraparound, the wait was effectively done for the reserved_size free space from the start of Ring buffer. In such a case there is a potential of Ring buffer overflow, the instructions at the head of Ring (ACTHD) can get overwritten. Since the base request can fit in the remaining space, there is no need to wraparound immediately. The wraparound will anyway happen later when the reserved part starts getting used. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Akash Goel <akash.goel@intel.com> Signed-off-by:
-
- 08 Apr, 2016 9 commits
-
-
Chris Wilson authored
Having fixed the tracking of the engine's last_submitted_seqno, we can now rely on it for detecting when the engine is idle (and not have to touch the requests pointer). Testcase: igt/gem_exec_whisper Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
Seal the request and mark it as pending execution before we submit it to hardware. We assume that the actual submission cannot fail (that guarantee is provided by preallocating space in the request for the submission). As we may inspect this state without holding any locks during hangcheck we should apply a barrier to ensure that we do not see a more recent value in the HWS than we are tracking. Based on a patch by Mika Kuoppala. Suggested-by:
-
Chris Wilson authored
When we change the current seqno, we also need to remember to reset the last_submitted_seqno for the engine. Testcase: igt/gem_exec_whisper Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460010558-10705-7-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
An oversight is that when we wrap the seqno, we need to reset the hw semaphore counters to 0. We did this for gen6 and gen7 and forgot to do so for the new implementation required for gen8 (legacy). Signed-off-by:
-
Chris Wilson authored
We reuse the same calculation into two macros, and I want to add a third user. Time to refactor. Signed-off-by:
-
Chris Wilson authored
Since we are setting engine local values that are tied to the hardware, move it out of i915_gem_init_seqno() into the intel_ring_init_seqno() backend, next to where the other hw semaphore registers are written. v2: Make the explanatory comment about always resetting the semaphores to 0 irrespective of the value of the reset seqno. Signed-off-by:
-
Chris Wilson authored
We only use drm_i915_private within the function, so delete the unneeded drm_device local. Signed-off-by:
-
Chris Wilson authored
After the GPU reset and we discard all of the incomplete requests, mark the GPU as having advanced to the last_submitted_seqno (as having completed the requests and ready for fresh work). The impact of this is negligible, as all the requests will be considered completed by this point, it just brings the HWS into line with expectations for external viewers. Signed-off-by:
-
Chris Wilson authored
It's useful to look at the last seqno submitted on a particular engine and compare it against the HWS value to check for irregularities. Signed-off-by:
-
- 07 Apr, 2016 8 commits
-
-
Ramalingam C authored
At BXT DSI, PIPE registers are inactive. So we can't get the PIPE's mode parameters from them. The possible option is retriving them from the PORT registers. The required changes are added for BXT in intel_dsi_get_config (encoder->get_config). v2: Addressed the Jani's comments -removed the redundant call to encoder->get_config -read bpp from port register -removed retrival of src_size from encoder->get_config v3: pipe_config->pipe_bpp is fixed Jani's review comments addressed: Few horizontal timing parameters dropped from the patch to make progress, as there seems to be some disagreement on best/feasible/possible options. Signed-off-by:Ramalingam C <ramalingam.c@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Previously Reviewed at: https://lists.freedesktop.org/archives/intel-gfx/2016-April/091737.htmlSigned-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460019967-26501-2-git-send-email-ramalingam.c@intel.com
-
Ramalingam C authored
Shared the function pixel_format_from_vbt for whole display module. Function declaration is added to intel_dsi.h. V2: Moved the function to intel_dsi.c and renamed as per the purpose of the function. Suggested by Jani. Signed-off-by:
-
Jani Nikula authored
The shorthand is easier. Also change the struct name. No functional changes. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Prepare for future. No functional changes. v2: Move earlier in the series. Use bool for gpio value. Reviewed-by:
-
Jani Nikula authored
Define and store the pad base offset in the array, and reference the pconf0 and padval registers through macros. Add VLV prefixes to macros. Use spec nomenclature for pconf0 and padval. v2: Address Ville's review comments, squash another patch here. v3: Use the names Ville dug up in the specs. Reviewed-by:
-
Joonas Lahtinen authored
dev_priv is what the macro works hard to extract, pass it directly. > sed 's/\([A-Z].*(dev_priv\)->dev)/\1)/g' v2: - Include all wrapper macros too (Chris) v3: - Include sed cmdline (Chris) v4: - Break long line - Rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Joonas Lahtinen authored
According to Chris, use of i915_vm_to_ppgtt is visible in benchmark unless WARN_ON is removed, so lets get rid of it. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by:
-
Joonas Lahtinen authored
Looks much better without container_of everywhere. v2: - In i915_gem_restore_gtt_mappings too (Chris) v3: - Do not cause WARN by calling on non PPGTT object (Chris) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 06 Apr, 2016 4 commits
-
-
Matt Roper authored
intel_update_max_cdclk() doesn't have a switch case for Broxton, so dev_priv->max_cdclk_freq gets set to whatever clock frequency we're currently running at (e.g., 144 MHz) rather than the true maximum. This causes our max dotclock to also be set too low and in turn leads mode verification to reject perfectly valid modes while loading EDID firmware blobs. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Kumar, Mahesh authored
Use plane size for relative data rate calculation. don't always use pipe source width & height. adjust height & width according to rotation. use plane size for watermark calculations also. v2: Address Matt's comments. Use intel_plane_state->visible to avoid divide-by-zero error. Where FB was present but not visible so causing total data rate to be zero, hence divide-by-zero. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93917 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94044 Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by:Kumar, Mahesh <mahesh1.kumar@intel.com> Reviewed-by:
-
Shubhangi Shrivastava authored
This patch sets the invert bit for hpd detection for each port based on VBT configuration. Since each AOB can be designed to depend on invert bit or not, it is expected if an AOB requires invert bit, the user will set respective bit in VBT. v2: Separated VBT parsing from the rest of the logic. (Jani) v3: Moved setting invert bit logic to bxt_hpd_irq_setup() and changed its logic to avoid looping twice. (Ville) v4: Changed the logic to mask out the bits first and then set them to remove need of temporary variable. (Ville) v5: Moved defines to existing set of defines for the register and added required breaks. (Ville) Signed-off-by:Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
Durgadoss R <durgadoss.r@intel.com> Signed-off-by:
Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Reviewed-by:
-
Shubhangi Shrivastava authored
This patch adds new fields that are not yet added in drm code in child devices struct Signed-off-by:
-
- 05 Apr, 2016 6 commits
-
-
Ville Syrjälä authored
Currently we set the initial GPU frequency to min_freq_softlimit on gen9, and to efficient_freq on VLV/CHV. On all the other platforms we set it to idle_freq. Let's use idle_freq across the board to make sure we don't waste power. This is especially relevant for VLV since Vnn won't drop to minimum unless the GPU is at the minimum frequency. Signed-off-by:
-
Ville Syrjälä authored
Extract the GPLL reference frequency from CCK and use it in the GPU freq<->opcode conversions on VLV/CHV. This eliminates all the assumptions we have about which divider is used for which czclk frequency. Note that unlike most clocks from CCK, the GPLL ref clock is a divided down version of the CZ clock rather than the HPLL clock. CZ clock itself is a divided down version of the HPLL clock though, so in effect it just gets divided down twice. While at it, throw in a few comments explaining the remaining constants for anyone who later wants to compare this to the spreadsheets. v2: Add slow/fast notes for CHV clocks (Imre) Signed-off-by:
-
Dave Gordon authored
After a suspend-resume cycle, the resumed kernel has no idea what the booted kernel may have done to the GuC before replacing itself with the resumed image. In particular, it may have already loaded the GuC with firmware, which will then cause this kernel's attempt to (re)load the firmware to fail (GuC program memory is write-once!). The symptoms (GuC firmware reload fails after hibernation) are further described in the Bugzilla reference below. So let's *always* reset the GuC just before (re)loading the firmware; the hardware should then be in a well-known state, and we may even avoid some of the issues arising from unpredictable timing. Also added some more fields & values to the definition of the GUC_STATUS register, which is the key diagnostic indicator if the GuC load fails. Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
-
Arun Siluvery authored
Due to timing issues in the HW, some of the status bits required for GuC authentication occasionally don't get set; when that happens, the GuC cannot be initialized and we will be left with a wedged GPU. The W/A suggested is to perform a soft reset of the GuC and attempt to reload the F/W again for few times before giving up. As the failure is dependent on timing, tests performed by triggering manual full gpu reset (i915_wedged) showed that we could sometimes hit this after several thousand iterations, but sometimes tests ran even longer without any issues. Reset and reload mechanism proved helpful when we indeed hit f/w load failure, so it is better to include this to improve driver stability. This change implements the following WAs, WaEnableuKernelHeaderValidFix:skl,bxt WaEnableGuCBootHashCheckNotSet:skl,bxt Signed-off-by:
Alex Dai <yu.dai@intel.com> Signed-off-by:
-
Chris Wilson authored
Both the oom and vmap notifier callbacks have a loop to acquire the struct_mutex and set the device as uninterruptible, within a certain time. Refactor the common code into a pair of functions. Suggested-by:
-
Chris Wilson authored
If the core runs out of vmap address space, it will call a notifier in case any driver can reap some of its vmaps. As i915.ko is possibily holding onto vmap address space that could be recovered, hook into the notifier chain and try and reap objects holding onto vmaps. Signed-off-by:
-
